Prompt engineering : le guide complet (techniques avancées)

Le prompt engineering consiste à structurer l’entrée d’un modèle de langage pour rendre sa sortie fiable, contrainte et reproductible. Ce n’est ni un ensemble de formules magiques, ni du « piratage » de modèle : c’est de la spécification. On y fait le même travail qu’un chef de projet qui rédige un cahier des charges.

Le point important, souvent mal compris : le prompt engineering ne change pas ce que le modèle sait. Il ne lui apprend rien de nouveau, il n’étend pas ses connaissances, il ne corrige pas ses lacunes factuelles. Il oriente la manière dont il mobilise ce qu’il a déjà. Un prompt parfait ne fera pas connaître à un modèle un événement postérieur à son entraînement, et n’éliminera jamais totalement le risque d’hallucination.

Ce qu’il fait, en revanche, est considérable : il fait passer un taux de réussite d’environ 40 % à 90 % sur une tâche donnée, ce qui est exactement la différence entre « amusant » et « utilisable en production ».

Le zero-shot prompting consiste à demander une tâche sans fournir le moindre exemple de la sortie attendue. C’est le mode par défaut, celui que tout le monde utilise sans le nommer.

Exemple : « Classe cet avis client dans l’une de ces catégories : positif, négatif, mitigé. Réponds par le seul mot de la catégorie. Avis : [texte]. »

Le zero-shot fonctionne bien quand la tâche est courante et bien définie : traduction, résumé, classification simple, correction orthographique. Les modèles récents ont été entraînés à suivre des instructions (« instruction tuning »), ce qui rend le zero-shot beaucoup plus performant qu’aux débuts des LLM.

Il montre ses limites dès que la tâche exige un format inhabituel, un style particulier, ou des critères de jugement subjectifs. C’est là qu’intervient le few-shot.

Le few-shot prompting consiste à insérer dans le prompt quelques paires entrée → sortie montrant exactement ce que vous attendez. Le modèle infère le motif et l’applique au nouveau cas. On parle parfois d’« apprentissage en contexte » (*in-context learning*) : rien n’est réellement appris au sens des poids du modèle, qui ne sont pas modifiés — le motif n’existe que le temps de la requête.

Exemple sur une tâche de classification fine : « Classe chaque ticket support selon l’urgence. Ticket : “Je n’arrive plus à me connecter depuis ce matin, j’ai une démo client à 14h.” → Urgence : haute. Ticket : “Petite faute d’orthographe sur la page tarifs.” → Urgence : basse. Ticket : “L’export CSV met 3 minutes au lieu de 5 secondes depuis la mise à jour.” → Urgence : moyenne. Ticket : [nouveau ticket] → Urgence : »

Trois règles d’usage tirées de la pratique :

• Le format des exemples est plus déterminant que leur contenu. Le modèle imite la forme avant le fond : gardez une structure rigoureusement identique d’un exemple à l’autre.
• Couvrez les cas limites. Si tous vos exemples sont des cas faciles, le modèle traitera les cas ambigus comme des cas faciles. Incluez délibérément un cas difficile.
• Deux à cinq exemples suffisent. Au-delà, le gain devient marginal, alors que la consommation de contexte, elle, continue de croître.

Le chain-of-thought (CoT, ou « chaîne de pensée ») consiste à demander au modèle de dérouler son raisonnement avant de donner sa réponse. Comme un LLM génère token par token, chaque étape intermédiaire qu’il écrit devient un appui pour la suivante : il « pense » littéralement en écrivant.

La formulation minimale est célèbre pour sa simplicité : « Réfléchis étape par étape avant de répondre. » Une version plus opérante impose la structure : « Procède ainsi : (1) liste les données du problème ; (2) identifie ce qui est demandé ; (3) pose le calcul ou le raisonnement ; (4) donne la réponse finale, précédée de “Réponse :”. »

Quand l’employer : problèmes arithmétiques, raisonnements logiques ou juridiques à plusieurs conditions, comparaisons multicritères, débogage. Ce sont les tâches où l’erreur vient d’un saut d’étape, pas d’un manque de connaissance.

Quand l’éviter : les tâches de style ou de création, où l’explicitation du raisonnement n’apporte rien et alourdit la sortie. Et sachez que les modèles dits « de raisonnement » (o-series d’OpenAI, modes de réflexion étendue) exécutent déjà une chaîne de pensée en interne : leur demander explicitement de « réfléchir étape par étape » est en général redondant.

Une mise en garde importante : le raisonnement affiché n’est pas nécessairement le raisonnement réellement suivi. Un modèle peut produire une chaîne d’étapes plausible menant à une conclusion fausse. Le CoT améliore la fiabilité ; il ne fournit pas une preuve.

Le role prompting attribue au modèle une identité professionnelle stable. Techniquement, il s’agit de conditionner la génération : en écrivant « tu es un radiologue », vous rendez plus probable le vocabulaire, la prudence et les réflexes propres à un compte-rendu de radiologie.

Dans les API, ce rôle se place dans le message système, distinct des messages utilisateur. C’est un emplacement privilégié : les instructions qui s’y trouvent persistent sur toute la conversation et sont, en pratique, mieux respectées que les mêmes instructions répétées dans chaque message. Les interfaces grand public exposent l’équivalent sous les noms « instructions personnalisées » ou « instructions de projet ».

Ce qu’il faut y mettre : le rôle, les règles de style durables, les interdits permanents, le format par défaut. Ce qu’il ne faut pas y mettre : la tâche du moment, qui appartient au message utilisateur.

Deux limites à connaître. D’abord, un rôle n’ajoute aucune compétence : « tu es médecin » ne rend pas le modèle plus exact médicalement, il rend seulement sa réponse plus médicale d’apparence — nuance dangereuse dans les domaines à enjeu. Ensuite, le rôle est plus efficace quand il est fonctionnel (« relecteur chargé de traquer les incohérences factuelles ») que quand il est honorifique (« expert mondial de renom »).

Dès que la sortie est destinée à être traitée — par un humain pressé ou par un programme — le format doit être imposé, pas suggéré.

• Structure explicite : « Réponds uniquement avec un objet JSON valide comportant exactement les clés suivantes : titre (string), score (entier de 1 à 5), justification (string de 30 mots maximum). Aucun texte avant ou après l’objet JSON, aucun bloc de code Markdown. »
• Longueur chiffrée : « exactement 3 phrases », « 80 mots maximum ». Les modèles comptent mal les mots ; considérez ces chiffres comme des cibles fortes, pas comme des garanties, et vérifiez si la précision est critique.
• Interdictions positives : « pas d’introduction, pas de conclusion, pas de reformulation de ma demande, pas d’avertissement sur les limites de l’IA ». Ces quatre clauses éliminent l’essentiel du remplissage.

Sur les API, plusieurs fournisseurs proposent une sortie structurée garantie (JSON schema, mode outil) : la contrainte est appliquée au niveau du décodage, ce qui est bien plus fiable qu’une consigne en langue naturelle. Utilisez-la dès qu’elle est disponible : un prompt ne garantit rien, un schéma si.

Ces paramètres ne s’écrivent pas dans le prompt : ils se règlent dans l’API ou, parfois, dans les options avancées de l’interface. Les comprendre évite d’essayer de compenser par le texte ce qui relève du réglage.

• Température — contrôle le degré d’aléa dans le choix du token suivant. Une température basse (0 à 0,3) rend la sortie plus déterministe et plus répétable : c’est ce qu’il faut pour la classification, l’extraction de données, le code, tout ce qui doit être reproductible. Une température plus haute (0,7 à 1) élargit l’éventail des choix et produit des formulations plus variées : utile en brainstorming ou en écriture créative. Attention au contresens répandu : une température élevée ne rend pas le modèle « plus intelligent » ou « plus créatif » au sens des idées — elle le rend simplement moins prévisible, et donc plus susceptible de dériver.
• Top-p (nucleus sampling) — restreint le choix aux tokens les plus probables jusqu’à atteindre une masse de probabilité cumulée p. C’est un second levier d’aléa. En pratique, on ajuste soit la température, soit le top-p, rarement les deux à la fois.
• Verbosité et longueur — la longueur maximale de sortie (*max tokens*) est une coupure brutale : elle tronque, elle ne résume pas. Pour obtenir une réponse courte, il faut le demander dans le prompt ; le paramètre de longueur maximale ne sert qu’à borner le coût et éviter les débordements.
• Fenêtre de contexte — la quantité totale de texte (prompt + conversation + réponse) que le modèle peut traiter en une fois. Quand elle est saturée, les éléments les plus anciens de la conversation cessent d’être pris en compte. C’est la cause la plus fréquente du modèle qui « oublie » une consigne donnée trente messages plus tôt : la solution est de répéter la consigne critique, ou de la placer dans le message système.

Au-delà des techniques élémentaires, l’essentiel du gain vient de la manière dont on enchaîne les prompts.

• Décomposition (prompt chaining) — découpez une mission complexe en étapes, chacune avec son propre prompt, la sortie de l’une devenant l’entrée de la suivante. Rédiger un article : (1) plan détaillé ; (2) rédaction section par section ; (3) relecture critique ; (4) titres et méta. Chaque étape est vérifiable, et une erreur ne se propage pas silencieusement.
• Auto-critique (self-refine) — après une première sortie, demandez explicitement : « Relis ta réponse et liste ses 3 principales faiblesses au regard des consignes. Puis produis une version corrigée. » Ce second passage est souvent celui qui apporte le plus de valeur, pour un coût minime.
• Modèle-juge — pour évaluer plusieurs variantes, demandez au modèle de les noter selon des critères que vous définissez explicitement (« clarté /5, exactitude factuelle /5, respect du format /5 »), puis de justifier. Sans critères explicites, il notera au feeling — et complimentera généreusement.
• Délimitation du contexte — quand vous collez des données, entourez-les de balises claires (<document>…</document>) et référez-vous-y explicitement. Cela réduit fortement le risque que le modèle confonde vos données avec vos instructions — un problème qui devient une véritable faille de sécurité (*prompt injection*) dès que le texte collé provient d’une source extérieure non fiable.

Le prompt engineering sérieux ressemble beaucoup plus au développement logiciel qu’à l’écriture. Le cycle est le même : on écrit, on teste, on mesure, on corrige, on versionne.

Concrètement, dès qu’un prompt est destiné à être réutilisé : constituez un jeu de test d’une dizaine d’entrées représentatives, incluant les cas limites ; définissez ce que « réussi » signifie (format respecté, aucune donnée inventée, longueur tenue) ; faites tourner le prompt sur ce jeu à chaque modification. Sans cela, vous « améliorez » à l’aveugle et régressez sans le voir.

Enfin, versionnez et archivez vos prompts. Un prompt qui fonctionne est un actif : il a coûté des essais, il représente une méthode. Le perdre dans un historique de conversation, c’est recommencer à zéro le mois suivant. C’est précisément la fonction d’une bibliothèque de prompts : conserver, classer et rendre réutilisable ce travail — Amiral IA le fait pour les cas d’usage professionnels courants, avec des gabarits déjà testés et paramétrés.