Prompt engineering
Prompt engineering en production : des systèmes IA fiables
Le prompt engineering en production est la discipline qui rend un modèle de langage prévisible au sein d'un vrai produit, face à des entrées jamais vues. Elle traite les prompts comme du code : spécifiés, versionnés, testés sur un jeu d'évaluation, surveillés et protégés contre l'injection. Un prompt qui marche une fois dans un bac à sable est un brouillon ; un prompt qui passe une suite de non-régression à chaque modification est un composant.
- Un prompt de production est un composant versionné et testé, pas une phrase astucieuse.
- Des sorties structurées et un prompt système clair suppriment l'essentiel de l'imprévisibilité.
- La qualité du contexte fourni compte davantage que la formulation de la consigne.
- Chaque modification de prompt doit passer un jeu d'évaluation construit à partir de cas réels.
- Traitez toute entrée externe comme une donnée non fiable pour vous protéger de l'injection de prompt.
Pourquoi les prompts de bac à sable échouent en production
Un prompt testé sur cinq exemples choisis à la main rencontre en production des milliers d'entrées réelles : demandes mal orthographiées, documents en trois langues, champs vides, textes malveillants. Un comportement qui semblait solide devient incohérent, et personne ne s'en aperçoit avant un client.
Le prompt engineering de production comble cet écart. Il définit ce qu'est une sortie correcte, la mesure sur des cas réalistes et rend chaque modification visible et réversible. Le but n'est pas un prompt parfait, mais un système dont les échecs sont rares, détectés et contenus.
Le prompt système est une spécification
Le prompt système doit se lire comme une courte spécification : le rôle, la tâche, le public, les contraintes et la conduite à tenir quand une information manque. Toute ambiguïté dans le prompt système se traduit par de la variance dans les réponses.
Formulez les consignes de manière positive et concrète. « Réponds dans la langue du client, en trois phrases au plus, et dis que tu ne sais pas si la documentation ne couvre pas la question » fonctionne mieux qu'une liste d'interdits. Énoncez les cas limites explicitement, car le modèle les rencontrera.
Sorties structurées et exemples few-shot
Quand la sortie alimente un logiciel, exigez une structure. Un schéma JSON avec des champs typés, des énumérations pour les catégories et des clés obligatoires transforme une réponse libre en donnée que votre code peut valider. La plupart des modèles actuels gèrent nativement les sorties contraintes par un schéma ; utilisez-les, et validez quand même de votre côté.
Les exemples few-shot enseignent le format et le jugement plus vite que n'importe quelle description. Deux à cinq exemples variés, dont un cas piège et un cas de refus, suffisent généralement à stabiliser le comportement. Gardez-les réalistes et renouvelez-les lorsqu'ils commencent à orienter les réponses vers leur formulation exacte.
- Définir le schéma avant d'écrire la consigne
- Utiliser des énumérations plutôt que du texte libre pour les catégories et les statuts
- Inclure un exemple de la bonne réponse « je ne peux pas répondre »
- Valider chaque réponse, puis relancer ou escalader en cas d'échec
L'ingénierie du contexte : ce que voit le modèle
La plupart des problèmes de qualité imputés au prompt sont des problèmes de contexte. Le modèle ne peut utiliser que ce qui se trouve dans sa fenêtre de contexte : la bonne fiche client, le bon paragraphe de politique, les derniers messages de la conversation. Sélectionner, ordonner et réduire ce contexte, c'est ce qu'on appelle désormais l'ingénierie du contexte.
La recherche augmentée (récupérer les documents pertinents dans un index ou une base vectorielle) fonctionne quand les documents sont propres, bien découpés et étiquetés avec leur source. Demandez au modèle de citer le passage utilisé : les citations rendent les réponses vérifiables et les échecs de recherche visibles.
Jeux d'évaluation et tests de non-régression
Un jeu d'évaluation est une collection d'entrées réelles accompagnées de la sortie attendue ou des critères qu'une bonne sortie doit remplir. C'est l'actif le plus important d'une fonctionnalité IA, car il transforme « ça semble mieux » en chiffre.
Commencez avec cinquante à quelques centaines de cas issus du trafic réel, y compris les plus difficiles. Notez-les automatiquement quand c'est possible (correspondance exacte, validité du schéma, mots-clés) et avec un évaluateur à grille ou une relecture humaine quand le jugement est nécessaire. Rejouez tout le jeu à chaque changement de prompt, de modèle ou de recherche, et bloquez la mise en ligne en cas de régression.
Versionner les prompts comme du code, et surveiller coûts et latence
Les prompts vivent dans le dépôt de code, pas dans une zone de texte d'un tableau de bord. Chaque modification est un commit avec une raison, un résultat d'évaluation et un retour arrière possible. Les journaux indiquent quelle version du prompt a produit chaque réponse, pour qu'une réclamation remonte à la consigne exacte.
Le choix du modèle est un arbitrage d'ingénierie entre qualité, latence et coût. Utilisez le modèle le plus capable là où le raisonnement compte, et un modèle plus petit et plus rapide pour la classification ou l'extraction dès que votre jeu d'évaluation prouve qu'il suffit. La mise en cache des prompts, des contextes plus courts et le traitement par lots réduisent les coûts sans toucher à la qualité.
Se protéger de l'injection de prompt
L'injection de prompt est une attaque dans laquelle un texte caché dans un e-mail, un document ou une page web tente de remplacer vos consignes. Elle figure en tête du Top 10 OWASP des applications LLM, et aucune formulation ne peut l'empêcher totalement.
La défense est architecturale. Séparez clairement les contenus non fiables et étiquetez-les comme données. Ne donnez au modèle que les outils nécessaires, avec le moindre privilège. Exigez une validation humaine pour les actions sensibles. Validez les sorties avant qu'elles n'atteignent un autre système. Notre guide de l'automatisation par IA agentique montre comment ces contrôles s'articulent autour d'un agent.
Comment FlexiGlob pratique le prompt engineering
Chez The Super Platform, chaque fonctionnalité IA est livrée avec son prompt système, son schéma, son jeu d'évaluation et sa surveillance, dans le même dépôt que la plateforme. C'est ce qui permet aux agents de passer en ligne le jour 5 de la méthode en 7 jours sans devenir un risque au jour 30.
FlexiGlob propose aussi un service de prompt engineering autonome pour les équipes qui ont déjà un produit : audit des prompts existants, construction du jeu d'évaluation, puis réécriture testée et versionnée.
Questions
Questions
Qu'est-ce que le prompt engineering en production ?
C'est la pratique qui consiste à concevoir, tester et maintenir les consignes et le contexte fournis à un modèle de langage au sein d'un produit en ligne, pour qu'il se comporte de manière fiable sur des entrées réelles. Elle couvre les sorties structurées, les jeux d'évaluation, le versionnage, la surveillance et la protection contre l'injection.
Comment teste-t-on un prompt ?
On l'exécute sur un jeu d'évaluation d'entrées réelles accompagnées de sorties attendues ou de critères de notation, puis on note les résultats automatiquement ou avec une grille. Le même jeu est rejoué à chaque modification du prompt, du modèle ou du contexte, et toute régression bloque la mise en ligne.
Un prompt bien écrit peut-il empêcher l'injection de prompt ?
Non. Une formulation soignée réduit le risque sans l'éliminer. La protection fiable vient de l'architecture : séparation des données non fiables, outils à moindre privilège, validation des sorties et validation humaine des actions sensibles.