L'autonomie jusqu'où vous voulez.
Les garde-fous, toujours.
Un workflow de développement piloté par l'IA (Claude Code), bâti sur le TDD, l'architecture hexagonale et le DDD. L'agent écrit, teste, refactore, se relit et travaille en flotte. Ce qui se règle, projet par projet, c'est jusqu'où il va seul.
J'ai construit mon propre plugin Claude Code : un pipeline qui transforme un besoin métier en code de production testé, relu et conforme à l'architecture — jusqu'à faire travailler plusieurs agents en parallèle, supervisés, mesurés, relancés après incident. Ce n'est pas de la génération de code à l'aveugle : c'est une discipline outillée, dont le niveau d'autonomie est un curseur que l'on pose là où on veut.
Le pipeline en trois temps
Six commandes, trois moments : on cadre, on implémente, on vérifie. Le premier temps ne produit aucun code.
Cadrage
Une idée brute devient un design validé, une liste de comportements attendus et un ordre de livraison. Aucune ligne de code n'est écrite ici.
-
/brainstormConception & scénarios Le dialogue, une question à la fois, jusqu'au design validé. -
/mvpDécoupage en lots de valeur Plusieurs MVP aux angles distincts : on choisit quoi livrer en premier.
Implémentation
Chaque scénario devient un test. Cycle strict : nommer → test rouge → vert minimal → refactor, un comportement à la fois. Les pauses de décision se posent ou se lèvent selon le contexte.
-
/tddTDD piloté par l'acceptation Le cœur : le test est la spécification, le design émerge du test. -
/tdd-medicalVariante logiciel médical Même cycle, plus la traçabilité exigences / risques (IEC 62304, ISO 14971).
Vérification
On éprouve les tests eux-mêmes, puis on passe le diff devant un panel de relecteurs indépendants. À chaque commit, avant chaque push, ou au rythme qui vous convient.
-
/mutateTests mutants Des bugs injectés dans le cœur métier : un test qui n'en tue aucun ne protège rien. -
/panelPanel de relecture Des relecteurs seniors en parallèle, chacun sa spécialité, aucun ne voit les autres.
Le curseur d'autonomie
L'autonomie n'est pas un interrupteur, c'est un cran — et il se choisit par contexte : prototype, reprise de dette, code de production, logiciel médical. Le cycle ne change pas ; c'est la longueur de laisse qui change.
Assisté
L'agent écrit le test, écrit le code, refactore et trace. L'humain tient les pauses laissées actives : choix de design, guidage d'architecture, détermination de risque. Rien de structurant ne se décide sans lui.
Flotte
Plusieurs agents avancent en parallèle sur des lots qui ne se marchent pas dessus, sous la supervision d'un orchestrateur. Le débit change ; le cycle, les pauses et les portes de qualité ne changent pas.
Zéro contact
La boucle tourne seule sur une liste de critères déjà validée : l'agent tranche d'après le design figé en amont, relance la suite de tests pour se vérifier, se répare après un échec, redécoupe un critère trop ambitieux. Se branche quand le contexte s'y prête.
Quel que soit le cran, les portes de qualité restent les mêmes : tests d'abord, score de mutation sur le cœur métier, panel de relecture au moment que vous choisissez. On règle l'autonomie, jamais la discipline.
Ce que la flotte fait seule
Au cran « flotte », une septième commande — /orchestrate — met plusieurs agents
sur des lots disjoints et les surveille. Voici ce qu'elle gère sans qu'on lui demande : c'est ce qui rend le
parallélisme tenable plutôt qu'ingérable.
Dispatch & supervision
N agents en parallèle, un board d'état partagé, un lot par agent
Reprise après crash
Agent planté détecté, écran capturé, agent relancé, lot réassigné
Recyclage de contexte
Entre deux lots, l'agent repart à neuf — rebriefé, jamais saturé
État sur disque
On coupe tout, on reprend : la mémoire vit dans des fichiers
Télémétrie native
Coût, tokens, durées, erreurs — par agent, en continu (Grafana)
Le panel de relecture
Quand vous le déclenchez — avant un commit, avant un push, avant une PR — le diff passe devant un panel de relecteurs seniors lancés en parallèle. Chacun a son périmètre et ne voit pas les trouvailles des autres — l'indépendance fait la couverture. Le panel ne corrige rien : il rapporte, trié par sévérité. C'est vous qui décidez.
Architecte
Frontières hexagonales, règles de dépendance
Domaine (DDD)
Agrégats, invariants, langage métier
QA
Tests manquants, cas limites, zéro mock
Correction
Bugs, null / bornes / concurrence, async
Lisibilité
Noms complets, zéro abréviation, zéro region
Simplicité
YAGNI, duplication, code mort
Sécuritéconditionnel
Injection SQL, validation, secrets
Les principes non-négociables
Le test est une spécification
Un critère d'acceptation lisible par un non-développeur — pas un détail technique caché.
Outside-In
On part du besoin (le cas d'usage), le design émerge du test, jamais l'inverse.
Classicist, zéro mock
Objets réels, comportements réels. On ne simule que l'externe : base, bus, API.
La plus petite transformation
On avance pas à pas (TPP). Si un switch surgit trop tôt, le test était trop ambitieux.
Architecture hexagonale
La logique métier vit dans le Domaine. L'infrastructure n'est qu'un adaptateur.
La pause est un réglage
Les points d'arrêt sont placés là où la décision coûte cher — parce qu'on les veut, pas parce que l'agent ne saurait pas faire sans.
L'état vit sur le disque
Ce qui n'est pas écrit dans un fichier n'existe pas. C'est ce qui rend le parallélisme et la reprise possibles.
Ce que ça produit
La discipline n'est pas une fin en soi. Voici les résultats concrets sur la base de code.
Règles de dépendance qui tiennent dans le temps — Domaine ↛ Infra, Read ↛ Write.
Score de mutation visé sur le cœur métier : des tests qui détectent réellement les régressions.
Un panel de relecteurs indépendants sur le diff, déclenché quand vous voulez — pas après la mise en production.
Plusieurs lots en vol en même temps, avec la même discipline appliquée sur chacun.
Coût, progression et erreurs mesurés en continu par agent — pas devinés en fin de course.
Variante médicale : exigences ancrées et risques analysés (IEC 62304 / ISO 14971).
Ce qui reste dans la boîte à outils
Cette page montre la démarche — les phases, les principes, les résultats. Les commandes elles-mêmes — leurs règles précises, les standards maison, les prompts des relecteurs — restent privées. La méthode se montre ; la recette reste maison.
Envie de voir ce que ça donne sur votre code ?
Discutons d'une mission, d'un audit ou d'un accompagnement à l'intégration de l'IA dans vos pratiques.