Un agent de code écrit vite. Il lui arrive aussi d'oublier les tests ou de pousser une branche que personne n'a relue. Le rapport DORA 2025 l'a mesuré : l'IA augmente le débit des équipes, et leur instabilité avec, sauf chez celles qui gardent des principes clairs, des petits lots et du feedback réel.
Kaizen est le plugin que j'ai écrit pour outiller ces disciplines dans Claude Code, sur tout le SDLC, du besoin jusqu'à la production. Il répond aussi à la question que je laissais ouverte en avril dans ma cartographie SDD, Compound Engineering et BMAD : peut-on combiner la rigueur d'une spec et une boucle d'apprentissage ?
L'essentiel
- Quoi : Kaizen est un plugin Claude Code open source (MIT) qui couvre tout le cycle de développement : besoin, plan, code, revue, PR, déploiement, monitoring, post-mortem.
- Chiffres clés : 23 skills, 21 agents en lecture seule, 6 hooks, une CLI Node.js sans dépendance npm. Version 3.2.1 du 7 octobre 2026.
- Ce qui le distingue : les règles critiques sont des hooks. Claude ne peut pas finir sur des tests rouges, pousser sans revue réelle, ni déployer en production sans un code que vous tapez.
- D'où il vient : la boucle du Compound Engineering d'Every, la constitution de Spec Kit, les pratiques de DORA et du NIST SSDF.
- Pour qui : les équipes sur Claude Code qui veulent des garanties de qualité jusqu'à la production.
Le SDLC, phase par phase
Chaque phase classique du cycle a sa commande. La dernière colonne indique si un contrôle en code l'impose.
| Phase | Commande /kaizen:… | Imposé par du code |
|---|---|---|
| Principes | constitution : 5 à 9 règles, chacune avec un contrôle | en partie |
| Besoin | brainstorm : exigences R1…, exemples d'acceptation AE1… | en partie |
| Conception | plan (menaces STRIDE, rollback, tranches de la taille d'une PR), puis doc-review | en partie : plan check vérifie que chaque exigence est couverte |
| Code | work (test d'abord), debug | oui : pas de fin de tour sur des tests rouges |
| Vérification | review, reviewers choisis selon le diff | oui : push refusé sans revue réelle |
| Livraison | ship, watch-pr, release | oui : taille de PR et SemVer vérifiées |
| Déploiement | deploy avec vos commandes, rollback | oui : code d'approbation pour la production |
| Exploitation | monitor : seuils du plan, incidents datés | en partie |
| Amélioration | learn, postmortem, metrics (DORA) | en partie |
Perdu en route ? /kaizen:help regarde où en est le dépôt et donne la prochaine commande.
Les règles critiques sont des hooks
Écrire « lance les tests avant de terminer » dans CLAUDE.md marche neuf fois sur dix. La dixième, la session est longue, le contexte compacté, et Claude annonce que tout va bien sur une suite rouge. Kaizen place donc ces règles dans des hooks, que Claude Code exécute à chaque appel d'outil.
- Avant un commit, un scan refuse une trentaine de types de clés et de jetons.
- Avant un push, la branche est refusée tant qu'une revue n'a pas été enregistrée, avec la preuve que les agents reviewers ont vraiment tourné.
- En fin de tour, tests, lint et typage doivent passer.
- Pour la production, seul un code que vous tapez débloque le déploiement.
Une boucle qui apprend
C'est l'apport du Compound Engineering. Ce qu'un cycle apprend (learnings, ADR, post-mortems) est écrit dans le dépôt, et un agent le relit avant chaque plan, revue ou debug. Les déploiements, rollbacks et incidents deviennent des tags git datés, d'où des métriques DORA calculées sur des événements réels. /kaizen:metrics distingue aussi les learnings lus de ceux appliqués dans un commit. Un learning que personne ne réutilise signale une boucle qui ne tourne pas.
La cérémonie se règle par profil : lean pour un prototype, standard pour un produit en production, full pour un domaine réglementé. Les contrôles en code restent actifs dans les trois.
L'essayer
/plugin marketplace add Lingelo/dojo
/plugin install kaizen@dojoKaizen est conçu pour Claude Code, dont il exploite les hooks. Il faut Node.js 18 ou plus, git, et gh pour les PR. Dans votre dépôt, lancez /kaizen:setup audit : il note la maturité SDLC du projet sur cinq axes et propose d'ajouter ce qui manque. Le code et la doc sont sur GitHub. Pour le fonctionnement des plugins, voir mon article sur les marketplaces Claude Code.
Questions fréquentes
- Qu'est-ce que Kaizen pour Claude Code ?
- Kaizen est un plugin open source (licence MIT) qui donne à Claude Code un SDLC complet : cadrage du besoin, plan, code test-first, revue multi-agents, pull request, déploiement surveillé, incidents et apprentissages. Il compte 23 skills, 21 agents en lecture seule et une CLI Node.js sans dépendance. La version 3.2.1 date du 7 octobre 2026.
- Qu'est-ce qu'un SDLC IA ?
- Un SDLC (Software Development Life Cycle) est l'ensemble des phases qui mènent un logiciel du besoin à la production : cadrage, conception, code, vérification, livraison, déploiement, exploitation et amélioration. Un SDLC IA outille ces phases pour un agent de code, avec des contrôles adaptés à un exécutant rapide qui peut oublier une consigne.
- Quelle différence entre Kaizen et Compound Engineering ?
- Kaizen dérive du plugin Compound Engineering d'Every (MIT), dont il reprend la boucle d'apprentissage. Il y ajoute des contrôles appliqués par des hooks, la constitution de Spec Kit, le déploiement, le monitoring et les métriques DORA. Kaizen est conçu pour Claude Code, dont il exploite les hooks.
- Comment installer Kaizen ?
- Dans Claude Code, ajouter la marketplace avec /plugin marketplace add Lingelo/dojo, puis installer le plugin avec /plugin install kaizen@dojo. Kaizen demande Node.js 18 ou plus et git, plus gh pour les pull requests. Dans un dépôt, on commence par /kaizen:setup.
- Kaizen peut-il déployer en production tout seul ?
- Non. Kaizen déploie uniquement avec les commandes déclarées par l'équipe, et pour un environnement protégé l'utilisateur doit taper lui-même un code d'approbation valable 30 minutes. Le mode autopilot s'arrête à une pull request prête et ne merge ni ne déploie jamais.
