Une entreprise publie une offre de Tech Lead.
Elle recherche une personne capable de coder, concevoir l’architecture, organiser les sprints, garantir les délais, encadrer les développeurs, recruter, gérer les incidents, parler aux clients et maintenir la motivation de l’équipe.
Le problème n’est pas que chacune de ces missions soit impossible. Le problème est que l’entreprise vient peut-être de regrouper cinq fonctions sous un seul titre, sans préciser laquelle est prioritaire.
Elle ne recrute alors pas un Tech Lead. Elle recrute une ambiguïté.
Le titre ne définit pas le poste
Les référentiels publics montrent que Tech Lead peut être une responsabilité temporaire, une casquette d’ingénieur senior, un archétype Staff, un emploi permanent ou un rôle hybride avec management.
Une fiche de poste ne devrait donc jamais commencer par une liste générique de tâches copiée sur le marché. Elle devrait commencer par le problème organisationnel que la personne doit résoudre.
Par exemple :
- l’équipe prend des décisions incompatibles entre elles ;
- les choix techniques ne tiennent pas compte de la roadmap produit ;
- personne ne porte les risques techniques de bout en bout ;
- les développeurs seniors travaillent chacun sur leur périmètre sans direction commune ;
- l’Engineering Manager absorbe trop de décisions techniques ;
- un architecte transverse définit des principes, mais personne n’en organise l’exécution dans l’équipe.
Ces situations peuvent justifier un Tech Lead. Elles n’impliquent pas toutes le même poste.
Commencer par le résultat attendu
Avant de publier l’offre, il faut pouvoir terminer cette phrase :
Même si cette personne délègue une grande partie du code et des documents de conception, elle restera responsable de…
Une réponse solide pourrait être :
…faire en sorte que les décisions techniques importantes soient prises, comprises et exécutées de manière cohérente par l’équipe, avec des risques visibles et des escalades réalisées au bon moment.
Une réponse telle que « développer les fonctionnalités les plus complexes » décrit plutôt une activité de développeur senior. « Gérer les carrières et les évaluations » décrit un mandat d’Engineering Manager. « Garantir le planning, le budget et les ressources » se rapproche de la gestion de projet. « Définir les standards de toute l’entreprise » dépasse généralement la portée d’un Tech Lead d’équipe.
Les rôles peuvent être fusionnés, mais la fusion doit être volontaire et annoncée.
Responsabilités et activités ne sont pas la même chose
Une fiche de poste classique accumule des activités :
- effectuer les revues de code ;
- rédiger les ADR ;
- animer les réunions techniques ;
- programmer en binôme ;
- accompagner les développeurs ;
- participer au recrutement.
Cette liste ne dit pas de quel résultat la personne répond.
Les revues de code ne sont qu’un moyen de soutenir la qualité. Les ADR ne sont qu’un moyen de rendre les décisions explicites. Les réunions ne sont qu’un moyen de créer de l’alignement. Le mentorat ne devrait pas créer une dépendance permanente au Tech Lead, mais augmenter l’autonomie de l’équipe.
Une bonne fiche distingue donc quatre catégories :
| Élément | Exemple |
|---|---|
| Résultat attendu | Direction technique cohérente et exécutable |
| Responsabilité | Faire traiter les risques et décisions critiques |
| Activités possibles | Design review, ADR, code review, mentorat, prototypage |
| Indicateurs | Risques détectés tôt, décisions comprises, moins de blocages récurrents, qualité adaptée au besoin |
Les huit décisions à prendre avant le recrutement
1. S’agit-il d’un poste, d’un niveau ou d’un rôle ?
Un candidat doit savoir si « Tech Lead » figurera dans son contrat, s’il s’agit d’une responsabilité attachée à une équipe ou si le terme désigne une progression de carrière.
2. Quel est le périmètre ?
Une équipe, un produit, un projet, plusieurs équipes ou une plateforme ? Le même titre ne peut pas être évalué de la même manière sur ces différentes portées.
3. Qui manage les personnes ?
Qui conduit les entretiens individuels ? Qui décide des promotions, des rémunérations et des plans de performance ? Si la réponse est « le Tech Lead », l’entreprise recrute un rôle hybride et doit l’assumer explicitement.
4. Qui porte la livraison ?
Le Tech Lead répond-il seulement de la crédibilité technique ? Possède-t-il également le périmètre, le calendrier, la relation client et la capacité de l’équipe ? La responsabilité est-elle partagée avec un Engineering Manager, un Product Manager ou un chef de projet ?
5. Quels sont ses droits de décision ?
Peut-il décider d’un choix local ? Doit-il obtenir l’accord d’un architecte ? Peut-il bloquer une mise en production ? Qui accepte un risque de sécurité ? Une responsabilité sans droits associés est un piège pour l’entreprise comme pour le candidat.
6. Quelle contribution au code est réellement attendue ?
Éviter les pourcentages décoratifs. Demander plutôt : la personne doit-elle posséder des fonctionnalités sur le chemin critique ? Peut-elle déléguer ? Combien d’équipes et d’interfaces doit-elle coordonner ?
7. Avec quels rôles travaillera-t-elle ?
La présence ou l’absence d’un Product Manager, Engineering Manager, architecte, Staff Engineer, équipe plateforme ou responsable sécurité change fortement le contenu du poste.
8. Comment sa réussite sera-t-elle évaluée ?
Le volume de code produit est insuffisant. La réussite peut inclure la qualité des décisions, la détection précoce des risques, la réduction des blocages, la soutenabilité du système et la progression technique de l’équipe.
Les erreurs fréquentes dans les offres
Rechercher « le meilleur codeur »
Une excellente capacité de développement ne garantit ni la délégation, ni l’alignement, ni la communication avec les parties prenantes. Le meilleur contributeur individuel peut devenir un mauvais Tech Lead s’il conserve toutes les tâches critiques.
Exiger une responsabilité sans autorité
Demander de « garantir la livraison » sans contrôle sur la capacité, le périmètre, les priorités ou les mécanismes d’escalade crée une responsabilité impossible.
Confondre leadership et management
Le mentorat et le feedback technique ne signifient pas nécessairement que la personne doit évaluer les carrières. Si l’entreprise souhaite les deux, elle doit décrire un Tech Lead Manager, pas dissimuler le management dans une ligne secondaire.
Inventer un pourcentage universel de code
Il n’existe pas de seuil démontré valable pour toutes les équipes. Le besoin dépend de la portée, du produit, du niveau d’autonomie et du nombre d’interfaces.
Empiler tous les rôles absents
Dans une petite entreprise, une même personne peut légitimement couvrir architecture, delivery, opérations et management. Mais la fiche doit présenter cette réalité, les priorités et les moyens disponibles. Le candidat doit pouvoir évaluer la charge réelle.
Un cadre de poste plus honnête
Une offre de Tech Lead devrait au minimum contenir :
- la finalité du rôle ;
- le périmètre technique et humain ;
- les résultats attendus après six à douze mois ;
- les droits de décision et d’escalade ;
- les responsabilités explicitement exclues ;
- les partenaires directs ;
- le niveau de contribution attendu au code ;
- la nature permanente, temporaire ou hybride du rôle.
Le recrutement devient alors plus simple. L’entreprise ne cherche plus une personne correspondant à un titre abstrait. Elle recherche une personne capable de produire un résultat précis dans une organisation réelle.
La première question d’entretien ne devrait donc pas être : « Avez-vous déjà été Tech Lead ? »
Elle devrait être : « Sur quel résultat technique collectif étiez-vous réellement attendu, et avec quels moyens pour l’obtenir ? »