Un audit de sécurité IA cartographie la surface d'attaque réelle de vos chatbots et agents : ce qu'ils peuvent divulguer, exécuter ou autoriser quand on les manipule. Vous recevez un rapport avec un score de risque et des correctifs priorisés.
Un scanner de vulnérabilités analyse du code. Un LLM, lui, n'a pas de faille dans son code : la faille est dans ce qu'on arrive à lui faire dire ou faire avec du langage.
Votre pare-feu ne verra rien passer. Vos tests unitaires seront au vert. Votre pentest classique conclura que tout va bien. Et pourtant, une phrase bien construite dans un champ de saisie peut suffire à faire remonter le prompt système, les données d'un autre utilisateur ou le contenu d'un document interne indexé dans votre base vectorielle.
C'est un mode de défaillance nouveau : il ne relève ni du bug ni de la mauvaise configuration, mais du comportement du modèle face à une entrée adverse. Il faut donc le tester comme tel — avec des attaques réelles, pas avec une checklist.
Chaque audit est adapté à votre architecture. Voici les familles d'attaques systématiquement couvertes.
L'utilisateur écrit lui-même l'instruction malveillante dans la conversation pour détourner le comportement du modèle.
L'instruction est cachée dans une source que le modèle consulte : page web, PDF, e-mail, ticket, fiche produit.
Ce que le système accepte de révéler sous pression : données d'autres utilisateurs, documents internes, secrets de configuration.
Résistance réelle des protections en place, plutôt que leur existence sur le papier.
Si votre agent peut appeler des outils, envoyer des e-mails ou écrire en base, la surface d'attaque dépasse la conversation.
Chaque constat est rattaché au référentiel public OWASP Top 10 for LLM Applications et, quand c'est pertinent, à MITRE ATLAS.
Quatre étapes, cinq jours ouvrés entre le lancement et la remise du rapport.
Un échange pour identifier ce qui compte : les systèmes concernés, les données qu'ils touchent, les actions qu'ils peuvent déclencher, et ce qui serait grave en cas de compromission. C'est ce qui détermine la priorité des tests.
Cartographie du système : modèle utilisé, sources de contexte, outils connectés, filtres en place. Objectif — comprendre l'architecture avant de l'attaquer, comme le ferait un attaquant motivé.
Exécution des scénarios d'attaque, manuellement et avec de l'outillage automatisé. Chaque faille confirmée est reproduite et documentée avec sa charge utile exacte, pour que vos équipes puissent la rejouer.
Rapport livré, puis session de restitution pour dérouler les constats avec vos équipes techniques et répondre aux questions. Les correctifs sont classés par impact et par effort.
Deux documents, deux lecteurs. La direction n'a pas besoin des charges utiles, vos développeurs n'ont pas besoin d'un score global.
Score de risque global, synthèse des expositions majeures et de leurs conséquences métier, budget et délai estimés pour la remédiation. Format lisible par un comité de direction.
Chaque vulnérabilité avec sa charge utile reproductible, la réponse obtenue du système, la classification OWASP LLM, le niveau de sévérité et le correctif recommandé.
Ce qu'il faut corriger tout de suite, ce qui peut attendre le prochain cycle, et ce qui relève d'un choix d'architecture. Avec, pour chaque point, l'effort estimé.
Une fois vos correctifs déployés, je rejoue les attaques qui avaient fonctionné pour vérifier qu'elles sont bien neutralisées — et qu'aucune n'a été contournée autrement.
Cinq jours ouvrés entre le lancement et la remise du rapport, pour un périmètre standard (un chatbot ou un agent, avec ses sources de contexte). Un système multi-agents avec de nombreux outils connectés demande davantage de temps, ce qui est cadré avant de démarrer.
Les tests sont menés en priorité sur un environnement de préproduction. Si seule la production est disponible, le périmètre est défini ensemble en amont, avec des créneaux convenus et des limites strictes sur les actions destructives. Aucun test n'est lancé sans accord écrit sur le périmètre.
Un pentest classique cherche des failles dans le code et l'infrastructure : injection SQL, mauvaise configuration, dépendance vulnérable. Un audit de sécurité IA cherche des failles dans le comportement du modèle face à des entrées adverses. Les deux sont complémentaires : un système IA peut être parfaitement sécurisé au niveau infrastructure et divulguer malgré tout des données via une simple conversation.
Non, ce n'est pas indispensable. L'essentiel des tests se fait en boîte noire, du point de vue d'un utilisateur ou d'un attaquant externe. Un accès à l'architecture et à la configuration des garde-fous rend l'audit plus précis, mais reste optionnel.
À partir de 5 000 € pour un périmètre standard. Le prix dépend du nombre de systèmes, de leur complexité et de l'étendue des outils connectés. Le devis est établi après le cadrage, sans surprise en cours de mission.
Les protections d'un fournisseur de modèle portent sur le modèle, pas sur votre application. Votre prompt système, vos sources de contexte, vos outils connectés et vos règles métier vous appartiennent — et c'est là que se situent la majorité des expositions constatées.
Trente minutes en visio : vous me montrez votre chatbot, je teste en direct devant vous. Si je ne trouve rien, vous l'apprenez gratuitement.