Opus 5 n’est pas aussi mauvais qu’on le dit

Opus 5 n’est pas aussi mauvais qu’on le dit. Après plus de cinq semaines à coder avec lui chaque jour, je retrouve encore la prose illisible, l’élargissement du périmètre, les fausses hypothèses et les régressions signalées en ligne. Mais avec un plan documenté, une tâche ciblée et des contrôles extérieurs à son message final, c’est un très bon développeur logiciel.

Pourquoi mon avis a changé : j’ai cessé de demander à Opus de tout faire à la fois

Mon avis s’est amélioré lorsque j’ai arrêté de demander à Opus de découvrir l’architecture et d’implémenter une grande fonctionnalité dans le même contexte. Dans mon bilan de la semaine de lancement, je le décrivais comme un bon agent d’implémentation difficile à superviser. Cinq semaines d’usage répété ont confirmé cette distinction et renforcé ma confiance dans son travail d’implémentation.

Lire des centaines de retours négatifs a influencé mon jugement plus que je ne l’imaginais. Ces témoignages m’ont appris quoi surveiller, mais chaque phrase maladroite ou modification inutile semblait aussi confirmer un verdict déjà rendu. La différence est devenue plus nette lorsque j’ai séparé les tâches mal cadrées de celles préparées par un plan. Opus rencontrait surtout des difficultés quand je demandais à une seule conversation de comprendre une grande fonctionnalité, de choisir l’architecture, de préserver toutes les contraintes, d’implémenter l’ensemble et de l’expliquer clairement. Ce prompt regroupait en réalité plusieurs tâches distinctes.

Une fois l’architecture et les limites fixées, j’ai confié l’implémentation à Opus et il a produit un travail solide. Il a suivi le code concerné dans tout le dépôt, effectué des modifications difficiles et repéré des conséquences qu’un modèle moins attentif aurait pu manquer. Dans une tâche bien délimitée, cette attention devient utile : Opus trouve les fichiers, les tests et les cas limites liés au comportement demandé.

Ce changement d’avis n’efface pas les défauts d’Opus 5. Il m’indique le rôle dans lequel ils sont le plus faciles à contenir.

Quels problèmes d’Opus 5 sont réels, et qu’est-ce qui aide ?

Les cinq groupes de critiques sont crédibles, mais ils n’ont pas tous la même gravité dans mon travail. Le problème de prose reste évident au quotidien. Les quatre autres font beaucoup moins de dégâts lorsqu’Opus reçoit un plan documenté, un périmètre d’implémentation réduit et une véritable étape de vérification.

Critique	Ce qui l’atténue	Ce qui subsiste
Prose difficile à lire	Limites de longueur et règles de langage simple	Opus reste moins clair que Fable dans mon usage
Élargissement du périmètre	Non-objectifs explicites et périmètre de fichiers réduit	Les consignes peuvent toujours être ignorées
Fausses prémisses	Recherche avant modification et questions explicites	Un relecteur doit vérifier la prémisse
Régressions ou faux achèvement	Critères d’acceptation, tests et revue du diff	Les contrôles choisis peuvent rester incomplets
Perte du plan	Plan enregistré, petites tâches et contexte plus propre	Chaque bloc doit encore être relu

Chaque mesure réduit le problème correspondant, mais aucune ne permet de se passer d’une revue indépendante.

1. Prose difficile : les limites aident, mais Fable reste plus clair

C’est la critique que je reconnais le plus vite. Opus peut assembler des mots corrects dans une phrase qu’il faut relire pour la comprendre, surtout dans les explications, les récapitulatifs et les longs fichiers Markdown. Des utilisateurs de Reddit ont décrit la même combinaison : phrases longues, structure peu claire et texte qui a techniquement un sens, mais reste épuisant à déchiffrer. [5] [6]

Ce qui aide : le guide d’Anthropic consacré aux prompts pour Opus 5 indique que les réponses destinées à l’utilisateur et les rapports écrits sont plus longs par défaut. Il recommande de fixer explicitement la longueur de ces deux types de contenu. [1] Des réponses plus courtes et une consigne directe en faveur d’un langage simple améliorent le résultat, sans donner systématiquement à Opus la clarté naturelle que j’obtiens avec Fable 5. Cette différence compte dans une conversation de planification. Elle compte bien moins lorsque le résultat attendu est une modification de code testée.

2. Élargissement du périmètre : des non-objectifs explicites gardent la tâche dans ses limites

Opus repère facilement les problèmes voisins, les abstractions possibles, les validations manquantes et les façons de rendre une petite modification plus complète. Cette attention est utile pendant un audit. Sur un correctif délimité, elle peut transformer une demande en refactorisation ou créer tout un processus autour d’un contrôle qui aurait dû prendre une seule commande. Anthropic avertit qu’Opus 5 peut élargir le périmètre d’une tâche, vérifier son travail à l’excès et déléguer trop facilement. [1]

Ce qui aide : j’énonce les non-objectifs aussi clairement que l’objectif. Les constats sans rapport avec la demande sont signalés, pas corrigés, et l’architecture existante reste en place sauf si les critères d’acceptation exigent un changement. Un auteur sur Reddit a observé une amélioration comparable après avoir remplacé d’anciennes instructions qui imposaient des corrections immédiates par une règle demandant de signaler les problèmes hors périmètre et de laisser l’utilisateur décider. [7] Ce témoignage montre que la configuration peut modifier le comportement. Il ne rend pas l’utilisateur responsable de chaque échec.

3. Fausses prémisses : la recherche révèle plus tôt les hypothèses

Le témoignage le plus clair sur Reddit décrit Opus inventant un ticket Linear, puis le citant dans les commentaires du code, les tests et les messages de commit. [8] Je n’ai pas rencontré exactement cet échec, mais j’en reconnais le risque : une fois qu’Opus a retenu une interprétation, il peut produire beaucoup de travail techniquement solide avant de remettre la prémisse en question.

Ce qui aide : une phase de recherche séparée rend les hypothèses visibles avant que le code en dépende. Le modèle doit encore recevoir une consigne claire lui demandant de poser une question lorsqu’une information manquante modifie la conception. Un relecteur doit aussi vérifier que l’implémentation répond à la demande d’origine, et non à une demande voisine.

4. Régressions : vérifiez le travail en dehors d’Opus

Plusieurs témoignages décrivent un correctif qui crée une régression, suivi d’un autre qui réintroduit le bug initial. Un fil Reddit résume le cycle ainsi : corriger le bug A, le casser en corrigeant le bug B, puis résoudre A une nouvelle fois. [9] Ces récits restent des anecdotes sans dépôt que je puisse examiner, mais ils décrivent un échec courant des agents : chaque correction locale paraît utile alors que l’ensemble s’éloigne des critères d’acceptation.

Ce qui aide : je n’accepte pas la simple déclaration du modèle selon laquelle la tâche est terminée. Ce sont les contrôles convenus qui tranchent : les tests concernés, le build, une lecture ciblée du diff et toute vérification manuelle exigée par la fonctionnalité. La planification aide Opus à choisir le travail. La vérification détermine si ce travail est fini.

5. Perte du plan : séparez la recherche de l’implémentation

Une grande fonctionnalité mélange la recherche, l’architecture, l’implémentation, le débogage et la revue dans un contexte qui ne cesse de grossir. Opus peut consommer la partie utile de ce contexte pendant son exploration, puis implémenter la décision à partir d’un souvenir condensé ou incomplet. Un témoignage nuancé sur Reddit est révélateur : son auteur trouvait Opus frustrant dans un grand dépôt existant, mais expliquait que le modèle avait créé une nouvelle extension Chrome en une session, effectué 17 commits et réussi une revue par Codex. [10] Le témoignage n’isole pas la cause, mais il montre que le même utilisateur obtient de bien meilleurs résultats sur un nouveau projet, avec moins de contexte hérité.

Ce qui aide : la documentation de Claude Code publiée par Anthropic indique que les performances peuvent baisser à mesure que la fenêtre de contexte se remplit, ce qui peut entraîner des consignes manquées et davantage d’erreurs. Pour les modifications incertaines ou portant sur plusieurs fichiers, elle recommande de séparer la recherche et la planification de l’implémentation. [2] Ce conseil vaut pour tous les modèles de code que j’utilise. Avec Opus, les conséquences apparaissent simplement plus vite lorsque je l’ignore.

Que prouvent vraiment 1 008 extraits négatifs sur Opus 5 ?

Le recueil montre que cinq types de critiques reviennent régulièrement. Il sert donc à décider des risques contre lesquels se protéger. Il recense des modes d’échec, mais ne constitue ni une enquête de satisfaction ni un classement des modèles.

J’ai recueilli 1 008 extraits datés du 23 juillet au 29 août 2026. Ils proviennent de 229 publications et de 779 commentaires répartis dans 294 fils Reddit distincts. Un commentaire et la publication à laquelle il répond ne sont pas deux tests indépendants, et plusieurs fils très actifs ont fourni de nombreuses entrées. Un horodatage précède d’un jour l’annonce publique d’Anthropic, datée du 24 juillet. Je traite donc ces dates comme des métadonnées de Reddit et non comme la preuve d’un accès anticipé. [14]

extraits négatifs

1 008

fils distincts

294

publications

229

commentaires

779

Une comparaison honnête de la popularité demanderait des échantillons équivalents pour Fable, Sol, les anciennes versions d’Opus et d’autres modèles, puis une correction selon le nombre d’utilisateurs et l’activité de chaque subreddit. Je ne dispose pas de ces échantillons. En revanche, mon recueil fournit un relevé détaillé des problèmes que les utilisateurs ont décrits à plusieurs reprises après une mauvaise session avec Opus 5.

J’ai regroupé les extraits selon l’échec décrit plutôt que de compter chaque étiquette libre comme un problème distinct. J’ai ainsi obtenu les cinq groupes présentés plus haut. Les écarts aux instructions et la consommation de tokens apparaissaient généralement comme une partie de ces problèmes, et non comme des résultats séparés. Ce regroupement m’a permis d’établir la liste pratique des protections que je cherchais.

Que peuvent vraiment corriger de meilleures instructions pour Opus 5 ?

De meilleures instructions peuvent réduire la verbosité, les vérifications inutiles, les délégations et l’élargissement du périmètre. Elles ne garantissent ni le respect du plan, ni que le modèle déclarera la tâche terminée à juste titre, ni une bonne prose, ni un raisonnement correct. Ce qui fait la différence n’est pas un prompt ingénieux, mais un contrat de tâche plus clair, soutenu par une méthode et des contrôles.

Quatre précisions changent le plus les résultats dans mon travail. Je nomme le résultat attendu, j’indique ce qui ne doit pas changer, je désigne l’architecture existante à suivre et je définis les preuves nécessaires pour considérer la tâche comme terminée. Pour une fonctionnalité étendue, ces détails viennent de la recherche et d’un plan d’architecture, pas d’une version plus longue de ma première idée.

Les instructions persistantes conviennent aux règles qui s’appliquent à toutes les tâches. Claude Code charge CLAUDE.md dans le contexte du projet. C’est donc un endroit adapté pour préciser que les problèmes hors périmètre doivent seulement être signalés, que les conventions existantes doivent être reprises et que l’achèvement exige les résultats réels des tests ou du build. Anthropic prévient toutefois que ce fichier fournit du contexte sans imposer une configuration, et que des instructions courtes et précises fonctionnent mieux qu’une longue collection de règles qui se recoupent. [3]

Cette limite compte, car même des utilisateurs attentifs rencontrent encore des échecs. Un fil Reddit vérifié décrit un fichier CLAUDE.md concis qui n’a pas été respecté. [12] De meilleures instructions augmentent les chances de réussite. Elles ne rendent pas l’utilisateur responsable d’une erreur du modèle.

C’est aussi pourquoi je ne dirais pas à un utilisateur mécontent de simplement apprendre à mieux rédiger ses prompts. Les retours positifs les plus convaincants portaient sur un changement de méthode autour d’Opus. Un utilisateur de Reddit a confié les exigences et la revue à Fable, puis transmis une spécification complète à Opus. La plupart des comportements indésirables ont alors disparu. [11] J’applique désormais la même séparation des rôles aux grands changements.

Comment j’utilise Opus 5 pour les grandes fonctionnalités

Je garde une conversation principale responsable du résultat et de l’architecture. Elle étudie le dépôt, demande aux agents spécialisés les informations manquantes, choisit la conception et rédige un plan qui couvre les systèmes concernés, les non-objectifs, les risques et les critères d’acceptation. Ce n’est qu’ensuite que des agents Opus prennent en charge l’implémentation, par blocs bien délimités.

Les agents ne reçoivent pas une consigne vague comme « développez la fonctionnalité ». Chacun obtient la partie du plan qui le concerne, les fichiers ou systèmes inclus dans son périmètre, le comportement à préserver, les contrôles à lancer et un point d’arrêt. La documentation d’Anthropic sur les sous-agents précise qu’un sous-agent travaille dans son propre contexte, puis renvoie un résumé à la conversation principale. Cela protège le contexte principal, mais oblige aussi le message de délégation à contenir les faits que l’agent ne peut pas déduire. [4]

Je préfère Fable 5 pour la conversation principale, car il communique plus clairement et garde une meilleure vue d’ensemble de l’architecture dans mes projets. Opus prend ensuite en charge une grande partie de l’implémentation. C’est ma préférence, pas un classement général, et mon abonnement Max 20x la rend en partie possible. Anthropic affiche ce forfait à 200 $ par mois, avec 20 fois la capacité de Pro par session. [13] Une méthode qui utilise un modèle haut de gamme pour la planification et plusieurs agents Opus pour l’exécution n’est pas accessible dans les mêmes conditions à tous les abonnés.

La même séparation reste utile si Opus est le seul modèle disponible. Dans ce cas, je sépare les étapes en changeant de conversation plutôt qu’en changeant de modèle.

Comment utiliser Opus 5 seul ?

Utilisez Opus pour l’ensemble du processus, mais ne lui demandez pas de tout réaliser en une seule exécution ininterrompue. Séparez la planification et la modification du code, conservez le plan validé, implémentez un bloc vérifiable à la fois et repartez avec un contexte plus propre lorsque la nature du travail change.

Pour une fonctionnalité encore incertaine, commencez en mode plan et demandez à Opus d’inspecter le dépôt sans le modifier. Le plan doit nommer les fichiers et systèmes concernés, expliquer l’approche choisie, consigner les questions en suspens et définir comment chaque bloc sera contrôlé. Relisez ce document avant l’implémentation. Anthropic recommande de séparer la recherche et la planification de l’implémentation lorsque l’approche reste floue ou que le changement porte sur plusieurs fichiers, tout en précisant qu’un petit correctif évident peut se passer de cette étape supplémentaire. [2]

Ensuite, ne confiez à la conversation d’implémentation que le premier bloc cohérent. Un bon bloc peut être relu et testé sans attendre la fonctionnalité entière. Si un développeur devait consacrer plusieurs semaines à cette fonctionnalité, découpez-la en parties testables séparément. Suivez les dépendances et les limites de vérification, pas un nombre arbitraire de prompts.

Conservez le plan hors de la conversation afin qu’il survive à une réinitialisation du contexte. Utilisez /clear entre les tâches sans rapport et confiez la recherche sur le dépôt à des sous-agents uniquement lorsqu’elle justifie un contexte isolé par son ampleur. Opus 5 a déjà tendance à déléguer, donc ajouter des agents n’améliore pas automatiquement le résultat. [1] Le but est de garder le contexte principal concentré sur la tâche, pas de créer autant d’agents que possible.

Enfin, jugez les preuves plutôt que l’assurance du message final. Lisez le diff, lancez les contrôles pertinents et comparez le résultat aux critères d’acceptation enregistrés. Si un bloc est incorrect, corrigez-le et vérifiez-le avant d’ajouter le suivant. Vous éviterez ainsi qu’une erreur locale ne provoque la réécriture de toute la fonctionnalité.

Ce qu’Opus 5 fait encore mal

Certains problèmes d’Opus 5 subsistent même avec une bonne méthode. Dans mon usage, sa prose reste plus difficile à lire que celle de Fable, il demande toujours plus de supervision que je ne le voudrais et des limites explicites ne garantissent pas qu’il les respectera.

Opus 5 fait désormais partie de ma méthode d’implémentation habituelle. Ce n’est pas mon modèle préféré pour la conversation principale sur l’architecture, et je ne le choisirais toujours pas pour écrire un article sans une révision exigeante. Une implémentation présentée avec assurance peut encore reposer sur une mauvaise prémisse. Je garde donc le plan et la revue finale hors du contexte de l’agent d’exécution.

Les critiques sur Reddit m’ont aidé à repérer les modes d’échec, mais elles n’ont pas suffi à déterminer si Opus pouvait fonctionner pour moi. Lors de la semaine de lancement, j’ai eu tort de confondre la qualité de la supervision avec celle de l’implémentation. Je ne confierais toujours pas à Opus la supervision d’un grand changement. En revanche, quand Fable garde le plan et la revue, je fais souvent confiance à Opus pour écrire le code.