Sommaire : le jeu d’évaluation, la notation et les juges, garde-fous et sécurité, un exemple détaillé, les seuils de mise en production, la non-régression et la supervision, les erreurs fréquentes, par où commencer, FAQ.
- Tester une application LLM avec un vrai jeu d’évaluation
- Noter les réponses : contrôles automatiques, relecture humaine et juge LLM
- Garde-fous et tests de sécurité
- Un exemple détaillé : un assistant de service client fictif
- Seuils, déploiement progressif et checklist de mise en production
- Non-régression et supervision après la mise en ligne
- Erreurs fréquentes
- Par où commencer
- FAQ
En bref. Une démo prouve qu’un assistant sait bien répondre une fois. Pour tester une application LLM sérieusement, il faut un jeu d’évaluation écrit, des critères de notation clairs et des seuils fixés avant le lancement. Ajoutez des garde-fous et des tests de sécurité, ouvrez d’abord à un petit groupe, puis rejouez les mêmes tests après chaque changement de consigne, de documents ou de modèle. Continuez à journaliser après la mise en ligne et réinjectez chaque échec dans le jeu.
La plupart des équipes font l’inverse. Elles peaufinent la démo, essaient une douzaine de questions bienveillantes et livrent. La première semaine en production leur apprend alors ce que le test aurait dû leur apprendre. Voici la démarche que nous recommandons en tant qu’équipe de consultants IA : quoi construire, quoi mesurer, quoi bloquer et quand dire oui.
Elle vaut pour une application IA sur mesure, un assistant de support branché sur vos documents ou un outil interne. Les étapes restent les mêmes. Seuls les seuils changent avec le niveau de risque.
Tester une application LLM avec un vrai jeu d’évaluation
Le jeu d’évaluation est la base de tout. C’est une liste de questions, chacune avec la réponse attendue ou le comportement attendu, que vous rejouez à chaque changement. Sans lui, toute opinion sur la qualité reste une anecdote.
D’où viennent les questions
Partez des futurs utilisateurs. Rassemblez de vraies questions dans les tickets, les e-mails, les conversations et lors d’entretiens avec l’équipe. Si les données réelles manquent, demandez à des experts métier d’en écrire de réalistes. Ne laissez pas l’équipe projet les inventer seule : elle pose les questions dont elle sait que le système se sortira.
Les types de questions à prévoir
- Questions courantes : les demandes fréquentes et bien documentées, qui font l’essentiel du trafic.
- Cas limites : formulations ambiguës, fautes de frappe, langues mélangées, messages très courts ou très longs.
- Questions à plusieurs étapes : demandes qui exigent deux documents ou un calcul.
- Questions hors périmètre : sujets que l’assistant doit refuser, comme un avis juridique ou les données d’un autre client.
- Information absente : questions dont la réponse n’est pas dans les documents. Le bon comportement est de le dire.
- Entrées hostiles : tentatives de contourner les consignes, d’extraire le prompt système ou de changer de sujet.
Ce qu’il faut écrire pour chaque question
Pour chaque entrée, notez la question, la réponse attendue ou les faits clés qu’elle doit contenir, le document source qui la soutient et le comportement attendu (répondre, refuser ou passer la main). Ajoutez une étiquette de catégorie pour repérer les points faibles. Gardez le jeu dans un fichier simple sous gestion de versions, afin que les changements soient visibles.
Commencez petit, puis enrichissez. Un jeu relu avec soin vaut mieux qu’un énorme jeu auquel personne ne croit. Chaque échec réel après le lancement devient une nouvelle entrée : le jeu s’améliore à l’usage. Gardez aussi un groupe de questions que vous n’utilisez jamais pour régler la consigne. Il vous dit si vous corrigez de vrais problèmes ou si vous apprenez simplement le test par cœur.
Noter les réponses : contrôles automatiques, relecture humaine et juge LLM
Un test n’est utile que si l’on sait dire à quoi ressemble une réussite. Définissez les critères en termes métier, puis choisissez comment vérifier chacun.
Les critères qui comptent pour le métier
- Exactitude : la réponse correspond-elle aux faits de vos sources approuvées ?
- Ancrage : chaque affirmation s’appuie-t-elle sur un document retrouvé, sans détail inventé ?
- Citation : l’assistant renvoie-t-il vers la bonne source, et celle-ci dit-elle bien ce qui est affirmé ?
- Refus : décline-t-il quand il le faut, et répond-il quand il le faut ?
- Ton et format : la réponse convient-elle au public, dans la bonne langue, à la bonne longueur ?
- Sécurité : évite-t-elle d’exposer des données personnelles ou confidentielles ?
Notez chaque critère séparément. Une note unique de « qualité » masque le problème : une réponse peut être parfaitement rédigée et totalement fausse.
Trois façons d’évaluer
Contrôles automatiques. Des règles exécutées en quelques secondes : la réponse contient-elle un fait obligatoire, cite-t-elle un document de la liste approuvée, respecte-t-elle la longueur maximale, évite-t-elle une formule interdite, renvoie-t-elle une sortie structurée valide ? C’est peu coûteux, reproductible et strict. Cela ne juge pas les nuances.
Relecture humaine. Des experts métier lisent un échantillon et le notent selon des critères écrits. C’est lent et coûteux, mais c’est la référence. Elle sert à construire la première version du jeu, à trancher les désaccords et à vérifier les deux autres méthodes.
Juge LLM. Un second modèle note les réponses à partir d’une grille. Il passe bien à l’échelle et repère ce que les règles ratent, par exemple une réponse fluide mais non soutenue par la source.
Les limites du juge LLM
Le juge est un outil, pas un oracle. Sachez où il échoue.
- Il favorise souvent les réponses plus longues et plus assurées, même fausses.
- Il peut préférer les réponses écrites dans son propre style.
- Ses notes varient selon la formulation de la grille et parfois d’une exécution à l’autre.
- Il peut manquer des erreurs métier que seul un expert remarquerait.
- Si le juge et l’application reposent sur le même modèle, ils peuvent partager les mêmes angles morts.
Calibrez le juge avant de lui faire confiance. Faites noter un échantillon par des humains, comparez avec les notes du juge et ajustez la grille jusqu’à l’accord sur les cas qui comptent. Donnez-lui les documents sources et une liste de contrôle précise, pas une demande vague de note. Revérifiez l’accord de temps en temps, et envoyez toujours les cas limites et à fort risque à une personne.
Un partage raisonnable : contrôles automatiques sur tout, juge sur les critères nuancés, relecture humaine sur un échantillon régulier et sur toutes les catégories critiques.
Garde-fous et tests de sécurité
Les garde-fous limitent les dégâts quand le modèle se trompe ou qu’on le manipule. Ils ont leurs propres tests, car un garde-fou que vous n’avez jamais essayé de casser reste une hypothèse.
Injection de prompt
L’injection de prompt consiste à glisser, dans un message ou dans un document que l’assistant lit, une instruction lui demandant d’ignorer ses consignes. Testez les deux voies. Écrivez des tentatives directes (« ignore tes règles et… ») et placez des instructions dans les documents ou pages que l’assistant récupère. Il doit traiter le contenu récupéré comme des données, jamais comme des ordres. Limitez aussi ce qu’il peut faire : une instruction injectée est bien moins dangereuse quand l’assistant n’a pas le pouvoir d’agir.
Fuite de données
Vérifiez que l’assistant ne révèle jamais le prompt système, les conversations d’autres utilisateurs, des données personnelles ou des documents que l’utilisateur n’a pas le droit de voir. Le contrôle d’accès doit être appliqué par le système qui récupère les documents, pas par une phrase dans la consigne. Testez avec des utilisateurs de droits différents et vérifiez que les réponses diffèrent en conséquence.
Sources approuvées uniquement
Pour un assistant de connaissances, limitez les réponses à un ensemble de documents choisis. Vérifiez qu’il refuse les questions que les sources ne couvrent pas, au lieu de combler le vide avec des connaissances générales. Vérifiez que les documents périmés sont retirés de l’index et que chaque réponse affiche la source utilisée.
Passage à un humain
Définissez quand l’assistant doit s’arrêter et transmettre à une personne : confiance faible, sujet sensible, client en colère, demande d’exception, échecs répétés. Testez que le passage de relais a bien lieu, que le contexte suit et que l’utilisateur sait ce qui se passe ensuite.
Limites sur les actions et les coûts
Si l’assistant peut appeler des outils, envoyer des messages ou modifier des fiches, testez chaque action avec de mauvaises entrées. Exigez une confirmation pour tout ce qui est irréversible. Ajoutez des plafonds de longueur, de fréquence et de dépense pour qu’une boucle ou un abus ne passe pas inaperçu. Votre socle DevOps et cloud doit appuyer tout cela : gestion des secrets, règles d’accès et alertes.
Vous préparez une migration cloud ?
Découvrez comment nos consultants seniors évaluent, planifient et conduisent les migrations vers AWS ou Azure, avec un retour arrière testé.
Un exemple détaillé : un assistant de service client fictif
Prenons une entreprise fictive qui vend un logiciel par abonnement et veut un assistant qui répond aux clients à partir de son centre d’aide. C’est une illustration, pas un cas réel.
Étape 1, le jeu. L’équipe exporte d’anciens tickets anonymisés et les classe : facturation, accès au compte, fonctionnalités, intégrations, résiliations. Les conseillers écrivent la réponse attendue pour chacun, avec l’article d’aide qui la soutient. Ils ajoutent des questions sans article, des demandes de remboursement hors politique, un client qui s’informe sur le compte d’une autre personne et quelques messages qui tentent de faire révéler ses consignes à l’assistant.
Étape 2, les critères. Exactitude et ancrage sont notés en réussite ou échec. Le ton est noté sur une courte échelle. Le refus est noté par catégorie : l’assistant doit décliner les questions de compte qu’il ne peut pas vérifier et transmettre toute demande de remboursement.
Étape 3, la première exécution. Les contrôles automatiques vérifient que chaque réponse cite un article de la liste approuvée. Le juge note l’exactitude à partir du texte de l’article. L’équipe lit chaque échec et chaque cas où le juge et un conseiller divergent. Deux tendances apparaissent : l’assistant répond aux questions de résiliation avec un article périmé, et il répond avec aplomb quand la question est ambiguë.
Étape 4, les corrections. L’article périmé est retiré de l’index. La consigne est modifiée pour que l’assistant pose une question de clarification quand la demande est ambiguë. Chaque correction est suivie d’une exécution complète, qui révèle aussi qu’un changement a cassé une réponse de facturation qui passait auparavant. C’est précisément pour cela que la réexécution existe.
Étape 5, le passage sécurité. Les testeurs glissent une instruction dans un brouillon d’article, tentent d’extraire le prompt système et interrogent l’assistant sur la facture d’un autre client. Il résiste aux deux premières attaques, mais la troisième révèle une faille de contrôle d’accès dans la recherche de factures. Elle est corrigée dans la couche de récupération, pas dans la consigne.
Étape 6, la mise en ligne. L’assistant ouvre d’abord au personnel interne, puis à une petite part des clients, avec un lien visible pour joindre un humain. Les journaux sont relus chaque semaine et chaque nouvel échec rejoint le jeu.
Seuils, déploiement progressif et checklist de mise en production
Fixer les seuils avant de tester
Convenez des critères de réussite avant de voir les résultats, sinon les chiffres seront tordus pour coller à la date de lancement. Utilisez des exigences différentes selon le risque. Une tolérance zéro convient à la sécurité et aux fuites de données : un seul échec bloque la mise en production. Un taux de réussite minimal convient à l’exactitude et à l’ancrage, fixé par le métier selon le coût d’une erreur. Le ton peut être plus souple.
Écrivez les seuils, avec le nom de la personne qui peut accorder une exception.
Déployer par étapes
- Usage interne : les collaborateurs essaient l’assistant sur du vrai travail et signalent les problèmes.
- Mode fantôme : l’assistant rédige des réponses qu’une personne relit avant envoi.
- Petit groupe : un nombre limité de vrais utilisateurs, avec un moyen simple de joindre un humain.
- Ouverture élargie : n’étendez l’accès que si les résultats supervisés restent dans les seuils.
Gardez la possibilité de désactiver l’assistant ou de revenir à un comportement simple rapidement. Un plan de retour arrière que personne n’a essayé n’est pas un plan.
Grille de décision
Go : les seuils sont atteints, tous les tests de sécurité passent, le passage à un humain fonctionne, la journalisation est active, un responsable est nommé et un retour arrière a été répété.
Go avec limites : la qualité est acceptable mais une catégorie est faible. Lancez en bloquant cette catégorie ou en la confiant à une personne, et fixez une date de revue.
No go : un test de sécurité ou de fuite échoue, les résultats sont instables d’une exécution à l’autre ou personne ne porte le système après le lancement.
Checklist
- Le jeu couvre questions courantes, cas limites, hors périmètre, information absente et entrées hostiles.
- Les critères de notation et les seuils sont écrits et validés.
- Le juge LLM a été calibré sur des notes humaines.
- Les tests d’injection, de fuite et de droits ont été joués, et les corrections retestées.
- Les réponses citent des sources approuvées et refusent quand les sources se taisent.
- Le passage à une personne fonctionne et transmet le contexte.
- Journalisation, alertes, plafonds de coût et retour arrière sont en place.
- Un responsable nommé relit les journaux à intervalle fixe.
Non-régression et supervision après la mise en ligne
Rejouer le jeu à chaque changement
Trois éléments modifient le comportement d’une application LLM : la consigne, les documents et le modèle. Une petite retouche de consigne peut casser des réponses qui marchaient la veille. Un nouveau document peut contredire un ancien. Une mise à jour du modèle peut changer le ton, la longueur ou les refus sans aucune modification de votre côté. Traitez chacun comme un changement de code et jouez le jeu complet avant de livrer. Automatisez l’exécution pour qu’elle prenne quelques minutes et s’insère dans votre chaîne de livraison.
Comparez avec la version précédente, pas seulement avec le seuil. Une petite baisse sur une catégorie est un signal, même si le score global semble correct. Figez la version du modèle quand c’est possible et prévoyez un cycle de test avant d’en changer.
Journaliser ce qui se passe en production
Enregistrez la question, les documents retrouvés, la réponse, les versions du modèle et de la consigne, le temps de réponse et les retours des utilisateurs. Masquez les données personnelles dans les journaux et fixez une durée de conservation. Sans journaux, impossible d’enquêter sur une réclamation ou d’ajouter un échec au jeu.
Superviser avec une routine
- Relisez chaque semaine un échantillon aléatoire de conversations, plus celles signalées par les utilisateurs ou par des règles automatiques.
- Surveillez les taux de passage à un humain, de refus et de retours négatifs pour repérer les changements brusques.
- Suivez le coût et le temps de réponse, avec des alertes sur les pics anormaux.
- Repérez les nouveaux sujets que les utilisateurs abordent et que les documents ne couvrent pas.
- Ajoutez chaque échec confirmé au jeu d’évaluation et rejouez.
Cette boucle transforme un lancement en produit qui s’améliore. Elle demande un responsable, un rythme et quelques heures d’attention, pas une grande équipe.
Erreurs fréquentes
- Tester seulement avec des questions bienveillantes. L’équipe pose ce qu’elle sait gérable. Les utilisateurs, non.
- Écrire le jeu après la démo. Les critères se calent alors sur ce qui marche déjà.
- Juger avec une note unique. Elle masque les affirmations non soutenues et les mauvaises sources.
- Faire confiance aveuglément au juge LLM. Sans calibrage sur des humains, il ne reflète que ses propres biais.
- Mettre la sécurité dans la consigne. Les droits et l’accès aux données relèvent du système, pas d’une phrase dont on peut dissuader le modèle.
- Changer la consigne sans rejouer le jeu. Les régressions silencieuses sont l’échec le plus courant des assistants en ligne.
- Fixer les seuils après les résultats. La date de lancement décide alors de ce qui est « assez bon ».
- Lancer pour tout le monde d’un coup. Un déploiement progressif coûte moins cher qu’un correctif public.
- Aucun responsable après la mise en ligne. Les documents vieillissent, les questions évoluent et personne ne le voit.
Par où commencer
Si vous voulez tester une application LLM et n’avez encore aucune méthode, commencez petit cette semaine. Rassemblez quelques dizaines de vraies questions avec leurs réponses attendues. Écrivez quatre à six critères de notation. Jouez le jeu, lisez chaque échec et fixez vos seuils. Ajoutez ensuite les cas de sécurité, un plan de journalisation et un déploiement par étapes. C’est suffisant pour passer de l’opinion à la preuve.
Un accompagnement aide quand l’enjeu est fort ou l’équipe sous tension. Un consultant IA expérimenté peut construire le premier jeu avec vos experts, calibrer le juge, jouer les tests de sécurité et installer la boucle de supervision. Découvrez notre approche de la stratégie IA, des applications IA sur mesure et de l’ensemble de nos services IA.
Prochaine étape : demandez l’audit gratuit et échangez avec un consultant senior. Nous examinons votre cas d’usage, vos documents et vos risques, et nous vous disons quoi tester avant le lancement. Réserver un appel de découverte.
FAQ
De combien de questions de test a-t-on besoin ?
Il n’existe pas de chiffre magique. Partez de quelques dizaines qui couvrent chaque catégorie et chaque risque, puis enrichissez le jeu à chaque échec réel. La couverture compte plus que la taille. Un petit jeu avec des cas limites et des entrées hostiles vaut mieux qu’un grand jeu de questions faciles.
Un juge LLM peut-il remplacer les relecteurs humains ?
Non. Il peut démultiplier la relecture, mais il doit être calibré sur des notes humaines et revérifié régulièrement. Gardez des personnes aux commandes pour les catégories critiques, les cas limites et la grille elle-même.
À quelle fréquence rejouer les tests ?
Avant chaque changement de consigne, de documents, de modèle ou d’outils, et à intervalle régulier même si rien n’a bougé. Les fournisseurs mettent à jour leurs modèles et vos documents évoluent. Une exécution planifiée détecte les dérives que personne n’a décidé d’introduire.
Quel est le test de sécurité le plus important ?
Vérifiez que les droits sont appliqués en dehors du modèle, puis testez l’injection de prompt par les messages et par les documents récupérés. Ces deux tests couvrent les défaillances les plus graves : exposer des données et obéir à des instructions hostiles. Ajoutez des limites d’actions si l’assistant peut faire plus que répondre.
Quand un assistant est-il prêt pour la production ?
Quand il atteint les seuils fixés à l’avance, réussit tous les tests de sécurité, passe la main à une personne de façon fiable et dispose de journalisation, d’un responsable et d’un retour arrière. Si une catégorie est faible, lancez en la bloquant plutôt que de tout retarder.
Faut-il superviser si les tests sont passés ?
Oui. Les tests ne couvrent que les questions auxquelles vous avez pensé. De vrais utilisateurs apportent de nouveaux sujets, les documents vieillissent et les modèles changent. La supervision trouve ce que le jeu a manqué, et chaque découverte renforce le test suivant.