Stratégie de prompt engineering
Statut
Document de doctrine IA — version initiale.
Objectif
Le prompt engineering DMV doit produire des assistants fiables, sobres et maintenables.
Il ne s'agit pas d'empiler des formulations complexes, mais de créer des consignes métier claires, testables et adaptées aux cas d'usage locaux.
Principes
- Partir du besoin métier.
- Limiter le contexte.
- Demander une sortie structurée.
- Prévoir le cas où l'information manque.
- Tester avec des exemples réels.
- Mesurer qualité, coût et latence.
- Versionner les prompts.
- Éviter les prompts trop longs si un service métier peut préparer les données.
Méthode cible
- Définir le cas d'usage.
- Définir l'utilisateur cible.
- Définir les données autorisées.
- Définir la sortie attendue.
- Écrire un prompt système court et strict.
- Ajouter des exemples si nécessaire.
- Tester sur cas simples, limites et sensibles.
- Mesurer coût et qualité.
- Versionner.
- Déployer derrière l'AI Gateway.
Formats de sortie
Privilégier des sorties structurées :
- JSON contrôlé pour les services backend ;
- liste courte pour suggestions ;
- brouillon éditable pour publications ;
- score et justification pour modération ;
- réponse avec sources pour recherche ;
- plan de slides pour PlayLoop.
Tests
Chaque prompt important doit être testé avec :
- cas nominal ;
- contexte incomplet ;
- demande hors périmètre ;
- tentative d'injection ;
- contenu sensible ;
- données contradictoires ;
- sortie trop longue ;
- coût élevé.
Erreurs à éviter
- Donner trop de contexte.
- Laisser le modèle décider des droits.
- Demander une décision critique sans humain.
- Produire des réponses non vérifiables.
- Utiliser le même prompt pour tous les usages.
- Oublier le coût tokens.
- Confondre prompt et règle métier.
Gouvernance
Les prompts doivent être maintenus comme des artefacts produit et technique.
Toute évolution majeure doit indiquer :
- pourquoi le prompt change ;
- quel problème il corrige ;
- quels tests valident le changement ;
- quel impact coût ou qualité est attendu.