Le Tech Lead décide où placer le niveau d'exigence technique, quels risques accepter pour livrer, et comment rendre l'équipe capable de tenir ces décisions sans dépendre de lui.
Le Tech Lead n'est ni le développeur le plus rapide de l'équipe, ni un architecte détaché du delivery, ni un manager hiérarchique par défaut. Il tient la cohérence technique d'un produit ou d'un domaine dans le temps : il transforme des contraintes parfois contradictoires — délai, fiabilité, dette, sécurité, compétences disponibles — en décisions compréhensibles, applicables et réversibles quand elles doivent l'être.
Un bon développeur peut résoudre un problème complexe. Celui qui tient réellement le rôle de Tech Lead décide aussi si ce problème mérite d'être résolu maintenant, à quel niveau, avec quel filet de sécurité et par qui. Il sait différencier une préférence technique d'un risque réel, une amélioration locale d'un enjeu systémique, une dette acceptable d'une fragilité qui menace la production.
La tension centrale du métier est double. Il faut rester assez proche du code et de la production pour conserver une autorité technique réelle, sans devenir le passage obligé de chaque revue, de chaque incident et de chaque choix. Il faut également défendre la qualité sans construire une doctrine impossible à livrer. L'évaluation cherche précisément cette capacité à tenir une ligne technique tout en augmentant l'autonomie collective.
Repères marché
Le titre de Tech Lead recouvre des réalités très différentes sur le marché français : référent de code, architecte d'équipe, responsable de delivery technique ou relais du management. Cette ambiguïté alimente des recrutements décevants, car beaucoup de profils sont évalués sur leur ancienneté ou leur expertise de stack plutôt que sur leur capacité à arbitrer et à faire progresser un collectif.
Le besoin porte particulièrement sur les profils capables de combiner crédibilité technique, maturité de production et influence sans autorité formelle. Les profils réellement équilibrés — ni goulot d'étranglement ni facilitateur sans capacité de décision technique — sont plus rares que les intitulés ne le laissent penser.
Contexte
En ESN, le Tech Lead doit décider dans un cadre où le patrimoine est souvent hérité, les équipes peuvent changer, plusieurs donneurs d'ordre interviennent et la marge de manœuvre dépend du contrat. L'évaluation insiste davantage sur la capacité à rendre explicites les risques, à distinguer ce qui relève du périmètre vendu de ce qui menace réellement la livraison, et à construire une décision applicable chez le client.
Niveau 1
Tech Lead de proximité
Il sécurise les décisions courantes d'une équipe, repère les défauts de conception, structure une revue et accompagne l'exécution. Il est crédible techniquement, mais reste dépendant d'un cadre posé ailleurs lorsqu'un arbitrage engage plusieurs équipes, la production ou la roadmap.
Cliquer pour lire
Niveau 2
Tech Lead d'équipe
Il tient la cohérence technique d'un produit dans la durée. Il séquence les évolutions, rend la dette visible, choisit ce qui doit bloquer une livraison et ce qui peut être assumé. Il ne se contente plus de donner un avis : il transforme un désaccord en décision, la documente et vérifie qu'elle est comprise par l'équipe.
Cliquer pour lire
Niveau 3
Tech Lead de domaine
Il arbitre au-delà d'un dépôt ou d'une squad. Il traite les frontières entre services, les dépendances, les trajectoires de migration, les différences de maturité entre équipes et les effets d'une décision locale sur l'exploitation globale. Il sait accepter plusieurs solutions locales lorsque leur uniformisation coûterait davantage qu'elle ne rapporte.
Cliquer pour lire
Niveau 4
Tech Lead transverse
Il ne se distingue pas parce qu'il connaît davantage de technologies. Il tranche des arbitrages qui engagent l'organisation et nomme explicitement leur coût : ralentir une livraison pour réduire un risque majeur, maintenir temporairement deux architectures, refuser une standardisation prématurée ou accepter une dette bornée pour préserver un enjeu produit. Son rôle est aussi de rendre la décision durable sans devenir lui-même indispensable à son application.
Cliquer pour lire
Cette catégorie pèse le plus lourd parce que la légitimité du rôle repose sur la capacité à comprendre les mécanismes, à découper correctement un problème et à décider au bon niveau d'abstraction — pas sur la maîtrise déclarative d'une stack.
Un Tech Lead engage la production autant que le code. La qualité des tests, l'observabilité, la résilience, la sécurité et la capacité à diagnostiquer doivent peser presque autant que la conception, car une architecture élégante mais inexploitable reste une mauvaise décision.
Le rôle échoue lorsque toute la qualité dépend d'une seule personne. Ce poids mesure la capacité à faire progresser les développeurs, déléguer les décisions, poser des standards utilisables et créer une culture de revue qui améliore le collectif au lieu de le ralentir.
La technique n'est jamais évaluée hors contexte. Le Tech Lead doit traduire une contrainte technique en impact de délai, de risque ou de valeur, proposer des options décidables et porter une position sans confondre influence et autorité hiérarchique.
Cette catégorie reste volontairement plus légère : les standards ne valent que s'ils servent les quatre précédentes. Elle distingue le Tech Lead qui corrige un cas isolé de celui qui transforme un incident en apprentissage collectif.
La méthode en action
La scorecard en un regard — survoler un axe
Développement et ingénierie logicielle