Traduction automatique. Lire l’original en anglais: Your performance review is a memory test →
Demandez à n’importe quel responsable technique qui est son meilleur ingénieur. Regardez à quelle vitesse la réponse arrive. Pas d’hésitation, pas de réserve, pas de « laissez-moi vérifier un truc d’abord ». Il le sait. Il l’a toujours su.
Demandez-lui maintenant de montrer le travail.
Vous aurez une histoire. Une bonne histoire, en général, sur un incident géré à 2h du matin, ou un refactor qui a débloqué un trimestre, ou la personne qui répond toujours dans le canal. Ce que vous n’aurez pas, c’est un chiffre, une comparaison, ou un compte rendu des quatre ingénieurs dont le responsable n’était pas dans la salle au moment du travail. La confiance ne reposait jamais sur une mesure. Elle reposait sur le souvenir, et le souvenir est une fonction de la proximité.
Voici la thèse, et tout ce qui suit en est la preuve. La performance en ingénierie est jugée de mémoire, la mémoire récompense la visibilité plutôt que la valeur, et ce que vous voulez vraiment que les gens construisent est écrit dans une feuille de route qui n’est jamais connectée à ce sur quoi vous les évaluez. Ces deux documents, la feuille de route et la performance review, n’ont rien à voir l’un avec l’autre dans presque toutes les entreprises que j’ai vues, y compris la mienne jusqu’à récemment.
Alors nous les avons connectés. Chaque pull request fusionnée est lue par un modèle, se voit attribuer une sévérité, et est multipliée par l’importance que notre feuille de route accorde au composant qu’elle a touché. Le résultat est un leaderboard mensuel, et il alimente les décisions de bonus.
Je vais vous montrer le nôtre, y compris les parties où c’est embarrassant et celles où c’est faux.
La sagesse reçue dit que ça ne peut pas être mesuré, et la sagesse reçue est un haussement d’épaules
La position standard sur la mesure de la production individuelle en ingénierie est qu’il ne faut pas, parce que chaque proxy est un piège. Les lignes de code récompensent le gonflement. Le nombre de commits récompense le découpage. Les story points sont une négociation, pas une mesure. Même les bons frameworks sont délibérément au niveau de l’équipe : DORA mesure quatre choses sur un pipeline de delivery et ne dit rien sur les personnes, ce qui est un choix de conception que ses auteurs explicitent.
Tout cela est correct, et rien de tout cela n’est une réponse. Refuser de mesurer ne produit pas une entreprise où personne n’est classé. Cela produit une entreprise où tout le monde est classé quand même, par un mécanisme sans piste d’audit. Le classement a toujours lieu au moment de la compensation. Il a juste lieu dans une salle, de mémoire, pondéré par la personne avec qui l’évaluateur a passé le plus de temps.
Appelons cela la prime à l’ingénieur bruyant : l’écart entre la note que vous recevez et votre performance réelle, expliqué entièrement par votre distance par rapport à celui qui écrit votre review. Ce n’est pas un défaut de caractère chez les responsables. C’est le résultat prévisible du fait de demander à un humain de comparer les contributions techniques de quinze personnes sur une année en utilisant uniquement ce qu’il a remarqué par hasard.
La prime était inévitable jusqu’à il y a environ deux ans, parce que la matière première pour une meilleure réponse était un tas de diffs que personne n’avait le temps de lire. Cette contrainte a disparu. Un modèle peut lire chaque diff de votre dépôt chaque mois pour moins que le coût d’une heure de la réunion où vous devinez actuellement.
Les lire est la partie facile. Décider ce que vaut la lecture est tout le problème, et ce n’est pas une question technique.
La formule entière tient en une ligne
La voici, en entier, depuis le chemin de scoring dans GitRank :
final_score = is_eligible ? severity_base_points × component_multiplier : 0Ce n’est pas une simplification pour le blog. C’est la ligne. Il n’y a pas de régression cachée, pas de pondération apprise, pas de terme de réputation, pas d’ajustement d’ancienneté. Sévérité multipliée par importance, ou zéro.
La moitié sévérité est une échelle fixe. Quatre niveaux, quatre valeurs de points, définies une fois et visibles par tous ceux qui sont notés :
Un correctif critique vaut vingt correctifs de faible priorité. Ce ratio est une déclaration de politique, et nous l’avons écrite plutôt que de la laisser dans la tête de quelqu’un.
La moitié importance est la partie qui compte vraiment, et c’est la raison pour laquelle je pense que cette approche se généralise. Chaque composant du dépôt porte un multiplicateur, et le multiplicateur est défini par ce dont le produit a besoin ce trimestre :
Chat est à 2,0x parce que chat est ce sur quoi nous misons le produit. Authentification est à 1,0x parce que ça marche et nous aimerions que ça continue de marcher tranquillement. Les fonctionnalités de collaboration et le surlignage de documents sont à 2,0x pour la même raison que chat. Aucun de ces chiffres n’est un jugement technique. Ce sont la feuille de route, retapée dans un champ qui paie.
C’est là le geste. Pas le modèle, pas le leaderboard, pas la gamification. Le geste, c’est que le document de stratégie et l’entrée de compensation sont devenus le même document. Si la feuille de route change en octobre, les multiplicateurs changent en octobre, et l’incitation change en octobre plutôt qu’au prochain cycle annuel de review dans quatorze mois.
Laissez-moi expliciter cela, car c’est la partie que les gens sautent. Le vrai problème dans une organisation d’ingénierie en croissance n’a jamais été que les gens sont paresseux. C’est que quarante personnes intelligentes, chacune optimisant localement et honnêtement, produiront collectivement un quart de travail qui ne correspond pas à ce que l’entreprise a dit vouloir. Le management intermédiaire existe en grande partie pour résoudre cela en transportant la stratégie dans la conversation, un bureau à la fois, perdant en fidélité à chaque saut. Une table de multiplicateurs fait le même travail de routage en un seul saut et ne se fatigue pas, n’a pas de favoris et n’oublie pas ce que vous lui avez dit en janvier.
Un correctif critique dans le chat vaut quarante commits de polish dans l’API
En combinant les deux moitiés, l’écart est sévère.
Un P0 dans le chat obtient 100 de base multiplié par 2,0, soit 200 points. Un P3 dans l’API obtient 5 de base multiplié par 1,0, soit 5 points. La pull request unique la plus précieuse que vous puissiez fusionner ici vaut quarante des moins précieuses. Pas quarante pour cent de plus. Quarante fois.
Ce nombre est délibérément violent, et il fait ce que les incitations douces n’arrivent jamais à faire. Personne ne réorganise sa semaine autour d’une différence de 15 %. Les gens réorganisent absolument leur semaine autour d’un facteur 40.
Regardez ce qui arrive à une semaine réelle sous ces pondérations. Voici la répartition des sévérités sur cinq semaines, avec la semaine du 13 juillet détaillée :
188 pull requests. Les P2 représentent 59 % d’entre elles, ce qui ressemble à une semaine d’ingénierie normale partout : principalement des correctifs de taille moyenne avec une solution de contournement disponible.
Maintenant, pondérez. Ces 111 P2 valent 2 220 points à 1x. Les 50 P1 valent 2 500. Moins de la moitié des pull requests portent plus de la moitié de la valeur de la semaine, et le seul P0 vaut autant que vingt des P3 qu’un simple comptage de commits aurait traités comme un travail identique.
C’est tout l’argument en faveur de la pondération, en une semaine de données réelles. Comptez les pull requests et vous concluez que la semaine était centrée sur les P2. Pondérez-les et vous découvrez que la semaine était centrée sur cinquante travaux spécifiques, et vous pouvez nommer qui les a réalisés.
Deux personnes représentaient 58 % de la production, et je n’aurais pas deviné l’ordre
Revenons au classement, car c’est là que j’ai cessé de faire confiance à ma propre intuition.
Sept développeurs, 10 415 points sur la fenêtre de 30 jours. Le meilleur développeur en détient 3 530, soit 33,9 % de tout ce que l’équipe a produit en valeur. Les deux premiers détiennent 57,7 % à eux deux.
Je veux être prudent sur ce que cela signifie et ne signifie pas. Cela ne signifie pas que les cinq autres sont sous-performants, et si vous le lisez ainsi, vous avez tiré la mauvaise leçon de cet article. Une telle concentration signifie généralement que les deux premiers travaillent sur les composants au multiplicateur le plus élevé, ce qui est exactement ce que le système est conçu pour récompenser et exactement ce que nous leur avons demandé de faire. Le nombre est une description de l’endroit où la valeur atterrit, pas un verdict sur cinq personnes.
Mais regardez l’ordre, car il a brisé ma prédiction. Voici qui possède quoi :
Mulualem-E est l’expert principal sur le chat, notre composant à 2,0x, avec 71 de ses 230 pull requests. Il est également l’expert principal sur les agents, notre composant à 1,5x, avec 86 sur 148, soit 58 % de ce domaine. Si vous m’aviez décrit cela et demandé qui domine le classement, je l’aurais dit sans hésiter. Il est deuxième.
La première place revient à tugberkayartextcortex, avec 31 pull requests P1 contre 12 pour Mulualem-E. Le mélange de sévérité a battu la propriété de composant. Posséder la zone la plus importante du produit n’est pas la même chose que réaliser régulièrement un travail à fort impact dans celle-ci, et jusqu’à ce que nous publiions cela, je n’aurais pas pu vous dire laquelle de ces deux choses notre rémunération récompensait réellement. Elle récompensait celle que j’avais remarquée.
C’est la prime de l’ingénieur bruyant, prise en flagrant délit, dans ma propre entreprise. Mon intuition avait les deux bonnes personnes et le mauvais ordre, et le mauvais ordre, c’est ce qu’est un bonus.
La personne qui a écrit le plus de code est en dernière place
Maintenant, la découverte qui m’a mis mal à l’aise, celle sur laquelle je veux que vous réfléchissiez vraiment.
karthikmudunuri est l’expert principal sur le presentation maker, avec 51 des 58 pull requests de ce composant. Cela représente 88 % d’un domaine produit entier. Le volume n’est pas son problème. Il est dernier au classement, avec 300 points.
Il y a une combinaison qui donne exactement ce nombre : quatre pull requests P1 dans un composant à 1,5x, et rien d’autre qui marque. 4 × 50 × 1,5 = 300. Son badge indique 4 P1, ce qui correspond. Je ne peux pas prouver que c’est la véritable décomposition à partir de ce tableau de bord, et je veux signaler honnêtement l’imprécision, car le classement couvre 30 jours tandis que les graphiques de composants couvrent du 6 juillet au 3 août, donc les deux fenêtres sont proches mais pas identiques.
Si la décomposition est correcte, environ 47 pull requests fusionnées ont produit zéro point. Il n’y a que deux explications. Soit il s’agissait de retouches de faible sévérité, auquel cas le score est correct et la conversation utile porte sur la question de savoir si nous devrions avoir une personne passant un mois à 88% de concentration sur un composant que nous n’avons pas marqué comme important. Soit il s’agissait d’un vrai travail que la porte d’éligibilité a réduit à zéro, auquel cas le score est erroné et l’outil lui doit une explication.
Le scoring est tout ou rien sur l’éligibilité. Échouer à un seul critère activé, et l’ensemble par défaut est le lien vers le ticket, l’implémentation du correctif, la qualité de la description de la PR, les tests là où le modèle juge que des tests sont requis, et un plafond de 3 000 lignes, et le score est zéro quelle que soit la sévérité. Un correctif vraiment critique avec une mauvaise description obtient le même score que rien du tout.
Je ne sais pas quelle explication est la bonne, et voici ma véritable plainte : le tableau de bord devrait pouvoir me le dire, par pull request, et aujourd’hui il me force à le rétro-ingénierer à partir d’un total. C’est une vraie lacune dans notre produit et elle est en cours de correction. C’est aussi le mode de défaillance exact que les gens redoutent dans les systèmes de scoring, donc je ne vais pas prétendre l’avoir découvert lors d’une revue de conception. Je l’ai découvert en écrivant ce billet.
Là où se trouvent les bugs est une décision produit, pas une décision d’ingénierie
L’autre chose qui découle du scoring de chaque pull request est que vous cessez de débattre de la qualité à partir d’anecdotes.
740 pull requests réparties sur les dix composants les plus actifs. 230 d’entre elles, 31%, étaient des correctifs de bugs plutôt que du nouveau travail. Chat à lui seul représente 230 pull requests, encore 31%, ce qui est à quoi un multiplicateur 2.0x est censé ressembler quand il fonctionne.
Ensuite il y a le presentation maker : 58 pull requests, 23 bugs. Cela fait un taux de bugs de 40% dans un composant avec quatre contributeurs, contre 25% dans chat avec sept. Et payments est à 44 pull requests avec 20 bugs, un taux de 45%, dans le composant qui touche à l’argent.
Chat et agents sont à égalité avec 57 bugs chacun, mais chat a produit ceux-ci sur 230 pull requests et agents sur 148. Même nombre de bugs, 55% de travail en plus derrière l’un d’eux. C’est un signal concernant agents qu’aucune rétrospective n’aurait jamais fait émerger, car aucune personne seule dans l’équipe n’a fusionné assez des deux pour le remarquer.
La ligne des bugs et la ligne des fonctionnalités montent ensemble sur la fenêtre plutôt que de s’échanger, ce qui est la forme que l’on souhaite et non la forme que j’attendais. Je lis ce graphique comme descriptif, pas comme une affirmation que nous avons amélioré quelque chose. Il couvre cinq semaines et la tendance est dans le bruit que l’on obtiendrait de l’arrivée d’un seul grand projet.
Voici où notre propre outil est actuellement erroné
Si je ne vous montrais que les parties qui fonctionnent, vous auriez raison de tout remettre en question. Donc :
-
L’onglet prompt ne fait pas ce qu’il dit sur le chemin de production. Il y a un écran d’administration qui vous permet de personnaliser le prompt d’évaluation. Il pilote l’exécuteur d’évaluation par lots. Le chemin webhook et cron qui score les pull requests en production utilise un prompt codé en dur dans le source. Si vous modifiez ce modèle en espérant qu’il change vos scores en direct aujourd’hui, il ne le fera pas, et rien dans l’interface utilisateur ne vous le dit.
-
La colonne du classement du tableau de bord intitulée « PRs » n’est pas un comptage de pull requests. C’est le score d’authorship. Vous pouvez le voir dans la capture d’écran ci-dessus : la première ligne indique 3530 sous PRs et 3530 sous Score. La page de classement autonome fait cela correctement, avec des colonnes séparées pour les pull requests et l’authorship, c’est donc un mauvais étiquetage sur le seul écran que tout le monde ouvre réellement, ce qui est proche du pire endroit pour en avoir un.
-
Notre README publie les mauvaises valeurs de points. Il dit que P2 vaut 25 points et P3 10. La base de données initialise 20 et 5, et la capture d’écran de configuration ci-dessus confirme 20 et 5. La documentation et le logiciel ne sont pas d’accord sur le scoring, et le logiciel gagne.
-
La piste de review est presque morte. Reviewing le code des autres rapporte des points sur une échelle de vélocité séparée, les reviews plus rapides obtenant un score plus élevé. Sur l’ensemble de ce classement, exactement une personne a des points de review : 90 sur un total de 10 415, soit 0,86% de tout ce qui a été scoré. Quoi que nous pensions inciter concernant la revue de code, nous ne le faisons pas. La raison la plus probable est que la synchronisation des reviews n’a commencé à collecter que récemment, mais je ne l’ai pas confirmé, et jusqu’à ce que je le fasse, la lecture honnête est que la fonctionnalité n’atterrit pas.
-
Notre propre FAQ revendique environ 90% de précision de classification et je ne peux pas le justifier. Il n’y a pas d’ensemble d’évaluation dans le dépôt, pas de script de benchmark, et pas de corpus arbitré derrière ce nombre. C’est une affirmation que je n’accepterais pas de la part d’un fournisseur, et elle est sur notre propre page marketing. Elle va disparaître.
Un tableau de bord est contourné, et le nôtre n’a presque aucune défense
Je suis allé chercher dans notre code de scoring des mesures anti-contournement. Voici la liste complète de ce qui existe.
Les pull requests de plus de 3 000 lignes modifiées sont inéligibles, ce qui empêche la forme la plus grossière de gonflement. Les auto-reviews rapportent zéro et sont exclues de toute requête au classement. Les reviews provenant de comptes contenant [bot] dans l’identifiant sont ignorées. On demande au modèle si le code fait réellement ce que la description prétend, ce qui est la chose la plus proche d’un détecteur de non-sens. Les administrateurs peuvent annuler n’importe quel score, et l’annulation nécessite une raison écrite d’au moins dix caractères.
Voici ce qui n’existe pas. Pas de plafond de points par personne par semaine ou par mois. Pas de rendements décroissants pour un travail répété dans le même composant. Pas de dégradation temporelle d’aucune sorte, et la fenêtre de 30 jours du classement est une plage de dates par défaut que n’importe qui peut élargir, pas un plafond. Pas de détection de doublons ou de revert, donc réparer quelque chose que vous avez cassé la semaine dernière rapporte autant que réparer quelque chose que quelqu’un d’autre a cassé. Pas de détection de collusion entre relecteurs. Et le filtre bot s’applique aux relecteurs mais pas aux auteurs de pull requests, donc une pull request fusionnée écrite par un bot rapporte comme une humaine, ce qui en 2026 n’est pas hypothétique.
Toute personne déterminée à exploiter ce système le peut. Diviser le travail en plusieurs pull requests, chacune avec un lien vers un issue et une description claire, ciblant le composant à 2,0x. C’est l’exploit, et je veux le nommer précisément à cause de ce à quoi il ressemble : il ressemble à de petites modifications bien documentées et bien testées sur la partie la plus importante du produit. La façon la plus efficace de tricher notre tableau de bord est de faire ce que nous voulons. Ce n’est pas un accident, c’est l’objectif de conception, et c’est la seule défense contre la loi de Goodhart qui ait jamais réellement fonctionné. Rendre le proxy coûteux à falsifier d’une manière qui ne soit pas la vraie chose.
Ce n’est pas une défense complète. La sévérité est attribuée par un modèle qui lit un diff, et on peut amener un modèle à qualifier un bug moyen de critique avec une description de pull request suffisamment dramatique. Nous n’avons pas mesuré la fréquence de ce phénomène. Personne ne l’a fait. Si vous évaluez un outil de cette catégorie, y compris le nôtre, c’est la question à poser, et « environ 90 % » n’est pas une réponse.
Je ne vais pas vous donner le chiffre d’augmentation, parce que je n’en ai pas
Voici l’affirmation que j’aimerais faire. Depuis que nous avons commencé à publier ce classement mensuellement, le travail s’est visiblement déplacé vers les composants que nous avons marqués comme importants, parce que les ingénieurs veulent le score.
Voici pourquoi je ne le présente pas sous forme de chiffre. Nous avons activé cela en cours de route, sans base de référence propre, sans référentiel de contrôle, et sans définition pré-enregistrée de ce que « déplacé » signifierait. Les multiplicateurs ont changé pendant la période. De même que les effectifs et la feuille de route. Tout pourcentage que je publierais serait un nombre que j’aurais choisi après avoir vu les données, ce qui n’est pas une mesure, c’est une décoration.
Ce que je peux vous dire est qualitatif et je le qualifie comme tel. Les arguments ont changé. Les gens ont cessé de me demander si leur travail était apprécié et ont commencé à demander pourquoi un composant était noté 1,0x. C’est un bien meilleur débat à avoir, et c’est la seule chose pour laquelle j’aurais payé de moi-même.
Si jamais j’ai un véritable avant-après, je publierai la méthodologie d’abord et le chiffre ensuite. Si je le publie dans l’autre sens, ne me croyez pas.
Pointez-le vers la feuille de route, puis donnez la règle aux gens
Je veux terminer au-dessus du produit, parce que le produit est la chose la moins intéressante ici.
Le vrai rôle de l’organigramme n’a jamais été l’autorité. C’était le routage. Il transportait la réponse à « ce qui compte ce trimestre » vers l’extérieur depuis les personnes qui l’ont décidé, et transportait la réponse à « qui a fait quoi » vers l’intérieur, et il faisait les deux mal, lentement, et avec une distorsion énorme à chaque saut. Tout ce que vous n’aimez pas dans la politique d’entreprise est un artefact de compression de ce routage. Les managers n’en étaient pas la cause. Ils étaient le seul matériel disponible.
Ils ne sont plus le seul matériel disponible. Un modèle qui lit chaque diff plus une table de multiplicateurs effectue le routage externe en un saut et le routage interne en une requête. Ce qui reste pour les humains, c’est la partie qui a toujours été le vrai travail et qui n’a jamais eu le temps : décider ce que devraient être les multiplicateurs, et s’asseoir avec les personnes dont les scores ont été modifiés par ces décisions.
La politique ne disparaît pas. Ne laissez personne vous vendre cela. Elle se déplace. Elle passe de « est-ce que mon manager se souvient de mon trimestre » à « pourquoi mon composant est noté 1,0x alors que la feuille de route dit qu’il est central », et ce second combat est un combat sur la stratégie réelle de l’entreprise, mené en public, dans un tableau que tout le monde peut lire. Je préfère avoir ce combat chaque mois plutôt que celui actuel, qui est mené une fois par an, en privé, par quelqu’un qui reconstruit onze mois de mémoire.
Quelqu’un va mal gérer cela. Quelqu’un va mettre un tableau de bord sur un mur sans explications d’éligibilité et sans trace d’annulation et virer le décile inférieur, et ce sera un désastre, et on en blâmera le modèle plutôt que la personne qui a choisi les multiplicateurs. C’est la partie qui est payée, et elle ne sera pas payée par celui qui l’a mise en place.
Alors mesurez-moi avec le même instrument. Si vous mettez en place quelque chose comme ça, publiez trois choses à côté du classement : la table des multiplicateurs, pour que les gens puissent débattre de la stratégie plutôt que du score. La ventilation par pull request, pour que quiconque a obtenu zéro puisse voir quelle porte s’est fermée sur lui et faire appel. Et le journal des annulations, parce que le nombre qu’un humain a modifié est le seul nombre qui mérite d’être audité.
Nous publions actuellement le premier. Nous faisons le troisième mal : une annulation écrit sa raison sur la ligne d’évaluation, et effacer l’annulation supprime la raison avec elle, donc ce que nous avons est une note qui peut être révoquée plutôt qu’un journal. Et nous ne publions pas le second assez bien, ce que j’ai découvert seulement parce qu’un développeur avec 88 % d’un composant s’est retrouvé dernier sur mon propre classement et je n’ai pas pu lui expliquer pourquoi.
GitRank est disponible sur gitrank.dev et est sous licence CC BY-NC 4.0. Le scoring sur le chemin de production utilise Claude Haiku 4.5 à température 0,3. Tous les chiffres ci-dessus proviennent de notre propre dépôt de la plateforme entre le 6 juillet et le 3 août 2026, avec un échantillon d’une entreprise et de sept développeurs, ce qui est une description de nous-mêmes et non un benchmark de quoi que ce soit.