Image: AI generated
Le 31 mars 2026, Anthropic a accidentellement publié les source maps du package npm Claude Code (v2.1.88). Une seule ligne manquait dans .npmignore.1 Ces 59,8 Mo de source maps ont exposé en clair quelque 512 000 lignes de TypeScript non obfusqué, réparties sur environ 1 900 fichiers. Anthropic a qualifié l’incident de « erreur humaine de packaging, pas une compromission de sécurité » et a recommandé aux utilisateurs d’épingler la version v2.1.87.
Dans le code examiné par la communauté, une seule fonction dans un fichier (print.ts) atteignait 3 167 lignes.2
L’outil le plus vendu au monde pour le codage assisté par IA — celui qui prétend vous donner les rênes sur votre code — n’avait lui-même aucune rêne sur son propre code.
Je ne soulève pas cette ironie pour railler. Bien au contraire. Cet incident constitue la réponse la plus limpide à une question à laquelle je peinais depuis longtemps à répondre clairement.
« Reins Engineering, c’est finalement du harness engineering, non ? »
Bonne question. Question acérée, même. Les deux se ressemblent indéniablement. Tous deux se situent hors du modèle. Tous deux sont des structures non-modèle construites en code. Tous deux empêchent l’agent de faire n’importe quoi. Alors le soupçon — « les rênes ne sont-elles pas une simple composante du harnais ? » — est légitime.
Pendant un moment, je ne savais pas y répondre clairement. Quand j’ai trouvé la réponse, j’ai réalisé qu’elle constituait elle-même la description la plus précise de ce qu’est Reins. Et l’incident de fuite en est la démonstration concrète.
D’abord : les deux ne s’opposent pas
Pensez à l’équipement équestre. La selle et la bride sur le dos et la tête du cheval, et les deux courroies qui partent de la bride jusqu’aux mains du cavalier — les rênes.
Les rênes sont fixées à la bride. Elles ne sont pas extérieures au harnais, elles en sont une pièce. Alors à la question « harnais et Reins s’opposent-ils clairement ? », la réponse est non. Ce sont deux parties d’un même équipement.
Il faut partir de là. Le cliché habituel — « le harnais est la clôture, les Reins sont la direction » — les oppose. Les opposer est une erreur. « Les portes de validation font aussi partie du harnais, non ? » Une seule phrase suffit à faire s’effondrer cette opposition. Et elle a raison. La CI, le vérification de types, la suite de tests — ce sont des échafaudages hors-modèle, et c’est exactement ce que le harnais englobe.
La bonne question n’est donc pas : s’opposent-ils ? Mais : où divergent-ils ?
Où les Reins deviennent-elles possibles — trois boucles imbriquées
Avant de localiser le point de divergence, il faut voir où les Reins deviennent seulement possibles. En termes de couches de boucle, il y en a trois.
① Boucle de chat LLM → humain → LLM Tout probabiliste. Rênes impossibles.
② Boucle agentique LLM → exécution → observation → LLM L'exécution touche un sol déterministe → Rênes possibles.
③ Boucle Reins ② + vérificateurs conçus + cliquet Rênes accomplies.
Dans la boucle de chat, il n’y a nulle part où accrocher une bride. On n’est même pas encore en selle. Pendant que le LLM répond, que l’humain lit et renvoie, pas un seul maillon n’est déterministe. Il n’y a pas de métal pour mordre le signal.
La boucle agentique pose la selle. Dès que l’exécution intervient — le compilateur tourne, les tests échouent, des fichiers sont écrits — la boucle foule pour la première fois un sol déterministe. Il y a enfin quelque chose à saisir.
C’est précisément la raison du succès écrasant de Claude Code. Bash, I/O de fichiers, exécution de tests — des portes déterministes intégrées dans la boucle, en partie par accident, lui conféraient déjà des « Reins partielles ». Ce qui n’existait pas à l’ère du simple chat.
Ce n’est pas seulement mon affirmation. Le HAL (Holistic Agent Leaderboard) de Princeton a montré, sur 21 730 exécutions d’agents, qu’en prenant le même modèle et en changeant seulement l’échafaudage, la précision varie de plusieurs dizaines de points de pourcentage.3 Le modèle est fixe ; ce qui change, c’est la structure qui l’entoure. Addy Osmani le résume en une ligne : « un modèle passable + un excellent harnais > un excellent modèle + un mauvais harnais. » Il note également que le même Opus obtient de meilleurs scores dans un harnais personnalisé que dans Claude Code lui-même.4
Voilà le territoire que l’industrie appelle « harness engineering ». C’est une vraie découverte. Et c’est précisément là que la confusion avec les Reins est la plus forte. Les deux produisent des résultats depuis l’extérieur du modèle.
Mais la boucle ② n’est que la moitié accidentelle des Reins. Reins Engineering, c’est compléter intentionnellement cette moitié. Transformer les portes intégrées par accident en vérificateurs conçus, en cliquet et en séparation décision/implémentation — élever ② vers ③. Le discours sur les harnais démontre les Reins, mais ne les remplace pas.
Les trois axes
Deux personnes travaillent avec un même cheval.
L’une fabrique le harnais. Les dimensions de la selle, la résistance de la bride, la forme du mors. Cela sert pour n’importe quel cheval, n’importe quel voyage. Bien conçu une fois, il reste le même qu’on aille à Paris ou à Lyon. Celui qui le fabrique est un sellier — pas quelqu’un qui va monter à cheval.
L’autre tient les rênes. Il connaît ce voyage. À quel croisement tourner à gauche, quelle est la destination, quand dire « nous sommes arrivés ». Les courroies qu’il tient sont fixées au même harnais, mais les signaux qu’il envoie varient à chaque voyage. Celui qui envoie les signaux n’est pas le sellier, c’est le cavalier.
Voilà les trois axes.
- Fonction. Le harnais contraint — des limites qui empêchent. Les Reins guident — vers où aller et quand c’est terminé.
- Durée de vie. Le harnais se fabrique une fois et se réutilise pour toutes les tâches. Les Reins se conçoivent à nouveau pour chaque tâche.
- Propriété. Le harnais est livré par le vendeur. Les Reins sont rédigées par l’architecte.
La boucle de Claude Code est identique quel que soit mon projet. C’est le harnais. Anthropic l’a fabriqué et livré ; il est le même pour tous les utilisateurs. Mais la définition de complétion — « départ locataire = cinq photos des emplacements désignés » — je l’ai rédigée moi-même, pour ce domaine précis. Aucun harnais ne la contient. C’est ça, les Reins.
La dépendance ne coule que dans un sens
Si les deux étaient la même chose, on ne pourrait pas en retirer un sans détruire l’autre. Essayons.
Harnais présent, Reins absent. L’agent tourne. Il tourne sans s’arrêter. Mais il erre. Il déambule dans un champ sans marqueur d’objectif ni verdict de complétion, puis s’arrête en se disant « ça devrait suffire comme ça ». Nous connaissons déjà ce phénomène. On l’appelle vibe coding.
Reins présentes, harnais absent. Cela ne tient même pas. On tient les rênes, mais il n’y a pas de bride à mordre. Nulle part où envoyer le signal. On serre du vide dans sa main.
La dépendance est unidirectionnelle. Les Reins ont besoin du harnais, mais le harnais n’a pas besoin des Reins. Le harnais fonctionne sans les Reins — mais mal. Cette asymétrie réfute proprement l’idée que « les deux sont la même chose ». Si c’était le cas, retirer l’un devrait faire s’effondrer les deux. Or le harnais court tout seul.
La seule zone d’intersection
Y a-t-il vraiment un chevauchement ? Oui. Exactement une case.
Les portes de validation en cours d’exécution. La CI tourne dans la boucle agentique. Cette surface d’exécution enjambe les deux camps — elle fait partie du harnais et elle est aussi ce que les Reins accrochent. C’est là que naît la question « c’est pas du harnais, ça ? ». En effet, sur cette case précise, les deux désignent la même chose.
Mais au-delà, ils divergent.
Harnais seul Intersection Reins seules
───────────────── ───────────────── ─────────────────
Sandbox·permissions Portes de validation Définition du "fini"
Câblage des outils (checks exécutés) Conception anti-cheese
Gestion du contexte Analyse proxy↔objectif
(confinement sans (intention sans
direction) (surface d'exécution) substrat)
Le harnais possède un confinement sans direction — le sandbox ne dit pas où aller, il empêche seulement de sortir. Les Reins possèdent une intention sans substrat d’exécution — la définition de « qu’est-ce qui est terminé » existe avant même qu’une porte soit là pour l’exécuter. Ni l’un ni l’autre ne contient entièrement l’autre. Ils se croisent. Ils ne s’incluent pas.
Pourquoi la question de la sous-inclusion est mal posée
« Alors les Reins sont-elles un sous-ensemble du harnais ? »
Pour qu’il y ait sous-ensemble, il faut que les deux se mesurent avec la même règle. Or le harnais se définit par qui le livre et à quel point il est réutilisable (axe du substrat), et les Reins par ce qu’elles font à la trajectoire (axe fonctionnel). Les axes sont différents.
C’est comme demander : « Le rouge est-il un sous-ensemble du lourd ? » Il existe des choses rouges et lourdes (= les portes exécutées), mais la couleur ne peut pas être contenue dans le poids. Les règles de mesure diffèrent. La relation de sous-ensemble est ici une erreur de catégorie.
La relation exacte est la suivante : les Reins présupposent le harnais, mais ne sont pas incluses dans le harnais. Une couche posée au-dessus n’est pas une partie contenue à l’intérieur. Ce qui est posé au-dessus s’étend au-delà du substrat.
Le vrai point de divergence — le cheese
Tout ce qui précède relève de la structure. Mais l’endroit où Reins se sépare décisivement du discours sur les harnais est ailleurs. C’est le cheese (en anglais dans le texte — terme du jargon du game design désignant une stratégie qui exploite les failles d’une règle pour atteindre l’objectif sans vraiment jouer le jeu).
Les concepteurs de jeux le savent. « Tuez 10 rats » est une quête notoirement problématique. Il y a un écart entre ce que la porte vérifie (10 rats morts) et ce que le designer voulait vraiment (que le joueur vive le contenu), et le joueur s’y engouffre. C’est le cheese. C’est exactement ce que les chercheurs en sécurité IA appellent le « jeu de spécification (specification gaming) » — un agent de course nautique qui tourne en rond pour ramasser des bonus de score au lieu de franchir la ligne d’arrivée, un agent Tetris qui met le jeu en pause indéfiniment pour ne jamais perdre.5
Ma porte de vérification locative se fait aussi cheesée. Cinq photos vérifient « les photos existent », pas « la remise des clés s’est bien passée ». Et si le responsable n’a photographié que les murs propres ? La porte est franchie. Dès que la mesure devient l’objectif, la mesure se dégrade — c’est la loi de Goodhart.6
Voici le cœur du sujet. Le harnais peut répondre jusqu’à « est-ce que ça passe ? » Les tests sont-ils verts ? Les types sont-ils corrects ? Le schéma est-il intact ? Il s’arrête là. Mais « ce passage capture-t-il l’objectif ? » est une question à laquelle le harnais ne peut jamais répondre. Car ce qu’est le cheese ne peut être défini qu’en connaissant l’objectif du domaine. Pourquoi des photos de murs propres relèvent de la fraude, pourquoi toutes les règles sont respectées alors que l’objectif n’est atteint qu’à 90% — seul celui qui sait à quoi sert ce travail le sait.
Ce quelqu’un, c’est le cavalier. Celui qui tient les Reins.
Concevoir des portes imperméables au cheese — anticiper là où le proxy ne suit pas l’objectif — est fondamentalement différent pour chaque tâche, incorpore la connaissance du domaine, et est rédigé par l’opérateur. Un harnais agnostique à la tâche ne peut pas fournir cela. Non pas qu’il ne veuille pas — il ne connaît pas le domaine, donc il ne peut tout simplement pas le traiter.
C’est le territoire propre à Reins Engineering, absent des discours sur le harness engineering et l’agentic engineering. Eux parlent de mieux construire le harnais. Reins dit : pour ce voyage précis, par quelle porte faire passer le cheval sans que rien ne casse.
Et donc, retour à l’incident de fuite
Revenons maintenant à l’ironie initiale. On voit désormais pourquoi cet incident est une preuve plutôt qu’un sujet de raillerie.
Le cheval était un génie. Opus est la puissance probabiliste à l’état pur. La selle fonctionnait aussi — Claude Code est le meilleur harnais au monde, et les chiffres du HAL le prouvent. Pourtant, la base de code que ce harnais a produite a dérivé exactement selon le mode d’échec prévisible. Une fonction à 3 167 lignes. Le mur des 200 endpoints, manifesté dans le code. La fuite elle-même — une ligne manquante dans .npmignore — signifie qu’il n’y avait aucune porte sur les artefacts de déploiement.
La société qui a construit le meilleur harnais au monde n’a pas accroché ce harnais dans ses propres écuries.
Ce n’est pas une antithèse — c’est la preuve décisive de la thèse. Les Reins ne sont pas une propriété que le modèle ou l’agent possède — c’est une discipline qu’on applique. Que l’agent soit brillant et que le code produit par cet agent soit soumis aux Reins sont deux choses entièrement distinctes. Un modèle plus grand n’est pas la réponse. Un meilleur harnais non plus. Tenir les rênes, définir soi-même la complétion de ce voyage, concevoir les portes pour bloquer le cheese — c’est cette discipline qui est la réponse.
En définitive
Le harnais fait courir le cheval. Les Reins décident par quelle porte l’envoyer. Le harnais se pose une fois ; les Reins se tiennent à chaque instant. Le harnais est livré par le sellier ; les Reins sont dans la main du cavalier.
Les deux ne s’opposent pas. Ce sont des pièces différentes du même équipement. Mais des pièces différentes. Sans harnais, les Reins ne peuvent exister ; sans Reins, le harnais erre. Et savoir si ce travail est vraiment terminé — c’est toujours la main qui tient les rênes qui le sait.
La prochaine fois que quelqu’un vous demande « c’est pas finalement du harnais ? », répondez ceci :
« Le harnais est livré par le vendeur ; les Reins, je les conçois pour cette quête précise. Il n’y a pas de Reins sans harnais, mais un harnais sans Reins ne fait qu’errer. L’outil même qui prétendait vous donner les rênes n’en avait aucune sur son propre code — parce que les Reins ne se possèdent pas, elles se tiennent. »
Articles liés
- L’IA sous les rênes : Reins Engineering — l’origine du reframe « porte = rêne »
- Qui définit le « terminé » ? — portes imperméables au cheese, le tasking comme design de quête
- Pourquoi les agents de codage fonctionnent et pourquoi ils cassent — « la génération peut être probabiliste, la vérification doit être déterministe »
- Pourquoi votre agent ne s’arrête jamais — un système capable de s’arrêter = un système dont la complétion est définie
- Yongol : le mur des 200 endpoints — la spécification rédigée par l’opérateur = les Reins dans le réel
À lire aussi
Ces articles extérieurs approfondissent — ou éclairent sous un autre angle — les frontières que ce texte explore : harnais et Reins, la façon de s’arrêter, les spécifications qui se font cheesées.
- How Coding Agents Work — Simon Willison — « Un agent de codage est un harnais enveloppant un LLM. » La définition de référence du harnais, à lire avant d’entrer dans l’article.
- Agent Harness Engineering — Addy Osmani — Formalise le harness engineering comme une discipline à part entière. Traite les conditions de terminaison via le « sprint contract » — le chevauchement le plus direct avec cet article.
- Reward Hacking in Reinforcement Learning — Lilian Weng — L’épine dorsale théorique de la loi de Goodhart et du jeu de spécification. Explique pourquoi le cheese se produit, du point de vue du RL et du RLHF.
- Water Finds a Crack — Soren Johnson — « Si on lui en donne l’occasion, le joueur optimise le jeu jusqu’à le vider de sa substance. » L’archétype humain du reward hacking vu par le design de jeux.
- Effective Harnesses for Long-Running Agents — Anthropic — Le premier concerné traite la défaillance consistant à « déclarer terminé sans l’être ». Conditions de terminaison et vérification déterministe en un seul article.
Les faits de l’incident (2026-03-31, v2.1.88, omission
.npmignore/Bun source maps, ~512K lignes·~1 900 fichiers, position « erreur humaine / pas de compromission », recommandation d’épingler v2.1.87) ont été vérifiés de manière croisée avec The Register (« Anthropic accidentally exposes Claude Code source code », 2026-03-31), InfoQ et VentureBeat. ↩︎La fonction unique de 3 167 lignes dans
print.tsa été confirmée par claudefa.st, « Claude Code Source Leak: Everything Found ». ↩︎Kapoor, Narayanan et al., « Holistic Agent Leaderboard: The Missing Infrastructure for AI Agent Evaluation » (Princeton), arXiv:2510.11977 — 9 modèles × 9 benchmarks, 21 730 exécutions. Quantifie l’impact de l’échafaudage en dissociant modèle, échafaudage et benchmark. Tableau de bord en direct : hal.cs.princeton.edu. ↩︎
Addy Osmani, « Agent Harness Engineering » — « Un modèle passable + un excellent harnais > un excellent modèle + un mauvais harnais. » Observation que le même Opus obtient de meilleurs scores dans un harnais personnalisé que dans Claude Code. ↩︎
Krakovna et al., Google DeepMind, « Specification gaming: the flip side of AI ingenuity » ; liste de cas : V. Krakovna, « Specification gaming examples in AI » (boucle de score CoastRunners, pause permanente de Tetris, etc.). « Comportement qui satisfait la spécification littérale d’un objectif sans atteindre le résultat voulu. » ↩︎
Marilyn Strathern (1997), « ‘Improving ratings’: audit in the British University system », European Review 5(3):305–321 — source de « dès qu’une mesure devient un objectif, elle cesse d’être une bonne mesure » (reformulation de la proposition de Goodhart de 1975 via Hoskin). ↩︎