Évaluation de l’IA générative au Maroc : mesurer avant de déployer

L’évaluation de l’IA générative au Maroc ne consiste pas à demander à quelques collaborateurs si une démonstration « semble bonne ». Un système peut produire une réponse convaincante tout en citant une mauvaise source, en ignorant une consigne, en appelant le mauvais outil ou en révélant une information qu’il ne devrait pas utiliser. Avant la mise en production, il faut transformer les attentes métier en cas de test, critères et seuils de décision.

Cette discipline fait partie d’un projet d’Intelligence Artificielle industrialisé. Elle accompagne le choix du modèle, le prompt, la recherche documentaire, les outils, les permissions et l’expérience utilisateur. L’objectif n’est pas d’obtenir un score universel, mais de savoir si le système est suffisamment fiable pour un usage défini.

Commencer par la décision métier

Une évaluation doit répondre à une question exploitable : le système peut-il résumer un dossier sans omettre les éléments obligatoires ? Peut-il orienter une demande vers le bon service ? Peut-il répondre à partir d’un corpus autorisé avec une citation vérifiable ? Chaque question implique des critères différents.

Décrivez d’abord l’utilisateur, la tâche, les données accessibles, l’action autorisée et l’impact d’une erreur. Cette étape prolonge l’audit IA : l’audit sélectionne le bon cas d’usage ; l’évaluation vérifie qu’une solution précise respecte les conditions de déploiement.

Écrire les modes d’échec avant les métriques

Listez ce qui peut mal se passer : réponse non fondée, instruction ignorée, source obsolète, extraction incomplète, ton inadapté, divulgation de données, outil incorrect, boucle d’agent ou refus excessif. Associez chaque mode d’échec à son impact et à une réaction : avertir, demander une validation humaine, bloquer l’action ou revenir vers une procédure sûre.

Le profil GenAI du NIST AI RMF fournit une grille de risques comprenant notamment la confabulation, la confidentialité, l’intégrité de l’information, la sécurité et la supervision. Cette grille doit être adaptée au contexte réel de l’entreprise, pas copiée comme une checklist générique.

Construire un jeu de test représentatif

Le jeu d’évaluation doit refléter les entrées rencontrées en production : demandes simples, ambiguës, incomplètes, multilingues, mal formulées et volontairement hostiles. Pour un service utilisé au Maroc, il peut être nécessaire de couvrir français, arabe, anglais et darija selon les utilisateurs visés, sans supposer qu’un résultat dans une langue se transfère automatiquement aux autres.

Organisez les cas par scénario, difficulté, langue, segment utilisateur et niveau de risque. Conservez une réponse attendue lorsque c’est possible, mais acceptez qu’une tâche générative puisse avoir plusieurs bonnes formulations. Ce qui doit rester stable est le critère : faits requis, sources autorisées, structure, action ou limite à respecter.

Séparer développement et validation

Si l’équipe ajuste continuellement le prompt sur le même jeu de questions, elle finit par optimiser pour ces exemples. Conservez un jeu de développement visible, un jeu de validation protégé et une sélection de cas critiques de non-régression. Versionnez chaque cas, sa source, son attendu et son niveau de risque.

Les exemples issus de la production doivent être nettoyés, minimisés et anonymisés avant d’entrer dans une suite de tests. Une démarche de qualité des données aide à contrôler la provenance, les doublons et les droits d’usage de ce corpus.

Combiner plusieurs types d’évaluateurs

Aucun évaluateur ne couvre tout. Une suite robuste combine généralement :

• contrôles déterministes pour le format, le schéma, les champs, les citations ou les actions interdites ;
• règles métier pour vérifier une contrainte précise ;
• comparaison à une référence lorsque la réponse attendue est stable ;
• revue humaine avec une grille explicite pour les cas ambigus ou sensibles ;
• LLM-as-judge pour accélérer certains jugements qualitatifs, après calibration sur des décisions humaines.

Le guide officiel d’OpenAI sur les bonnes pratiques d’évaluation recommande des évaluations liées à la tâche, une combinaison de méthodes et un processus continu plutôt qu’un test ponctuel. Un juge modèle ne doit pas être traité comme une vérité : mesurez ses désaccords avec les experts et réexaminez les cas difficiles.

Choisir des métriques liées à l’usage

Les métriques doivent guider une décision. Pour une extraction structurée, mesurez la conformité du schéma, l’exactitude des champs et les omissions. Pour un assistant documentaire, évaluez la pertinence de la recherche, la fidélité à la source, la qualité des citations et l’absence d’affirmation non soutenue. Pour un agent, examinez la réussite de la tâche, la trajectoire, les appels d’outils et l’état final.

Ajoutez des métriques opérationnelles : latence, coût par scénario, taux de reprise, escalades humaines et erreurs techniques. N’écrasez pas tout dans une moyenne. Un score global peut masquer un échec grave sur un petit segment. Affichez les résultats par langue, scénario, risque et version.

Évaluer un système RAG par composants

Un assistant RAG peut échouer parce que le bon document n’a pas été indexé, parce que la recherche renvoie un mauvais passage ou parce que le modèle invente malgré un contexte correct. Évaluez séparément l’ingestion, la recherche et la génération.

• vérifier si les passages pertinents sont récupérés ;
• mesurer le bruit et les sources non autorisées ;
• contrôler que la réponse reste fondée sur le contexte ;
• valider que la citation mène bien au passage utilisé ;
• tester les questions auxquelles le système doit refuser de répondre.

La documentation de Ragas présente une approche d’évaluation des applications LLM et RAG basée sur des jeux de données et des métriques adaptées. L’article sur le RAG au Maroc détaille la conception technique qui précède ces tests.

Tester les agents et les outils

Pour un agent IA, la réponse finale ne suffit pas. Il faut analyser la séquence : outil choisi, paramètres transmis, permissions, gestion d’une erreur, nombre d’étapes et condition d’arrêt. Deux trajectoires peuvent produire le même résultat, mais l’une peut être coûteuse ou dangereuse.

Préparez des scénarios où un outil est indisponible, où une donnée manque, où l’utilisateur change d’objectif et où une action irréversible demande une confirmation. Le système doit échouer de manière contrôlée et transmettre un dossier compréhensible à un humain.

Intégrer sécurité et tests adversariaux

Une suite fonctionnelle ne couvre pas l’injection de prompt, l’exfiltration de données, le contournement des permissions ou les entrées spécialement conçues pour provoquer une action. Créez des tests négatifs qui vérifient ce que le système ne doit jamais faire.

Les résultats doivent être classés par gravité. Une formulation imparfaite n’a pas le même impact qu’un accès à une donnée confidentielle ou une action externe non autorisée. Les cas critiques doivent bloquer la promotion d’une version, même si la moyenne générale progresse.

Garder l’humain dans la boucle

L’évaluation automatisée accélère les comparaisons, mais les décisions sensibles nécessitent encore une revue humaine. Définissez une grille courte : exactitude, complétude, justification, conformité au ton et niveau de risque. Formez les évaluateurs avec des exemples annotés et mesurez les désaccords.

En production, le même principe s’applique. Un workflow human-in-the-loop prévoit les cas qui doivent être validés, escaladés ou repris. Les corrections humaines deviennent ensuite des candidats pour enrichir le jeu d’évaluation.

Automatiser les régressions

Le changement d’un prompt, d’un modèle, d’un index, d’un outil ou d’une règle peut améliorer un scénario et en dégrader un autre. Exécutez une suite de non-régression avant chaque promotion et comparez les résultats à une version de référence.

Ce contrôle s’intègre au MLOps : version du modèle, configuration, corpus, jeu de tests, scores et décision de mise en production sont liés. Enregistrez aussi les coûts et la latence afin de détecter une amélioration de qualité trop chère ou trop lente pour l’usage.

Surveiller après le déploiement

Une suite hors ligne ne peut pas prévoir toutes les demandes réelles. En production, suivez les erreurs, refus, escalades, retours utilisateurs, changements de distribution et incidents. Échantillonnez régulièrement des interactions pour une revue qualitative, dans le respect des règles de confidentialité.

Une pratique d’observabilité relie chaque interaction à la version du modèle, du prompt, du corpus et des outils. Lorsqu’un défaut apparaît, il peut être reproduit puis ajouté au jeu de non-régression.

Checklist avant décision

• objectif métier et impact des erreurs définis ;
• modes d’échec et cas sensibles documentés ;
• jeu de test représentatif, multilingue si nécessaire et versionné ;
• métriques segmentées par scénario et risque ;
• évaluateurs automatiques calibrés avec des humains ;
• tests RAG, agents et sécurité séparés quand ils s’appliquent ;
• seuils de blocage et responsable de décision nommés ;
• non-régression et surveillance en production actives.

L’évaluation de l’IA générative au Maroc transforme une impression en décision documentée. Elle ne garantit pas l’absence totale d’erreur, mais rend les limites visibles, les changements comparables et le déploiement gouvernable. Pour concevoir une suite adaptée à votre cas d’usage, contactez Kanteek.