Vos agents IA ont un fichier de règles. Ils n'ont pas de modèle de votre système.

Ouvrez le CLAUDE.md, AGENTS.md ou .cursor/rules à la racine de votre repository et lisez-le comme il arrive à un agent : un bloc de texte, sans rien à l'intérieur qui indique quelles lignes sont encore vraies.

L'essentiel de ce que vous y trouverez, ce sont des conventions. Utilisez des tabulations. Pas de any. Retournez tôt. Enveloppez les erreurs avec %w. Ces lignes-là sont durables, parce qu'elles décrivent comment écrire une ligne de code, et l'agent les applique au code qu'il a sous les yeux.

Puis il y a l'autre type de ligne. Celle qui décrit votre système : quels services existent, quel package possède quoi, comment les couches ont le droit de se parler. Ce sont ces lignes qui font l'intérêt du fichier, et ce sont elles qui pourrissent.

Je le sais, parce que le nôtre a pourri.

Ce qui a périmé chez nous

Le repository d'Archyl a un CLAUDE.md à la racine. C'en est un bon, aux standards du genre : 422 lignes, un arbre d'architecture, les variables de configuration, le câblage de l'injection de dépendances, une description du pipeline de discovery. Tout agent qui touche à cette codebase le lit avant de faire quoi que ce soit d'autre.

Voici ce qu'il disait le matin où j'ai écrit ces lignes, le 5 août 2026. Ligne 392 :

No test suite: The codebase currently has no Go test files or frontend tests.

Pas de suite de tests : la codebase n'a actuellement aucun fichier de test Go ni test frontend.

Il y a 146 fichiers _test.go sous backend/ et 31 fichiers de test sous frontend/src/.

La ligne 140 dit :

AI Provider Abstraction: Supports both OpenAI and Ollama via ai.Provider interface.

Abstraction de provider IA : supporte à la fois OpenAI et Ollama via l'interface ai.Provider.

backend/internal/adapter/ai/resolver.go route vers OpenAI, Anthropic, Gemini, Bedrock et n'importe quel endpoint compatible OpenAI, en plus du chemin OpenAI et Ollama géré par la plateforme. Cinq types de provider dans un seul switch. Le fichier en nomme deux.

Et l'arbre d'architecture, aux lignes 74 à 87, liste onze packages sous internal/domain/ : c4, project, user, team, adr, projectdoc, flow, insight, subscription, dependency, history. Il y a aujourd'hui quarante et un répertoires dans internal/domain/. Parmi les trente qu'il ne mentionne pas : conformance, drift, apicontract, marketplace, reality, managedagent, mcpsession. Autrement dit, l'essentiel de ce que le produit est devenu depuis que le fichier a été écrit.

Chacune de ces lignes était vraie le jour où elle a été tapée. Aucune n'a été corrigée ensuite, parce que les corriger demande qu'un humain le remarque, et rien ne surveillait.

C'est une entreprise qui vend de la documentation d'architecture. Si la discipline était le remède, ça aurait marché ici.

Les deux moitiés de ce fichier n'ont rien en commun

La moitié conventions est applicable. « Pas de fmt.Println en Go », c'est un grep. « Les fichiers Go doivent être en snake_case », c'est un script. Si un agent enfreint l'une d'elles, un linter le dit en CI. Si la convention elle-même change, le linter commence à échouer et quelqu'un met le fichier à jour. Il y a une boucle de retour, et elle est assez courte pour fonctionner.

La moitié système n'a pas d'équivalent. Il n'existe pas de go vet pour « le service de paiement est interdit d'accès direct à la base de données ». Rien ne parse cette phrase, rien ne la compare au repository, rien n'échoue quand elle cesse de correspondre. C'est de la prose dans un fichier markdown, et la prose n'a pas de mode d'échec.

Un fichier de règles, c'est donc deux documents qui partagent un nom de fichier. L'un est vérifié en continu, l'autre n'est jamais vérifié, et rien dans le fichier ne les distingue. « Enveloppez les erreurs avec %w » et « la codebase n'a pas de tests » figurent dans la même liste, sur le même ton. L'un est une règle sur le code que l'agent a sous les yeux. L'autre est une affirmation sur 146 fichiers qu'il ne regarde pas.

L'absence est la moitié la plus difficile

La péremption, c'est la défaillance que tout le monde arrive à se représenter. La plus discrète compte davantage : un fichier de règles ne contient que ce que quelqu'un a pensé à écrire, et rien dedans ne distingue « ça n'existe pas » de « personne n'en a parlé ».

Le nôtre ne mentionne jamais internal/adapter/marketplace/. Ce package contient une interface de provider et huit adaptateurs : GitHub, GitLab, Argo CD, Datadog, Prometheus, Sentry, SonarQube, PagerDuty. La liste d'adaptateurs dans CLAUDE.md s'arrête à git, ai, stripe, email, osv et registry. Rien de ce que le fichier dit du marketplace n'est faux. Le fichier n'en a pas.

Je n'ai pas fait l'expérience de demander à un agent d'ajouter une neuvième intégration, et je ne vais pas vous dire ce que ça donnerait, parce que j'inventerais le résultat. Ce que je peux vous dire, c'est que la carte ne porte aucun marketplace, et que c'est la condition ordinaire de tous les fichiers de règles que j'ai lus, y compris ceux que j'ai écrits.

Un modèle n'a pas cette propriété. Vous pouvez demander à un modèle ce qui existe et obtenir une réponse qui veut dire quelque chose, parce que la réponse est une requête sur un ensemble plutôt qu'une recherche à travers de la prose. « Qu'est-ce qui parle au service de paiement » est une question à laquelle un graphe peut répondre et un paragraphe non.

Les deux réponses évidentes, et pourquoi aucune ne tient

Écrire un meilleur fichier de règles. Plus long, plus soigné, avec une case à cocher dans le template de pull request. Les équipes font ça, et ça marche quelques semaines. Ça ne tient pas, pour une raison qui n'a rien à voir avec la discipline : chaque ligne qui décrit le système est une copie en cache de quelque chose qui vit ailleurs, et les caches ont besoin d'invalidation. Ici, l'invalidation, c'est un humain qui remarque. C'est tout le mécanisme, et c'est le même que celui censé garder les diagrammes d'architecture exacts depuis vingt ans. On sait comment ça s'est terminé ; le guide de détection de drift est la version longue de cet argument.

Laisser l'agent lire le repository. Il le peut, et pour une question portant sur un seul fichier il le devrait. Mais lire le code ne vous dit pas quelles frontières étaient délibérées. L'interface posée devant un service a exactement la même allure qu'elle soit là à cause d'une décision prise il y a deux ans après un incident, ou parce que quelqu'un aime les interfaces. L'intention n'est pas récupérable depuis l'artefact qui en a résulté. C'est pour ça que le fichier de règles existe en premier lieu, et c'est pour ça que le supprimer n'est pas non plus la réponse.

Quelqu'un en dehors de cette entreprise a remarqué la même chose

Thoughtworks a placé « Architecture drift reduction with LLMs » dans l'anneau Assess du Technology Radar Vol. 34, publié en avril 2026. Leur ouverture :

Increased use of AI coding agents can accelerate drift from the intended codebase and architecture designs. Left unchecked, this drift compounds as agents and humans replicate existing patterns, including degraded ones, creating a feedback loop where poor code begets poorer code.

L'usage croissant d'agents de code IA peut accélérer l'écart avec la codebase et les designs d'architecture visés. Laissé sans contrôle, ce drift se cumule à mesure qu'agents et humains répliquent les patterns existants, y compris ceux qui se sont dégradés, créant une boucle de rétroaction où du code médiocre engendre du code plus médiocre encore.

Assess, dans la définition du radar lui-même, veut dire "worth exploring with the goal of understanding how it will affect your enterprise" — à explorer, dans le but de comprendre en quoi cela affectera votre entreprise. Ce n'est une recommandation de rien, et certainement pas de nous. C'est une note disant que certaines de leurs équipes essaient, et que c'est tôt.

La partie utile, c'est la forme qu'ils décrivent : des outils d'analyse déterministe (ils citent Spectral, ArchUnit et Spring Modulith) combinés à une évaluation par LLM, parce que la structure est vérifiable par un programme et l'intention non. La leçon qu'ils rapportent mérite d'être volée elle aussi : le premier scan fait remonter plus de violations que quiconque n'a envie d'en trier.

Remarquez ce qui ne figure pas dans cette recette. Personne n'a pour réponse au drift accéléré par les agents un fichier markdown plus long.

Ce que l'artefact devrait faire

Deux propriétés. Aucune n'est exotique.

Il doit énumérer. Vous devriez pouvoir demander ce qui existe et recevoir l'ensemble, pas le souvenir qu'en garde quelqu'un. Cela veut dire un artefact qu'on interroge plutôt qu'on lit, et la différence se voit le plus durement sur les questions que personne n'a écrites.

Il doit être falsifiable. Quelque chose doit le comparer au code et signaler quelles parties ont cessé d'être vraies, à un rythme qui ne soit pas « quand un humain le remarque ». ArchUnit fait ça pour les règles de couches Java. dependency-cruiser le fait pour les imports JavaScript. Les deux sont délibérément étroits, et les deux illustrent le point : l'artefact qui vaut la peine est celui avec lequel un programme peut être en désaccord.

Un fichier de règles échoue sur les deux. Il n'énumère pas, et rien ne peut le contredire.

Où nous en sommes, et ce que je ne peux pas vous dire

Archyl maintient un modèle C4 de votre système : systèmes, containers, composants, relations, générés depuis le repository par la découverte par IA et validés par une personne plutôt que dessinés par une personne. Ce modèle, c'est la moitié énumérable, et les agents l'atteignent via MCP, l'équivalent de 181 outils, pour qu'un agent demande ce qui existe au lieu d'espérer que quelqu'un l'ait écrit. La moitié conventions, c'est un catalogue de conformance : 169 règles réparties sur 23 technologies nommées plus un ensemble agnostique du langage, des vérifications déterministes plutôt que de la prose. Et le modèle est re-confronté au code et scoré, ce qui est la propriété de falsifiabilité.

Avoir un serveur MCP n'est pas la partie intéressante, et quiconque vous en vend un comme différenciateur vous vend une prise de courant. Structurizr en livre un et celui d'IcePanel est en bêta ouverte. La question qui mérite qu'on se dispute, c'est de savoir si la chose derrière la prise est maintenue, parce qu'un endpoint qui sert un modèle périmé depuis mars n'est qu'une façon plus rapide d'avoir tort.

Je pense que c'est la différence qui compte. Je ne peux pas le prouver. Personne n'a mesuré si un agent travaillant à partir d'un modèle maintenu écrit du code mieux formé qu'un agent travaillant à partir d'un fichier de règles soigné, et tant que personne ne l'aura fait, cette phrase est une affirmation sur un mécanisme, pas un résultat. Tenez-la comme telle, et objectez à quiconque l'énonce plus platement que je viens de le faire.

Il y a ici un pli honnête aussi. Archyl génère un fichier de règles. L'outil MCP get_agent_context renvoie l'architecture sous forme de briefing markdown que vous pouvez committer dans votre repository, ce qui est un fichier de règles sous un autre nom. Le fichier n'a jamais été le problème. Le problème, c'est que rien ne se tenait derrière, donc rien ne pouvait le régénérer. Un fichier de règles qui est le cache d'un modèle maintenu, c'est très bien. Un fichier de règles qui est la seule copie, c'est un instantané de ce qu'une personne croyait un après-midi.

La version cinq minutes, qui ne vous coûte rien

Ignorez tout ce qui précède et faites plutôt ceci.

Ouvrez votre fichier de règles. Allez ligne par ligne et marquez chacune soit comme convention, c'est-à-dire qu'elle dit à l'agent comment écrire du code, soit comme affirmation, c'est-à-dire qu'elle dit à l'agent quelque chose sur votre système. Puis, pour chaque affirmation, écrivez ce qui vous apprendrait qu'elle a cessé d'être vraie.

Mon pari, c'est que vous arriverez au bout du fichier avec une deuxième colonne vide. Voilà l'écart. Ce que vous en faites est une décision à part, et vous n'avez rien à acheter pour le voir.

Le nôtre a pris quelques minutes et a fait sortir trois lignes fausses. Les corriger, c'est un commit, et ça ne change rien de structurel : la prochaine ligne périmera de la même façon, et rien ne surveille celle-là non plus.