Fiabiliser l'IA générative : construire son banc d'essai

Faites l'essai. Posez à votre assistant d'IA générative préféré une question pointue sur un sujet que vous maîtrisez parfaitement. La réponse arrive en quelques secondes, bien construite, sûre d'elle. Vous repérez immédiatement ce qui est juste et ce qui ne l'est pas. Maintenant, posez-lui une question sur un domaine que vous ne connaissez pas. La réponse a exactement la même allure. Même fluidité, même assurance, même mise en forme soignée. Comment savez-vous si elle est juste ?

Vous ne le savez pas. Et c'est tout le problème.

L'IA générative est installée dans les processus, dans les outils métier, entre les mains de collaborateurs qui n'ont aucune raison de se demander comment elle fonctionne. Pourtant, dans la plupart des organisations que nous accompagnons, la validation des réponses repose toujours sur le même geste qu'au premier jour : on lit, on trouve que « ça a l'air correct », on passe à la suite.

Nos missions nous ont forgé une conviction : tant qu'une réponse d'IA n'a pas passé plusieurs points de validation, il faut la traiter comme une simple hypothèse. Ce contrôle n'a rien d'inaccessible. Il s'organise, avec des méthodes qui existent déjà ailleurs en ingénierie.

• Ce premier volet pose la démarche. Pourquoi notre œil de lecteur est un mauvais instrument de contrôle, et par quoi le remplacer.
• Le deuxième volet raconte une mission réelle. Un assistant documentaire de type RAG (une IA qui va chercher la réponse dans les documents de l'entreprise avant de la rédiger) que nous avons fait passer d'1 réponse fiable sur 2 à plus de 9 sur 10, sans changer de modèle.
• Le troisième volet s'attaque au terrain le plus difficile. Les systèmes agentiques, ces IA qui ne se contentent plus de répondre mais enchaînent des actions.

L'erreur crédible circule sans que personne la remette en cause

Toutes les technologies font des erreurs, et l'informatique d'entreprise a appris depuis longtemps à vivre avec. Un traitement qui plante, une API qui renvoie une erreur, un écran qui affiche n'importe quoi : c'est ennuyeux, mais c'est visible, donc c'est gérable. Quelqu'un s'en aperçoit, ouvre un ticket, et on corrige.

L'IA générative introduit une catégorie d'erreur beaucoup plus sournoise : la réponse crédible et fausse. Celle-là, personne ne la remet en cause. Elle est bien écrite, elle cite des chiffres, elle a le ton de l'expertise. Alors elle circule. Elle est copiée dans une note interne, reprise dans une présentation, et elle finit par nourrir une décision. Le jour où quelqu'un remonte à la source, si ce jour arrive, plus personne ne sait d'où venait le chiffre.

C'est pour cela que, sur les missions que nous menons, un projet d'IA bascule vers quelque chose de sérieux le jour où l'équipe se dote d'un moyen de savoir si les réponses sont bonnes. Tant que ce moyen n'existe pas, on peut faire de belles démonstrations, mais on ne peut pas passer à l'échelle : personne ne saurait dire ce qui se dégrade, ni à partir de quand.

Le relecteur juge la forme en croyant juger le fond

Face à ce risque, la réaction naturelle des organisations est de demander aux utilisateurs de « rester vigilants » et de « bien relire ». Cela part d'une bonne intention, mais cela ne peut pas fonctionner.

Quand nous lisons une réponse, nous évaluons spontanément deux choses : est-ce bien écrit, et est-ce cohérent avec ce que nous croyons déjà savoir. Ces deux jugements portent sur la forme. Or un grand modèle de langage (un LLM, la technologie qui motorise l'IA générative) est entraîné précisément à produire la suite de mots la plus vraisemblable. Produire du texte qui a l'air juste, c'est littéralement sa fonction. Il excelle donc à paraître exact, y compris quand il ne l'est pas. Une date inventée au milieu d'un paragraphe par ailleurs impeccable ne sonne pas faux à la lecture. Rien n'accroche l'œil.

On demande ainsi au relecteur de repérer ce qu'une technologie a été conçue pour dissimuler.

Juger à l'instinct revient à mesurer la forme en croyant mesurer le fond.

Il faut donc autre chose que de la vigilance. Il faut un dispositif qui aille vérifier, indépendamment de la qualité rédactionnelle, si une réponse est ancrée dans les faits. Voyons à quoi il ressemble.

Un banc d'essai pour l'IA, comme il en existe pour n'importe quelle pièce d'ingénierie

L'image qui nous guide sur nos missions vient de l'ingénierie classique. Un ingénieur mécanique ne valide jamais une pièce parce qu'elle « a l'air solide ». Il la pose sur un banc d'essai, lui applique un protocole reproductible (les mêmes contraintes, dans les mêmes conditions, à chaque fois) et il lit des mesures. Si la pièce évolue, on la repasse au banc, et on compare les chiffres.

Ce banc d'essai manque à la plupart des projets d'IA générative, et rien n'empêche de le construire. La démarche ne dépend ni du modèle choisi ni de la pile technique.

1. Construire une première version du système, même imparfaite. À ce stade, la qualité importe peu. Ce qu'il faut, c'est quelque chose de complet et d'exécutable, sur lequel on pourra mesurer.
2. Mesurer sa qualité sur un référentiel stable. Le même jeu de cas, les mêmes critères, à chaque passage : c'est cette stabilité qui rend deux versions comparables entre elles.
3. Améliorer en agissant sur les paramètres que la mesure a désignés, et seulement ceux-là. On change un élément, on remesure, on vérifie que le gain est réel et qu'on n'a rien dégradé ailleurs.
4. Généraliser la méthode au cas d'usage suivant. Le contenu du référentiel change, la mécanique reste la même.

C'est la répétition de cette boucle, et non un passage unique, qui transforme une expérimentation en capacité maîtrisée.

Énoncée comme cela, la boucle a l'air évidente, et nos interlocuteurs y adhèrent sans réserve quand nous la présentons. Puis elle reste sur l'étagère, parce que tout se joue sur le deuxième temps, celui qui demande un vrai effort.

Mesurer suppose un référentiel, et c'est l'effort que tout le monde saute

Mesurer, cela veut dire disposer d'un référentiel.

D'abord, un jeu de questions représentatives de ce que les utilisateurs demanderont vraiment. Pas les dix questions de la démo, celles qui marchent toujours. Les vraies : les questions mal formulées, les questions dont la réponse est éparpillée dans plusieurs documents, et même les questions auxquelles le système ne devrait pas savoir répondre, car savoir dire « je ne sais pas » fait partie de la fiabilité.

Ensuite, pour chaque question, une réponse de référence, rédigée et validée par une personne du métier. C'est elle qui servira d'étalon.

Enfin, des critères de notation explicites, écrits noir sur blanc, suffisamment précis pour que deux évaluateurs différents attribuent la même note à la même réponse.

Constituer ce référentiel prend du temps, et mobilise des experts métier qui ont d'autres choses à faire. La plupart des organisations sautent donc l'étape, et leurs projets restent des expérimentations. Ce référentiel est pourtant ce qui transforme un démonstrateur en système qu'on peut piloter. Il n'est jamais figé : les usages évoluent, de nouveaux documents entrent dans la base de connaissance, des questions nouvelles remontent du terrain. Sans mise à jour régulière, le système de contrôle devient obsolète, et c'est au métier d'en garder le pilotage.

Et cet investissement rapporte deux fois. Avant la mise en production, le référentiel répond à la question « peut-on livrer cette version ? ». Après la mise en production, les mêmes contrôles peuvent être installés dans l'application elle-même, sous forme de quality gates : des points de passage qui vérifient en continu que le système reste dans les clous, et qui interceptent une dérive avant qu'elle n'atteigne l'utilisateur. La question devient alors « peut-on continuer ? ». Les deux volets suivants montrent ce double usage à l'œuvre.

La mesure a fait passer un assistant d'une réponse fiable sur deux à plus de neuf sur dix

Nous avons repris un assistant documentaire déjà en service chez un client, branché sur un corpus de plusieurs centaines de pages réglementaires. L'assistant fonctionnait, au sens où il répondait toujours quelque chose. Mais quand nous avons demandé s'il répondait bien, personne n'a pu nous répondre. Le seul indicateur disponible était le ressenti de quelques utilisateurs, sur quelques questions.

Nous avons construit un banc d'essai composé d'environ 140 questions métier, chacune associée à une réponse de référence validée et à des critères d'évaluation. Le processus a été rapide : deux semaines ont suffi pour recueillir questions et réponses auprès des experts, puis finaliser la construction du banc. Les premières évaluations ont révélé que l'assistant produisait une réponse fiable sur deux.

Puis nous avons déroulé la boucle. Nous avons mesuré chaque modification avant et après, sur le même banc. En deux grandes étapes d'optimisation, la fiabilité est montée à plus de 9 réponses sur 10. Le modèle de langage, lui, n'a pas changé. Tout le gain est venu de la méthode : mesurer, identifier le maillon faible, le corriger, remesurer.

L'IA qui répond et l'IA qui agit se mesurent différemment

La démarche que nous venons de décrire vaut pour tous les usages de l'IA générative. En revanche, elle ne se déploie pas avec la même facilité partout.

Il y a d'abord l'IA qui répond. C'est le cas de l'assistant de notre exemple, et de tous les systèmes bâtis sur une architecture RAG (Retrieval-Augmented Generation, « génération augmentée par la récupération ») : le système récupère les passages pertinents dans les documents de l'entreprise, puis demande au modèle de rédiger à partir d'eux. Ici, l'objet à évaluer est bien délimité : une réponse, face à une question, sur un corpus connu. L'exercice est exigeant, mais on sait le faire.

Il y a ensuite l'IA qui agit, ce qu'on appelle les systèmes agentiques. Là, le système enchaîne des étapes, appelle des outils, prend des décisions, modifie des données. Et il ne le fait jamais deux fois de la même façon : soumis deux fois à la même demande, il empruntera deux chemins différents. Du coup, examiner le résultat final ne suffit plus. Il faut évaluer la trajectoire, c'est-à-dire l'ensemble du chemin parcouru. C'est la frontière actuelle de la discipline, et le sujet du troisième volet.

La fiabilité se construit chez vous

Aucun fournisseur ne livrera la fiabilité en option de son modèle. La fiabilité est une propriété du dispositif que vous construisez autour.

Ce travail d'ingénierie est à la portée d'une DSI, appliqué à un objet nouveau. Le deuxième volet le montre sur le cas réel de notre assistant documentaire : comment nous avons construit le banc d'essai, ce que la première mesure a révélé, quels leviers nous avons actionnés, et les surprises rencontrées en route, car il y en a eu.