Guide pratique
Responsabilités d’un Tech-Lead : le guide concret
Publié le
Un Tech-Lead répond de cinq choses : la direction technique de l’équipe, la qualité de ce qui est livré, la capacité à livrer souvent sans stress, la fiabilité en production et la montée en compétence de l’équipe. Il ne fait pas tout lui-même. Il s’assure que c’est fait, rend les décisions explicites et retire ce qui bloque.
Direction technique et architecture
Le Tech-Lead porte la cohérence technique : quelles technologies, quel découpage, quelles frontières entre les composants. Deux idées aident à garder le cap. Chaque donnée a une seule source de vérité, et chaque composant a une seule responsabilité.
Chaque choix structurant est écrit avec son contexte et ses alternatives. Ce document sert à l’équipe actuelle et aux personnes qui arriveront dans deux ans.
Qualité et standards
Les contraintes coûtent peu au début d’un projet et très cher à la fin. Tests, typage, analyse statique, conventions de nommage : plus elles arrivent tôt, plus le projet garde son cap. On peut toujours relâcher une contrainte plus tard ; en ajouter une après coup fait mal.
Une convention qui n’est pas vérifiée automatiquement finit ignorée. Le rôle du Tech-Lead est de la faire porter par la CI plutôt que par les revues de code.
Livraison
Une équipe qui livre souvent livre plus sereinement. Le Tech-Lead raccourcit le chemin entre le code et la production : déploiement automatisé, environnements simples, peu d’étapes manuelles.
Il traque les goulots, y compris lui-même. Une validation qui attend toujours la même personne est un goulot. Limiter la taille des changements et la durée des chantiers garde le flux fluide.
Production et fiabilité
Tout système finit par tomber en panne. La question est de savoir si l’équipe l’apprend par une alerte ou par un client mécontent.
Le Tech-Lead s’assure que la supervision existe, qu’elle déclenche des alertes utiles et qu’elle mesure ce que vit l’utilisateur, au-delà de la charge CPU. La responsabilité de la production se partage au sein de l’équipe pour ne pas reposer sur une seule personne.
Dette technique
La dette technique se pilote. Le Tech-Lead distingue la dette subie, héritée du passé, de la dette choisie, prise volontairement pour livrer plus vite.
La dette choisie est écrite, datée et remboursée. La dette subie est rendue visible, puis traitée là où elle coûte le plus. Le but est que la structure du code oriente les évolutions futures dans la bonne direction.
Recrutement, accueil et montée en compétence
Le Tech-Lead participe au recrutement, en particulier à l’évaluation technique. Lire du code réel écrit par le candidat en dit plus long qu’un exercice au tableau.
Il prépare l’accueil : un nouvel arrivant productif rapidement est le meilleur indicateur d’un projet bien documenté. Ensuite, il fait progresser chacun par la revue de code, le binômage et des sujets choisis pour faire grandir.
Lien avec le produit et les métiers
Le Tech-Lead traduit entre l’équipe et le reste de l’entreprise. Il explique ce qu’une demande coûte vraiment et propose des alternatives moins chères. Il remonte aussi les problèmes de conception produit.
Un logiciel qui demande une formation pour être utilisé est souvent mal pensé. Donner aux métiers la main sur ce qui les concerne (configuration, règles, contenus) libère l’équipe technique.
Ce qui ne relève pas forcément du Tech-Lead
Selon les organisations, plusieurs sujets reviennent à d’autres rôles : la gestion de carrière et les entretiens annuels (Engineering Manager), la priorisation de la feuille de route (Product Manager), la cohérence du système d’information à l’échelle de l’entreprise (architecte ou CTO).
Le Tech-Lead y contribue sans en être le seul responsable. Le guide Tech-Lead vs Engineering Manager détaille ce partage.
Questions fréquentes
- Quelles sont les responsabilités d’un Tech-Lead ?
- La direction technique de l’équipe (choix et architecture), la qualité du code livré, la capacité à livrer souvent, la fiabilité en production, la gestion de la dette technique et la montée en compétence de l’équipe. Il fait aussi le lien avec le produit et les métiers.
- Quelle différence entre un Tech-Lead et un développeur senior ?
- Le développeur senior répond de la qualité de son propre travail. Le Tech-Lead répond de la direction technique et des résultats de toute l’équipe. Il passe donc une partie de son temps à décider, relire, expliquer et débloquer.
- Combien de temps un Tech-Lead passe-t-il à coder ?
- Cela dépend de la taille de l’équipe et de l’entreprise. Le repère utile est qualitatif : continuer à coder pour garder le contact avec le système, sans prendre les tâches dont dépend le reste de l’équipe.
- Le Tech-Lead est-il responsable des délais ?
- Il répond de la faisabilité technique et de la transparence : signaler tôt un risque, proposer un découpage, expliquer ce qu’un raccourci coûtera plus tard. L’engagement de date se prend en général avec le produit et le management.
- Comment savoir si un Tech-Lead fait bien son travail ?
- Quelques signaux : l’équipe livre régulièrement, les incidents sont détectés par la supervision avant les utilisateurs, les décisions techniques se retrouvent par écrit, les nouveaux arrivants deviennent vite autonomes et l’équipe fonctionne quand le Tech-Lead est absent.
Les autres guides
Les 60 principes, dans un seul livre
Chaque principe cité dans ces guides est développé dans NoBullshit Tech-Lead : 240 pages pour les développeurs, Tech-Leads, architectes et CTO.