Comment gérer un développeur en difficulté
Comment gérer un développeur en difficulté
Chez BNP Paribas, j'avais un développeur (5 ans d'expérience, reconnu dans l'équipe) qui s'était progressivement effacé. Moins de participation en réunion. Stories qui s'étiraient. Code review de moins en moins actif. Pendant 6 semaines, j'ai rationalisé : période chargée, contexte difficile, ça va passer. Ça n'a pas passé. Il est parti 3 mois plus tard. En post-mortem, j'ai compris que sa difficulté avait une cause simple : on l'avait repositionné sur une technologie qu'il ne maîtrisait pas, sans formation, sans filet. Six semaines d'inconfort muet, et personne n'avait ouvert la porte.
C'est l'erreur la plus courante que j'observe chez les managers engineering. Attendre. Espérer que ça se résout seul. Parfois ça se résout : le développeur trouve ses marques, le problème contextuel disparaît. Mais dans la majorité des cas, l'absence d'intervention transforme un problème traitable en départ. Et remplacer un développeur senior coûte entre 65 000 et 130 000€ en recrutement, onboarding, et perte de productivité sur 6 à 12 mois.
Ce n'était jamais un problème de personnes. C'était un problème de système : un système qui ne détectait pas les signaux et n'avait pas de protocole d'intervention.
Les signaux précoces : observer avant d'intervenir
Avant toute conversation, j'observe sur 2 à 4 semaines minimum. Une mauvaise semaine n'est pas un pattern. Un pattern, c'est un signal qui persiste.
Signaux techniques à surveiller :
- Baisse de la qualité du code (plus de bugs sur ses stories, code reviews avec plus de commentaires correctifs)
- Stories qui s'étirent au-delà de leur estimation habituelle
- PR créées plus tard dans le sprint, ou abandonnées sans merge
- Diminution de la participation aux revues de code
Signaux comportementaux à surveiller :
- Moins de participation aux réunions (questions posées, idées proposées)
- Isolement progressif (moins de communication spontanée dans Slack, moins de conversations informelles)
- Retards ou absences qui n'avaient pas de précédent
- Changement de ton dans les échanges écrits
Ma règle des 2 semaines : si un signal persiste sur 2 semaines, c'est un pattern. Si 2 signaux ou plus apparaissent simultanément, j'interviens immédiatement. Je n'attends pas.
Le diagnostic : identifier la catégorie avant de parler
Avant la conversation, je me force à avoir une hypothèse sur la cause. Les 4 catégories de difficultés ont des interventions radicalement différentes : parler sans hypothèse, c'est risquer de traiter le mauvais problème.
Catégorie 1 : Difficulté contextuelle : le projet, la technologie, ou l'environnement a changé. Le développeur n'a pas les outils, l'information, ou le support nécessaire pour s'adapter. C'était le cas dans l'histoire que j'ai décrite plus haut.
Catégorie 2 : Difficulté de compétences : la story ou le projet requiert des compétences que le développeur n'a pas encore, et aucune aide n'a été proposée pour combler le gap. Fréquent dans les équipes qui montent en gamme technologiquement sans investir dans la formation.
Catégorie 3 : Difficulté de motivation : le développeur a perdu le sens de son travail. Le projet ne l'engage plus, les perspectives de carrière sont floues, ou les ambitions ne correspondent plus au rôle. Souvent une conséquence non-adressée des catégories 1 ou 2.
Catégorie 4 : Difficulté personnelle : un problème extérieur au travail (santé, famille, finances) impacte la performance. C'est la catégorie la plus délicate : elle nécessite de la sensibilité et une attention à ne pas franchir les frontières de la vie privée.
Un de vos développeurs semble en difficulté et vous ne savez pas comment aborder le sujet sans aggraver la situation ?
Vous avez peut-être les signaux mais pas la méthode pour ouvrir la conversation sans créer de la défensivité. En 30 minutes, je peux vous aider à préparer la conversation, anticiper les réactions possibles, et définir le plan d'action adapté à la catégorie de difficulté que vous observez.
La conversation honnête : ni accusation ni déni
L'ouverture que j'utilise : je commence par l'observation factuelle, jamais par le jugement.
Ce que je ne dis pas : "Ta performance a beaucoup baissé ces dernières semaines."
Ce que je dis : "J'ai observé que tes stories prennent plus de temps que d'habitude ces 3 dernières semaines, par exemple exemples spécifiques. Et tu sembles moins participer aux réunions d'équipe. Je voulais prendre le temps de discuter avec toi pour comprendre ce qui se passe."
Après l'ouverture, je me tais. La plupart des développeurs en difficulté savent que quelque chose ne va pas : ils attendent souvent qu'on leur ouvre la porte.
Questions qui fonctionnent :
- "Comment tu vis cette période ?"
- "Qu'est-ce qui serait différent si les choses allaient mieux ?"
- "Y a-t-il des obstacles que tu rencontres sur lesquels je pourrais t'aider ?"
Ce que je ne fais absolument pas :
- Minimiser ("tout le monde passe par des périodes difficiles")
- Proposer des solutions avant d'avoir compris le problème
- Menacer, même implicitement, de conséquences pendant cette première conversation
Résultat attendu : une compréhension partagée de ce qui se passe, pas nécessairement la solution, mais la cause.
Le plan de développement sur 30 jours
Selon la catégorie diagnostiquée, le plan de 30 jours est différent.
Pour la difficulté contextuelle : identifier et lever l'obstacle. Pair programming avec quelqu'un qui maîtrise la technologie, accès à la documentation manquante, clarification des attentes.
Pour la difficulté de compétences : définir un plan de formation ciblé. 1 à 2 semaines de formation dédiée, stories de montée en compétence progressive, mentorat d'un senior.
Pour la difficulté de motivation : ouvrir la discussion sur les aspirations. Y a-t-il une direction différente à explorer ? Un projet plus stimulant dans l'organisation ? Une évolution de rôle possible ? Si ce n'est pas encore fait, c'est le moment d'anticiper l'entretien annuel plutôt que d'attendre la date prévue.
Pour la difficulté personnelle : proposer un support adapté. Flexibilité des horaires, réduction temporaire de la charge, accès à l'assistance psychologique si disponible. Sans chercher à connaître les détails personnels : je propose le cadre, pas l'intrusion.
Le plan contient systématiquement : 2 à 3 actions concrètes sur 30 jours, une métrique de succès visible, et une date de point d'étape à 15 jours. Je l'écris et je le partage avec le développeur, pas dans un email formel, mais dans le compte-rendu du 1-on-1.
Le suivi hebdomadaire et le seuil de décision
Suivi hebdomadaire en 1-on-1 court de 15 minutes pendant 4 semaines. Mes trois questions :
- Qu'est-ce qui a avancé cette semaine ?
- Qu'est-ce qui reste difficile ?
- L'équipe ou moi avons-nous tenu nos engagements ?
À 30 jours, évaluation honnête :
- Amélioration visible → continuer le support, réduire la fréquence des check-ins
- Plateau → approfondir le diagnostic, ajuster le plan
- Dégradation → conversation plus directe sur les conséquences possibles et les décisions à prendre
Quatre semaines d'investissement en management intensif coûtent bien moins que les 65 000 à 130 000€ d'un remplacement. Le calcul est simple. L'inaction est rarement neutre : elle est presque toujours la décision la plus coûteuse.
FAQ sur la gestion d'un développeur en difficulté
Quand faut-il impliquer les RH dans ce processus ?
Dès que la situation pourrait mener à une procédure disciplinaire ou un licenciement, les RH doivent être impliquées. En pratique, pour une difficulté de performance (catégories 1 à 3), je gère seul les 4 premières semaines. Si la situation ne s'améliore pas à J+30, ou si la difficulté personnelle (catégorie 4) dépasse mes capacités à l'accompagner, les RH entrent en copie.
Comment gérer la situation si le développeur nie avoir un problème ?
Je respecte le déni initial : c'est une réaction normale. Je reformule les faits observés sans accusation et laisse la conversation ouverte. "Je comprends que tu ne vois pas les choses de la même façon. Les faits que j'ai observés sont liste. Si tu veux qu'on en discute dans quelques jours, ma porte est ouverte." Je planifie un suivi à 1 semaine. Si le déni persiste face à des faits répétés et documentés, c'est un signal que la difficulté est plus profonde.
Quelle est la différence entre un développeur en difficulté et un développeur qui manque de motivation ?
La motivation est souvent une conséquence, pas une cause. Un développeur démotivé est généralement un développeur dans une difficulté contextuelle ou de sens non-adressée. La question que je pose : "Il y a 12 mois, était-il motivé ?" Si oui, chercher ce qui a changé. Si non depuis le début, c'est peut-être un problème de recrutement (un mauvais match entre la personne et le rôle) plutôt qu'un problème de management.
Comment gérer la situation vis-à-vis du reste de l'équipe ?
Confidentialité absolue sur le contenu des discussions. L'équipe peut percevoir une différence de traitement (moins de stories assignées, plus de check-ins). Si elle pose des questions, "nous gérons un sujet individuel" est suffisant. J'évite de couvrir les défaillances du développeur en difficulté face à l'équipe (ça génère de la frustration chez les autres) tout en évitant de l'exposer publiquement.
Que faire si les 30 jours ne suffisent pas et que la situation ne s'améliore pas ?
Ne pas confondre difficulté temporaire et inadéquation structurelle. Un développeur qui est en difficulté depuis 18 mois malgré plusieurs plans d'action peut avoir atteint son niveau de compétence maximum dans le rôle actuel : c'est ce que le Principe de Peter décrit. Dans ce cas, la solution n'est pas plus de support. C'est une discussion honnête sur un rôle mieux adapté, en interne ou en externe. Cette conversation est difficile mais elle est plus respectueuse que de laisser la situation se dégrader indéfiniment.
Ressource gratuite : Engineering Maturity Self-Assessment
L'Engineering Maturity Self-Assessment couvre le domaine People & Culture : évaluez la maturité de vos pratiques de détection et d'accompagnement des personnes en difficulté. Identifiez les leviers d'action avant que les signaux faibles ne deviennent des départs.
