Corriger le harnais avant le code

Quand un agent IA laisse passer un bug, corriger le code ne suffit plus : le défaut reviendra. Les équipes les plus rapides corrigent d'abord le harnais, puis le code.

Quand un agent IA produit un bug, le réflexe est de corriger le bug. C'est précisément ce qu'il ne faut plus faire en premier. Les équipes qui livrent le plus vite avec des agents ont changé de priorité : le harnais d'abord, le code ensuite.

Un harnais, c'est quoi ?

Le harnais regroupe tout ce qui entoure le modèle : hooks, skills, linters, tests, règles de CI. Ce sont des mécanismes déterministes qui encadrent, testent et valident le travail de l'agent avant que le code n'arrive où que ce soit. Ce n'est pas le modèle qui fait la différence, c'est ce qu'on construit autour. Un bon harnais avec un modèle modeste vaut mieux qu'un excellent modèle livré à lui-même.

Le contexte engineering, lui, consiste à placer la bonne information au bon endroit et au bon moment. Le harnais en est la sous-partie qui donne confiance dans ce qui est produit.

Le bug est un symptôme

Corriger le code sans toucher au harnais, c'est réparer la fuite sans regarder le tuyau. Si un agent a laissé passer une erreur, c'est qu'une règle manquait, qu'un hook n'existait pas ou que le contexte était saturé. Le même bug reviendra, sous une autre forme, à la prochaine session.

La démarche est simple. En staging, on part toujours du harnais : pourquoi cela a échoué, à quel endroit, quel skill faut-il modifier, faut-il ajouter un hook ? Souvent, la réponse tient en une phrase : le contexte était trop chargé, une information a manqué. En production, c'est moins dogmatique : on fait les deux. Et si le bug est vraiment trivial, on le corrige à la main, mais en le consignant pour que le harnais en tire la leçon.

La traçabilité comme condition

Pour que cette démarche tienne, il faut savoir d'où vient chaque erreur. Quel modèle, quel niveau de réflexion, quelle session, quel skill, quel agent a produit tel commit ? Sans cette chaîne de traçabilité, on corrige à l'aveugle. Avec elle, on peut presque faire de la data science : rejouer dix fois la même tâche, comparer, et établir qu'une configuration vaut mieux qu'une autre, en vitesse comme en coût.

Cela change la nature du travail. Dans une petite équipe, quelques développeurs et quelques profils produit peuvent envoyer plusieurs milliers de pull requests en quelques mois. Dès lors, une part considérable du temps d'un ingénieur, parfois les trois quarts, passe dans le harnais. Il n'est pas livré une fois pour toutes : il évolue avec l'application, avec les arrivées dans l'équipe, avec les contraintes de coût et de sécurité.

Ne plus relire : un pari raisonné ?

Cette approche explique une phrase qui fait réagir : certains ne relisent plus la majorité du code qu'ils poussent en production. Ce n'est pas de la négligence, c'est un déplacement de la confiance. Elle ne repose plus sur l'œil humain, mais sur une accumulation de verrous qui font que tout casse avant la production.

Le pragmatisme reste de mise. Le paiement se relit encore. Un formulaire qui bugge sur le web se corrige en quelques minutes, tandis qu'une application mobile qui attend plusieurs jours sa validation sur un store, ou un produit avec des millions d'utilisateurs, appellent plus de prudence. Le niveau du harnais se règle selon le risque.

Le harnais exige aussi de la veille. Un harnais verrouillé sur une ancienne version d'un modèle peut passer des semaines à brider une équipe qui ne comprend pas pourquoi ses collègues sont satisfaits. Un harnais figé devient un frein : il faut quelqu'un qui suive les évolutions et les digère pour les équipes, sans les noyer.

Un nouveau métier

On voit apparaître un rôle encore sans nom stable, quelque part entre le devex, le staff engineer et le "métabuilder". Les seniors ne passeront plus leur temps à relire du code, ils verrouilleront le harnais. Et des profils produit ou design y contribueront, pour que l'agent ne parte pas en freestyle sur le métier ou sur le design system.

Ce n'est pas la fin du développeur, c'est un changement de cible. Hier, on corrigeait ce que la machine avait écrit. Demain, on corrige ce qui l'a laissée mal écrire.

Reste une question que nous ne pouvons plus éluder : si le code n'est plus relu, qui relit le harnais ?