Les bases du prompting

#Comment interroger un LLM : trois façons, une règle

Un modèle de langage continue un texte. Ce qu'il produit dépend donc presque entièrement de ce que vous lui donnez. La documentation d'Anthropic formule une règle d'or utile pour n'importe quel modèle : montrez votre prompt à un collègue qui ne connaît pas la tâche et demandez-lui de l'exécuter ; s'il est perdu, le modèle le sera aussi. Elle recommande de demander explicitement ce que l'on veut, y compris le niveau d'effort, plutôt que d'attendre du modèle qu'il le déduise d'une consigne vague. Cette règle vaut autant pour un modèle de 8 milliards de paramètres sur votre poste que pour un modèle de pointe. Les paramètres, la quantification ou le modèle choisi comptent, mais un prompt flou gâche tout modèle.

#Trois façons d'envoyer une question à un modèle local

Interface de chat

Open WebUI, LM Studio, Jan : vous tapez, le modèle répond, l'historique est conservé. La voie la plus simple pour commencer.

Ligne de commande

ollama run suivi du nom du modèle ouvre une session interactive dans le terminal. Pratique pour des essais rapides.

API

Un programme envoie une requête HTTP au serveur local et reçoit la réponse en JSON. C'est la voie des scripts et des automatisations.

curl http://localhost:11434/api/chat -d '{
  "model": "gpt-oss",
  "messages": [
    {"role": "system", "content": "Tu réponds en français, en trois phrases maximum."},
    {"role": "user", "content": "Explique ce qu'est un token."}
  ],
  "stream": false
}'

Le message de rôle system fixe le cadre permanent, le message de rôle user contient la demande. Le guide sur les system prompts détaille ce que l'on y met. Quelle que soit la voie, la qualité de la réponse dépend de ce que contient le message.

#Anatomie d'un bon prompt : rôle, tâche, contexte, format

Beaucoup de guides retiennent quatre éléments : le rôle, la tâche, le contexte et le format. Ce n'est pas une norme, mais un moyen mnémotechnique qui recoupe les recommandations de la documentation : être précis, donner le contexte, structurer, fixer le format et, au besoin, un rôle. La documentation d'Anthropic note qu'un rôle d'une seule phrase dans le message système oriente déjà le ton et le comportement.

Rôle

Une phrase qui situe le modèle : « Tu es un correcteur de français rigoureux ». Il règle le registre, pas l'intelligence.

Tâche

Le verbe d'action, aussi précis que possible : « Résume en cinq puces factuelles, sans adjectifs » vaut mieux que « Résume ».

Contexte

Les données à traiter et la raison de la demande. Expliquer le pourquoi d'une contrainte aide le modèle à la généraliser correctement.

Format

Longueur, structure, langue, ton. Sans ces précisions, le modèle choisit lui-même.

Tu es un assistant juridique qui explique en français simple.

Tâche : résume le contrat ci-dessous en 5 points, du plus risqué
au moins risqué pour le signataire.

<contrat>
[le texte du contrat ici]
</contrat>

Format : liste à puces, une phrase par puce, 20 mots maximum.

Les balises qui encadrent le contrat dans l'exemple ci-dessus ne sont pas décoratives : la documentation indique que les balises XML aident le modèle à distinguer sans ambiguïté les instructions, le contexte, les exemples et les entrées variables. Choisissez des noms cohérents et descriptifs, et utilisez le même délimiteur d'un prompt à l'autre.

#Les erreurs qui font perdre le plus de temps

Sur l'avant-dernière ligne, la documentation d'Anthropic recommande de dire au modèle ce qu'il doit faire plutôt que ce qu'il ne doit pas faire, et donne l'exemple de remplacer « n'utilise pas de Markdown » par une description de la forme souhaitée, des paragraphes de prose fluide. Sur la dernière, elle recommande de donner la raison d'une consigne : le modèle en tire une règle générale plutôt qu'une interdiction littérale.

#Les techniques qui marchent sur presque tous les modèles

#Donner des exemples

Les exemples sont, selon la documentation d'Anthropic, l'un des moyens les plus fiables d'orienter le format, le ton et la structure. Trois à cinq exemples donnent en général les meilleurs résultats, à condition qu'ils soient pertinents, variés (y compris les cas limites) et encadrés par des balises pour ne pas être pris pour des instructions. C'est particulièrement efficace pour classer, extraire ou reformater.

#Demander de raisonner

Sur un problème logique, un calcul ou du code, demander au modèle de poser les étapes avant de conclure améliore souvent le résultat, au prix d'une réponse plus longue. Certains modèles locaux le font seuls : la documentation d'Ollama explique que les modèles à raisonnement renvoient un champ thinking séparé de la réponse finale, que vous pouvez lire, afficher ou masquer. Pour les autres, une phrase suffit : « Explique ton raisonnement étape par étape, puis donne la réponse finale ».

#Placer un long document

La documentation d'Anthropic recommande, pour les entrées de plus de 20 000 tokens, de placer les longs documents en haut du prompt, avant la question, et d'écrire la question à la fin : selon ses tests, cela peut améliorer la qualité des réponses jusqu'à 30 %, surtout sur des entrées à plusieurs documents. Ce résultat vient de tests sur les modèles Claude : vérifiez-le sur votre modèle local avec vos propres textes.

#Faire vérifier la réponse

Demandez au modèle de citer, pour chaque affirmation, le passage du texte fourni qui la justifie, ou d'écrire « non vérifié » s'il n'en trouve pas. Cette consigne ne supprime pas les hallucinations, mais elle rend les erreurs repérables. Le guide sur les hallucinations en détaille les limites.

#Un cas concret : de la consigne floue au prompt utilisable

Prenez une demande typique : vous collez un compte rendu de réunion et écrivez « fais un résumé ». Le modèle ignore pour qui est le résumé, combien de lignes vous attendez, s'il faut lister des décisions ou des tâches, et dans quelle langue répondre. Il produit un texte générique de longueur arbitraire, que vous corrigerez à la main.

La dernière ligne est la plus utile avec un modèle local : donner au modèle une issue explicite quand l'information manque réduit les inventions. Chaque ajout ne prend qu'une phrase, et l'ensemble transforme un résultat à retravailler en un résultat exploitable. Refaites l'essai sur trois comptes rendus différents avant de figer votre prompt : un prompt qui ne réussit que sur un exemple est un prompt fragile. Gardez ensuite votre meilleure version dans un fichier texte : réutilisée telle quelle, elle vous fera gagner plus de temps que n'importe quelle astuce de formulation, et elle vous permettra de comparer deux modèles à consigne identique.

#Imposer un format de sortie

Quand la réponse doit être lue par un programme, une simple phrase du type « réponds en JSON » ne suffit pas toujours. Ollama propose des sorties structurées : vous passez un schéma JSON dans le champ format de la requête, et la réponse est contrainte de le respecter. La documentation recommande de fournir aussi le schéma dans le prompt pour ancrer la réponse, de baisser la température (par exemple à 0) pour des résultats plus déterministes, et de définir le schéma avec Pydantic ou Zod pour le réutiliser en validation. Les sorties structurées fonctionnent aussi via l'API compatible OpenAI avec response_format. Elles ne sont pas disponibles pour les modèles cloud d'Ollama.

curl http://localhost:11434/api/chat -d '{
  "model": "gpt-oss",
  "messages": [{"role": "user", "content": "Résume ce contrat : ..."}],
  "stream": false,
  "format": {"type": "object", "properties": {"resume": {"type": "string"}, "risques": {"type": "array", "items": {"type": "string"}}}, "required": ["resume", "risques"]}
}'

#Itérer sans repartir de zéro

Une réponse imparfaite se corrige mieux par une instruction ciblée que par un nouveau prompt. Dites ce qui ne va pas et ce que vous attendez : « refais en trois puces de douze mots maximum », « ton plus direct, sans formules de politesse », « ajoute les trois risques les plus concrets ». Si le résultat se dégrade au fil des tours, c'est souvent que l'historique a rempli la fenêtre de contexte : recommencez avec un résumé.

#Ce qui change avec un modèle local

Consignes plus explicites

Un modèle de petite taille comble moins bien les non-dits. Écrivez tout, y compris ce qui vous semble évident.

Contexte tronqué par défaut

Ollama démarre à environ 4 000 tokens sous 24 Gio de VRAM : un long texte collé peut être coupé. Augmentez la fenêtre avant d'accuser le prompt.

Modèles à raisonnement

Ils réfléchissent avant de répondre : la réponse arrive plus tard et consomme des tokens de réflexion.

Français plus fragile

Les petits modèles font plus de fautes d'accord. Ajoutez une consigne de relecture ou choisissez un modèle plus gros.

Température

Un réglage bas (0 à 0,3) convient à l'extraction et au JSON, un réglage plus haut à la rédaction. Voir le guide sur les paramètres.

#Aide-mémoire avant d'envoyer un prompt

Une phrase, un verbe

La tâche est formulée comme une consigne complète, avec un verbe d'action précis.

Données séparées

Le texte à traiter est encadré par des balises, jamais mélangé aux instructions.

Format écrit

Longueur, structure, langue et ton sont indiqués.

Issue explicite

Le modèle sait quoi répondre quand l'information manque.

Un ou deux exemples

Pour une extraction ou une classification, un exemple vaut dix explications.

Fenêtre vérifiée

Le prompt et la réponse attendue tiennent dans le contexte alloué.

#Pour aller plus loin

• Maîtriser les system prompts
• Température, top-p, top-k : les paramètres
• Comprendre la fenêtre de contexte
• Function calling et sorties JSON avec Ollama
• Hallucinations : comment les limiter
• Votre première conversation locale

• Source : Anthropic, bonnes pratiques de prompt engineering
• Source : Ollama, sorties structurées
• Source : Ollama, modèles à raisonnement
• Source : Ollama, longueur de contexte