Mikado Method : le skill qui transforme la méthode en règles non négociables

Dans l’article précédent, je montrais pourquoi la méthode Mikado est le cadre qui manque aux agents IA sur le code legacy. Trois modes de défaillance (l’avidité de changement, la dispersion du contexte, l’illusion du vert) et un mécanisme commun : un système entraîné à progresser, sans discipline pour s’arrêter.

Je terminais sur une promesse : un skill prêt à l’emploi.

Le voici : github.com/chaabani-anis/mikado-method. Cet article explique ce qu’il impose à l’agent, et pourquoi. Le suivant déroule un cas pratique complet.

Connaître la méthode ne suffit pas

On pourrait croire qu’il suffit d’écrire dans le prompt : « applique la méthode Mikado ».

Après tout, l’agent la connaît. Le livre d’Ellnestam et Brolund est dans ses données d’entraînement.

En pratique, ça ne tient pas. Sous la pression de l’objectif, l’agent garde ses patchs au lieu de reverter. Il oublie de noter les blocages dans le graphe. Il saute l’exploration pour « gagner du temps ». Exactement les dérives décrites dans l’article précédent : la méthode est connue, la discipline s’érode.

C’est tout l’enjeu du skill : transformer la méthode en règles non négociables, vérifiées à chaque étape.

Ce que le skill impose à l’agent

Cinq règles structurent le comportement de l’agent.

Règle 1 — Trois portes de confirmation.

L’agent s’arrête trois fois pour vous demander votre accord :

• Gate 1 : avant de toucher au moindre fichier, il reformule l’objectif en valeur métier. Vous validez ou vous corrigez.
• Gate 2 : quand un échec suggère un pattern (Ports & Adapters, Strategy…), il le propose avant de l’inscrire dans le graphe.
• Gate 3 : une fois le graphe stable, il vous demande le niveau de délégation avant d’écrire une ligne de code de production.

Règle 2 — L’exploration n’écrit pas de code.

Pendant l’exploration, l’agent tente des changements dans les vrais fichiers, capture les erreurs… puis revert tout. Le seul fichier qui survit, c’est le graphe Mikado.

Règle 3 — Un commit par feuille.

Chaque nœud implémenté = un commit atomique qui contient le code, les tests et le graphe mis à jour. L’historique git raconte le refactoring nœud par nœud. Fini les PRs de 147 fichiers : chaque commit se review en dix minutes.

Règle 4 — Les enfants d’abord.

Dans le graphe, un enfant est un prérequis de son parent. Plus c’est profond, plus c’est implémenté tôt. C’est le piège classique de Mikado, et le skill le verrouille.

Règle 5 — Validation obligatoire.

Le repo embarque validate-mikado.sh, un validateur qui vérifie la structure du graphe à chaque étape : chaque nœud porte le commit qui l’a découvert et l’erreur exacte qui l’a rendu nécessaire, les dépendances résolvent, pas de cycle. S’il échoue, l’agent s’arrête. Point.

Cette dernière règle répond directement à la dispersion du contexte : le graphe n’est pas une note dans le prompt, c’est un artefact versionné et vérifiable que l’agent relit à chaque itération.

Le vrai apport : le curseur de délégation

Gate 3 mérite qu’on s’y attarde. Une fois le graphe stable et validé, l’agent pose une question simple :

Exploration terminée — N vraies feuilles. Niveau de délégation ? (1 / 2 / 3)

• Niveau 1 : vous implémentez, l’agent guide et relit.
• Niveau 2 : l’agent implémente feuille par feuille, et attend votre « ok » après chaque commit.
• Niveau 3 : l’agent déroule tout en autonomie.

La question floue « est-ce que je fais confiance à l’agent ? » devient une décision graduée. Et réversible : vous pouvez commencer en niveau 2, constater que les premières feuilles sont propres, et passer en niveau 3.

Installation

git clone https://github.com/chaabani-anis/mikado-method
cd mikado-method

./install.sh claude            # Claude Code, projet courant
./install.sh claude --global   # Claude Code, tous les projets
./install.sh opencode          # opencode
./install.sh agents            # Codex, Cursor, Copilot, Gemini CLI…

Ensuite, demandez à votre agent un refactoring transverse. Le skill prend le relais, Gate 1 en tête.

La suite

Le cas pratique complet promis est publié : découpler un BillingService de son client SMTP, cycle par cycle, jusqu’aux huit commits finaux, avec un repo compagnon dont l’historique git est rejouable commit par commit.

Le repo est sous licence MIT : github.com/chaabani-anis/mikado-method. Les retours et les PR sont bienvenus.