TL;DR : arrêtez d’expliquer à un modèle comment réfléchir, il le fait mieux que vos consignes. Écrivez seulement ce qu’il ne peut pas deviner : l’état de votre projet, les pièges de votre machine, et les décisions déjà prises. Le reste alourdit chaque session sans rien apporter.
Le 24 juillet, Anthropic a publié un billet qui a de quoi vexer quiconque a passé des soirées à peaufiner ses fichiers d’instructions. Thariq Shihipar, de son équipe technique, y explique avoir supprimé plus de 80 % du prompt système de Claude Code pour les modèles Opus 5 et Fable 5, « sans perte mesurable sur nos évaluations de code ».
Quatre-vingts pour cent. Pas une réécriture, une amputation.
Au même moment, sur ce site, je faisais exactement l’inverse. Notre fichier de règles est passé de rien à trente-trois règles apprises en une quinzaine de jours, chacune née d’une bêtise précise et datée. Le fichier de projet fait 15,5 Ko, le fichier de règles 24,5 Ko, et les deux sont lus à chaque démarrage de session.
Alors qui a tort ? Personne, et c’est tout l’intérêt de la question.
Deux sortes d’instructions, une seule qui mérite d’être écrite
Ce qu’Anthropic a coupé, ce sont des instructions qui décrivent comment penser : ne pas oublier de vérifier, lire le fichier avant de le modifier, structurer sa réponse ainsi, préférer telle approche. Sur les modèles de la génération précédente, ces béquilles servaient. Sur les modèles actuels, elles occupent de la place pour redire ce que le modèle fait déjà spontanément, et parfois pour l’empêcher de faire mieux.
Ce que nous avons écrit, ce sont des instructions qui décrivent ce qui ne se devine pas :
« Ne jamais juger un déploiement au compteur
deployment.all: la liste est plafonnée, elle cesse d’augmenter et donne l’illusion que plus rien ne part. »
Aucun modèle, aussi bon soit-il, ne peut inventer ça. C’est une propriété de notre hébergeur, découverte en perdant une heure. C’est une information, pas un conseil.
Le test qui tranche, et il est brutal : est-ce que cette ligne serait encore vraie sur le projet du voisin ? Si oui, effacez-la. « Vérifie ton travail avant de conclure » est vrai partout, donc inutile ici. « Le port de développement est 4321, ni package.json ni la configuration ne le fixent » n’est vrai que chez nous, donc ça reste.
Passez vos fichiers à ce filtre. Vous serez surpris de la proportion qui tombe.
Les six bascules, et ce qu’elles donnent en vrai
Le billet énonce six changements. Trois touchent directement les fichiers qu’on écrit à la main.
Donner des règles devient laisser juger
Nos règles ne disent jamais au modèle comment faire, elles disent ce qui s’est déjà mal passé. La différence tient dans la forme : une règle utile commence par un fait daté, pas par un impératif.
Comparez. « Toujours compter les fichiers avec soin » ne sert à rien. « Un compte de fichiers se fait sur toutes les extensions : ls *.md donnait 24 articles là où il y en a 28, parce que quatre sont en .mdx » raconte une erreur réelle, et l’agent qui la lit comprend le mécanisme au lieu d’obéir à un ordre.
Donner des exemples devient concevoir des interfaces
C’est la bascule la plus contre-intuitive, et celle qui rapporte le plus. Plutôt que d’expliquer par l’exemple ce qu’on attend, Shihipar conseille de réfléchir « à la conception de vos outils, scripts et fichiers : quels paramètres Claude a-t-il, et comment les rendre plus expressifs ? »
Chez nous, ça s’est traduit par un déplacement du texte vers le code. Notre rituel de publication ne s’explique plus, il s’exécute : un script assemble les artefacts de restitution, un autre vérifie qu’ils ne sont pas vides, un troisième produit les images au bon format. Les trois pages d’explications qu’il aurait fallu écrire sont devenues trois commandes qui échouent bruyamment quand on s’y prend mal.
Un outil qui refuse une mauvaise entrée vaut mieux qu’un paragraphe qui la déconseille.
Tout mettre en tête devient divulguer progressivement
C’est le point où la plupart des projets pèchent, le nôtre compris.
Tout ce qui est écrit dans le fichier de projet est lu à chaque session, y compris quand la session ne fait qu’une correction de deux lignes. Les instructions propres à une tâche n’ont donc rien à y faire : elles vont dans une compétence, chargée seulement quand la tâche arrive.
Nous avons huit compétences. Celle qui produit la fournée quotidienne fait plusieurs pages : elle ne coûte rien tant qu’on ne la lance pas. Si son contenu vivait dans le fichier de projet, chaque session paierait pour des consignes de rédaction, même une session de correction de CSS.
La règle pratique : si une instruction ne sert qu’à un type de tâche, elle ne va pas dans le fichier lu au démarrage. Le billet renvoie pour cela à la commande /doctor de Claude Code, qui passe les compétences et les fichiers CLAUDE.md en revue et signale ceux qui ont grossi sans qu’on y prenne garde.
Ce que ça change sur la facture
Il y a une raison très concrète de faire ce ménage, et elle est arrivée cette semaine : les limites hebdomadaires de Claude Code se resserrent au 14 septembre. Un contexte qu’on traîne est un contexte qu’on repaie à chaque tour de conversation.
Anthropic a d’ailleurs publié un second billet, plus terre à terre, sur la valeur qu’on tire d’une session. Les gestes qu’il retient sont simples et se prennent en trois jours d’habitude :
/clearentre deux tâches sans rapport. Sans ça, tout le contexte de la tâche précédente repart à chaque message.- Choisir son modèle et son niveau d’effort au début, pas au milieu : en changer casse le cache et refait payer ce qui était déjà en mémoire.
- Mentionner un fichier avec
@plutôt que d’écrire son chemin. Le chemin déclenche une lecture, la mention le fournit directement. /rewindplutôt que/compactpour revenir en arrière de quelques tours : c’est gratuit.
Aucun de ces gestes n’est spectaculaire. Mis bout à bout sur une session de trois heures, ils font la différence entre finir sa journée et attendre la remise à zéro du quota.
Ce que je garde, et ce que j’ai jeté
Après quinze jours à faire tourner ce site avec un agent, voilà l’état de mes fichiers.
Ce qui reste dans le fichier de projet : la structure du dépôt, les commandes qui marchent, l’adresse de déploiement, les pièges de l’hébergeur, les décisions éditoriales qui ne se rediscutent pas, et l’endroit où chercher le reste. Ce sont des faits, ils ne se devinent pas, et ils changent rarement.
Ce qui est parti dans les compétences : les gabarits d’articles, la procédure de veille, la direction artistique des images, le rituel de clôture. Tout ce qui ne sert qu’un jour sur trois.
Ce que j’ai arrêté d’écrire : les consignes de politesse, les rappels de méthode générale, les listes de bonnes pratiques valables partout. Elles me rassuraient, elles ne servaient à rien.
Et ce que j’écris toujours, sans exception : la règle née d’une erreur, avec sa date et le détail de ce qui a raté. C’est le seul type d’instruction dont j’ai la preuve qu’il a évité que la même bêtise se reproduise.
La leçon d’Anthropic n’est donc pas « écrivez moins ». Elle est plus exigeante que ça : écrivez seulement ce que personne d’autre ne pourrait écrire à votre place. Le reste, le modèle le sait déjà, et il le sait mieux que vous.
