Évaluer un assistant IA avant déploiement : une grille de tests métier

Intelligence artificielle Publié le 05/10/2026 Dimitri Jorand Gérant de DEMETER SANTE

Une démonstration convaincante ne constitue pas une validation. Construisez des cas représentatifs, mesurez les erreurs importantes et documentez votre décision.

Évaluer un assistant IA consiste à vérifier qu’il rend un service utile dans un périmètre défini, avec des erreurs, des accès et des coûts maîtrisés. Il faut tester le système complet : modèle, corpus, consignes, interface, habilitations et éventuels outils. Une bonne réponse lors d’une démonstration ne montre pas ce qui se passe quand la question est ambiguë ou la source absente.

Pour un établissement de santé, une organisation médico-sociale ou un organisme de formation, la démarche commence par un contrat d’usage : à quoi sert l’assistant, pour qui, sur quelles données et avec quelle responsabilité de vérification ? Sans cette définition, le même résultat pourra être jugé excellent ou dangereux selon le contexte.

Définir le service avant de noter les réponses

Rédigez une phrase opérationnelle : « aider les agents habilités à retrouver les documents d’accueil validés et leurs références ». Ajoutez les limites : pas de décision clinique, pas de consultation de documents réservés, pas d’envoi automatique. Ce périmètre permet de distinguer une réponse utile d’une réponse qui sort du rôle attendu.

Le profil NIST AI 600-1 consacré à l’IA générative est une ressource volontaire de gestion des risques. Il ne constitue ni une certification française ni un verdict sur votre assistant. Les critères ci-dessous sont une proposition de travail pour construire votre évaluation, pas un référentiel réglementaire autonome.

Construire un jeu de tests représentatif

Demandez aux utilisateurs métier des questions réalistes, puis créez des variantes. Une formulation administrative et une formulation de terrain peuvent désigner le même besoin. Incluez des termes locaux, une demande incomplète et des confusions plausibles entre services. Utilisez des données fictives ou un corpus de test autorisé, sans importer des dossiers réels par facilité.

Pour chaque cas, conservez la question, le contexte autorisé, la source de référence, les éléments attendus et les erreurs inacceptables. Les évaluateurs doivent connaître le périmètre. Si deux spécialistes interprètent différemment le document, clarifiez d’abord la règle métier : l’assistant ne peut résoudre à lui seul un désaccord documentaire.

Une grille en huit dimensions

Une note peut aider à comparer, mais chaque dimension doit garder ses critères. « Réponse agréable » n’est pas un critère d’exactitude. « Rapide » ne signifie pas « utile ». La personne doit pouvoir retrouver la source et comprendre les limites, pas uniquement recevoir un texte fluide.

Les cas négatifs sont indispensables

• Une question dont la réponse n’existe pas dans le corpus.
• Deux documents donnant des instructions différentes, dont un est obsolète.
• Une demande qui nécessite de préciser le service ou la date.
• Un utilisateur fictif cherchant une information réservée à un autre rôle.
• Un document de test contenant une consigne malveillante.
• Une source retirée de l’index ou momentanément indisponible.
• Une demande d’action que l’assistant n’est pas autorisé à effectuer.

Le bon résultat peut être une abstention, une question de précision ou un renvoi vers un référent. Un système qui répond toujours n’est pas nécessairement meilleur. Le comportement attendu doit être défini avant l’essai, afin de ne pas justifier après coup chaque réponse plausible.

Ne pas laisser une moyenne masquer une erreur critique

Classez les défauts selon leur conséquence pour l’usage. Une référence mal formatée et une divulgation de document réservé ne doivent pas se compenser dans une note globale. Définissez les critères de blocage et ceux qui autorisent un test limité après correction.

Évitez un seuil universel du type « 90 % suffit ». Un taux ne dit rien sans le nombre de cas, leur représentativité et la gravité des erreurs. Reportez les résultats par catégorie, les cas non couverts et les incertitudes. Si le périmètre est sensible, l’évaluation doit être dimensionnée avec les experts concernés.

Vérifier la sécurité avec les bons interlocuteurs

Les recommandations de l’ANSSI pour un système d’IA générative apportent un cadre cyber. La CNIL examine également les enjeux de sécurité dans le développement des systèmes d’IA. Un jeu de questions métier ne remplace pas une revue de sécurité, de protection des données ou de conformité applicable à votre projet.

Les tests d’injection doivent rester autorisés, réalisés dans un environnement contrôlé et sans tentative d’accès à des données réelles non autorisées. Le périmètre peut inclure les documents, les citations, les journaux et les permissions des outils. Un simple message dans le prompt ne constitue pas une barrière d’accès suffisante.

Comparer l’utilité à la méthode actuelle

Une réponse correcte peut être plus lente à vérifier qu’une recherche classique. Faites réaliser des tâches comparables avec et sans assistant, dans des conditions décrites. Observez le temps nécessaire pour obtenir une réponse vérifiée, les erreurs, les demandes d’aide et l’effort de contrôle. Ne publiez pas un gain de productivité tiré d’un exemple isolé comme un résultat général.

Prévoir les changements et le retour au mode standard

Conservez les versions du modèle, du corpus et des réglages avec les résultats. Rejouez les tests importants après une modification. Définissez qui peut arrêter le service, comment les utilisateurs sont informés et quelle recherche ou procédure standard reste disponible. Un assistant utile doit pouvoir être corrigé sans désorganiser le travail.

DEMETER SANTE peut vous accompagner dans le cadrage des usages, la formation et la construction de tests métier. Nos ressources sur le choix entre RAG et fine-tuning et l’inventaire des usages IA aident à préparer cette étape.