Le Modèle le Plus Puissant d'Anthropic a Raté une Faille de Sécurité sur 6 200 Lignes de Code Prod. Moi Aussi.
Anthropic a sorti Fable 5 hier matin. Le modèle que la fiche système d'avril qualifiait de « trop dangereux pour être publié » (même noyau que Mythos, garde-fous cyber activés) est maintenant dans Claude Code.
Alors j'ai fait un audit. 😬
TLDR : J'ai fait tourner Opus 4.8 et Fable 5 en parallèle sur 6 200 lignes de Go et TypeScript en production réelle. Ils n'ont pas trouvé les mêmes choses. Et aucun des deux n'a tout trouvé. Y compris la faille de sécurité qui tournait en prod depuis le premier jour.
J'avais un tracker de commissions e-commerce en live qui traînait là : binaire Go exposé derrière Cloudflare, back-office TypeScript sur un mesh privé, SQLite partagé. 2 sessions indépendantes, même brief d'une ligne, même accès SSH à la prod.
Ce qui est revenu était asymétrique d'une façon que je n'attendais pas.
Fable 5 Est Ce Qu'Anthropic Refusait de Livrer
Fable 5 est le premier modèle de classe Mythos à devenir public. Les chiffres du lancement sont difficiles à ignorer : 80,3% sur SWE-Bench Pro, contre 69,2% pour Opus 4.8, 58,6% pour GPT-5.5, et 54,2% pour Gemini 3.1 Pro. Un écart de 11 points sur le précédent meilleur d'Anthropic, ce n'est pas du progrès incrémental.
La démo phare : une base de code Ruby de 50 millions de lignes migrée en une seule journée. Stripe avait estimé le même boulot fait manuellement à 2 mois pour une équipe d'ingénieurs complète.
Jusqu'à hier, ce modèle (alors appelé Mythos) était enfermé dans le Project Glasswing : un programme restreint pour une poignée d'organisations de confiance, spécifiquement à cause du risque cybersécurité que représentait le modèle sans restrictions. Fable 5 est Mythos avec les garde-fous engagés. Toute requête qui touche aux surfaces d'attaque cyber, bio ou chimique rebascule automatiquement sur Opus 4.8. Prix : 10$ par million de tokens en entrée, 50$ par million en sortie. Gratuit sur abonnements jusqu'au 22 juin.
La plupart des comparaisons entre ces modèles se font sur des datasets contrôlés. Un audit sur un tracker de commissions en live a des contraintes différentes : la structure de fichiers est irrégulière, certains modules ne sont pas documentés, et la fenêtre de contexte se remplit de code qui a été écrit pour fonctionner, pas pour être lu. Aucun des deux modèles n'a eu un environnement préparé. Ils ont eu la même clé SSH et un listing de répertoire.
2 sessions. Même brief d'une ligne : « audite ce dépôt pour les vulnérabilités de sécurité et les problèmes d'infrastructure. » Mêmes identifiants SSH vers la production. Indépendantes, aucun contexte partagé entre elles.
2 Styles de Travail Radicalement Différents
Opus 4.8 travaille seul et va en profondeur. Il lit le code, forme une hypothèse, écrit un programme jetable pour prouver ou réfuter le bug, l'exécute, et revient avec des preuves. Quand Opus a signalé le problème d'idempotence des transactions SQLite, il n'a pas juste identifié le pattern : il a conçu un test, lancé 3 inserts avec un ID de transaction vide identique, et renvoyé la sortie montrant 1 ligne stockée. Collision INSERT OR IGNORE contre une contrainte UNIQUE, démontrée. Pas inférée à partir de la lecture.
Fable 5 travaille comme un chef d'audit qui manage une équipe. Il découpe le dépôt en 4 zones, spawn 4 agents parallèles, et assigne à chaque agent le modèle qu'il pense approprié pour le profil de risque de cette zone. Il ne va pas en profondeur dans un seul fichier. Il tient la carte pendant que les agents lisent le terrain, et fait ensuite quelque chose qu'Opus ne fait jamais : retourne valider chaque trouvaille des agents avant qu'elle n'atterrisse dans le rapport. (Pense raid lead qui appelle les assignments pendant que le meilleur joueur solo de l'équipe mémorise chaque hitbox de boss. Jobs différents. Même donjon.) Les builders qui veulent comprendre pourquoi ce modèle de coordination fonctionne comme ça trouveront pourquoi les pipelines d'agents natifs CLI surpassent les setups basés MCP à lire en parallèle de ceci.
1 modèle est construit pour prouver les choses. L'autre est construit pour ne pas les rater. Ils ne sont pas en compétition sur le même job.
Le Moment Où Fable 5 A Mérité Son Prix
Un des agents de Fable est revenu avec « backup litestream pas déployé, sévérité : haute ».
Fable a ouvert une connexion SSH et lancé systemctl is-active litestream. A reçu « active ». Reclassifié : la sauvegarde n'est pas manquante, la documentation du runbook est fausse. Sévérité rétrogradée à informationnelle.
Même session, 5 minutes plus tard : « vulnérabilité d'injection shell critique » sur un paramètre de requête URL. Fable a tracé le paramètre à travers le request builder, trouvé URLSearchParams encodant les apostrophes en %27 avant qu'aucun contexte shell ne puisse les recevoir. Pas injectable. Rétrogradé.
2 critiques éliminées sans que j'ouvre un seul fichier.
(Quand j'ai vérifié moi-même la reclassification litestream, j'ai ouvert le fichier unit et remarqué que le bloc de commentaires référençait encore l'ancien hostname du serveur d'une migration que j'avais faite il y a 8 mois. Le service fonctionne. Les commentaires décrivent une machine qui n'existe plus. Pas urgent ni bloquant, juste qui s'accumule silencieusement jusqu'à ce que la prochaine personne à toucher le serveur doive comprendre ce qui était réel de ce qui était réel il y a 2 migrations. J'ai un post-it sur mon écran qui dit « passe doc infrastructure » depuis au moins janvier.)
La qualité d'audit ne se mesure pas au nombre de trouvailles.
4 Trouvailles Que Fable A Attrapées, Opus A Ratées
4 vraies trouvailles de sécurité qu'Opus a complètement ratées.
La comparaison de clé postback. L'endpoint postback partenaire valide son secret entrant en utilisant une comparaison de chaîne Go != standard. Cette comparaison fuit de l'information de timing : avec assez de requêtes, un attaquant mesurant la latence de réponse peut détecter quand sa supposition est « plus proche » du secret correct. Le fix fait 2 lignes, échanger la comparaison pour subtle.ConstantTimeCompare du package crypto/subtle de Go.
La comparaison à temps constant est standard dans tout système d'auth qui gère des secrets. Le problème n'est pas de connaître le fix. Le problème est de savoir demander si la comparaison est à temps constant en premier lieu. (Les attaques de timing sur les systèmes d'auth sont basiquement du speedrunning : avec assez de runs mesurés, le leaderboard finit par te donner la clé.) Les attaques de timing sur les endpoints postback nécessitent un attaquant qui sait que l'endpoint existe, connaît la longueur du secret, et peut mesurer le jitter réseau avec assez de précision. Pas trivial. Aussi pas quelque chose que tu veux en live quand l'endpoint est publiquement accessible sans couche d'authentification supplémentaire.
C'est le « Moi Aussi » du titre. Cette comparaison tournait en prod depuis le lancement. Opus avait le code du handler dans sa fenêtre de terminal. Il ne l'a pas signalé. Fable l'a signalé.
Je ne l'avais pas signalé non plus.
Services qui tournent en root. Le binaire Go et le back-office TypeScript tournent tous les deux sans directive systemd User= et sans alerting de crash-loop configuré. Opus avait exécuté systemctl cat sur les deux fichiers de service, lu les variables d'environnement, et continué sans noter l'isolation absente. Faire tourner des services sans isolation utilisateur systemd est un moyen fiable de transformer un service compromis en hôte complètement compromis. Fable a signalé les deux.
Le CLI, qui était explicitement dans le scope. Le brief l'incluait. Fable l'a trouvé. Opus ne l'a jamais adressé. Trouvailles dans la zone CLI : identifiants API registrar visibles dans la sortie ps sur l'hôte distant. Une erreur de validation dans la routine d'import CSV déclenchant silencieusement un faux email d'alerte à chaque run affecté. Appels HTTP sortants sans timeout défini, qui sous dégradation réseau vont tenir les goroutines ouvertes indéfiniment.
Exposition Slowloris. Le serveur HTTP avait ReadHeaderTimeout configuré et rien d'autre. ReadTimeout, WriteTimeout, et IdleTimeout manquants signifient qu'une attaque de connexion lente peut tenir les goroutines worker vivantes jusqu'à ce que le serveur n'en ait plus. Fable l'a signalé. Opus n'a jamais atteint la configuration serveur.
Le pattern sur les 4 : ce qui se trouve en dehors du cône actif d'attention ne se fait pas trouver, même quand c'est présent dans la sortie terminal déjà à l'écran.
Ce Qu'Opus A Prouvé Que Fable N'A Fait Qu'Assumer
L'honnêteté exige l'équilibre. 4 trouvailles dans le rapport d'Opus qu'aucun agent Fable n'a fait remonter.
Le garde API no-op. Dans le back-office TypeScript, la fonction nommée apiGuard sort sans rien enforcer dans le build de production déployé. Accès destructif complet depuis le mesh privé avec zéro authentification. Les agents de Fable ont signalé « la configuration d'authentification devrait être revue ». Opus a SSH sur le serveur, localisé l'artefact déployé, confirmé le comportement de la fonction, et nommé la fonction spécifique. La différence entre ces 2 trouvailles est la différence entre un action item et un devoir de lecture.
Logique de routing morte. Un filtre is_bot dans les règles de routing de référral partenaire déclenche un rejet avant que l'évaluation de routing ne tourne. La condition downstream qui vérifie le statut bot ne peut jamais matcher, parce que les bots sont rejetés upstream avant de l'atteindre. Le modèle de données promet un comportement que le code ne peut structurellement pas livrer. Aucun des agents de Fable assignés à cette zone ne l'a attrapé.
Enregistrements de clics orphelins. Quand un token partenaire se fait supprimer, les enregistrements de clics associés restent dans la base de données. Aucune contrainte de clé étrangère n'enforce le nettoyage. Ils faussent silencieusement les métriques d'attribution pour toute analyse qui ne compte pas les tokens supprimés. Les deux modèles ont décrit ça comme « perte de revenus potentielle », ce qui n'est pas précis : les clics ne sont pas facturés en double, les statistiques sont calculées contre des enregistrements fantômes. Le framing d'impact business reste le job de l'humain.
La preuve d'idempotence. Opus a écrit un programme Go standalone, l'a exécuté contre une base de données de test, et renvoyé la sortie : 3 inserts avec un ID de transaction vide identique, 1 ligne stockée. C'est une preuve vérifiable. Tu peux lancer ce programme toi-même et obtenir le même résultat. Aucun agent Fable n'a poussé au niveau exécution. Ils ont identifié le pattern. Opus l'a prouvé.
Il y a quelque chose qui vaut la peine qu'on s'y attarde ici, et je pense que c'est genuinement difficile à articuler proprement même après avoir regardé les deux sessions en entier : l'écart entre « j'ai identifié un pattern suspect » et « j'ai construit un programme qui prouve que c'est un vrai bug » n'est pas une différence de capacité dans le sens benchmark traditionnel. Peut-être que je me trompe, mais ça ressemble à un jugement sur quand lire le code cesse d'être suffisant et exécuter le code devient nécessaire. La plupart des ingénieurs senior defaultent à lire plus longtemps qu'ils ne devraient. Opus a fait l'autre choix, écrit la preuve en moins de 3 minutes, et continué. Peut-être que ce jugement est ce que les chiffres de benchmark mesurent vraiment, à un niveau plus profond.
Couverture vs Preuve : Un Framework à 2 Lignes
Opus perce étroit et profond. Quand il prouve quelque chose, il le prouve avec des preuves que tu peux vérifier indépendamment. Le test Go jetable, la confirmation SSH du garde auth no-op : ce sont les sorties d'un modèle qui ferme la boucle au lieu de signaler et continuer.
Fable couvre le périmètre. Il doute de ses propres sous-traitants et valide les trouvailles avant qu'elles ne t'atteignent. Il trouve ce qui existe en dehors du cône d'attention de tout agent unique.
Le framework est court. Fable a du sens quand la couverture est la priorité : scope large, agents parallèles indépendants, trouvailles cross-validées avant qu'elles n'atterrissent dans le rapport. Opus a du sens quand la preuve est la priorité : un comportement suspect spécifique qui a besoin d'être démontré empiriquement, pas juste reporté. Quand le code a du vrai argent qui passe dedans, tu veux les deux sessions. (Lance-les comme une comp de party : Fable clear le donjon, Opus résout le boss.)
Ce n'est pas lire entre les lignes. La fiche système Fable 5, tous ses 319 pages publiées le 9 juin, documente le mode de défaillance directement. Dans une opération interne de routine (886 cas d'usage ordinaires, pas de red-teaming adversarial), le modèle a reporté « aucun mouvement d'erreur du tout » après avoir vérifié un seul type d'erreur, puis sous-compté l'incident de production réel d'un facteur de 20. Anthropic a écrit ça et l'a publié le jour du lancement. Le borgne est documenté, pas caché. Ça vaut le coup de construire ta couche de vérification autour de ça, pas autour de l'assumption que le modèle te dit tout ce qu'il a raté.
L'écart de 11 points SWE-Bench Pro est réel. Tout comme la défaillance de sous-comptage documentée. Les deux choses sont vraies en même temps, et ta politique d'accès production devrait tenir compte des deux.
Fable trouve ce que tu as oublié de chercher. Opus prouve ce que tu avais peur de lancer.
Cette faille de comparaison de timing sur l'endpoint postback partenaire (2 lignes à fixer) tournait depuis le lancement. Opus avait le code du handler dans son terminal. Il n'a pas posé la question. Fable l'a posée.
Je ne l'avais pas vue non plus.
Va auditer tes projets.
Sources
- Claude Fable 5 and Claude Mythos 5, Anthropic (June 9, 2026)
- Fable 5 and Mythos 5: Agentic Coding Deep Dive, Digital Applied (June 9, 2026)
- Fable 5 and Mythos 5: The Frontier Split in Two, Digital Applied (June 9, 2026)
Ce post peut contenir des liens d'affiliation. Si tu cliques dessus, je pourrais gagner une petite commission (ça ne te coûte rien, et ça m'aide à continuer à livrer des articles de qualité chaque jour pour ton plaisir de lecture).