Écrivez l'éval avant le prompt
On observe souvent une équipe triturant un prompt pour décréter à l'œil que « c'est mieux ». Sans jeu doré défini en amont, ce n'est qu'un réglage à l'aveugle.
Le prompt engineering à l'aveugle
On observe régulièrement une équipe en plein exercice de « prompt engineering ». Elle ajoute un adjectif à sa consigne, relance la génération, lit en diagonale trois sorties sur l'interface web d'un LLM, puis décrète solennellement que « c'est mieux ». L'itération suivante, censée corriger un détail, écrase souvent la précédente. Question simple : ce « mieux » est-il mesuré, et par rapport à quoi ? Silence dans l'open space.
Ce rituel, largement répandu en agence, n'a strictement rien d'une ingénierie. C'est un réglage à l'aveugle qui se donne des airs de méthode scientifique. Optimiser sur la base d'un ressenti face à un échantillon statistiquement insignifiant garantit une chose : la dérive silencieuse des prompts. On corrige un cas particulier en dégradant trois cas nominaux qu'on n'a pas pris la peine de retester systématiquement.
Bénéfice : Exiger une mesure de succès explicite bloque les itérations infinies basées sur le ressenti et fige les attentes réelles de l'équipe de production.
Le jeu doré comme cahier des charges
La rigueur impose d'inverser l'approche. Avant même d'ouvrir un éditeur de texte pour rédiger la moindre instruction système, il faut constituer un jeu doré — le fameux *golden dataset*. Il s'agit d'un échantillon strict de 30 à 50 cas d'usage réels, rigoureusement annotés manuellement.
Pour chaque entrée (l'input brut), on documente la sortie idéale attendue ou, à minima, une grille de critères binaires de validation (présence d'une entité spécifique, format JSON valide, absence de ton promotionnel). Ce n'est pas un exercice théorique ou une corvée administrative. Ce fichier encode physiquement et définitivement ce que « réussi » veut dire pour la tâche visée. Tout comme un développeur backend écrit ses tests unitaires avant de concevoir sa fonction, le producteur de contenu GenAI fige ses cas d'acceptation avant de parler au modèle.
Bénéfice : Le jeu doré transforme un débat d'opinion sur le style ou le ton en une validation mathématique d'exigences préalablement actées.
L'éval est la spec, le prompt l'implémentation
Dans la doctrine de production LIMEN, le paradigme est clair : l'évaluation est la spécification. Le prompt n'en est qu'une implémentation temporaire, contingente et jetable. Si le modèle de demain requiert une formulation radicalement différente pour atteindre le même résultat, le prompt sera réécrit de zéro, mais le jeu doré, lui, restera intact.
L'évaluation est la spécification absolue ; le prompt n'est qu'une implémentation temporaire dictée par les caprices du modèle actuel.
Commencer par le prompt, c'est confondre l'outil de production avec le cahier des charges. En définissant l'éval d'abord, on s'assure que le gain d'information, seule porte de publication, est mesurable de manière systématique sur l'ensemble du corpus. Un grand modèle de langage n'est qu'un moteur probabiliste ; sans un harnais de test déterministe pour le brider, l'équipe pilote au hasard et livre de la variance.
Bénéfice : Découpler la définition du succès de la mécanique de prompt immunise la production contre les mises à jour inopinées des modèles sous-jacents.
Construire un jeu doré représentatif
Un jeu d'évaluation de 30 à 50 exemples n'a de valeur que s'il cartographie fidèlement l'espace du problème. Il doit inclure les cas nominaux (le flux standard), les cas limites (les bords du modèle) et les pièges documentés. La logique est parfaitement identique à notre échantillonnage de requêtes lors de la phase de setup d'un audit Sonar.
Si le modèle doit extraire et formater des données chiffrées sans jamais halluciner, le jeu doré doit impérativement contenir des exemples où la donnée source est ambiguë, contradictoire ou totalement manquante. C'est le seul moyen de vérifier que le prompt force efficacement l'abstention. Et pour automatiser cette vérification à l'échelle, il faut séparer les rôles architecturaux : générateur chaud, classifieur froid. Le LLM configuré pour évaluer la sortie ne doit jamais être celui qui l'a produite.
Bénéfice : Un échantillonnage exhaustif garantit que le système est robuste face aux requêtes atypiques, réduisant drastiquement les retouches manuelles post-génération.
Le jeu doré comme actif contractuel
Au-delà de la stricte ingénierie de la donnée, ce jeu d'évaluation revêt une dimension contractuelle majeure. Il devient la baseline de non-régression de l'intégralité du système de contenu. C'est la transposition exacte, côté production, de notre principe cardinal de mesure de visibilité : pas de baseline, pas de preuve. Sans une référence de performance figée au temps T0, absolument aucun progrès qualitatif n'est attribuable à vos cycles d'itérations.
Le jeu doré est le premier livrable tangible qui prouve au client ou à la direction que le système génératif est sous contrôle méthodologique. Il acte le niveau d'exigence initial, aligne les parties prenantes, et permet d'auditer techniquement toute dérive future. Il transforme un processus souvent perçu comme de la magie noire en une prestation d'ingénierie auditable et opposable.
Bénéfice : Livrer l'éval comme une baseline contractuelle protège l'agence des ressentis clients subjectifs et quantifie objectivement le travail d'optimisation.