Idée principale

Quand un agent comme Claude Code implémente une fonctionnalité, il explore le code existant, modifie plusieurs classes, ajoute des fonctions, écrit des tests, et rend un travail qui compile et dont les tests passent. Ces deux signaux disent que l'implémentation est techniquement correcte. Ils ne disent rien de sa fidélité au métier.

Trois dérives passent sous ces deux contrôles. L'agent peut employer un second nom pour un concept qui en avait déjà un — « bon de commande » à côté de « commande » dans un ERP. Il peut réintroduire une notion que l'équipe avait abandonnée. Il peut créer une règle qui en contredit une autre, ailleurs dans le code : une facture validée qui redevient modifiable par un nouveau chemin.

Aucune de ces dérives ne casse un test, parce que les tests portent sur le comportement que l'agent vient d'écrire, pas sur le modèle métier qu'il aurait dû respecter.

Pourquoi c'est important

Le risque change d'échelle à mesure que les agents prennent une part croissante des modifications : chaque tâche est une occasion pour l'agent de reconstruire sa propre interprétation du métier, et les écarts s'additionnent sans qu'aucun contrôle existant ne les voie. Il manque un référentiel commun du métier, extérieur au code que l'agent modifie, auquel confronter son travail.

Nuances et limites

Le phénomène n'est pas propre aux agents : un développeur humain introduit les mêmes dérives. Ce qui change est le volume et la vitesse, et le fait qu'un agent n'a aucune mémoire des discussions qui ont fixé le vocabulaire et les règles.

Questions ouvertes

• Quelle proportion des dérives métier introduites par un agent un relecteur humain repère-t-il réellement en revue de code ?