Un test d'intrusion classique suffit-il pour un système d'IA ?

Non. L'ANSSI le compte parmi les tests à faire, sur les composants techniques (serveur web, orchestrateur, base de données), mais recommande d'y ajouter des tests automatisés visant les vulnérabilités des modèles et des tests manuels d'auditeurs sur des scénarios d'attaque plus élaborés.

Peut-on confier l'audit à un prestataire qualifié ?

Le guide de l'ANSSI indique qu'il est possible de faire appel à des prestataires d'audit de la sécurité des systèmes d'information (PASSI) qualifiés par l'ANSSI.

Red teaming d'une IA : tester avant de mettre en ligne

Le red teaming d'une IA consiste à attaquer volontairement votre assistant, votre chatbot ou votre agent, avant sa mise en ligne puis régulièrement, pour trouver ce qu'un vrai attaquant trouverait : injection de prompt, contournement des règles, fuite de documents, actions non voulues. L'ANSSI (Agence nationale de la sécurité des systèmes d'information) recommande ces tests avant tout déploiement en production (R23), et l'OWASP, fondation qui publie des référentiels de sécurité applicative, insiste sur un point : tester contre un attaquant qui connaît vos défenses.

Ce que recommande l'ANSSI

La recommandation R23 du guide du 29/04/2024 demande de prévoir des tests de robustesse et de sécurité, qui peuvent être :

Type de test	Ce qu'il couvre
Tests d'intrusion standards	Les composants techniques usuels : serveurs web, orchestrateur, base de données
Tests de sécurité des développements	Le code ajouté autour du modèle, par analyse statique ou dynamique (outils SAST ou DAST)
Tests automatisés propres aux modèles	Attaques adverses, extraction du modèle
Tests manuels d'auditeurs	La robustesse du modèle face à des scénarios d'attaque plus élaborés

Le guide ajoute que l'audit doit être fait par des équipes formées aux spécificités de l'IA, et qu'il est possible de recourir à des prestataires PASSI (prestataires d'audit de la sécurité des systèmes d'information) qualifiés par l'ANSSI. Il recommande aussi des tests fonctionnels métier (R24), y compris en continu, pour détecter tôt un dysfonctionnement.

Ce que dit l'OWASP

Le guide de red teaming de l'IA générative de l'OWASP, publié le 22/01/2025, couvre quatre domaines : l'évaluation du modèle, les tests de l'implémentation, l'évaluation de l'infrastructure et l'analyse du comportement en fonctionnement.

Le Top 10 2026 apporte une consigne de méthode : écarter les résultats obtenus seulement avec des attaques fixes. Il cite une étude de 2025 où le taux de réussite des attaques fixes était proche de zéro, alors que celui des attaques adaptatives dépassait 90 % pour la plupart des douze défenses récentes testées. Il recommande de partir de jeux de référence publics (AgentDojo, JailbreakBench), puis de faire tester l'application par des testeurs qui ont reçu la description complète des défenses.

Une méthode en six étapes

Délimiter. Quel système (modèle, base documentaire, outils, interface) ? Quelles données sont en jeu ? Qui sont les attaquants plausibles : visiteur anonyme, salarié curieux, auteur d'un mail entrant ?
Lister les scénarios. Partez des familles de l'ANSSI (manipulation, infection, exfiltration) et des dix entrées du Top 10 OWASP. Pour un assistant documentaire, les scénarios prioritaires sont souvent : obtenir un document hors de ses droits, extraire le prompt système, faire suivre une consigne cachée dans un document.
Préparer les contenus piégés. La documentation d'Anthropic recommande de tester le système avec des documents, des mails et des résultats d'outils qui contiennent délibérément des tentatives d'injection, et de vérifier que le modèle les ignore et que les filtres et validations attrapent le reste.
Automatiser le gros du travail avec un outil (voir ci-dessous), pour couvrir des centaines de variantes.
Attaquer à la main, en connaissant les défenses : c'est là que se trouvent les contournements adaptatifs.
Corriger, puis rejouer. Chaque attaque réussie entre dans un jeu de tests de non-régression, rejoué à chaque changement de modèle, de prompt ou de base documentaire.

Trois outils libres

Cercle IA Tech est édité par IArche, qui édite ALMA ; les outils ci-dessous sont cités pour information, sans classement.

Outil	Ce qu'il est, d'après sa documentation	Point à noter
garak	Un outil qui vérifie si une application fondée sur un modèle de langage peut être amenée à échouer de façon indésirable : hallucination, fuite de données, injection de prompt, désinformation, contenu toxique, jailbreak	Licence Apache-2.0, installation par `python -m pip install -U garak`
PyRIT	« Python Risk Identification Tool », un cadre libre pour aider les professionnels de la sécurité à trouver les risques des systèmes d'IA générative	Licence MIT ; le dépôt Azure, archivé le 27/03/2026, renvoie vers github.com/microsoft/PyRIT
promptfoo	Un logiciel libre de test d'applications d'IA, avec une fonction de red teaming pour repérer et corriger les vulnérabilités	Édité par Promptfoo, Inc. ; sa documentation cite l'OWASP LLM Top 10 et le NIST AI RMF, cadre américain de gestion des risques de l'IA, parmi les référentiels

Aucun outil ne remplace l'étape 5 : il trouve les failles connues, pas celles propres à votre application.

Ce que doit contenir le rapport

le périmètre testé et les versions (modèle, prompt système, base documentaire) ;
chaque scénario, la requête exacte, la réponse obtenue et sa gravité ;
les attaques qui ont réussi et la mesure proposée, en distinguant celles qui rendent l'attaque moins probable et celles qui limitent ses conséquences ;
la date du prochain test.

Pour l'évaluation de la qualité des réponses, qui est un autre exercice, voyez évaluer un agent IA.