Ce qui suit est ma lecture du métier, en référence aux essais que j’ai écrits. Ce n’est pas un manuel : c’est le point de vue de quelqu’un qui fait du logiciel depuis quinze ans dans des rôles hybrides — architecte, advisor, manager — et qui essaie de comprendre ce qui change vraiment et ce qui reste.
Dernière révision : 7 mai 2026.
Thèse en une phrase
Le logiciel est un métier au sens préindustriel du terme : apprentissage, goût et limites. La plupart des « best practices » sont des choix par défaut faits pour de mauvaises raisons, conservés parce que personne n’a jamais mesuré le coût de les avoir adoptés.
Comme je la vois
- Une architecture est un ensemble de décisions transmissibles. Si après deux ans personne ne sait pourquoi un choix a été fait, ce choix n’est pas une architecture : c’est un accident fossilisé.
- Le leadership technique est un problème d’autorité, pas de hiérarchie. On vous suit parce qu’on a vu que vous avez eu raison assez de fois. Le reste est un costume.
- L’Europe ne doit pas copier la Silicon Valley. Elle n’en a pas les prérequis — ni le capital, ni l’écosystème, ni l’échec socialement accepté. Notre avantage est le temps long : projets qui durent, équipes stables, clients fidèles. Plutôt que d’imiter le modèle rapide, ça vaut la peine de le capitaliser.
Essais sur ce thème
Travaillons ensemble
Mon engagement sur les architectures et le leadership technique se résume presque toujours à l’un de ces trois cas : une décision à bien prendre maintenant, une architecture en difficulté à redresser, une personne technique à faire grandir.
Pour qui c'est utile
CTO et Heads of Engineering qui doivent présenter à un board un choix architectural significatif et veulent une seconde tête avant
Fondateurs techniques qui constatent que l’architecture qui les a amenés ici ne les amènera pas à l’ordre de grandeur suivant
Équipes plateforme qui héritent d’un système complexe et doivent décider quoi garder, quoi réécrire, quoi jeter
Leaders techniques en croissance qui veulent un mentor externe pour parler des décisions les plus inconfortables
Comment je travaille
- Architecture review (2–4 semaines)
Je prends une architecture existante ou en projet, je parle avec ceux qui la maintiennent, je lis les design docs et les ADR, et je rends un jugement documenté : quoi garder, quoi changer, quoi mesurer avant de changer.
- Conception d'une nouvelle plateforme (4–8 semaines)
À partir de zéro ou d’une situation qui ne tient plus. Je travaille avec l’équipe interne pour produire un ensemble d’ADR, un stack argumenté et une roadmap avec des milestones mesurables.
- Mentorat de leadership technique (engagement continu)
Une ou deux calls par mois avec un CTO, un tech lead ou un architecte en croissance. Espace protégé pour parler des décisions difficiles sans politique interne.
Questions opérationnelles
- Vous occupez-vous de coding ou de code review ?
Non. Ce n’est pas ma valeur ajoutée. Le conseil porte sur les décisions de périmètre, pas sur l’implémentation.
- Travaillez-vous avec n'importe quel stack ?
Je travaille avec les décisions de stack, pas à l’intérieur d’un seul stack. Ma valeur est indépendante du langage — c’est comprendre quels trade-offs comptent vraiment à deux ans.
- Combien de temps dure un engagement type ?
Deux à quatre semaines pour une review, un à deux mois pour une conception, continu pour le mentorat.
- Comment se facture-t-il ?
À livrable documentable, pas à la journée. Le prix est fixe et lié à des livrables convenus au démarrage.
Écrivez-moi à hello@margiovanni.it avec deux lignes de contexte. Je réponds sous quelques jours ouvrés avec une proposition concrète, ou un refus poli si ce n'est pas mon périmètre.
Questions & answers
Pourquoi « métier » plutôt qu'« ingénierie » ?
Parce que l’ingénierie présuppose un savoir codifié et reproductible. Dans le logiciel réel — celui qui passe en production, survit à trois CTO et finit dans dix cahiers des charges différents — le savoir est largement tacite, se transmet par compagnonnage, et change avec le contexte. « Métier » décrit mieux la réalité.
Qu'est-ce que ça change ?
Ça change tout sur qui vous recrutez, comment vous le faites grandir, comment vous documentez, comment vous décidez. Qui raisonne en ingénieur cherche des processus. Qui raisonne en artisan cherche des maîtres, de la patience et un patrimoine de choix passés sur lequel s’appuyer.