Devant l’écran, la phrase tient en une ligne : « Résume ce document. » La machine répond, mais rate l’essentiel, adopte un ton maladroit et mélange les priorités. On recommence alors, non en ajoutant de la puissance de calcul, mais en précisant l’intention : à qui s’adresse le texte, ce qu’il faut conserver, ce qu’il faut écarter, la forme attendue. Soudain, la réponse devient exploitable. Entre les deux essais, il n’y a pas eu de magie : il y a eu du langage.
C’est dans cet espace que s’est installé le prompt engineer, figure souvent présentée comme le nouveau dompteur des intelligences artificielles. L’expression peut faire sourire : faut-il vraiment un ingénieur pour écrire une bonne consigne ? Elle désigne pourtant une compétence durable, bien plus large que la maîtrise d’une formule secrète. Savoir demander, cadrer, vérifier et itérer est une manière de travailler avec les machines, mais aussi avec les humains.
Un métier né d’un malentendu fécond
Le mot « prompt » désigne l’instruction adressée à un système conversationnel. À première vue, l’affaire semble simple : on pose une question, on reçoit une réponse. Mais les modèles de langage ne comprennent pas une demande comme le ferait un collègue familier de votre métier. Ils produisent du texte à partir de régularités apprises dans d’immenses ensembles de données. Leur aisance verbale peut donner l’illusion d’une compréhension pleine ; elle ne dispense ni du contexte, ni du contrôle.
Le prompt engineer est donc moins un spécialiste des formules miraculeuses qu’un concepteur d’interactions. Son travail consiste à transformer une intention parfois floue en une tâche suffisamment définie pour qu’un modèle puisse s’en acquitter. Il ne « parle pas machine » au sens où l’on parlerait un langage de programmation. Il pratique plutôt une forme d’ingénierie de la consigne.
Cette nuance compte. La fascination pour le métier a parfois nourri l’idée qu’une poignée d’initiés détiendrait des incantations capables de tirer le meilleur de n’importe quel outil. Or un prompt performant dépend d’un objectif, d’un corpus, d’un niveau de risque et d’un usage précis. Une bonne demande pour imaginer des pistes de titres n’a rien à voir avec une bonne demande pour analyser un contrat, préparer une formation ou assister un service client.
Un prompt n’est pas une question bien tournée : c’est une situation de travail rendue explicite.
Le vrai travail commence avant la première instruction
Quand une réponse produite par une IA déçoit, le réflexe est souvent de retoucher la formulation. C’est parfois utile, mais le problème se situe fréquemment plus en amont. Quelle décision la réponse doit-elle aider à prendre ? Quel public faut-il servir ? Quelles sources sont recevables ? De quel degré de précision a-t-on besoin ? Qu’est-ce qui serait, au contraire, une erreur inacceptable ?
Le prompt engineer commence par ce travail de clarification. Il transforme une demande vague, « aide-moi à faire une stratégie », en un problème délimité. Cela suppose de distinguer l’exploration, où l’on cherche des hypothèses et des angles, de la production, où l’on attend un livrable cadré, puis de la décision, qui engage une responsabilité et ne peut être déléguée à un générateur de texte.
Cette discipline rappelle les bons réflexes du journalisme, du conseil, du design ou de la recherche : préciser l’objet, identifier les inconnues, poser les contraintes. L’outil peut accélérer le travail de formulation ; il ne peut pas décider seul de ce qui mérite d’être formulé.
Un bon prompt comporte souvent plusieurs couches :
- un rôle ou une perspective utile : relecteur, analyste, contradicteur, pédagogue ;
- un objectif concret : comparer, résumer, classer, reformuler, extraire ;
- un contexte : public visé, documents disponibles, état d’avancement ;
- des contraintes : longueur, registre, critères d’exclusion, format de sortie ;
- un mécanisme de vérification : incertitudes signalées, points à confirmer, sources à demander.
La précision n’implique pas la lourdeur. Une consigne trop chargée peut devenir contradictoire, ou noyer l’objectif sous des détails secondaires. L’enjeu est d’offrir au modèle un cadre lisible, pas de lui dicter chaque mot.
Le dialogue plutôt que la formule unique
L’image du prompt parfait est trompeuse. Dans la plupart des usages sérieux, on ne lance pas une instruction définitive : on organise une conversation de travail. On commence par demander une structure, on teste un premier résultat, on corrige un angle, on apporte un document, on exige une variante. Le prompting est moins un acte d’écriture qu’un processus d’itération.
Cette manière de faire permet surtout de séparer les opérations. Demander à un même modèle de comprendre un dossier complexe, d’en tirer des faits, de proposer une stratégie, puis de rédiger un texte élégant en une seule étape est rarement une bonne idée. Chaque tâche appelle ses propres critères. Mieux vaut fractionner le parcours : extraction, synthèse, critique, mise en forme. À chaque étape, on peut inspecter ce qui a été produit, pour apprendre à lire entre les lignes.
Le principe est simple : plus une réponse a de conséquences, plus il faut rendre le raisonnement du processus observable. Non pas nécessairement en demandant au modèle de dévoiler une prétendue pensée interne, mais en lui faisant expliciter ses hypothèses, lister les informations manquantes, distinguer les faits fournis des interprétations et proposer plusieurs options argumentées.
Cette exigence de traçabilité protège d’un piège familier : une réponse fluide paraît facilement juste. Or la cohérence du style ne garantit ni la validité des faits, ni la pertinence du jugement. Un texte convaincant peut cacher une approximation, une source inexistante ou un raccourci dangereux.
Les compétences qui restent quand les outils changent
Les interfaces, les modèles et les fonctionnalités évoluent vite. Certaines astuces liées à un outil particulier vieillissent donc mal. Les capacités les plus solides du prompt engineer, elles, résistent mieux aux changements techniques.
La première est la capacité de décomposition. Face à un objectif vaste, il faut savoir identifier des sous-problèmes manipulables. La deuxième est l’esprit critique : repérer une réponse trop générale, une prémisse discutable, un oubli significatif. La troisième est la culture du domaine. Un modèle peut aider à rédiger une note médicale, juridique ou financière, mais il ne remplace pas la compétence qui permet de reconnaître une erreur dans ces matières.
Vient ensuite la maîtrise éditoriale. Dire « écris mieux » ne suffit pas. Il faut pouvoir nommer ce que l’on attend : un ton plus direct, une progression plus nette, des exemples concrets, moins de jargon, une objection prise au sérieux. En ce sens, les professionnels habitués à formuler des briefs, rédacteurs, chefs de produit, enseignants, chercheurs, managers, disposent déjà d’une partie du bagage nécessaire.
Enfin, il y a une compétence moins spectaculaire : savoir renoncer. Si les données sont insuffisantes, si la confidentialité est en jeu ou si la réponse touche à une décision sensible, le bon prompt peut être celui qui demande à l’outil de s’arrêter, de signaler ses limites ou de préparer des questions pour un expert humain.
Une méthode de travail en cinq gestes
Pour sortir de l’improvisation, on peut adopter une méthode légère. Elle vaut pour la rédaction, l’analyse de documents, la préparation de réunions ou la recherche d’idées.
- Définir le livrable. Avant d’ouvrir l’outil, formuler ce qui doit exister à la fin : une note, un tableau, un plan, une liste de questions, une synthèse critique.
- Fournir la matière. Si la tâche repose sur des documents ou des informations internes, les donner plutôt que de supposer que le modèle les connaît.
- Fixer les limites. Indiquer ce qui ne doit pas être inventé, les termes à conserver, les données à traiter avec prudence et les points hors périmètre.
- Demander une forme contrôlable. Un tableau, une liste hiérarchisée ou une réponse structurée sont plus faciles à relire qu’un bloc de prose.
- Évaluer avant de réutiliser. Vérifier la justesse, la complétude, le ton et les omissions avant d’intégrer le résultat dans un document ou une décision.
Ce dernier geste est décisif. Le contrôle humain ne doit pas être une formalité placée à la fin d’une chaîne automatisée. Il organise toute la chaîne : choix des entrées, définition des critères, lecture du résultat et responsabilité de l’usage.
Chuchoter, oui ; abandonner son jugement, non
Le prompt engineer incarne finalement une question plus ancienne que l’intelligence artificielle : comment obtenir une réponse utile d’un système complexe sans lui prêter plus d’autorité qu’il n’en a ? La réponse n’est pas de parler plus fort à la machine, ni de lui confier indistinctement le travail intellectuel. Elle consiste à mieux décrire les problèmes, à organiser les retours et à maintenir une vigilance proportionnée aux enjeux.
Les meilleurs prompts ne sont pas ceux qui impressionnent par leur longueur. Ce sont ceux qui rendent le travail plus clair, plus vérifiable et plus fécond. Ils ne remplacent pas l’expertise : ils obligent souvent à la rendre explicite. Et c’est peut-être là leur intérêt le plus durable. En apprenant à chuchoter aux machines, on redécouvre l’art, beaucoup plus humain, de formuler ce que l’on veut vraiment obtenir.
