Claude Opus 4.7 Semble Avoir Cassé Vos Prompts. Pas du Tout. Vous Avez Juste Raté les 2 Réécritures Qui Comptent.

9 min read

À chaque fois qu'un nouveau LLM sort, je lis le changelog. (Je suis le genre de type qui lit le manuel d'une débroussailleuse neuve. 🤓) C'est comme ça que j'ai capté le truc louche avec la panique autour d'Opus 4.7.

TL;DR. Si vous venez de passer à la 4.7, deux patterns dans vos prompts actuels vont effectivement foirer. Je vais vous montrer ce que j'ai corrigé en prod, et comment l'adapter à votre config. Tout le reste qu'on vous raconte sur "auditez tous vos prompts" c'est du bruit tiré des quatre mêmes points.

La doc Anthropic dit une ligne que personne ne relaie : les prompts écrits pour la 4.6 tournent très bien sur la 4.7 out of the box. La même doc dit aussi, explicitement, où ça ne marche pas. À deux endroits précis. Pas seize. Pas huit. Je vais les nommer, expliquer pourquoi la 4.7 les déclenche, et vous montrer comment patcher votre CLAUDE.md et vos prompts système en deux lignes.

Développeur tapant frénétiquement avec des fenêtres d'erreur tandis qu'un collègue lit calmement le manuel avec un sourire narquois dans un bureau en open space
Un dev panique, l'autre lit la doc. Devinez qui gagne ?

Je Lis Les Manuels. C'est Pourquoi Je Savais Que Le Tweet Était Faux.

16 avril. Opus 4.7 sort. En deux heures, mon feed déborde du classique : "Tout a changé", "Vous devez auditer tous vos prompts", "Le nouveau modèle est une autre bête". À la troisième heure, les guides de migration commencent à pleuvoir. Un déluge cette semaine-là. Tous recopiant les quatre mêmes points de la doc Anthropic, reformulés pour la voix maison.

Pendant ce temps, j'étais sur le site de doc. Pas sur Twitter. (Avouez, vous avez checké Twitter en premier aussi.)

Trois pages comptent : le guide de migration, la page "what's new", et la page des meilleures pratiques de prompting. Lisez-les dans cet ordre. La première vous dit ce qui a changé dans le comportement. La deuxième vous donne le vrai changelog, tokenizer inclus. La troisième cache la ligne qui annule 90% de la panique. Une phrase, enterrée dans les meilleures pratiques, qui dit basiquement que la 4.7 performe bien out of the box sur les prompts 4.6 existants.

Ce n'est pas "certains prompts vont bien". Ce n'est pas "vous n'aurez peut-être pas besoin de réécrire si vous avez de la chance". C'est le fabricant du modèle qui vous dit que l'hypothèse par défaut c'est : vos anciens prompts marchent. Les guides de migration que vous lisez partent de l'hypothèse inverse. Et l'écart entre ces deux positions, c'est là que vivent tous les mauvais conseils.

Donc la question devient la bonne. Pas "qu'est-ce que je réécris ?". La bonne c'est : où exactement la 4.7 arrête de se comporter comme la 4.6, et pourquoi ? La doc répond à ça. À deux endroits.

Le Mécanisme : La 4.6 Vous Couvrait

La 4.6 n'était pas un générateur de texte stupide. C'était un générateur coopératif. Quand vous écriviez un prompt techniquement incomplet, la 4.6 comblait silencieusement les trous pour vous. Deux types de trous, spécifiquement.

Premier type : appels d'outils implicites. Vous écriviez "vérifie la structure du projet avant de suggérer des changements" dans votre CLAUDE.md. La 4.6 glissait un appel Glob ou Read avant de répondre, même si votre instruction ne l'exigeait pas techniquement. Le mot "vérifie" pouvait signifier "invoque vraiment un outil" ou "considère mentalement". La 4.6 choisissait la première lecture. La plupart du temps.

Deuxième type : portée et exceptions implicites. Vous écriviez "préviens le client des délais de réapprovisionnement une fois par conversation". La 4.6 comprenait "une fois, mais rouvre si une nouvelle commande vraiment différente apparaît dans la session". Vous écriviez "n'utilise jamais de points d'exclamation". La 4.6 l'appliquait au texte généré, mais pas aux blocs de code ou au contenu d'avis cités, parce que supprimer la ponctuation d'avis verbatim serait absurde. Qui édite un avis client cinq étoiles ? La 4.6 inférait la frontière toute seule.

La 4.7 ne fait ni l'un ni l'autre. Elle lit votre instruction littéralement. Si vous n'avez pas dit "tu DOIS appeler l'outil", elle lit "vérifie" comme "considère". Si vous avez écrit "une fois par conversation" sans liste d'exceptions, elle applique "une fois" et passe à autre chose, nouvelle commande ou pas.

Anthropic documente ça dans le guide de migration sans édulcorer : le modèle n'étendra plus silencieusement une règle d'un cas à un cas similaire, et il ne devinera plus les requêtes que vous n'avez pas vraiment faites. C'est ça le changement. C'est tout le changement. Le reste (raisonnement plus rapide, moins d'appels d'outils par défaut, ton plus direct) découle de ce seul changement de posture.

Ce qui signifie que vos prompts n'ont pas cassé. Ils étaient toujours incomplets. La 4.6 colmatait les trous à la volée, et la 4.7 arrête de colmater.

D'autres analyses corroborent le mécanisme sous différents angles. Un deep-dive note que les prompts faibles masqués par la 4.6 remontent maintenant comme des lacunes visibles. Même conclusion, cadrage différent. La partie utile c'est qu'il y a exactement deux endroits où les lacunes comptent assez pour réécrire.

Réécriture #1 : Appels D'Outils Qui Étaient Des Suggestions

Allez ouvrir votre CLAUDE.md maintenant. J'attends.

Scannez-le pour des verbes qui sonnent actionnables mais ne sont pas contraignants. "Vérifie". "Considère". "Regarde". "Examine". Chacun d'eux est une suggestion du point de vue de la 4.7. Si l'action est critique, c'est-à-dire que l'étape suivante dépend vraiment de la sortie de l'outil, vous venez d'introduire un mode de défaillance silencieux.

Exemple concret de mon propre CLAUDE.md, nettoyé pour que ça se lise de façon générique. J'avais une règle qui disait "avant de suggérer des changements de code, vérifie la structure actuelle du projet". Sur la 4.6, ça produisait un appel Glob à chaque fois. Claude listait les fichiers, voyait ce qui était là, puis proposait des changements ancrés dans l'état réel. Sur la 4.7, même règle, même prompt, pas de Glob. Claude proposait des changements de mémoire. Parfois juste. Parfois complètement désynchronisé avec le repo, parce que le contexte de session était périmé et le verbe "vérifie" ne forçait pas un appel d'outil.

Pas un bug. Du littéralisme. "Vérifie" peut signifier "invoque un outil" ou "réfléchis-y". La 4.7 prend par défaut "réfléchis-y". Le fix prend deux lignes.

Remplacez l'instruction molle par une dure. Au lieu de :

Avant de suggérer des changements, vérifie la structure actuelle du projet.

Écrivez :

Avant toute suggestion de code, tu DOIS appeler Glob pour lister la structure actuelle du projet.
Ne te fie pas au contexte de session précédent pour la structure des fichiers.

Trois différences. "DOIS" au lieu d'un verbe mou. Outil nommé au lieu d'action générique. Négation explicite du comportement de fallback, qui ferme l'échappatoire.

Ça s'applique partout où un appel d'outil est critique. Votre agent tape une API partenaire avant de décider ? Nommez l'appel API. Votre bot support lit le flux CSV distributeur quotidien ? Nommez la lecture de fichier. Votre assistant WooCommerce interroge les enregistrements utilisateur avant de répondre ? Nommez l'outil base de données. À chaque fois que les données doivent venir d'un appel live, l'appel doit être non-optionnel dans le texte du prompt, pas dans la tête de la personne qui l'a écrit.

Caveat qui vaut la peine d'être distribué ici, pas à la fin : ce fix ne compte que quand l'appel d'outil est critique. Si vous vous fichez vraiment que Claude invoque l'outil ou devine depuis le contexte, laissez tomber. Certaines vérifications sont vraiment optionnelles. Faites-en un choix conscient, pas aveugle.

Principe plus large : outil appelé bat raisonnement inféré. Si vous voulez creuser ça, j'ai écrit pourquoi les CLI battent MCP pour les appels d'outils critiques il y a quelques mois. L'argument tient plus fort sous la 4.7.

Deux lignes. Premier fix fait.

Réécriture #2 : Celui Que Tout Le Monde Comprend Exactement À L'Envers

Voici une casse concrète de ma prod, la semaine dernière.

Je fais tourner un générateur de descriptions produit. Ancienne règle, qui shipait propre depuis des mois : "n'utilise jamais de points d'exclamation". Sur la 4.6, ça s'appliquait au texte généré, et évidemment pas aux avis clients cités en dessous de chaque produit. Parce que qui édite un avis cinq étoiles ? Le modèle savait. La frontière était implicite mais réelle.

Upgrade vers la 4.7. Même règle. Batch suivant de pages produit, mes blocs d'avis cités commencent à perdre les points d'exclamation. Les citations client qui disaient originellement "Meilleure affaire de l'été !!!" se lisent maintenant "Meilleure affaire de l'été". Aplaties. Ce qui est un petit problème de qualité pour les pages produit, et un vrai problème si vous faites tourner des avis verbatim pour des raisons légales ou de confiance. La source ne correspond plus à la citation.

Pas le modèle qui devient "pire". Le modèle qui est exactement ce que j'ai demandé. J'ai écrit "n'utilise jamais de points d'exclamation". La 4.7 a lu ça comme "jamais, nulle part, point final". Bien en intention, cassé en sortie.

Fix : écrivez la portée.

N'utilise jamais de points d'exclamation dans le texte produit généré.
Cette règle ne s'applique pas à l'intérieur des avis clients cités
tirés verbatim de sources externes.

Quatre lignes au lieu d'une. Zéro ambiguïté. Le JAMAIS est devenu plus fort, pas plus faible. Ce que j'ai fait c'est arrêter de demander au modèle de tracer la frontière pour moi.

Même pipeline. Règle différente. Celle-ci était plus chère avant que je la chope.

"Confirme la politique d'expédition une fois par conversation." Sur la 4.6, le modèle comprenait "une fois sous flux normal, mais reconfirme si une nouvelle commande est introduite, ou si le client passe de domestique à international en milieu de session". L'exception implicite était toujours là. Jamais écrite. Toujours inférée.

Sur la 4.7 : une fois. Point final. Quinze messages plus tard, le client évoque une commande complètement nouvelle vers un autre pays. Pas de reconfirmation de la politique. Parce que l'instruction disait "une fois" et le modèle a fait "une fois".

Fix : nommez les exceptions.

Confirme la politique d'expédition une fois par conversation sous flux normal.
Reconfirme quand : (a) une nouvelle commande est introduite, (b) la
destination change (domestique vers international ou inverse),
(c) le client demande explicitement les termes d'expédition à nouveau.

Maintenant la portée est explicite et les exceptions sont listées. Pas d'inférence requise.

Et c'est là que les conseils qu'on vous gave deviennent exactement à l'envers. Chaque guide de migration dans votre feed vous dit d'"adoucir vos règles JAMAIS maintenant que la 4.7 suit mieux les instructions". C'est l'inverse de ce que vous voulez faire.

Vos règles JAMAIS vont bien. Elles sont juste devenues plus tranchantes. Ce qui a cassé c'est les règles qui dépendaient du modèle inférant la portée ou les exceptions que vous n'avez pas pris la peine d'écrire. Vos absolus font leur boulot. Le problème c'est vos "une fois", vos "toujours", vos "habituellement". Ce sont les règles qui s'appuyaient sur la coopération silencieuse de la 4.6.

Si vous voulez le framework complet pour écrire des prompts qui ne s'appuient pas sur la coopération du modèle en premier lieu, j'ai tout mis dans l'approche prompt contracts que j'ai construite après six mois de ces désastres exacts. La 4.7 rend ce framework plus pertinent, pas moins.

Vos règles JAMAIS sont devenues plus tranchantes. Vos règles "une fois" et "toujours" sont devenues stupides. Fixez les dernières, ne touchez pas aux premières.

Ce Qui Reste, Et La Règle À Retenir

Maintenant la bonne nouvelle. La plupart de votre prompt ne bouge pas.

Les interdictions dures s'améliorent sous la 4.7. Pas de tirets cadratin, pas de tableaux, pas d'ouvertures bannies, pas de formules vides : tout ça tourne plus serré, pas plus lâche, parce que le modèle arrête de les traiter comme des suggestions de style et commence à les traiter comme des règles. Le ton direct que vous patchiiez avec des instructions explicites s'aligne avec la voix par défaut de la 4.7. Vos longs prompts système tiennent toujours à travers le contexte. Votre markdown rend exactement pareil. Vos définitions d'outils, vos personas, vos specs de format de sortie, vos règles de contenu : 90% d'un prompt 4.6 bien écrit reste intact.

La surface de réécriture est étroite. Deux questions, dans l'ordre.

Premièrement, où mon prompt dépend-il d'un appel d'outil que je n'ai pas explicitement exigé ? Trouvez ceux-là. Rendez l'appel obligatoire. Nommez l'outil. Fermez le fallback.

Deuxièmement, où mon prompt dépend-il du modèle devinant la portée ou les exceptions ? Trouvez ceux-là. Écrivez la portée. Listez les exceptions.

C'est tout. Pas dix-sept checkpoints. Deux questions.

Karen de la Compta adorerait dix-sept checkpoints, parce qu'elle pourrait faire un tableur. Vous n'avez pas besoin d'un tableur. Vous devez grepper vos prompts pour les verbes mous et pour les règles avec des frontières implicites. Dix minutes de grep. Une heure de réécriture. Fini.

Vous vous souvenez de RTFM ? 😬 (Détendez-vous, je suis là pour vous.)

Sources

(*) La couverture est générée par IA. Mes propres compétences d'illustration ont plafonné en CE2.