Anthropic a supprimé plus de 80% du system prompt de Claude Code pour les modèles de la génération Claude 5 (Opus 5 et Fable 5), sans pertes mesurables dans les évaluations de code. Le post du 24 juillet explique ce changement d’approche : les modèles plus performants ont moins besoin de règles rigides et gèrent mieux le contexte en s’appuyant sur leur propre jugement.

Si tu construis des agents ou utilises Claude Code avec des fichiers CLAUDE.md et des Skills chargées d’instructions, cela change ta façon de travailler. L’ancien pattern consistait à accumuler des règles défensives pour éviter les pires scénarios : « ne pas écrire de commentaires », « ne pas créer de documents de planning », « ne pas supprimer de fichiers ». Avec Claude 5, beaucoup de ces instructions finissent par entrer en conflit et forcent le modèle à un compromis avant de décider. Les supprimer le libère au lieu de l’affaiblir.

Anthropic a mis à disposition la commande /doctor dans Claude Code pour revoir et redimensionner les Skills et fichiers CLAUDE.md. Nous ne l’avons pas encore testé.

Le changement de paradigme est simple : avant tu donnais des règles, maintenant tu demandes du jugement. Les règles servaient quand le modèle pouvait faire des dégâts sérieux de lui-même. Maintenant que le modèle est plus performant, la sur-contrainte coûte plus cher que le risque qu’elle prévient.

Alongside the Cookbook of agentic patterns publié le même jour, Anthropic rend publiques les pratiques internes sur comment travailler avec Claude en production : l’une sur les patterns architecturaux, l’autre sur comment écrire le contexte.

En détail

Ce que signifie context engineering.

Quand tu écris un prompt pour Claude, ce que tu envoies n’est que une partie de ce que le modèle reçoit. Le reste arrive du system prompt (les instructions de base), des fichiers CLAUDE.md (les règles de projet), des Skills (compétences spécifiques), de la mémoire et d’autres sources. Anthropic appelle tout cela context engineering : la pratique d’assembler le bon contexte pour que le modèle fonctionne bien sur plusieurs requêtes différentes, pas seulement sur une.

La différence entre prompt et contexte est que le contexte doit être général. Tu ne sais pas ce que l’utilisateur te demandera, donc tu ne peux pas être trop spécifique. Mais si tu es trop vague, le modèle prend des directions que tu ne veux pas. Trouver le point juste est difficile, et cela change quand le modèle change.

Ce qui a changé avec Claude 5.

Anthropic a découvert qu’elle avait sur-constraint Claude Code. En lisant les transcriptions des sessions internes, elle trouvait des instructions en conflit dans le même message : le system prompt disait une chose, les Skills en disaient une autre, et la requête de l’utilisateur une troisième. Par exemple, une instruction disait « laisse de la documentation où c’est approprié » tandis qu’une autre imposait « NE PAS ajouter de commentaires ».

Le modèle devait négocier entre ces directions contradictoires avant même de commencer à travailler. Avec Claude 4, ces règles servaient à éviter des comportements pires. Avec Opus 5 et Fable 5, le modèle a assez de jugement pour décider seul quand laisser un commentaire et quand ne pas le faire. La confirmation est dans les chiffres : supprimé plus de 80% du system prompt, les évaluations de code ne se sont pas dégradées de façon mesurable.

Il y a aussi un facteur instrumental. Avant, CLAUDE.md servait de mémoire, source d’informations et guide. Maintenant Claude Code a des outils séparés pour chaque fonction : mémoire persistante, artifacts et Skills. Le contexte n’a plus à faire tout le travail seul, et les instructions qui dupliquaient ces fonctions deviennent un poids inutile.

Les limites de ce que nous savons.

L’80% est un chiffre déclaré par Anthropic sur ses propres évaluations internes. Nous ne savons pas quels tests elle a utilisés ni à quel point ils étaient rigoureux. Le conseil vaut pour les modèles Claude 5 : sur des modèles moins performants, supprimer les règles défensives pourrait dégrader les performances. Le passage de « règles » à « jugement » nécessite aussi que tu fasses confiance au modèle sur des décisions où avant tu avais le contrôle explicite. Ce n’est pas un saut qui se fait partout de la même manière : sur un système qui gère des données sensibles ou effectue des opérations irréversibles, la prudence initiale reste raisonnable même avec un modèle performant.