« Ça marche très bien. » C'est la phrase la plus dite sur un système d'IA et la moins défendable. Quelqu'un l'a essayé un moment, lui a posé cinq questions, elles sont bien sorties, et de là à « ça marche » il y a un saut de foi qui se paie cher en production. Comment évaluer un système d'IA en entreprise, ce n'est pas cette impression : c'est mesurer, contre une base, s'il a raison —et combien il se trompe quand ça arrive.
La thèse en une phrase : sans un jeu d'évaluation —ce que le métier appelle des evals— tu ne sais pas si ton IA marche, ça en a juste l'air. « On dirait que ça marche » n'est pas une métrique ; c'est une anecdote avec de la chance. Ce qui sépare un système que tu peux mettre devant un client d'une expérience qui prie pour ne pas échouer, c'est presque toujours s'il y a des evals ou non.
Comment évaluer un système d'IA en entreprise : pourquoi « on dirait que ça marche » n'est pas une métrique
Évaluer un système d'IA en entreprise, c'est comparer ce qu'il répond à ce qu'il devrait répondre, sur un ensemble de cas représentatifs, et en tirer un chiffre. Concrètement : tu réunis un jeu d'entrées réelles —les questions, documents ou tâches qui lui arrivent vraiment—, tu définis la bonne réponse ou le critère de réussite pour chacune, et tu exécutes ce jeu à chaque fois que tu changes quelque chose —le prompt, le modèle, les données. Le résultat est un score qui bouge : il monte quand tu améliores, il baisse quand tu casses quelque chose sans t'en rendre compte. Sans ce chiffre, chaque changement est à l'aveugle et chaque « ça marche » est une opinion.
Ce qu'est un eval (et en quoi ça diffère de « l'essayer un moment »)
Tester un système à la main est utile le premier jour et trompeur le deuxième. Un eval est l'inverse de ce test informel sur trois points :
- Il est représentatif, pas anecdotique. Ce ne sont pas les cinq questions qui te viennent ; ce sont des dizaines ou des centaines de cas réels, y compris les bizarres et ceux qui ont déjà échoué une fois.
- Il est répétable, pas ponctuel. Il s'exécute pareil à chaque changement, donc il compare des pommes avec des pommes : tu sais si la version d'aujourd'hui est meilleure ou pire que celle d'hier, pas si « ça t'a donné une bonne impression ».
- Il donne un chiffre, pas une impression. Un taux de réussite, un taux d'erreur, un taux d'hallucination. Quelque chose que tu peux mettre sur un graphique et surveiller chaque semaine.
La différence entre un système sérieux et une jolie démo, c'est presque toujours si ce chiffre existe. Le comment technique de le monter —le jeu, les critères, la boucle— on le détaille dans le guide sur comment entraîner un agent IA : données, evals et gouvernance ; ici, ce qui compte, c'est pourquoi sans lui tu es à l'aveugle.
Quoi mesurer : les quatre choses qui séparent la production de la foi
Pas besoin de tout mesurer dès la première minute. Quatre métriques t'en disent plus sur ton système que la plupart des projets en marche depuis des mois :
- Taux de réussite. Des cas du jeu, combien il répond correctement selon ton critère. C'est la métrique mère ; si tu ne l'as pas, tu n'as rien.
- Taux d'erreur et d'hallucination. Combien il a raison ne suffit pas : ce qui compte, c'est combien il se trompe avec aplomb. Un système juste à 90 % mais qui invente les 10 % restants avec une assurance totale peut être pire qu'un plus humble.
- Couverture des cas limites. Quel pourcentage des cas bizarres —ceux qui cassent les systèmes faibles— passent par l'eval. Ce qui n'est pas dans le jeu n'est pas mesuré, et ce qui n'est pas mesuré se dégrade en silence.
- Dérive dans le temps. Le même eval, exécuté chaque semaine. Un système d'IA ne reste pas immobile : l'entrée change, les prompts se dégradent, le fournisseur met à jour le modèle. La dérive se voit sur le graphique avant de se voir dans la réclamation du client.
L'erreur de ne pas avoir d'evals dès le premier jour
L'échec le plus cher n'est pas d'avoir de mauvais evals : c'est de n'en avoir aucun. Un système sans mesure n'échoue pas le jour du lancement —il échoue lentement, et personne ne s'en aperçoit jusqu'à ce que l'erreur atteigne le client. Sans un chiffre de base, tu ne peux pas prouver qu'il s'améliore, tu ne peux pas défendre la dépense devant la direction, et tu ne peux pas distinguer un changement qui aide d'un qui casse. C'est, de fait, une des causes nommées pour lesquelles les projets d'automatisation avec l'IA échouent : zéro mesure, zéro moyen de savoir si le projet est encore vivant ou un zombie que personne n'ose éteindre.
Les evals, ce n'est pas un projet, c'est une habitude
Le piège est de traiter les evals comme une phase (« on les montera à la fin »). À la fin, c'est trop tard : le système est déjà en production, à prendre des décisions que tu ne peux pas auditer. Le pas cher et le sensé, c'est l'inverse —commencer par un petit jeu dès le premier jour et le faire grandir à chaque cas bizarre qui apparaît. Ce n'est pas un livrable qu'on signe et qu'on oublie ; c'est la routine qui garde le système honnête.
Bien mesurer n'est pas glamour, mais c'est la seule chose qui transforme « on croit que ça marche » en « on sait que ça marche ». Si tu vas mettre l'IA au travail dans ton entreprise et que tu veux que ça tienne, c'est un fondement, pas un décor —et c'est exactement ce qu'on monte dans l'infrastructure d'IA d'entreprise : le système, ses evals et la boucle qui le garde mesuré dans le temps. On ne te laisse pas une IA qui a l'air de marcher ; on te laisse une IA dont tu peux prouver qu'elle marche —ou dont tu sais exactement où elle échoue.