Pourquoi un assistant IA ne se recette pas comme un logiciel
Un logiciel classique est déterministe : la même entrée produit toujours la même sortie. On le vérifie en relisant le code et en jouant des scénarios. Un système fondé sur un modèle de langage ne fonctionne pas ainsi. La même question posée deux fois peut produire deux formulations différentes, et une reformulation anodine peut faire basculer une bonne réponse en mauvaise.
La conséquence est simple et pourtant presque jamais tirée : on ne peut pas qualifier un assistant par une revue de code. On doit le caractériser statistiquement. C'est-à-dire lui poser un grand nombre de questions dont on connaît la bonne réponse, et compter.
C'est exactement ce que fait l'ingénierie de systèmes critiques depuis quarante ans sur des équipements non déterministes. Ce n'est pas une pratique nouvelle. Elle est simplement absente du marché de l'IA d'entreprise, où l'usage veut qu'on livre une démonstration réussie et qu'on appelle ça une preuve.
Une démonstration prouve qu'un système peut réussir. Une recette mesure à quelle fréquence il échoue, et sur quoi.
Les deux sont utiles. Un seul des deux engage celui qui livre.
Construire le jeu de référence
Le jeu de référence est l'ensemble des questions sur lesquelles le système sera jugé. Il se construit avant le développement, avec les équipes qui utiliseront l'outil. Jamais par le prestataire seul, sinon il teste ce qu'il sait faire.
Sa construction suit quatre règles.
- Partir de questions réellement posées. Historique de tickets, messages d'équipe, questions récurrentes aux experts. Pas de questions inventées : elles sont toujours trop propres.
- Annoter la bonne réponse et sa source. Pour chaque question : la réponse attendue, et le document qui la contient. Sans source annotée, on ne peut pas distinguer une bonne réponse d'une bonne réponse inventée.
- Inclure les questions sans réponse. Une partie du jeu doit porter sur des sujets absents du corpus. Le comportement attendu est alors « je ne sais pas ». Un assistant qui répond quand même est plus dangereux qu'un assistant muet.
- Viser 40 questions minimum, 150 en régime établi. En dessous de 40, l'intervalle de confiance est trop large pour conclure quoi que ce soit. Au-delà de 150, le coût d'annotation dépasse le bénéfice pour un premier déploiement.
Classer les questions par catégorie
Un taux global de bonne réponse ne sert à rien. « 84 % » ne dit pas si les 16 % d'échecs sont des cas rares et sans gravité, ou la moitié des questions les plus fréquentes du support.
Le jeu de référence se découpe donc en catégories, et le taux se mesure par catégorie. Le découpage varie selon le métier, mais revient souvent à ceci.
| Catégorie | Ce qu'elle contient | Attendu réaliste |
|---|---|---|
| Procédure standard | Question directe dont la réponse est écrite noir sur blanc dans un document. | Élevé |
| Référence produit | Recherche d'une valeur, d'une pièce, d'un paramètre précis. | Élevé |
| Cas limite | Panne rare, configuration inhabituelle, réponse dispersée dans plusieurs sources. | Moyen |
| Question ambiguë | Formulation incomplète, plusieurs interprétations possibles. | Faible |
| Hors corpus | Aucune source ne couvre le sujet. Le seul bon comportement est le refus. | Doit être élevé |
La dernière ligne est la plus importante et la plus négligée. Un système qui obtient 95 % sur les procédures standard mais qui invente une réponse chaque fois qu'il ne sait pas est inutilisable en support technique : personne ne peut plus faire confiance à aucune de ses réponses.
Écrire les critères d'acceptation avant de développer
Un critère d'acceptation est une phrase de la forme : « le système est accepté si, sur la catégorie X, le taux de bonne réponse atteint Y % et le taux de réponse inventée reste sous Z % ».
Écrits avant le développement, ces critères transforment la livraison en constat. Écrits après, ils s'ajustent au résultat obtenu et ne prouvent plus rien.
Trois critères suffisent pour un premier déploiement :
- Un seuil de bonne réponse par catégorie, différencié : on n'attend pas le même niveau sur une procédure standard et sur un cas limite.
- Un plafond de réponses non sourcées : toute réponse qui ne cite pas un document du corpus est comptée en échec, même si elle est juste.
- Un seuil de refus correct sur les questions hors corpus.
Exécuter la campagne et lire le rapport
La campagne consiste à rejouer l'intégralité du jeu de référence et à comparer chaque réponse à la réponse annotée. Elle est automatisée : sans automatisation, elle n'est jouée qu'une fois, et l'intérêt disparaît.
Le rapport remis contient, par catégorie : le nombre de questions testées, le taux de bonne réponse, le taux de réponse non sourcée, et la liste nominative des échecs avec la réponse produite et la réponse attendue.
Cette dernière partie est celle qui a le plus de valeur. Une liste d'échecs se lit en vingt minutes et dit précisément où placer la confiance, et où mettre une relecture humaine obligatoire.
Le chiffre le plus bas du rapport est le plus utile. Il indique où le système ne doit pas être laissé seul.
La non-régression, ou ce qui casse six mois plus tard
Un assistant qui fonctionne à la livraison ne fonctionne pas indéfiniment. Trois choses le dégradent silencieusement :
- Le modèle change. Le fournisseur met à jour sa version, et le comportement se déplace, parfois en mieux, parfois pas.
- Le corpus change. On ajoute des documents, on en retire, on réorganise une arborescence. La recherche ne remonte plus les mêmes sources.
- Les consignes changent. Quelqu'un ajuste une instruction pour corriger un cas, et casse trois cas qui fonctionnaient.
La non-régression consiste à rejouer la campagne à chaque évolution et à comparer avec la précédente. C'est une opération de quelques minutes lorsqu'elle est outillée, et c'est ce qui distingue un outil maintenu d'un outil qui se dégrade sans que personne ne s'en aperçoive, jusqu'au jour où les équipes cessent de l'utiliser sans le dire.
Cinq erreurs qui rendent une recette inutile
- Tester avec des questions écrites par celui qui a construit le système. Elles épousent ce qu'il a prévu.
- Ne mesurer qu'un taux global. Il masque exactement l'information qui compte.
- Ne pas tester le refus. C'est le comportement le plus important et le moins testé du marché.
- Juger la réponse « à l'œil ». Sans réponse attendue annotée, l'évaluation dérive vers « ça a l'air bien ».
- Ne jouer la campagne qu'une fois. Une mesure sans répétition n'est pas une mesure, c'est une anecdote.
Questions fréquentes
Combien de questions faut-il pour une recette sérieuse ?
Quarante au minimum pour qu'un taux ait un sens statistique, cent cinquante en régime établi. En dessous de quarante, l'intervalle de confiance est si large que deux campagnes successives peuvent donner des résultats opposés sans qu'aucune évolution réelle ne se soit produite.
Qui doit écrire les questions de test ?
Vos équipes, pas nous. Un jeu de test écrit par le prestataire teste ce que le prestataire a prévu. Nous animons la session d'annotation et nous outillons le processus, mais les questions viennent de votre historique de tickets et de vos experts.
Combien de temps prend une campagne de recette ?
La construction du jeu de référence prend trois à cinq jours, essentiellement du temps de vos équipes pour annoter. Une fois le harnais en place, l'exécution d'une campagne complète prend quelques minutes et peut être rejouée à chaque évolution.
Que se passe-t-il si les résultats sont mauvais ?
Vous le savez avant la mise en service, ce qui est précisément l'objet de la démarche. Un résultat faible sur une catégorie conduit soit à enrichir le corpus, soit à restreindre le périmètre de l'assistant, soit à imposer une relecture humaine sur cette catégorie. Dans certains cas, il conduit à ne pas déployer, et c'est un bon résultat.
Faites-vous la recette de systèmes que vous n'avez pas construits ?
Oui. La recette d'un assistant existant, construit en interne ou par un autre prestataire, est une mission à part entière. Elle produit le même livrable : jeu de référence, taux par catégorie, liste des échecs, critères d'acceptation.