Le prompt engineering désigne l'art de formuler une instruction pour obtenir d'un modèle de langage le résultat visé. Ce n'est pas un réglage cosmétique : une étude parue le 6 septembre 2026 montre que changer la consigne donnée à un modèle change le score qu'il attribue à un texte pourtant inchangé.
Ce que recouvre exactement le terme
Un modèle de langage ne comprend pas une demande, il complète une séquence. La formulation que vous lui donnez ne fait pas qu'exprimer votre intention, elle détermine dans quelle région de ce qu'il a appris il ira chercher sa réponse. Deux consignes qui veulent dire la même chose pour un humain n'atteignent pas le même endroit.
D'où une confusion fréquente. Le prompt engineering n'est ni une collection d'astuces, ni une science exacte. C'est un travail d'ingénierie au sens ordinaire : on formule, on observe, on corrige, et on garde ce qui tient sur plusieurs essais plutôt que ce qui a marché une fois.
La preuve la plus nette que la consigne compte vient d'un domaine inattendu. Dans une analyse de la fabrique des scores de visibilité, l'auteur relève que lorsqu'un modèle est chargé de compter les mentions d'une marque dans un texte, modifier sa consigne modifie le score attribué au même texte. L'objet évalué n'a pas bougé, la mesure si. Une consigne n'est donc pas un emballage, elle fait partie de l'instrument.
Les quatre leviers qui portent l'essentiel
Beaucoup de listes circulent. Dans la pratique, quatre gestes expliquent la plus grande part de l'écart entre une réponse inutilisable et une réponse exploitable.
| Levier | Ce qu'on écrit | Le défaut qu'il corrige |
|---|---|---|
| Rôle et périmètre | Qui répond, pour qui, et ce qui est hors sujet | Une réponse générique, calibrée pour personne |
| Exemples | Deux ou trois cas résolus, dans le format attendu | Une consigne comprise de travers faute de référence |
| Décomposition | Les étapes à suivre, dans l'ordre, avant de conclure | Une conclusion plausible mais fausse sur une tâche à plusieurs temps |
| Format de sortie | La structure exacte attendue, et quoi faire en cas de doute | Un texte à retraiter à la main, inexploitable par un programme |
Le rôle et le périmètre
Dire à qui s'adresse la réponse change plus de choses que dire ce qu'on veut. Une note destinée à un dirigeant de PME et la même note destinée à un ingénieur ne diffèrent pas par leur exactitude mais par ce qu'elles supposent connu. Le périmètre compte autant : indiquer ce qui est hors sujet évite au modèle de meubler quand il ne sait pas.
Les exemples
C'est le levier le plus sous-utilisé et le plus rentable. Deux exemples résolus valent mieux qu'un paragraphe d'explications, parce qu'ils montrent le format, le ton et le niveau de détail en même temps. Un exemple mal choisi enferme cependant le modèle dans un moule : mieux vaut deux exemples différents qu'un seul répété.
La décomposition
Sur une tâche qui demande plusieurs opérations, exiger les étapes avant la conclusion améliore nettement la fiabilité. La raison est mécanique : le modèle produit son texte de gauche à droite, et une conclusion écrite avant le raisonnement ne peut pas s'appuyer dessus.
Le format de sortie
Dès qu'une réponse doit être lue par un programme, la décrire ne suffit pas, il faut la contraindre. Et surtout, dire quoi faire quand l'information manque. Un modèle à qui l'on n'a pas donné le droit de répondre « je ne sais pas » inventera une valeur pour respecter le format.
Ce qui ne marche pas, et qui circule quand même
Trois croyances tiennent une place disproportionnée dans les formations qu'on trouve en ligne.
Les formules magiques. Promettre un pourboire, menacer, invoquer l'urgence. Ces tournures ont produit des effets sur certaines versions de certains modèles, à un moment donné. Rien de tout cela ne survit à une mise à jour, et construire un processus dessus revient à bâtir sur une version.
Le prompt très long. Empiler les précisions dégrade souvent le résultat, parce que les instructions finissent par se contredire sans que personne s'en aperçoive. Un prompt qui grossit à chaque correction est un symptôme, pas une méthode.
Le test unique. Une réponse générative n'est pas déterministe. Juger une consigne sur un seul essai, c'est mesurer un tirage. La règle minimale est de rejouer trois fois la même consigne avant de conclure qu'elle fonctionne.
Là où le prompt s'arrête
Vient un moment où aucune formulation ne suffit, et il faut savoir le reconnaître plutôt que de continuer à polir.
Dès que la réponse dépend d'une information que le modèle n'a pas, la question n'est plus de savoir comment demander mais quoi fournir. Vos tarifs, votre catalogue, l'historique d'un client, une réglementation à jour : rien de tout cela ne s'obtient par une meilleure tournure. C'est le contexte fourni au modèle qui décide, et le travail se déplace vers la sélection de ce contexte.
Ce basculement porte un nom dans les équipes qui construisent des systèmes : on passe de l'écriture de la consigne à la construction de ce que le modèle a sous les yeux au moment de répondre. Le prompt reste nécessaire, il cesse d'être suffisant.
Ce que le prompt ne règle jamais sur un agent
La rupture est plus franche encore quand on passe d'une conversation à un agent qui agit seul, envoie des messages, écrit dans des outils, engage l'entreprise.
Un prompt décrit ce qu'on souhaite. Il ne décrit ni ce que l'agent a le droit de faire, ni ce qui se produit quand une action est rejouée. Ces deux questions relèvent du périmètre d'exécution, pas de la formulation, et aucune consigne bien tournée ne les remplace. Une étude sur 113 personnes a montré cet été que 133 des 148 actions abusives exécutées par un agent l'ont été après approbation humaine : ce n'était pas un problème de prompt.
C'est la raison pour laquelle déployer un agent en entreprise ne se réduit pas à bien écrire ses instructions. La formulation est la première couche, pas la seule, et le passage de l'IA qui répond à l'IA qui agit déplace le problème ailleurs.
Comment progresser vraiment
La méthode qui fonctionne tient en quatre habitudes, et aucune n'est spectaculaire.
Écrivez vos consignes dans un fichier, pas dans une conversation. Une consigne qui vit dans un historique de chat est perdue, et ne peut être ni comparée ni corrigée.
Constituez un jeu de cas. Dix entrées réelles, avec la sortie que vous attendez. C'est le seul moyen de savoir si une modification améliore ou dégrade, plutôt que de se fier à l'impression du jour.
Changez une chose à la fois. Modifier le rôle et les exemples ensemble rend le résultat ininterprétable.
Gardez la trace de ce qui a été rejeté. Sans elle, la même mauvaise idée revient tous les trois mois.
Ce qu'un dirigeant doit en retenir
Le prompt engineering est réel, mesurable, et il s'apprend. Il est aussi devenu, en deux ans, la partie la plus visible et la moins déterminante d'un projet d'automatisation.
La valeur ne vient pas de savoir formuler une consigne. Elle vient de disposer d'un jeu de cas qui dit si ça marche, d'un contexte propre et à jour à fournir au modèle, et d'un périmètre d'action écrit pour tout ce qui agit sans supervision permanente. C'est d'ailleurs le cœur de la méthode d'automatisation pour une PME : la consigne est l'affaire d'un après-midi, le reste est le métier.
Si vous voulez savoir lequel de ces trois manques vous coûte le plus aujourd'hui, c'est ce qu'établit le Diagnostic IA.