L'entretien annuel d'un développeur : le format qui fonctionne vraiment
L'entretien annuel d'un développeur : le format qui fonctionne vraiment
J'ai conduit des entretiens annuels pendant des années avec un formulaire RH standard. Cinq questions génériques, une note sur une échelle de 1 à 5, une case "commentaires" que tout le monde remplissait avec des généralités. À Canal+, j'ai eu le cas d'un développeur senior (7 ans dans l'organisation, excellente technique) qui a remis sa démission deux semaines après son entretien annuel. Sa raison : "Personne ne m'a jamais demandé où je voulais aller." Il avait passé 7 ans dans l'organisation sans qu'un seul entretien annuel aborde réellement ses aspirations de carrière.
Je n'ai pas refait la même erreur.
Selon une étude LinkedIn de 2023, 62% des développeurs citent l'absence de perspectives de carrière comme principale raison de chercher un nouveau poste. Pas la rémunération. Les perspectives. Et les perspectives, c'est précisément ce que l'entretien annuel bien conduit est censé créer. Dans un marché du talent technique où le coût de remplacement d'un développeur senior atteint 65 000 à 130 000€, l'entretien annuel n'est pas une formalité RH. C'est un investissement de rétention.
Ce que l'entretien annuel n'est pas
Avant de décrire le format, je veux être clair sur ce que cet entretien ne doit pas être.
Ce n'est pas un bilan de performance descendant où le manager évalue et le développeur écoute. Ce n'est pas une liste de cases cochées sur les objectifs fixés un an plus tôt. Et surtout, je l'ai appris à mes dépens, ce n'est pas la même réunion que la révision salariale.
Camille Fournier le décrit précisément dans The Manager's Path : l'entretien annuel doit être un espace de développement, pas d'évaluation. L'évaluation crée de la défensivité. Le développement crée de l'engagement.
La préparation : ce qui se passe avant le jour J
Dix jours avant l'entretien, j'envoie au développeur un questionnaire de préparation de 5 questions. L'entretien ne commence pas le jour J : il commence quand le développeur a eu le temps de réfléchir.
Le questionnaire :
- "Quelles ont été tes 2-3 contributions les plus significatives cette année ? Pas les plus visibles, les plus impactantes selon toi."
- "Qu'as-tu appris cette année qui a changé ta façon de travailler ?"
- "Sur une échelle de 1 à 10, où te sens-tu par rapport à ton potentiel actuel ? Qu'est-ce qui t'empêche d'être à 10 ?"
- "Dans quelles directions voudrais-tu évoluer dans les 12 à 24 prochains mois ?"
- "Y a-t-il des sujets que tu veux aborder et que tu n'as pas pu aborder en 1-on-1 ?"
Je lis les réponses avant l'entretien et je prépare mes propres réflexions sur ces mêmes questions, en particulier les questions 3 et 4 du point de vue de l'équipe et de l'organisation.
La structure en 4 blocs (90 minutes)
Bloc 1 : Rétrospective (25 min)
Le développeur présente ses réponses aux questions 1 et 2. J'écoute d'abord, vraiment, sans interrompre. Puis j'ajoute ma perspective sur les contributions de l'année, en commençant par ce que le développeur n'a pas cité mais qui a eu de l'impact.
Ce que je ne fais pas dans ce bloc : transformer la rétrospective en évaluation notée. L'objectif est de reconnaître la contribution et de construire une perspective partagée sur l'année. La reconnaissance explicite est souvent absente dans les environnements techniques, et son absence est la principale cause du syndrome de l'imposteur chez des développeurs compétents.
Bloc 2 : Diagnostic honnête (20 min)
La question 3 est la plus difficile et la plus importante. Elle ouvre l'espace pour parler de ce qui bloque, de ce qui frustre, et de ce qui manque.
J'écoute sans défendre. Si le développeur exprime une frustration sur le management (délégation insuffisante, visibilité insuffisante, manque de reconnaissance), c'est de l'information précieuse, pas une attaque personnelle. Ce qui sort de ce bloc : une liste de 2 à 3 conditions manquantes pour que le développeur soit à 9 ou 10 sur 10. Ces conditions deviennent les engagements de l'organisation pour l'année suivante.
Vos entretiens annuels ne changent rien et vos meilleurs développeurs cherchent ailleurs ?
L'entretien annuel inefficace est souvent le symptôme d'un problème plus profond : absence de parcours de carrière structuré, 1-on-1 inexistants, ou culture qui ne valorise pas le développement individuel. En 30 minutes, je peux identifier la vraie cause dans votre organisation et définir le plan d'action concret pour retenir vos profils clés.
Bloc 3 : Plan de développement (30 min)
La question 4 du questionnaire. Discussion ouverte sur les ambitions à 12 à 24 mois.
Les 4 directions de carrière légitimes pour un développeur :
- Expert technique : approfondissement d'une compétence (architecture, sécurité, data, IA), jusqu'au niveau staff engineer ou principal engineer
- Lead technique : coordination, mentorat, design technique
- Management : équipe puis organisation
- Autre : product, data, autre domaine métier
Pour chaque direction souhaitée, je définis avec le développeur :
- Quelle est la prochaine étape concrète, pas "devenir architecte" mais "contribuer à la conception du prochain système en pair avec le head of architecture"
- Quelles compétences sont à développer dans les 6 prochains mois
- Quelles ressources l'organisation va allouer (formation, budget, temps dédié, mentorat)
Ce que j'ai appris de The Manager's Path de Camille Fournier : si votre organisation n'a que "développeur → manager" comme seul chemin de progression, c'est un problème structurel. Les meilleurs experts techniques partent précisément parce qu'ils ne veulent pas gérer des équipes, et qu'on ne leur laisse pas d'autre option pour progresser.
Bloc 4 : Le contrat (15 min)
Les engagements réciproques pour les 12 prochains mois.
Le développeur s'engage sur : les compétences à développer, les comportements à faire évoluer, la visibilité à gagner.
Je m'engage sur : les opportunités à créer (projets, formations, mentorat), les obstacles à lever, les conditions à améliorer identifiées en Bloc 2.
Ma règle absolue : ne promettre que ce qu'on peut tenir. Un engagement non-tenu détruit plus de confiance que de ne rien promettre. Si une promotion n'est pas possible dans les 12 mois, je le dis clairement plutôt que de laisser l'espoir flotter. J'ai vu trop de développeurs partir en mauvais termes après des promesses implicites qui ne se sont pas concrétisées.
Le suivi à 90 jours : le seul indicateur qui compte
L'entretien annuel n'a de valeur que si ses engagements sont suivis. À J+90, un 1-on-1 dédié de 30 minutes :
- Quelles actions ont été entreprises ?
- Quels progrès sont visibles ?
- Quels obstacles sont apparus ?
- Les engagements que j'ai pris ont-ils été tenus ?
Ce suivi à 90 jours envoie un signal fort : l'entretien annuel n'est pas une formalité RH, c'est un engagement réel.
En résumé
| Bloc | Durée | Contenu | Résultat |
|---|---|---|---|
| Préparation | 10 jours avant | Questionnaire 5 questions | Réflexion ancrée |
| Rétrospective | 25 min | Contributions + apprentissages | Reconnaissance partagée |
| Diagnostic | 20 min | Ce qui bloque + frustrations | Conditions à améliorer |
| Plan développement | 30 min | Ambitions + plan 12 mois | Feuille de route carrière |
| Contrat | 15 min | Engagements réciproques | Commitment clair |
| Suivi | J+90 | Bilan des actions | Continuité de la dynamique |
FAQ sur l'entretien annuel des développeurs
L'entretien annuel peut-il remplacer les 1-on-1 réguliers ?
Non, c'est l'inverse : les 1-on-1 réguliers sont le prérequis de l'entretien annuel. Un entretien annuel sans 1-on-1 réguliers pendant l'année est une conversation avec un quasi-inconnu. Les problèmes non-dits se sont accumulés, les tensions sont latentes, et 90 minutes ne suffisent pas à traiter 12 mois de sujets non-abordés. Les 1-on-1 mensuels rendent l'annuel plus riche et moins stressant pour les deux parties. Ces rituels de confiance sont le substrat de tout développement individuel efficace.
Comment conduire un entretien annuel avec un développeur qui ne veut pas évoluer vers le management ?
La progression de carrière ne passe pas nécessairement par le management. Un excellent développeur senior qui veut rester dans l'excellence technique a un parcours légitime : senior engineer → staff engineer → principal engineer. Ces titres reconnaissent la valeur croissante d'un expert technique sans le forcer vers un rôle qu'il ne veut pas. Si votre organisation n'a que "développeur → manager" comme chemin de progression, c'est un problème structurel à corriger, pas un problème du développeur.
Que faire si un développeur exprime des ambitions que l'organisation ne peut pas satisfaire ?
Être honnête. "Tu veux devenir Head of Architecture dans 24 mois : c'est une ambition légitime. Dans notre organisation, ce poste n'est pas disponible dans ce délai. Voilà ce qui est possible : alternatives réalistes. Et voilà les opportunités externes que je peux t'aider à explorer si notre trajectoire ne correspond pas." Un développeur qui part avec honnêteté part bien. Un développeur qui part après des promesses non-tenues part en ennemi potentiel.
L'entretien annuel est-il différent pour les juniors vs les seniors ?
Le format est le même, l'emphase diffère. Pour les juniors : plus de temps sur le Bloc 2 (diagnostic des blocages dans la montée en compétence) et le Bloc 3 (plan de développement très concret, avec des jalons trimestriels). Pour les seniors : plus de temps sur le Bloc 1 (reconnaissance de l'impact stratégique) et les ambitions à 24 à 36 mois plutôt que 12. Ces ambitions se concrétisent par une délégation progressive adaptée au niveau de séniorité.
Faut-il combiner l'entretien annuel avec la révision salariale ?
Jamais. Les deux sujets s'inhibent mutuellement. Si la discussion salariale arrive en premier, le développeur filtre le reste de la conversation en fonction de l'impact sur sa rémunération. Si elle arrive en dernier, il a passé 90 minutes à attendre cette partie. Je tiens systématiquement deux réunions séparées, à une semaine d'intervalle minimum. L'entretien de développement d'abord. La révision salariale ensuite.
Ressource gratuite : Engineering Maturity Self-Assessment
L'Engineering Maturity Self-Assessment couvre le domaine People & Rétention : évaluez la maturité de vos pratiques de management individuel, de développement de carrière, et de rétention. Score et recommandations concrètes en 10 minutes.
