Comment DevGhost évalue la productivité des développeurs

Mis à jour 23 octobre 2026

DevGhost évalue de manière indépendante la productivité de chaque développeur à partir du contenu et de la complexité cognitive de ses modifications Git. Les chefs d’entreprise et les CTO peuvent voir le rendement de leur investissement dans le développement : repérer des contributions durablement faibles et reconnaître les développeurs solides dont le travail est passé inaperçu.

La taille d’une modification ne correspond pas à la quantité de travail

L’ajout d’une bibliothèque prête à l’emploi peut prendre quelques minutes et produire des milliers de lignes ajoutées. Pourtant, une petite modification de comportement dans quelques fichiers peut nécessiter de comprendre les dépendances, de concevoir une solution et de la vérifier avec soin. DevGhost estime le travail d’ingénierie qui sous-tend une modification, afin que l’activité visible ne se substitue pas à la contribution.

Un apprentissage automatique ancré dans le code

DevGhost combine l’apprentissage automatique et son propre réseau neuronal avec l’analyse structurelle des modifications Git et des algorithmes spécialisés. Ensemble, ils estiment l’effort cognitif sur une échelle commune de développeur de référence.

DevGhost n’utilise pas de LLM pour analyser le code. Ses propres modèles entraînés et ses algorithmes calculent l’estimation.

  • Les modifications sont considérées dans le contexte du code existant, notamment les relations entre les parties modifiées et les indices de réutilisation.
  • Les modifications mécaniques reconnues et les artefacts générés sont traités séparément, afin que leur volume ne soit pas assimilé à un nouveau travail d’ingénierie.
  • Le code substantiel produit avec l’aide de l’IA est évalué sur la même échelle. Ce qui compte, c’est le résultat représenté dans le code.

Deux modifications, deux travaux différents

Ces commits publics montrent pourquoi la taille d’un diff ne suffit pas à elle seule pour évaluer la contribution.

k6 : fichiers React prêts à l’emploi pour les tests

La modification ajoute plus de 33 000 lignes, principalement des fichiers React prêts à l’emploi, afin que les tests ne dépendent plus d’un accès réseau peu fiable. DevGhost distingue les fichiers fournis du travail nécessaire à leur intégration. Estimation de DevGhost : environ 0,8 heure de référence.

Voir le commit public

Redis : E/S asynchrones

Environ 2 300 lignes ajoutées et supprimées modifient la manière dont les threads Redis interagissent : traitement des événements réseau, transmission du travail entre les threads et synchronisation de l’accès aux données. Il s’agit d’une modification architecturale substantielle qui exige que plusieurs parties du système fonctionnent correctement ensemble. Estimation de DevGhost : environ 23 heures de référence.

Voir le commit public

Ce que signifient les heures de référence

La référence est un développeur de niveau intermédiaire ayant 3 à 4 ans d’expérience, qui connaît le projet et travaille sans IA. L’estimation couvre le travail dont il aurait besoin pour comprendre le code concerné, concevoir et implémenter une solution, la vérifier et apporter les corrections nécessaires. Les tests effectués par le développeur lui-même sont inclus : exécuter les tests appropriés et interpréter leurs résultats, vérifier manuellement le comportement si nécessaire et relire sa propre modification avant de terminer.

Une échelle commune permet de comparer les contributions des développeurs et d’observer leur évolution dans le temps. Les heures de référence décrivent le travail estimé représenté dans le code, et non le temps que l’auteur y a réellement consacré.

Des heures de référence au Ghost%

La répartition des estimations dans le temps repose sur des recherches empiriques et des mesures pratiques. DevGhost utilise une échelle de référence commune pour comparer les résultats. Le Ghost% indique la production par rapport à la base, en tenant compte du Share et du mode de décompte des jours sélectionné. À 100 %, la production correspond à la base ; au-dessus de 100 %, elle la dépasse. L’assistance de l’IA peut en être une raison, mais ce nombre ne suffit pas à prouver son utilisation.

Formule, Share, Spread et FTE

Tenez compte du contexte

Observez les résultats durables sur plusieurs périodes, puis examinez les modifications et les responsabilités de la personne. DevGhost ne mesure ni les heures réelles, ni la qualité du code, ni toute la valeur professionnelle d’un développeur. Le travail effectué en dehors des modifications analysées compte également. Les décisions relatives à l’emploi exigent une évaluation humaine indépendante et approfondie ; le Ghost% ne doit pas en être le fondement unique ou principal.

Vérifiez l’historique d’un projet que vous connaissez

Choisissez un dépôt et une période dont vous connaissez bien les résultats de l’équipe. Comparez l’évaluation de DevGhost à votre expérience : qui a apporté une contribution solide, où le développement est systématiquement resté en deçà des attentes et quelles tâches difficiles sont passées inaperçues dans les statistiques d’activité. Ouvrez des modifications individuelles et examinez à la fois les concordances et les écarts. Vous pourrez ainsi juger de l’utilité du système pour vos décisions de gestion à partir d’un travail que vous connaissez déjà.

Vérifiez un projet que vous connaissez