Qu’est-ce que le prompt engineering ? Guide pratique pour 2026

Vous demandez à une IA d’« écrire quelque chose de bien » et recevez cinq paragraphes qui ressemblent à une brochure trouvée dans un aéroport. Le modèle a produit des mots. Vous espériez une idée. Quelque part entre ces deux réussites se trouve le prompt engineering.

Malgré son allure d’intitulé de poste, la compétence de base est accessible : expliquer la tâche, fournir les informations nécessaires et vérifier si la réponse fonctionne réellement. Aucune phrase secrète ne transforme tous les chatbots en experts fiables. Il existe cependant de bien meilleurs briefs que « fais le truc ».

Qu’est-ce que le prompt engineering ?

Le prompt engineering consiste à concevoir et tester les instructions données à un modèle d’IA. Un prompt peut contenir une question, une tâche, des éléments de contexte, des exemples et des exigences pour le résultat. Pour comprendre la mécanique sous-jacente, notre guide sur le fonctionnement des grands modèles de langage (en anglais) explique pourquoi des réponses fluides sont possibles sans considérer le modèle comme une personne qui connaît vos intentions.

Votre dernier message n’est qu’une partie de ce que le système peut recevoir. Messages antérieurs, consignes de l’application, documents récupérés et résultats d’outils peuvent aussi occuper sa fenêtre de contexte. L’explication de l’ingénierie du contexte par Anthropic distingue la rédaction des instructions de la gestion de cet ensemble plus vaste d’informations. Une demande magnifiquement écrite ne compense pas un document essentiel jamais fourni.

Pensez au prompt comme à un brief destiné à un collaborateur très rapide qui n’a pas assisté à vos réunions. Inclure l’ordre du jour aide. Supposer qu’il a absorbé six mois de politique de bureau à travers le clavier, non.

Un prompt utile commence par un brief utile

Voici une liste pratique plutôt qu’une incantation obligatoire en cinq parties :

• Tâche : que doit produire ou faire le modèle ?
• Contexte : quels faits, sources et destinataires comptent ?
• Format : un paragraphe, un tableau, un brouillon de courriel ou une autre forme exploitable ?
• Contraintes : que faut-il inclure, éviter ou laisser indécis ?
• Perspective : un rôle éditorial particulier serait-il utile ?

Par exemple : « Rédige une description produit de 120 mots pour un mug en céramique avec un chat, en utilisant uniquement ces caractéristiques : 350 ml, céramique blanche, motif imprimé de chat noir. Écris pour des personnes cherchant un petit cadeau d’anniversaire. Adopte un ton chaleureux et joueur. Indique la contenance. N’invente pas de compatibilité avec le lave-vaisselle ou le micro-ondes ; ces détails n’ont pas été fournis. »

Cette demande fournit des décisions que le modèle devrait autrement deviner. Elle crée aussi des éléments vérifiables : longueur, contenance indiquée et éventuelles promesses inventées. Elle ne garantit pas le respect des consignes. Si la réponse prétend que le mug résiste aux températures volcaniques, le brief est devenu un test auquel le modèle a échoué.

Un rôle peut orienter le ton et la perspective : « Révise ce texte comme un éditeur technique patient » est raisonnable. « Tu es un expert-comptable certifié avec vingt ans d’expérience » ne confère aucune qualification. Un rôle n’est pas non plus nécessaire pour une demande simple comme classer une liste par ordre alphabétique.

Montrez le résultat recherché

Les exemples sont particulièrement utiles lorsqu’un qualificatif comme « sympathique » laisse trop de place à l’interprétation. Anthropic recommande des exemples représentatifs et des consignes claires, en ajoutant des détails en réponse aux échecs observés plutôt qu’en enterrant la tâche sous toutes les exceptions imaginables.

Supposons que vous vouliez de courtes légendes pour des photos de chats. Vous pourriez fournir un exemple original : « Photo : chat assis dans une valise vide. Légende : La direction a annulé vos vacances. » Demandez ensuite trois légendes aussi brèves pour un chat endormi sur un clavier, sans reprendre la plaisanterie des vacances.

On parle souvent de few-shot prompting lorsqu’on fournit plusieurs démonstrations ; une consigne directe sans démonstration est couramment appelée zero-shot prompting. Il n’existe pas de nombre universellement correct d’exemples. Un seul peut clarifier un style ; plusieurs exemples variés peuvent préciser une règle de classification. Vingt exemples presque identiques risquent seulement de rallonger le trajet de votre prompt.

Demandez quelque chose de vérifiable

Les recherches sur le chain-of-thought prompting ont montré que des démonstrations de raisonnement détaillées amélioraient les résultats pour certaines tâches et certains modèles. C’est un résultat utile, pas la preuve qu’ajouter « réfléchis étape par étape » rend toujours une réponse correcte.

En pratique, demandez une explication concise, les hypothèses et des calculs vérifiables. Si un modèle propose un budget de voyage, demandez les montants individuels et leur total. Vérifiez l’arithmétique séparément. Une explication convaincante peut tout de même défendre un nombre faux.

Pour une mission compliquée, séparez les parties lorsque cela facilite la révision. Pour un article, vous pouvez d’abord vérifier le plan fondé sur les sources, puis demander un brouillon et enfin examiner les affirmations factuelles. Combiner les tâches n’est pas mauvais en soi ; perdre de vue si l’une d’elles a réussi est le problème.

Si un logiciel exige une structure de données précise, une simple instruction « renvoie du JSON » ne devrait pas constituer tout le plan de fiabilité. Les API peuvent proposer des sorties structurées fondées sur un schéma, comme l’illustre l’annonce de Google de 2025 sur l’API Gemini. Vérifiez les valeurs elles-mêmes autant que leur structure : un prix faux parfaitement formaté reste un prix faux.

Donnez au modèle des éléments probants, pas des encouragements à improviser

Quand la tâche dépend d’un document, fournissez-le et identifiez le passage pertinent. Demandez au modèle de distinguer ce que le document dit de ce qu’il déduit, et de signaler les informations manquantes. Examinez ensuite vous-même les passages cités. Demander des sources ne rend pas impossibles les sources inventées.

Les applications peuvent aussi récupérer automatiquement des documents ; c’est le principe de la génération augmentée par récupération (en anglais). La récupération et les prompts traitent des parties différentes du travail. Les instructions indiquent quoi faire des éléments disponibles ; la récupération aide à les mettre à portée.

Choisissez soigneusement ce que vous téléversez. Pour modifier le ton, un texte anonymisé peut suffire. L’adresse d’un client ou une clé d’accès sont généralement un contexte inutile pour décider si une phrase paraît joyeuse.

Améliorez le prompt en testant le résultat

Conservez quelques entrées réalistes et définissez la réussite avant d’ajuster la formulation. Pour l’exemple du mug, vérifiez si les descriptions conservent les caractéristiques, évitent les fonctionnalités inventées et conviennent au public visé. Essayez aussi des caractéristiques incomplètes. Modifiez une consigne importante, comparez les résultats et gardez la version qui réussit mieux sur l’ensemble des exemples.

C’est différent du fine-tuning. Le guide d’entraînement de Hugging Face décrit le fine-tuning comme un entraînement supplémentaire d’un modèle préentraîné sur des données propres à une tâche. Modifier un prompt change l’entrée d’une requête ; ce n’est pas ce processus d’entraînement.

Vous n’avez pas besoin de devenir un professionnel qui murmure des mots-clés magiques. Donnez au modèle un brief clair, des documents utiles et un résultat que vous pouvez juger. Et si la réponse ressemble toujours à une brochure d’aéroport, dites-lui précisément quelles phrases lui ont valu cette distinction.

Traduction française de l’article original en anglais du 2026-05-29. Traduction réalisée avec l’aide de l’IA le 1 novembre 2026 ; les références temporelles restent celles de l’original.