Une démo n'est pas une évaluation : tester une fonctionnalité IA dans la durée

Une démo montre qu'un système peut réussir quelques exemples choisis. Une évaluation vérifie s'il atteint un seuil défini sur des cas représentatifs, difficiles et dangereux, puis détecte les régressions lorsque le modèle, le prompt, les données ou le workflow changent.

La fluidité d'une réponse et l'enthousiasme d'une réunion ne constituent pas une preuve de fiabilité.

Partir du risque et du résultat

Avant de choisir un outil d'évaluation, demandez : quel résultat doit rester vrai et quelle erreur est inacceptable ?

Une fonction de reformulation marketing et un assistant qui prépare une décision sensible n'ont pas les mêmes seuils. L'évaluation doit suivre l'impact, la réversibilité et la capacité de recours.

Construire un jeu de cas

Réunissez quatre familles :

Cas fréquents

Le cœur du trafic, avec la diversité réelle des langues, formats et longueurs.

Cas difficiles

Informations incomplètes, ambiguïtés, contradictions, bruit et exceptions métier.

Cas dangereux

Injection de prompt, données sensibles, action non autorisée, source obsolète ou demande hors périmètre.

Cas de régression

Chaque incident important devient un test reproductible, après suppression ou protection des données sensibles.

Commencez avec 20 à 50 cas bien compris. Un grand jeu opaque est moins utile qu'un petit jeu relié à des décisions.

Écrire les critères avant le résultat

Exemples de critères : exactitude factuelle, complétude, respect des instructions, citation, refus approprié, ton, coût, latence, capacité à demander et sécurité.

Pour chacun, définissez :

• la méthode de notation ;
• le seuil de passage ;
• les erreurs critiques qui bloquent le déploiement ;
• la personne qui arbitre les désaccords ;
• la fréquence de révision.

Une moyenne élevée ne doit pas masquer un seul échec catastrophique.

Trois types d'évaluateurs

Règle déterministe

Vérifie format, présence, schéma, droits ou valeur calculable. Rapide et reproductible.

Modèle évaluateur

Utile pour comparer cohérence, pertinence ou style à grande échelle. Il doit être calibré sur des jugements humains et ne devient pas vérité parce qu'il produit un nombre.

Revue humaine

Indispensable pour les critères subtils, le contexte métier et les cas à fort impact. Mesurez aussi l'accord entre évaluateurs.

Combinez les trois plutôt que de chercher un score unique.

Offline et online

L'évaluation offline teste avant exposition. L'évaluation online observe la réalité : corrections, recours, abandon, résultat et incident. Une fonctionnalité peut réussir le jeu offline et échouer dans le workflow.

Reliez chaque version déployée au prompt, modèle, configuration, jeu de cas et résultat. Sans version, un changement de qualité devient difficile à expliquer.

Définir un budget d'erreur

Fixez la quantité d'erreurs acceptable pour une période et un segment, en distinguant les erreurs ordinaires des erreurs critiques. Lorsque le budget est consommé, ralentissez les changements et améliorez la fiabilité.

Ce mécanisme ne rend pas une erreur grave acceptable. Certains scénarios conservent une tolérance nulle et exigent une validation humaine.

Boucle après incident

1. protéger l'utilisateur ;
2. comprendre le parcours et la version ;
3. corriger ou revenir en arrière ;
4. ajouter un cas de régression ;
5. revoir le contrôle et le mode dégradé ;
6. enregistrer la décision et son résultat.

FAQ

Peut-on tout évaluer automatiquement ?

Non. L'automatisation couvre bien les règles stables et aide à échantillonner. Le jugement humain reste nécessaire pour le contexte et l'impact.

Combien de cas faut-il avant un pilote ?

Assez pour couvrir le chemin normal, les principales exceptions et les erreurs graves. Vingt cas bien choisis peuvent suffire à démarrer, puis le jeu grandit avec l'usage.

Quand relancer les évaluations ?

À chaque changement de modèle, prompt, outil, source, politique ou workflow, puis régulièrement pour détecter la dérive.

Prochaine étape

Transformez vos cinq dernières erreurs ou corrections en cas de régression, ajoutez cinq cas fréquents et cinq cas dangereux, puis écrivez les seuils avant de tester. Pour une revue du protocole, écrivez à contact@yumea.fr avec l'objet « EVALS ».

Sources

• NIST, AI Risk Management Framework.
• OWASP, Top 10 for LLM Applications 2025.
• Google SRE, Error Budget Policy.