Pourquoi nous ne mesurons pas la productivité des développeurs (et ce que nous mesurons à la place)

La rébellion est là

En janvier 2024, l'autorité française de protection des données a infligé une amende de 32 millions d'euros à Amazon pour surveillance « excessivement intrusive » des employés¹. L'entreprise suivait les frappes au clavier, l'activité des scanners et chaque moment d'« inactivité » dans ses entrepôts.

Amazon n'est pas seul. Une étude récente a révélé que 50 % des travailleurs surveillés préféreraient démissionner plutôt que de subir une surveillance constante². Pendant ce temps, les « mouse jigglers » — des appareils qui simulent l'activité pour tromper les logiciels de surveillance — sont maintenant des best-sellers sur Amazon. L'ironie se passe de commentaire.

Cela ne se produit pas seulement dans les entrepôts. Cela se produit en ingénierie.

Un écosystème croissant d'outils de « productivité des développeurs » promet d'aider les responsables techniques à comprendre ce que font leurs équipes. Ils suivent les lignes de code, les commits par jour, les heures au clavier et, de plus en plus — avec l'IA — même le contenu de ce que les développeurs écrivent.

Voici la vérité inconfortable : ces outils sont de la surveillance déguisée en gestion. Et ils rendent les équipes d'ingénierie moins performantes, pas plus.

Le problème : pourquoi les métriques de productivité sont toxiques

Examinons ce que ces outils mesurent réellement :

Lignes de code

Comme le dit l'adage, mesurer la productivité en programmation par les lignes de code, c'est comme mesurer les progrès d'un avion par son poids. Bill Gates aurait dit sans détour : « Mesurer les progrès en programmation par les lignes de code, c'est comme mesurer les progrès de la construction d'avions par le poids. »

Une discussion sur Stack Overflow l'a parfaitement résumé : « Mesurer la production d'un développeur par les lignes de code, c'est comme mesurer l'efficacité d'une centrale électrique par les déchets qu'elle produit. »

Plus de lignes signifie souvent un code de moins bonne qualité. Une refonte qui réduit 500 lignes à 50 est un progrès. Une automatisation qui élimine un processus manuel est un progrès. Une abstraction bien conçue qui prévient du travail futur est un progrès. Rien de tout cela n'apparaît positivement dans les métriques de lignes de code.

Commits par jour

Trivial à manipuler. Vous voulez augmenter votre nombre de commits ? Divisez un seul changement logique en quinze petits commits. Ajoutez des modifications d'espaces. Commitez votre pause déjeuner.

Plus important encore, les commits mesurent l'activité, pas l'impact. Un développeur qui passe une semaine à concevoir une architecture qui fait économiser des mois de travail à l'équipe aura moins de commits que quelqu'un qui livre frénétiquement des fonctionnalités créant de la dette technique.

Heures travaillées

Celle-ci est particulièrement insidieuse. La recherche montre systématiquement que travailler au-delà de 50 heures par semaine réduit en fait la production totale³. Les développeurs qui restent tard accomplissent moins, pas plus, parce que l'épuisement entraîne des bogues, de mauvaises décisions et du code qui nécessite une refonte.

Une étude a révélé que les développeurs travaillant des heures excessives produisaient littéralement un travail négatif — ils créaient plus de problèmes qu'ils n'en résolvaient.

Pourtant, les « heures en ligne » restent une pierre angulaire des outils de surveillance.

Le problème de Goodhart

L'économiste britannique Charles Goodhart a observé que « lorsqu'une mesure devient un objectif, elle cesse d'être une bonne mesure »⁴.

Chaque métrique mentionnée ci-dessus est triviale à manipuler :

• Vous voulez plus de commits ? Divisez les changements en fragments.
• Vous voulez plus de lignes ? Écrivez du code verbeux.
• Vous voulez plus d'heures ? Gardez votre portable ouvert.
• Vous voulez plus de PR ? Soumettez des changements plus petits et plus fréquents.

Dès que vous commencez à mesurer ces choses, vous ne mesurez plus ce que vous vouliez mesurer. Vous mesurez à quel point les gens manipulent vos métriques.

Le paradoxe de l'IA : pourquoi ça empire

Si vous pensiez que les métriques traditionnelles étaient défaillantes, l'IA est sur le point d'empirer les choses.

L'illusion de productivité

Le rapport DORA (DevOps Research and Assessment) de 2024 — l'étude annuelle la plus complète sur la performance de livraison logicielle — a révélé quelque chose de surprenant : les équipes utilisant des assistants de codage IA ont montré une diminution de 1,5 % du débit et une diminution de 7,2 % de la stabilité⁵.

Attendez, quoi ?

Une étude de 2025 par METR est allée plus loin. Ils ont constaté que les développeurs expérimentés utilisant des assistants IA étaient en fait 19 % plus lents sur des tâches réelles. Mais voici le hic : ces mêmes développeurs croyaient être 20 % plus rapides⁶.

L'IA crée un écart entre perception et réalité. Les développeurs se sentent plus productifs tout en accomplissant réellement moins.

Vitesse individuelle, ralentissement organisationnel

L'IA amplifie la productivité individuelle sur certaines tâches — générer du code standard, écrire des tests, expliquer du code. Mais cette accélération individuelle se traduit souvent par un ralentissement organisationnel.

L'analyse de données d'ingénierie a révélé que les équipes assistées par l'IA complétaient 21 % de tâches en plus, mais leurs revues de code prenaient 91 % plus de temps, et elles introduisaient 9 % de bogues en plus⁷.

Plus de production + revues plus longues + plus de bogues = livraison plus lente.

Quelle est la différence entre productivité et efficacité ?

La productivité des développeurs mesure l'activité : commits, lignes de code, heures au clavier. L'efficacité des développeurs mesure les résultats : si le travail a été livré, s'il a tenu, et s'il a aidé l'équipe. C'est là que nous divergeons de l'approche capitalisme-surveillance des métriques d'ingénierie.

« La productivité des développeurs » est un concept défaillant. Mais l'efficacité des développeurs est mesurable — si vous vous concentrez sur les résultats, pas sur l'activité.

Nos cinq principes fondamentaux guident tout ce que nous construisons :

1. Axé sur les résultats : Mesurer la valeur livrée, pas l'activité
2. Neutre vis-à-vis de l'IA : Ne pas suivre l'utilisation des outils, déduire des résultats
3. Développeur d'abord : Profils individuels privés par défaut
4. Coaching plutôt que jugement : Tendances et conseils, pas de classements
5. Anti-manipulation : Notation multidimensionnelle résistante à la manipulation

Ce que cela signifie en pratique

Nous ne mesurons pas les commits, les lignes de code ou les heures travaillées. Nous mesurons :

• Le travail a-t-il été livré ? (Livraison)
• A-t-il circulé de manière durable ? (Flux)
• A-t-il tenu ? (Qualité)
• A-t-il aidé l'équipe ? (Collaboration)

Un développeur obtenant d'excellents résultats avec l'IA = efficace. Un développeur obtenant d'excellents résultats sans l'IA = efficace. Activité élevée + résultats faibles = préoccupation, quels que soient les outils.

Les 6 dimensions de l'efficacité

Nous mesurons l'efficacité selon six dimensions. Chaque dimension comporte plusieurs composantes qui créent intentionnellement une tension entre elles.

Chaque dimension raconte une partie de l'histoire. La magie réside dans la façon dont elles interagissent.

La conception anti-manipulation (La sauce secrète)

Voici ce qui rend ce système différent : optimiser une seule dimension nuit généralement à au moins une autre.

Le point idéal de la taille de lot

Prenons la taille des PR. Nous ne récompensons pas « plus de PR » ou « de plus grandes PR ». Nous récompensons la taille optimale :

• 100-400 lignes : Optimal. Score de 100.
• Moins de 50 lignes : Sur-fragmenté. Le score diminue.
• Plus de 800 lignes : Trop grand pour une révision efficace. Le score diminue.

Vous ne pouvez pas manipuler cela en rendant les PR plus petites OU plus grandes. Il existe une plage optimale, et les écarts dans l'une ou l'autre direction vous pénalisent.

Ratio de correction de bogues

De même pour la qualité, nous ne pénalisons pas seulement les bogues. Nous mesurons la contribution nette :

• Corrigé plus de bogues que vous en avez introduits : Points bonus.
• Introduit plus que vous en avez corrigés : Pénalité.

Vous ne pouvez pas manipuler cela en évitant le code (pas de bogues, mais aussi pas de corrections). Le système récompense la contribution nette positive à la qualité.

La confidentialité comme architecture, pas comme politique

De nombreux outils prétendent être « axés sur la confidentialité » tout en permettant la surveillance. Ils ajoutent une case à cocher dans les paramètres. Ils promettent que les gestionnaires ne regarderont pas les données individuelles. Ils créent des politiques.

Les politiques peuvent être modifiées. Les paramètres peuvent être basculés. Les promesses peuvent être brisées.

Notre approche est différente. La confidentialité est intégrée à l'architecture :

1. Les profils individuels sont isolés — Il n'y a pas de point de terminaison pour récupérer « tous les scores des développeurs »
2. Aucun classement n'existe — Le concept n'est pas construit
3. Les gestionnaires voient des agrégats — Tendances au niveau de l'équipe, pas de classements individuels
4. Les informations de coaching sont délimitées — Visibles uniquement par le développeur (et éventuellement, son gestionnaire direct)
5. Limitations d'exportation — Les données individuelles ne peuvent être exportées que par l'individu

Il ne s'agit pas seulement de respecter les développeurs (même si c'est le cas). Il s'agit d'obtenir des données précises. Dès que les gens savent qu'ils sont classés, la loi de Goodhart entre en jeu. Dès que la surveillance commence, les données deviennent peu fiables.

La confiance permet la précision. La surveillance détruit les deux.

La vision : De l'activité aux résultats

L'industrie est à un point d'inflexion.

L'ancienne approche — métriques de surveillance, suivi d'activité, théâtre de la productivité — s'effondre. L'IA accélère l'effondrement. Les chiffres sont plus grands, mais ils signifient moins.

La nouvelle approche se concentre sur ce qui compte :

• De « combien de code » → « est-ce que ça aide les utilisateurs ? »
• De la surveillance → la confiance
• Des métriques de vanité → l'impact commercial
• Du théâtre de la productivité → l'amélioration réelle

Les équipes qui comprennent cela auront un avantage massif. Elles retiendront de meilleurs développeurs (qui ne toléreront pas la surveillance). Elles prendront de meilleures décisions (basées sur des données significatives). Elles s'amélioreront réellement (au lieu de manipuler les métriques).

Le rêve du CTO

Ce que les leaders en ingénierie veulent réellement :

1. La preuve que l'ingénierie s'améliore — Pas seulement des instantanés, mais des trajectoires
2. Des métriques défendables — Quelque chose qu'ils peuvent montrer au conseil d'administration qui ne peut pas être facilement rejeté
3. Pas de manipulation — Des métriques qui résistent à la manipulation
4. Préservation de la confiance — Une mesure qui ne détruit pas la culture d'équipe
5. Mesure prête pour l'IA — Des métriques qui fonctionnent quel que soit les outils que les gens utilisent

Les métriques de productivité traditionnelles échouent aux cinq exigences. Ce sont des instantanés, facilement manipulables, destructeurs de confiance et complètement brisés par l'IA.

Les métriques d'efficacité — axées sur les résultats, conçues pour l'anti-manipulation, construites sur la confiance — répondent aux cinq.

Ce que cela signifie pour votre équipe

Si vous êtes un leader en ingénierie qui envisage des outils de « productivité des développeurs », posez ces questions :

1. Qu'est-ce qu'on mesure exactement ? Si la réponse est l'activité (commits, lignes de code, heures), fuyez.
2. Peut-on le manipuler ? Si optimiser la métrique est plus facile que faire du bon travail, la métrique est inutile.
3. Qu'arrive-t-il aux données ? Si les individus peuvent être comparés et classés, la confiance s'érodera.
4. Comment gère-t-il l'IA ? S'il essaie de suivre l'utilisation des outils, il est déjà obsolète.
5. Est-ce que ça aide les développeurs à s'améliorer ? Si c'est juste de la mesure sans coaching, c'est de la surveillance avec des étapes supplémentaires.

Si vous êtes un développeur soumis à ces outils, sachez que vous n'êtes pas fou. Les métriques sont dénuées de sens. La surveillance fait du mal. Les meilleures équipes — celles pour lesquelles vous voulez probablement travailler — rejettent cette approche.

Rejoignez la rébellion

Nous construisons quelque chose de différent.

Pas de surveillance. Pas de théâtre de la productivité. Pas de métriques de vanité qui ont l'air bien dans les présentations au conseil d'administration mais qui encouragent les mauvais comportements.

Nous construisons la preuve que votre équipe s'améliore réellement.

Cela commence par mesurer ce qui compte : les résultats, pas l'activité. Les tendances, pas les instantanés. L'efficacité, pas la productivité.

Si vous en avez assez des métriques qui mesurent les mauvaises choses, de la surveillance qui détruit la confiance et des outils qui deviennent obsolètes dès que quelqu'un ouvre un assistant IA — nous devrions parler.

Sources