Comment évaluer la fiabilité d’un modèle IA

La fiabilité d’un modèle IA ne se résume pas à une note générale ou à une impression après dix prompts. Elle mesure la capacité d’un système précis à produire le comportement attendu, sur des cas représentatifs, dans un contexte défini.

Un modèle peut exceller en rédaction et échouer sur l’extraction de données. Il peut réussir 95 % des demandes courantes tout en ratant les 5 % qui déclenchent un paiement, une publication ou une décision sensible.

Une évaluation utile commence donc par le workflow, pas par le nom du modèle. Elle décrit la tâche, construit un jeu de cas, définit les critères de réussite, exécute plusieurs variantes et analyse les échecs.

OpenAI présente les evals comme un composant essentiel pour construire des applications fiables, notamment lors d’un changement de modèle ou de prompt. Le NIST insiste aussi sur le rôle des mesures et évaluations contextualisées pour juger l’exactitude, la robustesse, la sécurité, la confidentialité, les biais et la transparence.

Définir ce que « fiable » veut dire

Une réponse fluide peut être fausse. Une réponse exacte peut être inutilisable. Une action correcte peut arriver trop tard ou coûter trop cher.

La fiabilité doit donc être décomposée.

Pour un assistant qui classe des tickets, elle peut comprendre :

• la bonne catégorie ;

• un format strict ;

• une latence maximale ;

• l’absence de données personnelles dans la sortie ;

• un taux d’escalade acceptable.

Pour un agent qui publie un article, elle peut comprendre :

• des sources valides ;

• aucune affirmation inventée ;

• le bon slug ;

• une image conforme ;

• un statut publié ;

• une URL qui répond ;

• un rendu mobile contrôlé.

Le second système ne peut pas être évalué avec une simple comparaison de texte. Son résultat dépend d’une chaîne d’actions et de preuves.

Avant tout test, écris une phrase :

Le système est fiable si, pour [population de demandes], il produit [résultat observable], respecte [contraintes] et bloque ou escalade [cas à risque].

Cette phrase devient le contrat de l’évaluation.

Évaluer le système, pas seulement le modèle

Une application IA combine souvent :

• des instructions ;

• un modèle ;

• des outils ;

• des documents ;

• une mémoire ;

• une interface ;

• des règles de permission ;

• des validations humaines.

Changer un seul composant peut modifier le comportement final. Un meilleur modèle ne corrige pas une base documentaire obsolète. Une instruction plus longue ne répare pas une permission excessive. Un bon résultat textuel ne prouve pas qu’un outil externe a exécuté l’action.

L’unité de test doit correspondre à la décision réelle.

Tu peux distinguer trois niveaux.

Évaluation du modèle

Elle mesure une capacité isolée : classification, extraction, rédaction, raisonnement ou respect d’un format.

Évaluation du workflow

Elle teste l’enchaînement complet : récupération de données, choix d’outil, génération, validation et résultat.

Évaluation en production

Elle mesure le comportement sur des demandes réelles, avec les latences, erreurs réseau, permissions et distributions observées.

Ces niveaux se complètent. Un modèle performant en laboratoire peut échouer dans le workflow. Un workflow stable sur un jeu fixe peut dériver lorsque les utilisateurs changent leur manière de demander.

Construire un jeu de cas représentatif

Le jeu de test détermine ce que l’évaluation peut détecter.

Cent exemples faciles produisent une note rassurante et peu utile. Vingt cas choisis autour des décisions risquées peuvent révéler davantage de problèmes.

Un bon jeu combine plusieurs sources :

• demandes réelles anonymisées ;

• cas fréquents ;

• cas limites ;

• erreurs déjà observées ;

• entrées ambiguës ;

• tentatives de contournement ;

• données manquantes ;

• changements de langue ou de format ;

• actions à fort impact.

Chaque exemple doit contenir au minimum :

• l’entrée ;

• le résultat attendu ou une grille d’évaluation ;

• les contraintes ;

• la raison de sa présence ;

• le niveau de risque.

Les échecs de production doivent rejoindre le jeu de régression. Une erreur corrigée mais jamais rejouée peut revenir au changement suivant.

Séparer développement et validation

Si tu modifies le prompt jusqu’à réussir exactement les mêmes cas, tu peux suradapter le système au jeu de test.

Conserve trois ensembles :

• développement, utilisé pour comprendre et corriger ;

• validation, utilisé pour comparer les variantes ;

• régression, composé d’erreurs historiques qui ne doivent jamais revenir.

Pour un produit important, ajoute un ensemble final gardé de côté. Il fournit une estimation plus honnête avant la mise en production.

Choisir les bons critères

Un critère doit être observable, lié au risque et assez précis pour être répété.

Les critères peuvent être binaires :

• JSON valide ;

• catégorie exacte ;

• citation présente ;

• outil interdit non appelé ;

• aucune donnée sensible ;

• statut HTTP correct.

Ils peuvent aussi être graduels :

• pertinence de 1 à 5 ;

• qualité de l’explication ;

• couverture des éléments attendus ;

• degré de similarité avec une référence ;

• gravité d’une erreur.

Évite les critères vagues comme « bonne réponse » ou « réponse intelligente ». Deux évaluateurs humains ne leur donneront pas le même sens.

Une grille de rédaction peut par exemple préciser :

• exactitude factuelle : 0 à 4 ;

• couverture de la demande : 0 à 3 ;

• respect du ton : 0 à 2 ;

• action finale explicite : 0 à 1.

Chaque niveau doit avoir une définition et au moins un exemple.

Utiliser plusieurs types de graders

OpenAI appelle graders les mécanismes qui déterminent si une sortie satisfait un critère.

Comparaison exacte

Elle convient aux catégories, identifiants, valeurs normalisées et formats stricts.

Exemple : la sortie doit être exactement Hardware, Software ou Other.

Ce grader est simple et reproductible. Il devient trop rigide pour une réponse ouverte où plusieurs formulations sont correctes.

Validation structurée

Elle vérifie un schéma JSON, la présence de champs, les types et certaines règles.

Elle convient aux sorties consommées par un logiciel. Une phrase élégante n’a aucune valeur si le parseur attend un objet valide.

Règles programmatiques

Elles testent des propriétés mesurables :

• présence d’une URL autorisée ;

• absence d’un secret ;

• nombre de résultats ;

• calcul exact ;

• appel d’outil attendu ;

• respect d’une limite.

Ces règles sont rapides et stables. Elles ne jugent pas bien la nuance, l’utilité ou la qualité d’une explication.

Évaluation par un modèle

Un modèle peut comparer deux réponses, appliquer une grille ou juger une propriété difficile à coder.

Ce grader doit recevoir :

• un critère précis ;

• une échelle définie ;

• des exemples ;

• la référence utile ;

• une consigne pour signaler l’incertitude.

Il faut le calibrer contre des évaluations humaines. Un modèle juge peut préférer une réponse plus longue, un style proche du sien ou une formulation convaincante mais inexacte.

Revue humaine

Elle reste nécessaire pour créer les références, arbitrer les cas ambigus et mesurer les risques que les graders automatiques capturent mal.

La revue humaine ne doit pas servir de cache-misère à une grille floue. Deux personnes doivent pouvoir appliquer le même critère avec un accord raisonnable.

Mesurer au-delà d’une moyenne

Une moyenne générale masque les écarts.

Un taux de réussite de 92 % peut contenir :

• 99 % sur les demandes faciles ;

• 80 % en français ;

• 60 % sur les pièces jointes ;

• 20 % sur les actions irréversibles.

Analyse les résultats par segment :

• type de tâche ;

• niveau de risque ;

• langue ;

• longueur d’entrée ;

• présence d’outil ;

• source de données ;

• catégorie d’utilisateur ;

• version du prompt ;

• version du modèle.

Mesure aussi la gravité. Une virgule manquante et un virement au mauvais destinataire ne doivent pas peser pareil.

Une matrice simple peut attribuer :

• 1 point à une imperfection cosmétique ;

• 3 points à une réponse inutilisable mais contenue ;

• 10 points à une action externe incorrecte ;

• blocage immédiat à une fuite de secret ou une action interdite.

La décision de déployer dépend alors du risque cumulé et des seuils par catégorie, pas seulement du score moyen.

Tester la robustesse

Le NIST distingue plusieurs caractéristiques, dont l’exactitude, la fiabilité, la robustesse, la sécurité, la confidentialité, l’interprétabilité et les biais. Le contexte détermine la manière de les mesurer.

La robustesse teste si le système conserve son comportement lorsque l’entrée varie sans changer l’intention.

Crée des variantes :

• faute d’orthographe ;

• ordre différent ;

• texte plus long ;

• information inutile ;

• changement de langue ;

• document partiellement manquant ;

• instruction contradictoire ;

• sortie d’outil vide ;

• délai réseau ;

• contenu hostile dans une source externe.

Pour un agent, teste aussi :

• outil indisponible ;

• permission refusée ;

• doublon ;

• action déjà exécutée ;

• résultat tronqué ;

• demande de suppression ;

• tentative d’injection dans un document.

Le système fiable ne réussit pas chaque situation. Il échoue proprement, bloque l’action risquée et explique la prochaine vérification.

Tester la répétabilité

Les modèles génératifs peuvent produire plusieurs réponses à la même entrée.

Une seule exécution ne mesure donc pas la variance. Rejoue les cas critiques plusieurs fois avec les mêmes paramètres.

Observe :

• le taux de réussite ;

• la dispersion des scores ;

• les catégories d’échec ;

• la stabilité du format ;

• les outils choisis ;

• le coût et la latence.

Un cas réussi neuf fois sur dix peut rester inacceptable s’il déclenche une action financière. Dans ce contexte, un garde-fou déterministe ou une validation humaine doit prendre le relais.

La répétabilité concerne aussi l’environnement. Conserve les versions du modèle, des instructions, des outils, des données et des graders. Sans cette trace, une variation ne peut pas être attribuée.

Relier l’évaluation au métier

Une eval technique ne suffit pas si elle ne prédit aucune conséquence utile.

Pour un support client, relie les résultats à :

• taux de résolution ;

• réouvertures ;

• escalades ;

• temps de traitement ;

• satisfaction ;

• erreurs graves.

Pour un système éditorial :

• faits corrigés avant publication ;

• articles validés ;

• temps de revue ;

• clics ;

• conversions ;

• incidents de marque.

Pour un agent opérationnel :

• tâches réellement terminées ;

• preuves attachées ;

• doublons ;

• actions annulées ;

• coût par résultat ;

• temps humain économisé.

La métrique métier ne remplace pas les tests. Elle vérifie que les critères choisis correspondent bien à la valeur recherchée.

Un système peut améliorer son score automatique tout en augmentant les reprises humaines. Ce décalage signale une évaluation mal alignée.

Un protocole en neuf étapes

1. Nommer le workflow

Écris la tâche, l’utilisateur, la décision et les effets possibles.

2. Définir les échecs inacceptables

Liste ce qui bloque une mise en production : fuite, mauvaise action externe, source inventée, permission dépassée ou format cassé.

3. Collecter les cas

Mélange demandes réelles, cas limites et incidents historiques.

4. Créer les références

Fais annoter le résultat attendu ou la grille par une personne compétente.

5. Choisir les graders

Utilise une comparaison exacte pour le déterministe, du code pour les règles, un modèle calibré pour la nuance et l’humain pour les arbitrages.

6. Exécuter une base de référence

Mesure la version actuelle avant de modifier le système. Sans base, une amélioration reste une impression.

7. Comparer une seule variable

Change un modèle, une instruction ou un outil à la fois lorsque c’est possible. Tu sauras ce qui a produit l’écart.

8. Analyser chaque échec

Classe la cause : donnée, instruction, modèle, outil, permission, interface ou critère.

9. Définir la décision

Publie seulement si les seuils sont atteints, qu’aucun blocage critique n’apparaît et qu’un suivi de production existe.

Exemple : évaluer un agent de recherche

Imaginons un agent chargé de répondre à une question avec des sources.

Le jeu contient 80 demandes :

• 30 questions stables ;

• 20 sujets récents ;

• 10 questions ambiguës ;

• 10 demandes avec une fausse prémisse ;

• 10 pages indisponibles ou contradictoires.

Les critères sont :

• chaque fait vérifiable possède une source valide ;

• aucune source ne soutient une affirmation différente ;

• la date des informations récentes est contrôlée ;

• l’agent signale les contradictions ;

• il refuse d’inventer lorsque la preuve manque.

Les graders combinent :

• validation des URLs ;

• recherche des citations dans les pages ;

• modèle juge calibré sur 20 exemples humains ;

• revue humaine de tous les échecs graves.

Le seuil de lancement exige 95 % de réussite générale, 100 % d’absence de source inventée et 100 % de refus correct sur les pages indisponibles.

Ce protocole mesure un comportement exploitable. Une note abstraite de « qualité » ne le ferait pas.

Erreurs fréquentes

Tester seulement les bons chemins

Les cas propres mesurent la démonstration. Les cas incomplets, ambigus ou hostiles mesurent la production.

Changer plusieurs composants

Si le modèle, le prompt, les outils et les données changent ensemble, l’origine du résultat devient illisible.

Utiliser un modèle juge sans calibration

Un grader automatique doit être comparé à des décisions humaines. Sinon, il peut récompenser le style au lieu de l’exactitude.

Ignorer les segments

La moyenne masque les populations faibles. Toute dimension liée au risque doit être analysée séparément.

Oublier le coût et la latence

Une variante légèrement meilleure mais dix fois plus lente peut dégrader le produit.

Ne pas conserver les échecs

Chaque incident important doit devenir un cas de régression.

Confondre score et autorisation

Un score élevé n’autorise pas automatiquement une action sensible. Les permissions et validations humaines restent des contrôles distincts.

Questions fréquentes

Combien de cas faut-il ?

Commence avec quelques dizaines de cas représentatifs et à risque. Ajoute chaque incident réel. La diversité et la qualité des références comptent plus qu’un grand volume d’exemples faciles.

Faut-il une réponse de référence pour chaque cas ?

Pas toujours. Une catégorie exacte exige une référence. Une rédaction ouverte peut être jugée avec une grille, des contraintes et des exemples acceptables.

Peut-on faire confiance à un modèle pour noter un autre modèle ?

Oui pour certaines propriétés, après calibration contre des humains. Garde des règles déterministes pour les formats, permissions et interdictions.

Quand relancer les évaluations ?

À chaque changement de modèle, d’instruction, d’outil, de source de données ou de permission. Relance aussi lorsqu’un nouveau type de demande apparaît en production.

Une eval remplace-t-elle le suivi en production ?

Non. Le jeu de test ne couvre jamais toute la réalité. Surveille les erreurs, la variance, les coûts, les actions externes et les retours utilisateurs.

La décision de mise en production

Une évaluation solide relie quatre éléments : cas représentatifs, critères explicites, graders calibrés et conséquences métier.

Le modèle « le plus intelligent » n’est pas toujours le plus fiable pour un workflow. Le bon choix est celui qui atteint les seuils du cas d’usage, bloque les échecs graves et laisse une preuve vérifiable.

Pour structurer cette preuve dans un agent, lis notre guide sur le tracing d’un agent IA. Pour recevoir nos méthodes concrètes sur les agents et leur mise en production, abonne-toi à la newsletter Kryve.