Le prompting a changé. La plupart de nos instructions, non.

Les modèles sont devenus plus intelligents. Nos stacks de prompts ont vieilli. Il est temps de remplacer le musée d'instructions par une petite carte, des limites claires et une ligne d'arrivée.

Il y a quelques jours, j'ai découvert quelque chose d'un peu inconfortable :

La quasi-totalité de mes prompts, fichiers d'instructions, règles et compétences étaient obsolètes.

Pas complètement inutiles. Juste écrits pour une autre génération de modèles.

Les stacks de prompts qui aidaient les anciens modèles à se comporter correctement peuvent rendre GPT-5.6, Claude Fable 5, Claude Opus 5, Grok 4.5 et les outils de codage comme Cursor plus rigides, plus coûteux et parfois tout simplement moins bons.

Ce n'est pas ma dernière religion en matière de prompts. Anthropic prévient explicitement que les compétences écrites pour les modèles précédents peuvent être trop prescriptives pour Fable 5 et dégrader la qualité des sorties. OpenAI recommande des prompts plus légers, moins d'instructions répétées et des descriptions d'outils plus simples.

C'était un peu gênant à lire.

Depuis l'été 2025, j'ai écrit plus de 100 000 prompts. C'est à peu près le nombre de tweets qu'Elon Musk a publiés dans sa vie, avec moins de fusées et plus de suites de tests qui échouent.

Mes logs contiennent environ 15 millions de messages de modèles, y compris les messages d'assistant, les appels d'outils, les sous-agents et les événements de workflow. Jusqu'au 26 mars, le total était d'environ sept millions. Huit millions supplémentaires sont arrivés en trois mois, principalement en raison de l'explosion des sous-agents et des workflows autour des nouveaux modèles de codage.

Je pensais donc savoir comment écrire des instructions.

Puis j'ai lu la nouvelle documentation et j'ai réalisé qu'une grande partie de ce que j'avais appris s'était tranquillement transformée en dette technique.

Comment la dette de prompts est créée

Mon ancienne approche était simple :

• Le modèle faisait une erreur, donc j'ajoutais une règle.
• Il posait une question inutile, donc j'ajoutais une autre règle.
• Il manquait un cas limite, donc j'ajoutais trois exemples.

Chaque ajout semblait raisonnable pris isolément. Après un an, le fichier d'instructions ressemblait à ce tiroir de cuisine où l'on garde douze vieux câbles parce que l'un d'eux pourrait encore appartenir à quelque chose d'important.

Le résultat était une collection croissante de :

• instructions dupliquées
• exemples négatifs
• règles contradictoires
• solutions de contournement pour anciens modèles
• étapes de vérification excessives
• procédures détaillées ne s'appliquant qu'à une seule tâche
• exemples créés pour corriger des échecs qui n'existaient plus

Les anciens modèles avaient souvent besoin de cet échafaudage. Les nouveaux modèles suivent les instructions plus fidèlement et infèrent l'intention plus fiablement. Cela signifie qu'ils prennent aussi nos vieux bagages plus au sérieux.

Nous avons construit des moteurs plus intelligents, puis nous avons rempli le coffre de briques.

Portrait en noir et blanc à fort contraste d'une jeune femme blonde en col roulé sombre, cadre minimaliste en studio. Un léger contre-jour sépare sa silhouette d'un fond gris doux, renforçant la dimensionnalité. L'ambiance est introspective mais forte, incarnant un réalisme intemporel. Netteté numérique moyen format Hasselblad X2D, inspirée du photojournalisme du XXe siècle.

Le nouveau principe : dire moins, signifier plus

La solution n'est pas d'écrire des prompts minuscules et de faire aveuglément confiance au modèle.

Un prompt court mais ambigu reste un mauvais prompt.

L'objectif est un prompt à haute teneur informationnelle où chaque instruction mérite sa place.

Mes règles actuelles sont :

• Énoncer chaque instruction une fois.
• Supprimer les répétitions entre les prompts système, les fichiers de projet, les compétences, les descriptions d'outils et les prompts de tâche.
• Préférer une description claire du comportement souhaité à une collection de cas d'échec.
• Conserver les contraintes négatives lorsqu'elles protègent une véritable limite, mais cesser d'écrire des musées de tout ce que le modèle ne doit jamais faire.

Par exemple, au lieu de ceci :

Ne refactorisez pas de code non lié. Ne renommez pas de fichiers. Ne modifiez pas les API. N'ajoutez pas d'abstractions. Ne nettoyez pas les modules adjacents.

Mieux :

Limitez la modification au flux de connexion concerné. Préservez les contrats API existants et l'architecture environnante. Privilégiez la correction la plus petite et la plus correcte.

Même limite. Moins de bruit. Plus de place pour le jugement.

Dans un échantillon d'évaluation interne d'agent de codage, OpenAI a constaté que des prompts système plus légers amélioraient les scores d'environ 10 à 15 pour cent tout en réduisant l'utilisation de tokens de 41 à 66 pour cent et le coût de 33 à 67 pour cent. OpenAI précise également que ces chiffres sont indicatifs et doivent être validés sur votre propre charge de travail.

En d'autres termes, supprimer des instructions peut améliorer à la fois la qualité et la facture. C'est une combinaison rare et belle.

Votre fichier d'instructions global devrait être ennuyeux

Les fichiers globaux ~/.claude/CLAUDE.md et ~/.codex/AGENTS.md ne doivent contenir que des instructions qui s'appliquent à chaque projet et à chaque tâche.

Pour moi, en tant que germanophone natif, cela inclut des choses comme :

1Utilisez l'anglais pour tout le code, les commentaires, la documentation, les exemples,
2les tests, la configuration et les messages de commit.
3
4Préférez une terminologie inclusive comme allowlist/blocklist,
5primary/replica, placeholder/example, main branch,
6conflict-free, et concurrent/parallel.

C'est probablement déjà l'essentiel du fichier global.

• Les procédures de déploiement n'ont pas leur place ici.
• Les commandes de test spécifiques à un projet n'ont pas leur place ici.
• L'architecture d'un dépôt particulier n'a pas sa place ici.

Votre fichier d'instructions global ne devrait pas savoir comment déployer un site WordPress, publier un package npm et redémarrer une base de production. Ce n'est pas de la polyvalence. C'est de la confusion avec une bonne mise en forme.

Pour les fichiers au niveau projet, incluez les informations stables dont le modèle a réellement besoin de manière répétée : le but du projet, les contraintes architecturales importantes, les conventions inhabituelles et les orientations vers des instructions plus spécialisées.

Anthropic recommande désormais de viser moins de 200 lignes par fichier CLAUDE.md. Les fichiers plus longs consomment plus de contexte et peuvent réduire l'adhésion aux instructions. Sa documentation recommande également des règles spécifiques aux chemins et des compétences à la demande lorsque les fichiers d'instructions deviennent trop volumineux.

Deux cents lignes n'est pas une loi magique de la nature, mais c'est un excellent avertisseur d'incendie.

J'éviterais aussi de demander à Claude ou Codex de réécrire l'ensemble du système d'instructions tout seul et d'accepter le résultat sans le vérifier. J'ai essayé cela avec presque chaque nouveau modèle. Ils sont utiles pour trouver les duplications, les conflits et les coupes possibles, mais ils ont toujours tendance à conserver trop d'encombrement hérité ou à inventer une belle nouvelle bureaucratie.

Laissez le modèle préparer le plan de démolition. C'est vous qui devez décider quels murs sont porteurs.

Portrait d'une jeune femme posée aux cheveux blonds attachés en queue de cheval, rendu en tons noirs et blancs profonds. Éclairée en studio avec une lumière douce mais directionnelle qui accentue la géométrie du visage et les ombres naturelles. Photographiée avec un objectif 120 mm pour une compression douce, évoquant une esthétique portrait Hasselblad avec un réalisme tactile et une émotion retenue.

Arrêtez d'utiliser un seul fichier pour chaque modèle

Jusqu'à récemment, je créais CLAUDE.md et je créais un lien symbolique vers AGENTS.md.

Je ne fais plus cela.

Oui, maintenir deux fichiers est ennuyeux. Tout comme maintenir des correctifs séparés pour les navigateurs. Nous le faisons encore lorsque le comportement diffère.

Les modèles ont désormais des valeurs par défaut sensiblement différentes.

GPT-5.6 est plus concis par défaut, donc une instruction globale « sois concis » peut rendre certaines réponses trop courtes. Claude Opus 5 a tendance à produire des réponses plus longues destinées à l'utilisateur, donc une courte instruction sur la longueur de la réponse peut encore être utile. Fable 5 peut enquêter et planifier bien au-delà de ce qu'une tâche de routine nécessite, surtout à des niveaux d'effort plus élevés, il bénéficie donc de limites de périmètre et d'arrêt claires. Opus 5 effectue déjà une auto-vérification substantielle, ce qui signifie que les anciennes règles de « tout revérifier » peuvent créer une sur-vérification coûteuse.

Les faits communs du projet peuvent toujours vivre dans une documentation commune. L'adaptateur comportemental de haut niveau doit correspondre au modèle qui le lit.

Un prompt universel devient souvent le plus petit dénominateur commun.

Remplacez le prompt maître par des instructions à la demande

Ma structure préférée est un petit fichier central plus une documentation et des compétences spécifiques aux tâches.

Un fichier d'instructions de projet pourrait contenir ceci :

1Chargez les instructions spécifiques à une tâche uniquement lorsque cela est pertinent :
2
3- `docs/agent/commit_rules.md`
4- `docs/agent/code_review.md`
5- `docs/agent/debug_workflow.md`
6- `docs/agent/frontend_polish.md`
7- `docs/agent/release_notes.md`

Remarquez les backticks.

Dans Claude Code, écrire @docs/example.md en dehors d'une balise de code importe ce fichier dans le contexte au démarrage. C'est utile lorsque vous avez toujours besoin du contenu, mais ce n'est pas un chargement paresseux. Un chemin simple permet à l'agent de savoir où l'information existe sans transporter automatiquement l'intégralité du document dans chaque tâche.

Les compétences sont encore meilleures pour les procédures répétables. Leur corps complet n'est chargé que lorsque la compétence est utilisée, donc un workflow détaillé ne consomme pas de contexte pendant que vous corrigez un problème CSS sans rapport.

Une compétence de commit, par exemple, peut avoir un déclencheur étroit :

nom : git-commit-conventional

description : Utiliser après des modifications de code pour rédiger ou valider les messages de commit.

La compétence peut ensuite contenir le format exact, les types autorisés, la règle de longueur du sujet, les exigences du corps et le format de sortie.

1---
2nom : git-commit-conventional
3description : Utiliser pour rédiger ou valider les messages de commit git après des modifications de code. Ne pas utiliser pour les tâches de diagnostic uniquement, de planification uniquement ou de révision uniquement.
4---
5
6# Objectif
7
8Produire des messages de commit Conventional Commit qui sont courts, corrects et faciles à réviser.
9
10# Règles
11
12- Format : <type>(<scope>): <subject>
13- Types : feat | fix | docs | style | refactor | test | chore | perf
14- Sujet : mode impératif, pas de point, <= 50 caractères
15- Petites modifications : commit sur une ligne
16- Modifications plus importantes : ajouter un corps enveloppé expliquant quoi et pourquoi
17- Garder les commits atomiques et les diviser par préoccupation
18
19# Sortie
20
21Retourner 1 à 3 messages de commit candidats, puis recommander le meilleur.

Votre fichier d'instructions principal n'a pas besoin de transporter toute la constitution Conventional Commits dans chaque session de débogage.

Le saviez-vous ? Claude Code prend également en charge CLAUDE.local.md pour les paramètres personnels spécifiques au projet tels que les noms d'hôte locaux, les URL de sandbox, les comptes de test préférés ou les commandes spécifiques à la machine. Ajoutez-le à .gitignore. C'est enfin un foyer approprié pour les informations qui comptent beaucoup pour vous et pas du tout pour le reste de votre équipe.

Faites des prompts pour les résultats, pas pour la chorégraphie

Les nouveaux modèles fonctionnent généralement mieux lorsqu'ils comprennent la destination et les limites, plutôt que de recevoir une description rigide de chaque pas.

Dans la mesure du possible, je remplace « d'abord fais A, puis B, puis C » par :

• le résultat requis
• le contexte pertinent
• les contraintes strictes
• les preuves requises
• les critères de succès
• la limite d'approbation
• la condition d'arrêt

Par exemple :

1Objectif
2
3Corriger le flux de connexion défaillant dans l'application web.
4
5Contexte
6
7Concentrez-vous sur `apps/web` et `packages/auth`.
8Utilisez la sortie de test jointe comme point de départ.
9
10Contraintes
11
12Préservez les contrats API existants.
13Limitez les modifications au flux d'authentification.
14Privilégiez la correction la plus petite et la plus correcte.
15Élargissez la modification uniquement lorsque cela est nécessaire pour l'exactitude.
16
17Preuves
18
19Exécutez les tests pertinents et rapportez leurs résultats réels.
20Identifiez la cause racine avec des références aux fichiers concernés.
21
22Terminé quand
23
24Le test de connexion défaillant réussit.
25Les tests sont ajoutés ou mis à jour lorsque le comportement corrigé l'exige.
26Le résumé final explique la cause, la correction et tout risque restant.
27
28Approbation
29
30Vous pouvez inspecter les fichiers, modifier le code dans le périmètre et exécuter des tests non destructifs.
31Demandez avant les actions destructrices, les migrations de base de données, les écritures externes
32ou une expansion significative du périmètre.
33
34Arrêt
35
36Arrêtez lorsque la correction est implémentée, validée et résumée.

Cela donne à l'agent la liberté de résoudre le problème sans l'autorisation de rénover toute la maison en réparant une seule poignée de porte. (Utilisez un LLM pour générer des prompts comme celui-ci.)

Mettez l'effort de raisonnement dans les paramètres

• « Réfléchis plus fort. »
• « Ultra réflexion. »
• « Prends une profonde inspiration et raisonne étape par étape. »

Ces phrases ont eu une longue et distinguée carrière dans l'ingénierie des prompts. Il est temps d'en mettre beaucoup à la retraite avec dignité.

Utilisez les contrôles du modèle.

Définissez le niveau d'effort via /effort, l'API ou la configuration pertinente. Comparez plusieurs niveaux d'effort sur des tâches représentatives. Un niveau plus élevé n'est pas automatiquement meilleur.

OpenAI recommande de commencer les migrations GPT-5.6 au niveau d'effort existant et de tester un niveau inférieur. Il dit également que les prompts pour le mode Pro doivent rester concentrés sur l'objectif, le contexte, les contraintes, les preuves, les critères de succès et le format de sortie. Vous n'avez pas besoin de dire au modèle de « réfléchir plus fort. »

Un paramètre de raisonnement est un contrôle.

« S'il vous plaît, activez votre énorme cerveau numérique » est un encouragement de film de sport.

lire la description de l'image

ALT

Photographie en studio d'une femme sophistiquée aux cheveux noirs ondulés et à la coiffe chic, vêtue d'un pantalon en cuir taille haute. Elle est assise sur un tabouret bas, un genou plié vers l'avant, ses longues jambes attirant l'attention. Détail net, fond blanc immaculé et mouvement subtil dans les cheveux ajoutant de l'énergie. Le ton général rappelle la photographie éditoriale des années 1990 : propre, audacieuse, confiante.

L'autonomie a besoin d'une clôture

Les agents de codage modernes sont beaucoup plus proactifs. C'est utile jusqu'à ce que l'agent résolve trois problèmes supplémentaires, crée deux abstractions, lance six sous-agents et présente fièrement une architecture que vous n'avez jamais demandée.

Définissez les limites explicitement.

Définissez ce que l'agent peut faire sans demander. Définissez ce qui nécessite une approbation. Dites-lui quand s'arrêter.

Fixez également des limites à la délégation. Opus 5 et Fable 5 sont tous deux plus disposés à utiliser des sous-agents parallèles. C'est puissant pour des investigations indépendantes, mais coûteux et lent pour de petites tâches. Une correction de bug de douze lignes n'a pas besoin d'une réunion de comité.

Le mode Goal de Codex est vraiment excellent. Nous l'avons utilisé sur un projet pendant quatre jours en une seule session continue.

Mais ne traitez pas un agent de longue durée comme une mijoteuse. Vous ne pouvez pas ajouter un objectif le matin et supposer que le dîner sera correct quatre jours plus tard.

Pour nos sessions plus longues, nous faisons le point toutes les 30 à 60 minutes avec quelque chose comme :

Rapportez l'objectif actuel, le travail accompli, les preuves vérifiées,

les blocages actifs, la prochaine action et où la progression est documentée.

Fondez chaque affirmation de progression sur une sortie d'outil réelle ou l'état du dépôt.

Indiquez clairement ce qui reste non vérifié.

OpenAI décrit le mode Goal comme adapté à des objectifs qui peuvent durer des heures ou des jours et prend explicitement en charge la poursuite de la même session pour orienter le travail ou demander des mises à jour de statut. Anthropic recommande également de fonder les rapports de progression sur des résultats d'outils réels plutôt que de se fier à des affirmations narratives.

L'autonomie n'est pas l'absence de supervision. C'est une supervision à un niveau supérieur.

Portrait en gros plan d'une déesse illuminée par une lueur lunaire argentée, ses yeux brillants et remplis d'affection. Sa coiffe scintille de minuscules galaxies, de spirales inspirées de Klimt et de motifs célestes. L'arrière-plan est un fond pastel plat, soigneusement arrangé, avec une mise en scène théâtrale à la Anderson, des textures riches et un charme discret.

Refactorisez les prompts comme du code de production

Ne supprimez pas la moitié d'un prompt système, n'exécutez pas une tâche et ne déclarez pas la migration réussie.

OpenAI recommande de supprimer un groupe d'instructions, d'exemples ou d'outils à la fois, puis de réexécuter les mêmes évaluations. C'est exactement ainsi que la refactorisation des prompts devrait fonctionner.

Mesurez :

• le succès de la tâche
• l'exhaustivité
• l'exactitude
• les preuves requises
• l'utilisation de tokens
• la latence
• le coût
• les appels d'outils inutiles
• les modifications inutiles

Utilisez des tâches représentatives, y compris des cas concrets délicats, et pas une seule démo sympathique qui fonctionnait déjà avant la migration.

Un nettoyage de prompts sans évaluation reste une supposition. C'est simplement une supposition faite avec une chemise plus propre.

Le code généré contient encore des bugs

Les modèles se sont énormément améliorés. Ils n'ont pas abrogé les défauts logiciels.

Dans notre travail, une règle empirique est encore d'environ un problème pour 300 lignes de code source généré. Ce n'est pas un benchmark scientifique, et je ne compte pas les modèles HTML répétitifs de la même manière. Mais c'est suffisamment fiable pour que lorsqu'un agent génère 1 500 lignes de code d'application réel, je suppose que plusieurs bugs se cachent à l'intérieur, au moins 5.

Je ne demande pas s'il y a des bugs.

Je demande où sont les cinq bugs.

Parfois, j'ajoute :

Trouvez les cinq bugs, ou vous serez remplacé par Codex, Claude ou Grok.

Le développement basé sur la menace n'est pas une méthodologie officielle, mais cela peut être étrangement motivant. ;-)

Plus sérieusement, utilisez une nouvelle passe de révision pour les modifications importantes. Exécutez les tests pertinents. Inspectez le diff. Testez le comportement réel, pas seulement la compilation.

Et surveillez attentivement les tests. Les modèles préfèrent encore parfois « réparer » un test défaillant plutôt que de corriger le code de production qui l'a causé.

Une instruction utile est :

1Considérez les tests existants comme le comportement attendu à moins que les preuves ne montrent
2qu'un test est incorrect.
3
4Lorsqu'un test échoue, enquêtez d'abord sur le code de production.
5
6Avant de modifier un test existant, expliquez pourquoi son attente est erronée,
7quel devrait être le comportement correct et quelles preuves soutiennent ce changement.

Pour les tâches volumineuses et de longue durée, un vérificateur avec un nouveau contexte peut être utile. Pour une petite modification, lancer plusieurs agents uniquement pour se confirmer mutuellement gaspille généralement du temps et des tokens. La vérification doit correspondre à la taille et au risque de la tâche.

Ce que vous ne devriez pas supprimer

La leçon n'est pas « écrivez des prompts minuscules et faites confiance à la machine. »

• Conservez les limites de sécurité et de sûreté.
• Conservez les exigences légales et de conformité.
• Conservez les schémas de sortie exacts.
• Conservez le comportement spécifique au produit.
• Conservez les connaissances du domaine que le modèle ne peut pas déduire.
• Conservez les exigences d'approbation pour les actions importantes.
• Conservez les exigences de citation et de preuve.
• Conservez les critères de test et les définitions de « terminé ».
• Conservez les exemples qui corrigent un échec mesuré et reproductible.
• L'objectif n'est pas le prompt le plus court possible.
• L'objectif est un prompt où chaque instruction porte encore une information utile.

Un dernier bonus

OpenAI fournit une compétence Docs officielle qui peut inspecter un projet et appliquer ses directives de migration GPT-5.6 :

1$openai-docs migrer ce projet vers la famille de modèles GPT-5.6

C'est un premier passage utile. Ce n'est pas la révision finale.

Laissez Codex identifier les paramètres obsolètes, les instructions dupliquées et les opportunités de migration. Ensuite, inspectez chaque modification vous-même. Un agent de migration est un ingénieur junior très rapide, pas une cour constitutionnelle.

L'essentiel

• Traitez votre stack de prompts comme du code de production.
• Supprimez les instructions mortes.
• Supprimez les duplications.
• Séparez les préférences globales des règles de projet.
• Déplacez les procédures dans des compétences à la demande.
• Décrivez les résultats au lieu de scénariser chaque étape.
• Définissez un périmètre clair, des limites d'approbation, des exigences de preuve et des conditions d'arrêt.
• Contrôlez l'effort via les paramètres du modèle.
• Limitez les sous-agents.
• Évaluez chaque changement significatif.
• Les modèles les plus récents ont besoin de moins de micro-gestion, mais ils ont encore besoin de direction.
• Un bon prompt n'est plus un manuel d'instructions géant.

C'est une petite carte, une clôture solide et une ligne d'arrivée clairement marquée.

Avez-vous déjà commencé à migrer vos prompts et compétences ? Qu'avez-vous supprimé, et qu'est-ce qui est devenu inopinément meilleur ?

Liens

OpenAI GPT 5.6 meilleures pratiques :

https://developers.openai.com/api/docs/guides/latest-model?model=gpt-5.6#prompting-best-practices

Claude Opus 5 meilleures pratiques

https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-opus-5

Claude Fable 5 meilleures pratiques :

https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-fable-5

Compétences / plugins officiels OpenAI :

https://github.com/openai/plugins

Crédits : Image créée avec Midjourney. Recherche et tests pratiques par moi-même. Édité avec l'aide d'OpenAI, Claude et Grammarly.

Prompt de l'image principale :

1
2Portrait en noir et blanc en gros plan d'une femme blonde sereine, cheveux attachés en arrière, portant un pull à col roulé noir. L'effet clair-obscur façonne son visage avec une définition frappante, mêlant une lumière ambiante douce et une ombre audacieuse. Style moyen format avec un grain de film fin et une gradation tonale mélancolique. Évoque l'authenticité et la force.

PS : J'adore @Midjourney :-)