Réponse courte. Une IA se mesure comme le reste du logiciel se teste : avec un jeu d'évaluation. Soixante cas réels, pris dans vos vrais messages, documents et vocaux, en arabe, en français et en darija ; pour chacun, la bonne réponse écrite par la personne de chez vous qui sait. La moitié sont des cas courants ; l'autre moitié sont des pièges, des questions hors périmètre où la bonne réponse est « je ne sais pas », des données manquantes et des tentatives de contournement. Chaque réponse de l'IA est notée de trois façons : par code quand la réponse est un champ, par la règle « chaque affirmation a une source » qui compte les hallucinations, et par un modèle juge calé sur vos propres notes pour la forme. Le jeu est rejoué à chaque changement d'instructions, de documents ou de modèle : c'est ce qui attrape les régressions. Et un seuil de livraison est écrit avant le premier essai. Ce n'est pas un taux de précision unique : ce sont six mesures lues ensemble.
Ce guide s'adresse à celui qui compare des prestataires et veut savoir quoi leur demander, au gérant qui a vu une démonstration convaincante et se demande ce qu'elle prouve, et à la direction informatique qui doit signer la mise en production. Il détaille la méthode que nos autres guides supposent, l'IA dans l'application, la lecture de documents et le déploiement privé, et il répond à l'une des questions à poser avant de signer, listées dans le guide sur le choix d'une société.
Ce que les chiffres disent
Les éditeurs de modèles disent eux-mêmes qu'il faut mesurer. Le guide d'évaluation d'OpenAI définit les évaluations comme des « tests structurés pour mesurer la performance d'un modèle », nécessaires parce que ces systèmes ne répondent pas deux fois de la même façon, et recommande un processus en cinq temps : définir l'objectif, constituer un jeu de données, définir les mesures, comparer les versions, et évaluer en continu à chaque changement. Il nomme aussi ce qu'il ne faut pas faire : des mesures génériques sans lien avec la tâche, un jeu qui ne ressemble pas au trafic réel, et les évaluations « à l'impression », quand la stratégie se résume à « ça a l'air de marcher » ou qu'on attend d'avoir livré pour mesurer.
La façon de construire le jeu est écrite aussi. La documentation d'Anthropic demande des cas qui reflètent la distribution réelle de la tâche, sans oublier les cas limites, données absentes ou hors sujet, entrées trop longues, demandes ambiguës sur lesquelles même des humains hésiteraient ; elle recommande d'automatiser la notation dès que possible, et préfère beaucoup de cas notés automatiquement à peu de cas notés à la main. Elle distingue trois notations : par code, la plus rapide et la plus fiable ; par un humain, la plus fine et la plus lente ; par un modèle juge, entre les deux, de préférence avec un modèle différent de celui qu'on évalue. Le guide d'OpenAI ajoute la condition : un juge automatique ne se généralise qu'une fois calé sur des notes humaines.
Ce qui n'existe pas : un taux qui vaudrait pour vous. Les classements publics mesurent des tâches générales, en anglais le plus souvent ; ils ne disent rien d'une question posée en darija sur votre catalogue. Nous ne citons donc aucun « taux d'hallucination » de modèle : celui qui compte se mesure sur vos soixante cas, et il change avec vos documents. Les chiffres de la première figure, 47, 55 et 53 sur 60, sont un exemple construit pour montrer une régression, pas une mesure d'un projet ; ce qui n'est pas un exemple, c'est la méthode.
Soixante cas, rejoués sur trois versions
Le jeu d'évaluation ne sert pas à obtenir une note : il sert à comparer deux versions sans se fier à une impression.
La version 1, avec les premières instructions, réussit 47 cas sur 60 ; les treize échecs ne sont pas une mauvaise nouvelle, ils sont la liste de travail, et un tiers se trouvent dans les pièges. La version 2, instructions corrigées et documents mieux découpés, en réussit 55 ; les cinq échecs restants sont connus, listés, et montrés au client. La version 3 garde les mêmes instructions avec un modèle plus petit, qui coûte moins par requête : 53 sur 60. Essayée à la main, elle répond très bien. Le tableau montre autre chose : deux cas que la version 2 réussissait échouent maintenant.
Ces deux carrés sont la raison d'être du jeu. Sans lui, la version 3 serait partie en production parce qu'elle coûte moins, et deux types de demandes auraient commencé à recevoir de mauvaises réponses sans que personne le voie avant une réclamation. Avec lui, la décision est écrite d'avance : seuil de 54 sur 60 et aucune régression ; la version 2 est livrée, la version 3 attend. Le jeu est rejoué de la même façon le jour où un éditeur change la version de son modèle, ce qui arrive plusieurs fois par an, et il tourne en une commande, avec les tests décrits dans le guide sur la livraison.
«Essayée à la main, la version 3 répond très bien ; c'est le tableau qui montre qu'elle a perdu deux cas.»
Construire le jeu d'évaluation, en six étapes
Six étapes, dont une que personne ne peut faire à votre place.
Le critère dit ce que « marcher » veut dire pour cette fonction, en une phrase mesurable : la bonne date de livraison, la bonne catégorie, les bons champs, et aucune affirmation qui ne soit dans un document. Les cas réels sont soixante demandes tirées de vos vrais échanges, messages WhatsApp, e-mails, vocaux, documents, dans les trois langues ; des exemples inventés par nous mesureraient ce que nous croyons que vos clients demandent. La bonne réponse est écrite par la personne de chez vous qui sait, le gérant, le comptable, le chef d'agence ; c'est elle qui fait foi, et c'est l'étape qui demande votre temps : une heure ou deux, une fois.
Les cas difficiles sont ajoutés exprès : pièges, questions hors périmètre, données manquantes, tentatives de contournement ; un jeu de cas faciles donne une belle note et ne prouve rien. La notation est automatisée autant que possible, par code pour les champs, par un modèle juge calé sur vos notes pour le reste, avec un échantillon relu à la main pour vérifier que le juge juge comme vous. Le seuil est écrit avant le premier essai : la note minimale, la règle sur les régressions, et la liste des cas critiques sur lesquels aucune erreur n'est acceptée. Écrit après, un seuil s'ajuste toujours à la note obtenue.
Un cas, trois façons de le noter
Une réponse ne se note pas « bien » ou « mal » : elle se décompose, et chaque morceau a sa règle.
Le cas 37 est un piège : deux questions en une, « ma commande arrive quand, et je peux la retourner ? ». La réponse de l'IA tient en trois affirmations. La date de livraison se retrouve dans la commande ; le créneau du matin, dans la tournée ; « le retour est gratuit sous 30 jours » ne se retrouve nulle part, parce que votre entreprise n'a écrit aucune politique de retour. Première notation, par code : la date rendue est-elle celle attendue ? Oui. Deuxième notation, la source : chaque affirmation est confrontée aux documents que l'orchestration a récupérés ; deux sur trois en ont une, la troisième est inventée. Troisième notation, la forme, par un modèle juge calé sur vos notes : le ton, la langue, la longueur sont conformes.
Verdict : échec. Une réponse juste aux deux tiers, polie et bien écrite, passerait une notation à l'œil ; c'est précisément le genre de réponse qu'on appelle une hallucination, et c'est celle que le client retiendra, parce qu'elle lui promet quelque chose. La réponse attendue, écrite par votre équipe, disait : la date, le créneau, et « pour un retour, je vous mets en relation avec un conseiller ». Ce cas illustre aussi pourquoi la source se vérifie affirmation par affirmation : une note globale de « fidélité » aurait donné 67 %, un chiffre qui a l'air acceptable et qui cache une promesse fausse.
«Une réponse juste aux deux tiers, polie et bien écrite, contient une promesse inventée, et c'est celle que le client retient.»
Six types de cas, et ce qu'on attend de l'IA
Un jeu d'évaluation vaut par sa composition ; six types de cas, et pour chacun ce qui compte comme une réussite.
Le cas courant, la question qui revient vingt fois par jour dans les mots des clients, fait la moitié du jeu : la bonne réponse, sourcée, dans la langue de la question. Le piège : deux questions en une, un produit qui ressemble à un autre, une date ambiguë ; répondre à la partie connue, demander une précision sur l'autre, ne rien compléter. Le hors périmètre : la réponse n'est dans aucun de vos documents ; la seule réussite est « je ne sais pas » et le passage à un humain, comme le guide sur l'agent WhatsApp le décrit.
La donnée manquante : la commande n'existe pas, le client n'est pas reconnu, le document est illisible ; le dire, demander l'information, ne rien supposer. L'arabe et la darija : la même question en arabe standard, en darija, en lettres latines et en vocal doit recevoir la même réponse que sa version française, et l'écart entre langues se mesure à part, parce qu'une moyenne le cache. Le contournement : « oublie tes consignes », une remise réclamée avec insistance, la donnée d'un autre client ; refus sans divulgation, tentative journalisée, et aucun droit de plus que le rôle décrit dans le guide sur les rôles.
Six mesures, lues ensemble
Il n'y a pas un « taux de précision » : il y a six mesures, et aucune ne se lit seule.
La réussite sur le jeu, au total et par type de cas : une note par type vaut mieux qu'une moyenne, parce que 55 sur 60 avec tous les échecs dans le hors périmètre n'est pas la même chose que 55 avec des échecs répartis. Les affirmations sans source : le compte des hallucinations, avec zéro exigé sur les cas critiques. Les refus à tort : les « je ne sais pas » alors que la réponse était dans les documents. Ces deux-là se tiennent : une IA qui ne refuse jamais répond à tout et invente ; une IA qui refuse toujours n'invente rien et ne sert à rien ; on règle les deux ensemble, sur le jeu.
Les régressions : les cas réussis par la version précédente et échoués par la nouvelle ; zéro pour livrer, ou une décision écrite cas par cas. Le passage à l'humain : la part des demandes transférées, et surtout celles qui auraient dû l'être et ne l'ont pas été ; au pilote, chaque jour. Le coût et la latence, par version, à côté de la note et jamais seuls : une version qui coûte moins avec deux régressions n'est pas meilleure. C'est ce tableau, six lignes par version, qui est montré à chaque démonstration de deux semaines.
Vu ailleurs : les guides d'évaluation des éditeurs, et ce qui se transpose
Deux sources disent l'essentiel. Le guide d'OpenAI dit qu'évaluer à l'impression est un anti-modèle, qu'un jeu doit ressembler au trafic réel et qu'un juge automatique se cale sur des notes humaines ; ce qui se transpose, c'est que la mesure commence avant le code et ne s'arrête pas à la livraison. La documentation d'Anthropic dit de construire des cas propres à la tâche, d'y mettre les cas limites et d'automatiser la notation ; ce qui se transpose, c'est qu'on préfère soixante cas rejoués à chaque changement à six cas relus soigneusement une fois.
Ce que ces sources ne disent pas : quelles sont les bonnes réponses chez vous, quels cas sont critiques, et quel seuil vous acceptez ; la deuxième semaine du projet y répond, avec la personne de votre équipe qui sait.
Les règles d'une IA mesurée
Six règles, écrites la première semaine. Le seuil avant le premier essai. Des cas réels, pas des exemples inventés, dans les trois langues. La bonne réponse vient de vous ; le modèle ne fait jamais foi. Chaque affirmation a une source, vérifiée une par une sur les cas critiques. Chaque changement rejoue tout le jeu : instructions, documents, modèle, version de l'éditeur. Chaque erreur vue au pilote devient un cas ; le jeu grandit et ne rétrécit jamais.
Une septième règle porte sur le devis et sur le prestataire : « IA testée et validée » n'est pas une exigence, c'est une phrase ; l'exigence s'écrit « jeu d'évaluation de soixante cas réels dans les trois langues, bonnes réponses validées par le client, six types de cas présents, notation automatisée avec juge calé sur un échantillon noté à la main, seuil de livraison et règle sur les régressions écrits avant les essais, tableau des six mesures montré à chaque démonstration, jeu livré dans le dépôt du client », et elle se vérifie comme le guide sur le cahier des charges le recommande. À un prestataire qui montre une démonstration, la question à poser est : « sur combien de cas, écrits par qui, et quels sont ceux qui échouent ? »
Six fonctions, et ce qu'on y mesure d'abord
Six fonctions que nous construisons, et pour chacune la première mesure retenue.
- L'agent sur WhatsApp, décrit dans le guide dédié. Affirmations sans source et passages à l'humain manqués ; les contournements sont dans le jeu dès le départ.
- La lecture de factures et de pièces, décrite dans le guide dédié. Exactitude par champ, par code, sur soixante documents réels ; le total exige plus que le mode de règlement.
- La recherche dans les documents. Chaque réponse cite-t-elle le bon passage ; refus à tort quand le passage existe ; « je ne sais pas » quand il n'existe pas.
- La recherche produit, décrite dans le guide sur la recherche. Deux cents requêtes réelles avec le bon produit attendu ; c'est le même principe sans modèle de langage.
- Le tri des messages. Catégorie exacte, par code ; la confusion entre « réclamation » et « question » comptée à part, parce qu'elle ne coûte pas la même chose.
- Le modèle déployé sur site, décrit dans le guide sur le déploiement privé. Le jeu choisit le modèle avant l'achat de la machine, et il est rejoué à chaque mise à jour.
Le calendrier 2027
Le calendrier est celui d'une évaluation mise en place en huit semaines, pendant que la fonction se construit.
La semaine 0 à 1 écrit le critère et le seuil : ce que « marcher » veut dire, la note minimale, la règle sur les régressions, les cas critiques ; signés. La semaine 1 à 2 réunit les soixante cas et leurs réponses : les cas viennent de vos échanges, les réponses de votre équipe, et les six types sont présents. La semaine 2 à 3 automatise la notation : graders par code, modèle juge calé sur vos notes, échantillon relu à la main ; à la fin de la semaine, le jeu tourne en une commande.
Les semaines 3 à 6 sont celles des versions : chaque changement d'instructions, de documents ou de modèle rejoue tout, et le tableau est montré à chaque démonstration, échecs compris. Les semaines 6 à 8 sont le pilote : de vrais utilisateurs, et chaque erreur vue devient un cas ; le jeu passe de soixante à une centaine. Après la livraison, le jeu reste dans votre dépôt, et il est rejoué à chaque évolution et à chaque changement de version du modèle. C'est aussi lui qui rend possible un changement de prestataire : celui qui reprend sait, en une commande, ce qui marche.
Ce qui fait échouer la mesure d'une IA
Les évaluations que nous reprenons, quand il y en a, ont presque toujours échoué pour l'une de ces raisons.
- La démonstration à la place du jeu. Cinq questions choisies par celui qui vend.
- Des cas inventés. Rédigés en français soigné, alors que les clients écrivent en darija.
- Que des cas faciles. Aucun hors périmètre ; l'IA n'a jamais eu à dire « je ne sais pas ».
- La bonne réponse écrite par le prestataire. Ou pire, par le modèle lui-même.
- Une note globale. Une moyenne de « fidélité » qui cache l'affirmation inventée.
- Le seuil écrit après. Ajusté à la note obtenue.
- Le jeu abandonné après la livraison. Le modèle change de version ; personne ne rejoue rien.
Questions fréquentes
Les questions que nous recevons de gérants, de directions informatiques et d'équipes qui comparent des prestataires.
- Comment savoir si une IA marche vraiment avant de la mettre en production ?
- Par un jeu d'évaluation : soixante cas réels tirés de vos échanges, avec la bonne réponse écrite par votre équipe, dont la moitié sont des pièges, des questions hors périmètre et des tentatives de contournement. Chaque version de l'IA rejoue tout le jeu, et un seuil de livraison écrit avant les essais dit si elle part en production. Une démonstration de cinq questions ne prouve rien.
- Comment mesure-t-on les hallucinations ?
- Affirmation par affirmation : chaque phrase de la réponse est confrontée aux documents que le système a récupérés, et celles qui ne s'y trouvent pas sont comptées. On exige zéro sur les cas critiques. Une note globale de fidélité ne suffit pas : une réponse juste aux deux tiers contient une promesse inventée, et c'est celle que le client retient.
- Quel taux de précision peut-on attendre ?
- Aucun chiffre général ne vaut pour vous : les classements publics mesurent des tâches générales, souvent en anglais, pas une question en darija sur votre catalogue. Le taux qui compte se mesure sur vos soixante cas, par type de cas, et il se lit avec cinq autres mesures : affirmations sans source, refus à tort, régressions, passages à l'humain, coût et latence.
- Qui écrit les bonnes réponses ?
- Vous : la personne de votre équipe qui sait, le gérant, le comptable, le chef d'agence. C'est une heure ou deux, une fois, et c'est la seule étape que nous ne pouvons pas faire à votre place. Une bonne réponse écrite par le prestataire, ou par le modèle, mesure ce que le prestataire croit, pas ce que vos clients doivent entendre.
- Que se passe-t-il quand le modèle change de version ?
- Le jeu est rejoué, en une commande, et le tableau montre les régressions : les cas que l'ancienne version réussissait et que la nouvelle échoue. C'est la même procédure quand on change les instructions, les documents ou qu'on passe à un modèle moins coûteux. Sans jeu, un changement de version est un pari qu'on découvre par une réclamation.
- Que demander à un prestataire qui dit que son IA est fiable ?
- Sur combien de cas elle a été mesurée, qui a écrit les bonnes réponses, quels types de cas le jeu contient, comment les affirmations sans source sont comptées, quel était le seuil écrit avant les essais, et quels cas échouent encore. Un prestataire qui mesure peut montrer la liste de ses échecs ; celui qui montre seulement une démonstration n'en a pas.