Guides
Recommandations ANSSI (PA-102) : le socle cyber d'une IA générative en clair
Whondy Drouode
Consultant GRC IA
Si vous déployez une IA générative en interne, l'ANSSI vous demande de la traiter comme un système sensible, pas comme une application banale. Isoler les phases d'entraînement, de déploiement et de production. Maîtriser vos dépendances. 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. Je pars du problème concret que pose une IA générative déployée trop vite, puis je déroule la méthode en quatre étapes qui transforme ces recommandations en plan d'action 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, puis le connecte à des espaces de fichiers sensibles. Un incident finit par révéler 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 : 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. 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 :
- 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.
- 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 qu'un inventaire de composants logiciels, appliqué cette fois aux modèles.
- 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 : il éprouve la robustesse réelle, là où un questionnaire ne mesure qu'une conformité sur le papier.
- 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 :
| Recommandation ANSSI | Action concrète côté RSSI |
|---|---|
| Isolation des phases | Trois environnements séparés, comptes et réseaux distincts, aucune donnée de production dans les bacs à sable |
| Maîtrise des dépendances | Inventaire des modèles et bibliothèques, provenance vérifiée, versions figées et mises à jour tracées |
| Audit avant mise en production | Test de sécurité offensif obligatoire, mené par des personnes formées aux failles spécifiques des IA, avec plan de correction |
| Supervision continue | Journalisation des accès et des requêtes, détection des usages anormaux, revue périodique |
| Souveraineté | Hébergement et traitement maîtrisés en Union européenne, dépendances critiques identifiées |
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. J'en détaille la mise en œuvre dans le choix d'un hébergement IA en Union européenne.
Questions fréquentes
Les recommandations de l'ANSSI sont-elles obligatoires ?
Ce sont des recommandations, pas une loi : 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.
Elles recoupent en plus des obligations bien réelles. Si vous relevez de NIS2, les dix mesures de l'article 21 couvrent une bonne partie du même terrain : le test en 6 questions vous dit en cinq minutes si vous êtes dans le périmètre.
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 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.