Vos instructions IA ont une date de péremption. Faites-en l'audit avant qu'elles échouent.

Quelque part dans votre entreprise, il y a des instructions IA que personne n'a relues depuis qu'elles ont commencé à fonctionner. Le GPT personnalisé qu'utilise l'équipe des ventes, le prompt système derrière la boîte de courriels du soutien à la clientèle, le fichier d'instructions CLAUDE.md dans le dépôt d'un développeur, l'automatisation qui réécrit chaque nuit les descriptions de produits. Elles ont été écrites pour les modèles de l'époque, et souvent sur la défensive : JAMAIS ceci, TOUJOURS cela, suivez ces neuf étapes dans l'ordre. Anthropic affirme maintenant, dans sa propre documentation sur les modèles Claude 5, que des instructions de ce genre peuvent rendre un modèle plus récent moins bon. Le plus souvent, aucune erreur n'est signalée. Les réponses peuvent simplement devenir plus plates et plus littérales, et personne ne fait le lien avec un fichier écrit il y a un an.

Les instructions ont une date de péremption.

Anthropic le dit le plus clairement dans le guide de Fable 5, dans une liste de changements recommandés aux équipes qui passent au nouveau modèle : « Skills developed for prior models are often too prescriptive for Claude Fable 5 and can degrade output quality. » (en anglais dans l'original, comme toutes les citations d'Anthropic ci-dessous, suivies d'une traduction libre : les « skills » conçus pour les modèles précédents sont souvent trop prescriptifs pour Claude Fable 5 et peuvent dégrader la qualité des réponses).[3] Un skill, dans le vocabulaire d'Anthropic, est un fichier d'instructions enregistré que le modèle charge pour une tâche précise. La phrase vaut pour tous les prompts enregistrés, toutes les instructions d'assistants et toutes les règles d'automatisation qu'une entreprise fait rouler, parce que c'est le même artefact : du texte écrit pour guider un modèle, réglé sur le modèle qui était à jour au moment de l'écrire. Les guides ne décrivent que des modèles Claude : si votre GPT personnalisé tourne sur le modèle d'un autre fournisseur, voyez l'audit ci-dessous comme une méthode à mettre à l'essai, et non comme un constat sur ce modèle.

Le mécanisme est simple. Les anciens modèles avaient besoin qu'on les prenne par la main, alors on l'a écrit dans l'instruction. On détaillait les étapes parce que le modèle en sautait. On écrivait « vérifie ta réponse » parce que le modèle ne le faisait pas. On écrivait « n'utilise jamais de puces » parce que le modèle noyait chaque réponse sous les puces. Selon Anthropic, les modèles récents font ces choses d'eux-mêmes, et par endroits penchent maintenant dans l'autre sens. Le guide d'Opus 5 dit que le modèle « verifies its own work without being told to » (vérifie son propre travail sans qu'on le lui demande) et que les instructions de vérification explicites « cause over-verification » (causent de la survérification).[2] Le guide de Fable 5.1 dit que le modèle utilise maintenant moins le gras et recourt moins souvent aux listes, et vous invite à retirer les règles anti-formatage ou à les remplacer par une règle sur le moment où un format convient.[4] Une instruction qui corrigeait autrefois une faiblesse pousse maintenant contre une force.

C'est le problème d'affaires. Une automatisation brisée se signale d'elle-même. Une automatisation dégradée continue de tourner.

La seule suppression à faire cette semaine.

La plus grande partie de l'audit relève du jugement. Une partie n'en relève pas, et elle passe en premier parce qu'il s'agit d'exactitude plutôt que de polissage. Le guide de Fable 5 dit que les prompts, les skills ou les instructions de harnais qui demandent au modèle « to echo, transcribe, or explain its internal reasoning as response text may trigger the reasoning_extraction refusal category », et que le repli côté serveur « doesn't retry requests declined with reasoning_extraction; that refusal is returned to you. »[3] Le guide d'Opus 5 porte maintenant le même avertissement.[2] En français : demander au modèle de répéter, de transcrire ou d'expliquer son raisonnement interne dans le texte de la réponse peut déclencher la catégorie de refus reasoning_extraction, et le repli côté serveur ne relance pas les requêtes refusées pour ce motif : le refus vous est renvoyé tel quel. En clair : une ligne comme « expliquez-moi votre raisonnement à chaque étape » (en anglais, « walk me through your reasoning at each step ») ne rend pas seulement la réponse un peu moins bonne. Elle peut tout simplement faire refuser la requête, sans nouvelle tentative automatique sur un autre modèle.

Des lignes de ce genre sont courantes dans les prompts écrits il y a un an ou deux, parce que demander à un modèle de montrer son travail aidait autrefois. Le correctif est une recherche, pas un projet. Passez en revue chaque instruction enregistrée à la recherche de formulations qui demandent au modèle de raconter ou de rejouer sa réflexion : « your reasoning », « your thinking », « thought process », « out loud », « chain of thought », « show your work ». Ajoutez les équivalents qu'une équipe francophone aurait aussi pu écrire (ces ajouts sont de nous, pas d'Anthropic) : « votre raisonnement », « votre réflexion », « à voix haute », « chaîne de raisonnement », « montre ton travail ». Lisez chaque résultat en contexte. Une demande de justification en une ligne, ou des hypothèses que le modèle a posées, est correcte : c'est un livrable. Une demande de rejouer le raisonnement lui-même est la ligne à réécrire. Si votre application a réellement besoin de voir le raisonnement, la réponse d'Anthropic est de lire la sortie de réflexion structurée du modèle par l'API, pas de la demander dans la réponse.

Gardez la conséquence, coupez la méthode.

Au-delà de cette suppression, c'est ici qu'un résumé des guides peut dérailler, même un bon : le relais qui nous y a envoyés l'a fait.[6] La lecture tentante est un rechercher-remplacer : retirer chaque « jamais », chaque « toujours », chaque liste numérotée. Ce n'est pas ce que disent les pages d'Anthropic, et le faire peut supprimer les lignes qui vous protègent.

Prenez l'exemple du fournisseur lui-même. Sous « Add context to improve performance » (ajouter du contexte pour améliorer la performance), le guide commun à tous les modèles présente une instruction plus faible et une plus forte :[1]

Le bloc ci-dessus est en anglais, tel qu'il apparaît dans le guide. En français : « N'utilisez jamais de points de suspension » devient « Votre réponse sera lue à voix haute par un moteur de synthèse vocale; n'utilisez donc jamais de points de suspension, puisqu'il ne saura pas les prononcer ». La version plus forte dit encore jamais. Ce qui a changé, c'est que la règle porte maintenant sa raison, et le guide ajoute que le modèle « is smart enough to generalize from the explanation » (est assez intelligent pour généraliser à partir de l'explication). Le remède à une règle impérative est d'ajouter le pourquoi, pas d'adoucir le mot. La même page dit encore de « provide instructions as sequential steps using numbered lists or bullet points when the order or completeness of steps matters. »[1] (fournir les instructions sous forme d'étapes séquentielles, en listes numérotées ou à puces, quand l'ordre ou l'exhaustivité des étapes compte). Les étapes ne sont pas interdites. Ce sont les étapes imposées là où l'ordre n'a pas d'importance qui posent problème, parce qu'elles substituent votre découpage de la tâche à celui du modèle.

La question d'audit pour chaque règle est donc étroite : cette ligne encode-t-elle une conséquence, ou une méthode ? La page commune à tous les modèles propose aussi un test pour le fichier entier : « Show your prompt to a colleague with minimal context on the task and ask them to follow it. If they'd be confused, Claude will be too. »[1] (montrez votre prompt à un collègue qui a un minimum de contexte sur la tâche et demandez-lui de le suivre; s'il ne s'y retrouve pas, Claude non plus).

Ce qu'a trouvé notre propre audit.

Nous avons fait l'audit de notre propre boîte à outils le 12 septembre 2026 : 163 fichiers d'instructions, environ 200 000 mots, la plupart écrits plus tôt dans l'année pour la génération précédente de modèles. 116 des fichiers actifs sont des fichiers que nous avons écrits nous-mêmes; les autres viennent de projets en amont, que nous avons comptés et laissés intacts. Ces 116 fichiers contiennent 1 092 lignes comportant never, always, must ou do not (les mots recherchés, en anglais). Un échantillon aléatoire de 50 de ces lignes, codé à la main, a donné 35 vraies instructions, le reste étant des descriptions, des cellules de tableau et des citations. Extrapolé, cela fait environ 760 règles impératives.

À peu près la moitié des règles disaient déjà pourquoi, et celles-là sont correctes. Le reste se divise inégalement. Environ le quart des règles sans raison étaient des garde-fous : pas de chiffres inventés, pas de documents de clients envoyés à des services hébergés sans consentement, pas de fusion en production sans humain, rien d'envoyé sans approbation, aucune promesse de classement garanti. Ceux-là gardent le mot jamais. Il faut écrire la conséquence à côté, parce qu'un modèle qui sait qu'une règle existe pour prévenir un incident de confidentialité l'applique plus judicieusement dans les cas limites que celui qui sait seulement que la règle existe. Les trois autres quarts étaient de la méthode : toujours produire les six sections, ne pas montrer de code tout de suite, toujours préserver l'utilisabilité. Ce sont les candidats à couper ou à expliquer, et c'est la prescription contre laquelle le guide de Fable 5 met en garde.

Deux constats ont compté plus que les chiffres. D'abord, les fichiers les plus denses ont mérité leur densité. Les deux fichiers comptant le plus de règles par mot étaient des pipelines ordonnés où le mauvais ordre avait déjà livré un bogue, et presque chaque règle y portait sa raison sur la même ligne. C'est le schéma qu'approuve la page commune à tous les modèles. Ensuite, les règles sans raison venaient d'un seul endroit. Le gabarit que nous utilisons pour créer de nouveaux outils comportait une section « Hard rules » (règles impératives) obligatoire et ne disait rien sur l'énoncé d'une conséquence, et 57 fichiers actifs avaient hérité du bloc. Corriger le gabarit a empêché le schéma de se propager. Les fichiers déjà écrits ont demandé une passe à part.

Ce qu'a changé une passe soignée.

Nous avons fait cette passe le même jour sur les onze fichiers que nous avons écrits et qui comptaient le plus de règles sans raison (deux autres de la liste sont maintenus en amont et ont été laissés intacts). L'instruction pour chaque fichier tenait en une phrase : pour chaque règle sans raison, écrire la conséquence ou supprimer la ligne, et ne garder la numérotation que là où l'ordre compte. Les règles sans raison ont été comptées à l'œil avant et après.

Lisez la colonne de longueur dans le bon sens. La passe a allongé les fichiers, de 8 % en tout, et c'est justement le but. Ce que les guides demandent, ce sont des prompts qui disent pourquoi, et ceux-là sont plus longs. La plus forte croissance s'est produite dans les deux fichiers de tests d'intrusion, qui sont surtout des garde-fous et n'énonçaient presque aucune raison avant la passe : les mots ajoutés sont les raisons. Une réécriture qui ressort plus courte et plus propre devrait vous rendre méfiant. L'échec habituel d'une réécriture en lot est un ensemble de fichiers qui se lit mieux et qui a perdu discrètement ses garde-fous.

Là où les guides du fournisseur se contredisent.

Une raison de plus de ne pas traiter ces pages comme un règlement à copier : deux d'entre elles, toutes deux encore listées parmi les modèles actuels d'Anthropic, donnent des instructions opposées sur la même question. La question, ce sont les sous-agents vérificateurs, c'est-à-dire une deuxième instance de modèle chargée de vérifier le travail de la première.

Le relais que nous avons regardé fond les deux en une seule règle (supprimer les revérifications), ce qui revient à appliquer partout la moitié Opus 5.[6] Appliquez-la à un long travail autonome sur Fable 5 et vous retirez quelque chose qu'Anthropic recommande pour ce modèle. Les pages elles-mêmes indiquent la voie. Le guide commun dit que, lorsqu'une technique nomme un modèle précis, il faut « treat it as measured on that model and re-check it against your own evals before applying it to another. »[1] (la traiter comme mesurée sur ce modèle et la revérifier avec vos propres évaluations avant de l'appliquer à un autre). Les deux cas diffèrent aussi par leur forme : une tâche courte et bornée qui reçoit une deuxième passe redondante, contre une longue exécution où les erreurs s'accumulent et où un vérificateur à contexte neuf attrape ce que l'autorévision manque. Ce dernier point fait écho à notre note sur les juges IA : un modèle qui vérifie sa propre sortie est le vérificateur le moins indépendant qu'on puisse engager.

Notre lecture de travail : sur une tâche courte et bornée sur Opus 5, laissez tomber le vérificateur supplémentaire, comme le dit son guide; sur une longue exécution autonome sur Fable 5, gardez-le et donnez-lui un contexte neuf, comme le recommande ce guide. Sur tout autre modèle, mettez les deux à l'essai. Voyez-y une lecture plutôt qu'une règle. Elle illustre aussi un point plus large : ces pages sont des notes de migration pour des modèles précis, écrites par un fournisseur qui les révise sans préavis. Testez ce qu'elles vous disent sur votre propre travail.

Ce que ceci ne prouve pas.

Les quatre guides ne publient aucun chiffre. « Reduces wasted tokens with no loss in quality » (le guide d'Opus 5, à propos du retrait des instructions de vérification)[2] et « drop substantially with no measurable change in task success » (le guide de Fable 5.1, à propos des ajouts non demandés une fois une consigne de portée ajoutée : baissent substantiellement sans changement mesurable du taux de réussite des tâches)[4] sont des affirmations sur les évaluations internes d'Anthropic, sans chiffres à l'appui. Elles sont crédibles comme direction, et les pages elles-mêmes vous disent de les vérifier avec vos propres évaluations. Le même fournisseur dit aussi qu'Opus 5 « performs well out of the box on existing Claude Opus 4.8 prompts » (donne de bons résultats d'emblée avec les prompts existants de Claude Opus 4.8) : l'avertissement sur la dégradation est le plus fort dans le guide de Fable 5, et son effet dépend du modèle que vous utilisez.[2]

Notre audit compte des instructions, pas des résultats. Nous avons mesuré combien de règles n'avaient pas de raison et ce qu'une passe leur a fait. Nous n'avons pas mesuré si nos outils font un meilleur travail ensuite. Cela exige un avant-après sur des tâches réelles, que nous n'avons pas fait.

Le 46 % est une estimation d'échantillon. Il repose sur 35 instructions, trouvées dans un échantillon aléatoire de 50 lignes, avec une marge d'environ ±16 points. « À peu près la moitié » est la conclusion; le chiffre précis, non.

Nos fichiers ne sont pas les vôtres. Environ 160 fichiers écrits par une seule équipe, surtout pour des opérations de développement et de marketing. Une entreprise qui a trois prompts enregistrés verra un mélange différent. Les questions à poser à chaque ligne sont les mêmes.

Les noms de modèles vieillissent vite. Tout ceci décrit Opus 5, Fable 5 et Fable 5.1 tels que documentés le 12 septembre 2026. Depuis, la page commune à tous les modèles a ajouté des guides pour Opus 5.5 et Sonnet 5.5, que cette note ne couvre pas.[1] Chaque version apporte sa propre note de migration, et certaines des instructions correctes d'aujourd'hui se retrouveront sur l'une de ces listes.

Si votre équipe fait rouler des prompts enregistrés, des assistants personnalisés ou des automatisations écrits avant les modèles de cette année, le formulaire de contact est la voie la plus rapide. Dites-nous ce que vous faites rouler, et nous vous enverrons gratuitement un avis écrit sur le point de départ de l'audit.