La question intéressante en 2026 n’est plus de savoir si une IA peut écrire du code. Elle le peut, et une bonne partie de ce que je livre est écrit comme ça.

La question, c’est ce qui l’empêche de démolir un système sur lequel elle travaille depuis six mois.

La réponse ne se trouve pas dans le prompt. Elle se trouve dans la structure du dépôt.

Je maintiens un monorepo qui contient un framework web, trois sites, une application photo en Rust, un plugin Obsidian et une plateforme de publication. Une IA touche à presque tout, tous les jours. Ce qui rend ça tenable n’a rien à voir avec la qualité de mes instructions — c’est un ensemble de contraintes qui vivent dans les fichiers eux-mêmes, là où on ne peut pas les oublier.

Voici ce que j’ai construit, et ce que ça coûte.

Ce qui ne marche pas

Trois choses que j’ai essayées avant, et que je vois recommander partout.

Le prompt parfait. On le raffine, il marche une session, et il ne survit pas au changement de contexte. Un prompt est une intention. Une intention ne contraint rien.

Le fichier d’instructions de quatre cents lignes. Il commence bien. Puis il gonfle, personne ne le relit, il finit par se contredire lui-même — et une IA face à deux règles contradictoires en choisit une, sans le dire.

La discipline personnelle. Relire chaque diff. Ça tient deux semaines. Ça ne tient pas six mois, et surtout ça ne tient pas un mardi soir à 23 h quand le build casse.

Le point commun des trois : ils demandent à quelqu’un — moi, ou le modèle — de se souvenir. Une règle qui dépend de la mémoire n’est pas une règle. C’est un vœu.

Déplacer la contrainte dans la structure

Une seule source de vérité, et des fichiers qui pointent vers elle

CLAUDE.md, AGENTS.md, GEMINI.md et .github/copilot-instructions.md existent uniquement parce que les outils chargent ces noms-là. Chacun fait onze lignes et dit la même chose : va lire le README.

> [!important]
> **→ Read [`README.md`](./README.md). It is the single source of truth**

Quatre fichiers, une seule vérité. Le jour où une convention change, elle change à un endroit. C’est ennuyeux comme solution, et c’est exactement pour ça que ça marche : il n’y a aucun endroit où la dérive puisse s’installer.

Des lois, pas des recommandations

Le fichier .agents/rules/standard.md est injecté au début de chaque session. Il contient huit lois. Les voici mot pour mot :

1. No backward compatibility — Pre-release; no shims, no legacy aliases.
2. DRY — Reuse before you write.
3. .astro files must hold no business logic.
4. Vertical-slice modules — Use @modules/, never relative climbs.
5. src/ minimal — Place app code in modules/.
6. Agent Lock — Do not touch lines marked // @agents lock true without explicit permission.
7. Fatal Errors — Every fatal error must document a page on stnd.build.
8. Build & Secrets — Always verify with pnpm build. Secrets must never go in wrangler.toml.

Ce qui compte n’est pas leur contenu mais leur nature : ce sont des réductions de l’espace des décisions possibles. « Pas de rétrocompatibilité » supprime toute une famille de solutions qu’une IA propose spontanément — les alias de compatibilité, les couches d’adaptation, le code mort qu’on garde au cas où. En interdisant la famille entière, je n’ai plus à arbitrer cas par cas.

Une IA est fiable exactement dans la mesure où son espace de décision est petit.

Des verrous dans le code lui-même

// @agents lock true

Une ligne marquée comme ça ne se touche pas sans demander. Ce n’est pas une consigne qu’on espère respectée dans un fichier que personne n’ouvre — c’est un frein posé à l’endroit exact où la main va se poser.

C’est la différence entre un panneau à l’entrée du parc et une barrière devant le trou.

Le dépôt s’ouvre comme un vault

Le monorepo s’ouvre dans Obsidian. Obsidian n’affiche que les .md — donc on navigue la documentation, jamais le code. Chaque projet a son README, et un - [ ] écrit dans n’importe lequel de ces README remonte tout seul dans le tableau de bord à la racine.

Le contexte ne vit pas à côté du code, dans un wiki qu’on oublie de mettre à jour. Il vit dans le code, dans le même fichier qu’on modifie, et il se lit au même endroit.

Le symlink

C’est la partie que je n’ai vue nulle part ailleurs, et c’est celle qui règle le vrai problème.

Une IA travaille mieux quand elle connaît le contexte humain d’un projet : pourquoi telle décision a été prise, ce qui a été essayé, ce qui a échoué, ce que la personne cherche vraiment. Ce contexte-là, chez moi, est dans mon vault Obsidian personnel — au milieu de mon journal, de mes notes de séparation, des choses que je n’exposerai jamais.

La solution tient en un lien symbolique :

$ git ls-files -s vault
120000 9cce0314394a8f1a2468a4df63c58805d938bb93 0	vault/Atelier

Le mode 120000 est la signature d’un lien symbolique dans git. Ce que git versionne, c’est le chemin — jamais le contenu. Le dépôt peut devenir public demain matin sans qu’une seule ligne de mes notes intimes ne parte avec lui.

L’agent, lui, suit le lien sur ma machine et lit ce dont il a besoin. Il a le contexte complet en local, et il n’a rien à publier.

Un seul fichier, quarante octets, et le dilemme entre « donner du contexte » et « protéger sa vie privée » disparaît.

Ce que ça coûte

Il faut être honnête, sinon l’article ne vaut rien.

Les lois ralentissent. « Pas de rétrocompatibilité » veut dire que je casse des choses et que je répare en aval. C’est plus lent qu’un shim. Je le paie chaque semaine.

Le verrou agace. Il agace surtout quand j’ai raison et que je dois quand même m’autoriser moi-même. J’ai plusieurs fois été tenté de le retirer.

Documenter chaque erreur fatale est fastidieux. Une erreur en production doit produire une page de documentation avant d’être considérée réglée. C’est la loi que je respecte le moins bien.

Et le système lui-même peut se briser en silence. En préparant cet article, j’ai découvert que le fichier de règles auto-chargées commençait par cd ..--- au lieu de --- — un cd .. collé par accident devant le délimiteur du frontmatter. Résultat : le bloc de métadonnées ne s’ouvrait jamais, et le trigger: always_on qui garantit le chargement automatique n’était probablement pas lu. Quatre caractères de trop, dans le fichier chargé de faire respecter les règles.

C’est la meilleure illustration possible de la thèse. Une contrainte structurelle est plus forte qu’un vœu — mais elle reste une chose qu’il faut vérifier.

Ce qui reste humain

Ce qui distingue un bon logiciel écrit avec une IA d’un mauvais, ce n’est pas le modèle. Tout le monde a accès aux mêmes.

C’est le jugement de la personne qui l’encadre : savoir qu’une famille entière de solutions est mauvaise avant de l’avoir essayée, sentir qu’un module commence à porter des hypothèses qui n’appartiennent qu’à une seule application, décider qu’un système doit casser maintenant plutôt que pourrir six mois.

Ce jugement ne vient pas de l’IA, et il ne vient pas non plus des règles. Il vient d’ailleurs — de sept ans d’agence et de quinze ans à livrer des choses à des clients qui s’en fichaient complètement de mon architecture.

Les règles ne remplacent pas le jugement. Elles le rendent reproductible — y compris un mardi soir à 23 h.

Les lois, les règles et le symlink sont visibles dans le dépôt public : github.com/ZeFish/Standard.

Francis Fontaine est développeur et photographe à Québec. Il construit des systèmes modulaires pour le web (stnd.build) et pour le monde physique, et pense que la meilleure technologie est celle qui disparaît dans le quotidien.