Le prompting — principes fondamentaux

En bref

Parler à un LLM, ce n’est pas comme faire une recherche Google. Google tolère l’approximation — il infère ce que vous voulez dire. Un LLM, lui, prend votre formulation au pied de la lettre. Si vous êtes vague, il vous répond de manière vague. Si vous êtes précis, il peut l’être aussi.

Le prompting, c’est l’art de formuler des instructions claires pour obtenir des réponses utiles. Ce n’est pas de la manipulation, ni une compétence mystérieuse réservée aux experts. C’est de la communication précise avec un outil qui en a besoin.

Imagine un nouveau stagiaire qui débarque le matin. Il a lu cinq mille livres mais il ne sait rien de ton équipe, de ton client, ou de ce que tu fais cet après-midi. Si tu lui dis « écris-moi quelque chose », il écrit quelque chose. Si tu lui dis « rédige une note de cadrage de 300 mots pour le client X, ton conciliant, focus sur les risques juridiques », il livre quelque chose d’utile dès le premier essai. Le prompting, c’est cette discipline du briefing.

Explication

Ce qu’est un prompt

Un prompt, c’est tout ce que vous envoyez au modèle avant qu’il génère une réponse : une question, une instruction, un document à analyser, un rôle à jouer, des exemples à suivre. Le modèle ne voit que ça. Il n’a pas accès à votre intention, à votre contexte professionnel, à vos attentes implicites.

Cette contrainte est fondamentale : tout ce que vous ne dites pas, le modèle l’invente ou l’ignore.

Clarté et spécificité

Le premier principe est aussi le plus simple. Une question vague produit une réponse vague.

Comparez ces deux formulations :

• “Explique le code.” → Le modèle peut paraphraser, résumer, analyser la structure, ou tout à la fois.
• “Explique ce que fait cette fonction Python, ligne par ligne, en supposant un lecteur qui n’a jamais programmé.” → La réponse est contrainte dès le départ.

La spécificité réduit l’espace des réponses possibles. Elle force le modèle à aller là où vous voulez.

Contexte explicite

Un LLM n’a pas de mémoire entre les sessions. Il ne sait pas qui vous êtes, dans quel projet vous travaillez, ni pour qui vous écrivez. Tout ce contexte doit être fourni dans le prompt lui-même.

Fournir le rôle attendu, le format de sortie souhaité et les contraintes importantes réduit les allers-retours inutiles et améliore la pertinence des réponses dès la première tentative.

Délimiteurs

Quand un prompt mélange des instructions et des données (un texte à analyser, du code à corriger, un document à résumer), le modèle peut confondre les deux. Les délimiteurs — triple guillemets, balises XML, séparateurs explicites — indiquent clairement où s’arrêtent les instructions et où commencent les données.

Résume le texte suivant en 3 points :

"""
[texte à résumer]
"""

Ce principe devient critique dans les applications automatisées où le prompt est construit programmatiquement.

Messages système

La plupart des API LLM distinguent le system prompt (instructions globales, définies avant la conversation) du message utilisateur (la demande ponctuelle). Le system prompt est le lieu où définir le comportement général : registre, langue, format, rôle, contraintes permanentes. Le message utilisateur est la demande du moment.

Cette séparation permet de ne pas répéter les instructions de base à chaque tour de conversation.

Itération

Le premier prompt est rarement optimal. Le prompting est un processus empirique : tester, observer les limites de la réponse, ajuster une variable à la fois. Ce n’est pas différent de l’écriture — le premier jet sert à voir ce qui manque.

En clair : six règles pratiques résument tout — sois précis, donne le contexte, sépare instructions et données par des délimiteurs, utilise le system prompt pour les règles permanentes, varie un paramètre à la fois pendant l’itération. Tout le reste découle de là.

Exemples concrets

Zero-shot : poser la question directement

Le zero-shot consiste à envoyer la question sans aucun exemple préalable. Le modèle s’appuie uniquement sur ce qu’il a appris pendant l’entraînement.

Classe cet avis client comme positif, négatif ou neutre :

"La livraison était rapide mais l'emballage était abîmé."

Efficace pour les tâches courantes et bien définies. Insuffisant pour les formats de sortie non standards ou les tâches inhabituelles.

Few-shot : montrer avant de demander

Le few-shot fournit deux à cinq exemples input/output avant la question réelle. Le modèle infère le pattern et l’applique à la nouvelle entrée. Plus robuste que le zero-shot pour les formats spécifiques ou les tâches où la définition de “bonne réponse” est difficile à formuler en mots.

Entrée : "La livraison était rapide."
Sortie : POSITIF

Entrée : "Le produit est cassé à l'arrivée."
Sortie : NÉGATIF

Entrée : "La livraison était rapide mais l'emballage était abîmé."
Sortie :

Le modèle complète naturellement selon le pattern établi.

Chain-of-thought : raisonner avant de répondre

Le chain-of-thought (CoT) consiste à demander au modèle d’énoncer ses étapes de raisonnement avant de donner la réponse finale. Cette technique améliore significativement les performances sur les tâches de raisonnement multi-étapes — mathématiques, logique, analyse structurée.

La version zero-shot est simple : ajouter “Réfléchis étape par étape” à la fin du prompt suffit souvent à déclencher le comportement.

Un train part à 14h et arrive à 17h30. Il s'arrête 20 minutes en cours de route.
Quelle est la durée réelle du trajet sans les arrêts ?
Réfléchis étape par étape.

Pourquoi ça fonctionne : en forçant le modèle à externaliser son raisonnement, on réduit les erreurs de “saut” — les conclusions prématurées tirées sans vérifier les étapes intermédiaires.

Role prompting : ancrer l’expertise

Assigner un rôle au modèle change le registre et la profondeur des réponses. Ce n’est pas un tour de passe-passe — cela exploite le fait que le modèle a été entraîné sur des textes produits par des experts dans des contextes précis.

Tu es un expert en sécurité réseau avec 15 ans d'expérience en entreprise.
Un développeur junior te demande pourquoi son application expose le port 22 en production.
Explique le problème et les risques, sans jargon inutile.

Le rôle contraint le niveau d’abstraction, le vocabulaire et l’angle d’approche. Il est particulièrement utile quand la même information doit être présentée différemment selon l’audience.

En clair : une bonne hygiène mentale = chaque problème = une technique principale, pas un empilement. Si tu sens que tu accumules zero-shot + few-shot + CoT + rôle dans un même prompt, c’est souvent que la tâche mérite d’être découpée en deux.

Ce qu’il faut retenir

• La précision est la compétence centrale. Tout ce que vous ne spécifiez pas, le modèle l’interprète selon ses propres paramètres par défaut. Spécifier le rôle, le format, le niveau d’expertise visé et les contraintes importantes réduit la part d’interprétation laissée au modèle.
• Le few-shot surpasse le zero-shot dès que le format de sortie est non trivial. Décrire un format en mots est souvent moins efficace que de montrer deux exemples. Le modèle est entraîné à compléter des patterns — l’exploiter est plus fiable que de rédiger une spécification textuelle.
• Le chain-of-thought est le levier le plus puissant pour le raisonnement. Sur les tâches multi-étapes, demander au modèle de raisonner à voix haute avant de conclure améliore la précision de manière mesurable. C’est une instruction, pas une incantation.
• Le prompting est empirique, pas magique. Il n’existe pas de formule universelle. Un bon prompt pour une tâche ne transfère pas nécessairement à une autre. L’itération est la méthode — une variable à la fois.