Comment auditer un système d'IA en entreprise : méthode et contrôles
L'intelligence artificielle s'impose dans les entreprises françaises — chatbots, systèmes de recommandation, automatisation de processus. Mais la sécurité de ces modèles est souvent négligée. Ce guide détaille pourquoi et comment réaliser un audit IA complet pour protéger vos données, votre conformité et votre réputation.
Pentest web & API, audit IA, Toulouse, méthodologie OWASP/PTES
Qu'est-ce qu'un audit IA ?
Un audit IA est une évaluation systématique de la sécurité, de la fiabilité et de la conformité de vos systèmes d'intelligence artificielle. Contrairement à un pentest classique qui se concentre sur l'infrastructure et les applications web, l'audit IA examine des vecteurs d'attaque spécifiques aux modèles de machine learning et aux LLM.
Le périmètre d'un audit IA couvre quatre dimensions :
- 1.Sécurité des modèles — résistance aux attaques adverses, injection de prompts, extraction de modèle
- 2.Protection des données — confidentialité des données d'entraînement, conformité RGPD
- 3.Détection de biais — équité des décisions, discrimination algorithmique, explicabilité
- 4.Tests de robustesse — comportement face aux entrées malformées, limites opérationnelles, dégradation gracieuse
Les menaces qui pèsent sur vos modèles IA
Prompt Injection
CritiqueUn attaquant injecte des instructions malveillantes dans les entrées d’un LLM pour contourner ses garde-fous. L’injection indirecte (via des documents ou pages web consultés par le modèle) est particulièrement insidieuse car elle ne nécessite pas d’accès direct au système.
Data Poisoning (empoisonnement des données)
CritiqueL’attaquant corrompt les données d’entraînement pour introduire des backdoors ou biaiser les prédictions du modèle. Une fois le modèle entraîné sur des données empoisonnées, la compromission est extrêmement difficile à détecter.
Model Extraction (vol de modèle)
HauteEn multipliant les requêtes à une API d’IA, un attaquant peut reconstruire une approximation fonctionnelle du modèle propriétaire. Cela représente un vol de propriété intellectuelle et expose les vulnérabilités du modèle original.
Attaques adverses (Adversarial Attacks)
HauteDes perturbations imperceptibles ajoutées aux entrées (images, texte, audio) trompent le modèle avec une confiance élevée. Un système de reconnaissance faciale peut être dupé par des modifications invisibles à l’œil humain.
Fuite des données d’entraînement
HauteLes LLM peuvent mémoriser et régurgiter des fragments de données d’entraînement, y compris des informations personnelles, des secrets d’entreprise ou du code propriétaire. Cette fuite peut entraîner des violations RGPD graves.
Les 5 étapes d'un audit IA complet
Inventaire des modèles
Cartographier tous les systèmes IA déployés dans l’entreprise : modèles internes, API tierces (OpenAI, AWS Bedrock, HuggingFace), modèles embarqués. Pour chaque système, documenter les données en entrée, les décisions en sortie et les utilisateurs impactés.
Analyse des données d’entraînement
Vérifier la provenance, la qualité et la conformité des données utilisées pour entraîner ou fine-tuner les modèles. Contrôler le consentement RGPD, l’absence de données sensibles non anonymisées et la représentativité des jeux de données pour éviter les biais.
Tests de robustesse
Soumettre les modèles à des scénarios d’attaque : prompt injection (directe et indirecte), entrées adverses, fuzzing des paramètres, tentatives d’extraction de modèle. Mesurer la résistance aux jailbreaks et le respect des garde-fous de sécurité.
Évaluation de la conformité
Vérifier l’alignement avec le cadre réglementaire applicable : classification EU AI Act (risque inacceptable, haut, limité, minimal), obligations RGPD Article 22 (décisions automatisées), recommandations ANSSI. Documenter les mesures de transparence et d’explicabilité.
Rapport et remédiation
Produire un rapport détaillé avec classification des vulnérabilités par criticité, preuves d’exploitation (PoC) et plan de remédiation priorisé. Définir les indicateurs de suivi et planifier les audits de contrôle.
Comment prouver l'auditabilité d'un système d'IA ?
Un système d'IA est auditable quand une équipe indépendante peut reconstituer une réponse, identifier les versions et sources utilisées, vérifier les décisions d'accès et retrouver la validation humaine. Un simple journal de conversation ne suffit pas.
- Journaux horodatés des entrées, sorties et erreurs.
- Version du modèle, version du prompt système et des règles de sécurité.
- Sources récupérées par le RAG, avec identifiant et version.
- Décisions d'accès, outils appelés et données exposées.
- Validation humaine, refus, corrections et dérogations.
- Jeux de tests, preuves de contrôle, durée de conservation et procédure pour reconstituer un incident.
| Preuve | Responsable proposé | Vérification |
|---|---|---|
| Version modèle, prompt et politique | Équipe produit IA | Relier chaque trace à une livraison identifiable |
| Sources RAG et droits appliqués | Responsable données | Rejouer une recherche avec un autre rôle ou tenant |
| Appel d’outil et décision d’accès | Équipe plateforme | Retrouver l’objet, l’identité serveur et le motif du refus |
| Validation humaine et changement effectué | Propriétaire métier | Lier l’approbation à l’action exacte, sans réutilisation |
| Tests et écarts de sécurité | Responsable sécurité | Conserver version testée, résultat et contre-test |
Fixez une durée de conservation justifiée par la finalité et les obligations applicables. Minimisez les données personnelles et masquez les secrets : la traçabilité ne justifie pas de journaliser intégralement chaque conversation. Documentez les droits d’accès et l’effacement des traces.
Pour tester ces preuves et les scénarios offensifs associés, consultez notre audit IA pour PME et systèmes LLM.
OWASP ML Top 10 : les vulnérabilités IA les plus courantes
L'OWASP Machine Learning Security Top 10 est le référentiel de sécurité spécifique aux systèmes de machine learning. Il couvre les vecteurs d'attaque les plus exploités : injection dans les entrées, empoisonnement des données, inversion de modèle, vol de modèle, abus d'API ML et corruption de la supply chain ML.
Le choix dépend du périmètre : utilisez le ML Top 10 pour les risques du modèle, et le LLM Top 10 2026 pour les applications génératives, en complément du OWASP Top 10 classique pour les vulnérabilités web. Les deux référentiels sont complémentaires : le Top 10 web traite les applications web ; le ML Top 10 ne remplace pas les tests des droits, du RAG et des outils d’un agent. Consultez aussi la checklist sécurité MCP.
Consultez le projet complet sur GitHub (OWASP ML Top 10).
Cadre réglementaire : EU AI Act, RGPD et ANSSI
EU AI Act : classification par niveau de risque
Le Règlement européen sur l'IA (EU AI Act) classe les systèmes IA en quatre niveaux de risque : inacceptable (interdit), haut risque (obligations strictes de conformité, audit obligatoire, documentation technique), risque limité (obligations de transparence) et risque minimal (code de conduite volontaire).
Les systèmes à haut risque (RH, crédit, santé, justice) doivent faire l'objet d'une évaluation de conformité avant mise sur le marché, incluant un audit de sécurité documenté.
RGPD Article 22 : décisions automatisées
L'article 22 du RGPD encadre les décisions fondées exclusivement sur un traitement automatisé, y compris le profilage. Les personnes concernées ont le droit d'obtenir une intervention humaine, d'exprimer leur point de vue et de contester la décision. L'audit IA doit vérifier que ces droits sont effectivement implémentés.
Audit IA vs pentest classique : quelles différences ?
| Critère | Pentest classique | Audit IA |
|---|---|---|
| Périmètre | Infrastructure, applications web, API | Modèles ML/LLM, pipelines de données, API IA |
| Vecteurs d’attaque | SQLi, XSS, SSRF, contrôle d’accès | Prompt injection, data poisoning, adversarial attacks |
| Données analysées | Requêtes HTTP, configurations serveur | Données d’entraînement, poids du modèle, prompts système |
| Référentiel | OWASP Top 10, PTES, OSSTMM | OWASP ML Top 10, NIST AI RMF, EU AI Act |
| Conformité | NIS2, ISO 27001 | EU AI Act, RGPD Art.22, NIS2 |
| Livrables | Rapport de vulnérabilités, PoC | Rapport de vulnérabilités IA, analyse de biais, plan de conformité |
Les deux approches sont complémentaires. Si votre application intègre des composants IA, un pentest web combiné à un audit IA offre une couverture complète.
Quand faut-il auditer vos systèmes IA ?
Avant la mise en production
Tout modèle IA doit être audité avant son déploiement. C’est une obligation pour les systèmes à haut risque sous le EU AI Act et une bonne pratique pour tous les autres.
Après une mise à jour majeure du modèle
Un re-entraînement, un changement de données ou une modification d’architecture peut introduire de nouvelles vulnérabilités ou réactiver des biais éliminés précédemment.
Annuellement (audit de maintien)
L’environnement de menaces évolue. De nouvelles techniques d’attaque apparaissent régulièrement. Un audit annuel permet de vérifier que vos défenses restent efficaces.
Après un incident de sécurité
Si un incident implique vos systèmes IA (fuite de données d’entraînement, jailbreak exploité, décisions biaisées signalées), un audit post-incident est indispensable pour identifier la cause racine.
Vos modèles IA sont-ils sécurisés ?
Laucked réalise des audits de sécurité IA complets : tests de robustesse (prompt injection, adversarial attacks), analyse de conformité EU AI Act et RGPD, détection de biais. Rapport détaillé avec plan de remédiation priorisé.
Voir aussi : demander un devis · RGPD et chatbots IA