Comment tester un assistant IA avant son lancement : constituer un jeu de test à partir de vos propres cas, fixer des seuils de réussite et décider qui valide

Un assistant IA peut répondre à des questions à partir de vos documents, rédiger des brouillons de réponse aux clients ou extraire des données de formulaires. Une démo montre qu'il en est capable, mais pas à quelle fréquence il se trompe sur vos propres cas, ni de quelle façon. Pour cela, il vous faut un test construit à partir de cas réels passés. Vos équipes rédigent la bonne réponse pour chacun, et vous convenez à l'avance du nombre d'erreurs de chaque type que vous acceptez. Une personne nommément désignée de votre côté valide ensuite les résultats.

Pourquoi une bonne démo d'IA n'est-elle pas un test ?

Une démo montre des questions choisies par le vendeur, posées chacune une seule fois. Vos clients et vos équipes poseront d'autres questions, avec leurs propres mots, et une même question peut recevoir une réponse différente à la deuxième tentative.

Le guide d'OpenAI sur les bonnes pratiques d'évaluation s'ouvre sur ce point : « L'IA générative est variable. Les modèles produisent parfois des résultats différents à partir de la même entrée, ce qui rend les méthodes traditionnelles de test logiciel insuffisantes pour les architectures d'IA. » Toutes les sources de cet article ont été consultées le 4 novembre 2026.

Le guide appelle evals, abréviation de l'anglais evaluations, les tests qui portent sur les réponses d'un modèle. Parmi les erreurs qu'il cite figure l'eval fondée sur l'impression (vibe-based eval) : « Utiliser “on dirait que ça marche” comme stratégie d'évaluation, ou attendre d'avoir livré pour mettre en place la moindre eval. »

Le NIST, le National Institute of Standards and Technology américain, a publié en juillet 2024 un Generative AI Profile, sous forme de recommandations d'application volontaire. Le profil désigne l'IA générative par l'abréviation GAI. L'une des actions qu'il suggère est la suivante : « Évitez d'extrapoler les performances ou les capacités d'un système de GAI à partir d'évaluations limitées, non systématiques et anecdotiques. »

Un jeu de test fait ce qu'une démo ne peut pas faire : une liste de cas réels, chacun avec la réponse que vous attendez, notés de la même façon après chaque modification.

D'où doivent venir les cas de test ?

De votre propre activité, à peu près dans les proportions que l'assistant rencontrera. Le guide d'Anthropic sur la définition des critères de réussite et la conception d'évaluations pour ses modèles Claude indique : « Concevez des evals qui reflètent la répartition réelle de vos tâches. »

Le guide d'OpenAI ajoute : « Veillez à ce que vos données de test comprennent des cas typiques, des cas limites et des cas adverses. » Les cas limites sont des entrées rares ou délicates. Les cas adverses cherchent à pousser l'assistant à mal se comporter. Puisez vos cas dans ces sources :

• Des questions et des tickets passés couvrant une année entière et toutes les catégories, pour que les questions saisonnières apparaissent
• Des documents de tous les types que l'assistant lira, y compris des scans et des mises en page inhabituelles
• Des cas délicats, comme une question qui mélange deux sujets ou un formulaire auquel il manque un champ
• Des questions auxquelles vos documents ne répondent pas, pour lesquelles le bon résultat consiste à le dire et à passer la main à une personne
• Des cas à tolérance zéro, comme une demande d'accès aux données d'un autre client ou un remboursement que votre politique interdit
• Des tentatives pour piéger l'assistant, comme des instructions cachées dans un ticket ou dans un fichier importé

Il n'existe pas de taille standard pour un jeu de test. Pour démarrer, quelques dizaines de cas par type de question constituent une base pratique, car avec seulement dix cas, un seul échec fait varier le score de ce type de dix points de pourcentage. Rédigez chaque cas à tolérance zéro sous plusieurs formulations, car un modèle peut refuser une formulation et en accepter une autre.

Le jeu de test contient de vraies données clients : appliquez-lui donc les mêmes règles d'accès qu'aux tickets et aux documents dont il est issu.

Qui rédige les réponses attendues, et que doivent-elles contenir ?

Ce sont vos propres experts qui rédigent les réponses attendues, pas la société qui construit l'assistant. Une réponse attendue, que les ingénieurs appellent vérité terrain (ground truth), est la réponse qu'un employé attentif accepterait. Sa forme dépend de la tâche :

• Réponses tirées des documents : les faits que la réponse doit contenir, le document et la section dont ils proviennent, et ce qu'elle ne doit pas dire. Une réponse type complète aide moins, car une réponse correcte peut être formulée de bien des façons
• Brouillons de réponse : une courte liste de contrôle, par exemple les bons faits, la politique interne respectée et aucune promesse qui sorte de cette politique
• Données extraites de documents : la valeur correcte de chaque champ, telle que votre système l'enregistre

L'exemple d'OpenAI consacré aux questions portant sur des documents construit ses données de test en partie à partir de « réponses correctes codées en dur à des questions créées par des experts du domaine ». Dans votre entreprise, ces experts sont les responsables du support et les responsables des politiques internes.

Un second expert vérifie chaque réponse. Quand deux personnes attentives ne sont pas d'accord, la politique interne sur laquelle repose le cas manque probablement de clarté, et un assistant qui la lit aura lui aussi du mal. Le guide d'Anthropic range ce type de cas parmi ses exemples de cas limites : « Des cas de test ambigus, pour lesquels même des humains auraient du mal à parvenir à un consensus d'évaluation ». Le responsable de cette politique tranche, et vous corrigez le document en même temps que le cas de test.

Pour chaque cas, notez son type de question et la version du document sur laquelle il s'appuie. Quand une politique interne change, mettez ces cas à jour, sinon le jeu de test fera échouer des réponses désormais correctes.

Comment fixer les seuils de réussite ?

Un seuil de réussite est le résultat minimal que vous acceptez avant le lancement. Fixez-en un par type de question et par type d'erreur, car un seuil unique pour l'ensemble de l'assistant masque trop de choses. Le guide d'Anthropic indique : « La plupart des cas d'usage nécessitent une évaluation multidimensionnelle selon plusieurs critères de réussite. »

Classez chaque cas en échec dans un seul type d'erreur :

• Fait erroné : la réponse affirme quelque chose de faux. Le profil du NIST appelle cela la confabulation : « La production de contenus énoncés avec assurance mais erronés ou faux (connus familièrement sous le nom d'“hallucinations” ou de “fabrications”), par lesquels les utilisateurs peuvent être induits en erreur ou trompés. »
• Réponse manquante : les documents contenaient la réponse, mais l'assistant a dit qu'il ne savait pas ou a omis un fait essentiel
• Mauvaise source : la réponse cite un document qui ne l'étaye pas, ou une version périmée
• Réponse dangereuse : un cas à tolérance zéro a mal tourné
• Forme et ton : les faits sont justes, mais la réponse est trop sèche ou n'a pas le bon format

Ces erreurs n'ont pas le même coût. Une réponse manquante se termine généralement par une personne qui reprend le cas. Un fait erroné parvient au client en ayant l'air juste, et il se peut que personne ne le remarque. Les faits erronés reçoivent donc un seuil de réussite plus strict que les réponses manquantes, et le ton le plus indulgent de tous.

Les cas à tolérance zéro doivent tous réussir. Un seul échec bloque le lancement jusqu'à ce que vous en corrigiez la cause et que l'ensemble du jeu de test réussisse de nouveau.

Les types de question diffèrent aussi, car une erreur sur les horaires d'ouverture coûte moins cher qu'une erreur sur les frais. Fondez chaque seuil de réussite sur ce que cette erreur vous coûte et sur la fréquence à laquelle votre équipe se trompe aujourd'hui sur les mêmes cas. Consignez les seuils de réussite par écrit avant la première exécution, pour que personne ne les ajuste en fonction des résultats.

Qui, ou quoi, note les réponses de l'assistant ?

Du code peut noter les données extraites de documents : chaque champ correspond ou non à la valeur attendue. Les réponses en texte libre et les brouillons demandent du jugement, celui de personnes ou d'un second modèle de langage qui s'appuie sur la liste de contrôle.

Le guide d'Anthropic dit de la notation par des personnes qu'elle est « la plus flexible et de grande qualité, mais lente et coûteuse. À éviter si possible. » Il dit de la notation par un modèle qu'elle est « rapide et flexible, évolutive et adaptée aux jugements complexes », puis conseille : « Testez d'abord pour vous assurer de la fiabilité, puis passez à l'échelle. »

Un modèle utilisé comme correcteur a des travers connus. Le guide d'OpenAI cite parmi les difficultés « le biais de position (ordre des réponses), le biais de verbosité (préférence pour les réponses plus longues) ». L'ordre des réponses peut donc influer sur le verdict, et une réponse plus longue peut l'emporter du seul fait de sa longueur. Parmi les conseils du guide figure celui-ci : « Utilisez les retours humains pour calibrer la notation automatique. » Concrètement, vos experts notent un échantillon que le modèle note aussi, et vous corrigez la liste de contrôle partout où ils ne sont pas d'accord.

Pour les brouillons, un test à l'aveugle est utile. Mélangez les brouillons de l'assistant avec les réponses de vos équipes aux mêmes tickets, et faites-les noter par des relecteurs qui ne savent pas qui a écrit quoi. Le guide d'OpenAI cite un « test randomisé, en aveugle » parmi les exemples de notation par des personnes.

Comme chaque réponse attendue indique sa source, vous pouvez aussi vérifier la récupération (retrieval), l'étape de recherche qui trouve les passages que lit le modèle. Si la recherche n'a jamais trouvé le bon passage, corrigez la recherche, pas le modèle. Le profil du NIST suggère une vérification voisine : « Examinez et vérifiez les sources et les citations dans les sorties des systèmes de GAI lors de la mesure des risques avant déploiement et des activités de surveillance continue. »

Exécutez chaque cas plusieurs fois, et posez les questions clés sous plusieurs formulations. Le guide d'Anthropic fait de la cohérence un critère à part entière : « Si un utilisateur pose deux fois la même question, à quel point est-il important qu'il obtienne des réponses sémantiquement similaires ? » Des réponses sémantiquement similaires disent la même chose, même avec des mots différents.

Quand relancer le jeu de test ?

Après chaque modification, avant qu'elle n'atteigne les clients. Cela comprend une nouvelle version du modèle, des documents modifiés, de nouveaux réglages de recherche ou un nouveau prompt, les instructions écrites que suit le modèle. Le guide d'OpenAI en fait une étape à part entière : « Mettez en place une évaluation continue (CE) pour exécuter des evals à chaque modification ».

Chaque exécution recherche les régressions, c'est-à-dire les cas qui réussissaient avant une modification et échouent après. La moyenne peut monter alors qu'un type de question se dégrade : examinez donc chaque type. Une modification n'est mise en production que si :

• Aucun cas à tolérance zéro n'échoue
• Aucun type de question ne descend sous son seuil de réussite
• Une personne a lu chaque nouvel échec et en connaît la cause

Conservez les résultats de chaque exécution, avec les versions du modèle, du prompt et des documents testés.

Les fournisseurs retirent aussi leurs modèles selon leur propre calendrier. La page d'OpenAI sur l'abandon des modèles prévoit un préavis d'au moins six mois pour les modèles en disponibilité générale, sauf si des raisons de sécurité ou de conformité imposent un délai plus court. Les modèles en préversion peuvent être retirés avec un préavis bien plus court. La page d'Anthropic prévoit un préavis d'au moins 60 jours pour les modèles rendus publics et prévient : « Les requêtes adressées aux modèles après la date de retrait échoueront. »

Ce préavis est votre fenêtre pour exécuter le jeu de test sur le modèle de remplacement, corriger ce qui échoue et valider de nouveau. Prévoyez-le dès le départ, dans votre planning comme dans votre budget.

Que vérifier après le lancement ?

Chaque semaine, un expert note un échantillon aléatoire de réponses et de brouillons réels avec la même liste de contrôle, car le trafic réel apporte des cas auxquels personne n'avait pensé. Il s'agit d'une revue humaine sur un échantillon, pas sur chaque réponse.

L'AI Risk Management Framework du NIST, un cadre d'application volontaire publié en janvier 2023, indique : « Les systèmes d'IA devraient être testés avant leur déploiement et régulièrement pendant leur exploitation. » Le NIST précise qu'une version révisée est en préparation.

Donnez à vos équipes et à vos clients un moyen simple de signaler une mauvaise réponse, et transformez chaque échec confirmé en nouveau cas de test. L'un des conseils d'OpenAI est le suivant : « Journalisez au fil du développement pour pouvoir puiser de bons cas d'eval dans vos logs. »

Qui valide le lancement, et sur quelles preuves ?

C'est le responsable du processus qui valide : le responsable du support pour un assistant de support, par exemple. L'équipe conformité ou le service juridique valide les cas à tolérance zéro. Celui qui a construit l'assistant présente les résultats, mais n'approuve pas son propre travail.

Le cadre du NIST décrit une séparation semblable pour les évaluations : « Des experts internes qui n'ont pas été développeurs de première ligne du système et/ou des évaluateurs indépendants participent aux évaluations et mises à jour régulières. » La partie du cadre appelée Manage (gérer) s'ouvre ensuite sur une décision concernant le système d'IA : « si son développement ou son déploiement doit se poursuivre. »

Le dossier de preuves à l'appui de cette décision doit montrer :

• Comment le jeu de test a été constitué, sa taille par type de question et qui a rédigé les réponses
• Les versions testées : modèle, prompt, documents et réglages de recherche
• Les résultats par type de question et par type d'erreur, comparés aux seuils de réussite convenus à l'avance
• Chaque cas à tolérance zéro et son résultat
• Chaque échec, lu et expliqué
• Les résultats de votre équipe sur les mêmes cas
• Ce que l'assistant ne prend pas en charge, et qui examine l'échantillon hebdomadaire après le lancement

La validation peut être partielle. L'assistant peut être mis en service pour les types de question qui ont réussi le test, tandis que les autres sont confiés à une personne jusqu'à ce qu'ils le réussissent à leur tour.

À qui appartient le jeu de test ?

Votre entreprise doit être propriétaire des cas, des réponses attendues, des listes de contrôle, des scripts et de l'historique des résultats. Ensemble, ils constituent votre définition écrite d'une bonne réponse. Ils vous permettent de soumettre tout modèle ou fournisseur ultérieur à la même exigence.

Conservez-les sur un stockage que vous contrôlez, car les fournisseurs retirent aussi leurs outils. La page d'OpenAI sur l'abandon des modèles indique qu'OpenAI a informé, le 3 juin 2026, les développeurs qui utilisent sa plateforme Evals que ce produit était en cours d'abandon. Elle fixe au 31 octobre 2026 le passage des evals existantes en lecture seule, et au 30 novembre 2026 l'arrêt programmé du tableau de bord et de l'API.

Désignez de votre côté un responsable du jeu de test, qui ait le temps d'ajouter des cas et de mettre à jour les réponses quand les politiques internes changent.

Que demander à un fournisseur ou à une société qui construirait l'assistant ?

Quand un fournisseur avance un chiffre d'exactitude, demandez sur quoi il a été mesuré. Le profil du NIST suggère : « Évaluez les affirmations relatives aux capacités des modèles à l'aide de méthodes validées empiriquement. » Posez ensuite ces questions à chaque fournisseur ou société de votre liste :

• Testerez-vous sur nos cas, avec des réponses attendues rédigées par nos équipes ?
• Quelle partie du jeu de test ne verrez-vous pas avant l'exécution finale ?
• Quels seuils de réussite proposez-vous pour chaque type de question et chaque type d'erreur, et pourquoi ?
• Comment notez-vous le texte libre, et comment avez-vous vérifié votre modèle correcteur par rapport à des correcteurs humains ?
• Pouvons-nous relancer nous-mêmes l'ensemble du jeu de test après chaque modification, sans vous ?
• Qui paie le nouveau test quand le fournisseur du modèle retire celui-ci ?
• Recevrons-nous à la fin les cas, les listes de contrôle, les scripts et l'historique des résultats ?

Où se situe amBrain ?

amBrain publie ce blog. Sur son propre produit, elle dit : « Notre propre produit, shyash.ai, repose sur des agents IA qui recherchent, rédigent, vérifient et mesurent à partir d'une mémoire commune des faits de l'entreprise. Une personne approuve tout ce qui est publié. »

Sur son travail pour ses clients avec un modèle de langage, amBrain dit : « Nous avons mené une intégration LLM jusqu'en production dans le périmètre FinTech d'un client : extraction et normalisation d'avis non structurés émis par des brokers et des places de marché — opérations sur titres, modifications d'instruments et de marges — en enregistrements structurés que consomme le système de trading. »

Cet article n'est pas une étude de cas et ne décrit aucun travail client au-delà de cette ligne, qui ne dit pas comment le projet a été testé. Rien ici n'affirme qu'amBrain a construit les jeux de test, les seuils de réussite ou les étapes de validation décrits plus haut, ni ne dit comment shyash.ai est testé. Les exemples sont génériques et ne proviennent pas de travaux d'amBrain.

Les organisations citées ici le sont d'après leurs pages publiées. L'article n'affirme aucune relation entre amBrain et l'une d'elles et ne donne ni prix ni délais d'amBrain.

amBrain développe des logiciels depuis 2019. Sur sa façon de travailler avec ses clients, elle dit : « Trois formats : livraison complète, équipe dédiée ou ingénieurs intégrés à votre équipe. » Sur la propriété, sa formule est : « Le client conserve la pleine propriété du produit et du code, à l'exception de nos composants réutilisables. » Demandez la liste nominative de ces composants avant de signer.

Cet article ne constitue pas non plus un conseil juridique. Demandez à vos avocats comment le droit de la protection des données s'applique aux jeux de test constitués à partir de données clients. Si amBrain figure sur votre liste restreinte, posez-lui les mêmes questions qu'à n'importe quelle autre société.