Sécurité des IA génératives en entreprise : le guide complet pour RSSI (2026)

Temps de lecture : 14 min · Mis à jour : juillet 2026.

En moins de trois ans, l'IA générative est passée du statut de curiosité à celui d'infrastructure. Copilotes intégrés à la bureautique, assistants de code, chatbots clients, moteurs de recherche interne fondés sur du RAG (Retrieval-Augmented Generation), et désormais agents autonomes capables d'exécuter des actions : ces systèmes manipulent aujourd'hui vos données les plus sensibles et, de plus en plus, agissent sur vos systèmes d'information.

Pourtant, la plupart des entreprises françaises n'ont toujours pas de référentiel de sécurité dédié à l'IA générative. Le RSSI hérite d'une surface d'attaque nouvelle, mal documentée, qui ne rentre dans aucune case des pare-feux traditionnels. Une injection de prompt n'est pas une injection SQL. Une fuite de données par un modèle n'est pas une exfiltration classique. Un agent IA doté de droits excessifs n'est pas un compte de service ordinaire.

Ce guide fait le pont entre deux référentiels de référence — le OWASP Top 10 for LLM Applications 2025 et les 35 recommandations de sécurité de l'ANSSI (ANSSI-PA-102) — et les traduit en un plan d'action concret pour un RSSI.

Pourquoi l'IA générative crée une surface d'attaque inédite

La sécurité informatique classique repose sur une hypothèse : le code fait ce pour quoi il a été écrit. Avec un modèle de langage, cette hypothèse tombe. Le comportement du système est probabiliste, dépend d'entrées en langage naturel, et peut être détourné par de simples instructions textuelles.

Trois propriétés rendent l'IA générative structurellement difficile à sécuriser :

• La frontière entre données et instructions disparaît. Pour un LLM, tout est du texte. Un document, un e-mail, une page web « lus » par le modèle peuvent contenir des instructions cachées qui prennent le pas sur vos consignes. C'est le principe de l'injection de prompt indirecte.
• Le modèle mémorise et peut restituer. Un système entraîné ou connecté à des données non publiques peut révéler des informations confidentielles, des données personnelles ou des secrets.
• L'IA agit désormais. Avec les agents, le LLM ne se contente plus de répondre : il appelle des outils, exécute des requêtes, envoie des e-mails. Une manipulation ne provoque plus seulement une mauvaise réponse, mais une action destructrice.

L'ANSSI, dans sa note du 4 février 2026 (CERTFR-2026-CTI-001), rappelle que ces outils sont utilisés « tant de manière encadrée et officielle que de façon informelle, voire dissimulée » — le fameux Shadow AI. La première étape de la sécurité consiste donc à savoir quels systèmes d'IA existent réellement dans l'organisation : c'est l'enjeu de détecter les usages ChatGPT invisibles.

Le référentiel OWASP Top 10 for LLM Applications 2025

L'OWASP (Open Worldwide Application Security Project) publie depuis 2023 un Top 10 dédié aux applications fondées sur des LLM. La version 2025 introduit deux nouvelles catégories — la fuite de prompt système et les faiblesses des vecteurs/embeddings — et réorganise plusieurs risques pour refléter l'essor des agents et du RAG.

Les dix risques, traduits pour un contexte entreprise :

• LLM01 — Injection de prompt. Une entrée manipule le comportement du modèle : contournement des garde-fous, exécution de commandes via des outils connectés. Risque n°1.
• LLM02 — Divulgation d'informations sensibles. Le modèle révèle des données confidentielles, des PII ou des secrets — risque RGPD direct.
• LLM03 — Vulnérabilités de la chaîne d'approvisionnement. Modèles, jeux de données ou composants tiers compromis.
• LLM04 — Empoisonnement des données et du modèle. Injection de données malveillantes pendant l'entraînement ou le fine-tuning.
• LLM05 — Gestion incorrecte des sorties. Sorties transmises sans contrôle à d'autres systèmes (XSS, injection SQL, exécution de code).
• LLM06 — Agence excessive. L'IA dispose de trop de permissions, d'outils ou d'autonomie ; une manipulation devient une action réelle.
• LLM07 — Fuite de prompt système. Les instructions internes (règles, secrets) sont exposées, révélant le fonctionnement du système.
• LLM08 — Faiblesses des vecteurs et embeddings. Failles dans les bases vectorielles du RAG : empoisonnement, fuite inter-tenant, accès non maîtrisé.
• LLM09 — Désinformation. Le modèle produit des contenus faux mais crédibles (hallucinations) sur lesquels on prend des décisions.
• LLM10 — Consommation non bornée. Abus de ressources : déni de service, explosion des coûts, extraction de modèle.

Ce référentiel constitue la grille d'analyse technique de tout système d'IA générative. Chaque copilote, chaque chatbot, chaque agent devrait être passé au crible de ces dix risques.

Les 35 recommandations de l'ANSSI : le cadre français

Le 29 avril 2024, l'ANSSI a publié « Recommandations de sécurité pour un système d'IA générative » (ANSSI-PA-102), un guide destiné explicitement aux RSSI, DSI, data scientists et data engineers. Il énonce 35 recommandations couvrant les trois phases du cycle de vie d'un système d'IA générative :

• Entraînement — sécurisation des données et des environnements d'apprentissage.
• Intégration et déploiement — cloisonnement, gestion des accès, contrôle des composants tiers.
• Production — supervision, filtrage des entrées/sorties, journalisation, gestion des incidents.

L'ANSSI y décrit trois familles de scénarios d'attaque : manipulation (détourner le comportement), infection (empoisonner les données ou la chaîne) et exfiltration (extraire données ou modèle). Ces trois familles recoupent directement le Top 10 OWASP.

Points saillants pour un RSSI : traiter l'IA générative comme un composant critique du SI (EBIOS RM se prête bien à l'exercice) ; cloisonner les systèmes d'IA et limiter leurs interconnexions ; maîtriser les droits accordés aux systèmes automatisés ; journaliser et superviser les interactions. En 2026, l'ANSSI a complété ce socle par des publications ciblées sur les agents IA autonomes (CERTFR-2026-ACT-016), identifiant cinq risques majeurs propres aux agents : compromission du poste utilisateur, fuite de données vers des ressources externes, droits d'accès démesurés, partage de secrets d'authentification, et perte de maîtrise des actions.

Les cinq risques que tout RSSI doit traiter en priorité

L'injection de prompt (directe et indirecte)

La menace n°1. En injection directe, l'utilisateur manipule lui-même le modèle. En injection indirecte, l'instruction malveillante est cachée dans une source externe que le modèle consulte : un e-mail, une page web, un document, une réponse d'API. Avec un agent connecté à des outils, une injection réussie peut déclencher des actions non autorisées.

Contre-mesures : séparation stricte entre instructions système et contenu utilisateur, filtrage des entrées, validation des sorties, moindre privilège sur les outils connectés, revue humaine pour les actions sensibles.

La fuite de données sensibles

Vos collaborateurs collent des informations confidentielles dans des services d'IA grand public. Vos systèmes RAG interrogent des bases où cohabitent des documents de niveaux de confidentialité différents. L'ANSSI cite d'ailleurs des compromissions de comptes ChatGPT par infostealers.

Contre-mesures : classification des données, contrôle d'accès sur les bases vectorielles, filtrage des sorties (DLP appliqué à l'IA), politiques d'usage claires, instances hébergées et cloisonnées pour les cas sensibles.

L'agence excessive

Plus un agent dispose de permissions, d'outils et d'autonomie, plus une manipulation devient dangereuse. Un agent capable d'envoyer des e-mails, de modifier des fichiers ou de passer des commandes est un vecteur d'action, pas seulement de réponse.

Contre-mesures : moindre privilège, périmètre d'outils minimal, validation humaine pour les actions irréversibles, journalisation exhaustive, red teaming avant mise en production.

Les faiblesses du RAG et des bases vectorielles

Le RAG est devenu la brique standard des assistants d'entreprise. Mais la base vectorielle est un actif de sécurité à part entière : mal cloisonnée, elle peut laisser fuiter des données entre équipes ou entre clients, ou être empoisonnée par des documents piégés.

Contre-mesures : isolation par tenant, contrôle d'accès au niveau des documents, validation des sources ingérées, surveillance de l'intégrité de l'index.

La gouvernance de la Shadow AI

On ne sécurise que ce que l'on connaît. Or une large part des usages d'IA échappe au SI officiel. Sans cartographie, les quatre priorités précédentes restent théoriques.

Contre-mesures : inventaire continu des usages IA, registre des systèmes, politique d'usage et sensibilisation — c'est précisément la brique que SiyadAI industrialise.

Méthode en 6 étapes pour sécuriser vos IA génératives

• Cartographier. Inventoriez tous les systèmes d'IA générative : officiels, expérimentaux et non déclarés (Shadow AI). Un système inconnu est un système non sécurisé.
• Classifier par risque. Croisez sensibilité des données, niveau d'autonomie (répond / agit) et exposition (interne / externe).
• Évaluer avec OWASP + ANSSI. Passez chaque système au crible des dix risques OWASP et des recommandations ANSSI pertinentes pour sa phase de cycle de vie.
• Prioriser et remédier. Concentrez l'effort sur l'injection de prompt, la fuite de données et l'agence excessive avant le reste.
• Superviser. Journalisez les interactions, mettez en place des alertes, définissez un plan de réponse à incident spécifique à l'IA.
• Réévaluer en continu. Les modèles, les usages et les menaces évoluent vite. La sécurité de l'IA est un cycle, pas un projet ponctuel.

Sécurité de l'IA et conformité : deux faces d'une même pièce

La sécurité technique doit s'articuler avec la conformité. L'article 15 de l'AI Act impose aux systèmes à haut risque un niveau approprié d'exactitude, de robustesse et de cybersécurité — voir ce qui reste obligatoire le 2 août 2026. La norme ISO/IEC 42001 exige un système de management de l'IA incluant la maîtrise des risques (ISO 42001 vs AI Act). Le RGPD s'applique dès qu'un système traite des données personnelles.

Autrement dit : un incident de sécurité IA est souvent aussi un incident de conformité. Le RSSI et le DPO doivent partager un référentiel commun — un registre unique des systèmes d'IA, articulé avec la gouvernance de l'IA en entreprise.

Comment SiyadAI aide les RSSI

SiyadAI industrialise la première étape, la plus négligée : la cartographie et la maîtrise continue des usages d'IA. La plateforme détecte les usages (y compris Shadow AI), constitue un registre vivant des systèmes d'IA, associe à chacun ses risques (grille OWASP/ANSSI) et son statut de conformité (AI Act, ISO 42001, RGPD), et fournit au RSSI comme au DPO un tableau de bord unique.

Vous voulez savoir quels systèmes d'IA existent réellement chez vous ? Lancez un Scan Shadow AI gratuit, ou réservez une démonstration de 15 minutes.

Sources et références

• OWASP — Top 10 for LLM Applications 2025 (GenAI Security Project)
• ANSSI — Recommandations de sécurité pour un système d'IA générative (ANSSI-PA-102)
• ANSSI — CERTFR-2026-CTI-001 (04/02/2026) ; CERTFR-2026-ACT-016 (agents IA)
• Commission européenne — AI Act, article 15 (exactitude, robustesse, cybersécurité)
• ISO/IEC 42001:2023 — Systèmes de management de l'intelligence artificielle

Cet article a une vocation informative et ne constitue pas un conseil juridique.