Le sujet a changé de place. Je ne suis plus seulement en train d’inventer des façons de parler aux modèles. Je regarde ce qui tient quand ces règles reviennent dans différents projets.
Deux projets me servent de banc d’épreuve : une application web complète pour exposer les problèmes d’architecture, et ma configuration système, qui décide de ce qu’un agent peut lire, charger, appeler ou modifier.
Les essais d’orchestration et les garde-fous restent dans le décor. Ici, le sujet est plus terre-à-terre : qu’est-ce qui survit quand je dois travailler avec ces règles tous les jours ?
Une application full-stack comme banc d’essai d’architecture
Sur l’application web, le problème est simple : laisser l’IA intervenir sans perdre la forme du système.
Je commence par rendre les frontières visibles : contrats entre modules, tests d’architecture, et règles que la CI peut refuser.
Pour aider l’IA, je limite le contexte : parfois une seule couche (toute la logique métier), parfois une feature complète, du front au back. Ça garde le contexte petit et évite les dégâts.
Je ne cherche pas à “faire propre”. Je veux un cadre où l’IA peut proposer, où la CI et les tests filtrent, et où l’architecture dit vite si une proposition sort des rails.
Dans cette logique, j’ai aussi publié hex-validator, un validateur d’architecture open source. Je ne le présenterais pas aujourd’hui comme un outil abouti ; il montre surtout l’idée que je garde encore : certaines règles d’architecture peuvent sortir du prompt et devenir des checks exécutables.
C’est là que le discours sur le contexte devient vérifiable : soit les frontières tiennent, soit elles se fissurent dans la codebase.
Dotfiles et configuration globale : de la magie aux règles
En parallèle du projet web et de l’orchestration, je reprends tout ce qui pilote mes IA au quotidien : ma configuration système (dotfiles, comme .bashrc ou .gitconfig) et la config globale (au niveau système) de mes agents.
Au départ, c’est un empilement de hooks et de scripts. Ça marche tant que je suis seul, mais c’est fragile à maintenir. Je passe donc à des presets : des configs prêtes à l’emploi qui regroupent outils, droits et contexte selon la tâche (MCP, sandbox, permissions, etc.). Ça me permet de lancer un agent avec le bon niveau d’accès, sans tout reconfigurer à la main à chaque nouvelle session de travail.
Ces expérimentations m’ont aussi montré les limites des MCP. Pour objectiver ça, j’ai codé un petit plugin maison qui mesure le coût en tokens à l’ouverture d’une nouvelle session (ou d’un sous-agent). Constat : 15-20 % du budget partait dès le départ, et ce n’était pas le prompt système. Le poids venait surtout de l’empilement des MCP, autour de 36 000 tokens sur 200 000.
J’ai donc basculé vers du chargement à la demande : au lieu d’ouvrir chaque session avec tout le menu d’outils, je démarre avec le minimum utile. Pour une tâche simple, aucun MCP. Pour une recherche, seulement les outils de documentation ou de recherche. Pour une passe front-end, les outils front-end, et Playwright seulement quand il faut vraiment voir la page. Le but n’est pas d’avoir une belle matrice de profils : c’est de ne pas payer en contexte pour des outils qui ne serviront pas.
Concrètement, mes lanceurs sélectionnent des profils mesurés au démarrage : Base, 0 MCP (~0 token)
; Minimal, Context7 (~1 300 tokens) ; Recherche, Context7 + Exa (~3 000 tokens) ; Front-end 1,
ShadCN (~5 500 tokens) ; Front-end 2, Context7 + ShadCN + Playwright (~14 000 tokens) ; puis
d’autres profils, back-end, testing ou exploration (Firecrawl, etc.), chargés à la demande. Ces
chiffres ne sont pas des benchmarks universels. Ils me servent à comparer mes propres lanceurs et
à voir quand un profil charge trop avant même que l’agent commence.
Je finis donc par séparer deux niveaux : les règles de projet, qui dépendent de la codebase, et une base globale, qui s’applique partout.
Attention : ce nettoyage ne remplace pas les fichiers de contexte des projets (
AI.md). Il les complète au niveau du système. C’est la base sur laquelle les projets s’appuient.
Le cap reste le même : éviter d’empiler de la logique difficile à maintenir, et rendre les limites assez visibles pour qu’un agent ne les invente pas en chemin.
Je formalise aussi quelques règles de collaboration : chercher la doc avant d’inventer une API, ne pas deviner quand l’information manque, éviter les estimations “magiques”, rester focus et marquer le reste avec des TODO/FIXME plutôt que tout corriger en chemin.
Au fond, je cherche surtout à réduire les zones grises. Moins l’agent doit deviner, moins il compense par de l’assurance mal placée.