Prompt engineering

Le prompt engineering désigne le travail de rédaction et d'ajustement des instructions transmises à un modèle de langage. Le prompt est le texte envoyé au modèle : il contient la consigne, le contexte, les contraintes de format et parfois des exemples.

Le terme a connu une inflation regrettable, jusqu'à désigner un métier à part entière. Dans un projet web, il s'agit plus modestement d'un travail d'ingénierie ordinaire : on écrit une spécification, on la teste, on mesure, on corrige. La différence est que cette spécification est rédigée en français plutôt qu'en code, ce qui la rend trompeusement facile à écrire et difficile à valider.

Ce qui fonctionne réellement

Au-delà des listes de « formules magiques » qui circulent, quelques pratiques produisent des résultats constants.

• Décrire le rôle et le contexte : préciser à qui s'adresse la réponse, dans quel cadre et avec quel niveau de détail. Un modèle sans contexte produit une réponse générique.
• Donner des exemples : montrer deux ou trois cas d'entrée et de sortie attendue est plus efficace que dix lignes de consignes abstraites. C'est le levier le plus rentable.
• Imposer un format de sortie : demander une structure précise (JSON, liste, gabarit) rend la réponse exploitable par du code et testable automatiquement.
• Énoncer les interdits : indiquer explicitement ce que le modèle ne doit pas faire (inventer, répondre hors périmètre, dépasser une longueur...).
• Autoriser l'abstention : prévoir une réponse de repli lorsque les informations disponibles ne permettent pas de conclure. Sans cette porte de sortie, le modèle invente.
• Découper les tâches complexes : deux appels successifs simples donnent de meilleurs résultats qu'une instruction unique contenant six exigences.

Un prompt est du code

C'est le point le plus souvent négligé, et celui qui distingue un prototype d'un service exploitable. Les instructions envoyées à un modèle pilotent le comportement de votre application : elles doivent être traitées avec les mêmes exigences que le reste du code.

• Versionnées : stockées dans le dépôt Git, jamais éparpillées dans une interface d'administration ou un tableur partagé.

• Testées : un jeu de cas d'entrée avec les sorties attendues, rejoué à chaque modification. C'est le seul moyen de constater qu'une amélioration apparente a dégradé trois autres cas.

• Documentées : pourquoi telle contrainte a été ajoutée, quel problème elle corrigeait. Sans cela, la première personne qui « simplifie » le texte réintroduit un bug résolu six mois plus tôt.

• Séparées des données utilisateur : ce que saisit un visiteur ne doit jamais être concaténé sans vérification à vos consignes, sous peine de permettre leur détournement.

L'injection d'instructions

Un modèle ne distingue pas structurellement vos consignes du contenu qu'on lui soumet. Un texte fourni par un utilisateur, ou une page web lue par un agent, peut contenir des directives destinées à détourner le comportement prévu : contourner une règle, divulguer les instructions internes, déclencher une action non souhaitée.

Il n'existe pas de parade complète à ce jour. Les mesures qui limitent réellement le risque sont architecturales : restreindre le périmètre d'actions accessibles, valider les sorties par du code avant tout effet, et considérer que le contenu extérieur n'est jamais digne de confiance. C'est un sujet de sécurité web, relativement classique, appliqué à une nouvelle technologie.