Le constat : « il a l'air de bien marcher » est le niveau d'évaluation le plus répandu — et il ne permet ni de détecter une dégradation, ni de justifier un élargissement, ni de comparer deux approches.
Un logiciel classique fait la même chose à chaque exécution : on le teste une fois, il reste conforme. Un agent IA métier ne fonctionne pas ainsi. Sa qualité varie selon les formulations, les données du moment et les évolutions du modèle sous-jacent. Sans dispositif d'évaluation, une entreprise découvre une dérive par une réclamation client — c'est-à-dire trop tard. Voici comment construire une évaluation qui tienne, sans monter une usine à gaz.
1. Pourquoi l'impression générale ne suffit pas
Les premiers jours d'un déploiement produisent presque toujours un enthousiasme. L'agent traite des cas, les résultats semblent pertinents, l'équipe est impressionnée. Le problème est que cette phase repose sur une observation biaisée : on teste surtout des cas simples, on regarde attentivement, et on corrige mentalement les approximations sans les noter.
Trois mois plus tard, l'attention a baissé, le volume a augmenté, le catalogue produit a changé, et personne ne sait dire si la qualité est restée la même. Les dégradations d'un système IA sont rarement spectaculaires — elles sont graduelles, et c'est précisément ce qui les rend difficiles à repérer sans mesure.
« Un agent IA ne tombe pas en panne. Il se met à avoir un peu moins souvent raison — et sans jeu de test, personne dans l'entreprise n'est en mesure de le remarquer. »
Ce qui peut changer sans que vous n'ayez rien touché
- Les données sources évoluent : nouveaux produits, tarifs révisés, procédures modifiées
- Les cas d'entrée changent de nature : nouveaux types de demandes, nouveau segment de clients
- Le modèle sous-jacent est mis à jour par son éditeur, avec des comportements légèrement différents
- Les utilisateurs adaptent leurs formulations et sortent du cadre anticipé
2. Construire un jeu de test métier
Le socle de toute évaluation sérieuse est un ensemble de cas réels dont on connaît la bonne réponse. Ce n'est pas un dispositif technique complexe : c'est un document de travail, souvent un simple tableur, mais c'est le seul moyen d'objectiver la qualité.
Combien de cas, et lesquels
Une trentaine à une cinquantaine de cas suffit largement pour démarrer sur un processus unique. Ce qui compte n'est pas le nombre mais la répartition : le jeu doit refléter la réalité du flux, pas seulement les situations confortables.
- Des cas standards : ceux qui représentent le gros du volume quotidien
- Des cas limites : ceux où l'expert métier hésite lui-même, ou applique une règle particulière
- Des cas hors périmètre : ceux où la bonne réponse est « je ne sais pas » ou « à transmettre à un humain »
- Des cas pièges : information absente, demande ambiguë, donnée contradictoire entre deux sources
Cette dernière catégorie est la plus révélatrice. Un agent qui invente une réponse plausible quand l'information n'existe pas est bien plus dangereux qu'un agent qui admet son ignorance. C'est un comportement qu'on ne détecte qu'en le testant explicitement.
Qui écrit les réponses attendues
La personne qui exerce le métier, pas l'équipe technique. C'est elle qui sait ce qu'est une bonne réponse dans le contexte de l'entreprise. Ce travail rejoint directement celui de formalisation des règles implicites : le jeu de test et le corpus de cas commentés sont souvent le même livrable.
Un jeu de test utile tient en 4 colonnes
- Le cas d'entrée : la demande réelle, telle qu'elle arrive
- La réponse attendue : ce que produirait l'expert métier
- Le point critique : ce qui doit absolument figurer ou ne pas figurer
- La catégorie : standard, limite, hors périmètre, piège
3. Ce qu'il faut mesurer, au-delà du « bon / pas bon »
Un verdict binaire sur chaque cas donne un pourcentage de réussite, ce qui est déjà utile. Mais quelques dimensions supplémentaires changent la nature de l'information obtenue.
L'exactitude factuelle
Les éléments vérifiables de la réponse — un montant, une date, une référence, un nom — correspondent-ils à la source ? C'est le critère le plus important et le plus facile à contrôler. Une réponse bien tournée contenant un chiffre faux est un échec, pas une réussite partielle.
La traçabilité
L'agent cite-t-il l'origine de ce qu'il avance, et cette source dit-elle réellement ce qu'il lui fait dire ? Ce second point mérite un contrôle spécifique : citer un document existant tout en déformant son contenu est une erreur fréquente et difficile à repérer par un lecteur pressé.
Le comportement face à l'inconnu
Sur les cas où l'information n'est pas disponible, l'agent le dit-il clairement, ou produit-il une réponse vraisemblable ? C'est la mesure qui prédit le mieux le niveau de confiance qu'on peut accorder au système en production.
La stabilité
La même question posée deux fois, ou formulée légèrement différemment, produit-elle des réponses cohérentes entre elles ? Une forte variabilité indique un cadrage insuffisant et rend l'agent difficile à faire accepter par les équipes.
4. Passer de l'évaluation ponctuelle au suivi continu
Un jeu de test passé une fois avant la mise en production ne protège de rien. L'intérêt vient de la répétition : c'est la comparaison dans le temps qui révèle les dérives.
Rejouer le jeu de test à chaque changement
Toute modification — nouvelle version du modèle, ajustement des instructions, ajout de sources documentaires, évolution du catalogue — justifie de rejouer l'ensemble des cas. C'est l'équivalent des tests de non-régression en développement logiciel, et ça remplit exactement la même fonction : vérifier qu'en corrigeant un point, on n'en a pas cassé trois autres.
Exploiter les rejets de la validation humaine
Si votre agent fonctionne avec un point de validation humaine, les refus constituent une source d'évaluation continue et gratuite. Le taux de rejet et surtout ses motifs indiquent en temps réel où le système décroche. Chaque rejet récurrent mérite de devenir un nouveau cas dans le jeu de test.
Surveiller quelques signaux simples en production
- Le taux de reprise : proportion de résultats modifiés avant usage
- Le taux d'escalade : proportion de cas transmis à un humain — une hausse soudaine signale un changement dans les entrées
- Les cas sans réponse : leur nature indique souvent un manque documentaire précis à combler
- Le délai de traitement : une dégradation peut révéler un problème d'infrastructure autant qu'un changement de comportement
Ces indicateurs se suivent avec des moyens légers. L'important n'est pas la sophistication de l'outillage mais la régularité du regard porté dessus — un point de suivi mensuel vaut mieux qu'un tableau de bord temps réel que personne ne consulte.
5. Les métriques qui trompent
Certaines mesures rassurent sans rien garantir. Il vaut mieux les connaître pour ne pas fonder de décision dessus.
Le taux de satisfaction déclaré
Demander aux utilisateurs s'ils sont satisfaits mesure l'expérience, pas l'exactitude. Un agent qui répond vite, poliment et avec assurance obtient de bons retours même quand il se trompe — surtout si l'utilisateur n'a pas les moyens de vérifier. La satisfaction est un indicateur d'adoption utile, jamais un indicateur de qualité.
Le volume traité
Le nombre de demandes traitées mesure l'activité, pas la valeur. Un agent qui traite un fort volume en produisant des résultats systématiquement repris derrière détruit du temps au lieu d'en gagner. Le volume n'a de sens que rapproché du taux de reprise.
Les scores automatiques de similarité
Comparer automatiquement la réponse produite à une réponse de référence donne un score commode, mais qui passe à côté de l'essentiel : une réponse formulée différemment peut être excellente, et une réponse presque identique peut contenir l'unique erreur qui compte. Sur un processus métier, le jugement humain sur un échantillon reste plus fiable qu'un score global.
La question qui prime sur toutes les métriques
- Sur les cas où l'agent se trompe, l'erreur est-elle détectable par la personne qui reçoit le résultat ?
- Si oui, le système est exploitable même imparfait. Si non, aucun taux de réussite ne suffit à le rendre sûr.
6. Ce que l'évaluation permet de décider
Mesurer n'est pas une fin. L'intérêt d'un dispositif d'évaluation est qu'il autorise des décisions qu'on ne peut pas prendre autrement.
Élargir le périmètre. Passer d'un régime de validation bloquante à une supervision allégée sur une catégorie de cas suppose de démontrer la fiabilité sur cette catégorie. Sans historique mesuré, cet assouplissement reste un pari — et il sera soit refusé indéfiniment, soit accordé à l'aveugle.
Arbitrer techniquement. Comparer deux approches, deux modèles ou deux façons de structurer les données n'a de sens que sur une base commune. Le jeu de test rend ces comparaisons factuelles au lieu de les laisser au débat d'opinions — un point utile notamment pour arbitrer entre fine-tuning, RAG et prompting.
Justifier la dépense. Un dirigeant qui finance un deuxième déploiement veut savoir ce qu'a produit le premier. Le taux de reprise et son évolution racontent une histoire vérifiable, là où une impression favorable ne convainc personne au moment de l'arbitrage budgétaire. C'est également ce qui permet de raisonner sérieusement sur le coût réel d'un usage IA.
Documenter la maîtrise. Pour les usages soumis à des obligations réglementaires, être capable de montrer comment on contrôle la qualité d'un système automatisé n'est plus optionnel — un sujet traité dans notre article sur l'AI Act pour les PME.
Chez Lewis, le jeu de test se construit pendant le cadrage, pas après la mise en production. C'est ce qui permet de savoir quand un agent est prêt — et d'éviter la situation, courante, où personne ne sait dire si le projet est terminé.