Évaluer et versionner ses prompts

L’essentiel. Un prompt professionnel n’est pas seulement un texte qui « marche sur mon exemple ». C’est une version précise d’un système — instructions, modèle, paramètres, outils, données et format — évaluée sur des cas représentatifs. La boucle saine est : définir la réussite, constituer un petit jeu de tests, mesurer, analyser les erreurs, modifier une chose, puis recommencer. Sans version ni trace, une amélioration perçue reste une impression impossible à reproduire.

Définir « mieux » avant de réécrire

Commencez par traduire l’objectif métier en propriétés observables. Pour un résumé : couverture des cinq faits essentiels, aucune affirmation ajoutée, 150 à 180 mots, noms et nombres exacts. Pour un classement : ensemble fermé d’étiquettes, justification reliée au texte, taux d’abstention accepté. Pour un agent : taux de réussite, nombre d’actions, incidents, coût et besoin de reprise humaine.

Un bon jeu de tests contient des cas ordinaires, des cas limites, des entrées ambiguës et des situations à refuser. Il ne doit pas être composé uniquement des exemples qui ont servi à écrire le prompt. Commencez petit — dix à trente cas soigneusement relus valent mieux qu’un grand fichier douteux — puis ajoutez chaque erreur réelle à une suite de non-régression.

Les critères peuvent être déterministes (JSON valide, mot interdit absent, calcul exact), humains (clarté, ton, utilité) ou assistés par un modèle évaluateur. Ce dernier est pratique à grande échelle, mais doit être calibré contre des jugements humains, surveillé pour les biais et complété par des contrôles déterministes. L’évaluateur ne devient pas vrai parce qu’il renvoie un score décimal.

Quand évaluer et quand éviter la fausse précision

• Évaluez systématiquement avant un déploiement, un changement de modèle, de données, d’outil ou de prompt.
• Réévaluez après un incident et à intervalles adaptés à l’évolution du contexte.
• Évitez un score unique lorsque plusieurs dimensions s’opposent : exactitude, style, coût, latence et sécurité méritent des mesures séparées.
• N’optimisez pas uniquement le test : gardez un lot final non consulté pendant les itérations.

Avant / après : de « ça a l’air mieux » à une décision

Avant : une équipe modifie le rôle, ajoute trois exemples et change de modèle dans la même journée. Elle teste deux demandes faciles et garde la réponse préférée. Personne ne sait quel changement a aidé, ni si les anciens cas fonctionnent encore.

Après : la version 1.3 ne modifie que les exemples. Elle est exécutée avec la même configuration sur 24 cas gelés. Le tableau rapporte exactitude factuelle, respect du format, refus corrects, coût et latence. Les trois régressions sont examinées avant la décision ; la version et son rapport sont conservés, avec une procédure de retour à 1.2.

Prompt copiable : créer un plan d’évaluation

Tu m’aides à concevoir l’évaluation d’un système IA, pas à déclarer qu’il est bon.

Usage : [TÂCHE ET UTILISATEURS]
Conséquences d’une erreur : [FAIBLES / MOYENNES / ÉLEVÉES]
Sortie attendue : [FORMAT]
Exemples réels anonymisés : [EXEMPLES]

Propose :
1. les dimensions de qualité séparées ;
2. pour chacune, une définition observable et une méthode de mesure ;
3. 12 cas de test : normaux, limites, ambigus, adversariaux et refus attendus ;
4. les réponses ou propriétés attendues, sans inventer une vérité manquante ;
5. les contrôles déterministes possibles ;
6. les cas exigeant un expert humain ;
7. une règle de décision et des seuils justifiés ;
8. les informations à journaliser pour reproduire le test.

Signale les angles morts et les risques de sur-optimisation du jeu de tests.

La fiche de version minimale

• Identité : nom du prompt, version sémantique, propriétaire, date et objectif.
• Configuration : modèle/version, paramètres, instructions système, outils, schémas et politique de reprise.
• Données : corpus ou documents, version, droits d’accès et règles de confidentialité.
• Évaluation : jeu de tests versionné, métriques, résultats par catégorie et exemples d’échecs.
• Décision : approbateur, limites connues, date de révision et procédure de retour arrière.

Conservez le prompt dans un format texte versionnable, idéalement avec les exemples et schémas séparés. Ne placez jamais une clé secrète ou des données personnelles dans le dépôt. Un journal de modifications doit expliquer l’intention — « réduit les classifications forcées quand le texte est ambigu » — et pas seulement « amélioration du prompt ».

Erreurs fréquentes

• Tester uniquement la démonstration qui a inspiré le prompt.
• Changer simultanément prompt, modèle et corpus.
• Utiliser un juge automatique sans échantillon relu par des humains.
• Moyenner les scores au point de masquer un échec grave.
• Réutiliser le lot final jusqu’à l’optimiser indirectement.
• Oublier de versionner les outils, schémas, sources et paramètres.