No. 18 · Technical

Technique : Le harnais anti-dérive

Comment un ensemble d’outils automatisés aide à garder toutes les parties d’une base de code, en pleine croissance, cohérentes entre elles pendant qu’une IA la construit, expliqué étape par étape.

Les applications modernes sont composées de nombreuses fonctionnalités, souvent réparties dans plusieurs fichiers. Chaque fonctionnalité forme une chaîne d’éléments liés : exigences, base de données, logique du programme, interface, documentation, formation, etc. Quand une IA modifie une partie, cette chaîne peut facilement se désaligner du reste du système. Même si chaque changement semble correct, l’ensemble de l’application peut se détériorer peu à peu. Pour éviter cela, on met en place un harnais composé de plusieurs outils automatiques, qui permettent de garder l’application cohérente et stable malgré les nombreuses modifications.


## §01 Le problème de la dérive

Quand on demande à une IA de faire un changement précis, comme ajouter un champ dans un formulaire, elle peut le faire très vite. Mais elle ne va pas toujours vérifier les effets de ce changement ailleurs dans le système. Par exemple, si on ajoute un champ « Deuxième prénom », il faut aussi le mettre à jour dans la base de données, la logique d’affaires, la validation du formulaire, la documentation et même le matériel de formation. Comme l’IA se concentre surtout sur la tâche demandée, elle oublie souvent de vérifier l’ensemble du système.

Un utilisateur expérimenté peut penser à demander régulièrement à l’IA de tout vérifier. Dans ce cas, l’IA peut repérer des incohérences, appelées « régressions » ou « dérive ». Mais cela demande de la rigueur et dépend du fait que quelqu’un pense à faire cette vérification chaque fois, ce qui n’est pas fiable. C’est pourquoi on met en place des mécanismes automatiques pour détecter ces problèmes et les signaler à l’IA sans attendre.

La dérive est difficile à voir, car le code peut continuer à fonctionner en apparence. Pourtant, la cohérence du système est déjà brisée et les problèmes peuvent s’aggraver avec le temps. Par exemple, si un champ existe dans l’interface mais pas dans la base de données, l’erreur peut passer inaperçue au début. Avec le temps, ces incohérences s’accumulent. L’IA peut même essayer de corriger le problème plus tard, mais sans savoir quelle version est correcte. Comme le code sert aussi de référence, ces contradictions rendent la situation de plus en plus difficile à gérer et la dérive devient invisible mais grandissante.

"Le code produit par une IA est généralement correct du point de vue fonctionnel à 98 ou 100 pour cent, en ce sens qu’il se compile et s’exécute. Mais ses pratiques font croître la dérive de façon invisible avec le temps, et la base de code se fragmente à chaque révision."


## §02 Une fonctionnalité est une chaîne

Le code moderne est souvent conçu pour être modulaire, c’est‑à‑dire que les composants sont créés une seule fois et réutilisés. Il suit aussi le principe DRY (« Don’t Repeat Yourself »), qui consiste à éviter les répétitions. Cela rend les applications plus faciles à maintenir, mais signifie aussi que les fonctionnalités sont divisées en plusieurs petites parties liées entre elles.
Ces parties sont reliées par des dépendances, formant parfois de véritables chaînes. Quand une IA modifie un élément de cette chaîne, elle met généralement à jour les éléments les plus proches, puis s’arrête. Si, plus tard, elle travaille ailleurs dans cette même chaîne, elle peut utiliser une partie devenue obsolète et créer de nouvelles incohérences. La chaîne se désynchronise peu à peu. Par exemple, enlever un champ dans la base de données devrait aussi être reflété dans l’interface, la documentation et la formation, mais ce n’est souvent pas le cas.

La dérive se propage de deux façons principales. D’abord le long d’une même fonctionnalité, d’un élément à l’autre. Ensuite entre différentes fonctionnalités, lorsqu’un élément partagé change à un endroit et cause des problèmes ailleurs. Un bon harnais permet de détecter ces deux types de dérive en temps réel, pendant que le travail est en cours, plutôt que plusieurs mois plus tard. Pour cela, il s’appuie sur plusieurs mécanismes simples et réutilisables : des instructions pour guider l’IA (appelées compétences), des déclencheurs automatiques à certains moments (crochets), et des vérifications rapides (évaluations). Ces outils accompagnent l’agent et permettent de surveiller et de maintenir la cohérence du système en continu.


## §03 Contrôle 1 : Suivre le changement (l’arpenteur de chaîne)

Cette première fonction suit le changement à travers toute la chaîne de dépendances. Dès que l’IA modifie un fichier, un outil parcourt les éléments liés, dans les deux sens : ce qui alimente ce fichier et ce qui en dépend. À chaque étape, il compare les éléments pour vérifier qu’ils sont toujours cohérents. Par exemple, il vérifie si les noms, les champs ou les attentes correspondent encore. Lorsqu’il détecte un problème, il note précisément ce qui ne correspond plus.
L’outil continue cette vérification jusqu’à une limite définie, puis produit un rapport clair des éléments qui se sont désalignés. Son principal avantage est sa portée : il ne vérifie pas seulement les éléments proches du changement, mais toute la chaîne. Et ses résultats sont assez précis pour permettre de comprendre exactement où se situe le problème.


## §04 Contrôle 2 : Cartographier l’activité (la carte de chaleur des empreintes)

Cette méthode garde une trace des endroits où le travail est effectué. Chaque fois que l’IA modifie un fichier, une marque est ajoutée. On obtient ainsi une carte visuelle du projet sous forme de grille, où les fichiers les plus actifs sont les plus visibles, et où le changement le plus récent est identifié.
Cette méthode ne détecte pas directement la dérive. Elle sert plutôt à montrer où se concentre l’activité, afin d’aider les autres outils de vérification à savoir où regarder en priorité. Elle est simple, peu coûteuse, ne demande aucune configuration et apporte de la valeur dès le début du projet.


## §05 Contrôle 3 : Petits tests automatiques (les évals de chaîne)

Ce contrôle effectue de petits tests automatiques pour vérifier des incohérences précises. Par exemple, il vérifie si la structure de la base de données correspond toujours au script qui la crée, ou si l’interface correspond à sa documentation. Chaque test compare deux éléments liés et signale toute différence. Les tests sont placés directement avec le code et évoluent avec le projet : lorsqu’un nouveau type de relation apparaît, on ajoute un test pour le couvrir. Quand l’IA modifie un fichier, seuls les tests concernés sont exécutés. Ils sont rapides, donnent toujours le même résultat et, comme ils sont définis par l’équipe, ils ciblent exactement les erreurs les plus fréquentes du projet.

"Le surveillant anti-dérive n’écrit jamais l’application lui-même. Il observe les actions du constructeur, lit les preuves que produisent les vérifications automatiques, les confirme par rapport au code, et décide si quelque chose mérite d’être signalé. C’est le contrôle de la circulation aérienne, pas le pilote." · Le harnais anti-dérive, note de conception


## §06 Contrôle 4 : Faire compter la note de sauvegarde (l’épine des commits)

Les développeurs enregistrent leur travail sous forme de petits ensembles de changements, appelés « commits », accompagnés d’une courte description. Dans cette approche, cette description a un double rôle. Elle suit un modèle précis qui indique les éléments modifiés et ceux qui ont été vérifiés en lien avec ce changement. Au moment de l’enregistrement, une vérification automatique s’assure que la description est complète avant d’accepter le changement. L’IA peut aussi rédiger cette description en se basant sur ce qui a réellement été modifié. Comme cela se fait au moment où le travail est sauvegardé, l’information reste fiable. Avec le temps, l’historique du projet devient ainsi une trace claire et consultable des modifications apportées et des vérifications effectuées pour garder le système cohérent.


## §07 Contrôle 5 : Une fiche par fichier (le manifeste des dépendances)

Cette méthode associe à chaque fichier important une petite fiche qui indique ce qui lui fournit des données et ce qui en dépend. Chaque fois qu’un fichier est modifié, cette fiche est mise à jour, puis une vérification rapide compare la fiche avec le contenu réel pour détecter toute incohérence. Un petit schéma montre ensuite le fichier au centre, avec les éléments en entrée au-dessus et les éléments en sortie en dessous. Chaque relation est marquée comme étant correcte, périmée ou brisée. Comme ces relations sont clairement définies, les autres outils peuvent lire ces fiches directement, sans avoir à analyser tout le code à chaque fois.


## §08 Contrôle 6 : Une liste de contrôle de fin d’étape (le balayage de dérive)

Cette méthode exécute automatiquement une liste de vérifications à la fin de chaque étape du travail. Elle vérifie des éléments essentiels, comme : est‑ce que la documentation correspond encore à l’interface ? Est‑ce que les champs de la base de données sont bien utilisés là où il faut ? Est‑ce que le matériel de formation correspond aux écrans actuels ?

Elle produit un court rapport pour chaque étape. Si trop d’incohérences sont détectées, elle peut arrêter le travail de l’IA et exiger que les problèmes soient corrigés avant de continuer.
Ce contrôle ne s’exécute pas à chaque modification, mais seulement à la fin de chaque étape. Cela permet de garder un coût prévisible, tout en assurant que le système reste cohérent avant de passer à la suite.


## §09 Contrôle 7 : Le tableau de bord partagé (le tableau de tuiles)

Ce tableau de bord est conçu autant pour l’humain que pour l’IA. Il présente le projet sous forme de grille : les fonctionnalités sont d’un côté et les quatorze éléments en haut. Chaque case est colorée selon les résultats des différentes vérifications. C’est une vue unique que l’équipe peut consulter pour comprendre rapidement l’état général du système. Le tableau peut aussi afficher les résultats détaillés de chacune des méthodes de vérification, sans avoir à les modifier. En pratique, il fonctionne en continu : pendant que l’agent construit, le système de surveillance anti‑dérive analyse l’ensemble, et les problèmes détectés s’ajoutent progressivement sous forme de notes.


## §10 Des surveillants en marge

Ces contrôles fonctionnent avec l’agent qui construit l’application. Si on donne trop de responsabilités à un seul agent d’IA — gérer la dérive, la sécurité, les tests, la documentation et le style, il devient vite surchargé, et les instructions deviennent trop lourdes pour être efficaces. Le harnais anti‑dérive adopte une autre approche : celle de la supervision. L’agent principal reste concentré sur la construction, pendant que d’autres agents agissent comme des surveillants. Ces surveillants travaillent en parallèle, chacun avec un rôle précis. Ils observent les fichiers du projet, lancent leurs propres vérifications lorsqu’un changement est détecté, puis laissent des notes dans un espace partagé. L’agent principal lit ces notes au début de son prochain cycle de travail et les traite comme des tâches à faire. Chaque surveillant peut fonctionner à son propre rythme. Certains utilisent des modèles plus simples pour les vérifications courantes, tandis que les travaux plus complexes utilisent des modèles plus puissants. Lorsqu’un nouveau besoin apparaît, on ajoute simplement un nouveau surveillant au lieu d’alourdir l’agent principal. En résumé, pendant que l’agent construit, les surveillants observent, analysent et signalent les problèmes en continu.


## §11 Comment les combiner, et ce qui reste à trancher

Ces méthodes s’ajoutent les unes aux autres, et il n’est pas toujours nécessaire de toutes les utiliser. La combinaison la plus simple et efficace consiste à utiliser la carte de chaleur et la vérification en fin d’étape : la première montre où le travail se concentre, et la seconde valide l’ensemble à chaque étape. On peut ensuite ajouter des vérifications plus précises pour mieux soutenir le développement, et tester différents contrôles de surveillance pour élargir progressivement la couverture.

Tags: anti-drift, harness, agents, quality, observability, change-management

Open the interactive version