AIDiveLe plan que personne n'a relu
Le Elephant-Goldfish Model (EGM) de Google est un plugin gratuit pour Claude Code qui fait relire ton plan par des relecteurs sans mémoire avant que la moindre ligne de code soit écrite. Nous l'avons installé et nous avons mené une vraie fonctionnalité de notre propre appli du plan au code qui marche : un système de réservation pour une liste de cadeaux familiale, construit avec Next.js et une base Notion, sur une copie du dépôt.
Le planificateur a trouvé la race condition tout seul. Les deux trous qui comptaient, il ne les a jamais vus : les parents pouvaient lire qui avait réservé quoi dans les logs de leur propre hébergement, et un cookie enregistré dans le navigateur pouvait être rejoué pour annuler la réservation de quelqu'un d'autre. Seuls les relecteurs sans mémoire les ont trouvés. La fonctionnalité construite à partir du plan relu a donné un seul gagnant sur les trente courses pour le dernier cadeau, face à un faux Notion. Et sur un petit correctif, la relecture coûte bien plus cher que le correctif lui-même : on la saute.
Le workflow tient en cinq étapes : installer, brainstormer et rédiger, relire, résoudre, construire. La dernière section donne la règle pour tout sauter.
Ce qu'est EGM, et l'installation en deux commandes
Quand tu demandes à Claude Code de planifier une fonctionnalité, l'agent qui a écrit le plan est le même que celui à qui tu demandes de le vérifier, et il ne voit pas ses propres angles morts. EGM, le Elephant-Goldfish Model, est le plugin gratuit de Google pour ce problème. Le dépôt précise clairement que ce n'est pas un produit officiellement supporté par Google.
L'éléphant est l'agent avec qui tu parles : il garde toute la conversation et écrit le plan avec toi. Les poissons rouges sont des agents relecteurs sans mémoire. Ils ne lisent que le plan et ton code, comme un collègue qui relit une pull request sans avoir assisté à la réunion de conception. Ils peuvent lire ton code mais pas le modifier, ils ne voient pas les notes de ton projet, et tu as le dernier mot sur chaque choix qu'ils soulèvent. L'idée vient de Dave Rensin, qui a écrit que si nous ne faisons pas attention, nous n'écrivons pas seulement du code plus vite, nous produisons nos erreurs en série.
L'installation se fait depuis le dossier de ton projet, avec deux commandes :
claude plugin marketplace add google/elephant-goldfish-model
claude plugin install egm@egm --scope project
La première ajoute le dépôt de Google comme marketplace de plugins, une liste d'où Claude Code peut installer des plugins. La seconde installe le plugin pour ce projet seulement. Les deux ont renvoyé une coche verte en cinq secondes environ ; ouvre une nouvelle session pour que le plugin se charge. La doc demande Claude Code 2.1.271 ou plus, parce que les relecteurs s'appuient sur le réglage omitClaudeMd qui masque les notes de ton projet.
Ajoute ensuite une ligne à ton CLAUDE.md pour que les rapports atterrissent dans un seul dossier plutôt qu'à la racine du dépôt :
EGM artifact directory: docs/egm
Les commandes ne coûtent rien tant que tu n'en tapes pas une : aucune ne se charge toute seule dans ta session. La limite, c'est que les poissons rouges ne font que lire des documents. Ils ne lancent pas ton appli, et ils utilisent le même modèle que toi, donc ils peuvent partager ses angles morts.
Le brainstorm et le draft sur une vraie fonctionnalité
Le brainstorm sert au moment où tu t'apprêtes à construire quelque chose dont une mauvaise décision te coûtera cher plus tard. Notre appli est une liste de cadeaux familiale : les proches cochent ce qu'ils ont acheté, et la liste vit dans une base Notion. Tout a tourné sur une copie du dépôt, sans accès à la vraie liste.
La fonctionnalité : permettre à un proche de réserver un cadeau pour que personne n'achète deux fois le même, empêcher les parents de voir qui a réservé quoi, et autoriser l'annulation. Tu tapes la commande de brainstorm suivie de la fonctionnalité en une phrase :
/egm:egm-brainstorm Let a relative reserve a gift on the list so two people never buy the same one. Parents must not see who reserved what. A reservation can be cancelled.
Avant de poser la moindre question, il a lu le code et fait remarquer que l'appli ne sait pas qui est qui, puisque tout le monde se connecte avec un seul mot de passe partagé. Il pose ensuite des questions en plusieurs tours, et un petit essaim de poissons rouges examine l'idée avant qu'une section soit écrite. Tu réponds en product owner. Nous : un mot de passe partagé, un proche ne saisit qu'un prénom, et rien qui le nomme ne va là où les parents regardent. L'essaim a soulevé un point que nous n'avions pas nommé : l'ancienne route d'édition qui laisserait encore n'importe qui modifier une quantité à la main.
Le planificateur a aussi nommé lui-même la race condition : des proches qui appuient sur réserver au même moment. Une race condition, c'est quand deux requêtes lisent la même ancienne valeur et écrivent toutes les deux, si bien qu'une mise à jour est perdue sans bruit, et la doc de Notion n'offre aucun moyen d'ajouter un nombre de façon atomique.
Ensuite, /egm:egm-draft docs/egm/concepts_brief.md écrit le document de design section par section : le plan écrit de chaque fichier avant tout code. Il s'est arrêté quinze fois pour demander. Tu valides une section, ou tu choisis entre des options d'architecture, chacune listée avec sa façon d'échouer. Un choix portait sur l'endroit où vit la réservation d'un proche ; nous avons pris un cookie signé dans son propre navigateur, pour que rien qui porte son nom n'arrive au serveur. Le draft a même admis dans ses propres limites connues que son correctif pour la course ne marchait pas, puisque les deux proches liraient la même valeur. Tu finis cette étape avec un document de design approuvé dans ton dépôt.
La relecture à l'aveugle : neuf relecteurs, deux trous que le planificateur n'a pas vus
La relecture sert quand toi et ton agent pensez tous les deux que le plan est solide, ce qui est exactement le moment où l'on ne voit pas ce qui manque. Tu tapes /egm:egm-review docs/egm/gift-reservations.md ; il demande si les relecteurs doivent lire autre chose, puis un mode. Le mode consolidé enchaîne toutes les étapes sans s'arrêter et rend une seule liste fusionnée d'actions.
Les cinq étapes sont : Initial Zoom Out Review (le design résout-il le bon problème), Comprehension Review (un nouveau venu comprendrait-il), Design Critique (structure et formulation), Intermediate Zoom Out Review, et Implementation Readiness, qui lit ton vrai code et vérifie chaque étape du plan contre lui. Chaque étape envoie de nouveaux poissons rouges qui n'ont jamais vu la conversation.
Sur notre design, il a lancé neuf relecteurs en 7 minutes 24 secondes sans toucher au document ; il a seulement écrit des rapports.
| Résultat de la relecture | Nombre |
|---|---|
| Sous-agents relecteurs | 9 |
| Constats bruts | 77 |
| Bloquant / Majeur / Détail | 1 / 42 / 34 |
| Actions fusionnées | 12 |
Il n'a pas trouvé la course : chaque constat sur la course reprenait l'aveu du planificateur lui-même. Il a trouvé deux trous que personne n'avait soulevés :
- Vie privée. Les parents possèdent le compte d'hébergement, et ses logs de requêtes, avec l'heure et le cadeau, leur permettraient de deviner qui a réservé quoi.
- Sécurité. Une copie enregistrée du cookie du navigateur pouvait être rejouée pour annuler la réservation de quelqu'un d'autre.
Il a aussi repéré des détails de code qui seraient apparus au moment du build, comme le fait que les paramètres de route du framework sont asynchrones, ou un build qui resterait cassé pendant une bonne partie du plan. Sur la course qu'il connaissait déjà, son correctif consistait à affaiblir l'objectif, un conseil à repousser.
Resolve : tu décides, même contre les relecteurs
L'étape resolve est celle où un tas de constats devient une décision. /egm:egm-resolve transforme chaque rapport en un seul tableau, chaque problème avec une suggestion : escalader, contester, décliner ou proposer un correctif. Tu acceptes un correctif ou tu le contestes avec ta raison, et il n'applique que ce que tu acceptes. Tu peux répondre toi-même aux problèmes escaladés et le laisser accepter automatiquement le reste.
Le nôtre a listé trente-sept problèmes, et resolve avait déjà vérifié les relecteurs contre le code : il a signalé un constat comme faux, un fichier déclaré inutilisé que la page de connexion importe encore.
Le gros sujet, c'était la course. Le Bloquant proposait de réécrire l'objectif en "reduces duplicate purchases, does not prevent them" (réduit les achats en double, sans les empêcher). Nous avons contesté et demandé exactement un gagnant, avec Notion comme seul stockage et aucun nom. L'agent a refusé de faire semblant : "Notion has no way to do that. It has no conditional write and no atomic increment." (Notion n'a aucun moyen de faire ça. Il n'a ni écriture conditionnelle ni incrément atomique.) Il a proposé plusieurs issues, et nous avons choisi un registre de réservations : une liste de notes anonymes sur la page Notion du cadeau, une par réservation, lues dans l'ordre pour décider qui l'obtient. Cela a aussi fermé le trou du cookie, puisque le navigateur ne contient plus que ta propre réservation : tu ne peux annuler que ce que tu as réservé.
La limite : ce correctif est arrivé après la relecture, donc aucun poisson rouge ne l'a lu, et il repose sur le fait que Notion garde un seul ordre pour des écritures simultanées, ce que sa doc ne promet pas. Le design dit de lancer son test de course sur une copie de la vraie base avant de livrer.
Build selon le plan dans une session neuve, puis test de la course
Le risque au moment du build, c'est un agent qui improvise en route et s'éloigne de ce que tu as décidé. Ouvre une session neuve, une nouvelle conversation qui ne connaît que ce qui est dans tes fichiers, et donne-lui le design :
Build the feature exactly to the approved design in docs/egm/gift-reservations.md; add tests.
La nôtre a travaillé seule pendant 7 minutes 56 secondes, modifié 24 fichiers, et la suite est revenue avec Tests 216 passed (216). Elle a signalé où elle s'était écartée du plan (une ancienne version du lanceur de tests, parce que la plus récente demandait un paquet plus récent) et a demandé avant de mettre à jour. Elle a aussi trouvé un test instable dans sa propre installation et l'a rendu prévisible.
Teste ensuite toi-même le chemin risqué, parce qu'une suite verte ne prouve que ce que quelqu'un a pensé à tester. Deux proches sur le dernier cadeau à la même seconde, trente fois avec des timings différents : à chaque fois, exactement une réservation est passée et l'autre a été prévenue que le cadeau était pris. La vue des parents montrait le cadeau complet sans aucun nom, et une annulation le remettait en jeu.
Ces tests tournent contre un faux Notion qui se comporte comme le vrai, sans ajout atomique et avec des délais aléatoires. C'est la règle générale pour les services externes dans les tests : on les simule, mais on rend la simulation aussi hostile que le vrai service. Avant de livrer, lance le test de course du design sur une copie de la vraie base ; le fichier de test documente même le cas où les deux proches gagneraient.
Quand la sauter : la règle
Sur la même appli, le README disait encore qu'il n'y avait aucune connexion alors que le site a un mot de passe : un correctif d'une ligne. Claude Code seul a vérifié le code et l'a corrigé en quelques secondes, sans aucun plugin.
| Chemin | Coût (prix API, Sonnet 5.5) | Durée |
|---|---|---|
| Correctif du README, Claude Code seul | $0.0455 | 10 s |
| EGM brainstorm, draft, review, resolve (avant tout code) | $7.10 | 32 min |
Le README de Google dit la même chose : "Use it when a feature needs design decisions before implementation. For a small, clear bug fix, use your normal coding workflow." (Utilise-le quand une fonctionnalité demande des décisions de design avant l'implémentation. Pour un petit bug clair, garde ton workflow de code habituel.) Sa FAQ ajoute que terminer le workflow ne prouve pas un gain de productivité, et un petit pilote sur un blog de code a trouvé que la relecture n'apportait rien sur une fonctionnalité qu'un plan simple gérait déjà.
EGM rapporte là où une erreur se cache en dehors de la conversation, comme les logs des parents et le cookie rejouable ici. Sur le problème que le planificateur connaissait déjà, la décision qui l'a réglé était la nôtre. La règle : avant de taper le prompt de build, demande-toi si une erreur ici touche les données de quelqu'un d'autre, la vie privée, les permissions ou l'argent. Si oui, lance la relecture avant de construire.
