Anthropic Claude a réduit de 80 % le prompt système de Claude Code, remettant en cause l’approche du toujours-plus-de-règles

Anthropic Claude a supprimé plus de 80 % du prompt système de Claude Code pour ses modèles les plus récents, sans pour autant constater de perte mesurable dans ses évaluations internes de programmation. Ce changement, annoncé le 24 juillet, concerne des modèles avancés comme Claude Opus 5 et Claude Fable 5. Il inverse une hypothèse répandue sur les agents IA : des instructions plus détaillées ne produisent pas toujours un comportement plus fiable.

Anthropic explique que les anciennes versions de Claude Code nécessitaient des règles explicites pour éviter les commentaires médiocres, les documents non souhaités et les opérations de fichiers dangereuses. Ces protections se sont accumulées dans le prompt système, les instructions de projet, les compétences, les descriptions d’outils, la mémoire et les requêtes individuelles des utilisateurs. Le contexte obtenu pouvait ainsi contenir des directives dupliquées ou contradictoires.

L’ingénierie du contexte de Claude 5 part désormais d’un principe différent. Anthropic souhaite que les équipes laissent aux modèles compétents une marge de jugement, conçoivent des interfaces plus claires et ne chargent les instructions spécialisées qu’en cas de besoin. La compétition principale n’oppose plus Anthropic à un autre fournisseur de modèles. Elle oppose le prompting prescriptif au contexte sélectif.

Cette distinction compte au-delà de Claude Code. Les développeurs conçoivent des agents qui lisent des dépôts, appellent des outils, modifient des fichiers, révisent du code et conservent un état au fil de longues sessions. Chaque instruction permanente entre en concurrence pour l’attention du modèle avec la tâche, les fichiers courants, les résultats d’outils et l’intention de l’utilisateur.

Les preuves apportées par l’entreprise restent toutefois limitées. Anthropic n’a pas publié la suite d’évaluation, les scores de référence, la distribution des tâches ni les résultats modèle par modèle qui sous-tendent son affirmation d’« absence de perte mesurable ». La réduction de 80 % est significative, mais sa portée pratique doit encore être testée de manière indépendante.

Anthropic Claude a supprimé des règles qui semblaient autrefois essentielles

Le changement immédiat n’est pas une fenêtre de contexte plus large. C’est une couche d’instructions permanentes bien plus réduite.

Anthropic décrit l’ingénierie du contexte comme l’assemblage de tout ce qu’un modèle reçoit au-delà du prompt immédiat de l’utilisateur. Cela inclut les instructions système, les fichiers de projet, les compétences, la mémoire, les définitions d’outils, l’historique de conversation et les références récupérées.

Un prompt système est l’ensemble initial d’instructions qui façonne un agent tout au long d’une conversation. Il peut définir le comportement, l’utilisation des outils, le style de réponse, les limites de sécurité et les hypothèses concernant l’environnement d’exploitation.

Selon les conseils d’Anthropic sur l’ingénierie du contexte, l’entreprise a supprimé plus de 80 % du prompt système de Claude Code pour Opus 5 et Fable 5. Elle indique que les évaluations de programmation n’ont montré aucune perte mesurable après ce changement.

L’annonce ne dit pas que les instructions sont devenues inutiles. Elle distingue plutôt les règles permanentes des informations qui doivent figurer ailleurs. Les limites de sécurité, les autorisations, les contrats d’outils et les exigences explicites des utilisateurs doivent toujours être clairement représentés.

Ce qui a changé, c’est l’emplacement par défaut de ces indications. Anthropic plaçait auparavant des comportements détaillés de programmation, de révision, de documentation et de vérification dans le prompt principal. Ces instructions accompagnaient le modèle même lorsqu’une tâche donnée n’en avait pas besoin.

Certaines anciennes règles visaient également à contrôler des modes d’échec étroits. Anthropic cite une ancienne instruction demandant à Claude d’éviter les docstrings à plusieurs paragraphes et les documents de planification, sauf demande explicite. Cette règle réduisait les sorties indésirables, mais décourageait aussi une documentation utile dans du code complexe.

Le remplacement est plus court et davantage ancré dans le contexte. Claude doit s’aligner sur la densité des commentaires, la convention de nommage et l’idiome du code environnant. Au lieu de prescrire un modèle de sortie universel, l’instruction indique au modèle où trouver la norme pertinente.

Ce changement crée la tension centrale de l’article. Une règle détaillée peut sembler plus sûre parce que son comportement est visible et testable. Pourtant, toute instruction rigide peut devenir erronée lorsque le dépôt, la demande de l’utilisateur ou la tâche exige une exception.

Claude Code reçoit également des instructions par plusieurs canaux qui se chevauchent. Un utilisateur peut demander une documentation appropriée tandis qu’une règle globale décourage les commentaires. Une compétence peut exiger une vérification tandis qu’un autre fichier demande à l’agent de limiter le travail supplémentaire.

Le modèle doit résoudre ces conflits avant de pouvoir traiter le véritable problème d’ingénierie. Davantage de texte crée donc une tâche de raisonnement supplémentaire au lieu d’ajouter simplement des connaissances utiles.

Anthropic a ajouté une réponse de diagnostic à ce problème. L’entreprise indique que la commande /doctor peut aider les utilisateurs à ajuster la taille de leurs compétences et de leurs fichiers CLAUDE.md. Ces fichiers fournissent un contexte de projet persistant, notamment les conventions du dépôt et les instructions récurrentes.

Le message pratique est plus nuancé que « supprimez vos prompts ». Les équipes doivent identifier quelles informations s’appliquent réellement à chaque requête. Tout le reste nécessite un déclencheur, un emplacement ou un mécanisme de livraison plus précis.

Pourquoi l’ingénierie du contexte de Claude 5 privilégie le contexte sélectif

Anthropic mise sur l’idée qu’un meilleur jugement du modèle réduit la valeur de la microgestion comportementale permanente.

L’ancienne approche s’est imposée pour de bonnes raisons. Les premiers modèles de programmation produisaient fréquemment trop de commentaires, créaient des fichiers de planification inutiles, géraient mal les outils ou suivaient les exemples de façon trop littérale. Des instructions détaillées réduisaient l’éventail des comportements possibles.

Cette limitation impliquait un compromis. Prévenir un échec fréquent pouvait empêcher la bonne réponse à une tâche inhabituelle. Une interdiction des longs commentaires pouvait améliorer les modifications routinières, mais nuire au travail sur des algorithmes complexes ou du code sensible en matière de sécurité.

L’ingénierie du contexte de Claude 5 rapproche cette décision de la tâche. Le modèle reçoit la demande de l’utilisateur, examine le code voisin et applique les conventions locales. Anthropic parle de « libérer » Claude de ses entraves, car le système supprime des contraintes ayant dépassé leur objectif initial.

Ce terme ne doit pas être confondu avec une autonomie sans restriction. Claude Code continue d’opérer dans un harnais, c’est-à-dire le logiciel environnant qui gère les outils, les autorisations, le contexte et l’exécution. Anthropic simplifie une couche de ce harnais.

L’entreprise présente plusieurs évolutions de type « avant et maintenant ». Les règles cèdent la place au jugement. Les exemples d’outils cèdent la place à des interfaces expressives. Les instructions initiales cèdent la place à la divulgation progressive. La répétition cède la place à des descriptions d’outils concises.

La divulgation progressive consiste à charger des informations détaillées lorsque la tâche l’exige, au lieu de tout placer dans le contexte initial. Claude Code utilise désormais des compétences dédiées pour des domaines tels que la révision de code et la vérification.

Cette approche préserve l’accès à l’information sans imposer un coût d’attention permanent. Une procédure de révision peut rester détaillée, mais Claude la charge lorsqu’il effectue une révision. Une modification de fichier de routine n’a pas besoin d’emporter toute la procédure.

Claude Code applique le même principe aux outils. Certains outils utilisent un chargement différé, qui n’expose d’abord qu’une description légère. Le schéma complet n’apparaît qu’après que l’agent a sélectionné cet outil par recherche.

Le guide sur la fenêtre de contexte d’Anthropic montre pourquoi cette distinction importe. Les instructions de projet, la mémoire, les descriptions de compétences, les fichiers, les réponses et le contenu d’exécution caché occupent tous le même contexte de travail.

Une grande capacité de contexte ne supprime pas le problème de sélection. Un modèle peut accepter davantage de tokens tout en recevant des informations non pertinentes, obsolètes ou contradictoires. La capacité répond à la question de savoir combien d’éléments tiennent, et non lesquels méritent de l’attention.

Le contexte sélectif change également la manière dont les équipes devraient organiser les connaissances d’un dépôt. Un unique fichier CLAUDE.md ne devrait pas devenir une encyclopédie de toutes les préférences d’ingénierie. Anthropic recommande plutôt une arborescence de références que l’agent peut charger au moment opportun.

Cette conception rappelle une bonne architecture logicielle. Les interfaces stables restent petites, tandis que les comportements spécialisés se trouvent derrière des limites explicites. L’agent apprend ce qui existe sans recevoir chaque détail d’implémentation au démarrage.

Les définitions d’outils deviennent particulièrement importantes dans ce modèle. Anthropic soutient que les exemples peuvent restreindre l’exploration en orientant le modèle vers des schémas déjà démontrés. Des paramètres et des définitions d’état clairs peuvent communiquer l’intention sans prescrire un itinéraire unique.

Son exemple Todo utilise des états énumérés tels que pending, in progress et completed. Une contrainte n’autorisant qu’un seul élément actif décrit un état système valide. Le modèle peut ensuite choisir ses actions à l’intérieur de cette interface.

Il s’agit d’un changement important dans l’endroit où réside la fiabilité des agents. Les auteurs de prompts tentaient autrefois d’encoder la fiabilité principalement par le texte. Anthropic attribue désormais davantage de responsabilités à la conception des interfaces, au routage du contexte, aux autorisations et au jugement du modèle.

Le véritable affrontement oppose le prompting prescriptif au jugement du modèle

La réduction de 80 % remet en cause l’idée que chaque défaillance observée d’un agent mérite une instruction permanente supplémentaire.

Les équipes qui développent des agents IA réagissent souvent aux erreurs en ajoutant des règles. Si un agent omet des tests, le prompt reçoit une exigence de test. S’il modifie des fichiers sans rapport, un autre paragraphe réduit son périmètre. S’il explique trop, une restriction de verbosité s’ajoute.

Ce processus crée un effet de cliquet. Les instructions s’accumulent, car les ajouts semblent plus sûrs que les suppressions. Peu d’équipes testent régulièrement si une ancienne règle améliore encore les modèles, les outils et les flux de travail actuels.

Anthropic Claude affirme désormais que ce cliquet peut réduire la qualité. Le problème ne se limite pas à la consommation de tokens. Des instructions contradictoires forcent le modèle à déduire les priorités, interpréter les exceptions et concilier des protections obsolètes avec l’intention actuelle de l’utilisateur.

Le prompting prescriptif reste attrayant parce que les équipes peuvent l’auditer. Un réviseur de sécurité peut localiser une interdiction explicite. Un chef de produit peut désigner une règle de formatage. Un développeur peut reproduire le texte inclus dans une requête.

Le jugement du modèle offre de la flexibilité, mais il est plus difficile à prédire. Il permet à Claude de reconnaître qu’une fonction complexe a besoin de documentation malgré une préférence générale pour des commentaires minimaux. Cette même latitude peut produire des choix incohérents d’une tâche à l’autre.

La version la plus solide de l’argument d’Anthropic dépend donc des capacités du modèle. Un modèle moins performant pourrait encore nécessiter des exemples détaillés, des avertissements répétés et des règles étroites. Un déploiement combinant plusieurs modèles ne peut pas supposer que chaque agent interprète des indications concises avec la même qualité.

Cela crée une pression pour les équipes qui prennent en charge plusieurs générations de modèles. Des instructions optimisées pour Opus 5 ou Fable 5 pourraient ne pas spécifier suffisamment le comportement des modèles plus anciens ou plus petits. Des prompts écrits pour d’anciens modèles pourraient trop contraindre les plus récents.

Un contexte versionné devient une exigence opérationnelle. Les équipes doivent savoir quelles règles s’appliquent à chaque modèle, comment les évaluations ont évolué et à quel moment une instruction partagée a cessé d’apporter de la valeur. Sans cela, la simplification devient une autre convention non testée.

Ce changement exerce aussi une pression sur les entreprises qui vendent des modèles de prompts comme des actifs durables. Un long modèle peut encoder une expertise utile, mais sa longueur n’est plus un indicateur crédible d’exhaustivité. Sa valeur dépend de sa pertinence, de son routage et de résultats mesurables.

Les développeurs qui créent des agents personnalisés font face à une décision similaire. La documentation sur les prompts système d’Anthropic distingue le préréglage complet de Claude Code d’une configuration minimale par défaut et d’instructions entièrement personnalisées.

La configuration complète convient aux agents de programmation supervisés et pilotés par un humain. Un prompt personnalisé est mieux adapté aux agents ayant des identités, interfaces ou modèles d’autorisation différents. Anthropic avertit que les créateurs de configurations personnalisées doivent remplacer toute directive de sécurité qu’ils retirent.

Cet avertissement révèle la limite de ce nouveau guide pratique. Supprimer les éléments comportementaux superflus ne revient pas à affaiblir les autorisations. Un agent concis a toujours besoin de limites explicites concernant les opérations destructrices, les données sensibles, les communications externes et l’exécution sans supervision.

Les équipes devraient classer les instructions avant de les supprimer. Une préférence de style peut souvent s’en remettre aux conventions du dépôt. Un processus de vérification peut devenir une compétence. Une limite d’autorisation relève d’un logiciel applicable, et non d’une simple formule de politesse.

Cette répartition oriente le secteur vers une architecture du contexte. Le travail essentiel consiste à déterminer ce qui reste global, ce qui se charge selon le chemin, ce qui s’active selon la tâche et ce que le logiciel applique indépendamment du modèle.

Pour les équipes d’ingénierie, cette architecture devient aussi une mémoire organisationnelle. Les conventions du dépôt, les décisions et les références techniques nécessitent une responsabilité claire et des parcours de récupération précis. Une base de connaissances d’ingénierie interrogeable peut aider les équipes à distinguer les faits durables des instructions d’agent temporaires.

Le vainqueur de cette compétition ne sera pas nécessairement celui des « prompts courts » dans tous les cas. Ce sera le système qui fournit le contexte suffisant le plus réduit possible tout en préservant la sécurité, la fidélité à la tâche et des performances reproductibles.

Les résultats du prompt système de Claude Code nécessitent encore des tests indépendants

Le résultat mis en avant par Anthropic est notable, mais les éléments publics ne démontrent pas que chaque équipe puisse supprimer les mêmes 80 %.

L’entreprise affirme que la réduction du prompt système de Claude Code n’a entraîné aucune perte mesurable lors des évaluations de programmation. Cette formulation laisse plusieurs questions importantes sans réponse.

Anthropic n’a pas divulgué les tâches d’évaluation utilisées pour cette comparaison. Les lecteurs ne peuvent pas savoir si la suite mettait l’accent sur la génération de code, le débogage, la navigation dans les dépôts, les tests, la documentation, l’utilisation d’outils ou le travail autonome de longue durée.

L’entreprise n’a pas non plus publié les scores de référence ni les intervalles de confiance. « Aucune perte mesurable » peut signifier des résultats identiques, une différence statistiquement non significative ou une variation trop faible pour être détectée par le benchmark choisi.

L’affirmation concerne la configuration interne de Claude Code d’Anthropic pour des modèles avancés. Elle ne prouve pas que les utilisateurs puissent supprimer 80 % de leurs propres fichiers CLAUDE.md, compétences ou prompts d’agents personnalisés sans conséquence.

Ces fichiers contiennent souvent des exigences propres à l’organisation. Parmi les exemples figurent les commandes de build, les processus réglementés, les normes de revue, les politiques de dépendances, les restrictions de déploiement et les conventions que le modèle de base ne peut pas déduire du code voisin.

Un dépôt peut également contenir des schémas incohérents. Demander à Claude de reproduire le code environnant fonctionne lorsque cet environnement représente la norme souhaitée. Cela peut reproduire de la dette technique lorsque d’anciennes et de nouvelles conventions coexistent.

La divulgation progressive introduit son propre mode de défaillance. L’agent doit reconnaître lorsqu’une compétence ou une référence spécialisée est nécessaire. Si le routage échoue, l’information correcte existe, mais n’atteint jamais le contexte actif.

Les outils différés créent une dépendance similaire. Des descriptions légères économisent le contexte initial, mais elles doivent être suffisamment précises pour que l’agent découvre la bonne capacité. Un outil mal nommé peut devenir pratiquement invisible.

La compaction complique encore la situation. Claude Code résume les longues conversations lorsque le contexte se remplit. La documentation d’Anthropic indique que certaines instructions de projet et certains éléments de mémoire sont ensuite rechargés, tandis que les règles limitées à un chemin peuvent attendre une nouvelle lecture de fichier correspondante.

Des informations importantes peuvent donc passer de couches persistantes à des couches temporaires au cours d’une même session. Les équipes qui testent des modifications de contexte devraient inclure des tâches longues franchissant les limites de compaction, et pas seulement des prompts de programmation isolés.

La mise en cache des prompts influence également l’architecture. Elle réutilise un préfixe de requête stable afin de réduire les calculs répétés. Anthropic indique que Claude Code conserve le contenu statique en premier et les messages dynamiques ensuite afin de préserver les correspondances de cache.

Les enseignements d’Anthropic sur la mise en cache des prompts avertissent que modifier les outils ou les modèles au milieu d’une session peut invalider les préfixes mis en cache. Le contexte sélectif doit donc équilibrer pertinence et stabilité.

La stratégie de chargement différé de Claude Code répond à une partie de cette tension. Des stubs d’outils légers peuvent rester stables tandis que les schémas complets se chargent plus tard. Cette approche économise le contexte sans modifier constamment l’ensemble d’outils de base.

Néanmoins, un prompt système plus court ne garantit pas automatiquement une utilisation totale du contexte plus faible. Un agent pourrait compenser en lisant davantage de références, en invoquant plus de compétences ou en consacrant des tours supplémentaires à découvrir les instructions.

La réduction du prompt ne garantit pas non plus un comportement cohérent. Retirer des directives répétées pourrait révéler des défaillances rares que de vastes évaluations de programmation ne détectent pas. Les équipes sensibles à la sécurité et soumises à des réglementations devraient tester les risques extrêmes plutôt que les seuls scores moyens des tâches.

La réponse appropriée est une évaluation contrôlée. Les équipes peuvent comparer les anciennes configurations et les configurations réduites sur des dépôts représentatifs, des tâches fixes, des exécutions répétées et des catégories de défaillance clairement définies.

Parmi les mesures utiles figurent l’achèvement des tâches, les modifications de fichiers non intentionnelles, la couverture de tests, les conclusions de revue, les erreurs d’outils, les corrections des utilisateurs et la consommation totale de contexte. Les équipes devraient également enregistrer les instructions que l’agent a effectivement chargées.

La charge de la preuve augmente avec l’autonomie. Un développeur supervisant chaque modification peut rapidement détecter une erreur de jugement. Un agent sans supervision qui ouvre des pull requests ou modifie des systèmes de production exige des contrôles plus stricts et une évaluation plus approfondie.

Le résultat d’Anthropic doit être considéré avant tout comme une preuve que la dette de prompt existe. Il ne constitue pas un objectif universel de suppression, et l’entreprise n’a pas validé indépendamment cette conclusion en dehors de ses propres modèles et de son propre environnement de test.

Des prompts plus courts déplacent davantage de responsabilités vers l’architecture des agents

La simplification du contexte ne supprime pas la complexité. Elle la déplace vers le routage, les outils, la mémoire, l’évaluation et les autorisations.

Ce déplacement est la conséquence commerciale la plus importante de l’annonce. Les équipes qui considéraient les prompts comme le produit de l’agent doivent désormais examiner le système complet qui entoure le modèle.

Un agent fiable a besoin d’un moyen d’identifier les connaissances pertinentes. Il a besoin d’outils aux noms clairs, aux paramètres expressifs et aux états contraints. Il a besoin d’une mémoire qui sépare les préférences durables des détails temporaires de session.

Il a également besoin d’une exécution observable. Les développeurs doivent voir quels fichiers l’agent a lus, quelles compétences il a invoquées, quels outils il a sélectionnés et quelles instructions ont influencé une décision.

L’ingénierie du contexte de Claude 5 rend ces capacités plus précieuses, car le prompt principal contient moins de procédures explicites. Si la couche de routage échoue, le modèle dispose de moins de directives redondantes comme solution de repli.

La fonctionnalité d’auto-mémoire d’Anthropic illustre ce changement. Claude Code peut enregistrer des informations qu’il considère pertinentes au fil du travail. Cela réduit la pression d’utiliser CLAUDE.md comme un dépôt de mémoire maintenu manuellement.

La mémoire automatisée introduit toutefois des questions de gouvernance. Les équipes doivent savoir ce qui a été stocké, si cela reste exact et comment les mémoires contradictoires sont résolues. Un contexte obsolète peut induire un agent en erreur même lorsque le prompt principal est concis.

Les références riches créent un autre changement architectural. Anthropic indique que Claude peut travailler avec des artefacts plus complexes plutôt que de s’appuyer uniquement sur de simples plans Markdown. Cela élargit ce que les agents peuvent examiner lors de la conception et de l’implémentation.

Le bénéfice dépend de la découvrabilité. Un artefact détaillé n’aide que si l’agent sait qu’il existe et comprend quand le consulter. Les arborescences de références nécessitent des noms informatifs, des index concis et des points d’entrée propres à chaque tâche.

La conception d’outils devient une forme de prompting. Une énumération communique des états valides. Un paramètre obligatoire signale une information nécessaire. Les limites d’autorisation empêchent les actions invalides, quelle que soit la manière dont le modèle interprète le texte.

Cette approche devrait séduire les acheteurs d’entreprise, car les contrôles logiciels sont plus faciles à appliquer que les avertissements en langage naturel. Un système d’autorisations peut bloquer une opération. Un prompt peut seulement demander au modèle de ne pas l’exécuter.

Pourtant, la conception d’interfaces demande davantage d’efforts d’ingénierie que l’ajout d’un paragraphe supplémentaire. Les équipes doivent modéliser les processus, gérer les erreurs d’outils, exposer l’état et maintenir la compatibilité à mesure que les modèles et les produits évoluent.

La réduction de 80 % pourrait donc élargir l’écart entre les démonstrations simples et les agents de production. Une démonstration peut paraître meilleure avec moins de contraintes. Un système de production doit remplacer le comportement retiré des prompts par une architecture plus robuste lorsque cela est nécessaire.

L’effet s’étend aussi aux travailleurs du savoir qui utilisent l’IA en dehors du développement logiciel. Les agents de recherche, d’opérations et d’analyse font face au même problème de contexte. Les longs documents d’instructions mélangent souvent objectifs, préférences, documents de référence et procédures ponctuelles.

Séparer ces catégories peut améliorer la récupération et la maintenance. L’identité stable et les règles de sécurité restent globales. Les références de domaine se chargent lorsqu’elles sont pertinentes. Les procédures de tâche deviennent des workflows appelables. Les faits temporaires restent dans la session active.

Cela ne signifie pas que chaque workflow nécessite une plateforme élaborée. Le principe peut commencer par un court index de projet, des fichiers de référence à portée limitée et un ensemble de tests fondé sur le travail récurrent.

L’essentiel est de cesser de traiter le contexte comme un bloc de texte indifférencié. Chaque élément devrait avoir une raison d’être chargé, une portée définie, un responsable et une méthode permettant de tester sa valeur.

L’initiative d’Anthropic exerce également une pression indirecte sur les fournisseurs concurrents d’agents de programmation. Les utilisateurs compareront de plus en plus non seulement les scores de benchmark, mais aussi la manière dont chaque produit gère les instructions, la mémoire, les outils, la compaction et la visibilité du contexte.

Un modèle doté de capacités brutes élevées peut tout de même sous-performer dans un environnement encombré. Un modèle plus petit peut rester utile lorsque ses outils et les limites de ses tâches sont étroits. La concurrence entre agents devient une compétition de systèmes.

L’avantage émergent revient aux produits qui rendent le contexte inspectable. Les utilisateurs doivent comprendre ce qui est entré dans le modèle, ce qui est resté caché, ce qui a survécu à la compaction et ce qui a changé entre les exécutions.

Anthropic a clairement indiqué sa direction. De meilleurs modèles devraient porter moins de règles comportementales universelles, tandis que le système environnant fournit des informations précises au moment où elles sont nécessaires.

Ce qu’il faut surveiller après la réduction de 80 %

Trois signaux montreront si la stratégie d’Anthropic fondée sur des prompts plus courts devient une règle du secteur ou reste une optimisation propre à Claude.

Le premier signal sera l’évaluation indépendante. Les développeurs devraient rechercher des comparaisons contrôlées entre l’ancien prompt système de Claude Code et sa version réduite, sur des dépôts réels et des exécutions répétées.

Des preuves solides incluraient des scores au niveau des tâches, des distributions plutôt que des moyennes, ainsi que des catégories explicites pour la sécurité et les modifications non intentionnelles. Des résultats comparables renforceraient l’affirmation d’Anthropic selon laquelle de nombreuses règles permanentes sont devenues une dette de prompt.

Une hausse des comportements incohérents l’affaiblirait. Les défaillances rares mais coûteuses comptent, en particulier lorsque les agents fonctionnent sans revue humaine continue. Les études les plus utiles testeront les longues sessions, la découverte d’outils et la compaction.

Le deuxième signal concerne la manière dont les autres générations de modèles gèrent le même contexte. L’annonce d’Anthropic mentionne précisément Opus 5 et Fable 5. Les équipes doivent déterminer si les modèles de classe Sonnet, plus petits ou plus anciens tolèrent des instructions tout aussi concises.

Si les configurations réduites fonctionnent sur l’ensemble des modèles, le contexte sélectif devient un schéma général de conception d’agents. Si les performances varient fortement, les équipes auront besoin de prompts versionnés et de politiques de routage pour chaque famille de modèles.

Ce résultat compliquerait les produits multi-modèles. Changer de fournisseur ou de taille de modèle ne se limiterait pas à modifier un identifiant d’API. Chaque modèle pourrait exiger un équilibre différent entre discernement, exemples, répétition et contraintes.

Le troisième signal concerne le comportement du produit autour de /doctor, des skills, de la mémoire et des outils différés. Anthropic affirme que /doctor peut repérer des instructions et des skills de projet surdimensionnés. Ses recommandations montreront à quel point l’entreprise s’attend à ce que les utilisateurs simplifient leur configuration.

Il faudra observer si Claude Code indique quelles règles sont en conflit, quels fichiers sont rarement activés et quelles instructions font double emploi avec des comportements intégrés. Ces diagnostics transformeraient le nettoyage des prompts, aujourd’hui subjectif, en une maintenance mesurable.

Il faudra également voir si Anthropic publie des détails d’évaluation plus complets. L’affirmation actuelle ne précise ni la composition des tâches, ni les scores bruts, ni les comparaisons par modèle. Une plus grande transparence aiderait les équipes à déterminer si ce constat s’applique à leurs environnements.

Pour les développeurs, l’action immédiate n’est pas une suppression aveugle de 80 %. Auditez les instructions selon leur finalité. Conservez les limites de sécurité applicables, supprimez les doublons évidents et placez les procédures spécialisées derrière des déclencheurs clairs.

Testez ensuite la configuration allégée sur le travail réellement effectué par votre équipe. Incluez les modifications courantes, les demandes ambiguës, les tâches de revue, les conventions du dépôt, les échecs d’outils et les longues sessions. Mesurez les taux de correction en parallèle du taux d’achèvement.

Les acheteurs en entreprise devraient demander aux fournisseurs comment le contexte est assemblé et inspecté. Une grande fenêtre de contexte ne suffit pas. Ils ont besoin de contrôles sur le périmètre, la mémoire, les autorisations, la récupération, la compaction et les comportements propres à chaque modèle.

Les travailleurs du savoir devraient appliquer la même discipline aux instructions persistantes destinées à l’IA. Gardez les préférences stables concises. Stockez les documents de référence là où ils peuvent être récupérés. Évitez de contraindre chaque future demande à emporter toutes les leçons du passé.

Le résultat d’Anthropic concernant Claude est important, car il redéfinit la sophistication. L’agent le plus avancé n’a peut-être pas le prompt le plus long. Il peut disposer du système le plus clair pour déterminer ce dont le modèle a besoin à un instant donné.

Des tests indépendants reproduiront-ils le résultat d’Anthropic, ou révéleront-ils des tâches pour lesquelles les règles supprimées restent importantes ? Au cours des prochains mois, cette réponse devrait orienter tout audit sérieux du contexte de Claude Code.