Le prompting : bien briefer un modèle

Deux mots proches désignent deux choses différentes. Le prompt est un texte : celui que le modèle reçoit, avec vos instructions, le contexte, des exemples et la demande elle-même. Le prompting est une pratique : écrire ce texte et, plus largement, choisir tout ce que le modèle lit avant de répondre. Un résultat décevant vient rarement d'une formule magique oubliée. Il vient presque toujours d'une information qu'un collègue aurait eue et que le modèle n'avait pas.

Du prompt à l'ingénierie du contexte

Un LLM (grand modèle de langage) ne sait de votre tâche que ce qui se trouve dans sa fenêtre de contexte au moment de la requête. Ce texte ne vient pas seulement de vous. L'éditeur de l'outil y place ses propres instructions. Votre organisation peut y ajouter les siennes. Viennent ensuite un document ou le résultat d'une recherche, puis votre message. Bien écrire sa demande reste utile. Mais le travail s'est élargi : décider de ce qui entre dans la fenêtre, de ce qui sera cherché au moment voulu et de ce qui en sort. Les équipes techniques appellent ce travail l'ingénierie du contexte (context engineering). En septembre 2025, un article d'ingénierie d'Anthropic la résumait ainsi : trouver le plus petit ensemble d'informations utiles qui rend le bon résultat le plus probable.

Des principes qui durent

Les modèles se succèdent en quelques mois, et chaque éditeur publie des conseils propres à ses modèles. Les principes ci-dessous, eux, se retrouvent en octobre 2026 dans les guides officiels de plusieurs éditeurs.

Être clair et direct

Anthropic propose de voir le modèle comme un nouvel employé brillant, à qui il manque le contexte de vos habitudes. Son test : montrez votre prompt à un collègue qui ne connaît pas la tâche. S'il est perdu, le modèle le sera aussi. Mistral conseille d'écrire pour quelqu'un qui n'a aucun contexte préalable. OpenAI compare le modèle à un collègue débutant, qui travaille mieux avec des consignes explicites. Google demande des instructions « claires et précises ». Dites ce que vous voulez obtenir, pour qui, sous quelle forme et avec quelles contraintes.

Dire pourquoi

Une consigne accompagnée de sa raison s'applique mieux, et le modèle peut l'étendre aux cas que vous n'aviez pas prévus. Anthropic donne cet exemple : « n'utilise jamais de points de suspension » fonctionne moins bien que « ta réponse sera lue par une synthèse vocale, qui ne sait pas prononcer les points de suspension ». Google écrit que le contexte aide le modèle à comprendre les contraintes de la demande. Microsoft fait du contexte l'une des quatre parties d'une demande à Copilot : pourquoi vous en avez besoin, et qui est concerné.

Montrer des exemples

Quelques exemples (few-shot) fixent un ton ou un format mieux qu'une longue description. Anthropic en conseille trois à cinq, proches de vos cas réels, variés, et séparés des instructions. Mais le modèle copie aussi ce que vous n'aviez pas voulu montrer. Google prévient qu'avec trop d'exemples, le modèle colle trop à leur forme. OpenAI conseille, pour ses modèles qui raisonnent, d'essayer d'abord sans exemple.

Structurer le texte

Quand un prompt mêle instructions, documents, exemples et demande, séparez chaque partie : des titres, ou des balises comme <contexte> et <demande>. Anthropic, OpenAI, Google et Mistral recommandent tous cette séparation. Google ajoute qu'il faut choisir un seul format et s'y tenir. Pour un long document, Anthropic et Google conseillent de placer le document d'abord et la question à la fin.

Décrire le résultat, pas la manière de penser

Les modèles récents savent planifier leur travail. Ce qui leur manque, c'est votre définition du résultat. Selon le guide d'OpenAI pour ses derniers modèles, il n'est souvent plus nécessaire de prescrire chaque étape. Le guide demande plutôt le but, le contexte, les contraintes, les preuves attendues, les critères de réussite et le format. Google juge généralement inutile de faire détailler au modèle ses étapes de raisonnement dans la réponse. Microsoft résume une bonne demande à Copilot en quatre parties : le but, le contexte, les sources, les attentes. Le niveau de réflexion, lui, se règle à part : c'est l'effort de raisonnement.

Un bon brief tient en sept lignes :

• Le but. Ce que vous voulez obtenir, et pour qui.
• Le contexte. Ce qu'un collègue devrait savoir : la situation, ce qui a déjà été essayé, les documents à lire.
• Les contraintes. Le ton, la longueur, les sources autorisées, ce qu'il ne faut pas modifier.
• Les outils. Ce que le modèle peut lire ou faire, et ce qui demande votre accord.
• Ce qui compte comme fini. Le livrable attendu, dans quel format.
• La vérification. Comment le résultat sera contrôlé : des chiffres recoupés, une source citée, un test qui passe.
• Quand s'arrêter. Ce qui doit faire revenir le modèle vers vous plutôt que de continuer.

Préciser plutôt qu'interdire vaguement

« Évite le jargon » ou « sois plus professionnel » laissent le modèle deviner. Anthropic recommande de dire ce qu'il faut faire plutôt que ce qu'il faut éviter, et note qu'une consigne vague comme « évite un style générique » remplace souvent un défaut par un autre. Nommez plutôt ce que vous voulez voir disparaître. Mistral demande d'éviter les formules floues comme « rends-le meilleur » et de dire exactement ce que vous voulez. Microsoft conseille d'écrire ce que l'assistant doit faire quand il manque d'information ou quand la demande sort de son rôle.

Tester et itérer

Un prompt se juge sur des cas réels, pas sur une impression. OpenAI recommande de relancer les tests à chaque publication d'un prompt, et classe « on dirait que ça marche » parmi les erreurs à éviter. Microsoft conseille de tester avec des demandes réalistes et des demandes piégées. Google et Mistral rappellent que l'écriture d'un prompt se fait par essais successifs. La page Les évaluations (évals) explique comment bâtir ces cas de test.

Trois niveaux d'instructions

Toutes les instructions ne vivent pas au même endroit. Un assistant IA lit, à chaque requête, des consignes posées à trois niveaux.

Le niveau permanent. Ces instructions s'appliquent à toutes les conversations, sans qu'on les répète. Ce sont les instructions de votre compte ou de votre organisation, celles d'un projet, le prompt système d'un produit, un fichier d'instructions lu par un agent, et les skills, qui ne se chargent que lorsqu'une tâche les demande. On y met ce qui ne change pas : qui vous êtes, le ton de la marque, les règles de l'entreprise, les conventions d'un projet.

La conversation. Au début d'un échange, le brief pose la tâche du moment : le dossier, le client, l'échéance, les documents à lire. Il vaut pour cette conversation, et pour elle seule.

Le message. Chaque demande précise l'étape suivante : « rédige la section 3 », « raccourcis ce paragraphe ».

Prenez une équipe commerciale qui utilise un assistant IA. Au niveau de l'organisation : le ton de l'entreprise, les engagements à ne jamais prendre par écrit. Dans un projet « Appels d'offres » : le modèle de réponse et trois réponses gagnantes. Dans une conversation : l'appel d'offres de la semaine, son client et sa date limite. Dans un message : « reprends la section prix avec la remise accordée ». Une équipe de développement fait la même chose avec un fichier d'instructions dans son dépôt de code : les commandes de test, les conventions, les dossiers à ne pas toucher.

Ce qui n'a pas sa place au niveau permanent

Tout ce qui change souvent : le client du jour, un prix, une date, le projet en cours. Une information périmée dans les instructions permanentes continue d'agir sur chaque réponse, sans que personne ne la voie. Une règle qui ne souffre aucune exception n'y a pas sa place non plus : le modèle lit ces instructions comme du contexte, pas comme une règle imposée. La page Le harnais : ce qui entoure le modèle explique où placer ces règles.

Comment les niveaux se combinent

Les niveaux ne se remplacent pas : ils s'additionnent. L'outil les assemble et les envoie ensemble au modèle. En cas de contradiction, c'est le produit qui décide laquelle l'emporte. En octobre 2026, chez Anthropic, les instructions d'organisation priment sur celles de chaque personne. Dans ChatGPT, les instructions d'un projet remplacent les instructions personnalisées à l'intérieur de ce projet. Sur GitHub.com, les instructions personnelles de Copilot passent avant celles du dépôt, qui passent avant celles de l'organisation. Et la documentation de Claude Code prévient que, si deux fichiers se contredisent, le modèle peut suivre l'un ou l'autre. Le plus sûr est de ne pas laisser deux niveaux se contredire.

Pourquoi le niveau permanent doit rester court

Les instructions permanentes sont relues à chaque requête. Elles occupent la fenêtre de contexte et se paient en tokens (des fragments de texte, souvent des morceaux de mots) à chaque fois. GitHub demande des instructions courtes et autonomes, justement parce qu'elles accompagnent chaque message. En octobre 2026, Anthropic conseille de garder chaque fichier CLAUDE.md sous 200 lignes : au-delà, il consomme du contexte et il est moins bien suivi. Microsoft note qu'un prompt système trop long réduit la place laissée aux demandes des utilisateurs. Gardez au niveau permanent ce qui sert presque toujours, et rangez le reste dans un skill ou un document que l'outil va chercher au besoin.

Qui propose quoi, en octobre 2026

• Anthropic. Dans Claude : des instructions de profil pour toutes vos conversations, des instructions de projet sur les offres payantes, et, sur les offres Team et Enterprise, des instructions d'organisation de 3 000 caractères au plus, ajoutées à chaque message de chaque membre. Claude Code lit des fichiers CLAUDE.md à plusieurs niveaux : organisation, utilisateur, projet.
• OpenAI. Dans ChatGPT : des instructions personnalisées pour toutes les conversations, des instructions de projet et, dans l'offre Enterprise, des instructions pour tout l'espace de travail. Codex lit des fichiers AGENTS.md, un global et ceux du dépôt ; le plus proche du dossier de travail l'emporte.
• Google. Dans l'application Gemini : vos instructions pour Gemini (comptes personnels), les Gems et les notebooks. Gemini dans Google Workspace a ses propres instructions, séparées. Gemini CLI lit des fichiers GEMINI.md et les envoie avec chaque requête.
• Microsoft. Microsoft Copilot propose des instructions personnalisées, en préversion, que les administrateurs peuvent désactiver. Les notebooks Copilot ont leurs propres instructions, et Copilot Studio donne des instructions à chaque agent. GitHub Copilot accepte des instructions personnelles, de dépôt et d'organisation.

Ce qui entre dans la fenêtre, ce qui en sort

L'ingénierie du contexte pose trois questions à chaque requête.

Que faut-il y mettre ? Le brief, les règles qui s'appliquent, les documents dont la tâche a besoin. Pas la base documentaire entière : Google conseille de ne pas envoyer au modèle les tokens dont il n'a pas besoin.

Que faut-il aller chercher ? Ce qui est trop volumineux ou trop changeant pour être placé d'avance se cherche au moment de la question. C'est le principe du RAG. Un agent peut aussi garder de simples références (un chemin de fichier, un lien) et n'ouvrir le contenu qu'au besoin, une approche qu'Anthropic décrit pour ses agents.

Que faut-il retirer ? Les vieux résultats d'outils, les pistes abandonnées, les détails périmés. OpenAI conseille de garder l'agent ancré sur le dernier objectif de l'utilisateur, sans s'encombrer de détails dépassés. Quand la fenêtre se remplit, résumer l'historique (la compaction) libère de la place. Une conversation trop longue se dégrade : mieux vaut souvent repartir d'une conversation neuve avec un brief à jour.

Ce que ça change pour vous

L'erreur classique

Autour du sujet