Quand faire l'analyse de risque d'un système d'IA ?

Le plus tôt possible. Le guide de l'ANSSI de 2024 recommande de la mener avant la phase d'entraînement (R2) ; le document de février 2025 demande de la faire avant tout déploiement d'un système d'IA.

Quelle méthode utiliser ?

Le guide de l'ANSSI cite par exemple la méthode EBIOS Risk Manager, la méthode d'analyse de risque publiée par l'ANSSI. Elle s'applique aux systèmes d'IA en y ajoutant les menaces propres à l'IA.

Analyse de risque cyber d'un système d'IA : la méthode

L'analyse de risque d'un système d'IA générative suit la même logique que pour toute application, avec quatre ajouts : cartographier la chaîne d'approvisionnement (modèles, bibliothèques, données), lister les données que le système traitera, prendre en compte les attaques propres à l'IA (empoisonnement, extraction, détournement) et fixer le niveau d'autonomie selon la criticité des actions. L'ANSSI (Agence nationale de la sécurité des systèmes d'information) fournit deux documents pour la mener.

Les deux documents de l'ANSSI

Document	Date	Ce qu'il apporte
« Recommandations de sécurité pour un système d'IA générative » (ANSSI-PA-102)	29/04/2024	35 recommandations, six scénarios d'attaque, une recommandation dédiée à l'analyse de risque (R2)
« Développer la confiance dans l'IA à travers une approche par les risques cyber »	Février 2025	Une analyse haut niveau des risques, publiée pour le Sommet pour l'action sur l'IA, avec une liste de questions et de mesures en annexe

Le second a été mené avec des experts institutionnels français : la CNIL (Commission nationale de l'informatique et des libertés), l'institut de recherche Inria, le LNE (Laboratoire national de métrologie et d'essais), le PEReN (Pôle d'expertise de la régulation numérique) et l'AMIAD (Agence ministérielle pour l'IA de défense). Il a été cosigné dans sa version anglaise par des agences de cybersécurité d'autres pays, dont celles d'Allemagne, du Canada, du Royaume-Uni et de Singapour. Il porte sur la sécurité des systèmes qui intègrent des composants d'IA, plutôt que sur une liste exhaustive des vulnérabilités de chaque composant.

Ce que l'analyse doit couvrir (R2)

La recommandation R2 du guide de 2024 demande d'intégrer :

la cartographie de tous les éléments liés au modèle : bibliothèques tierces, sources de données, applications connectées ;
l'identification des parties du système qui traiteront les données de l'organisation, en particulier celles contenues dans les requêtes des utilisateurs ;
le scénario de partage de responsabilités et la sous-traitance, pour chaque phase ;
les impacts directs et indirects de réponses erronées ou malveillantes ;
la protection des données d'entraînement du modèle.

Le guide cite la méthode EBIOS Risk Manager à titre d'exemple.

Les scénarios d'attaque à examiner

Le guide de 2024 décrit six scénarios, que l'on peut reprendre comme grille :

N°	L'attaquant a accès à…	Et il…
1	Une source de données d'entraînement	L'empoisonne pour déclencher plus tard une action cachée
2	L'environnement de développement	Insère une porte dérobée dans le code ou les paramètres
3	Un service externe de test avant déploiement	Fausse le processus d'intégration
4	L'interface du système	Exfiltre des données (d'entraînement, d'autres utilisateurs) ou provoque un déni de service
5	Une ressource externe lue par le système	Renvoie un contenu malveillant que le modèle intègre, par exemple un lien piégé
6	Une extension utilisée par le système	Injecte des commandes vers une application métier

Le document de 2025 y ajoute une lecture par scénarios de risque : compromission de l'hébergement et de l'administration, compromission de la chaîne d'approvisionnement, propagation par les interconnexions avec d'autres systèmes (il cite l'injection indirecte de prompt), lacunes humaines et organisationnelles (dont le shadow IA, l'usage d'outils grand public sans approbation des services informatiques), et dysfonctionnement des réponses.

Les impacts à évaluer

Le guide de 2024 liste notamment : le ternissement de la réputation d'un service ouvert au public, l'exfiltration de données sensibles, le vol des paramètres d'un modèle propriétaire, la propagation d'une attaque vers d'autres applications connectées (comme la messagerie interne) et le sabotage d'applications par du code généré vulnérable. Il précise que la fuite de données sensibles doit être prise en compte dans tous les cas, quel que soit l'usage.

Les questions à se poser

L'annexe du document de 2025 propose une série de questions. En voici une sélection, reformulée :

La finalité du système est-elle définie et documentée ?
Qui accède au système à chaque phase de son cycle de vie, et le moindre privilège est-il appliqué ?
Quelle est la chaîne de dépendances ? Quelle est la réputation et la santé financière des fournisseurs, et respectent-ils les normes de sécurité ?
Le recours au cloud a-t-il fait l'objet d'une analyse de risque globale ?
Le contrat prévoit-il une clause de réversibilité, techniquement réalisable ?
Un dysfonctionnement de l'IA peut-il mettre l'organisation en danger ?
Les modèles doivent-ils être protégés en confidentialité ?

Ce qui en sort : des décisions

L'analyse doit aboutir à des choix concrets. Le document de 2025 en donne la direction : ajuster le niveau d'autonomie du système selon l'analyse de risque, le besoin métier et la criticité des actions, avec une validation humaine dès que nécessaire ; recenser et limiter les interconnexions aux besoins ; superviser et maintenir le système en continu ; tenir une veille sur les nouvelles menaces ; former les équipes, y compris les directions.

En pratique, chaque risque retenu se traduit par une mesure de la liste de contrôle d'un chatbot d'entreprise, puis par un scénario de red teaming qui vérifie que la mesure tient. Pour un résumé des recommandations de l'ANSSI pensé pour une PME qui équipe ses équipes, voyez aussi l'essentiel des recommandations ANSSI.