Si tu as 30 secondes. La mémoire versionnée d'un workflow Claude Code a un effet de bord que personne ne signale : une règle mémorisée qui colle au symptôme de manière plausible court-circuite la vérification, même quand elle ne s'applique pas au compteur précis que tu regardes. Je me suis coûté vingt minutes d'exploration SQL la semaine dernière parce qu'une règle de la forme du bug — sans en être le bug — m'a permis de sauter la lecture de la vue qui produisait le chiffre. Utile si tu as commencé à faire confiance à tes propres fichiers de feedback.
Un écart de 77
Le 22 avril 2026, 11 h 14. Je suis sur la page /crm/eleves à relire les compteurs d'onglets avant un point avec notre assistante administrative. L'onglet « Inscrits » affiche 785. L'onglet « Atelier Alésia » affiche 312, « République » 278, « Villiers » 272. J'additionne les trois : 862. Soixante-dix-sept inscrits dans un atelier de plus que ce que prétend le compteur Inscrits. Les chiffres sont côte à côte sur l'écran, comme les chiffres le sont juste avant de te gâcher la matinée.
Mon premier réflexe n'est pas d'ouvrir le SQL. C'est d'interroger l'agent. Je colle la capture, je décris l'écart, j'ajoute — trop vite — « c'est sans doute à cause de la règle 1 inscription = N places, non ? Les gens dans deux ateliers sont comptés deux fois dans les onglets atelier. » L'agent acquiesce. L'explication est plausible. La règle existe. Elle a même son fichier mémoire : feedback_modele_inscription_places.md. J'ouvre l'éditeur SQL quand même, parce que c'est la discipline, et je passe vingt minutes à joindre inscriptions à elle-même, à chercher des contacts présents dans deux ateliers en même temps.
Il y en a onze. Onze n'explique rien. L'écart est de soixante-dix-sept.
Je referme le SQL, je lis la vue qui alimente réellement les onglets atelier — v_eleves — et je vois, ligne trois, une clause DISTINCT contact_id et une colonne array ateliers_effectifs[]. La vue déduplique par contact. Elle compte des personnes, pas des places. La règle 1 inscription = N places, vraie dans la table inscriptions, ne s'applique pas à ce compteur parce que ce compteur ne voit jamais inscriptions directement. Il lit une vue qui a déjà collapsé les places en personnes.
Le vrai bug est ailleurs : l'onglet « Inscrits » filtre sur statut = 'inscrit' tandis que les onglets atelier filtrent sur statut IN ('inscrit', 'ancien_eleve'). Soixante-dix-sept ancien_eleve qui apparaissent dans les onglets atelier et pas dans l'onglet Inscrits. Un écart de filtre statut. Cinq minutes pour le trouver, une fois dans la bonne portion de code.
Le bug a pris cinq minutes. Y arriver en a pris vingt-cinq — et vingt de ces minutes ont été passées à confirmer une règle mémorisée qui ne s'appliquait pas.
Ce qui vient de se passer
Je reviens sur le piège. L'agent n'a pas menti ; il a confirmé une hypothèse que je lui ai fournie. Le fichier mémoire n'est pas faux ; il décrit un invariant réel du modèle de données. L'erreur est en amont — au moment où j'ai cadré le problème par une règle avant de lire le code qui produisait le chiffre.
Les règles mémorisées portent un risque spécifique dans les workflows agent : elles offrent une explication plausible qui ne coûte rien à invoquer. La règle est là, elle a un nom, elle a été validée, et elle épouse vaguement la silhouette du symptôme. La friction cognitive d'ouvrir la vue SQL est non nulle ; la friction cognitive de « la règle dit X, donc le bug doit être une manifestation de X » est nulle. Tu prends le chemin moins cher. La règle se vend toute seule.
C'est un mode de défaillance différent de celui que j'avais décrit dans l'article précédent sur la mémoire. Là, la défaillance était l'agent qui confabulait sur des faits ayant dérivé dans le code. Ici, la défaillance, c'est moi qui utilise une règle stable et juste comme substitut à la vérification, parce que la règle épouse la silhouette du bug. Le dispositif de trace est le même. La discipline qui le rend utile est différente.
Il a fallu que j'écrive un feedback pour moi, pas pour l'agent.
La règle que j'applique désormais
Le feedback que j'ai ajouté cet après-midi-là, dans ~/.claude/agent-memory/feedback_memoire_court_circuite_verification_code.md, est court :
Why: Une règle mémorisée s'applique à un endroit précis du modèle. Elle ne s'applique pas automatiquement à tous les compteurs qui affichent des données reliées. Sauter la vérification parce que la règle « ressemble au bug » m'a coûté 20 minutes d'exploration SQL le 22 avril.
How to apply: quand un chiffre UI semble incohérent et qu'une règle mémorisée semble expliquer l'écart, ouvrir le code qui produit le chiffre avant d'invoquer la règle. Lire la requête SQL ou la vue utilisée. Si la vue fait un
DISTINCTou route via une source dédupliquée, la règle « N places par personne » ne s'applique pas à ce compteur précis. Lire d'abord, invoquer ensuite.
C'est une règle sur les règles. Le genre de feedback qui ne réduit pas les erreurs directement — il réduit les erreurs de second type, celles où une règle juste est mal appliquée parce que le symptôme a une silhouette plausible.
Ce que tu peux copier
Trois éléments concrets que je tiens désormais comme discipline :
- Lire le producteur avant d'invoquer la règle. Quel que soit le compteur, le solde ou l'agrégat que tu investigues, ouvre la vue SQL, le handler d'API ou le sélecteur React qui le produit. Sinon, tu ne vérifies pas — tu apparies une silhouette à une silhouette.
- Audite tes propres questions à l'agent. Quand tu cadres une investigation par un « c'est sans doute à cause de X », regarde comment l'agent acquiesce. Si ton hypothèse nomme une règle que l'agent a en mémoire, l'acquiescement est gratuit. L'hypothèse fait le travail ; l'agent appose son tampon. Ce n'est pas une collaboration, c'est du biais de confirmation blanchi via une interface aimable.
- Écris le méta-feedback. Quand tu découvres que tu as sauté la vérification parce qu'une règle avait approximativement la bonne forme, c'est un feedback qui mérite d'être écrit. Il s'applique plus largement que le cas spécifique. Le mien m'a rattrapé au moins deux fois depuis — une fois sur une détection de doublon qui ressemblait à la règle couple-vs-doublon mais ne l'était pas, une fois sur un compteur qui ressemblait à une dérive de snapshot tarif appliqué mais venait d'un REFRESH périmé.
La discipline plus profonde, c'est qu'une règle mémorisée est une hypothèse, pas un verdict. Elle ne gagne son rang que lorsque le code qui produit la valeur la confirme. Traite-la comme une stack trace venue d'un collègue — pointeur utile, exige reproduction.
Coda
Ce que je remarque, en regardant en arrière les quatre semaines de construction de Rembrandt avec Claude Code, c'est que les règles s'accumulent plus vite que la discipline de vérifier leur application. Mon dossier mémoire compte cinquante-sept fichiers de feedback aujourd'hui. Chacun est opposable. Chacun est daté. Chacun est juste quelque part. Aucun n'est juste partout, et le terrain où il est juste est plus contraint que l'espace de symptômes qu'il a l'air de couvrir.
Cette asymétrie est le méta-piège. Elle passe à l'échelle avec le nombre de règles. Plus la mémoire est riche, plus souvent une règle épousera la forme d'un bug qu'elle n'explique pas réellement. Le remède n'est pas moins de règles — moins de règles, c'est plus de dérive. Le remède, c'est l'habitude de lire le producteur avant de citer la loi.
Les cinq minutes que j'ai passées à trouver le vrai bug, ce matin-là, étaient calmes. Les vingt-cinq d'avant étaient un roman policier que j'écrivais seul, l'agent fournissant l'alibi. Je n'ai aucune animosité envers l'agent. J'ai la conscience légèrement froide que tout outil qui te répond te dira ce que tu lui as apporté, et que ce qui te protège de toi-même, c'est le fichier que l'outil n'a pas écrit.
Code compagnon : rembrandt-samples/claude-md/feedback-template.md — la structure des fichiers feedback_* avec le meta-feedback de cet article comme exemple, licence MIT.
Top comments (0)