Nous mesurons encore les ingénieurs sur la partie qui a été automatisée.

Il y a une phrase que les ingénieurs de vingt ans de métier prononcent désormais à voix basse, comme on avoue quelque chose : je n'écris plus vraiment de code.

Elle vient en général avec une petite excuse accolée. Elle ne devrait pas. Ce que cette phrase a d'intéressant n'est pas ce qu'elle dit de celui qui la prononce. C'est ce qu'elle dit des instruments avec lesquels nous décidons si cette personne est bonne.

Le tableau de bord a été jeté, et presque personne ne l'a remarqué

Pendant une décennie environ, le secteur a noté la livraison sur quatre chiffres et rangé les équipes en low, medium, high et elite. Ces paliers étaient cités dans des présentations de conseil d'administration par des gens qui n'avaient jamais lu le rapport d'origine, ce qui est en général le signe qu'une mesure est devenue véritablement porteuse.

En 2025, DORA les a abandonnés. Les paliers ont disparu, remplacés par sept archétypes d'équipe, décrits sur huit mesures : throughput, stabilité, performance de l'équipe, performance du produit, efficacité individuelle, temps consacré au travail à valeur, friction et épuisement. Les archétypes portent des noms plutôt que des rangs, du genre qu'on ne peut pas mettre sur une diapositive en faisant croire que c'est une note.

On peut soutenir à raison que c'est plus difficile à appliquer que quatre chiffres et une échelle. Ça l'est. Mais la raison du changement est la part qui mérite qu'on s'y arrête : la moitié de ces huit mesures ne parle pas de production du tout. Friction, épuisement, temps à valeur et efficacité individuelle mesurent si une organisation gaspille le jugement qu'elle emploie.

C'est un aveu très précis. Il dit que l'ancien instrument mesurait le volume de travail et se désintéressait de savoir si ce travail était le bon, et que cette distinction a cessé d'être abordable.

Ce que disent les chiffres, et pourquoi ils dérangent

Les données de 2025 expliquent l'urgence. Environ 90 % des répondants déclarent utiliser l'IA dans leur travail, avec une médiane d'environ deux heures par jour, contre 75 % l'année précédente. En comparant des personnes aux caractéristiques et environnements par ailleurs identiques, une adoption plus forte de l'IA est associée à une meilleure efficacité individuelle, un throughput plus élevé, une meilleure performance organisationnelle et une meilleure qualité déclarée du code et du produit.

Et à une plus grande instabilité de la livraison logicielle.

Il vaut la peine de lire ce couple lentement, car sa forme est l'argument. L'IA a déplacé presque toutes les métriques dans le bon sens, sauf celle qui dit si le système tient debout. Les mesures qui se sont améliorées comptent la production. La mesure qui s'est dégradée compte les conséquences.

Si votre idée d'un ingénieur se construit à partir des cinq premières lignes, les deux dernières années ressemblent à un triomphe. Si elle se construit à partir de la dernière, elles ressemblent à un avertissement. Les deux lectures sortent du même jeu de données, et c'est exactement pour cela que le tableau de bord devait changer.

Cela s'est déjà produit, et nous savons comment cela finit

Il y a vingt ans, un bon administrateur système était quelqu'un qui configurait bien un serveur. La compétence était réelle et rare, et se mesurait par une sorte de throughput : combien de machines, à quelle vitesse, avec combien peu d'erreurs.

Puis la gestion de configuration est arrivée, et ensuite l'infrastructure as code. L'ingénieur a cessé d'écrire la configuration et s'est mis à décrire l'état souhaité. Personne aujourd'hui ne pense qu'un ingénieur qui utilise Terraform est moins compétent qu'un autre qui configure les machines à la main. Au contraire : nous considérons la configuration manuelle comme un risque, parce qu'elle ne se relit pas, ne se reproduit pas et ne s'annule pas.

Le travail n'a pas disparu. Il est monté d'un niveau. Ce qui était un acte de production est devenu un acte de spécification, et la difficulté a changé de place : elle n'est plus dans l'exécution correcte mais dans le fait de décider correctement, car une erreur dans un module se propage désormais à quatre cents machines au lieu d'une.

Nous n'avons jamais appelé cela un déclin. Nous l'avons appelé maturité, et nous avons relevé les salaires en conséquence.

La même échelle, en trois barreaux :

Le logiciel applicatif gravit aujourd'hui les mêmes barreaux, et ceux qui le vivent le décrivent dans le langage de la perte. Observez quel barreau l'automatisation a pris à chaque fois. Elle a pris celui de gauche et laissé celui de droite exactement où il était.

Ce qui est réellement monté d'un niveau

Il vaut la peine d'être précis sur la part du travail qui a changé, car la réponse est plus petite que l'enthousiasme et plus grande que ne l'admettent les sceptiques.

Ce qui est devenu bon marché, c'est la transcription. Traduire en syntaxe qu'une machine accepte une décision déjà prise. C'était toujours la partie la moins intéressante, et elle consommait une large part de la journée.

Ce qui n'est pas devenu bon marché, c'est tout ce qui précède la première ligne : est-ce que ceci doit être un service ou une fonction, quel est le mode de défaillance quand le tiers est indisponible, lequel de ces deux modèles de données fera mal dans dix-huit mois, est-ce que cette intégration crée une dépendance dont l'entreprise ne peut pas sortir. Nous avons écrit sur le versant qualité du code dans l'IA a résolu la syntaxe, pas le jugement. Ceci en est la version organisationnelle.

Un agent écrit déjà le code, génère les tests, ouvre la pull request et met à jour la documentation. Ce sont des tâches de production et elles s'automatisent dans cet ordre. Ce qu'aucun agent ne fait aujourd'hui, c'est vous dire que ce qu'il vient de construire avec soin ne devrait pas exister.

La colonne de droite n'est pas une liste de choses que les modèles ne feront jamais. C'est une liste de choses qui exigent de connaître l'organisation, son histoire, ses contrats et son appétit pour le risque. Ce ne sont pas des capacités de modèle. C'est un contexte qui, pour l'essentiel, n'est écrit nulle part, et c'est pourquoi ceux qui le détiennent valent désormais davantage, et non moins.

Les décisions sans autocomplétion

En pratique, les décisions qui déterminent la survie d'un système se prennent avant toute frappe, et elles sont moins nombreuses qu'on ne le suppose. Sur un projet normal, nous en comptons peut-être une douzaine qui comptent.

• Où passe la frontière entre deux systèmes, car cette frontière devient un contrat et les contrats coûtent cher à déplacer.
• Ce qui se passe quand une dépendance est indisponible, décision métier déguisée en décision technique.
• Quelles données constituent le système de référence, car tout l'aval hérite de ce choix.
• Ce que le système a le droit de faire sans personne, question devenue concrète plutôt que théorique.
• Ce que l'on décide délibérément de ne pas construire, la décision la moins écrite et la plus regrettée.

Chacune tient en une phrase et aucune ne se délègue à quelque chose qui n'a pas lu les quatre dernières années de décisions de votre organisation. Si elles sont justes, du code médiocre survit. Si elles sont fausses, un code excellent, produit vite, arrive plus vite à un endroit où vous ne vouliez pas être.

Un exemple récent, et volontairement sans éclat. Une équipe avait besoin d'une étape d'approbation de documents. L'implémentation évidente était un flux dans la plateforme où les documents vivaient déjà, et un assistant produit cela en un après-midi, correctement. La question que personne n'a posée d'abord était de savoir si l'approbation était une propriété du document ou un fait métier. C'était un fait métier : la même approbation devait être visible d'un système qui n'aurait jamais accès à la bibliothèque de documents. L'après-midi de code correct aurait été jeté dans l'année, et le coût n'aurait pas été l'après-midi. Cela aurait été les six mois pendant lesquels deux systèmes se contredisaient sur ce qui avait été approuvé.

Cette décision a pris vingt minutes et aucune ligne de code. C'est aussi toute la raison pour laquelle le projet n'a pas eu à être refait, et elle n'apparaîtrait dans aucune mesure de la production de cet ingénieur cette semaine.

La phrase n'est pas un aveu

Alors, quand un ingénieur expérimenté dit qu'il n'écrit plus beaucoup de code, la lecture honnête est en général l'inverse de la lecture honteuse.

C'est la même phrase qu'un administrateur système aurait prononcée en 2012 au sujet de la configuration manuelle des serveurs, et personne ne l'entend aujourd'hui comme un déclin. Elle signifie que la personne est passée de produire des artefacts à décider quels doivent être les artefacts, direction qu'a prise toute discipline d'ingénierie à mesure que son outillage mûrissait. Les ingénieurs en structures ont cessé de tracer chaque trait à la main. Cela n'en a pas fait des dessinateurs moins compétents.

Le risque de cette phrase est ailleurs, et mérite d'être nommé. Un ingénieur qui cesse complètement d'écrire du code finit par ne plus pouvoir évaluer le code qu'il approuve, et le jugement sans contact avec la matière devient de l'opinion. Ceux qui réussissent cela n'écrivent pas rien. Ils écrivent moins, exprès, et lisent beaucoup plus.

Que mesurer à la place

Si le throughput s'est amélioré pendant que la stabilité se dégradait, alors le throughput a cessé de fonctionner comme approximation de la valeur, et continuer à le récompenser n'est pas neutre. Cela sélectionne activement le comportement qui a produit l'instabilité.

Les mesures qui méritent la discussion sont celles qui survivent à l'automatisation de la production :

Chaque ligne de droite est plus difficile à collecter que celle de gauche, et ce n'est pas un hasard. Ce qui prédit la survie d'un système a toujours coûté plus cher à mesurer que ce qui prédit à quel point tout le monde avait l'air occupé. L'automatisation de l'étape de production a retiré la dernière excuse pour utiliser les mesures bon marché.

La partie qui vieillit bien

L'outillage continuera de bouger. Le modèle en production aujourd'hui sera remplacé deux fois avant que ceci ne vieillisse, et l'agent qui ouvre des pull requests cette année fera l'an prochain quelque chose de plus ambitieux.

Ce qui ne bougera pas, c'est l'endroit où loge la difficulté. Elle a gravi l'échelle de l'abstraction dans toutes les disciplines d'ingénierie jamais automatisées, et elle n'est jamais redescendue. À chaque fois, les mêmes trois choses se sont produites : l'étape de production est devenue moins chère, le coût d'une mauvaise décision a grandi parce qu'elle se propageait plus loin, et la profession a passé quelques années inconfortables à mesurer la mauvaise chose avant que les instruments ne rattrapent leur retard.

Nous sommes dans les années inconfortables. DORA a changé son instrument en 2025 ; la plupart des organisations n'ont pas changé le leur.

La valeur d'un ingénieur n'a jamais vraiment été la frappe. Elle n'était mesurable que de cette façon, ce qui est une affirmation différente, et celle-là vient d'expirer.