Prompts IA : cinq méthodes pour obtenir des réponses plus précises et utiles

Les assistants comme Gemini, ChatGPT ou Claude donnent parfois l’impression de comprendre une demande au premier essai. Pourtant, la qualité de leur réponse dépend moins d’une formule magique que des informations, des contraintes et du cadre fournis. Le « prompting », c’est-à-dire l’art de formuler une instruction à un modèle de langage, devient donc une compétence pratique pour rédiger, classer, résumer, analyser ou extraire des données.

Un modèle de langage ne lit pas une intention comme le ferait un collègue : il produit sa réponse token par token, en estimant quelles suites de mots sont plausibles au regard de la consigne et du contexte. Un prompt imprécis laisse au modèle une grande marge d’interprétation. À l’inverse, une demande qui définit le résultat attendu, le public visé, les limites et des exemples réduit les ambiguïtés.

Voici cinq méthodes complémentaires. Certaines concernent les réglages disponibles dans les interfaces de programmation, ou API, plutôt que les simples interfaces conversationnelles. Toutes reposent sur la même idée : ne pas confondre une réponse fluide avec une réponse juste, et évaluer le résultat en fonction de l’usage réel.

1. Régler les variables d’inférence selon la tâche

Avant même de modifier le texte d’un prompt, il faut savoir que les modèles peuvent proposer des réglages qui modifient leur manière de générer une réponse. Ces paramètres sont surtout visibles dans les API et les outils avancés. Ils ne rendent pas un modèle plus compétent, mais influencent ses choix parmi les suites de mots possibles.

Les trois variables citées le plus souvent sont la longueur maximale de sortie, la température et les mécanismes de sélection appelés top-K et top-P. Leur intérêt dépend du cas d’usage : on ne règle pas un classement automatique comme une séance de recherche d’idées.

La valeur max tokens fixe un plafond, pas une longueur garantie. Pour une tâche de classification, par exemple associer un avis client à une catégorie, une limite de moins de 10 tokens peut suffire. Elle évite que le modèle ne transforme une sortie attendue sous forme d’étiquette, comme « livraison », en paragraphe de justification. Pour une note de synthèse, cette même limite serait au contraire insuffisante.

La température joue sur le caractère plus ou moins déterministe de la réponse. Lorsqu’elle est proche de 0, le modèle tend à privilégier les suites les plus probables et fournit plus facilement des résultats stables d’un essai à l’autre. Une température plus élevée favorise la variété, ce qui peut être utile pour des slogans, des angles éditoriaux ou des idées de scénario. En contrepartie, elle peut accroître le risque d’« hallucination », c’est-à-dire d’information inventée ou erronée présentée avec assurance.

Enfin, top-K limite la sélection aux K mots ou tokens les plus probables. Top-P, aussi appelé échantillonnage par noyau, retient les candidats jusqu’à un seuil de probabilité cumulée. Ces deux réglages sont plus techniques. Pour la plupart des utilisateurs, le plus efficace consiste d’abord à préciser la tâche et le format de sortie, puis à ne changer qu’un paramètre à la fois.

2. Montrer le résultat attendu avec le few-shot prompting

Le few-shot prompting consiste à inclure dans la consigne un ou plusieurs exemples de ce que l’on attend. C’est une solution légère pour guider le modèle sans entraîner une version spécialisée de celui-ci, comme le ferait le fine-tuning. Elle est particulièrement utile lorsqu’un résultat doit respecter un format strict, une nomenclature précise ou un ton éditorial identifiable.

Un seul exemple peut donner un cap. Dans de nombreux cas, 3 à 5 exemples représentatifs permettent toutefois au modèle de mieux saisir la règle implicite. Ils doivent couvrir les cas réellement rencontrés, être cohérents entre eux et ne contenir aucune faute dans le format attendu. Le modèle peut en effet reproduire une erreur, une catégorie mal nommée ou une ponctuation incohérente.

Imaginons une demande d’extraction de commande de pizza au format JSON. Au lieu de demander seulement « transforme cette commande en JSON », il est préférable d’indiquer une structure attendue avec plusieurs commandes modèles :

Commande : Je veux une petite pizza avec fromage, sauce tomate et pepperoni.
Sortie : {"taille":"petite","ingredients":["fromage","sauce tomate","pepperoni"]}

Commande : Une grande pizza végétarienne, sans olives.
Sortie : {"taille":"grande","ingredients":["végétarienne"],"exclusions":["olives"]}

Commande : [nouvelle commande à traiter]
Sortie :

L’exemple ne sert pas seulement à montrer que le JSON est requis. Il indique les noms de champs, la manière de traiter une exclusion et le niveau de détail attendu. Cette précision limite les réponses difficilement exploitables par un tableur, un logiciel ou une automatisation.

Le few-shot prompting fonctionne aussi pour les tâches de rédaction. Pour demander trois accroches dans un ton donné, il vaut mieux fournir quelques exemples courts validés que se contenter d’adjectifs généraux tels que « dynamique » ou « inspirant ». Les exemples doivent cependant rester brefs : ils occupent une partie du contexte disponible et peuvent rendre le prompt plus coûteux.

3. Prendre du recul avant de résoudre avec le step-back prompting

Certaines demandes sont trop complexes pour être posées de manière brute. Le step-back prompting propose de les aborder en deux temps : demander d’abord quelle méthode, quels principes ou quelles informations sont nécessaires, puis demander l’application de cette méthode au cas concret.

Plutôt que d’écrire immédiatement « résous ce problème », une première instruction peut être : « Identifie les principes et les étapes nécessaires pour résoudre le problème suivant. » Une fois cette réponse obtenue, une seconde demande invite le modèle à appliquer le cadre établi.

Cette technique est utile pour les problèmes mathématiques, la planification, l’analyse de documents ou toute tâche où il faut distinguer les faits, les hypothèses et la méthode. Elle pousse le modèle à mobiliser des notions plus générales avant de se précipiter vers une réponse particulière.

Un exemple de séquence peut être formulé ainsi :

1. « Quelle approche faut-il mobiliser pour traiter ce problème, et quelles données doivent être vérifiées ? »
2. « Applique maintenant cette approche au problème ci-dessous. Indique les calculs et signale clairement toute hypothèse. »

Cette étape de recul facilite aussi le contrôle humain. Le lecteur peut examiner la méthode proposée avant de lui faire confiance. Elle n’équivaut pas à une démonstration infaillible : dans un domaine juridique, médical, financier ou scientifique, les sources et les calculs doivent être contrôlés indépendamment.

4. Comparer plusieurs sorties grâce à la self-consistency

Un modèle peut produire des réponses différentes à une même question, surtout lorsque la température est relevée. La méthode de self-consistency, ou cohérence par répétition, exploite cette variabilité : le même prompt est soumis plusieurs fois, puis les résultats sont comparés. Pour une question dont la réponse est structurée, la sortie qui revient le plus souvent peut être retenue selon un principe de vote majoritaire.

Prenons le classement d’une transcription téléphonique en trois catégories : demande commerciale, réclamation ou question technique. Il est possible de lancer le même prompt trois fois, avec une température choisie pour introduire une légère diversité, puis de conserver la catégorie majoritaire. Si deux sorties indiquent « réclamation » et une « question technique », « réclamation » est retenue.

Cette méthode est adaptée aux tâches où les réponses peuvent être normalisées : choix parmi une liste fermée, extraction d’un champ, calcul dont le résultat est vérifiable, évaluation selon une grille. Elle est moins convaincante pour une question ouverte ou subjective. Trois formulations semblables ne constituent pas, à elles seules, trois preuves indépendantes.

La self-consistency peut réduire l’effet d’une réponse aberrante isolée, mais ne supprime pas les hallucinations. Si le prompt manque d’informations, ou si le modèle partage la même erreur dans tous les essais, le vote majoritaire confirmera simplement une erreur majoritaire. Il faut donc prévoir une option « incertain » et une revue humaine pour les cas sensibles.

5. Passer de l’intuition au test avec l’automatic prompt engineering

L’automatic prompt engineering, souvent abrégé en APE, vise à automatiser l’amélioration des consignes. Le principe est simple : partir d’un prompt de référence, demander au modèle d’en générer plusieurs variantes, puis les tester sur un ensemble de cas connus. La meilleure formulation n’est plus celle qui « semble » efficace, mais celle qui obtient les meilleurs résultats selon un critère défini à l’avance.

Cette approche suppose de disposer de réponses de référence, idéalement rédigées ou validées par des humains. Chaque variante est envoyée sur les mêmes exemples, puis ses sorties sont comparées aux références. Les métriques BLEU et ROUGE peuvent mesurer la proximité textuelle entre deux formulations. Elles sont utiles pour certaines tâches de génération ou de résumé, mais elles ne suffisent pas à juger seules la qualité : deux réponses correctes peuvent employer des mots différents, tandis qu’une réponse très proche peut contenir une erreur importante.

Pour un classement, il est plus pertinent de mesurer le taux de catégories correctes. Pour une extraction de données, on vérifiera les champs exacts, les données manquantes et le respect du format. Pour un texte destiné au public, une grille humaine peut évaluer l’exactitude, la clarté, le ton et l’absence d’affirmations non étayées.

Organiser les essais dans un tableur

L’amélioration d’un prompt devient beaucoup plus fiable lorsqu’elle laisse une trace. Un simple tableur permet de comparer les formulations et de repérer les régressions : un prompt peut devenir meilleur sur les cas faciles tout en échouant davantage sur les cas rares.

Les colonnes les plus utiles sont les suivantes :

• le nom et la version du prompt ;
• l’objectif précis de la tâche ;
• les paramètres utilisés, comme la température et la limite de tokens ;
• le jeu de cas testé ;
• la sortie du modèle ;
• l’évaluation obtenue et les erreurs observées ;
• la décision prise, par exemple conserver, modifier ou écarter le prompt.

Ce suivi est particulièrement important lorsque les prompts servent à automatiser un processus. Il permet d’isoler l’effet d’un changement : nouvelle instruction, exemple supplémentaire, format différent ou réglage modifié. Tester plusieurs modifications simultanément rend presque impossible l’identification de ce qui a réellement amélioré le résultat.

Il faut également veiller aux données utilisées durant ces essais. Une transcription d’appel, un dossier client ou un document interne peuvent contenir des informations confidentielles. Avant de les transmettre à un service d’IA, une organisation doit connaître les règles applicables, anonymiser ce qui peut l’être et vérifier les options de conservation des données du service choisi.

Ce qu’il faut surveiller pour des prompts vraiment utiles

Les cinq méthodes ne se substituent pas les unes aux autres. Le réglage des paramètres encadre la génération, les exemples clarifient la sortie, le step-back prompting structure l’approche, la self-consistency met plusieurs réponses en concurrence et l’APE installe une démarche de mesure. Leur combinaison doit rester proportionnée à l’enjeu : un courriel informel ne justifie pas le même protocole qu’un outil qui traite des milliers de demandes clients.

Le premier réflexe reste de définir ce qu’est une bonne réponse avant de rédiger le prompt. Est-ce une réponse factuelle, courte, classée dans une catégorie, conforme à un format ou créative ? Qui doit la relire ? Quelle erreur serait inacceptable ? Ces questions déterminent les exemples, les paramètres et la méthode de test plus sûrement qu’une accumulation de mots-clés.

Enfin, un prompt performant n’est jamais définitivement acquis. Les modèles, les interfaces et les besoins évoluent. Conserver un jeu de test représentatif, surveiller les erreurs et réévaluer régulièrement les consignes permet de transformer une interaction ponctuelle avec l’IA en outil fiable, sans lui déléguer le jugement final.