Évaluer la qualité des sorties IA : la méthode du jeu d'évaluation

Vous avez branché une IA sur un vrai processus : la qualification de vos leads entrants, la rédaction de vos réponses support, l'extraction de données dans vos documents. En démonstration, elle a répondu juste trois fois de suite. Tout le monde a hoché la tête. Vous avez mis en production.

Deux mois plus tard, personne dans l'équipe ne sait dire si ça marche. On sait juste qu'une commerciale a vu passer une réponse absurde la semaine dernière, et que le prestataire a « amélioré le prompt » entre-temps. Vous n'avez ni avant, ni après, ni mesure. Vous avez une impression. Cet article explique comment évaluer la qualité des sorties IA avec une méthode plutôt qu'avec un ressenti : le jeu d'évaluation.

Un jeu d'évaluation, c'est quoi exactement ?

Un jeu d'évaluation est un ensemble figé de cas de test, chacun composé d'une entrée réelle et de la réponse attendue (ou des critères que la réponse doit satisfaire). C'est l'instrument de base pour évaluer la qualité des sorties IA autrement qu'au ressenti. On le rejoue à l'identique chaque fois que l'on modifie quelque chose : le prompt, le modèle, les documents fournis en contexte, les règles métier. Le résultat n'est pas une opinion, c'est un score comparable dans le temps.

C'est exactement l'équivalent, pour une IA, de ce qu'est une suite de tests pour un logiciel. La différence tient à une particularité : une IA est non déterministe. Posez deux fois la même question, vous pouvez obtenir deux formulations différentes. C'est précisément pour ça qu'un essai isolé ne prouve rien, et qu'il faut mesurer sur un volume de cas plutôt que sur une anecdote.

Trois éléments composent un jeu d'évaluation utilisable :

• Les cas : des entrées issues de votre activité réelle, pas des exemples inventés pour la démonstration.
• L'attendu : pour chaque cas, la bonne réponse, ou la liste des conditions qu'une bonne réponse doit remplir.
• La règle de notation : comment on décide qu'une sortie passe ou ne passe pas, de façon reproductible par une autre personne que vous.

Sans le troisième élément, vous n'avez pas un jeu d'évaluation : vous avez une collection d'exemples. La différence se voit le jour où deux personnes notent la même sortie et ne sont pas d'accord.

Le piège : juger la qualité sur trois essais réussis en démonstration

C'est l'erreur la plus fréquente, et la plus coûteuse. Elle a trois causes qui se cumulent.

Première cause : la sélection des cas. Quand vous testez à la main, vous tapez spontanément des cas que vous comprenez bien, donc des cas standards. Les entrées bancales, incomplètes, mal orthographiées, hors périmètre, celles qui remplissent en réalité une boîte de messagerie ou un formulaire de contact, ne vous viennent pas à l'esprit. Vous testez le beau temps.

Deuxième cause : la variance. Sur un cas donné, une IA peut répondre juste une fois et approximatif la suivante. Trois succès d'affilée sur trois cas différents ne vous disent rien sur la stabilité. Ce que vous voulez connaître, ce n'est pas le meilleur résultat possible, c'est le résultat que vous obtenez de façon fiable, y compris un mardi soir sur un dossier tordu.

Troisième cause : le biais du démonstrateur. Celui qui présente a itéré. Il a formulé sa question de la façon qui marche. En production, ce sont vos collaborateurs ou vos clients qui écrivent, et personne ne leur a transmis la formulation qui fonctionne.

Le symptôme est toujours le même : personne ne peut répondre à la question « est-ce que c'est mieux qu'il y a un mois ? ». Si vous voulez creuser le sujet côté formulation des instructions, notre article sur le prompt engineering appliqué au business montre pourquoi un prompt qui fonctionne en démonstration se comporte différemment sur du volume.

Construire votre jeu d'évaluation à partir de vos vrais cas métier

La bonne nouvelle : vous n'avez rien à inventer. Vos cas de test existent déjà dans votre historique. Tickets support traités, emails entrants, devis passés, fiches CRM, transcriptions d'appels. Vous prenez du réel, et vous figez.

La méthode tient en quatre étapes.

1. Extraire un échantillon représentatif. Sortez des entrées réelles de vos trois derniers mois. Ne prenez pas les plus propres : prenez ce qui est arrivé, dans les proportions où c'est arrivé. Anonymisez ce qui doit l'être avant de le mettre dans un fichier de test.
2. Équilibrer les familles de cas. Un bon jeu contient quatre catégories : les cas standards (le cœur du volume), les cas limites (une information manque, la demande est ambiguë), les cas piégeux (deux clients au même nom, une date au mauvais format, une demande qui ressemble à une autre) et les cas où l'IA doit refuser ou escalader vers un humain.
3. Écrire l'attendu avec la personne qui fait le travail aujourd'hui. Pas avec le prestataire, pas avec vous seul. Celui qui traite ces dossiers depuis deux ans sait ce qu'est une bonne réponse. C'est un atelier d'une demi-journée, pas un projet.
4. Geler le jeu. Une fois écrit, on n'y touche plus, sauf pour ajouter des cas. Un jeu qu'on modifie à chaque test ne mesure plus rien.

Sur le volume : commencez petit et honnête. Quelques dizaines de cas bien choisis valent mieux que des centaines de cas approximatifs que personne ne relira. Vous en ajouterez au fil des incidents. Règle de terrain : chaque fois qu'une sortie fausse arrive en production, elle entre dans le jeu d'évaluation le jour même. C'est le mécanisme qui fait que le même problème ne revient pas deux fois.

Dernier point, décisif : ces cas ne doivent jamais se retrouver dans le prompt, ni dans les exemples fournis au modèle. Sinon vous ne mesurez plus une capacité, vous mesurez une récitation.

Les quatre critères à mesurer sur chaque sortie

« C'est bien » n'est pas un critère. Voici les quatre dimensions à séparer, parce qu'elles cassent indépendamment les unes des autres et ne se corrigent pas de la même façon.

1. L'exactitude factuelle. Les informations produites sont-elles vraies et présentes dans les sources fournies ? C'est ici que se logent les inventions : un montant plausible mais faux, une référence produit qui n'existe pas, une date décalée. Mesure : on compare aux données de référence, champ par champ. C'est le critère le plus important et le plus souvent négligé, parce que la sortie est bien écrite et que la forme rassure.

2. La conformité de format. La sortie respecte-t-elle la structure attendue ? Champs obligatoires présents, types corrects, valeurs prises dans la liste autorisée, longueur dans les clous. Bonne nouvelle : ce critère se teste automatiquement, sans jugement humain. C'est aussi celui qui casse silencieusement vos automatisations en aval quand il dérive.

3. Le ton et le registre. Vouvoiement, niveau de langue, interdictions de vocabulaire, formules à ne pas employer, promesses commerciales à ne pas faire. Si l'IA écrit à vos clients, c'est votre marque qui parle. Ce critère se contrôle avec une grille explicite : trois à cinq points vérifiables, pas une notion floue de « ton adapté ».

4. Les refus attendus. Le critère que presque personne ne teste, et souvent le plus risqué. Que fait votre IA quand elle ne sait pas, quand la demande sort du périmètre, quand on lui demande un engagement juridique, un prix négocié, un conseil médical ? Le comportement correct est de refuser ou d'escalader. Une IA qui répond toujours n'est pas performante, elle est dangereuse. Mettez des cas de refus dans votre jeu et notez-les comme les autres.

Qui note, et comment : automatique, humain ou IA juge

Une évaluation qui demande trois jours de travail à chaque changement ne sera jamais refaite. L'enjeu est de rendre la notation économique. Trois niveaux, à empiler dans cet ordre.

Niveau 1 : les vérifications automatiques et déterministes. Format, présence des champs, valeurs autorisées, longueurs, présence ou absence de mots précis, égalité stricte avec une valeur de référence quand elle existe (un montant, un identifiant, une catégorie). C'est du code simple, ça tourne en quelques secondes, et ça attrape une grande partie des régressions. Commencez toujours par là.

Niveau 2 : la notation humaine sur échantillon. Pour l'exactitude nuancée et le ton, un humain reste la référence. Mais il ne relit pas tout : il relit un échantillon tiré au hasard, avec une grille de notation binaire (conforme ou non conforme, critère par critère). Une notation binaire est reproductible ; une note sur 10 ne l'est pas d'une personne à l'autre.

Niveau 3 : l'IA juge. Vous pouvez demander à un modèle d'évaluer les sorties d'un autre selon votre grille. C'est utile pour passer à l'échelle, à une condition non négociable : calibrer le juge contre l'humain. Vous faites noter le même échantillon par la personne métier et par le juge, vous comparez les désaccords, vous corrigez la grille. Un juge non calibré donne des scores rassurants et faux, ce qui est pire que pas de score du tout.

Ce triage est le même que celui à appliquer sur toute la chaîne de production : voir notre article sur la façon de fiabiliser les sorties d'une IA en production.

Détecter une régression après un changement de prompt ou de modèle

C'est la vraie raison d'exister d'un jeu d'évaluation. Une IA en production n'est jamais figée : vous ajustez le prompt, votre fournisseur met à jour son modèle, vous changez de version pour réduire le coût, vos documents de référence évoluent. Chacun de ces changements peut améliorer un critère et en dégrader un autre, sans que personne ne le voie.

La mécanique tient en cinq points.

• Établissez une référence. Faites tourner le jeu complet avant tout changement et enregistrez le score par critère. C'est votre point de comparaison. Sans référence, vous ne pourrez jamais prouver une amélioration, ni une dégradation.
• Ne changez qu'une chose à la fois. Nouveau prompt et nouveau modèle en même temps, et vous ne saurez pas lequel a produit l'effet.
• Comparez critère par critère, jamais en score global. Un score moyen stable peut cacher un effondrement sur les refus attendus compensé par un gain sur le format. Le score global est l'ennemi du diagnostic.
• Fixez un seuil de blocage à l'avance. Par exemple : aucune mise en production si l'exactitude factuelle recule, ou si un seul cas de refus attendu échoue. Décidé à froid, ce seuil vous évite les arbitrages de dernière minute sous pression de calendrier.
• Regardez les cas qui ont basculé. Le chiffre vous dit qu'il y a un problème, la liste des cas qui passaient et ne passent plus vous dit lequel. C'est là que se trouve l'information utile.

Un cas particulier mérite votre attention : les changements que vous ne décidez pas. Quand un fournisseur met à jour son modèle, votre comportement change sans que vous ayez touché à quoi que ce soit. Rejouer le jeu d'évaluation à intervalle régulier, même sans modification de votre côté, est le seul moyen de le détecter avant vos clients.

Faire vivre l'évaluation sans y passer vos semaines

Un jeu d'évaluation ne coûte cher qu'une fois : à la construction. Ensuite, c'est de l'exécution. Pour que ça tienne, trois conditions.

Un propriétaire nommé. Une personne responsable du jeu, de son enrichissement et de la décision de mise en production. Si c'est « l'équipe », ce sera personne.

Une cadence claire. Le jeu tourne à chaque modification, et à date fixe même sans modification (une fois par mois est un rythme raisonnable pour la plupart des usages internes). Les résultats sont archivés, pas commentés en réunion puis oubliés.

Un lien explicite avec la valeur. Un score de qualité qui ne se traduit pas en euros ou en heures gagnées finira par ne plus intéresser personne. Rattachez vos critères à l'impact métier : combien de dossiers repassent par un humain, combien de corrections manuelles, combien de temps par dossier. C'est le raccord avec la question du ROI de l'IA en entreprise, et c'est ce qui rend l'exercice défendable en comité de direction.

Un dernier bénéfice, moins évident. Construire un jeu d'évaluation vous oblige à écrire ce qu'est une bonne réponse. Beaucoup d'organisations découvrent à ce moment-là que leurs experts ne sont pas d'accord entre eux sur le traitement correct d'un dossier, et que le problème n'était pas l'IA mais le processus. C'est un effet secondaire fréquent, et souvent plus rentable que le projet lui-même : voir ce que l'IA révèle de vos process.

Chez Growth Consult, nous accompagnons des PME et des scale-ups sur ce type de chantier depuis 2012, avec 280 entreprises formées ou accompagnées. Le constat ne varie pas : les projets IA qui tiennent en production ne sont pas ceux qui ont le meilleur prompt. Ce sont ceux qui ont une mesure. La croissance ne se hacke pas. Elle se construit, et la fiabilité aussi.

La règle des 4 familles de cas. Un jeu d'évaluation utilisable contient toujours : des cas standards (le volume quotidien), des cas limites (information manquante, demande ambiguë), des cas piégeux (homonymes, formats inhabituels, demandes qui se ressemblent) et des cas où l'IA doit refuser ou escalader. Si votre jeu ne contient que la première famille, vous mesurez le beau temps.