Sécurité de l'IA générative en entreprise

Sécuriser une IA générative en entreprise, c'est d'abord la traiter comme n'importe quelle application : comptes, droits, réseau, mises à jour, sauvegardes. C'est ensuite ajouter des protections contre des attaques qui n'existent pas ailleurs : un texte qui détourne le modèle (injection de prompt), une base documentaire piégée (empoisonnement), une réponse qui laisse sortir des données (exfiltration). Ce site s'adresse à ceux qui mettent ces systèmes en place : DSI (direction des systèmes d'information), RSSI (responsable de la sécurité des systèmes d'information), développeurs, dirigeants techniques de PME.

Ce que disent les deux référentiels de base

L'ANSSI (Agence nationale de la sécurité des systèmes d'information) a publié le 29/04/2024 ses « Recommandations de sécurité pour un système d'IA générative » (référence ANSSI-PA-102). Le guide pose un principe simple : un système d'IA générative est d'abord une application métier standard, qui doit disposer du même socle de sécurité que les autres applications. Il ajoute trois familles d'attaques propres à l'IA :

Côté développement, la référence est le Top 10 de l'OWASP (fondation qui publie des référentiels de sécurité applicative) pour les applications de modèles de langage. L'édition 2026, parue en août 2026, garde l'injection de prompt en tête et fait monter au troisième rang l'« agentivité excessive », c'est-à-dire les droits et l'autonomie trop larges laissés au modèle. Le détail est sur la page OWASP Top 10 LLM 2026.

Le principe qui traverse tout le site

La lettre d'introduction du Top 10 2026 le résume ainsi : cessez d'essayer de construire un modèle impossible à tromper, construisez plutôt le système autour, pour que rien d'important ne casse le jour où il sera trompé. Concrètement :

• les droits d'accès aux documents se vérifient avant que le modèle ne lise quoi que ce soit ;
• les actions sensibles (envoyer, payer, supprimer) passent par du code et par une validation humaine, pas par une consigne écrite au modèle ;
• chaque traitement est journalisé, pour pouvoir reconstituer un incident ;
• le système est testé par des attaques avant sa mise en service, puis régulièrement.

Par où commencer

Ce que ce site ne traite pas

La sécurité propre aux serveurs MCP (Model Context Protocol, le standard qui branche des outils à un modèle) est détaillée sur la page sécurité de Cercle IA Tech · MCP. Pour les agents qui agissent seuls, voyez aussi comment limiter les permissions d'un agent ; le RGPD (règlement général sur la protection des données) relève d'un autre volet. Ici, on reste sur la sécurité : ce qui peut être attaqué, comment, et ce qui limite les dégâts. Rien sur ce site n'est un avis juridique.

Notre méthode

Chaque page cite les documents lus pour l'écrire, d'abord les sources officielles : guides de l'ANSSI, recommandations de la CNIL (Commission nationale de l'informatique et des libertés), référentiels de l'OWASP et du NIST (institut américain des normes et de la technologie), documentation des éditeurs. Les dates et les numéros de recommandation sont repris tels que lus le 15/11/2026.

Cercle IA Tech est édité par IArche, qui édite aussi ALMA, la plateforme IA pour PME. Les pages de ce site décrivent des risques et des méthodes, pas un produit.