Coder avec l'IA, sans lâcher le volant.
Un workflow de développement piloté par l'IA (Claude Code), bâti sur le TDD, l'architecture hexagonale et le DDD. L'agent guide, pose les bonnes questions, applique les conventions — le développeur décide.
J'ai construit mon propre plugin Claude Code : un pipeline en cinq phases qui transforme un besoin métier en code de production testé, relu et conforme à l'architecture. Ce n'est pas de la génération de code à l'aveugle — c'est une discipline outillée, avec des points d'arrêt où l'humain reprend la main.
Le pipeline en 5 phases
Chaque phase a un rôle précis et une sortie claire. Les deux premières ne produisent aucun code — on conçoit avant d'implémenter.
/brainstorm Conception & scénarios
Une idée brute devient un design validé et une liste complète de comportements attendus — par le dialogue, une question à la fois, avant la moindre ligne de code.
/mvp Découpage en lots de valeur
Les scénarios sont répartis en plusieurs MVP aux angles de valeur distincts. On choisit quoi livrer en premier, et dans quel ordre.
/tdd TDD piloté par l'acceptation
Le cœur. Chaque scénario devient un test. Cycle strict : nommer → test rouge → pause d'architecture → vert minimal → refactor. Un comportement à la fois.
/mutate Tests mutants
On injecte des bugs dans le cœur métier pour vérifier que les tests les attrapent vraiment. Un test qui ne tue aucun mutant ne protège rien.
/panel Panel de relecture pré-commit
Avant chaque commit, plusieurs relecteurs seniors indépendants passent le diff au crible — chacun sa spécialité, sans voir les trouvailles des autres.
Le panel de relecture
Avant le commit, 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.
L'humain garde le volant
Des pauses obligatoires : choix de design, guidage d'architecture. L'agent guide, il ne décide pas à votre place.
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 filet de relecture multi-regards avant chaque commit, pas après la mise en production.
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.