Prompt engineering : ce qui change vraiment la réponse

Le prompt n’est pas une incantation, c’est un brief

La plupart des déceptions face à un outil d’IA générative viennent d’un malentendu de départ : on attend d’une phrase de dix mots qu’elle produise le travail d’un brief de trois paragraphes. Un modèle de langage ne devine ni le client, ni le canal de diffusion, ni le niveau de langue attendu. Il produit la suite la plus plausible de la demande telle qu’elle est posée. Demande générique, réponse générique — le mécanisme n’a rien de mystérieux.

L’expression « prompt engineering » a été popularisée par des équipes techniques, ce qui a laissé croire à beaucoup d’indépendants que le sujet leur échappait. C’est l’inverse. Les leviers qui font réellement bouger la qualité d’une réponse sont ceux d’un brief : décrire une cible, un objectif, une contrainte, un format. Tout dirigeant qui a déjà commandé un visuel à un graphiste ou un texte à un rédacteur possède déjà la compétence de base.

L’usage, lui, s’est banalisé beaucoup plus vite que la pratique. Les chiffres publics montrent une adoption qui triple en deux ans, sans que la manière de s’en servir ait été formalisée dans les entreprises concernées.

Les deux séries ne portent pas sur le même périmètre — l’enquête de l’Insee exclut les entreprises de moins de 10 salariés, là où le baromètre France Num interroge massivement des TPE. Elles disent pourtant la même chose : beaucoup de comptes ouverts, peu de méthode. C’est précisément dans cet écart que se loge la différence de résultat entre deux personnes qui utilisent exactement le même outil.

Les cinq leviers qui changent réellement la réponse

1. Le contexte avant la demande

Le premier réflexe consiste à poser le décor avant de formuler la commande. Qui parle, à qui, dans quel but, avec quelles contraintes. « Rédige un e-mail de relance » produit un texte creux. « Je suis architecte d’intérieur indépendante, ce client a reçu un devis de 4 200 € il y a trois semaines et n’a pas répondu, je veux relancer sans donner l’impression d’insister » produit un texte qu’on peut envoyer après deux corrections. Le contexte n’est pas de la politesse envers la machine, c’est la matière première du résultat.

2. Le format de sortie, décrit explicitement

Un modèle a une tendance naturelle à produire des paragraphes équilibrés et des listes de cinq points. Si le livrable attendu est un tableau à trois colonnes, un script de 45 secondes ou trois variantes d’objet d’e-mail de moins de 50 caractères, il faut l’écrire. Préciser la longueur en signes ou en mots, le nombre d’éléments, la présence ou non de titres : ces contraintes se respectent bien et évitent la moitié du travail de remise en forme.

3. Deux ou trois exemples valent mieux que dix consignes

C’est le levier le plus sous-utilisé par les non-techniciens, et probablement le plus puissant. Plutôt que de décrire abstraitement votre ton, collez deux extraits de textes que vous avez écrits et demandez d’en reprendre le registre. Les praticiens appellent cela le few-shot : montrer plutôt que décrire. Deux à cinq exemples suffisent, et ils rendent la sortie beaucoup plus régulière d’une session à l’autre — un point décisif quand on produit du contenu en série.

4. Le critère de réussite

Ajouter une phrase du type « le texte est réussi si un lecteur pressé comprend l’offre en dix secondes » donne au modèle une cible évaluable. C’est aussi, accessoirement, un excellent test pour vous : si vous êtes incapable de formuler le critère de réussite, le problème n’est pas l’outil.

5. L’itération courte plutôt que la réécriture

Face à une réponse décevante, le réflexe fréquent est de repartir de zéro avec un prompt plus long. C’est rarement le bon calcul. Reprendre la réponse existante — « le deuxième paragraphe est trop commercial, réécris-le sur un ton factuel et coupe la dernière phrase » — coûte quelques secondes et converge plus vite. La conversation garde le contexte ; le nouveau prompt le perd.

Ce qui ne sert presque à rien

Une bonne partie de ce qui circule sous l’étiquette « prompt engineering » relève du folklore. Quelques pratiques dont l’effet est faible, nul, ou contre-productif :

• Les formules d’autorité empilées (« tu es le meilleur expert mondial de… ») : attribuer un rôle aide à cadrer le registre, mais la surenchère n’ajoute rien.
• Les menaces et récompenses fictives (« je te donnerai un pourboire ») : anecdotique face à un contexte bien posé.
• Les prompts de 2 000 mots recopiés d’un fichier partagé : ils encombrent la demande de contraintes qui ne sont pas les vôtres et rendent le débogage impossible.
• Le prompt unique censé produire l’article complet du premier coup : découper en plan, puis section par section, donne un résultat nettement plus contrôlable.
• Coller un document client entier « pour le contexte » : outre le bénéfice marginal, la CNIL rappelle qu’il ne faut pas transmettre à ces services d’informations confidentielles ou couvertes par un secret professionnel.

Passer du prompt jetable à la méthode réutilisable

Le gain réel n’apparaît pas au prompt isolé, mais à la troisième fois qu’on refait la même tâche. Un indépendant qui rédige chaque semaine des fiches produit, des comptes rendus de rendez-vous ou des posts de recrutement a intérêt à figer un modèle de brief : un bloc de contexte permanent sur l’activité et la cible, un bloc de format, deux exemples de référence, et seulement ensuite la demande du jour. Le tout tient dans un fichier texte que l’on copie-colle.

Cette bibliothèque a une deuxième vertu : elle rend les écarts diagnosticables. Quand la sortie se dégrade, on sait quelle brique modifier au lieu de tout réécrire. Elle survit aussi aux mises à jour des outils, puisqu’elle ne repose sur aucune astuce propre à un service donné — le contexte, le format et les exemples fonctionnent aussi bien avec ChatGPT, Claude ou Gemini.

Reste la question du temps. Écrire un brief structuré prend deux à trois minutes de plus qu’une question improvisée. Sur une tâche unique, le calcul est discutable. Sur une tâche répétée vingt fois dans l’année, il ne l’est plus. La bonne question n’est donc pas « quel est le meilleur prompt » mais « quelles sont les cinq tâches que je refais assez souvent pour mériter un brief écrit une bonne fois ». Pour tout le reste, une question directe et deux corrections dans le fil suffisent largement.

Un dernier point de méthode, souvent négligé : relire la sortie en cherchant l’erreur, pas la confirmation. Les modèles produisent des affirmations plausibles et fausses avec le même aplomb que les affirmations exactes. Tout chiffre, toute référence réglementaire, tout nom propre doit être vérifié ailleurs avant publication. C’est la seule règle du lot qui n’a rien à voir avec la rédaction du prompt, et c’est la plus coûteuse à ignorer.

En résumé

Le prompt engineering utile à un indépendant tient en une poignée de gestes : poser le contexte avant la demande, décrire le format attendu, montrer deux exemples plutôt que décrire dix règles, énoncer un critère de réussite et corriger dans le fil au lieu de tout réécrire. Rien de technique là-dedans, et rien qui dépende d’un outil en particulier. Le vrai investissement consiste à identifier les quelques tâches assez récurrentes pour justifier un brief écrit, puis à vérifier systématiquement ce qui sort — parce qu’une réponse bien formatée n’est pas pour autant une réponse exacte.