La semaine dernière, j’ai passé trois heures à écrire le prompt parfait. Tous les cas limites couverts. Chaque règle de mise en forme spécifiée. Douze paragraphes d’instructions détaillées pour un simple modèle d’e-mail.
Le résultat était pire qu’un prompt de deux phrases que j’avais bricolé la veille.
Ça arrive plus souvent que les gens ne l’avouent. On part du principe que plus de détails = meilleur résultat, que les prompts plus longs prouvent plus d’expertise, que la minutie gagne toujours. Parfois, oui. Et parfois, tout ce travail ne fait que brouiller le modèle ou gonfler votre facture d’API sans rien apporter.
La vraie question n’est pas de savoir quelle approche est « la bonne ». C’est de savoir quand chacune aide vraiment.
Le paradoxe de la longueur
Voici ce que la recherche continue de montrer : la longueur d’un prompt et la qualité de sortie ont une relation compliquée.
Une discussion Hacker News sur le prompt engineering illustre bien cette tension. Des chercheurs qui tentaient de comprendre le lien entre longueur et performance ont découvert quelque chose de contre-intuitif : “Prompt length would play a big factor in the performance of this approach. In practice, though, we discovered that it’s actually not as big a factor as we predicted.”
Un prompt de 410 tokens et un prompt de 57 tokens ont tous deux plutôt bien fonctionné dans leurs tests. Un prompt de 88 tokens a sous-performé. La longueur, à elle seule, n’expliquait presque rien.
Qu’est-ce qui comptait vraiment ? La précision. Les mêmes chercheurs ont conclu que “the relationship between performance of the estimation and the prompt structure is less about length, and more about ‘ambiguity.’” Des formulations ouvertes dégradent les résultats, quel que soit le nombre de mots.
Ça correspond à ce que les praticiens redécouvrent sans cesse. Selon l’analyse de Ruben Hassid, “Prompts exceeding 500 words generally show diminishing returns in terms of output quality.” Et ça se dégrade à mesure que vous rallongez : “For every 100 words added beyond the 500-word threshold, the model’s comprehension can drop by 12 %.”
Ces chiffres varient selon le modèle et la tâche. Mais le principe tient.
À quoi ressemblent vraiment les prompts longs
Andrew Ng et son équipe chez DeepLearning.AI appellent les prompts détaillés des « méga-prompts ». D’après leur recherche sur la sophistication des prompts, ce sont des instructions qui font “1 to 2 pages long” et qui donnent des consignes explicites couvrant chaque aspect de la tâche.
Ng soutient que la plupart des équipes ne poussent pas assez : “I still see teams not going far enough in terms of writing detailed instructions.”
Un méga-prompt bien conçu peut inclure :
- Une définition précise du rôle et de l’expertise
- Du contexte sur la situation
- Plusieurs exemples du rendu souhaité
- Des règles de mise en forme explicites
- Des contraintes et des choses à éviter
- Des critères de qualité pour la réponse
Voilà à quoi ça ressemble, concrètement :
Vous êtes un rédacteur B2B senior spécialisé dans les logiciels pour entreprises.
Votre lecteur cible est un VP marketing d’une entreprise de taille moyenne qui
s’est déjà fait avoir par des vendeurs d’IA trop prometteurs.
Rédigez un texte produit pour DataSync, une plateforme d’intégration de données.
Différenciateur clé : nous sommes honnêtes sur les limites. Notre outil
gère 80 % des intégrations parfaitement, et nous sommes transparents sur
les 20 % qui nécessitent du sur-mesure.
Exigences :
- Titre de moins de 12 mots, axé sur le bénéfice
- Sous-titre qui reconnaît le scepticisme de notre audience
- Trois puces sur les capacités
- Une puce sur les limites connues (ça construit la confiance)
- Appel à l’action axé sur « voir que ça marche », pas sur l’achat
Ton : sûr de lui mais jamais survendu. Pas de « révolutionner » ou « transformer ».Ce prompt laisse peu de place au hasard. L’IA sait exactement ce qu’on attend d’elle.
À quoi ressemblent vraiment les prompts courts
À l’autre extrémité, il y a le micro-prompt. Bref. Ciblé. Une tâche à la fois.
Écris un titre pour une plateforme d’intégration de données honnête. 10 mots max.Même idée générale. Une fraction des mots. Et l’IA complète le reste avec des valeurs par défaut raisonnables.
Un développeur sur Hacker News décrivait son évolution vers la concision : “I’ve stopped writing well-formed requests/questions and now I just state things like: ‘sed to replace line in a text file?’”
Malgré l’entrée ultra-compacte, le modèle a quand même donné des réponses utiles. Toutes les tâches n’ont pas besoin d’un échafaudage complexe.
La dimension du coût caché
Voici un truc dont on parle rarement quand on débat de la longueur des prompts : chaque token coûte de l’argent.
En se basant sur les tarifs actuels de l’API OpenAI, GPT-4o facture $2.50 par million de tokens en entrée et $10.00 par million de tokens en sortie. Ça peut sembler insignifiant pour une requête. Mais à l’échelle, ça pique.
Un prompt de 500 mots représente environ 650 tokens. Un prompt de 50 mots, environ 65 tokens. Si vous faites 10 000 appels API par jour, l’écart entre méga et micro s’accumule vite :
- Prompts à 650 tokens : 6.5 millions de tokens = $16.25/jour en coûts d’entrée
- Prompts à 65 tokens : 650 000 tokens = $1.63/jour en coûts d’entrée
Ça fait presque $5 300 d’économies par an, rien que sur les tokens d’entrée. Et sans même compter la sortie plus longue que les prompts détaillés déclenchent souvent.
La latence s’ajoute à ça. Plus le prompt est long, plus il est long à traiter. Si votre application doit répondre vite, ce prompt système de 500 mots crée un délai visible à chaque requête.
Pour du traitement par lot ou des prompts à usage unique, le coût compte moins. Pour des systèmes en production qui traitent des milliers de requêtes, c’est énorme.
Quand le détail nuit vraiment
L’idée que « plus, c’est mieux » s’effondre de façon prévisible dans certains cas.
D’abord, il y a le problème du « perdu au milieu ». L’analyse de Ruben Hassid sur la longueur des prompts le dit sans détour : “The single greatest threat to output quality is prompt bloat.” Quand les prompts s’allongent, ce qui se trouve au milieu est souvent ignoré. Des exigences critiques enfouies au paragraphe huit peuvent tout aussi bien ne pas exister.
Ensuite, les contradictions s’invitent. Écrivez assez d’instructions, et vous finirez par dire « sois concis mais complet » ou « sois créatif mais respecte exactement ce format ». Le modèle ne peut pas satisfaire les deux. Il en choisit une et ignore l’autre, ou produit un résultat confus en essayant de couper la poire en deux.
Enfin, il y a la surcharge cognitive. Un praticien, dans un fil Hacker News sur des bibliothèques de prompts, racontait son ressenti : “Sometimes I get the feeling that making super long and intricate prompts reduces the cognitive performance of the model.”
Sa solution ? “My usage has converged to making very simple and minimalistic prompts and doing minor adjustments after a few iterations.”
Le modèle n’est pas un collègue humain qui « apprécie le contexte ». C’est un moteur de reconnaissance de motifs. Trop de motifs à faire matcher, et le matching se dégrade.
Quand le détail aide vraiment
Rien de tout ça ne veut dire que les méga-prompts sont « faux ». Ils résolvent de vrais problèmes.
Quand la sortie part directement chez le client sans relecture, il faut du contrôle. Un prompt souple qui sort parfois une copie un peu hors marque, c’est OK pour des brouillons. C’est catastrophique pour des campagnes d’e-mails automatisées.
Quand vous allez réutiliser le prompt des centaines de fois, l’investissement se rentabilise. Passer deux heures à peaufiner un prompt que vous allez lancer 5 000 fois, c’est du bon calcul. Passer deux heures pour une demande ponctuelle, non.
Quand plusieurs morceaux doivent être cohérents, un seul prompt peut battre plusieurs. Une page d’atterrissage a besoin d’un titre, d’un sous-titre, d’un corps et d’un appel à l’action qui marchent ensemble. Des micro-prompts séparés peuvent être bons individuellement, puis se contredire une fois assemblés.
Un autre développeur, dans le même fil Hacker News, partageait sa méthode : “Some of my best system prompts are >20 lines of text, and all of them are necessary.”
La façon dont il les construisait est révélatrice : “every time the model does something undesired, even minor I add an explicit rule in the system prompt to handle it.” La longueur venait de besoins réels, pas d’une obsession théorique de la « complétude ».
C’est la différence clé. Les prompts longs qui grandissent à partir d’échecs réels fonctionnent. Les prompts longs écrits pour couvrir des cas limites hypothétiques ajoutent souvent juste du bruit.
L’alternative par enchaînement
Il existe une voie du milieu qui évite le piège du méga-prompt tout en gardant le niveau de contrôle dont vous avez besoin.
Paul Shirer explique dans son analyse des stratégies de prompts que les prompts enchaînés battent les méga-prompts pour la plupart des tâches. Son raisonnement : “You aren’t stuck with the result of a mega prompt that might have gone astray due to an overlooked detail.”
Avec un enchaînement, chaque étape est une consigne courte et focalisée :
- “Génère cinq concepts de titres pour ce produit.”
- “Prends le concept n°3 et écris trois variantes.”
- “Maintenant, écris le texte d’accompagnement pour la meilleure variante.”
- “Ajoute un appel à l’action qui colle au ton du titre.”
Chaque sortie nourrit la suivante. Si l’étape 2 déraille, vous corrigez avant l’étape 3, pas après l’exécution de tout le méga-prompt. Comme le dit Shirer, les prompts enchaînés fonctionnent comme “inching closer with each shot, adjusting your aim according to where the last arrow landed.”
Le compromis, c’est la vitesse. Les chaînes demandent plusieurs allers-retours. En usage interactif, ça va. En traitement par lot sur des milliers d’éléments, la charge s’accumule.
Lire les signaux
Comment savoir si votre prompt est trop long ou trop court ?
Trop long :
- La sortie ignore des instructions que vous aviez explicitement incluses
- Vous répétez le même point avec des mots différents
- Vous vous surprenez à contredire des sections précédentes
- La plupart des phrases sont « au cas où », plutôt qu’essentielles
- L’IA a l’air confuse sur ce que vous voulez vraiment
Trop court :
- La sortie est générique alors que vous aviez besoin de spécifique
- Les mêmes corrections en suivi, à chaque fois
- Mauvaises hypothèses sur l’audience, le ton ou le format
- Vous ajoutez sans arrêt des « et aussi… » en dernière minute
Le schéma, pour la plupart des tâches : commencez court, ajoutez uniquement ce qu’il faut à partir d’échecs réels, arrêtez quand c’est suffisamment bon.
Un cadre qui marche
Oubliez le débat méga vs micro. Posez plutôt ces questions.
À quel point cette sortie est-elle importante ? Les contenus critiques qui partent en production sans filtre justifient plus de détails. Les brouillons et l’exploration n’en ont pas besoin.
À quel point ce prompt est-il réutilisable ? Vingt utilisations justifient trente minutes de travail. Une utilisation justifie deux minutes.
Pouvez-vous itérer ? Si vous pouvez relancer facilement avec des ajustements, commencez court. Si c’est un traitement par lot qui doit marcher du premier coup, mettez les détails au début.
Quel est le contexte de coût ? À grand volume d’usage API, chaque token compte. Pour des requêtes ponctuelles, l’écart est négligeable.
Savez-vous exactement ce que vous voulez ? La certitude favorise les prompts détaillés. L’exploration favorise les prompts courts, avec itération rapide.
Le test de pertinence
La règle la plus simple possible : regardez chaque phrase de votre prompt et demandez-vous si la supprimer changerait la sortie.
Si oui, gardez-la. Le contexte pertinent améliore les résultats.
Si non, coupez. Le remplissage inutile dilue juste l’attention.
Un praticien, dans une discussion sur le prompt engineering, résumait ça parfaitement : “Irrelevant context is worse than no context, but it doesn’t mean a long prompt of relevant context is bad.”
Cette distinction compte plus que n’importe quelle règle de nombre de mots. Un prompt de 50 mots bourré de blabla performe moins bien qu’un prompt de 300 mots où chaque mot a sa raison d’être. Un prompt de 300 mots rempli de padding performe moins bien qu’un prompt ciblé de 50 mots.
Mesurez la pertinence, pas la longueur.
Ce qui change vraiment le comportement
Les prompts les plus efficaces partagent une qualité qui n’a rien à voir avec la longueur. Ils réduisent l’ambiguïté.
« Écris quelque chose de bien » est court, mais inutile. « Écris une description produit de 100 mots pour une gourde en acier inoxydable, destinée aux amateurs de plein air, en mettant l’accent sur la durabilité » est plus long, mais chaque mot a une fonction.
La recherche le confirme. En revenant à cette analyse Hacker News, l’idée centrale est que le prompt engineering consiste à viser la précision linguistique : “say what you mean in the most linguistically precise way possible.”
Pas plus de mots. Pas moins de mots. Les bons mots.
Certaines tâches ont besoin de beaucoup de bons mots. D’autres, de peu. La compétence, ce n’est pas de choisir un camp dans le débat méga vs micro. C’est d’apprendre à écrire exactement ce qu’il faut pour chaque situation, et à reconnaître dans quelle situation vous êtes réellement.
Commencez par ce dont la tâche a besoin. Ajoutez ce que vos échecs vous apprennent. Arrêtez quand la sortie est suffisamment bonne. La longueur de prompt qui en résulte est la longueur qui était la bonne.
