Votre assistant IA interne répond correctement pendant la démonstration. Il lit aussi des documents, conserve les conversations et peut modifier une fiche client grâce à un outil connecté. Avant de le confier aux équipes, quelqu’un demande s’il a été testé. Quelques bonnes réponses ne suffisent pas à répondre à cette question.
Pour les organisations au Luxembourg et dans la Grande Région, une évaluation IA utile doit couvrir la sécurité et les performances attendues. Le pentesting IA recherche les failles exploitables. Les tests IA mesurent si le système accomplit sa tâche de manière fiable. Ce guide explique comment cadrer ces deux missions, quelles preuves demander et quelle place donner aux modèles, harnesses d’agents, intégrations MCP et biais.
Le pentesting IA et les tests IA répondent à des questions différentes
Un pentest cherche ce qu’un attaquant pourrait faire révéler ou exécuter au système. Une évaluation de qualité vérifie si le résultat est acceptable dans les conditions rencontrées par vos utilisateurs. Un système peut bien répondre aux questions courantes tout en exposant les documents d’un autre utilisateur. Il peut aussi résister à un jailbreak tout en inventant une réponse destinée à un client.
| Évaluation | Question principale | Preuves utiles |
|---|
| Pentesting IA | Un attaquant peut-il franchir une limite de sécurité ? | Attaques reproductibles, permissions concernées et impact métier |
| Tests IA | Le système réalise-t-il sa tâche prévue ? | Cas représentatifs, résultats mesurés et critères d’acceptation |
| Préparation à la conformité | Quelles exigences applicables disposent de preuves ? | Correspondance des contrôles, dossiers techniques, écarts et responsables des corrections |
Notre service de pentesting IA couvre les limites de sécurité de l’application complète. Il peut être associé à des évaluations de qualité et de biais si la mission nécessite une analyse plus large. Conservez des objectifs distincts dans le cahier des charges pour qu’aucun ne disparaisse derrière une promesse générique de tester le modèle.
Définissez le périmètre du système avant de choisir un outil
Commencez par un schéma montrant l’utilisateur, l’application, le modèle, les sources documentaires, la mémoire, les outils et les systèmes en aval. Indiquez où les identités changent et où les informations passent d’une organisation à une autre. Incluez l’interface d’administration, les traitements en arrière-plan et la supervision : leurs accès peuvent dépasser ceux du chatbot visible.
Précisez ensuite les utilisateurs visés, les tâches permises et les actions interdites. Un assistant qui prépare une demande d’achat présente des risques différents de celui qui la soumet. Indiquez s’il peut envoyer des courriels, modifier des fiches, exécuter du code ou consulter des documents de plusieurs services. Ces décisions définissent les limites que l’évaluation doit tenter de franchir.
Convenez des autorisations, environnements de test, restrictions des tiers, données synthétiques, contacts d’escalade et conditions d’arrêt. Utilisez des destinations contrôlées pour simuler une exfiltration. Si une dépendance en production doit intervenir, définissez explicitement les actions autorisées : la permission de tester votre application ne vaut pas permission de tester le service d’un tiers.
Prenons un assistant de support illustratif qui peut préparer un courriel sans l’envoyer. L’évaluation doit vérifier séparément le brouillon, le destinataire proposé et la trace d’exécution. Si la conversation affirme que le courriel a été envoyé, établissez si un véritable appel d’outil a eu lieu. Si l’exécution a été bloquée, conservez également cette preuve. Vous évitez ainsi de confondre un message de réussite inventé avec une action accomplie et identifiez le composant à corriger.
Testez le modèle par des points d’entrée réalistes
Les tests doivent inclure les langues, formats de fichiers et modes d’interaction réellement pris en charge. Pour un workflow multilingue au Luxembourg, cela peut demander plus qu’une traduction du même prompt anglais. Des formats documentaires différents, des messages mêlant plusieurs langues et un vocabulaire métier peuvent modifier la compréhension et le comportement des protections.
L’OWASP distingue l’injection de prompts directe et indirecte : une instruction peut venir de la saisie utilisateur ou d’un contenu récupéré par l’application. Cette distinction aide à choisir des points d’entrée réalistes au lieu de tester uniquement la fenêtre de conversation.
Pour chaque test, consignez les versions de l’application et du modèle, les prompts, le contexte fourni, la configuration et le résultat observé. Distinguez une réponse offensante d’un véritable franchissement de limite. Révéler une instruction système sans conséquence et divulguer des données clients n’ont pas le même impact, même si les deux semblent impressionnants sur une capture d’écran.
Un scanner automatisé généraliste apporte de la couverture et de la répétabilité. Il faut néanmoins des cas propres à l’application : données présentes, outils accessibles et actions considérées comme inacceptables par le métier. Un scan sans anomalie renseigne sur les tests exécutés ; il ne garantit pas la sécurité de toutes les interactions possibles.
Évaluez le harness d’agents et ses contrôles d’action
Le harness d’agents est la couche applicative qui fournit le contexte, gère la mémoire, sélectionne les outils et exécute les actions autour du modèle. C’est là qu’une suggestion plausible peut devenir une modification réelle en base de données. Examinez le chemin entre la sortie du modèle et son exécution, puis identifiez les contrôles imposés par le code.
Testez les validations sur un workflow métier synthétique. Un assistant peut, par exemple, préparer une modification de fiche client avec approbation humaine obligatoire. Vérifiez que cette approbation porte sur l’action et les arguments exacts, expire correctement et ne peut pas être réutilisée pour une autre opération. Contrôlez le résultat après exécution plutôt que d’accepter le récit de l’assistant.
Exercez les annulations, nouvelles tentatives, erreurs d’outils et changements de session. Une validation annulée doit le rester après une nouvelle tentative. Un échec de recherche ne doit pas élargir silencieusement les accès. La mémoire conversationnelle ne doit pas transmettre de données sensibles à un autre utilisateur. Limitez les appels répétés aux outils pour qu’une boucle improductive ne consomme pas un budget illimité.
Incluez les serveurs MCP, les clients et les permissions en aval
Le Model Context Protocol, ou MCP, relie les applications IA à des outils et ressources. Inventoriez chaque client et serveur, son hébergement, l’identité utilisée et les permissions détenues en aval. Le bon périmètre de test comprend toute la chaîne entre une demande utilisateur et l’appel API final.
Les recommandations officielles de sécurité MCP traitent de risques propres au protocole, notamment le transfert de jetons et le comportement de mandataire confus. Confrontez ces indications au transport et au parcours d’autorisation réellement utilisés par votre implémentation.
Construisez des cas positifs et négatifs explicites. Un utilisateur autorisé doit pouvoir accomplir la tâche approuvée. Un autre utilisateur, un identifiant expiré ou une demande hors du périmètre autorisé doivent échouer sans exposer de données supplémentaires. Examinez les descriptions et résultats des outils, l’exécution locale et la gestion des secrets avec l’authentification du serveur.
Un connecteur de confiance ne prouve pas que toutes ses réponses constituent des instructions fiables. Un ticket de support ou document peut contenir du texte hostile même s’il provient d’un service authentifié. Testez son influence sur l’action suivante avec des fiches synthétiques et des destinations de test sans danger.
Évaluez séparément la récupération, la qualité et les biais
Un système de génération augmentée par récupération, ou RAG, doit être évalué au stade de la recherche et à celui de la réponse. Vérifiez que les documents autorisés sont trouvés, que les documents interdits sont exclus et que la réponse utilise fidèlement les éléments récupérés. Une réponse apparemment correcte peut masquer un filtre d’accès défaillant.
Pour la qualité, constituez un jeu de données relu à partir de tâches réalistes. Incluez des questions avec réponse, des questions sans réponse dans la base de connaissances, des sources contradictoires, des documents périmés et des demandes nécessitant un humain. Gardez les résultats attendus et les règles de notation indépendants du système évalué.
Les évaluations de biais nécessitent un contexte explicite. Définissez les groupes, langues et circonstances pertinents pour l’usage prévu, ainsi que le sens d’une différence injuste. Lorsque c’est approprié, comparez des cas autrement équivalents en modifiant un seul attribut pertinent. Consignez l’incertitude et les limites d’échantillonnage sans transformer un petit test en affirmation universelle d’équité.
Le profil IA générative du NIST est une ressource volontaire de gestion des risques sur le cycle de vie. Il peut structurer un programme d’évaluation ; vos critères de mise en production doivent néanmoins refléter votre workflow réel. Notre service de tests IA transforme ces critères en évaluations reproductibles et tests de régression.
Reliez les preuves de test aux travaux sur l’EU AI Act
Les tests techniques contribuent à la préparation réglementaire, mais le rapport doit préciser son contexte. Établissez l’usage prévu, votre rôle de fournisseur ou de déployeur et les exigences applicables avant de choisir les preuves à collecter. Un chatbot, un système de recrutement et un modèle intégré à un autre produit réglementé demandent des évaluations différentes.
L’article 15 de l’EU AI Act traite de la précision, de la robustesse et de la cybersécurité des systèmes IA à haut risque. Reliez les résultats pertinents aux obligations applicables en exposant leur périmètre et leurs limites. Un test isolé de prompt ne remplace pas la procédure de conformité complète.
Conservez les preuves concernant les jeux de données, le contrôle humain, les journaux et les corrections avec les constats techniques. Notre guide de l’EU AI Act explique le cadre plus large. L’évaluation doit identifier les écarts et leurs responsables sans présenter un pentest ou un score de biais comme un certificat de conformité juridique.
Une fiche de test utile relie un cas au résultat attendu, au résultat observé et aux traces justificatives. Stockez les preuves sensibles avec accès contrôlé et masquez les données dans les copies diffusées plus largement. Rattachez le responsable de correction et le résultat du contre-test à la même fiche. Le réviseur peut distinguer un problème ouvert, une limite acceptée et une correction vérifiée sans reconstituer l’évaluation à partir de conversations.
Demandez un rapport exploitable par votre équipe
Chaque constat de sécurité doit préciser le composant concerné, les prérequis, les étapes de reproduction, l’impact observé, la justification de la sévérité et la correction proposée. Les constats de qualité doivent exposer la population testée, la méthode de notation et les critères d’acceptation non atteints. Les deux doivent signaler les zones non testées et la dépendance à un modèle ou une configuration.
Convenez des contre-tests et conservez les cas de régression. Modifier un prompt, un modèle, un index documentaire ou un outil MCP peut changer le comportement sans changer l’interface. La checklist de déploiement et d’administration explique comment intégrer ces tests à l’exploitation continue.
Pour évaluer un système IA, apportez son architecture, ses actions autorisées et son stade de déploiement à une discussion de cadrage avec ObsidianCorps. Nous pouvons définir un pentest ciblé, une évaluation de qualité et de biais ou une mission combinée avec preuves précises et livrables de remédiation.
