Les méga-prompts IA sont-ils vraiment meilleurs ?

Depuis quelque temps, j’ai pris une habitude assez étrange avec les IA.

Quand une tâche me paraît importante, je ne lui demande plus forcément directement ce que je veux. Je peux d’abord expliquer mon idée à une première IA, lui demander de fabriquer un « prompt parfait », récupérer un pavé de 8 000, 10 000 ou 15 000 caractères rempli de sections, de contraintes, de procédures et de vérifications, puis envoyer ce texte à l’IA qui doit réellement faire le travail.

Sur le papier, le raisonnement paraît logique : plus le prompt est précis, plus l’IA devrait comprendre ce qu’on attend d’elle.

Le problème, c’est que précision et longueur ne sont pas la même chose.

Avec les modèles de 2026, GPT-6 Astra et Sol, Claude 5.5, Gemini 4 Argon et les systèmes agentiques construits autour, la question inverse devient donc légitime :

Est-ce qu’à force de vouloir tout préciser, on finit par rendre l’IA moins bonne ?

J’ai lancé plusieurs recherches indépendantes sur le sujet, puis vérifié les affirmations les plus importantes à partir des documentations officielles et de la littérature technique récente.

La réponse est plus intéressante qu’un simple « prompts courts = bien » ou « prompts longs = bien ».

La conclusion en une phrase#

Un énorme prompt généré par IA n’est pas intrinsèquement meilleur qu’un prompt humain beaucoup plus court.

Ce qui compte surtout, c’est ce que le prompt apporte réellement : les informations que l’IA ne peut pas connaître, les contraintes qui changent la solution, le résultat attendu, les critères permettant de savoir si le travail est terminé et, dans le cas d’un agent, ses permissions et ses limites.

Autrement dit :

Ce n’est pas la quantité de texte qui compte. C’est la quantité de signal utile.

Cette nuance compte aussi dans l’autre sens : un prompt long n’est pas automatiquement mauvais.

Une migration logicielle complexe peut légitimement demander plusieurs pages de spécifications. Un agent qui travaille pendant une heure sur un dépôt a besoin de beaucoup plus d’informations qu’un chatbot auquel on demande d’expliquer git rebase.

Le problème commence quand la longueur augmente sans que l’information utile augmente avec elle.

Pourquoi un gros prompt donne souvent l’impression d’être meilleur#

Prenons deux demandes.

La première :

Trouve-moi le meilleur VPS.

La seconde précise le budget exact, la localisation, le stockage nécessaire, le type de facturation acceptable, les frais interdits, le besoin ou non d’IPv4 et les critères de fiabilité.

Le deuxième prompt a de bonnes chances de produire un meilleur résultat.

Mais conclure qu’il est meilleur simplement parce qu’il est plus long serait une erreur.

Il est meilleur parce qu’il contient davantage d’informations nécessaires à la décision.

C’est le problème fondamental de beaucoup de comparaisons de prompts : plusieurs variables changent en même temps.

Pour étudier sérieusement la question, il faut distinguer au moins :

• la longueur ;

• le nombre d’instructions ;

• la quantité d’information utile ;

• la redondance ;

• l’organisation ;

• la présence de contexte inutile ;

• le système dans lequel le prompt est utilisé.

Un prompt de 12 000 caractères contenant douze contraintes métier indépendantes n’a presque rien à voir avec un prompt de 12 000 caractères qui répète quatre fois les mêmes intentions sous des titres différents.

Les modèles ont une capacité limitée à respecter beaucoup de règles simultanément#

C’est l’un des résultats expérimentaux les plus intéressants sur le sujet.

Dans When Instructions Multiply, publié dans Findings of EMNLP 2025, les chercheurs ont créé deux benchmarks contrôlés : ManyIFEval pour le texte, avec jusqu’à dix instructions simultanées, et StyleMBPP pour le code, avec jusqu’à six contraintes.

Sur dix LLM différents, les performances diminuent régulièrement à mesure que le nombre d’instructions augmente.

IFScale pousse l’expérience beaucoup plus loin, avec jusqu’à 500 instructions d’inclusion de mots simultanées. Sur vingt modèles provenant de sept fournisseurs, le meilleur n’atteint plus que 68 % de conformité au niveau maximal.

Évidemment, personne ne demande normalement à ChatGPT de respecter 500 mots obligatoires dans un rapport.

Ce benchmark ne permet donc pas de fixer une limite du type :

« Au-delà de 80 règles, votre prompt est mauvais. »

En revanche, il montre quelque chose de beaucoup plus important :

les instructions supplémentaires ne sont pas gratuites.

Une fenêtre de contexte d’un million de tokens n’implique pas qu’un modèle soit capable de respecter parfaitement un million de tokens d’instructions.

Ce sont deux propriétés complètement différentes.

Une grande fenêtre de contexte n’est pas une mémoire parfaite#

Les modèles modernes affichent des fenêtres de contexte gigantesques.

GPT-6 Astra, GPT-6.1 Sol et Luna supportent actuellement environ 1,05 million de tokens côté API. Gemini 4 Argon est lui aussi conçu pour des contextes extrêmement importants.

Il est tentant d’en déduire :

« 10 000 caractères, ce n’est rien. Je peux donc mettre autant de texte que je veux. »

Mais ce raisonnement est faux.

La taille maximale du contexte indique combien d’informations peuvent être transportées. Elle ne garantit pas que toutes seront exploitées avec la même efficacité.

NoLiMa, publié à ICML 2025, a justement étudié des modèles disposant de grandes fenêtres de contexte tout en supprimant une partie des raccourcis simples de récupération par correspondance lexicale.

À 32 000 tokens, la majorité des modèles testés étaient déjà tombés sous la moitié de leurs performances obtenues avec un contexte court.

Un autre travail publié dans Findings of EMNLP 2025 va encore plus loin : les chercheurs ont essayé d’éliminer le problème de récupération lui-même.

Même lorsque les informations pertinentes étaient parfaitement disponibles, les performances sur des tâches de mathématiques, de questions-réponses et de programmation diminuaient avec l’allongement du contexte. Les chutes observées allaient de 13,9 % à 85 % selon la configuration.

Cela ne prouve pas qu’un prompt de 10 000 caractères réduit automatiquement les performances de GPT-6 Astra en 2026.

Les modèles testés et les tâches ne sont pas identiques.

En revanche, cela suffit à casser une idée beaucoup plus simple :

Du texte supplémentaire n’est pas nécessairement gratuit simplement parce qu’il tient dans la fenêtre de contexte.

Les fabricants eux-mêmes commencent à retirer du prompting#

C’est probablement l’un des changements les plus intéressants de ces dernières années.

OpenAI a publié en septembre 2026 un article explicitement intitulé Rethinking skills and prompts for GPT-6 Astra.

Le message est assez clair : beaucoup de techniques utilisées pour guider les modèles précédents deviennent inutiles, voire nuisibles.

OpenAI explique notamment que des descriptions de skills trop longues peuvent être tronquées, que des skills qui se chevauchent peuvent déclencher les mauvaises instructions, que demander de lire systématiquement plusieurs documents gaspille du contexte et que des « recettes » très détaillées peuvent désormais surcontraindre Astra.

Le guide officiel de la famille GPT-6 résume l’idée avec quelque chose de très proche d’un cahier des charges humain normal : donner au modèle le résultat recherché, le public concerné, le contexte et les contraintes importantes, puis définir ce que signifie « terminé ».

OpenAI recommande également, pour les modèles de raisonnement, des prompts simples et directs et déconseille les demandes artificielles de chaîne de pensée comme « think step by step ».

Anthropic a connu une évolution similaire.

En 2026, l’entreprise explique avoir retiré plus de 80 % du system prompt de Claude Code pour ses nouveaux modèles Claude 5.

Ce n’est pas parce que les instructions sont devenues inutiles.

C’est parce que les modèles plus capables ont moins besoin qu’on leur explique comment réfléchir à chaque étape.

Le cas Claude Code est particulièrement parlant#

Claude Code permet de répartir les instructions dans plusieurs endroits : CLAUDE.md, règles spécifiques à certains chemins, skills, subagents, hooks et system prompts additionnels.

Pourquoi autant de mécanismes ?

Parce que toutes les informations ne devraient pas vivre au même endroit.

Anthropic explique qu’un CLAUDE.md racine est chargé dans toutes les sessions et que chaque ligne consomme donc du contexte, même lorsqu’elle n’est pas pertinente.

Sa recommandation actuelle est de garder ce fichier sous environ 200 lignes et de déplacer les procédures spécialisées vers des skills, ou les règles locales vers des fichiers chargés uniquement lorsqu’ils deviennent nécessaires.

Google applique la même philosophie dans Antigravity.

Charger toutes les règles et tous les outils dans le contexte crée ce que Google appelle du tool bloat : davantage de coût, de latence et de confusion. Ses Skills reposent donc sur la progressive disclosure : l’agent connaît d’abord l’existence d’une compétence, puis ne charge son contenu complet que lorsque la tâche la nécessite.

Cette architecture dit quelque chose de fondamental sur le futur de l’utilisation des IA :

le problème n’est plus seulement d’écrire un bon prompt. Il faut organiser le contexte.

Du prompt engineering au context engineering#

Anthropic formule cette évolution très directement.

Le prompt engineering cherche principalement à déterminer comment écrire les instructions.

Le context engineering cherche plutôt à déterminer quelles informations doivent être présentes dans le contexte du modèle à cet instant précis.

Cela comprend le prompt utilisateur, le system prompt, les outils disponibles, les fichiers, le code du dépôt, la mémoire, les résultats de recherche, les actions précédentes de l’agent, les skills et éventuellement les résultats de subagents.

Cette distinction devient essentielle avec les agents.

Pour un chatbot classique, on peut encore penser en termes de :

question → réponse.

Avec Codex, Claude Code, Antigravity ou ChatGPT Work, on se rapproche plutôt de :

mission → observation → action → nouvel état → nouvelle observation → vérification → action suivante.

Réinjecter la totalité des connaissances du projet à chaque étape n’est pas forcément intelligent.

Le meilleur contexte n’est donc pas le plus gros.

C’est le bon contexte au bon moment.

Et les prompts générés par une IA ?#

C’est là que la question devient vraiment intéressante.

Imaginons ce workflow :

idée humaine → IA spécialisée en prompts → prompt de 12 000 caractères → IA cible.

Est-ce une bonne idée ?

Pas forcément.

Une IA peut réellement améliorer un prompt en découvrant une information que l’utilisateur avait oubliée.

Elle peut demander :

• quel budget ?

• quelle compatibilité ?

• quels utilisateurs ?

• quelles actions sont interdites ?

• comment mesurer la réussite ?

• quelles hypothèses sont encore inconnues ?

Dans ce cas, elle crée de la nouvelle information utile.

C’est précieux.

Mais il existe une autre forme d’« optimisation » beaucoup moins convaincante :

« Agis comme un architecte logiciel senior de classe mondiale, expert UX, spécialiste sécurité, analyste marché et consultant stratégique. Cette mission est extrêmement importante. Procède méthodiquement. Première phase… deuxième phase… troisième phase… Sois exhaustif, rigoureux, précis… »

Le texte a augmenté.

L’information, pratiquement pas.

Parfois, le générateur va encore plus loin : il ajoute une méthodologie que l’utilisateur n’avait jamais demandée, fixe arbitrairement le nombre de phases, impose un format, énumère des technologies ou transforme des préférences supposées en contraintes.

Le danger n’est alors pas seulement que l’IA cible lise trop de texte.

Le danger, c’est que l’humain ne sache plus exactement ce qu’il a demandé.

Pourtant, l’optimisation automatique de prompts fonctionne réellement#

Ce serait une erreur de conclure que les IA ne devraient jamais aider à écrire les prompts.

PromptWizard, publié dans Findings of ACL 2025, utilise une boucle de critique, de feedback et de synthèse pour optimiser automatiquement instructions et exemples. Il rapporte des améliorations sur 45 tâches.

SPRIG, accepté à ICLR 2026, optimise des system prompts à travers 47 types de tâches et montre qu’un system prompt optimisé peut rivaliser avec des prompts spécialisés tâche par tâche.

La nuance est capitale.

Ces systèmes ne fonctionnent pas simplement comme ceci :

« écris davantage de texte ».

Ils fonctionnent davantage comme ceci :

prompt → résultats → mesure des erreurs → modification → nouvelle évaluation.

OpenAI applique actuellement exactement cette logique dans son Prompt Optimizer : utiliser des datasets, des annotations et des graders pour améliorer un prompt, puis réévaluer la nouvelle version et la vérifier humainement. OpenAI prévient même qu’une optimisation peut améliorer le score général tout en dégradant certains inputs particuliers.

C’est probablement la meilleure réponse à la question :

Oui, une IA peut être excellente pour améliorer un prompt. Mais son intérêt principal n’est pas d’écrire plus. C’est de détecter ce qui manque et ce qui échoue.

ChatGPT, Deep Research et Codex ne devraient pas recevoir les mêmes prompts#

Une erreur assez fréquente consiste à appliquer la même philosophie de prompting à tous les produits.

Pour une conversation ChatGPT classique, la plupart du temps, on peut directement fournir :

objectif + contexte indispensable + contraintes importantes + résultat voulu.

Pour une mission de Deep Research, davantage de cadrage devient pertinent :

question exacte + période + définitions + types de sources + standard de preuve + livrable.

Mais il n’est pas forcément nécessaire d’expliquer au research agent les vingt requêtes Google qu’il doit lancer dans un ordre prédéfini. Son rôle est justement de planifier et d’adapter ses recherches.

Pour Codex ou Claude Code, une mission complexe peut nécessiter énormément d’informations.

Mais elles devraient être réparties.

Les règles stables du dépôt peuvent vivre dans AGENTS.md ou CLAUDE.md.

Une procédure spécialisée peut devenir un Skill.

Les contraintes exécutables peuvent être garanties par les tests, le linter ou des hooks.

Le dépôt contient l’état réel du logiciel.

Le prompt courant n’a alors besoin de dire principalement :

voici ce qui doit changer, pourquoi, ce qui ne doit pas casser et comment reconnaître que la tâche est terminée.

C’est une architecture beaucoup plus robuste que de copier quinze pages d’instructions dans chaque nouvelle conversation.

Un détail important : nous n’avons pas encore l’expérience parfaite#

C’est probablement le point que je trouve le plus important après toute cette recherche.

Nous avons aujourd’hui de bonnes preuves que :

• le suivi se dégrade avec l’augmentation du nombre d’instructions ;

• le contexte long n’est pas exploité parfaitement ;

• le contexte inutile peut nuire ;

• les modèles modernes demandent souvent moins de scaffolding ;

• la distribution contextuelle et le chargement à la demande sont devenus des pratiques centrales des agents modernes ;

• l’optimisation automatique de prompts peut fonctionner lorsqu’elle utilise de vraies évaluations.

Mais nous n’avons toujours pas une énorme étude propre prenant exactement les modèles de pointe d’octobre 2026, GPT-6 Astra, Claude Opus 5.5, Gemini 4 Argon, etc., et testant à information strictement constante :

1. un prompt humain naturel ;

2. un prompt humain structuré ;

3. le même prompt gonflé par une IA ;

4. une version experte compressée ;

5. une version volontairement redondante.

Ce benchmark serait extrêmement intéressant.

Tant qu’il n’existe pas, affirmer qu’un prompt de « 8 000 caractères est optimal » ou qu’« après 5 000 caractères les performances baissent » serait de la fausse précision.

Il n’existe pas de nombre magique.

La règle que je retiens#

Après cette recherche, je ne chercherais plus à produire le prompt le plus complet possible.

Je chercherais plutôt :

le plus petit contexte contenant toutes les informations qui pourraient raisonnablement changer la bonne réponse ou la bonne exécution.

Chaque phrase peut passer un test simple :

Si je retire cette phrase, quelle erreur concrète devient plus probable ?

S’il existe une bonne réponse, la phrase mérite probablement sa place.

Si la seule réponse est :

« ça donne l’impression que le prompt est plus sérieux »,

elle peut probablement disparaître.

Alors, les méga-prompts sont-ils du bullshit ?#

Pas exactement.

Une spécification de 15 000 caractères peut être excellente.

Une spécification de 30 000 caractères peut même être indispensable.

Mais elle doit être longue parce que le problème possède réellement autant d’informations indépendantes, pas parce qu’une IA a transformé cinq idées en vingt rubriques.

Le véritable changement de 2026 n’est donc pas :

« utilisez des prompts courts ».

C’est plutôt :

arrêtez d’optimiser le nombre de mots. Optimisez l’information que le modèle reçoit, l’endroit où elle est placée et le moment où elle devient disponible.

Pour les agents modernes, ce changement porte déjà un nom :

context engineering.

Le meilleur prompt n’est probablement pas celui qui semble le plus impressionnant lorsqu’on le fait défiler.

C’est celui dans lequel presque chaque phrase a une raison d’être.