Tester une application d’IA avant la mise en production
Une application d'IA ne se teste pas comme un logiciel classique : la même question peut recevoir deux réponses différentes. On ne vérifie donc pas une sortie exacte, mais un niveau de qualité sur un ensemble de cas. Méthode.
Comment savoir qu’un assistant fondé sur un modèle de langage est prêt ? La démonstration s’est bien passée, les premiers utilisateurs sont contents, et pourtant personne ne peut dire combien de réponses seront fausses la première semaine. En matière d’IA, tests et validation demandent une méthode différente de celle d’un logiciel classique, parce que le résultat n’est pas déterministe.
Ce guide décrit une démarche applicable à la plupart des applications : assistant documentaire, aide à la rédaction, classement de demandes, extraction d’informations.
Ce qui change par rapport à un logiciel classique
Un test classique compare une sortie à une valeur attendue. Avec un modèle de langage, la même entrée peut produire plusieurs sorties, toutes acceptables, ou une sortie différente d’une fois sur l’autre. Le modèle peut aussi changer, si le fournisseur publie une nouvelle version. On ne teste donc plus une égalité, mais un niveau de qualité, mesuré sur un ensemble de cas, selon des critères explicites.
| Famille | Question | Exemple de mesure |
|---|---|---|
| Qualité fonctionnelle | La réponse est-elle juste, complète et utile ? | Part des réponses jugées correctes sur le jeu d’évaluation |
| Fidélité aux sources | La réponse s’appuie-t-elle sur les documents fournis, sans inventer ? | Part des affirmations vérifiables dans les sources citées |
| Robustesse | La qualité tient-elle avec des fautes, des formulations inhabituelles, d’autres langues ? | Écart de qualité entre cas standards et cas dégradés |
| Sécurité | Peut-on détourner l’application ou lui faire révéler des données ? | Taux de réussite des tentatives d’injection et de fuite |
| Équité | La qualité varie-t-elle selon le profil de l’usager ? | Écart de qualité entre groupes de cas |
| Performance et coût | Le délai et le coût par requête sont-ils acceptables ? | Délai médian et au pire cas, coût par requête |
La méthode, étape par étape
- Construire le jeu d’évaluation avant de développer. Cent à quelques centaines de cas réels, choisis avec les métiers : questions fréquentes, cas difficiles, cas limites, questions auxquelles l’application doit refuser de répondre. Pour chaque cas, la réponse attendue ou les éléments qu’elle doit contenir.
- Écrire les critères d’acceptation avec un seuil. Par exemple : au moins tel pourcentage de réponses correctes, aucune réponse contenant une donnée personnelle d’un tiers, refus systématique sur les questions hors périmètre. Les seuils se fixent avec le responsable métier, selon le risque.
- Noter un premier échantillon à la main. Deux personnes notent indépendamment les mêmes réponses ; leurs désaccords révèlent les critères mal définis.
- Automatiser l’évaluation, si le volume l’exige, avec des règles ou un modèle évaluateur, puis vérifier sur l’échantillon noté que l’évaluation automatique est d’accord avec les humains.
- Tester les entrées hostiles. Injection d’instructions dans la question ou dans un document fourni, demande de révéler les consignes, tentative d’obtenir des données d’un autre utilisateur. Le Top 10 de l’OWASP pour les applications à base de grands modèles de langage donne une liste de risques à couvrir.
- Faire tester par des utilisateurs dans des conditions proches du réel, avec un moyen simple de signaler une mauvaise réponse.
- Décider au regard des seuils : mise en production, mise en production restreinte, ou retour au développement.
Le jeu d’évaluation est l’actif le plus durable du projet. Il survit aux changements de modèle, de fournisseur et d’équipe, et permet de comparer chaque nouvelle version à la précédente.
Après la mise en production
La qualité d’une application d’IA dérive : les questions des utilisateurs changent, les documents sources évoluent, le fournisseur met à jour son modèle. Trois dispositifs permettent de garder le contrôle. Rejouer le jeu d’évaluation à chaque changement (de modèle, de consignes, de sources) et avant chaque nouvelle version. Échantillonner régulièrement des échanges réels, dans le respect des règles de protection des données, pour les noter et enrichir le jeu d’évaluation. Suivre les signalements des utilisateurs et les traiter comme des anomalies.
Une mise à jour du modèle par le fournisseur peut changer le comportement de l’application sans aucune modification de votre côté. Le contrat ou la configuration doivent permettre de figer une version et d’être prévenu des changements.
Le cadre réglementaire
Le règlement européen sur l’IA, entré en vigueur le 1er août 2024, prévoit des obligations de test, de documentation et de surveillance après commercialisation pour les systèmes à haut risque, dont l’essentiel s’applique à partir du 2 août 2026 ; un report de certaines de ces obligations a été proposé fin 2025 et fait l’objet de discussions. Même pour une application qui n’est pas à haut risque, une démarche de test documentée est la meilleure préparation. Le cadre de gestion des risques du NIST et la norme ISO/IEC 42001 en donnent la structure.
Liste de contrôle avant la mise en production
- Un jeu d’évaluation fondé sur des cas réels existe et est versionné.
- Les critères d’acceptation et leurs seuils sont écrits et validés par le métier.
- L’évaluation automatique a été comparée à une notation humaine.
- Les tests d’injection et de fuite de données ont été réalisés.
- La version du modèle est connue et les changements seront signalés.
- Un moyen de signaler une mauvaise réponse est disponible dans l’application.
- Un responsable suit la qualité après la mise en production.
Cette démarche est appliquée dans les projets d’IA en entreprise de DOSOBE. Le dossier sur les agents d’IA en entreprise l’étend aux systèmes qui enchaînent plusieurs actions.
Pour approfondir : IA d’entreprise · Automatisation des processus
Questions fréquentes
Pourquoi les tests classiques ne suffisent-ils pas ?
Parce qu'un modèle de langage ne donne pas toujours la même réponse à la même question, et qu'une réponse peut être juste sous plusieurs formes. On évalue donc un taux de réussite sur un ensemble de cas, selon des critères définis, plutôt qu'une égalité avec une réponse attendue.
Peut-on utiliser un modèle pour évaluer un autre modèle ?
Oui, pour passer à l'échelle, à condition de vérifier d'abord, sur un échantillon noté par des humains, que l'évaluateur automatique est d'accord avec eux. Sans cette vérification, on mesure les préférences de l'évaluateur, pas la qualité.
Quels référentiels utiliser ?
Le cadre de gestion des risques de l'IA du NIST (AI RMF 1.0, 2023), la norme ISO/IEC 42001:2023 pour le système de management, et le Top 10 de l'OWASP pour les applications à base de grands modèles de langage pour les tests de sécurité.