Une réponse bien écrite peut être fausse. Une réponse exacte peut arriver trop tard. Et une réponse utile dans une démonstration peut devenir dangereuse dès qu’elle concerne un contrat, un client ou un document confidentiel.
L’évaluation d’un assistant IA doit donc partir du travail qu’il réalise, pas de l’impression qu’il produit. Le bon protocole permet de choisir un outil, de comprendre ses limites et de détecter une régression après une modification. Il sert aussi à décider quels usages doivent rester sous contrôle humain.
Ce dossier propose une méthode de recette applicable à un assistant documentaire ou métier. Les exemples chiffrés sont fictifs : ils expliquent les calculs, sans prétendre représenter un résultat observé dans une entreprise.
En bref — Définissez les tâches autorisées, constituez des cas représentatifs, conservez un lot de test séparé et mesurez la qualité sur des critères explicites. Comptez aussi les refus justifiés, les erreurs critiques, le temps de vérification et le coût complet. Un score global ne remplace jamais l’examen des incidents graves.
Commencer par une décision que l’évaluation doit éclairer
« Notre assistant est-il bon ? » est une question trop large. « Peut-il préparer une réponse à une demande de remboursement, sans l’envoyer et en citant la procédure applicable ? » permet déjà de construire un test.
La première étape consiste à écrire un contrat d’usage. Il précise les utilisateurs, les données accessibles, la tâche attendue, les actions interdites et la personne responsable de la décision finale. Un outil qui prépare une synthèse et un agent qui modifie un dossier ne présentent pas le même risque.
Décrivez ensuite la sortie acceptable. Pour une synthèse contractuelle, on peut demander la date d’échéance, le préavis, les clauses pertinentes et les incertitudes. Une réponse qui invente le préavis ne devient pas acceptable parce que ses autres éléments sont corrects.
La documentation doit aussi identifier ce que l’assistant ne sait pas faire. Une absence de document, une question hors périmètre ou une demande ambiguë peuvent justifier une abstention. Le refus devient alors un comportement attendu, avec une explication utile et une voie de traitement humain.
Cette préparation prolonge le travail de gouvernance des usages et des données sensibles. Sans périmètre stable, un test peut récompenser un comportement qui serait interdit en production.
Il faut enfin arrêter une règle de décision avant de regarder les résultats. Par exemple : aucun accès indu à un document confidentiel, une couverture minimale sur les questions courantes et un temps de vérification inférieur à la méthode manuelle. Ces objectifs sont des choix métier à argumenter, pas des seuils universels fournis par un fournisseur.
Construire un jeu de cas qui ressemble au travail réel
Une collection de questions faciles donne surtout une bonne présentation commerciale. Un jeu d’évaluation utile contient les demandes ordinaires, les situations difficiles et les cas où répondre serait une erreur.
Commencez par un échantillon de tâches historiques, après retrait ou transformation des données personnelles inutiles. Conservez les variantes importantes : document court ou long, tableau, formulation imprécise, information ancienne, versions contradictoires. Évitez de n’utiliser que les questions des personnes qui ont configuré l’assistant.
Pour chaque cas, enregistrez l’entrée, le contexte disponible, les éléments attendus, les erreurs éliminatoires et la justification de la réponse de référence. Une référence n’est pas nécessairement un paragraphe unique. Elle peut être un ensemble de faits obligatoires, une décision attendue ou plusieurs formulations acceptables.
Les catégories suivantes constituent une grille de départ :
| Famille de cas | Ce que le test doit révéler | Exemple pédagogique |
|---|---|---|
| Question courante | Capacité à effectuer la tâche centrale | Retrouver une échéance dans un contrat disponible |
| Information absente | Abstention et demande de précision | Expliquer qu’un avenant manque |
| Documents contradictoires | Gestion des versions et des incertitudes | Signaler deux procédures incompatibles |
| Demande non autorisée | Respect du périmètre | Refuser une pièce inaccessible à l’utilisateur |
| Instruction malveillante | Résistance aux consignes présentes dans les données | Ne pas suivre un ordre inséré dans un document |
| Action métier | Contrôle avant effet externe | Proposer une modification sans l’exécuter seul |
Le volume dépend de la diversité des usages. Cent cas ciblés peuvent révéler des problèmes majeurs, mais ils ne prouvent pas une fiabilité générale. Si une famille comporte seulement trois situations, son résultat doit rester visible avec cette petite base, plutôt que se perdre dans une moyenne.
Un point mérite une attention particulière : les utilisateurs emploient rarement le vocabulaire du concepteur. Ajoutez des abréviations, des fautes raisonnables et des demandes incomplètes. Le système doit poser une question lorsque l’ambiguïté change la décision, au lieu de choisir silencieusement une interprétation.
Séparer le réglage du verdict
L’équipe a besoin de cas pour améliorer le système. Elle a également besoin de cas qu’elle n’a pas utilisés pour choisir les consignes, les paramètres ou la recherche documentaire.
C’est le rôle du lot de test réservé. Les cas de développement servent aux corrections. Les cas de validation aident à sélectionner une configuration. Le lot final sert à estimer sa performance sur des situations laissées de côté. Si l’équipe modifie l’assistant après chaque résultat final, ce lot devient progressivement un nouvel ensemble de développement.
Cette séparation ne suffit pas si plusieurs questions décrivent exactement le même document ou la même situation. Répartir des quasi-doublons entre les lots donne une impression de généralisation excessive. Il est préférable de répartir par dossier, période ou scénario lorsque ces unités partagent beaucoup d’informations.
Versionnez tous les éléments qui peuvent influencer le résultat : modèle, consigne système, paramètres de génération, moteur de recherche, documents, droits d’accès et outils connectés. Une comparaison entre deux configurations doit préciser ce qui a changé.
Pour un assistant documentaire, la méthode de construction d’un système RAG aide à distinguer les défauts de recherche des défauts de réponse. Si le bon passage n’est jamais récupéré, changer uniquement la consigne de rédaction risque de masquer le vrai problème.
Une sortie générative peut varier. Répétez donc certains cas sensibles avec une configuration identique, en conservant chaque exécution. L’objectif n’est pas de chercher la meilleure réponse parmi plusieurs essais, mais d’observer la stabilité et la fréquence des comportements problématiques.
Noter des faits et des actions, pas une impression générale
Une note unique de « qualité » mélange trop de dimensions. Utilisez plusieurs critères, avec des consignes de notation suffisamment précises pour que deux évaluateurs comprennent la même règle.
La correction factuelle vérifie les éléments requis. La pertinence examine si la réponse traite réellement la demande. La traçabilité contrôle que les passages cités existent et soutiennent les affirmations. Le respect des droits porte sur les données accessibles. La sécurité des actions examine les modifications ou envois effectués.
Ajoutez la capacité à expliciter une incertitude. Une réponse prudente mais vague peut rester inutilisable. Une bonne abstention explique ce qui manque et ce qu’il faut obtenir, sans inventer une autorisation ou un document.
Pour les tâches à enjeux, faites relire les réponses par une personne compétente dans le domaine. Une seconde notation sur une partie du jeu aide à repérer les désaccords. Conservez les motifs : différence d’interprétation, référence imprécise, preuve insuffisante ou erreur de l’assistant.
Un modèle peut aider à présélectionner des réponses à examiner. Il ne doit pas devenir le seul arbitre d’une sortie dont il ne peut vérifier les conséquences. Les évaluations automatiques sont particulièrement utiles sur des propriétés contrôlables : format valide, présence d’un identifiant, respect d’une liste de champs ou absence d’une action interdite.
Le cadre de gestion des risques du NIST et son profil consacré à l’IA générative invitent à traiter l’évaluation dans le contexte d’usage et à documenter les risques. Ils ne fournissent pas une note magique transformant un assistant en produit fiable pour toute entreprise.
Pourquoi le dénominateur change le diagnostic
Prenons un exemple fictif de 100 demandes auxquelles les documents permettent de répondre. Le moteur récupère les bons éléments pour 82 demandes. L’assistant produit finalement 70 réponses acceptables.
La qualité globale est de 70 %. Sur les seuls cas où la recherche a fourni les bons éléments, elle est de 70 ÷ 82, soit environ 85,4 %. Ce deuxième indicateur aide au diagnostic, mais ne doit pas remplacer le premier dans le bilan utilisateur.
Les 18 échecs de recherche demandent un travail sur les documents, les filtres ou la récupération. Les 12 autres échecs demandent un examen de l’interprétation, des citations et de la génération. Les corrections ne sont pas interchangeables.
Il faut également mesurer les refus sur les cas auxquels il était possible de répondre, et les réponses produites sur les cas qui exigeaient un refus. Ces deux erreurs ont des conséquences différentes. Un assistant qui refuse tout évite certaines fautes, tout en échouant à rendre le service attendu.
Mesurer le coût de la réponse réellement exploitable
Le prix d’une requête ne représente qu’une partie du coût complet. Il faut ajouter la recherche, l’infrastructure, la supervision, l’intégration et surtout le travail de vérification.
Voici un autre calcul fictif. Cent tâches consomment 12 euros de traitement automatique. Chaque sortie exige cinq minutes de contrôle à un coût chargé hypothétique de 36 euros par heure. Le contrôle représente 500 minutes, soit 300 euros. Le total atteint 312 euros.
Si 80 tâches sont finalement acceptables, le coût est de 3,90 euros par tâche exploitable, avant les coûts fixes. Afficher seulement 12 ÷ 100, soit 0,12 euro, décrit une consommation technique. Cela ne décrit pas le coût du service rendu.
Comparez avec la méthode existante sur des tâches semblables. Chronométrez le travail complet : lecture, production, corrections, validation et reprise des erreurs. Une rédaction plus rapide peut être compensée par un contrôle plus long.
La mesure du temps doit distinguer attente du système et travail humain. Regardez aussi les cas lents, pas seulement la moyenne. Un assistant utilisable en entretien téléphonique et un outil exécuté en arrière-plan n’ont pas le même besoin de latence.
Ce raisonnement rejoint le calcul du retour sur investissement d’un projet numérique. Une capacité libérée devient une économie de trésorerie seulement si l’organisation transforme effectivement cette capacité en dépense évitée ou en revenu supplémentaire démontrable.
Examiner les erreurs critiques une par une
Un score de 95 % peut cacher un incident inacceptable. Cinq erreurs mineures de formulation et cinq divulgations de documents ne doivent pas porter le même verdict.
Construisez une taxonomie courte : fait inventé, information périmée, mauvaise source, confusion entre clients, droit d’accès contourné, action non autorisée, donnée sensible exposée. Pour chaque incident, consignez sa gravité, sa reproductibilité, sa cause probable et la protection envisagée.
L’analyse doit couvrir l’ensemble de la chaîne. Un document confidentiel peut apparaître dans un index autorisé par erreur. Une bonne règle de génération n’efface pas ce défaut. À l’inverse, un index correctement filtré ne garantit pas qu’un outil d’action applique les mêmes permissions.
Testez également les chemins de secours. Lorsque le modèle ou la recherche ne répond plus, le système doit annoncer l’indisponibilité, conserver une demande si cela est prévu et permettre un traitement manuel. Inventer une réponse pour éviter un écran vide aggrave généralement l’incident.
Une correction doit produire un nouveau cas de non-régression. La question n’est pas seulement « avons-nous réparé cet exemple ? », mais « avons-nous couvert la famille d’erreurs sans dégrader le reste ? ».
Passer de la recette au suivi opérationnel
Avant le pilote, prévoyez une fiche de résultat par famille de tâches. Elle indique le nombre de cas, les réponses acceptables, les refus attendus, les incidents critiques et le temps humain nécessaire. Deux configurations peuvent avoir le même score global et des profils très différents : l’une répond mieux aux questions simples, l’autre traite mieux les contradictions documentaires.
La comparaison doit conserver la même base. Si une configuration reçoit davantage de documents ou des accès différents, il faut le signaler. Sinon, le verdict attribue au modèle un avantage qui vient du contexte. Le rapport peut présenter deux comparaisons : à contexte identique pour comprendre le composant, puis en conditions complètes pour décider du service.
Après une recette satisfaisante, démarrez sur un périmètre limité. Le pilote doit permettre une observation réelle, avec une procédure claire pour signaler et corriger une mauvaise réponse. Les utilisateurs doivent savoir quelles sorties nécessitent une validation.
Le suivi repose sur des signaux interprétables : fréquence des corrections, refus injustifiés, demandes abandonnées, incidents d’accès, temps de contrôle et coût par tâche acceptée. La satisfaction déclarée est intéressante, mais elle ne suffit pas à détecter une erreur factuelle discrète.
Les journaux doivent rester proportionnés. Enregistrer toute conversation sans règle de conservation peut créer un nouveau risque de confidentialité. Préférez des identifiants techniques, des catégories d’erreur et des extraits minimaux lorsque cela permet le diagnostic. Les accès aux traces doivent être limités.
Rejouez le jeu de référence après une modification importante. Un changement de modèle, de documentation ou de découpage des textes peut améliorer certaines familles et en dégrader d’autres. Gardez la possibilité de revenir à une configuration connue, avec des versions cohérentes des composants.
Le dossier de décision final doit montrer les cas testés, les limites de l’échantillon, les seuils retenus, les incidents ouverts et les usages effectivement autorisés. Il doit permettre à une personne qui n’a pas participé à la démo de comprendre pourquoi le lancement est acceptable.
Une évaluation utile ne promet pas l’absence d’erreur. Elle transforme une impression en décisions vérifiables : ce que l’assistant peut faire, ce qu’il doit refuser et les preuves qu’il faudra conserver pour continuer à lui confier du travail.
Je suis Romain, rédacteur passionné par tout ce qui touche au high-tech, à la crypto, et à l’innovation. Diplômé d’une école de marketing à Paris, je mets ma plume au service des dernières tendances et avancées technologiques.
