Les garde-fous
Tests, règles et contraintes pour garder le contrôle.
Introduction : de l’architecture à la méthode
Dans les chapitres précédents (L’odyssée du contexte), j’ai testé plusieurs façons de charger et passer le contexte aux agents. J’ai fini par revenir à quelque chose de plus pragmatique en voyant l’impact direct sur le code.
J’avais une constitution claire et des fichiers d’instructions bien tenus. Sur le papier, tout était carré. Dans le code, c’était autre chose : l’IA génère, et parfois elle se trompe. Il me fallait des garde‑fous, pas des promesses.
Restaient les questions du quotidien : comment travailler avec les agents sans retomber dans l’usine à gaz ? Ce chapitre raconte comment j’ai posé des rails qualité pour que chaque itération renvoie un feedback immédiat.
État des lieux
À cette date, je vis déjà avec ces outils au quotidien. Mon setup contient :
- des prompts réutilisables (commandes, skills) ;
- une constitution projet unique (règles et cadre partagé) ;
- un orchestrateur qui sait lancer des agents et boucler le feedback avec les sous‑agents ;
- une CI robuste qui ne laisse passer que les PRs dont les tests et le build sont OK ;
- des scripts et des mappings symboliques pour générer les fichiers de contexte pour plusieurs outils.
Je jongle entre architecture, pilotage technique et outillage. Je code encore, mais surtout pour solidifier l’écosystème d’automatisations.
Le vrai sujet n’était plus d’empiler des consignes, mais de rendre la qualité vérifiable.
Vers des outils d’assurance qualité et d’orchestration
À partir de là, je cherche un signal simple : l’IA propose, le système répond. Si ça casse, je veux un retour clair, et de quoi corriger tout de suite. L’objectif n’est pas d’éduquer le modèle à coups de prompt, mais de mettre les limites dans le code.
On parle souvent de DX (Developer Experience) pour les humains. Moi, je parle d’AIX : la même idée, mais pour les IA. Quand je configure un linter, un message d’erreur ou un script, je le fais pour qu’une IA comprenne et se corrige seule. Si le retour est clair, elle repart. S’il est vague, elle patine et répète les mêmes erreurs.
La boucle opérationnelle (du prompt aux garde-fous).
- Je formule la tâche (souvent en termes simples).
- L’IA planifie et explore la codebase, repère les patterns existants, propose une implémentation.
- Elle modifie le code et lance les tests locaux (scripts outillés).
- Elle sauvegarde et commit via Git.
- Mes hooks et pipelines se déclenchent automatiquement : linters, types, règles d’architecture, tests unitaires/intégration.
- Le feedback est renvoyé à l’IA (logs, erreurs, diffs), qui corrige et recommence jusqu’à validation.
- La CI rejoue la même batterie de contrôles (et quelques vérifications plus lourdes) avant d’autoriser la PR/merge.
Concrètement, voilà ce que j’ai mis en place :
- Linting et formatage automatisés déclenchés en local et dans la CI ;
- Type checking strict (TypeScript en mode strict) ;
- Règles d’architecture automatisées (Dependency Cruiser) ;
- Tests unitaires et d’intégration pensés pour les agents ;
- Git hooks qui notifient les agents et déclenchent analyses et suggestions ;
- Pipelines CI qui exécutent des vérifications avancées et remontent des tickets/actions.
Note (aujourd’hui) : mes workflows ont encore évolué. J’ai maintenant des hooks qui se déclenchent dès qu’un fichier est écrit ou modifié dans Claude Code (lint/typecheck). Le feedback est plus rapide, mais moins complet que les vérifications au commit et en CI.
J’ai épuré et publié le validateur d’architecture en open source : hex-validator. C’est un outil conçu pour mes choix d’architecture spécifiques, mais les règles et patterns peuvent servir d’inspiration.
L’idée est simple : laisser l’IA proposer, mais lui imposer un système qui valide, bloque ou renvoie un retour exploitable.
On verra la suite dans une phase de stabilisation plus longue, où ces garde‑fous sont mis à l’épreuve sur des projets réels.