Pourquoi une IA « qui marche » peut se tromper une fois sur deux
Une IA qui impressionne en réunion peut, sur le terrain, répondre juste une fois sur deux, sans que personne ne s’en rende compte. La raison n’est presque jamais le modèle : c’est qu’on a jugé la fiabilité au ressenti, jamais à la mesure. Et ce qui ne se mesure pas ne se corrige pas. La bonne nouvelle, c’est que dès qu’on mesure, on voit où ça casse, et on le répare, souvent à moindre coût.
La scène est classique. Une démonstration bluffe tout le monde : l’assistant répond vite, bien, avec assurance. On déploie. Trois mois plus tard, les équipes l’utilisent du bout des doigts, parce qu’« il dit parfois n’importe quoi ». Personne ne sait vraiment à quelle fréquence. C’est tout le problème.
Pourquoi une démonstration réussie ne prouve rien
Une démo, c’est une poignée de questions choisies, dans des conditions idéales. La production, c’est des centaines de cas par jour, dont beaucoup que personne n’avait anticipés : formulations ambiguës, sujets en bordure du périmètre, questions pièges posées de travers. Un assistant peut être brillant sur les cas faciles et s’effondrer sur les cas sensibles, précisément ceux qui comptent.
Tant qu’on regarde l’IA répondre « à l’œil », on voit surtout les bons cas. Les erreurs, elles, passent sous le radar : elles sont diluées, rarement signalées, et chaque utilisateur croit que la sienne est une exception.
La fiabilité d’une IA, ça se mesure comment ?
Comme on mesure n’importe quel processus : avec un échantillon représentatif et une définition claire de « juste ». On rassemble des cas réels, on définit la bonne réponse attendue pour chacun, et on confronte l’IA à cet échantillon, encore et encore. On en sort trois chiffres que tout décideur peut comprendre :
- La justesse : sur 100 cas, combien sont vraiment corrects ?
- La stabilité : la même question posée deux fois donne-t-elle la même qualité de réponse ?
- Le coût : combien coûte une réponse, et peut-on le réduire sans perdre en qualité ?
Cette discipline, mesurer avant de généraliser, porte un nom : l’approche eval-driven. Elle transforme un débat d’opinions (« je trouve qu’elle répond bien ») en un constat partagé (« elle est juste à 81 %, et voici les 19 % à corriger »).
Et si la cause n’était pas le modèle, mais vos données ?
C’est le contre-pied le plus utile à retenir. Quand une IA répond mal, le réflexe est d’incriminer le modèle, ou d’en vouloir un « plus puissant ». Dans la grande majorité des cas, la cause est ailleurs : dans les données qu’on lui donne à lire : une base de connaissances incomplète, mal structurée, contradictoire. Changer de modèle ne corrige pas une donnée défaillante. La mesure, elle, pointe la cause racine : on voit quels cas échouent, et pourquoi.
Concrètement, ça donne quoi ?
Un éditeur de logiciel IA, dans un domaine expert et réglementé, avait un assistant qui répondait juste une fois sur deux sur ses cas les plus sensibles. En appliquant cette méthode (mesurer, trouver la cause racine dans la donnée, corriger ce qui compte), la justesse est passée de 53 % à 81 % (+28 points), avec les cas critiques ramenés à 100 %. Le tout pour environ 18 USD de calcul et deux correctifs ciblés. Pas un modèle plus cher : deux corrections au bon endroit, rendues visibles par la mesure.
Ce qu’un décideur peut en retenir
Avant de déployer une IA largement, ou avant de conclure que « la vôtre ne marche pas », posez une seule question : quel est son taux de justesse mesuré, sur nos vrais cas ? Si personne ne sait répondre, vous ne pilotez pas votre IA, vous l’espérez. Et c’est exactement là que tout commence.
Si vous avez une IA en production dont vous n’êtes pas sûr, c’est le bon moment pour en parler.