Stabilisation et terrain d'essai | IdeAs — Augustin B
FR EN ES
Chapitre 7

Stabilisation et terrain d'essai

Consolidation des pratiques et mise à l'épreuve sur des projets réels.

Phase de consolidation (été–fin 2025)

Parmi mes chantiers de l’époque, ces trois‑là montrent comment j’applique le cadre (contexte, règles, outils) au quotidien :

Cette période fixe ma posture : cadrer, déléguer, vérifier. J’ai l’impression de devenir une sorte de chef d’orchestre…

Une application full-stack comme banc d’essai d’architecture

Cette appli web est mon terrain d’essai. Je veux un cadre où une IA peut intervenir sans tout casser.

Je passe par trois choses simples : rendre l’architecture explicite, poser des contrats entre modules, et renforcer les tests (pas seulement “est‑ce que ça marche ?”, mais “est‑ce que ça respecte l’architecture ?”).

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 terrain où l’IA peut proposer, où la CI et les tests filtrent, et où l’architecture dit vite si une proposition sort des rails.

Ce projet me sert de labo d’architecture. C’est là que je vois si mes idées sur le contexte, les règles et la qualité tiennent dans une vraie 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 : seulement les MCP utiles pour la tâche. Mes lanceurs sélectionnent des profils prédéfinis selon le besoin :

Je garde des menus avancés optionnels et je corrige quelques détails d’ergonomie pour enlever les frictions.

Je pose aussi une règle commune à tous les agents, au niveau système. C’est ma base globale, celle 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 préférer des règles simples, visibles, documentées, qui expriment clairement ce qui est hors limite.

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.

Ce ne sont pas que des préférences de style. Ce sont des garde‑fous contre les hallucinations très sûres d’elles, le scope creep (l’IA qui veut tout réparer au passage) et le bruit (commentaires ou métriques qui donnent l’illusion de la maîtrise).