Demandes avancées : exemples, rôles, critères et étapes

• Une demande de base qui marche déjà en partie (écrire une demande).
• Cinq à dix cas réels de la tâche, avec la réponse attendue : ils serviront à tester chaque version de la demande (évaluer un outil d'IA).
• Savoir si votre modèle raisonne avant de répondre : plusieurs techniques changent de sens selon la réponse (les modèles qui raisonnent).

1. Écrire les critères avant la demande

   Ce qu'on écrit : trois à cinq critères vérifiables : « une seule catégorie », « la raison cite la demande », « moins de 120 mots ».

   Le conseil : précis, mesurables, utiles : Anthropic les demande avant tout travail sur une demande ; OpenAI ajoute de dire quelles décisions le modèle peut prendre seul, et quand il doit demander.

2. Séparer les parties par des balises

   Ce qu'on écrit : <contexte>, <consignes>, <exemples>, <demande> : chaque partie entre ses balises.

   Le conseil : Anthropic les recommande pour éviter les confusions ; pour de nombreux documents, OpenAI a trouvé le XML efficace et le JSON particulièrement mauvais.

3. Choisir deux ou trois exemples variés

   Ce qu'on écrit : des cas différents, au même format, chacun entre balises <exemple>.

   Le conseil : ils montrent surtout le format et le genre de réponse : des étiquettes tirées au hasard dans les exemples ont à peine changé le résultat ; trop d'exemples font copier, prévient Google. Sur un modèle qui raisonne, essayer d'abord sans, comme le conseille OpenAI.

4. Un rôle pour le ton, s'il le faut

   Ce qu'on écrit : « Vous êtes le responsable administratif d'une PME… » quand le ton ou le point de vue comptent.

   Le conseil : Anthropic et Mistral le conseillent pour le ton et le comportement ; pour la justesse, aucune étude lue ne trouve de gain fiable.

5. Laisser le modèle raisonner

   Ce qu'on écrit : sur un modèle qui raisonne, régler l'effort de réflexion plutôt qu'écrire « réfléchis étape par étape ».

   Le conseil : Anthropic préfère une consigne générale comme « réfléchis soigneusement » à un plan écrit à la main ; ses modèles les plus récents peuvent refuser d'écrire leur raisonnement.

6. Découper la tâche en étapes

   Ce qu'on écrit : une demande pour le brouillon, une pour la relecture, une pour la correction.

   Le conseil : chaque étape se relit : c'est le découpage le plus courant selon Anthropic ; Google propose aussi des chaînes et des demandes en parallèle.

7. Faire relire par une liste de contrôle

   Ce qu'on écrit : les critères de l'étape 1, transformés en questions à répondre par oui ou non.

   Le conseil : une liste oui ou non a fait gagner 7,8 points en raisonnement ; sur Claude Opus 5, Anthropic conseille au contraire de retirer les consignes de vérification héritées, qui font trop vérifier.

8. Alléger

   Ce qu'on écrit : chaque consigne une fois, sans majuscules ni « IMPÉRATIF », et le ton décrit par des choix concrets plutôt que par « chaleureux ».

   Le conseil : OpenAI a gagné 10 à 15 % sur ses tests internes en retirant les consignes et les exemples répétés ; Anthropic note que les consignes criées font trop réagir ses modèles.

Les deux demandes, prêtes à copier. Une PME qui trie les messages de son formulaire ; l'entreprise et les messages sont fabriqués pour l'exemple. La première porte les critères, les balises et trois exemples variés ; la seconde est la liste de contrôle de la relecture, tirée des mêmes critères.

<contexte>
Nous sommes une PME qui vend et entretient des chaudières. Les demandes arrivent par le formulaire du site ; chacune doit partir vers le bon service.
</contexte>

<consignes>
Classe la demande dans une seule catégorie : Dépannage, Entretien, Devis, Facturation, Autre.
Réponds sur deux lignes :
Catégorie : …
Raison : une phrase qui cite les mots de la demande.
Si la demande relève de deux catégories, choisis celle qui demande une intervention, et dis-le dans la raison.
</consignes>

<exemples>
<exemple>
Demande : « Plus d'eau chaude depuis ce matin, la chaudière affiche F28. »
Catégorie : Dépannage
Raison : « plus d'eau chaude » et un code d'erreur signalent une panne.
</exemple>
<exemple>
Demande : « Je ne comprends pas la ligne "forfait déplacement" sur ma dernière facture. »
Catégorie : Facturation
Raison : la question porte sur « ma dernière facture ».
</exemple>
<exemple>
Demande : « Combien coûterait le remplacement de ma vieille chaudière au fioul ? »
Catégorie : Devis
Raison : « combien coûterait » demande un prix avant travaux.
</exemple>
</exemples>

<demande>
[Collez ici la demande du client]
</demande>

Voici une demande de client et la classification proposée.
Réponds par oui ou par non à chaque question :
1. Une seule catégorie est donnée, parmi les cinq ?
2. La raison cite des mots de la demande ?
3. Si deux catégories étaient possibles, celle qui demande une intervention a été choisie ?

[Collez ici la demande et la classification]

• Sur vos cinq à dix cas, la réponse est juste à chaque foissinon, chercher l'étape qui échoue
• Deux envois de la même demande donnent la même réponsesinon, la demande laisse trop de place
• Le format demandé est tenu
• La relecture trouve les erreurs qu'elle doit trouveressayez-la sur une réponse fautive exprès
• La demande n'a pas grossi pour rienchaque consigne une fois

Les mesures : Kojima et al., 2022 ; Meincke et al., Wharton, 2025.

• Garder chaque version de la demande, datée, avec ses résultats sur les cas de test ; revenir à la précédente si la nouvelle fait moins bien.
• Changer une seule chose à la fois : sinon, on ne sait pas ce qui a aidé.
• À chaque nouveau modèle, repasser les cas : ce qui aidait peut gêner, comme les consignes de vérification sur Claude Opus 5 ; Mistral prévient qu'une simple mise à jour peut changer la réponse.

D'après les guides des éditeurs, lus le 9 octobre 2026 ; ils sont en anglais, leurs conseils sont traduits. Les guides se contredisent sur les exemples et sur la place de la question : chacun vaut pour ses modèles.