Recommandations ANSSI (PA-102) : le socle cyber d'une IA générative en clair

Si vous déployez une IA générative en interne, l'ANSSI vous demande de la traiter comme un système sensible et non comme une application banale : isoler les phases d'entraînement, de déploiement et de production, maîtriser vos dépendances et faire auditer le tout avant la mise en service par des équipes formées aux spécificités de l'IA. Ce sont les recommandations PA-102, et elles forment le socle cyber qui vous manque. Pas besoin d'être expert en sécurité pour vous y mettre. Dans cet article, je vous explique le problème concret que pose une IA générative déployée trop vite, puis la méthode en quatre étapes pour transformer les recommandations de l'ANSSI en plan d'action concret pour votre RSSI.

Le problème : une IA générative n'est pas une application comme les autres

Une IA générative se branche vite. Une clé d'API, une bibliothèque open source, quelques documents internes en contexte, et l'assistant répond. Le problème n'est pas cette facilité, c'est qu'elle masque une surface d'attaque inhabituelle : un modèle récupéré ailleurs, des données d'entraînement qui côtoient la production, des dépendances que personne n'a vérifiées, et un service mis en ligne sans que quiconque l'ait attaqué pour voir ce qu'il livre.

Le scénario que je vois revenir : une équipe motivée déploie un assistant interne en quelques semaines, le connecte à des espaces de fichiers sensibles, et découvre lors d'un incident que la même infrastructure servait à expérimenter, à entraîner et à servir des utilisateurs réels. Une seule brèche, et tout tombe ensemble. La bonne nouvelle, c'est que l'ANSSI a formalisé un socle simple pour éviter exactement cela.

Ce que disent les recommandations ANSSI (PA-102), en clair

Le guide de l'ANSSI sur la sécurité des systèmes d'IA générative tient en une idée directrice : traiter l'IA comme un maillon sensible de votre système d'information, avec les mêmes réflexes de cloisonnement, de maîtrise des dépendances et de contrôle avant mise en production que pour n'importe quel composant critique. Trois principes reviennent.

• Isoler les phases.L'entraînement, le déploiement et la production ne doivent jamais partager le même environnement. Ce qui sert à expérimenter ne doit pas toucher ce qui sert vos utilisateurs.
• Maîtriser la chaîne d'approvisionnement. Modèles, bibliothèques et jeux de données entrent chez vous avec leurs propres risques. Il faut en connaître la provenance avant de les intégrer.
• Auditer avant de mettre en service.Aucune IA ne passe en production sans un contrôle de sécurité mené par des personnes qui comprennent ses failles propres, pas seulement celles d'une application web classique.

La méthode en 4 étapes pour bâtir le socle

Voici comment je traduis ces recommandations en plan d'action, dans l'ordre où je les déroule avec une équipe qui démarre :

1. Cloisonnez vos trois environnements.Séparez physiquement ou logiquement l'entraînement, le déploiement et la production, avec des accès distincts pour chacun. Une compromission d'un bac à sable ne doit jamais atteindre les données de vos utilisateurs. C'est la première barrière, et la plus rentable.
2. Cartographiez et verrouillez vos dépendances.Recensez chaque modèle, bibliothèque et jeu de données, avec sa provenance et sa version. Un modèle téléchargé sur une place de marché peut embarquer une porte dérobée invisible. Tracer cette chaîne, c'est la même logique que auditer la provenance de vos modèles avec un AI-BOM.
3. Auditez avant la mise en production.Faites tester votre IA comme un attaquant le ferait, avant l'ouverture aux utilisateurs. C'est tout l'objet d'un red teaming de LLM, qui éprouve la robustesse réelle plutôt qu'une conformité sur le papier.
4. Supervisez et formez.Journalisez les accès et les usages en production, surveillez les comportements anormaux, et formez les équipes aux risques propres à l'IA. Un socle ne tient que si des personnes compétentes le maintiennent dans le temps.

De la recommandation à l'action : le tableau de correspondance

Pour un RSSI, l'utile n'est pas le texte du guide mais ce qu'il faut mettre en place. Voici la correspondance que j'utilise :

Cette dernière ligne compte plus qu'il n'y paraît. Choisir où vivent votre modèle et vos données, c'est décider qui peut y accéder et sous quelle loi. La souveraineté n'est pas un slogan, c'est une propriété de sécurité qui conditionne aussi votre conformité au RGPD.

Questions fréquentes

Les recommandations de l'ANSSI sont-elles obligatoires ?

Ce sont des recommandations, pas une loi, donc elles ne sont pas contraignantes en elles-mêmes. Mais elles décrivent l'état de l'art attendu. En cas d'incident ou de contrôle, ne pas les avoir suivies pèse lourd, et elles recoupent souvent des obligations bien réelles, RGPD et sécurité, que vous devez tenir.

J'utilise une IA en ligne, pas un modèle que j'héberge. Suis-je concerné ?

Oui, en partie. Vous n'entraînez pas le modèle, mais vous restez responsable de la façon dont vous le branchez à vos données, des accès que vous ouvrez et des sorties que vous exposez. Le cloisonnement des accès et la supervision vous concernent directement.

Par où commencer si je n'ai rien mis en place ?

Par l'isolation des environnements et l'inventaire des dépendances, les deux premières étapes. Elles coûtent peu, réduisent immédiatement le risque et préparent l'audit qui suivra. Pour situer votre exposition d'ensemble, l'OWASP LLM Top 10 vous donne le panorama des risques à couvrir.

Faut-il une équipe de sécurité dédiée à l'IA ?

Pas nécessairement une équipe séparée, mais des compétences dédiées. Sécuriser une IA générative demande de comprendre des failles que la sécurité applicative classique ignore. C'est souvent là qu'un regard externe formé à ces spécificités fait gagner le plus de temps.

C'est précisément l'objet de mon audit Sécurité & Conformité IA : vérifier votre cloisonnement, la provenance de vos dépendances et la robustesse réelle de votre IA avant sa mise en production, puis vous remettre une feuille de route priorisée.

Cet article a une visée pédagogique et ne constitue pas un conseil juridique. Chaque situation mérite une analyse au cas par cas.