À la chasse aux fantômes : comment voir la contribution réelle des développeurs

Les « ghost engineers », ou développeurs fantômes : un développeur sur dix ne produit pratiquement aucun travail utile et se contente de donner, de façon convaincante, l’impression d’être débordé. Les véritables raisons de cette inactivité — travail en parallèle, épuisement professionnel ou simple paresse — peuvent rester très longtemps invisibles aux yeux de la direction. (Étude de Stanford de 2024 : fil d’origine)

Les développeurs n’aiment pas que l’on parle de leur performance. Après un long « âge d’or » pour la profession, le secteur a fini par rendre taboue une question pourtant simple : les résultats de l’ingénierie justifient-ils le temps et l’argent qui y sont investis ? Mais les développeurs fantômes exaspèrent aussi leurs collègues — et, en général, c’est l’équipe, pas la direction, qui remarque le problème en premier.

Chez nous, en Russie, « dénoncer » quelqu’un est depuis toujours très mal vu. Beaucoup peuvent donc savoir qu’il y a un problème sans que personne veuille en parler. Pourquoi se mêler des histoires des autres ? Tout finit par éclater seulement lorsque la patience de chacun est déjà épuisée.

Mais peut-être devrions-nous les laisser tranquilles, ces fantômes. Après tout, ce n’est pas comme si l’entreprise avait besoin de cet argent.

Sauf qu’il y a un hic…

Quand je parle de faible performance, je ne veux pas dire qu’Alex travaille d’arrache-pied et accomplit malgré tout 10 % de moins que Ben. Je parle d’autre chose : à chaque daily, toute l’équipe doit écouter le nouveau récit larmoyant du jour — l’autre équipe l’a laissé tomber, le ticket manquait de clarté, les planètes n’étaient pas alignées. Mais demain, la tâche sera terminée, c’est promis. Croix de bois, croix de fer.

Seulement voilà : ce « demain » était déjà hier, et avant-hier — et c’est désormais devenu une tradition.

Les équipes repèrent vite ce genre de situation. Ceux qui portent réellement le travail finissent naturellement par se demander : pourquoi se tuer à la tâche s’il suffit de raconter des histoires sans jamais en subir les conséquences ?

Mais remarquer le problème ne suffit pas. Sans chiffres ni faits à l’appui, la conversation tourne vite à la dispute : l’équipe affirme « il n’est pas à la hauteur » ; le développeur répond « on m’empêche de travailler ». Le plus souvent, personne ne commence à enquêter avant que la patience soit à bout et que l’équipe demande au responsable de remplacer le développeur.

C’est alors que commence une longue saga : réunir les faits, écouter les deux parties, faire un retour à l’intéressé et lui laisser le temps d’améliorer la situation. D’après mon expérience, cela se termine le plus souvent par le départ du fantôme vers un nouvel employeur — qui a vraiment beaucoup de chance.

Le problème n’est pas seulement qu’une personne en fait moins. L’entreprise paie deux fois : d’abord pour un travail qui n’est jamais réalisé, puis pour le temps que collègues et responsables passent à tout revérifier, à combler les vides et à chercher à comprendre pourquoi. Au bout du compte, ce n’est plus un seul développeur qui sous-performe. C’est toute l’équipe.

Un responsable peut-il repérer le problème plus tôt — voir l’anomalie, demander du contexte et enquêter avant que l’équipe perde patience et que l’entreprise perde du temps et de l’argent ?

Avec suffisamment d’expérience, on peut souvent reconnaître ces situations à l’avance grâce à quelques comportements caractéristiques :

• Tous les succès sont à mon crédit ; tous les échecs sont de ta faute.
• Des excuses pour l’échec d’une tâche avant même que le travail ait commencé.
• Un manque de compétence compensé par un excès de paroles.
• Avec le temps, le responsable en particulier est désigné comme le « coupable ».
• Contrairement à quelqu’un qui rencontre de réelles difficultés, ce comportement ne s’améliore pas, même après un retour direct.

Mais les soupçons ont besoin de traces numériques.

Passons en revue les outils les plus courants pour mesurer la performance en ingénierie et voyons s’ils peuvent nous aider à débusquer les fantômes.

Avant de les comparer, je dois signaler l’évident conflit d’intérêts : vous lisez le blog officiel de DevGhost, et je suis le fondateur du produit. Il s’agit du point de vue d’un auteur, pas d’une étude indépendante.

Pour évaluer l’ingénierie logicielle elle-même — pas l’entreprise ou le produit dans son ensemble —, j’utilise une triade simple : vitesse, qualité et volume. Les métriques DORA nous renseignent sur la vitesse ; les tests et les défauts, sur la qualité. Le volume est plus difficile à saisir. C’est le terrain le moins balisé — et celui où se cachent généralement les fantômes que nous recherchons.

DORA : vitesse et fiabilité des mises en production

DORA montre avec quelle rapidité et quelle fiabilité une équipe met ses changements en production. Le modèle s’appuie sur cinq métriques : le délai entre le commit et la production, la fréquence de déploiement, le pourcentage de déploiements qui provoquent des échecs, le temps de rétablissement et la part de reprises imprévues.

C’est une bonne mesure du processus de livraison, mais pas de la contribution individuelle. Si une personne fait le travail de trois pendant qu’une autre se cache derrière le résultat global de l’équipe, DORA ne vous le dira pas.

Ces métriques font aussi des KPI merveilleusement commodes. Dans une entreprise où j’ai travaillé, nous les pressions comme des citrons depuis 2018 — tous les tableaux de bord finissaient soigneusement en vert et tout le monde était content. Le modèle DORA actuel.

Tests et défauts : le travail a-t-il été bien fait ?

Les méthodes sont bien établies et ont fait leurs preuves. La qualité est contrôlée par la revue de code, les tests et l’analyse statique ; les conséquences sont suivies au moyen des défauts et des incidents.

Mais ces signaux ne disent rien du volume. Un minuscule correctif irréprochable fera passer tous les indicateurs au vert — et le fantôme restera invisible.

Jira et story points : combien de tickets ont été clôturés ?

Jira affiche les tickets clôturés et les story points, mais les estimations viennent de l’équipe elle-même. Le même travail peut être estimé à trois points ou à treize, découpé en cinq tickets ou regroupé dans un seul.

Les story points sont utiles pour planifier, mais peu fiables pour mesurer la contribution individuelle. Dès que les points deviennent l’objectif, les gens se mettent à optimiser les points.

Eux aussi font des KPI bien pratiques. On saisit des données et on déplace des tickets uniquement pour franchir les contrôles qualité. Beaucoup de travail manuel parfaitement inutile.

Commits et lignes de code : des faits sans contexte

Git ne dépend pas des estimations de l’équipe, il est donc tentant de compter les commits et les lignes. Mais cinq commits peuvent représenter un minuscule correctif, tandis qu’un seul squash commit peut correspondre à une semaine de travail.

Le formatage, le code généré, la copie et le déplacement de code gonflent le nombre de lignes, alors qu’une correction difficile peut ne tenir qu’en dix lignes.

Swarmia, LinearB et Waydev : tout le système d’ingénierie au même endroit

Swarmia, LinearB et Waydev réunissent Git, les outils de suivi des tâches et la CI/CD. Les responsables peuvent voir les métriques DORA, les files d’attente de revue, les délais de livraison des changements et les résultats d’enquêtes.

Ces plateformes donnent une vue utile du système d’ingénierie — et montrent souvent que le problème vient du processus plutôt que d’une personne. Mais mesurer le volume de travail d’un développeur sur une échelle comparable n’est pas la question centrale à laquelle elles cherchent à répondre. Swarmia, LinearB, Waydev.

GitClear : ce qui reste une fois le bruit du code éliminé

GitClear distingue le code ajouté, déplacé et copié, exclut les fichiers générés et tient compte du fait que le nouveau code a ensuite été réécrit ou supprimé.

Il en résulte Diff Delta, l’unité propre à GitClear pour les changements significatifs qui restent dans la base de code. Le code copié ou rapidement abandonné pèse moins qu’un changement compact qui continue de fonctionner en production. Le fonctionnement de Diff Delta.

Diff Delta ne répond pas à la question du travail nécessaire. Il indique la quantité de changement significatif qui subsiste après le bruit et les reprises. GitClear excelle dans la mesure de la pérennité et de la qualité du code, ainsi que dans l’analyse de l’impact de l’IA.

Nous nous rapprochons. Le service publie des benchmarks, mais Diff Delta reste une unité qui lui est propre : un chiffre comme 10 000 ne signifie pas grand-chose sans le bon point de comparaison et sans comprendre la méthode. Il n’existe pas de repère clair du type « 100 % correspond à la norme ». Benchmarks Diff Delta.

BlueOptima : la même question à l’échelle de l’entreprise

Je connais BlueOptima de première main. J’ai commencé à travailler avec la plateforme en 2019. C’est cette expérience qui m’a donné envie de créer mon propre produit.

L’algorithme Coding Effort analyse chaque modification du code source à l’aide d’un ensemble de métriques statiques, en tenant compte de sa taille, de sa complexité et de sa relation avec le reste du code. Il exprime ensuite le résultat en heures.

Cela permet de comparer des développeurs appartenant à différentes équipes et travaillant avec différentes technologies, y compris par rapport à un benchmark mondial. À mes yeux, c’était la première tentative convaincante de répondre non pas à la question « Combien de lignes ce développeur a-t-il écrites ? », mais à la question « Quelle quantité de travail substantiel ces changements représentent-ils ? » Méthodologie de BlueOptima, benchmark mondial.

Dans mon cas, l’accès à ces fonctions destinées aux grandes entreprises a exigé un déploiement assez lourd : il a fallu installer un agent dans un environnement réseau fermé, le prix était élevé et les résultats nécessitaient l’interprétation d’un expert.

Pour une entreprise qui compte des milliers de développeurs, cela peut se justifier. Pour une startup ou une petite équipe, probablement pas. C’est notamment pour combler cet écart que DevGhost a vu le jour.

Le même étalon, sans appel d’offres

Lorsque j’ai créé DevGhost, je ne cherchais pas à construire une énième plateforme tout-en-un remplie de toutes les métriques d’ingénierie imaginables.

Je voulais obtenir la même réponse que BlueOptima — quelle quantité de travail substantiel se cache derrière les changements —, mais sous une forme qu’un fondateur de startup ou une petite équipe pourrait utiliser sans appel d’offres, sans long déploiement et sans armée de consultants.

La logique est simple : DevGhost analyse les changements eux-mêmes — ce qui a été ajouté, supprimé et restructuré, ainsi que la difficulté de créer et de vérifier le résultat. Le formatage, les déplacements de code, les remplacements automatiques massifs et le code généré sont séparés du travail substantiel.

Le résultat est une estimation de l’effort exprimée en heures équivalentes : le temps qu’il faudrait à un développeur de niveau intermédiaire, connaissant la base de code et travaillant sans IA, pour écrire le même code. Ce n’est ni le temps réellement passé au clavier, ni une évaluation de la qualité ou de la valeur commerciale du code. C’est un étalon commun pour comparer les changements. En savoir plus sur la méthodologie de DevGhost.

Ghost% compare cette estimation au volume de travail attendu d’un développeur de niveau intermédiaire, en tenant compte de la part de son temps réellement consacrée au développement. Un résultat de 100 % signifie qu’il se situe dans la norme. Un résultat inférieur invite à enquêter ; un résultat supérieur mérite d’être étudié et peut-être transformé en bonne pratique.

Le benchmark suppose délibérément un travail sans IA. DevGhost ne cherche pas à déterminer qui a écrit tel ou tel fragment de code — une personne, Copilot ou un agent autonome. Il évalue les changements finaux : quel effort un développeur de niveau intermédiaire aurait-il dû fournir pour les créer et les vérifier sans IA ?

L’effet de l’IA ne disparaît donc pas à l’intérieur de la métrique. Il devient visible. Si, pendant une période donnée, un développeur crée et vérifie un travail qui aurait auparavant demandé deux ou trois fois plus d’effort, Ghost% le reflète. Le formatage, la génération massive et les autres formes de bruit dans le code ne devraient pas produire le même effet.

Qui juge le juge ?

La question la plus évidente est la suivante : pourquoi faire confiance à une estimation produite par une machine ? La réponse courte : personne ne devrait lui faire aveuglément confiance.

Évaluer la difficulté d’un travail est subjectif par définition. Nous l’avons vérifié en demandant à plusieurs développeurs expérimentés d’estimer les mêmes changements — et avons obtenu des chiffres sensiblement différents. Chacun a son propre rythme, sa propre expérience et sa propre perception de la difficulté.

DevGhost peut aussi se tromper. Son avantage n’est pas d’avoir accès à une quelconque vérité absolue. Il tient au fait que chaque changement est évalué selon le même étalon — sans favoritisme, sans fatigue et sans opinion préconçue sur son auteur.

C’est pourquoi Ghost% est un signal, pas un verdict. Un résultat faible peut indiquer une contribution insuffisante, mais il peut aussi s’expliquer par des responsabilités de lead technique, du travail d’architecture, du mentorat, des incidents ou des blocages.

Le chiffre indique où poser une question. Le responsable doit toujours trouver la réponse lui-même — mais il dispose désormais d’un deuxième avis indépendant, plutôt que de sa seule intuition.

« Je sais déjà comment travaille chacun dans mon équipe »

L’un des clients de DevGhost dirige l’ingénierie d’une entreprise d’IA en pleine croissance. Au départ, il était sceptique quant à l’idée même de mesurer la performance en ingénierie. Sa position était simple : un bon responsable technique sait déjà comment travaille chacun, sans avoir besoin d’un tableau de bord.

Nous avons analysé l’historique d’un dépôt qu’il connaissait bien. Trois développeurs suscitaient déjà des inquiétudes : leurs tickets avançaient lentement, mais ils travaillaient sur un service distinct, ce qui rendait la comparaison avec le reste de l’équipe difficile. DevGhost a affiché des résultats constamment faibles pour tous les trois pendant environ six mois.

Plus tard, lorsque les développeurs ont commencé à partir, il est apparu que, pendant toute cette période, ils développaient aussi leurs propres produits. DevGhost ne pouvait pas en connaître la raison. Il a simplement fait ressortir ce que le nombre de commits, les pull requests et les conversations quotidiennes sur Slack n’avaient pas révélé : leur volume de travail était nettement inférieur aux attentes.

Mais l’analyse ne s’est pas transformée en liste de licenciements. Pour deux autres développeurs, un résultat faible a permis de donner un retour précis, d’en étudier les causes et d’améliorer les performances. Tous deux sont restés dans l’équipe.

Les développeurs qu’il considérait comme solides se sont également retrouvés exactement là où il s’y attendait. Et il pouvait désormais voir non seulement qui dépassait les attentes, mais aussi avec quelle régularité.

Un cas isolé, bien entendu, ne prouve pas la précision de la méthode. Ce qui a surpris le client, c’est à quel point la vue d’ensemble correspondait à ce qui, auparavant, n’était connu qu’intuitivement — et, dans certains cas, n’était devenu évident qu’avec le recul.

Et si un développeur produisait autant que trois personnes ?

La chasse aux fantômes est la partie la plus accrocheuse de cette histoire. Mais le haut du graphique peut s’avérer encore plus utile.

Si un développeur produit régulièrement plusieurs fois la moyenne, cela vaut la peine de comprendre précisément comment il y parvient.

Aujourd’hui, la question n’est plus de savoir si un développeur utilise l’IA — pour beaucoup, elle fait désormais partie du quotidien. La question est de savoir avec quelle efficacité il transforme les agents en capacité de livraison supplémentaire.

L’un s’arrête à l’autocomplétion. L’autre sait fournir aux agents le bon contexte, définir des règles claires, mener plusieurs tâches en parallèle et vérifier soigneusement le résultat. Le même accès à l’IA peut donc entraîner des gains de productivité radicalement différents.

Un Ghost% élevé aide à repérer les développeurs qui obtiennent déjà de solides résultats grâce à cette association entre humain et agent — et à comprendre quelles pratiques le reste de l’équipe pourrait adopter.

Si ce résultat élevé est confirmé par la qualité du travail et l’évaluation du responsable, ce développeur mérite d’être valorisé, fidélisé et envisagé pour une promotion. Ses pratiques doivent être étudiées et diffusées dans l’équipe.

Ne transformez pas l’étalon en arme

Toutes les métriques connaissent le même sort : tôt ou tard, quelqu’un essaie d’en faire un KPI. Ghost% ne s’y prête pas.

Faites de Ghost% un KPI d’équipe, et les gens commenceront à organiser leur travail autour de la métrique. Publiez un classement, et la confiance disparaîtra. Transformez le score en bouton de licenciement, et les erreurs deviendront inévitables.

J’établirais quatre règles :

• Ne tirez pas de conclusion à partir d’une seule mesure ou d’une courte période.
• Tenez compte du rôle de la personne, de la part de son temps consacrée au développement et du travail réalisé en dehors du code.
• Montrez le résultat au développeur et donnez-lui la possibilité d’expliquer le contexte.
• N’utilisez pas Ghost% comme seul fondement d’une décision RH.

Si un résultat faible persiste, le responsable doit d’abord en rechercher les causes. Peut-être la personne éprouve-t-elle réellement des difficultés à être performante. Ou peut-être travaille-t-elle sur l’architecture, gère-t-elle les incidents des autres ou se trouve-t-elle bloquée par les processus de l’équipe.

Si le problème est confirmé, il faut établir un plan d’amélioration précis et procéder à une nouvelle évaluation après une période convenue.

Rejeter les métriques ne supprime pas l’évaluation des personnes. Cela ne laisse que l’intuition, les histoires racontées pendant les daily meetings et les préférences personnelles du responsable.

Vitesse, qualité et volume exigent des outils différents. DORA montre comment les changements arrivent en production. Les tests et les défauts montrent la qualité. DevGhost ajoute une estimation du travail qui se cache derrière les changements de code.

Aucune de ces métriques ne devrait prendre de décision à la place du responsable.

La valeur d’un chiffre ne vient pas de ce qu’il prononce un verdict. Elle vient du fait qu’une conversation difficile commence plus tôt — et qu’elle s’appuie sur des faits.

Comment évaluez-vous le volume de travail des développeurs, et où placez-vous la frontière entre transparence utile et surveillance ?