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 Continuous Integration Système automatique testant le code à chaque modification pour empêcher les bugs d'entrer en production. Le portique de sécurité à l'aéroport : chaque valise (code) est scannée avant de pouvoir monter dans l'avion (projet). 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 Fichiers de configuration cachés (ex: .bashrc) personnalisant l'environnement de travail de l'utilisateur. Les réglages du siège et des rétroviseurs : ils ne changent pas le moteur, mais adaptent le poste de pilotage au conducteur. , comme .bashrc ou .gitconfig) et la config globale (au niveau système) de mes agents.
Au départ, c’est un empilement de Hook Git Hook Script se déclenchant automatiquement avant ou après une action (ex: sauvegarde) pour effectuer des vérifications. Le bip de la ceinture de sécurité : une alerte automatique qui empêche de démarrer si la sécurité n'est pas là. 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 Model Context Protocol Standard open-source permettant de connecter des assistants IA à des outils ou données externes (fichiers, serveurs) de manière uniformisée. Une prise USB universelle pour les IA : un connecteur standard pour brancher n'importe quel outil sans adaptateur spécifique. , 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 Token Unité de base (morceau de mot) utilisée par l'IA pour traiter le texte. Sert d'unité de mesure pour la facturation et la limite de mémoire. Si l'IA était un télégraphe, le token serait le mot facturé. Plus le message est long, plus il coûte cher et prend de place. à 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 System Prompt Instruction initiale « invisible » définissant le comportement et le rôle de l'IA avant même la première question de l'utilisateur. Le briefing donné à un acteur en coulisses avant qu'il n'entre sur scène. Le public ne l'entend pas, mais il dicte le jeu. . 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.