Introduction

Vos modèles d'IA sont probablement vulnérables à FGSM, PGD ou à l'injection de prompts. Et vous ne le savez pas. Ce n'est pas une affirmation provocatrice, c'est une réalité statistique confirmée par Gartner en 2025 : 80% des modèles d'IA déployés en production n'ont jamais fait l'objet de tests de sécurité adversariaux. À une époque où les systèmes d'apprentissage automatique prennent des décisions qui ont une incidence directe sur l'accès au crédit, les diagnostics médicaux, la détection des fraudes et les processus de recrutement, cet angle mort constitue un risque organisationnel systémique.

La question abordée dans cet article est à la fois méthodologique et opérationnelle : comment une organisation peut-elle identifier, classer et hiérarchiser de manière rigoureuse les vulnérabilités de ses modèles d’IA de production, avant qu’un incident de sécurité, un audit réglementaire ou une attaque coordonnée ne l’oblige à le faire dans des conditions d’urgence ?

Ce guide propose une méthodologie complète structurée autour de cinq étapes audibles, s'appuyant sur le cadre MITRE ATLAS (plus de 80 tactiques, techniques et procédures documentées pour les systèmes d'IA) et les cinq piliers du risque lié à l'IA : Confidentialité, Intégrité, Déni, Traçabilité et Vie privée (C-I-D-T-P). Chaque étape produit des livrables concrets et défendables devant les régulateurs, les assureurs et les comités exécutifs.

I. Aperçu général : évaluation des risques liés à l'IA et IA adversaire

1. Définition et Fondements

L'évaluation des risques liés à l'IA désigne le processus structuré d'identification, d'analyse et d'évaluation des vulnérabilités spécifiques aux systèmes d'intelligence artificielle. Elle diffère fondamentalement d'un audit de cybersécurité classique en ce qu'elle doit aborder les menaces intrinsèques à la nature statistique des modèles d'apprentissage automatique. Des menaces qu'aucune approche conventionnelle de test d'intrusion ne peut détecter.

Un modèle d'IA n'est pas un programme logiciel déterministe. C'est une fonction mathématique entraînée sur des données, dont le comportement peut être manipulé par des entrées soigneusement conçues (exemples contradictoires), corrompu via son pipeline d'entraînement (empoisonnement des données), ou rétro-conçu par des requêtes répétées (inversion de modèle). Ces surfaces d'attaque n'existent pas dans les logiciels traditionnels, c'est pourquoi elles nécessitent une méthodologie dédiée.

IA contradictoire fait référence à l'ensemble des techniques utilisées pour exploiter délibérément ces spécificités, soit pour amener le modèle à produire des sorties incorrectes, soit pour en extraire des informations sensibles, soit pour saper la confiance en ses résultats. Le cadre MITRE ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems) est aujourd'hui la taxonomie de référence pour structurer ce paysage de menaces.

2. L'ampleur du problème : chiffres clés

Ces chiffres révèlent un paradoxe structurel : les organisations investissent massivement dans le déploiement de systèmes d'IA tout en négligeant systématiquement la dimension de sécurité spécifique à ces systèmes. Cet écart s'explique par trois facteurs convergents : la nouveauté des menaces adverses, l'absence de cadres d'audit standardisés jusqu'à récemment, et la séparation organisationnelle entre les équipes de science des données et les équipes de cybersécurité.

II. Analyse détaillée : panorama des menaces

Les 5 piliers C-I-D-T-P du risque lié à l'IA

La sécurité de l'information classique est organisée autour de la triade CIA (Confidentialité, Intégrité, Disponibilité). Les systèmes d'IA nécessitent un cadre élargi qui prend en compte les menaces spécifiques à leur architecture statistique et à leur rôle dans la prise de décision automatisée. Le cadre C-I-D-T-P étend cette triade à cinq dimensions.

2. MITRE ATLAS : les plus de 80 TTP à connaître

MITRE ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems) est la taxonomie faisant autorité pour les menaces spécifiques à l'IA, maintenue par la MITRE Corporation en collaboration avec plus de 30 organisations, y compris des laboratoires d'IA et des agences gouvernementales de premier plan. La version 4 répertorie plus de 80 TTP structurées en 14 tactiques, de la reconnaissance initiale contre l'infrastructure d'IA à l'impact et à l'exfiltration.

3. Quatre vecteurs d'attaque critiques en environnement de production

Parmi les plus de 80 TTP répertoriés dans MITRE ATLAS, quatre vecteurs d'attaque sont statistiquement les plus répandus dans les environnements de production des entreprises et doivent être considérés comme prioritaires dans tout audit des risques liés à l'IA.

4. Cas concrets et exemples sectoriels

III. Méthodologie : Cartographier votre exposition à l'IA en 5 étapes

Étape 1. Définir la portée et la gouvernance

Un audit des risques liés à l'IA qui commence sans une gouvernance claire produit des inventaires incomplets et des conflits de classification non résolus. La première étape consiste à constituer un comité multidisciplinaire et à définir formellement la portée avant le début de toute activité technique.

• Commanditaire de l'audit : CISO ou CRO (Chief Risk Officer) avec mandat exécutif
• Science des données / MLOps : architecture du modèle, pipelines d'entraînement, infrastructure de déploiement
• Unités commerciales : cas d'utilisation, impact sur la décision, populations d'utilisateurs concernées
• Juridique / DPO : RGPD, AI Act, contraintes réglementaires sectorielles
• Cybersécurité / Red Team : modélisation des menaces, capacités de tests d'intrusion

La définition de la portée doit explicitement aborder trois limites : organisationnel (quelles unités commerciales, filiales, fournisseurs tiers), technique (quels types de modèles : supervisé, génératif, apprentissage par renforcement), et temporel (modèles de production uniquement, ou incluant les modèles en cours de développement et les modèles retirés de la production mais toujours accessibles).

Étape 2. Inventaire de tous les modèles d'IA en production

L'inventaire doit combiner quatre méthodes de découverte complémentaires afin d'atteindre l'exhaustivité requise pour un audit défendable :

1. Questionnaire sur les unités commerciales structurées forme normalisée identifiant tous les outils d'IA utilisés (automatisation, TAL, vision par ordinateur, recommandation, scoring, IA générative).
2. Scan de l'infrastructure technique : analyse des registres de modèles (MLflow, SageMaker, Vertex AI), des services d'inférence conteneurisés, des passerelles d'API et des abonnements aux services d'IA cloud.
3. SaaS et audit des achats : Rapprochement des dépenses logicielles avec les bases de données des fournisseurs d'IA connues pour identifier l'utilisation non déclarée d'outils d'IA.
4. Série d'entretiens avec des développeurs : entretiens structurés avec des data scientists et des ingénieurs MLOps pour découvrir les modèles construits en dehors de la gouvernance formelle des projets.

Chaque système identifié doit être documenté dans une carte de modèle standardisée couvrant : le type et l'architecture du modèle, la provenance des données d'entraînement, l'exposition de l'API d'inférence, la portée de l'impact des décisions (combien d'individus affectés, réversibilité des décisions) et l'état actuel du suivi.

Étape 3. Classifier les vulnérabilités par pilier C-I-D-T-P

La classification est le cœur analytique de la méthodologie. Pour chaque modèle de l'inventaire, l'auditeur doit évaluer systématiquement l'exposition selon les cinq dimensions C-I-D-T-P, en faisant référence aux TTPs ATLAS pertinents.

Étape 4. Effectuer du Red Teaming IA

La classification identifie une exposition potentielle. Le "red teaming" confirme l'exploitabilité réelle. Pour chaque modèle classé comme présentant un risque élevé ou critique à l'étape 3, le protocole de test contradictoire suivant doit être appliqué proportionnellement au niveau de risque et à l'accessibilité du modèle :

• Test contradictoire en boîte noire : Attaques FGSM et PGD utilisant uniquement l'accès à l'API d'inférence. Ceci simule le scénario d'attaquant le plus réaliste sans accès aux internes du modèle.
• Tests en boîte blanche (lorsqu'accessibles) : attaques basées sur le gradient avec accès complet au modèle. Cela produit des bornes de vulnérabilité dans le pire des cas pour les modèles internes.
• Simulation d'empoisonnement de données : injecter des échantillons empoisonnés contrôlés dans le pipeline d'entraînement et mesurer la dégradation du comportement du modèle. Critique pour les modèles entraînés en continu.
• Évaluation de l'injection de prompts (LLM) : tests structurés de l'extraction de requêtes système, du jailbreaking, de l'injection indirecte via des documents récupérés et de l'exploitation de l'utilisation d'outils.
• Tests d'inférence d'adhésion : Attaque statistique pour déterminer si les données de personnes spécifiques ont été utilisées dans l'entraînement. Validation directe de la conformité à la vie privée.

Les résultats du red teaming en IA doivent être quantifiés (taux de réussite de l'attaque, perturbation minimale requise, nombre de requêtes nécessaires pour l'extraction) afin de produire des métriques exploitables pour la priorisation des remédiations et les décisions d'acceptation des risques.

Étape 5. Documenter, remédier et maintenir

Un audit qui produit un rapport classé dans un lecteur partagé n'a aucune valeur en matière de sécurité. L'étape 5 transforme les constatations en gouvernance opérationnelle via trois axes de travail parallèles :

Documentation formelle : Chaque vulnérabilité confirmée est documentée avec son identifiant TTP ATLAS, son pilier C-I-D-T-P, son taux de succès d'attaque confirmé, le(s) modèle(s) affecté(s), l'évaluation de l'impact commercial, et le responsable de la remédiation. Ce registre sert d'artefact principal pour les audits réglementaires, les évaluations d'assurance cyber et la déclaration des risques liés à l'IA au niveau du conseil d'administration.

Feuille de route de remédiation priorisée : Les actions de remédiation sont classées par score de risque et par effort d'implémentation. Les solutions rapides (renforcement de la validation des entrées, filtrage des sorties pour les LLM, limitation du débit des API) sont séparées des remédiations structurelles (entraînement contradictoire, implémentation de la confidentialité différentielle, modifications de l'architecture du modèle) qui nécessitent des délais plus longs.

Cadre de surveillance continue : Les audits ponctuels fournissent un instantané. Les systèmes d'IA de production nécessitent une surveillance continue grâce à : la détection d'entrées adversariales dans les journaux d'inférence, les sommes de contrôle d'intégrité des données d'entraînement, la surveillance de la dérive des performances du modèle (un indicateur potentiel d'empoisonnement) et des cycles de red teaming planifiés alignés sur la cadence de réentraînement du modèle.

Liste de contrôle pour l'audit des risques liés à l'IA

IV. Conclusion

Le chiffre de 80% correspondant aux modèles d’IA de production qui n’ont jamais fait l’objet de tests adversariaux ne reflète pas une négligence. Il témoigne d’une discipline qui n’existait pas officiellement il y a cinq ans. MITRE ATLAS, le cadre C-I-D-T-P et les méthodologies structurées de « red teaming » en IA ont suffisamment mûri pour rendre l’audit systématique des risques liés à l’IA à la fois réalisable sur le plan opérationnel et essentiel sur le plan stratégique.

La convergence de trois forces fait de 2026 un point d'inflexion : l'échéance du 2 août 2026 de l'AI Act pour les obligations relatives aux systèmes à haut risque, la marchandisation rapide des outils d'attaques adversariales réduisant la barrière de compétence pour les attaquants, et l'appétit croissant des cyberassureurs pour des preuves quantifiées de la posture de sécurité de l'IA avant d'émettre des couvertures liées à l'IA.

La méthodologie en cinq étapes présentée dans cet article, de la gouvernance et de la définition de la portée au red teaming de l'IA et à la surveillance continue, offre un chemin structuré de l'exposition actuelle à une gestion des risques défendable. Les organisations qui exécutent cette cartographie avant qu'un incident ne se produise seront structurellement mieux placées que celles qui la mènent comme un exercice de remédiation post-violation.

Vos modèles sont probablement vulnérables. La seule question est de savoir exactement comment etdans quelle mesure.

V. Références