« Supprimez juste vos instructions » n'est pas un conseil que je peux suivre
Claude Opus 5 est un meilleur modèle qui produit un travail moins bon dans mon système. Le correctif consensuel me demande de jeter ce qui rend le système digne d'intérêt.
Claude Opus 5 est sorti le 24 juillet. Sur tous les benchmarks qui comptent, il bat Opus 4.8. SWE-bench Pro est passé de 69,2% à 79,2%. Le benchmark de codage de pointe d'Anthropic a plus que doublé.
Je gère toute mon entreprise via Claude Code. Des dizaines de projets dans six domaines, environ trente compétences personnalisées, un système de mémoire, des agents de maintenance programmés, des règles strictes acquises au fil des mois de dysfonctionnements. Environ 20 000 tokens de contexte chargés avant que je tape un seul mot.
Quatre jours plus tard, je ne pouvais plus travailler avec. Deux sessions complètes — un site client et un produit SaaS — ont produit un résultat que je n'aurais pas mis en production.
J'ai maintenant lu la plupart de ce qui a été écrit à ce sujet, et le correctif consensuel est remarquablement uniforme : supprimez votre échafaudage d'instructions. Anthropic a supprimé 80% du prompt système de Claude Code. Le PDG d'Every a supprimé ses compétences et a rapporté que les choses étaient « considérablement meilleures. »
Je ne pense pas que ce conseil fonctionne pour moi, et je veux expliquer pourquoi attentivement, car je pense que beaucoup de gens s'apprêtent à supprimer quelque chose qui leur manquera.
Trois choses qui ont cassé
Il fait des erreurs avec assurance. Extrait de la fiche système d'Anthropic elle-même :
« Le modèle hallucine des affirmations factuelles légèrement plus qu'Opus 4.8, bien qu'il soit globalement plus précis. »
Lisez cela deux fois. Plus précis globalement, hallucinant davantage. Ce n'est pas contradictoire — ensemble, ils décrivent exactement ce que ressent l'utilisation quotidienne. Le même document note que le modèle « a affirmé avec confiance une réponse sur laquelle il était en fait incertain. » Un modèle manifestement erroné est peu coûteux. Un modèle qui se trompe tout en ayant l'air certain est coûteux, parce que vous arrêtez de vérifier.
Il s'arrête avant que le travail ne soit terminé. Kieran Klaassen, qui exécute un flux autonome :
« il n'arrêtait pas de rendre le contrôle à l'utilisateur. Même s'il s'agit d'un flux autonome. C'est extrêmement agaçant. »
Cela correspond à ce que j'ai vu. Des tâches remodelées plutôt qu'exécutées, un travail partiel présenté comme terminé, des objections là où le modèle précédent faisait simplement les choses.
Il parle trop. Le mieux documenté des trois, admis à plusieurs reprises dans le guide de migration d'Anthropic :
« Les réponses visibles par défaut et les livrables écrits sont plus longs sur Claude Opus 5 que sur les modèles Opus précédents, et réduire l'effort diminue le volume de réflexion sans raccourcir de manière fiable la réponse visible. »
Notez la seconde moitié. Le paramètre d'effort ne résout pas le problème.
Le mécanisme sur lequel tout le monde s'accorde
Voici la partie qui a recadré ma compréhension. Extrait du billet technique d'Anthropic, publié le jour du lancement d'Opus 5 :
« nous contraignions trop Claude Code, à la fois via notre prompt système et dans nos fichiers CLAUDE.md et compétences »
Ils ont supprimé environ 80% de leur prompt système. Dan Shipper a rapporté qu'Opus 5 « ne fonctionnait pas bien avec nos compétences et plugins existants », et que la suppression de ces compétences l'a rendu « considérablement meilleur. » João Queirós : « Les prompts simples ont produit des résultats plus prometteurs que les workflows matures et riches en instructions. »
Quatre sources indépendantes plus le fournisseur, pointant toutes vers la même variable : plus vous avez accumulé d'instructions, moins ce modèle performe.
Cela explique aussi pourquoi le discours semble divisé plutôt qu'unanime. Si votre CLAUDE.md fait douze lignes, Opus 5 est franchement meilleur et les critiques semblent dramatiques. Si vous avez passé des mois à construire un système, vous êtes dans une conversation complètement différente.
Là où le conseil consensuel s'effondre
Alors supprimez-les, disent tous. Voici le problème : mes instructions ne sont pas une seule chose. Ce sont deux choses qui ont l'air identiques dans un fichier texte et qui sont complètement différentes par nature.
Les compensations. Des instructions qui existent pour contrer une faiblesse du modèle. « Vérifie ton travail. » « Délègue par défaut » — que j'ai écrit à l'époque où le modèle précédent sous-déléguait. « Résume avant de continuer. » Ce sont des échafaudages au sens littéral : une structure temporaire autour d'un vide dans le bâtiment.
Les compensations peuvent être supprimées sans risque, et Opus 5 rend effectivement beaucoup d'entre elles obsolètes. Il s'auto-vérifie spontanément. Il délègue volontiers. Très bien. Supprimez.
La constitution. Des faits et des normes qui n'existent nulle part ailleurs. Qu'une build verte m'a déjà menti, donc la preuve signifie un vrai WebKit et une chaîne de marqueur dans le HTML, pas un HTTP 200. Quel hôte se trouve derrière quel projet. Quel client est cloisonné et lequel ne l'est pas. Ce que la typographie de cette marque est autorisée à faire. Quelle classe de défaillance m'a coûté le plus cher et ce qui la protège spécifiquement.
Ce n'est pas du harcèlement. C'est de l'information. Et ce n'est pas inférable à quelque qualité de modèle que ce soit, parce que ce n'est pas un problème de raisonnement — c'est une connaissance qui n'existe que dans mon entreprise. Un modèle plus intelligent ne le devine pas mieux. Il le devine avec plus d'assurance.
Le conseil consensuel ne fait pas la distinction entre les deux. Il dit « supprimez vos instructions », et les gens supprimeront les deux, parce que dans un fichier markdown, ils se ressemblent.
Je le sais parce que je l'ai fait. En suivant le guide de migration, j'ai supprimé les instructions de vérification de ma porte de finalisation. Le guide a raison de dire que « vérifie ton travail » est désormais redondant. Mais j'ai aussi supprimé les définitions de ce qui compte comme preuve dans ma pile — et les illusions de vérification sont, de loin, mon échec récurrent le plus coûteux. J'ai supprimé la barrière de protection construite spécifiquement contre mon propre pire mode d'échec parce qu'une recommandation générale m'a dit de réduire.
Deux sessions plus tard, j'ai tout annulé.
L'affirmation que je veux vraiment faire
Le cadrage partout est qu'Opus 5 a besoin de moins d'instructions. Je pense que c'est la mauvaise description de ce qui se passe.
Opus 5 est moins bon pour opérer sous instruction. Et pour toute une classe d'utilisateurs, opérer sous instruction n'est pas un surcoût — c'est tout le travail.
Je ne paie pas pour un modèle qui écrit du bon code générique. Je peux obtenir ça n'importe où maintenant. Je paie pour un modèle qui écrit du code qui s'intègre dans un système avec des conventions, des exigences de conformité, des règles de marque, des contraintes spécifiques au client, et un historique documenté de la façon dont les choses ont mal tourné ici auparavant. Supprimez les contraintes et vous n'avez pas amélioré mon résultat. Vous avez rendu le modèle plus à l'aise et mon résultat plus générique.
Alors quand je lis « supprimez vos compétences et ça marche considérablement mieux » — mieux pour quoi ? Pour la fluidité de codage sans contraintes, probablement. Pas pour produire un travail qui s'intègre dans mon système, parce que ce qui rend le travail adapté à mon système est précisément ce qui a été supprimé.
Je suis à environ 90% convaincu qu'Opus 5 sans mon échafaudage d'instructions n'atteindra jamais la qualité que j'obtiens avec. Non pas parce que le modèle est faible, mais parce que l'ingrédient manquant n'est pas l'intelligence. C'est la connaissance de mon entreprise, et il n'y a pas de quantité de capacité brute qui puisse la remplacer.
Ce que je fais, et ce que je suggérerais
Je suis de retour sur Opus 4.8 avec ma configuration précédente restituée à l'octet près. Pas comme une protestation — parce que ça marche, et j'ai des délais.
Je ne prétends pas qu'Opus 5 est un moins bon modèle. Les benchmarks sont réels, des personnes que je respecte rapportent de véritables gains, et j'ai changé deux variables à la fois — modèle et configuration, le même jour — donc je ne peux pas attribuer proprement mes propres résultats. C'est une limitation réelle de mes preuves, pas une précaution rhétorique.
Ce que j'affirme est plus précis : un meilleur modèle peut produire un travail moins bon dans un système mature, et l'échec est silencieux. Rien n'erre. Rien ne vous avertit. Vos instructions cessent simplement de signifier ce qu'elles signifiaient auparavant.
Si vous rencontrez cela, voici la séquence que j'utiliserais désormais :
- Triez avant de couper. Parcourez vos instructions et marquez chacune : est-ce une compensation pour une faiblesse du modèle, ou est-ce quelque chose que seulement moi sais ? Ce seul passage vaut plus que n'importe quelle heuristique de réduction.
- Supprimez les compensations librement. Surtout tout ce qui dit au modèle de vérifier, déléguer ou résumer. Ce conseil est valable.
- Défendez votre constitution. Les faits du domaine, les définitions de preuve, les normes de marque, les contraintes client. Si supprimer une ligne ferait produire un travail erroné à une nouvelle recrue compétente, elle reste.
- Changez une variable à la fois. Modèle ou configuration, jamais les deux. J'ai enfreint cela et perdu ma capacité à attribuer quoi que ce soit.
- Rendez-le réversible. Un commit, pour que le retour en arrière soit exact plutôt qu'approximatif.
- Votre propre schéma d'échec documenté prime sur tout conseil général d'un fournisseur. C'est celui que je tatouerais quelque part.
La partie inconfortable est que les compensations et la constitution semblent identiques quand vous les avez écrites. Chaque règle dans mon système existe parce que quelque chose a mal tourné une fois. Les distinguer après coup est le vrai travail — et « supprimez juste » suppose tranquillement que personne n'a rien qui vaille la peine d'être conservé.
Sources : Fiche système et guide de migration de Claude Opus 5 (Anthropic, juillet 2026) ; Blog technique d'Anthropic, 24 juillet 2026 ; Dan Shipper et Kieran Klaassen via X, juillet 2026 ; João Queirós, juillet 2026.
