Le prompt engineering comme discipline système

Un prompt définit le rôle du modèle, la tâche, les contraintes, les données disponibles et le format de sortie attendu. Il ne garantit pas la vérité et ne remplace pas la validation. La fiabilité apparaît lorsque les instructions fonctionnent avec le retrieval, les schémas, les tests et des outils contrôlés.

Un prompt fragile tente d’anticiper chaque erreur possible en ajoutant du texte. Une approche systémique supprime d’abord les ambiguïtés du contrat, sépare les instructions des données, puis n’ajoute que les règles justifiées par des tests.

Les règles critiques doivent être courtes, explicites et placées au niveau d’instruction le plus élevé disponible. Les données utilisateur, les documents RAG et les résultats des outils sont traités comme des entrées non fiables, et non comme une extension de la politique système.

Une structure pratique comprend l’objectif, le contexte, les contraintes, le format de sortie, les critères de réussite et le comportement en cas de données insuffisantes. Chaque bloc doit avoir une seule fonction ; les exigences mélangées sont plus difficiles à tester et à versionner.

• objectif et limites de la tâche ;
• faits disponibles et leur provenance ;
• actions interdites ;
• format de sortie ;
• critères de refus ou d’escalade.

Les exemples few-shot sont utiles lorsqu’un format ou un style est difficile à décrire uniquement par des règles. Ils doivent couvrir non seulement le cas nominal, mais aussi le refus, les états inconnus, les conflits entre sources et les valeurs limites.

Une tâche complexe gagne à être divisée en étapes : extraction des faits, vérification, classification et construction de la réponse. Cela réduit le nombre de décisions cachées dans un seul appel et facilite le diagnostic.

Un prompt doit être testé sur un jeu d’évaluation stable comprenant des exemples réels, négatifs et adversariaux. Il faut mesurer les critères satisfaits, les erreurs de format, les affirmations non étayées et le coût plutôt que l’impression donnée par quelques réponses.

La version du prompt est conservée avec la version du modèle, le schéma de sortie et les métriques. Modifier une seule phrase peut affecter tout le pipeline ; une régression de prompt doit donc être traitée comme une régression de code.

Si le modèle ne dispose pas des faits nécessaires, il faut améliorer le retrieval. Si le résultat casse un parser, il faut utiliser des structured outputs. Si un agent exécute des actions inutiles, il faut réduire ses outils et son policy layer. Un paragraphe supplémentaire dans le system prompt répare rarement un défaut d’architecture.

Le meilleur prompt devient souvent plus court lorsque le système sépare correctement les données, les instructions, les outils et les validations.

En production, le prompt engineering consiste à gérer les instructions comme du code. Un prompt a un propriétaire, une version, un jeu de tests, un format attendu et des critères de rollback. Modifier le texte sans évaluation crée des régressions cachées : améliorer un scénario peut en dégrader un autre, et changer de modèle peut transformer complètement le comportement d’une ancienne instruction.

Un system prompt ne doit contenir que des règles stables. Le contexte dynamique, les données utilisateur et les résultats de retrieval sont transmis séparément et marqués comme non fiables. Pour une tâche complexe, il est plus robuste de décomposer le workflow en plusieurs étapes vérifiables que d’accumuler des dizaines d’exigences contradictoires dans un méga-prompt.

• Conserver les templates de prompts dans le contrôle de version.
• Exécuter des regression evals avant de modifier un prompt de production.
• Séparer les instructions des données non fiables.

Un prompt de production doit avoir un contrat explicite : objectif, entrées autorisées, schéma de sortie attendu, capacités des outils, contraintes de sécurité et comportement de fallback. Les system instructions, le template de tâche, les exemples et le contexte récupéré doivent être versionnés séparément afin qu’une modification d’une couche n’en masque pas une autre. Le prompt est assemblé de manière déterministe à partir de variables typées ; les entrées utilisateur et les documents récupérés sont marqués comme données non fiables au lieu d’être concaténés sans frontières. Pour les réponses structurées, la validation du schéma et la stratégie de retry font partie du contrat au même titre que le texte des instructions.

Chaque modification doit passer par une régression offline, une shadow evaluation et un rollout limité. Le diff du fichier de prompt ne suffit pas : il faut conserver les résultats sur un dataset de contrôle, l’impact sur token usage et latence, le taux de refus et les échecs critiques. Les exemples few-shot sont choisis pour leur couverture plutôt que pour leur élégance ; ils ne doivent contenir ni secrets, ni données personnelles, ni révéler accidentellement un answer key. L’ownership, la review et la deprecation des prompts doivent être formalisés, sinon des dizaines de templates presque identiques divergeront rapidement entre services.

• Conserver le prompt ID et sa version dans chaque trace.
• Valider les variables runtime avant de composer les messages.
• Tester les conflits d’instructions et l’indirect prompt injection.
• Prévoir un rollback rapide vers une version stable.