Fuite de Bug-Scope chez Anthropic : un modèle qui corrige un bug et pose des questions sur la classe

La phrase la plus intéressante dans la fuite actuelle d’Anthropic ne porte pas sur l’intelligence. Elle porte sur le périmètre. Selon un rapport relayé sur X le 19 octobre 2026, Anthropic prépare un modèle qui, lorsqu’on lui demande de corriger un seul bug, peut identifier la catégorie plus large de problèmes qui se cache derrière, puis demander s’il doit aussi les traiter. C’est une affirmation sur l’endroit où un modèle s’arrête, et non sur la qualité de son raisonnement — et elle tombe directement sur la ligne de faille de chaque agent de codage en production, y compris ceux construits aujourd’hui sur Claude Opus 5.5 et ceux dont on suppose déjà qu’ils tourneront sur Claude Fable 5.5, le candidat non confirmé pour le modèle décrit. Anthropic n’a annoncé, nommé ni daté un tel modèle. Il n’existe ni identifiant, ni grille tarifaire, ni fiche de modèle, ni évaluation. Tout ce qui suit à propos du comportement rapporté relève d’un reportage non vérifié et à source unique, et tout ce qui suit à propos de la gamme actuelle provient de la documentation propre à Anthropic.Les défaillances de l’IA et les incidents d’agents de codage documentés qui sous-tendent des rapports comme celui-ci sont recensés dans le OrcaRouter AI Incident Archive où chaque entrée comporte ses propres sources, son niveau de gravité, son degré de confiance et son indicateur de contestation.

La formulation compte plus que d’habitude ici, car deux résumés du même rapport décrivent deux comportements différents. Celui qui se lit comme une spécification — un bug, la classe qui le sous-tend, une question sur l’opportunité d’élargir la tâche — figure dans le relais qui nous est parvenu. L’agrégation publique du rapport, consultée le 19 octobre, contient une formulation différente : un modèle « doté d’une meilleure intuition et d’un raisonnement capable de discerner les intentions sous-jacentes et plus à même de penser hors des sentiers battus ». Ce ne sont pas les mêmes affirmations. L’une concerne un modèle qui propose davantage de travail ; l’autre, un modèle qui lit ce que vous vouliez dire. Les deux peuvent être vrais d’un même modèle, mais une seule de ces affirmations change l’allure d’un diff le lundi matin, et c’est celle-là qui mérite d’être décortiquée.

Ce que l’affirmation dit réellement, et ce qu’elle ne dit pas

Dépouillez le texte de ses adjectifs et le rapport décrit un comportement en trois étapes : on présente un seul défaut au modèle, celui-ci généralise de ce défaut à un schéma, puis il fait remonter ce schéma à l’utilisateur au lieu de le corriger silencieusement. C’est la troisième étape qui transforme cela en affirmation de conception plutôt qu’en affirmation de benchmark. Un modèle qui réparerait discrètement chaque occurrence serait un agent autonome au rayon d’impact non borné. Un modèle qui trouve le schéma et demande propose une modification du périmètre de la tâche, ce que fait un ingénieur prudent et ce qu’on ne devrait pas laisser un agent imprudent faire unilatéralement.

Il ne s’agit pas non plus d’une affirmation que quiconque puisse encore évaluer. Il n’existe pas de jeu de tâches public qui mesure « a identifié la classe correctement » par rapport à « a inventé un motif qui n’était pas là ». Les deux comportements sont identiques dans une transcription : le modèle revient avec une liste. Savoir si cette liste est une véritable généralisation ou une hallucination présentée avec assurance ne se tranche qu’en lisant chaque élément, c’est-à-dire le travail que le modèle était censé vous épargner.

Ce que le rapport ne dit pas est tout aussi déterminant. Aucun nom de modèle. Aucun identifiant d’API. Aucun prix, aucune fenêtre de contexte ni aucun plafond de sortie. Aucune indication permettant de savoir si ce comportement est celui par défaut, un mode, ou quelque chose que l’appelant doit demander. Et aucune confirmation du fournisseur, d’aucune sorte — la salle de presse d’A​nthropic n’a rien publié au sujet d’un nouveau modèle depuis Claude Haiku 5.5 le 7 octobre 2026, et la page d’aperçu des modèles de Claude Platform répertorie toujours exactement quatre modèles : Claude Fable 5.1, Claude Opus 5.5, Claude Sonnet 5.5 et Claude Haiku 5.5.

Pourquoi « la classe plus large » est une affirmation différente de « un meilleur raisonnement »

Un meilleur raisonnement est l’affirmation sans risque. Chaque génération est décrite ainsi, elle est mesurée sur des indices publics, et un successeur obtenant un meilleur score serait attendu plutôt que digne d’intérêt. Généraliser à partir d’un cas est une opération différente, et ce qui la rend intéressante, c’est qu’il s’agit du type de défaut réel le plus courant en logiciel.

L’exemple canonique est l’injection. Vous signalez une requête non assainie dans un gestionnaire. La classe derrière cela, ce sont tous les autres gestionnaires qui construisent une requête de la même manière. Un relecteur humain qui a déjà vu cela ne corrige pas le seul gestionnaire puis passe à autre chose ; il recherche le motif avec grep, puis il demande si le correctif a sa place dans ce ticket. Un modèle qui fait la même chose effectue une revue, pas une réparation. La sortie n’est pas un correctif, c’est un constat — et les constats ne sont utiles que si quelqu’un ayant l’autorité d’élargir le ticket est dans la boucle.

• Ce que décrit la réclamation — face à un seul défaut, identifier le schéma et le signaler avant d'agir.

• Ce que fait un correctif ordinaire — il modifie le code que vous avez indiqué, puis s'arrête.

• Ce que fait un agent négligent : il modifie le code que vous avez indiqué, puis poursuit son chemin, et vous ne l’apprenez qu’en voyant le diff.

• Ce que le rapport laisse en suspens — si « asks » désigne une question bloquante lors d’une session interactive ou une note ajoutée à une modification terminée.

Cette dernière ligne est le point où la fuite cesse de pouvoir être évaluée. La différence entre ces deux lectures est celle qui sépare un outil qui respecte le contrôle des changements d’un outil qui documente après coup son propre dérapage de périmètre.

Les propres recommandations d’Anthropic se situent déjà des deux côtés de cette question.

Voici ce qui rend cette affirmation crédible plutôt qu’arbitraire. Les recommandations publiées par Anthropic pour Claude Code demandent déjà exactement ce réflexe à un endroit et le déconseillent à un autre, et les deux conseils sont séparés par un paragraphe.

« S’attaquer aux causes profondes, pas aux symptômes » est l’une des stratégies documentées dans le guide des bonnes pratiques de Claude Code, illustrée par un échec de build : corriger l’erreur et vérifier que le build réussit, et ne pas masquer l’erreur. C’est une instruction directe à ne pas s’arrêter à l’instance signalée. Quelques sections plus haut, le même guide dit de « délimiter la tâche. Préciser quel fichier, quel scénario et quelles préférences de test », avec l’exemple de demander un test qui couvre un cas limite plutôt que des tests en général. La raison invoquée est que Claude peut déduire l’intention mais ne peut pas lire dans vos pensées.

Le guide trace aussi une limite selon la taille du diff : le mode plan vaut le surcoût lorsqu’un changement touche plusieurs fichiers ou que l’approche est incertaine, et « si vous pouviez décrire le diff en une phrase, passez le plan ». Un modèle qui étend un seul bug à toute une classe transforme, par construction, un diff d’une phrase en plan. Ainsi, le comportement que décrit la fuite n’est pas étranger à la philosophie produit d’A​nthropic — c’est le moment où deux de ses principes énoncés entrent en collision, et la collision est actuellement résolue par l’utilisateur, pas par le modèle.

Il existe une deuxième raison, moins confortable, pour laquelle cette affirmation est plausible. La documentation d’Anthropic elle-même reconnaît franchement qu’un modèle s’arrête lorsque le travail semble terminé, et que, sans quelque chose que le modèle peut exécuter — une suite de tests, un code de sortie de build, un diff par rapport à un fixture — « semble terminé » est le seul signal disponible. Un modèle qui généralise d’un bogue à une classe de bogues est un modèle qui a trouvé un signal au-delà de « semble terminé ». C’est le meilleur argument en faveur de la capacité et le meilleur argument pour demander avant d’agir sur elle.

Là où la décision est réellement prise aujourd’hui

L’intérêt de cette fuite, c’est que les contrôles dont elle aurait besoin existent déjà, et vous pouvez les examiner sans attendre un modèle. Trois d’entre eux comptent.

Effort — Anthropic expose cinq niveaux, de low à medium et high jusqu’à xhigh et max, et ce réglage détermine la quantité de travail que le modèle effectue de lui-même. Claude Opus 5.5 et Claude Haiku 5.5 sont par défaut sur medium ; les autres modèles actuels le sont sur high. L’effort s’applique à tous les jetons de sortie, y compris les appels d’outils, ce qui signifie qu’un modèle qui élargit le périmètre avec un effort high est un modèle qui élargit le périmètre avec une facture plus élevée.

• Mode Plan — Claude Code sépare l’exploration de l’exécution, et le seuil documenté pour y recourir correspond précisément au cas multi-fichiers qu’implique une classe de bugs. Ce contrôle n’est pas un filtre sur les idées du modèle ; c’est une étape où vous pouvez voir le périmètre élargi avant qu’il ne devienne un diff.

• Barrières déterministes — les hooks exécutent une vérification sous forme de script et peuvent empêcher un tour de se terminer tant qu’elle n’a pas réussi. C’est la seule des trois qui ne dépende pas du fait que le modèle choisisse de demander. Si le comportement rapporté est un jour livré, la manière honnête de l’utiliser consiste à le placer derrière une barrière que vous avez écrite, car « demande s’il devrait s’en occuper » est une promesse concernant le jugement d’un modèle, et un hook d’arrêt est une promesse concernant le vôtre.

Rien de tout cela ne constitue une critique de l’affirmation. C’est précisément ce qui rend l’affirmation intéressante : un modèle qui propose une portée plus large ne constitue une amélioration que si cet élargissement est visible avant d’être appliqué, et tout mécanisme qui le rend visible est quelque chose que l’appelant configure, non quelque chose que le modèle garantit.

Ce que cela coûterait si cela fonctionnait

L’élargissement du périmètre est la forme d’aide la plus coûteuse, car il multiplie les sorties plutôt que les entrées. Sur la grille tarifaire actuelle d’A​nthropic, Claude Fable 5.1 coûte 10 $ par million de tokens d’entrée et 50 $ par million de tokens de sortie, tandis que Claude Opus 5.5 est à 4 $ et 20 $ — et la documentation d’A​nthropic oriente d’abord les développeurs vers Claude Opus 5.5, en ne passant à Fable que lorsque les évaluations d’Opus à effort plus élevé restent encore insuffisantes. Un modèle dont l’argument de vente est de trouver plus de travail à faire va directement à l’encontre de ce conseil, puisque le palier bon marché est celui dont on veut multiplier les sorties, et le palier coûteux celui où un ticket élargi devient une ligne budgétaire.

Il existe un coût de second ordre qui n’apparaît pas sur une facture de tokens : la relecture. Un correctif apporté à une fonction peut être lu en une minute. Un résultat qui mentionne neuf autres sites d’appel doit être vérifié point par point, et cette vérification représente le même travail que le modèle prétendait éliminer. Ce n’est pas un argument contre cette capacité — un bon relecteur muni d’une liste de contrôle est plus rapide qu’un bon relecteur qui n’en a pas —, mais cela signifie que la valeur dépend de la précision. Un modèle qui fait ressortir cinq cas réels et un cas inventé vous a coûté le temps de réfuter le cas inventé, et vous a appris à faire un peu moins confiance à la liste.

Ce que vous pouvez appeler aujourd’hui, et la réponse honnête à ce sujet

Rien de nouveau. Il n’y a aucun identifiant pour le modèle dans le rapport, et notre propre catalogue en est un bon test : lui demander anthropic/claude-fable-5.5 renvoie modèle introuvable, et il en va de même pour anthropic/claude-haiku-5.5. Ces chaînes ne figurent pas parmi les 209 modèles que nous routons. Ce qui fonctionne, c’est la gamme actuelle au prix catalogue d’Anthropic — anthropic/claude-opus-5.5 avec une fenêtre de contexte de 1 M de tokens, un plafond de sortie de 128 K et 4 $ / 20 $ par million, et anthropic/claude-fable-5.1 à 10 $ / 50 $. Toute plateforme qui annonce en ce moment l’accès au « nouveau modèle de chasse aux bugs d’Anthropic » ne vend qu’un nom.

La question pratique qu’un lecteur se pose réellement n’est pas de savoir comment le modèle s’appelle. C’est de savoir comment déterminer si un modèle qui élargit le périmètre aide ou nuit sur votre base de code, sans parier un chemin de production sur une rumeur. C’est une question de routage, et c’est le seul endroit où une plateforme justifie son existence : envoyer une part des requêtes vers le modèle non éprouvé en plaçant derrière lui un modèle que vous avez déjà mesuré, afin qu’une mauvaise généralisation vous coûte une revue plutôt qu’un incident. Les changements tarifaires et les nouvelles versions d’Anthropic arrivent sur OrcaRouter le jour même avec 0 % de marge, donc lorsqu’une grille tarifaire apparaît, le coût de l’expérimentation se limite au prix catalogue, sans supplément. Vous pouvez voir exactement ce que coûte le modèle le plus haut de la gamme actuelle sur la page du modèle Claude Opus 5.5, et le comparer à la page de Claude Fable 5.1 avant de décider lequel votre charge de travail doit utiliser par défaut.

Qu'est-ce qui changerait cette pièce ?

Trois choses, et la première est celle qui permettrait de trancher le plus rapidement.

Une phrase émanant directement d’A​nthropic. Une seule ligne dans la documentation d’A​nthropic décrivant quand le modèle élargit le périmètre, et si cet élargissement est un comportement par défaut ou une option à activer explicitement, transformerait toute la fuite en spécification. L’absence de cette ligne est la raison pour laquelle chaque affirmation ici doit être nuancée.

Une évaluation publiée. « A trouvé la classe » n’a de sens que par opposition à « a inventé la classe », et aucun fournisseur ne publie de jeu de tâches qui permet de distinguer les deux. Tant qu’un tel jeu n’existe pas — précision et rappel sur l’identification des classes de défauts, évalués par quelqu’un d’autre que le laboratoire —, toute affirmation sur la généralisation à partir d’un seul bug décrit une intention, pas une capacité que l’on peut comparer entre modèles.

Un nom et une grille tarifaire réunis. La convention de nommage est restée stable à travers Fable 5, Fable 5.1, Opus 5.5, Sonnet 5.5 et Haiku 5.5, et l’identifiant porte le palier : un claude-fable-5-5 impliquerait 10 $ / 50 $ et un claude-opus-5-6 impliquerait 4 $ / 20 $. Une seule chaîne dans la présentation des modèles résout la question à laquelle la fuite consacre mille mots.

D’ici là, la position honnête est qu’un laboratoire de pointe chercherait, selon les rapports, à mettre au point un comportement sur lequel chaque organisation d’ingénierie a déjà une politique, et que personne n’a publiée. Savoir si un modèle doit corriger le bug que vous avez signalé, ou celui que vous ignoriez avoir, n’est pas une question de capacité. C’est une question de savoir qui détient le bouton de fusion, et la fuite — qui indique que le modèle demande — est une réponse plus rassurante que celle que donnent actuellement la plupart des agents de codage, à savoir continuer et laisser le diff s’expliquer de lui-même.