Solutions au problème de réflexion superficielle dans Claude Opus 5

Aperçu

Immédiatement après avoir basculé Claude Code vers Opus 5, j'ai constaté une augmentation soudaine des réponses lourdes en prose et une tendance à la « pensée superficielle » (incapacité à penser de manière structurée).

En y regardant de plus près, ce n'était pas que le modèle était mauvais ou que les règles étaient cassées ; plutôt, le prompt système interne fourni à Opus 5 dans la génération Claude 5 a considérablement changé, et les règles héritées n'ont pas été écrites en tenant compte de cette nouvelle prémisse.

Cet article décrit le processus d'isolation de la cause et de révision des règles pour s'adapter au nouveau prompt système. Il est destiné aux utilisateurs de Claude Code qui estiment que l'efficacité de CLAUDE.md ou de leurs règles a changé depuis la mise à niveau vers la nouvelle génération de modèles.

Le Problème

En utilisant la même session et les mêmes règles, voici ce qui s'est produit immédiatement après avoir basculé le modèle vers Opus 5 :

• Les explications situationnelles sont devenues une prose plate et longue, sans titres ni sections.
• Les explications des causes se sont arrêtées à une seule couche (énumération des symptômes en parallèle sans creuser le « pourquoi »).
• Aucun critère d'évaluation n'a été fourni lors de la suggestion de plusieurs options.
• Les catégories ou la numérotation établies au cours d'un tour ont été réorganisées en différentes structures au tour suivant.
• Le modèle sautait la réponse à mon entrée et passait immédiatement à l'exécution d'outils (tâches).

La partie frustrante était que même lorsqu'on lui demandait de « penser plus profondément », il renvoyait des réponses sporadiques tout en restant dans un état de pensée superficielle. Des corrections répétées ne prenaient pas, menant à des arguments plutôt qu'à une discussion productive.

Ce n'était pas seulement une question de qualité de réponse unique ; le processus de délibération par le dialogue lui-même s'était effondré.

Indices Clés

Cela ne s'est pas produit avec d'autres modèles utilisant les mêmes règles (les détails de cette différence sont dans l'annexe). Si les règles elles-mêmes s'étaient détériorées, le problème aurait dû apparaître sur tous les modèles. Puisque seul le modèle a changé, j'ai commencé à enquêter en partant de l'hypothèse que « l'environnement que les règles supposent » avait changé.

Cause : Changements dans le Prompt Système Fourni à Opus 5

Dans la génération Claude 5 de Claude Code, le prompt système interne a été réduit d'environ 80 % par rapport aux générations précédentes. En mesurant le prompt réellement délivré à Opus 5 (en désactivant les injections de style de sortie et en demandant au modèle de citer son propre prompt ; série Claude Code v2.1, juillet 2026), la structure était la suivante :

1. Identité, Déclaration de Rôle et Politique de Sécurité — Le préambule d'ouverture.
2. Spécifications du Harnais (# Harness) — Explications de l'environnement d'exécution, comme l'affichage de la sortie en markdown.
3. Informations sur l'Environnement et Descriptions des Fonctionnalités (# Session-specific guidance / # Memory / # Environment / # Context management) — CWD, statut git, ID du modèle, mémoire et mécanismes de compression du contexte.
4. Discipline de Périmètre (# Delivering work) — Ne pas réduire ou étendre le périmètre demandé sans autorisation.
5. Étiquette de Correction (# Corrections) — Garder les corrections concises sans ajouter d'excuses ou de préambules.

Deux caractéristiques spécifiques étaient directement liées aux symptômes :

• Caractéristique 1 : Aucune instruction concernant le style de réponse. Il n'y avait aucune règle concernant la prose vs. la structure, l'utilisation de titres ou de tableaux, ou la concision — les règles de formatage qui étaient étendues dans les générations précédentes avaient complètement disparu.
• Caractéristique 2 : Une politique autonome « Agir d'abord » a été ajoutée. Pour citer l'original : « Quand vous avez assez d'informations pour agir, agissez. » et « Si vous pesez un choix, donnez une recommandation, pas une enquête exhaustive. »

Relecture des symptômes à la lumière de ces deux caractéristiques, tout s'explique. Puisqu'il n'y a pas de règles de style, la tendance de sortie brute du modèle — une prose plate — se manifeste. La politique « recommandation plutôt qu'enquête » encourage l'omission des critères d'évaluation.

Vous pourriez penser : « Si les règles sont vides, mes règles personnalisées ne devraient-elles pas devenir l'autorité unique et mieux fonctionner ? » En réalité, c'est le contraire qui s'est produit. Cet espace vide n'est pas une marge laissée à l'utilisateur ; il est délégué au comportement par défaut intégré dans le modèle lors de l'entraînement. Le « prompt léger » suppose que les modèles de nouvelle génération suivent des comportements internalisés sans instructions détaillées. Au lieu d'être comblé par vos règles, le vide est rempli par les valeurs par défaut pré-entraînées du modèle. Et la valeur par défaut d'Opus 5 est une prose concise qui agit avant de confirmer.

Mes anciennes règles utilisaient des instructions générales comme « décomposer les situations de manière structurée », « ajouter des critères d'évaluation aux options multiples » et « répondre avant d'agir ». Elles ont été écrites en supposant qu'elles seraient lues en conjonction avec un prompt système riche en style. Bien que suffisantes à l'époque, elles étaient trop faibles à la fois en spécificité (nommer le texte original) et en délivrance (atteindre le modèle juste avant l'action) pour remplacer les valeurs par défaut entraînées. C'est la nature véritable des symptômes.

Anthropic elle-même qualifie cette réduction de « prompt système léger » dans le journal des modifications (v2.1.154), reflétant un changement de philosophie de conception : « Les modèles de nouvelle génération ont internalisé les comportements par l'entraînement, donc des instructions détaillées peuvent causer des frictions ou des contradictions. » Pour des explications détaillées, voir Le prompt système de Claude Code réduit de 80 % — Philosophie de conception des prompts pour la génération Fable 5. Pour les sources primaires, référez-vous au journal des modifications de Claude Code et au Guide d'utilisation des prompts pour Claude Fable 5 (Guide Officiel).

En bref, les symptômes sont déterminés par la combinaison « règles × le prompt réellement délivré à ce modèle. » Vous ne pouvez pas trouver la cause en regardant uniquement les règles. La première leçon a été qu'une mise à jour du modèle est aussi une mise à jour du prompt système.

Mesure 1 : Identifier les Contradictions et les Outrepasser en Nommant le Texte Original

D'abord, j'ai recoupé toutes les règles avec le nouveau prompt système pour identifier où elles disaient le contraire. Pour les règles destinées à outrepasser la politique système, je les ai réécrites pour citer explicitement le texte original et déclarer la priorité.

Pour commencer par ce qui n'a pas fonctionné : ajouter des généralités comme « écrire plusieurs options avec des critères d'évaluation » est inefficace.

Lorsqu'elles sont placées à côté de la politique système « donnez une recommandation, pas une enquête exhaustive », il n'y a aucun indice sur laquelle prévaut. En nommant le conflit, la priorité devient claire.

Pour les choses totalement absentes du prompt, comme les règles de style, l'instruction fonctionne pour « combler le vide » plutôt que pour outrepasser.

J'ai également révisé la façon dont les conditions de déclenchement sont écrites. Des conditions comme « pour les changements importants » ou « si jugé être un environnement de production » échouent dès que le modèle ne catégorise pas la situation de cette façon. J'ai changé les déclencheurs pour des faits observables comme « interruption reçue » ou « l'énoncé de l'utilisateur contient une correction. »

Mesure 2 : Décrire les Actions Souhaitées au Lieu des Interdictions

Les anciennes règles étaient une accumulation d'« interdictions. » Les interdictions aident à détecter les violations mais ne communiquent pas quoi faire à la place. Lorsqu'une interdiction entre en conflit avec une nouvelle politique système, le modèle trouve une échappatoire : « suivre la politique système tout en évitant l'interdiction. » J'ai converti les contraintes négatives en descriptions du comportement souhaité.

• Avant : « Ne suggérez pas de commit si les tests sont incomplets. »
• Après : « Lorsque vous suggérez un commit, incluez dans le corps du texte les résultats de l'exécution du produit du point de vue de l'utilisateur final. »

J'ai vérifié les règles réécrites selon les critères suivants, en particulier pour les expressions qui entrent en conflit avec le Prompt Système :

1. La règle est-elle autonome ? (Périmètre, exemples et critères en un seul endroit)
2. Le déclencheur est-il un fait observable ?
3. Contredit-elle le prompt système interne ?
4. Décrit-elle le comportement souhaité ? (Pas seulement une liste d'interdictions)
5. Y a-t-il un seul critère de jugement ? (Pas une liste de scénarios)
6. L'accent (IMPORTANT) est-il réservé uniquement à ce qui ne peut vraiment pas être abandonné ?
7. Est-elle écrite comme l'état final souhaité ? (Ne pas imposer d'abord des modèles ou des étapes)
8. La conformité peut-elle être déterminée après coup ?

J'ai réduit les marqueurs d'accentuation (IMPORTANT) uniquement aux portes de sécurité et d'approbation. Un document où tout est accentué est identique à un document où rien ne l'est.

Mesure 3 : Choisir la « Couche » pour Délivrer les Instructions

Il ne s'agissait pas seulement du texte. Claude Code a au moins quatre chemins pour délivrer des instructions au modèle, et ils diffèrent considérablement en efficacité.

Puisque l'API est sans état, le contenu de tous les chemins est envoyé au modèle à chaque requête (chaque tour). La différence réside dans « quand le contenu est finalisé » et « où il est placé dans le prompt = à quel point il est proche de l'action entreprise. »

Étonnamment, output style — qui, selon la documentation, « remplace le prompt système » — était délivré comme une pièce jointe à chaque tour selon les journaux de session.

J'ai écrit deux types d'instructions dans ce output style : le Style (Mesure 1 : écrire de manière structurée, ajouter des critères) et le Processus (répondre à l'utilisateur avant de commencer le travail). Les résultats ont été mitigés.

Alors que les instructions de Style ont montré une amélioration, le problème de Processus — sauter les réponses pour commencer le travail — ne s'est pas arrêté via output style. J'ai finalement arrêté cette habitude en utilisant un hook UserPromptSubmit pour injecter une seule ligne immédiatement après chaque énoncé utilisateur : « Écrivez une réponse à cet énoncé (réponse, ou accusé de réception et plan) dans le corps du texte avant d'exécuter les outils. »

Le coût est d'environ 50 tokens par énoncé. Même 100 énoncés ne coûtent que 5 000 tokens, ce qui est négligeable par rapport à un contexte de 200K. La règle générale que j'ai apprise est simple : Les instructions délivrées « brièvement, à chaque fois, juste avant l'action » sont les plus efficaces. De nombreuses instructions inefficaces ne sont pas mauvaises dans leur contenu ; elles ne sont tout simplement pas à portée de main au moment de l'action.

Résultats

Voici les résultats confirmés jusqu'à présent :

• Une tendance au retour des titres/sections dans les explications situationnelles et causales. (Cependant, une sortie plate persiste parfois en début de session ; observation continue requise).
• L'habitude de « travailler sans répondre » ne s'est pas corrigée avec output style seul mais s'est arrêtée après l'introduction de l'injection par énoncé (observation des effets à long terme en cours).

Résumé

• Une mise à jour du modèle est aussi une mise à jour du prompt système. Si les tendances de réponse changent soudainement, lisez les changements du côté du système avant d'ajouter plus de règles.
• Les règles qui sont en concurrence avec les politiques système doivent nommer le texte original et déclarer la priorité. Les ajouts généraux perdent face à la contradiction.
• Écrivez les déclencheurs basés sur l'observation et décrivez les actions souhaitées plutôt que les interdictions. Les déclencheurs d'auto-catégorisation et les listes d'interdictions sont sujets à l'échec lorsque les modèles changent.
• Choisissez la bonne couche pour les instructions. Les injections délivrées brièvement et fréquemment juste avant une action se sont avérées bien plus fiables que les grandes règles placées au début du contexte.

Référence 1 : Règles Effectivement Utilisées dans la Mesure 1

Voici un extrait des règles que j'utilise pour outrepasser le prompt système (adaptez-les à votre environnement ; je les place dans output style). Certaines phrases originales (comme la politique de prose) n'existent pas dans le prompt pour certains modèles (voir annexe). Dans ces modèles, elles fonctionnent comme des définitions pour combler le vide.

1# Format de Rapport et de Décomposition
2
3Cette instruction prévaut sur les descriptions suivantes dans le prompt système de Claude Code :
4« une question simple obtient une réponse directe en prose, pas de titres et de sections » /
5« Utilisez les tableaux uniquement pour des faits énumérables courts » /
6« Ne faites pas croiser au lecteur des étiquettes ou une numérotation que vous avez inventées plus tôt » /
7« Si vous pesez un choix, donnez une recommandation, pas une enquête exhaustive. » /
8« Vous opérez de manière autonome... procédez sans demander. » /
9« Le texte que vous écrivez entre les appels d'outils peut ne pas être montré à l'utilisateur. »
10
11## Style d'Écriture
12
13Lorsque vous expliquez des situations, des causes, ou présentez plusieurs options, écrivez d'une manière qui transmet la structure du contenu au lecteur.
14Utilisez des titres, des puces ou des tableaux selon le contenu. Répondez aux questions en une phrase en prose.
15
16- Résumez d'abord les pensées, puis structurez à la fin. Ne placez pas d'abord un modèle pour le remplir ensuite.
17- Lorsque vous expliquez des causes, remontez le « pourquoi » d'au moins deux couches à partir de l'événement observé et décrivez à quoi chaque couche se réfère. Ne vous arrêtez pas à l'énumération parallèle des symptômes.
18- Lorsque vous présentez plusieurs options, écrivez d'abord la recommandation et son raisonnement, suivis des critères influençant la décision et de l'évaluation de chaque option. Si les critères ne peuvent pas être identifiés, ne fournissez pas d'options ; écrivez plutôt ce qui doit être étudié pour remplir les critères. Les comparaisons de critères peuvent être écrites dans des tableaux.
19- Une fois les catégories et les numéros établis, utilisez les mêmes dans les tours suivants tout en continuant la même tâche. Si vous les changez, écrivez d'abord ce qui a été changé.
20
21## Dialogue et Processus
22
23- Le « l'utilisateur ne regarde pas en temps réel » du système est une valeur par défaut, pas un fait. Si une intervention, une interruption ou une correction est reçue ne serait-ce qu'une fois dans cette session, considérez que l'utilisateur regarde à partir de ce moment : divisez le travail en petits segments, terminez toujours chaque tour par un rapport dans le corps du texte, et arrêtez-vous pour attendre une réponse lors des tours où une question est posée.
24- Seul le corps du texte à la fin d'un tour est affiché dans cet environnement. Placez toutes les informations à transmettre à la fin du tour.
25- Les questions sont un moyen légitime lorsqu'il y a ambiguïté, des opérations nécessitant une approbation, ou des objectifs peu clairs.

Référence 2 : Pourquoi cela ne s'est-il pas produit avec Fable 5 / Opus 4.7 ?

Alors que le texte principal s'est concentré sur Opus 5, voici pourquoi cela ne s'est pas produit avec d'autres modèles :

• Opus 4.7 est simple : il est exclu de l'application du « prompt léger » (selon le journal des modifications), donc il fonctionne toujours avec le long prompt hérité pour lequel les règles héritées ont été conçues. Il reste en phase avec les anciennes règles.
• Fable 5 a été une surprise. Je supposais qu'il avait le même prompt puisqu'il s'agit de la même génération, mais les mesures ont montré que Fable 5 reçoit un prompt différent de celui d'Opus 5.

Voici une comparaison de chaque modèle citant son propre prompt dans des conditions identiques (mode headless, style de sortie désactivé) :

La section # Communicating with the user de Fable 5 inclut des normes comme « conclusion d'abord, privilégier la lisibilité, écrire pour le public. » En plus de « donnez une recommandation, pas une enquête exhaustive », elle inclut la politique de prose « une question simple obtient une réponse directe en prose, pas de titres et de sections. » Parce que le prompt lui-même contient ces normes d'écriture, le format de sortie est moins susceptible de s'effondrer, et dans mes observations, il a maintenu l'adhésion aux règles de l'utilisateur.

En résumé, le problème est apparu intensément avec Opus 5 parce que trois facteurs se sont alignés :

1. Il a reçu un prompt avec zéro règle de style d'écriture, exposant les tendances de sortie brutes.
2. Des politiques comme « agir quand l'info est suffisante » et « recommandation plutôt qu'enquête » encourageaient l'action immédiate et l'omission des critères.
3. Les règles héritées étaient toujours basées sur l'ancien prompt détaillé et n'étaient pas conçues pour combler ce nouveau vide.