Retour aux analyses
insights6 min

Évaluation de l’IA : un bon score peut cacher une mauvaise méthode

Note exécutive TokenShift

Évaluation de l’IA : un bon score peut cacher une mauvaise méthode

Imaginons un assureur qui veut aider ses gestionnaires à repérer les sinistres nécessitant une expertise, dès l’ouverture du dossier. Pour tester son IA, il utilise des dossiers anciens, dont il connaît la suite. Le score paraît convaincant.

Mais le fichier contient aussi des renseignements ajoutés après l’expertise. Si l’IA s’en sert, elle dispose, pendant le test, d’informations que le gestionnaire n’aura pas au moment de décider.

Cet exemple est hypothétique. Il montre pourtant pourquoi un bon score ne suffit pas à autoriser un déploiement : il faut comprendre comment il a été obtenu et ce qu’il permet réellement de conclure.

Une IA qui connaît déjà la suite de l’histoire

Dans notre exemple, l’assureur cherche à anticiper un besoin d’expertise. Or, en donnant au modèle des informations recueillies après cette expertise, il lui facilite artificiellement la tâche. Le test ne reproduit plus le travail attendu.

C’est une forme de « fuite de données ». Ici, le mot ne désigne pas un vol d’informations. Il signifie que des données auxquelles le modèle ne devrait pas avoir accès influencent sa construction ou son évaluation. La documentation de scikit-learn explique comment ce défaut peut donner une estimation trop optimiste des performances. scikit-learn, documentation consultée en octobre 2026.

Une prépublication du Centrum Wiskunde & Informatica, déposée le 9 octobre 2026, illustre le problème. Les chercheurs ont étudié des agents d’IA chargés de réaliser des travaux de science des données sur 220 tâches. Dans les configurations examinées, certaines fuites de données étaient associées à de meilleurs scores prédictifs. Une méthode défectueuse pouvait donc sembler plus performante. Ce travail ne mesure pas la fréquence du problème dans les entreprises. CWI, 2026.

Pour l’assureur, la vérification consiste à reprendre chaque dossier tel qu’il était à son ouverture. Il faut distinguer ce qui était connu à cet instant de ce qui a été appris ensuite. La date d’extraction du fichier ne répond pas à cette question : un fichier extrait aujourd’hui peut mélanger plusieurs étapes de la vie d’un sinistre.

Tant que cette chronologie n’est pas respectée, le score ne permet pas de savoir si l’outil aidera les gestionnaires sur de nouveaux dossiers.

Pouvoir retrouver ce qui a été testé

Supposons maintenant que l’assureur ait corrigé son fichier et relancé l’évaluation. Le comité reçoit une présentation annonçant une « qualité satisfaisante ». Pour juger ce résultat, il doit pouvoir retrouver les dossiers examinés, ceux qui ont été écartés, la définition d’une bonne réponse et la version de l’outil utilisée.

Sans ces éléments, il reste difficile de distinguer un test solide d’un test incomplet.

Cette difficulté apparaît aussi dans la recherche. Dans une étude publiée dans le BMJ le 13 octobre 2026, David Chen et ses coauteurs ont examiné notamment 68 comptes rendus d’essais cliniques utilisant de grands modèles de langage. Ils relèvent des informations manquantes sur les versions des modèles, leurs réglages et le traitement des données en entrée et en sortie. Chen et coll., 2026, notice de l’université de Birmingham.

Une méthode mal décrite n’est pas nécessairement mauvaise. Mais les informations manquantes empêchent de l’apprécier correctement. Ces observations concernent la recherche clinique ; elles ne donnent pas un taux de défaillance applicable à l’assurance ou à l’industrie.

Dans notre exemple, nous recommandons de faire examiner le test par une personne compétente, distincte de l’équipe qui améliore le modèle. Elle doit pouvoir retrouver les données, les instructions, les documents et les outils utilisés, puis demander un nouvel essai si nécessaire. Le choix du fournisseur doit donc aussi tenir compte de l’accès à ces traces et de la façon dont il signale les changements de son système.

Le comité peut financer cette vérification. Il doit simplement garder visible la différence entre un résultat validé, un échec constaté et une question encore sans réponse.

Suivre les conséquences jusque dans le travail des équipes

Une fois le test vérifiable, reste à savoir ce que son score signifie pour les gestionnaires.

Dans notre exemple, l’IA peut manquer un dossier qui nécessite une expertise. Elle peut aussi envoyer inutilement un dossier simple à un expert. Ces erreurs n’ont pas les mêmes conséquences. Les réunir dans un score global masque le compromis que le responsable métier doit accepter.

L’évaluation doit donc présenter séparément les dossiers importants manqués et les expertises demandées à tort, avec le travail supplémentaire qu’elles entraîneraient. Elle doit aussi rendre visibles les dossiers incomplets écartés du test. S’ils n’ont pas été évalués, il faut prévoir comment les reconnaître et les traiter autrement.

La même logique vaut pour le gain économique. Un classement plus rapide ne démontrerait pas une économie nette si les experts recevaient davantage de dossiers inutiles. Le directeur financier doit pouvoir rapprocher le temps gagné du coût de préparation des données, des contrôles humains, des corrections et du fonctionnement de l’outil.

Du temps libéré peut permettre de traiter davantage de dossiers. Il ne se traduit pas, à lui seul, par une dépense réduite.

L’autorisation peut alors être précise : proposer aux gestionnaires un ordre de priorité, avec les seules informations disponibles à l’ouverture, pour les types de dossiers et les équipes couverts par le test. La décision reste au gestionnaire. Cette validation ne permettrait pas, par exemple, d’utiliser le même outil pour refuser une prise en charge.

Le responsable métier accepte ce périmètre, l’équipe technique décrit la version évaluée et le responsable de la validation consigne les limites du test. Si une preuve manque, la prochaine décision peut être de financer sa production. L’extension de l’usage attendra les résultats.

Sources

Continuer la lecture

Voir toutes les analyses