Au fil des années, j'ai vu beaucoup de façons de mesurer la performance en ingénierie. Certaines étaient formelles, d'autres informelles, et certaines n'étaient même pas vraiment présentées comme de la mesure. Elles influençaient quand même la façon dont les gens étaient perçus, et cette perception commençait souvent bien avant qu'un dashboard ou une évaluation de performance entre dans la discussion.
La première couche, c'est souvent le jugement des pairs. Un collègue lit votre code, entend vos idées ou voit votre façon d'aborder un problème, puis se fait une opinion. Parfois, cette opinion est juste. Parfois, elle reflète surtout un style, une préférence ou un contexte local. Si quelqu'un ne voit pas le système de la même façon que vous, il peut facilement lire vos décisions comme étant plus faibles qu'elles ne le sont vraiment. Pas nécessairement parce que le travail est mauvais, mais parce qu'il ne correspond pas à la façon dont lui l'aurait fait. C'est déjà une forme de signal de performance, même si personne ne le nomme ainsi.
Cette opinion peut devenir contagieuse. Les développeurs parlent. Les équipes construisent des narratifs autour des gens. Quelqu'un peut tranquillement être perçu comme peu performant parce que quelques personnes décrivent son travail de cette façon, et que les autres commencent à regarder avec la même lentille. L'équipe commence à porter une perception partagée de qui est fort, qui a besoin d'aide, qui ralentit les choses et à qui on peut confier le travail difficile. Parfois, cette perception est juste. Parfois, elle est incomplète, biaisée ou basée sur le travail le plus visible plutôt que sur le travail le plus utile.
La mesure formelle arrive souvent par-dessus cette couche humaine. Un Product Owner peut regarder les burndown charts, les estimations, le travail reporté ou la tendance du sprint. Un lead peut regarder la livraison, les pull requests, les commentaires, les bogues en production, le feedback de l'équipe et la performance de l'équipe elle-même. Ces signaux peuvent aider à équilibrer la perception avec des preuves, mais ils peuvent aussi créer une fausse impression d'objectivité. Beaucoup peuvent être contournés. Les estimations peuvent bouger. Les tickets peuvent être découpés autrement. Les pull requests peuvent devenir plus petites ou plus grandes selon ce qui est récompensé. Les commentaires peuvent devenir performatifs. Même les bogues en production ont besoin de contexte, parce que certaines équipes possèdent des surfaces plus risquées que d'autres. À un moment donné, la question devient moins de savoir quelle métrique est la bonne et plus de comprendre ce qu'on essaie vraiment d'apprendre. Est-ce qu'on veut augmenter la productivité pour livrer plus vite? Réduire le risque? Rendre le travail plus prévisible? Ou comprendre si l'équipe est assez en santé pour continuer à bien performer dans le temps?
De la vélocité à la santé de livraison
Je comprends pourquoi l'ingénierie finit sous cette pression. Dans plusieurs entreprises, l'ingénierie est l'un des plus grands centres de coûts, et beaucoup d'autres équipes en dépendent. Si le marketing attend une fonctionnalité qui pourrait générer des revenus, l'idée ne peut pas vraiment être prouvée tant que l'ingénierie ne l'a pas livrée. Si le produit a un engagement de roadmap, il devient réel seulement quand le système change. Cette dépendance crée de l'attention, et l'attention crée généralement de la mesure.
Plus tôt dans mon travail de leadership, je me suis beaucoup appuyé sur la visibilité des sprints. Avant la COVID, j'avais des dashboards sur des télés pour montrer la progression des sprints, les stories qui dépassaient les estimations et les burndown charts qui s'éloignaient du plan. L'intention était utile : débloquer rapidement, voir le risque tôt et challenger l'équipe quand le sprint glissait. Ces outils donnaient de la visibilité, mais ils renforçaient aussi une vision étroite de la performance. Ils rendaient le travail visible plus facile à discuter, tout en laissant beaucoup de travail important hors du cadre.
Plus tard, j'ai commencé à regarder des métriques inspirées de DORA. Je voulais comprendre combien de temps il fallait pour qu'une story passe du début du travail à la production, combien de temps les pull requests attendaient une revue, et éventuellement comment connecter ça à la fréquence de déploiement, au temps de livraison des changements, au temps de rétablissement après un déploiement échoué, au taux d'échec des changements et au travail de reprise après déploiement. On n'avait pas toute l'instrumentation que je voulais, et je n'ai pas réussi à pousser ça aussi loin que je l'aurais souhaité. Si la production avait été visiblement en feu tout le temps, ça aurait probablement été plus facile à justifier. Mais nos systèmes, même les vieux systèmes qui lancent beaucoup d'erreurs connues et acceptées, continuaient généralement de bien fonctionner.
DORA m'a quand même semblé être une amélioration parce que la discussion se déplaçait. On regardait moins si le sprint était propre, et plus si le système de livraison était en santé. Les questions sont meilleures : est-ce qu'on peut livrer de façon sécuritaire, est-ce qu'on peut récupérer, est-ce que les changements créent de l'instabilité, et combien de temps la valeur attend-elle avant d'arriver en production? Mais même cette vue demeure incomplète. DORA est utile pour comprendre la performance du système de livraison logicielle. Elle n'explique pas, à elle seule, toute l'expérience de faire le travail. Une équipe peut améliorer ses métriques de livraison tout en accumulant de la charge cognitive, en affaiblissant son architecture, en brûlant ses gens ou en perdant les habitudes de collaboration qui rendaient cette vitesse possible.
Quand le travail visible devient moins fiable
L'IA agentique a rendu cette limite beaucoup plus difficile à ignorer. Les grosses pull requests sont devenues plus faciles à générer. La revue de code a changé. Le coût de production du code a commencé à baisser, mais le coût de comprendre, valider et aligner ce code n'a pas disparu. Il est même devenu plus important.
C'est cette partie qui m'inquiète le plus. Si une équipe peut générer plus de code en moins de temps, elle peut aussi pousser plus de code vers la production avant que quelqu'un l'ait vraiment compris. Le risque n'est pas seulement que le code soit faux. C'est aussi que la personne qui l'approuve ne soit pas capable d'expliquer les compromis, les cas limites, les hypothèses ou la façon dont le changement s'intègre au reste du système. Quand ça arrive, la revue peut devenir un contrôle seulement en apparence. L'équipe peut encore avoir des pull requests, des approbations et des déploiements, mais la compréhension réelle derrière ces étapes est plus faible.
C'est là que les métriques d'activité traditionnelles deviennent dangereuses. Le nombre de pull requests, de commits, de tickets fermés ou de lignes modifiées était déjà un signal faible lorsqu'il était utilisé seul. Avec l'IA, il devient encore plus faible. Un développeur peut générer plus de code qu'avant et rendre le système pire. Un autre peut produire moins de traces visibles parce qu'il fait du pairing, de la revue, débloque les autres, clarifie l'architecture ou empêche une mauvaise direction de se répandre dans la base de code. Le deuxième crée peut-être plus de valeur, mais les journaux peuvent donner l'impression que le premier est plus occupé.
C'est particulièrement vrai pour les développeurs seniors et les leads. Un développeur senior peut passer du temps à aider quelqu'un à réfléchir à un problème, répondre à des questions, tester un cas limite, aligner avec des parties prenantes ou éviter que deux parties du système partent dans des directions différentes. Un lead peut passer des heures en réunion pour garder l'équipe dans la bonne direction. Rien de tout ça n'apparaît proprement dans les métriques de pull requests. Si le code devient de plus en plus généré, le travail invisible autour du code devient encore plus important.
Le risque, c'est une illusion d'accélération. Plus de code apparaît. Plus de changements avancent. Plus d'activité arrive dans les systèmes qu'on sait déjà mesurer. Mais si plus de code non revu ou mal compris arrive en production, les coûts retardés peuvent apparaître plus tard sous forme de patterns incohérents, d'abstractions faibles, de fatigue de revue, de régressions, de confusion sur l'ownership ou d'une architecture qui perd sa cohérence. Ce risque n'est plus seulement théorique. Un article du Guardian sur des incidents AWS impliquant des outils d'IA décrivait des interruptions où Amazon contestait que l'IA elle-même soit la cause racine et pointait plutôt vers une erreur d'utilisateur et des garde-fous. Même avec cette nuance, l'exemple est utile parce qu'il montre pourquoi l'accès à la production, la revue par les pairs, le contexte et les garde-fous comptent davantage quand des agents peuvent agir rapidement. L'IA peut amplifier les bonnes pratiques d'ingénierie, mais elle peut aussi amplifier les mauvaises.
Pourquoi SPACE me semble plus proche
C'est ce qui m'a poussé à chercher des façons plus larges de réfléchir à la performance en ingénierie. Je suis tombé sur SPACE, qui signifie Satisfaction et bien-être, Performance, Activité, Communication et collaboration, Efficacité et flow. À peu près au même moment, j'ai aussi commencé à regarder le DevEx, ou expérience développeur. Plus je lisais sur les deux, plus ils me semblaient se soutenir dans ce qu'ils essaient de mesurer.
Ce que j'aime avec SPACE, ce n'est pas qu'il donne une réponse parfaite. Il ne le fait pas. Ce que j'aime, c'est qu'il refuse de réduire la performance en ingénierie à un seul chiffre. Le DevEx donne ensuite un vocabulaire utile pour certains signaux qui peuvent alimenter cette vue. Il s'intéresse à l'expérience vécue des développeurs et aux frictions qu'ils rencontrent lorsqu'ils livrent du logiciel. Ses trois dimensions, les boucles de feedback, la charge cognitive et l'état de flow, se placent naturellement dans SPACE. Elles peuvent informer la satisfaction et le bien-être, l'efficacité et le flow, et même la communication et la collaboration. Un build lent, une base de code confuse, un besoin flou, une revue épuisante ou un outil d'IA qui crée plus de nettoyage que de progrès ne sont pas seulement des irritants. Ce sont des contraintes de productivité que SPACE doit pouvoir faire ressortir.
La satisfaction et le bien-être comptent parce qu'une équipe fatiguée peut continuer à produire pendant un certain temps. Ça ne veut pas dire que le système est en santé. À l'ère de l'IA, je pense que ce point devient plus important, pas moins. Un outil peut réduire la charge cognitive lorsqu'un développeur lui fait confiance, comprend le résultat et peut avancer plus vite sans perdre le contrôle. Le même outil peut ajouter de la charge lorsque le développeur doit constamment défaire du code généré, relancer des jobs, réparer des incompréhensions ou revoir des changements trop gros pour être raisonnés confortablement. Une prise de pouls mensuelle sur l'épuisement, la friction des outils, la charge cognitive et la confiance pourrait montrer quelque chose que les dashboards de livraison ne verront pas.
La performance compte encore, mais je préfère la mesurer par la qualité et les résultats du système plutôt que par la production brute. Le taux d'échec, les régressions, les bogues en production, la fiabilité des tests, la stabilité du système et la réduction de la dette comptent tous. La réduction de la dette est difficile à mesurer proprement, mais il existe des signaux utiles : les risques connus qui vieillissent, les incidents répétés dans la même zone, la fraîcheur des dépendances, les hotspots de code, les tests instables et les parties du système qu'une seule personne comprend. Livrer vite est utile seulement si le système reste fiable. Produire plus de code peut donner l'impression qu'une équipe performe bien pendant que le produit devient plus fragile.
L'activité peut encore être utile, mais seulement comme contexte. Les pull requests, les commits, les déploiements, les tickets, l'usage de l'IA et la participation aux revues peuvent aider à expliquer ce qui se passe. Ils ne devraient pas devenir l'objectif. Si une métrique devient une cible, les gens finissent par optimiser pour la métrique plutôt que pour le résultat. Au niveau de l'équipe, l'activité peut révéler des patterns à discuter. Au niveau individuel, elle peut devenir injuste très vite.
La communication et la collaboration sont peut-être les plus difficiles à mesurer, mais c'est aussi l'un des endroits qui m'inquiètent le plus avec l'IA agentique. Si tout le monde commence à travailler surtout avec des agents, certaines conversations d'équipe peuvent disparaître. Les décisions d'architecture peuvent devenir des interactions privées entre un développeur et un outil au lieu de rester des décisions partagées dont l'équipe est propriétaire. C'est risqué. Les systèmes ont besoin de cohérence. Si chaque développeur et chaque agent suit une interprétation un peu différente de la bonne façon de faire, la base de code peut dériver même si tout le monde se sent productif.
L'efficacité et le flow complètent l'image. L'attente en revue, le travail bloqué, les tests instables, le CI lent, les besoins flous, les interruptions et le changement constant de contexte réduisent tous la performance sans toujours apparaître comme des échecs. C'est là que le DevEx devient particulièrement utile comme intrant de mesure à l'intérieur de SPACE. Le temps d'attente en revue, la charge de revue, le temps de build, la fiabilité des tests, le niveau d'interruptions et la capacité d'entrer dans le flow disent tous quelque chose sur la capacité de l'équipe à transformer son jugement en logiciel sans gaspiller son énergie. L'IA peut améliorer le flow d'implémentation tout en nuisant au flow organisationnel si elle crée plus de pression de revue, plus de coordination ou plus d'incertitude sur ce qui a changé et pourquoi.
Mesurer sans aplatir
Je suis encore en train de réfléchir à la bonne façon de collecter ces signaux. Je ne veux pas d'un dashboard de surveillance, et je ne veux pas d'un score unique de productivité. Je veux assez de visibilité pour comprendre où l'équipe est en santé, où le système crée de la friction, et où une métrique ne raconte qu'une partie de l'histoire. Une version pratique pourrait utiliser SPACE comme cadre d'organisation, des métriques inspirées de DORA pour la performance de livraison, et des signaux DevEx comme les délais de feedback, la charge cognitive et le flow comme intrants dans les dimensions SPACE pertinentes. Aucun de ces éléments ne devrait être utilisé seul. La valeur est dans la tension entre eux.
Ça demande d'être prudent sur ce qu'on expose et à qui on l'expose. Une métrique interprétée sans contexte peut faire de vrais dommages. Quelqu'un peut voir moins d'activité en pull request et conclure à une baisse de performance, alors que la personne faisait du mentorat, de la revue, gérait des incidents ou faisait du travail d'alignement qui a évité de plus gros problèmes. Quelqu'un peut voir une livraison plus rapide et conclure à une amélioration, pendant que la qualité baisse discrètement. La mesure devrait aider les équipes à poser de meilleures questions, pas donner aux leaders un raccourci pour éviter de comprendre le travail.
Pour moi, le but n'est pas de maximiser la vitesse d'ingénierie indéfiniment. Si l'IA aide une équipe à livrer des fonctionnalités plus vite qu'avant, la prochaine question n'est pas automatiquement comment en extraire encore plus. C'est plutôt de savoir si l'équipe livre ce dont l'entreprise a besoin à un rythme durable, tout en restant en santé, en communiquant clairement et en gardant le système assez compréhensible pour être maintenu.
Peut-être que je changerai d'idée dans quelques mois et que je regarderai un autre framework. Ça ne me surprendrait pas. Mais je suis convaincu que mesurer avec prudence est mieux que de prétendre qu'on peut gérer tout ça seulement à l'instinct. Une mauvaise mesure peut être pire que l'absence de mesure si elle crée de la peur, du jeu autour des chiffres ou une évaluation individuelle injuste. Le travail change trop vite pour s'appuyer seulement sur les anciens signaux. Plus le code devient facile à générer, plus le jugement devient important, et plus il faut être prudent avec ce qu'on appelle de la performance.
- Patrick