Prompt engineering : définition et enjeux pour vos équipes

Comment fonctionne le prompt engineering ?

Le prompt engineering améliore par essais successifs la consigne donnée à un modèle de langage, et mesure chaque version sur des cas tests. Anthropic pose trois préalables dans sa documentation : des critères de réussite clairs, un moyen de les tester et une première version de la consigne.

Une consigne efficace réunit quatre éléments.

1. La tâche, décrite sans ambiguïté. Anthropic conseille de traiter le modèle comme un nouvel employé brillant, à qui manque le contexte de vos règles et de vos méthodes.

2. Le contexte et la raison des règles. Expliquer pourquoi une règle existe aide le modèle à l’appliquer aux cas voisins, selon la même documentation.

3. Le format attendu : longueur, structure, ton.

4. Des exemples. Anthropic recommande trois à cinq exemples proches de vos cas réels, et variés.

Le test le plus simple tient en une phrase : faites lire la consigne à un collègue qui ne connaît pas la tâche. S’il hésite, le modèle hésitera aussi. Les réponses d’un modèle varient d’un essai à l’autre : OpenAI qualifie l’exercice de mélange d’art et de science.

Prompt engineering ou fine-tuning : quelle différence ?

Le prompt engineering change la consigne ; le fine-tuning change le modèle. Le fine-tuning réentraîne un modèle existant sur un jeu d’exemples que vous préparez. OpenAI conseille d’essayer d’abord une consigne sans exemple, puis avec exemples, et de passer au fine-tuning seulement si ces deux essais échouent. L’éditeur ferme toutefois son fine-tuning en libre-service.

Une consigne ne donne pas non plus au modèle les informations qu’il ignore. Pour qu’il réponde à partir de vos documents, reliez-le à ces documents : c’est le rôle du RAG.

Anthropic parle désormais de « context engineering ». Dans un article du 29 septembre 2025, l’éditeur présente cette notion comme la suite naturelle du prompt engineering. Elle couvre toute l’information fournie au modèle : consignes, outils, MCP, données externes, historique des échanges.

Que change le prompt engineering pour votre décision ?

Le prompt engineering confie la qualité des réponses à ceux qui connaissent la tâche, et fait de chaque consigne un actif à gérer.

• La compétence clé consiste à décrire une tâche. Le test du collègue le montre : une bonne consigne exige de connaître le métier, ses règles et ses exceptions. Vos experts métier détiennent ce savoir ; un spécialiste apporte la méthode, mais il doit travailler avec eux. Le règlement européen sur l’IA pousse aussi à former. Son article 4, modifié par le règlement 2026/1744, demande aux fournisseurs et aux déployeurs de prendre des mesures pour favoriser la maîtrise de l’IA.

• Gérez une consigne en production comme du code. OpenAI recommande de traiter les consignes comme du code applicatif : versions, revue, tests à chaque mise en production. Désignez qui modifie une consigne et qui valide le changement. Une consigne qui revient d’une tâche à l’autre peut devenir une skill d’agent IA, à gérer de la même façon.

• Changer de modèle oblige à retester vos consignes. Selon la documentation d’OpenAI, des modèles différents demandent parfois des consignes différentes, et deux versions d’une même famille peuvent donner des résultats différents. L’éditeur conseille de figer en production une version précise du modèle. Ces tests pèsent dans le coût d’une sortie, donc dans votre dépendance fournisseur.

• Une consigne ne protège rien. L’OWASP recommande de ne traiter la consigne système ni comme un secret, ni comme un contrôle de sécurité (fiche LLM07:2025). Les contrôles d’accès restent hors du modèle. Un tiers peut aussi glisser ses propres consignes dans un contenu que lit le modèle : c’est la prompt injection.

• Une meilleure consigne ne corrige pas un mauvais choix de modèle. Anthropic le note : tous les problèmes ne relèvent pas du prompt engineering. Un autre modèle améliore parfois plus facilement le coût ou le temps de réponse.

Exemple illustratif

Ce cas est fictif. Une direction des achats veut résumer ses contrats fournisseurs. La première consigne, « Résume ce contrat », donne des résumés inégaux d’un contrat à l’autre. L’acheteuse la plus expérimentée réécrit la consigne. Elle précise le rôle (préparer une revue de contrat), les clauses à extraire (durée, résiliation, pénalités, réversibilité), un format en tableau et une règle : signaler une clause absente plutôt que la deviner. Elle ajoute comme exemples trois résumés qu’un juriste a rédigés. L’équipe teste la consigne sur des contrats qu’un juriste a déjà analysés, puis l’enregistre avec un numéro de version. À chaque changement de modèle, elle relance le même test.