Opus 5 est un excellent employé, mais un mauvais patron

Anthropic a lancé Opus 5 le 24 juillet 2026. Mon verdict est simple : c’est un excellent employé, mais un mauvais patron [1]. Après cinq jours de recherche, j’ai trouvé un modèle qui égale Fable 5 sur les principaux benchmarks alors que son prix par token est divisé par deux, mais qui devient moins fiable lorsqu’il doit lui-même fixer la direction [2].

Opus 5 est-il aussi performant que Fable 5 ? Presque, selon les benchmarks

Dans les benchmarks publiés, Opus 5 et Fable 5 se situent au même niveau. À effort maximal, Artificial Analysis attribue un indice d’intelligence de 61 à Opus, contre 60 à Fable. Cet écart d’un point est trop faible pour conclure qu’Opus est le modèle le plus intelligent [2].

Métrique	Opus 5	Fable 5
Indice d'intelligence AA	61	60
GDPval-AA v2, Elo	1 861 (Meilleure valeur de la ligne)	1 747
AA-Briefcase, Elo	1 720 (Meilleure valeur de la ligne)	1 574
Coût mesuré par tâche d'évaluation, $	2,03 (Meilleure valeur de la ligne)	2,75

Les évaluations plus ciblées d’Artificial Analysis confortent cette conclusion. Opus atteint 1 861 Elo sur GDPval-AA v2, qui mesure le travail intellectuel professionnel, puis 1 720 sur AA-Briefcase, consacré au travail réalisé par des agents. Il devance ainsi Fable de 114 et 146 Elo. Il partage aussi la première place du Coding Agent Index à l’effort xhigh et atteint 89 % sur Terminal-Bench 2.1 à effort maximal [2].

Ces résultats montrent que le modèle moins cher peut égaler Fable quand la tâche possède des limites claires et un résultat précis. Anthropic observe la même tendance : à effort maximal, Opus arrive à moins d’un demi-point de Fable sur CursorBench 3.2 et dépasse le meilleur résultat de Fable sur OSWorld pour environ un tiers du coût. Ces dernières mesures viennent d’Anthropic, donc j’accorde davantage de poids aux résultats indépendants présentés plus haut [1].

Que reproche-t-on à Opus 5 ? Il demande trop de supervision

Les critiques portent surtout sur le temps nécessaire pour superviser Opus, pas sur la qualité de son code.

L’exemple le plus clair vient d’un utilisateur qui lui attribue 100 % sur un ensemble de tâches de programmation réelles et juge son implémentation ainsi que sa discipline de test supérieures à tout ce qu’il avait vu jusque-là. Il le décrit pourtant comme « an incredible coder and really painful to work with » [4].

Cette différence entre la qualité du résultat et l’expérience de travail revient dans les fils négatifs, qui signalent régulièrement cinq problèmes.

Il perd de vue l’ensemble du système. Opus peut écrire du bon code pour une partie du projet, tout en prenant de moins bonnes décisions sur l’architecture, la conception existante et les composants qu’il faudrait réellement modifier. Un développeur raconte qu’il inventait de nouveaux mécanismes et préférait ses propres conventions à celles du dépôt. Pour son travail quotidien, il est revenu à Fable 5 et à une ancienne version d’Opus [5].

Il suppose au lieu de demander. Lorsqu’une information importante manque, Opus peut poursuivre avec une hypothèse plausible mais fausse. Le résultat paraît cohérent, mais résout le mauvais problème, ce qui donne à l’utilisateur le sentiment que le modèle ne l’a pas écouté [5].

Il annonce trop tôt que le travail est terminé. Opus dit avoir corrigé le problème, mais l’utilisateur retrouve le bug initial et parfois une nouvelle régression. Pendant un audit, le modèle a manqué 46 erreurs parce que son propre script les avait masquées. D’autres utilisateurs rapportent des affirmations de vérification alors qu’elle n’avait jamais eu lieu [6]. Présenter à tort le travail comme terminé coûte particulièrement cher pendant une migration ou une modification du déploiement.

Il donne trop de nouvelles. Opus raconte des actions ordinaires, rédige de longs comptes rendus et présente de petits détails comme des décisions importantes. Le testeur qui lui attribue 100 % décrit lui aussi sa communication comme nerveuse, pédante et fatigante à superviser [4].

D’anciennes instructions peuvent aggraver le problème. Au moins un utilisateur a corrigé ces difficultés en réécrivant les instructions et les mémoires de projet conçues pour Opus 4.x [7]. Ces fichiers demandent souvent de tout vérifier deux fois, de préparer des plans détaillés et de créer des sous-agents. Comme Opus 5 prend déjà volontiers l’initiative, ces consignes supplémentaires peuvent le pousser trop loin.

Le guide de prompting d’Anthropic décrit presque la même liste. Il indique qu’Opus 5 raconte davantage son travail, le vérifie de lui-même et crée plus facilement des sous-agents. Il peut aussi élargir le périmètre, ajouter des étapes non demandées et décider seul de ce que la tâche devrait inclure. Anthropic recommande de fixer clairement les limites, de plafonner le nombre de sous-agents et de demander explicitement des comptes rendus plus courts [8].

Les témoignages positifs sont tout aussi crédibles. Un testeur qui utilisait surtout des tâches intellectuelles et professionnelles a trouvé qu’à effort faible ou moyen, Opus surpassait Sonnet 5 et Opus 4.8. Seul Fable restait régulièrement devant, et uniquement sur les problèmes les plus difficiles [9].

Pourquoi les benchmarks et les utilisateurs divergent-ils ? Ils ne mesurent pas le même travail

Les benchmarks et les projets réels ne mesurent pas la même chose, donc les deux types de résultats peuvent être justes. Un benchmark vérifie si le résultat final passe, tandis qu’un projet montre aussi si le modèle a choisi le bon problème, s’il a fallu le corriger plusieurs fois et s’il a rendu compte de son travail honnêtement.

Cette différence compte pour interpréter le résultat d’Anthropic sur Frontier-Bench, qui dépasse le double du score d’Opus 4.8. Anthropic a utilisé un harness mini-SWE-agent précis et calculé une moyenne sur cinq tentatives par tâche [1]. La méthode est raisonnable, mais la moyenne réduit l’effet des sessions exceptionnellement bonnes ou mauvaises, qui sont souvent celles que les utilisateurs remarquent le plus.

Un résultat indépendant explique les plaintes plus directement. Sur AA-Omniscience, Artificial Analysis a trouvé Opus 5 plus exact qu’Opus 4.8, mais aussi plus disposé à répondre quand il n’était pas certain. Selon le barème de ce benchmark, son taux d’hallucination atteignait environ 50 % [2]. Cela ne signifie pas que la moitié d’une réponse ordinaire d’Opus est inventée, car le test pose volontairement des questions que les modèles ne comprennent parfois qu’en partie. Le résultat suggère plutôt un compromis : un modèle qui continue malgré l’incertitude peut résoudre plus de tâches, mais aussi commettre davantage d’erreurs avec assurance.

Opus 5 coûte-t-il vraiment 50 % moins cher ? Seulement par token

Le prix d’Opus 5 est bien divisé par deux pour chaque token, mais une tâche terminée n’est généralement pas 50 % moins chère. Claude Platform Docs affiche des tarifs API de 5 $ par million de tokens en entrée et 25 $ en sortie pour Opus, contre 10 $ et 50 $ pour Fable [10].

• Opus 5
• Fable 5

Afficher les données en tableau

Type de token	Opus 5	Fable 5
Entrée	5 $/MTok	10 $/MTok
Sortie	25 $/MTok	50 $/MTok

L’écart se resserre lorsque l’on mesure la tâche entière. Artificial Analysis a dépensé 2,03 $ par tâche avec Opus 5 sur l’ensemble de ses évaluations, contre 2,75 $ avec Fable. L’économie tombe donc à 26 % [2]. Un utilisateur de Reddit a observé un écart encore plus faible sur deux grandes tâches de programmation : 106,69 $ pour Opus et 118,46 $ pour Fable, soit environ 10 %. Il jugeait le résultat de Fable nettement meilleur, et Opus a coûté plus cher sur la seconde tâche [11].

La comparaison utile porte sur le coût d’un résultat accepté, pas seulement sur le prix de chaque token. Le test de deux tâches mené par une seule personne ne permet pas d’établir un coût moyen, mais il montre comment la remise peut disparaître lorsque des étapes inutiles, des appels d’outils supplémentaires, du code non demandé et des cycles de correction consomment des tokens. Si Fable doit encore vérifier le résultat, il faut ajouter ce coût.

Pourquoi chaque version d’Opus paraît-elle différente ? Son comportement change

Le comportement de chaque version d’Opus peut changer assez pour frustrer les utilisateurs dont les prompts fonctionnaient avec la précédente. Les documents d’Anthropic décrivent plusieurs de ces évolutions.

Les versions ne suivent pas une progression régulière vers toujours plus d’initiative. Les annonces d’Anthropic fournissent les dates [12] [13] [14] [1], tandis que ses recherches sur les valeurs des modèles aident à expliquer les changements de comportement. Cette étude associe Opus 4.6 à la déférence, à la concision et à l’exécution, puis 4.7 à la prudence, à la profondeur et à la franchise [15].

Les notes de migration rendent la différence plus concrète. Opus 4.7 suivait les instructions plus littéralement, contredisait plus volontiers l’utilisateur et effectuait moins d’appels d’outils à faible effort. Anthropic avertissait aussi que d’anciens prompts pouvaient mal fonctionner avec cette version [13]. Opus 4.8 a ensuite réduit les commentaires et explications excessifs de 4.7 [14], avant qu’Opus 5 ne reparte nettement vers davantage d’initiative [8].

Le problème pratique est que chaque changement de comportement peut rendre inadaptées des instructions écrites pour un ancien modèle. Davantage de planification et de vérification pouvait rendre Opus 4.6 plus fiable, mais les mêmes consignes peuvent pousser Opus 5 à trop planifier, trop commenter et effectuer du travail non demandé. Cela aide à comprendre pourquoi la réécriture d’anciennes instructions de projet résout autant de problèmes [7].

Les réactions de la première semaine évoluent aussi avec le temps. Opus 4.8 avait suscité des plaintes similaires lors de sa sortie [16]. Neuf semaines plus tard, certains utilisateurs le décrivaient pourtant comme le modèle stable qu’ils voulaient retrouver [17]. Cinq jours de témoignages peuvent révéler des modes d’échec utiles, mais ne suffisent pas pour rendre un verdict définitif.

Anthropic a-t-il discrètement dégradé Opus ? Je n’ai trouvé aucune preuve

Je n’ai trouvé aucune preuve qu’Anthropic ait remplacé discrètement les poids du modèle Opus. L’expérience peut malgré tout se dégrader, car le traitement des requêtes, le harness du produit et le contexte de l’utilisateur peuvent tous changer indépendamment.

Les poids du modèle. Anthropic indique que les identifiants d’API sans date de Claude 4.6 et des versions ultérieures renvoient à des snapshots fixes. Les poids ne sont donc pas remplacés sous le même identifiant [18]. Cette gestion documentée des versions ne va pas dans le sens d’un remplacement silencieux des poids.

Le traitement des requêtes. Le routage, les classifieurs de sécurité et les modèles de secours peuvent changer même lorsque l’identifiant du modèle reste identique. Anthropic précise que certaines requêtes de cybersécurité signalées à Opus 5 peuvent être traitées par Opus 4.8, y compris dans certaines évaluations publiées [1]. Deux requêtes adressées au même identifiant peuvent donc suivre des traitements différents. OpenAI a rencontré sa propre version de la question du risque cyber, que j’examine dans ce qu’OpenAI a confirmé sur Astra et pourquoi l’entreprise a freiné ses travaux.

Le harness du produit. Le bilan d’avril 2026 d’Anthropic décrit trois régressions de Claude Code qui ont largement épargné l’API. L’effort par défaut est passé silencieusement de high à medium entre le 4 mars et le 7 avril. Du 26 mars au 10 avril, un bug de contexte supprimait à plusieurs reprises d’anciens raisonnements après une période d’inactivité. Enfin, du 16 au 20 avril, un system prompt a limité la longueur des réponses et réduit d’environ 3 % les performances dans les évaluations de programmation [19]. Les limites d’utilisation entrent dans la même catégorie : le quota hebdomadaire réduit de Claude Code après la fin d’une promotion relève de l’offre, pas du modèle.

Votre propre contexte. D’anciennes instructions dans CLAUDE.md, des mémoires enregistrées ou une longue session peuvent aussi modifier le comportement du modèle. Dans ce cas, le snapshot reste identique, mais pas l’expérience de travail.

La dégradation signalée peut donc être réelle et parfois reproductible, même lorsque le diagnostic est faux. Dans de nombreux cas, c’est le produit, la configuration ou le contexte qui a changé, pas les poids du modèle.

Anthropic adopte la même répartition : Opus exécute, Fable conseille

Anthropic utilise la même répartition de base que ma comparaison entre employé et patron. Son outil Advisor associe un exécutant moins cher à un modèle plus puissant qui donne la direction, et sa documentation présente Opus 5 comme exécutant et Fable 5 comme conseiller.

Le conseiller peut lire la session en cours, proposer un plan et corriger le travail pendant la tâche. Anthropic le recommande donc pour la conception, l’architecture et l’évaluation des risques. Il doit être au moins aussi performant que l’exécutant, mais le solliciter davantage n’améliore pas automatiquement le résultat : la documentation prévient qu’un trop grand nombre d’appels ralentit la tâche et augmente son coût sans l’améliorer [20].

responsable

• Vous objectif, contraintes, critères d'acceptation

fixe la direction

direction

• Fable 5 architecture, tâches bien délimitées

tâches bien délimitées

exécution

• Opus 5 code, tests, vérification

implémentation et résultats des tests

relecture

• Fable 5 vérification aux étapes clés

Cette organisation donne une responsabilité claire à chaque modèle. Vous fixez l’objectif et les contraintes, Fable prépare le plan et vérifie les étapes importantes, puis Opus réalise le travail délimité à un prix par token inférieur. J’ai depuis appliqué cette répartition à de grandes fonctionnalités multi-agents et confronté le résultat à Codex dans ma comparaison entre Claude et Codex sur les grandes fonctionnalités.

Cette comparaison a ses limites. Anthropic ne considère pas Opus comme incapable de planifier, et Claude Code comprend un mode officiel opusplan dans lequel Opus planifie pendant que Sonnet exécute [21]. Fable n’est pas non plus un patron parfait. Son guide de prompting avertit qu’il peut trop planifier, refactorer sans autorisation et transformer une petite tâche en grand chantier. Lui expliquer pourquoi une modification est nécessaire l’aide à rester concentré [23].

Malgré ces limites, Anthropic positionne les modèles différemment. L’entreprise recommande Fable 5 lorsqu’il faut les meilleures capacités possibles et présente Opus 5 comme le meilleur rapport entre prix et performances pour les agents de programmation complexes [10]. Au lancement de Fable, Anthropic indiquait aussi que son avantage augmentait à mesure que les tâches devenaient plus longues et plus complexes [22]. Quand Anthropic a livré le Fable suivant, j’ai comparé Fable 5.1 et Opus 5 sur les longues tâches d’agents et sur le prix.

Cette répartition apparaît également dans l’analyse menée par Anthropic sur environ 400 000 sessions Claude Code de quelque 235 000 utilisateurs. Les humains prenaient près de 70 % des décisions de planification, tandis que les agents assuraient environ 80 % des décisions d’exécution. Les utilisateurs expérimentés déclenchaient en moyenne 12 actions d’agent et 3 200 mots, contre 5 actions et 600 mots chez les novices. Le taux de réussite vérifié était d’environ 15 % chez les novices, puis de 28 à 33 % à partir du niveau intermédiaire [24]. Un modèle plus proactif ne supprime pas le besoin d’une direction claire.

Comment j’utiliserais Opus 5 : délimiter la tâche et vérifier le résultat

Je confierais à Opus des tâches d’implémentation bien délimitées et laisserais à Fable les orientations incertaines, l’architecture et les vérifications à haut risque.

Voici comment je choisirais entre les deux aujourd’hui, d’après les résultats et les témoignages disponibles. Je pourrai revoir ce tableau après une utilisation plus directe. Cette utilisation plus directe est maintenant racontée dans pourquoi Opus 5 n’est pas aussi mauvais qu’on le dit.

Tâche	Modèle
Bug clair, avec reproduction et test	Opus 5
Fonctionnalité délimitée avec critères	Opus 5
Refactorisation vers une architecture connue	Opus 5, puis relecture par Fable
Cause racine incertaine entre plusieurs systèmes	Fable 5 pour le plan, puis Opus 5
Nouvelle architecture faite pour durer	Fable 5 d’abord
Longues sessions avec plusieurs flux d’agents	Fable 5 comme orchestrateur
Migration à haut risque	Conception avec Fable, exécution avec Opus, audit par Fable

Avant de changer de modèle, je modifierais d’abord la configuration. Je laisserais le thinking activé : c’est le réglage par défaut, un faible effort avec thinking donne de meilleurs résultats que sa désactivation pour un coût similaire, et le désactiver peut provoquer un comportement inhabituel pendant les appels d’outils [8]. Je commencerais avec un effort faible et l’augmenterais lorsque la tâche demande plus de raisonnement, au lieu d’utiliser xhigh par défaut. Artificial Analysis a mesuré un écart important entre les réglages faible et maximal [2].

Pour comparer les modèles correctement, utilisez leurs identifiants complets, car les alias peuvent changer [21]. Je supprimerais aussi toutes les instructions ajoutées pour compenser les défauts d’Opus 4.x avant d’évaluer Opus 5 [8].

Je partirais de ce system prompt plutôt que de l’ancienne consigne « sois exhaustif et proactif » :

Implement only the requested task.
Follow the existing architecture and conventions in the repository.
Do not redesign surrounding systems or refactor unrelated code
unless the acceptance criteria require it.

Before editing, state the concrete acceptance criteria.
Do not report the task as complete unless each criterion has been
verified against actual build, test, or tool output.

Do not create subagents for work you can do directly.
If you notice an unrelated problem, mention it at the end
without changing it. Keep progress updates short.

Ce prompt ne transformera pas Opus en Fable, et ce n’est pas le but. Opus 5 donne le meilleur de lui-même lorsque la tâche possède des limites et des critères d’acceptation clairs. Il peut alors fournir un excellent travail pour un prix par token inférieur. Lorsque l’objectif est flou, le modèle peut au contraire effectuer du travail supplémentaire, formuler des suppositions avec assurance et présenter à tort un travail inachevé comme terminé.

C’est pourquoi j’utiliserais Opus comme employé, pas comme patron. Fable est aujourd’hui meilleur pour fixer et vérifier la direction, mais l’objectif doit toujours venir de vous.