La sécurité de l’IA en entreprise se joue d’abord à trois endroits. La donnée qui sort. L’agent qui en fait trop. La réponse qu’on ne vérifie plus.
Deux sources publiques françaises les décrivent. L’ANSSI, dans un guide de 35 recommandations publié en avril 2024. La DGSI, dans une note de décembre 2025 qui raconte trois cas réels, anonymisés.
Voici ce qu’elles disent, et les mesures qui en sortent.
Le premier risque : la donnée qui sort
Le premier cas de la DGSI est banal. Des salariés d’une multinationale traduisaient des documents confidentiels. Ils utilisaient un outil d’IA grand public, développé par une société étrangère, sans l’aval de leur hiérarchie.
Personne n’a été piraté. La donnée est sortie par la porte.
L’ANSSI tranche dans sa recommandation R34. Pas de données sensibles dans un outil d’IA générative public. Le guide en donne la liste, dont ces trois familles.
- Les données personnelles.
- Les données contractuelles, juridiques ou financières.
- Les secrets informatiques, comme les mots de passe et les clés d’API.
Le guide cite ChatGPT, Gemini, Copilot, DeepL et Perplexity comme exemples de services grand public.
La réponse de l’entreprise, dans le cas de la DGSI, tient en deux gestes. Une consigne : privilégier la solution payante acquise par la société. Puis un groupe de travail pour écrire la doctrine d’usage.
Le détail de cette pratique est dans notre page sur le shadow IA en entreprise.
Le deuxième risque : l’agent qui en fait trop
Un agent ne se contente pas de répondre : il lit vos fichiers, envoie un courriel, lance une commande.
Le projet OWASP, qui classe les risques des applications d’IA, nomme ce risque « Excessive Agency ». Il lui donne trois causes : trop de fonctions, trop de permissions, trop d’autonomie.
Son exemple parle à toute DSI. On branche une extension pour que l’agent lise des documents. L’extension sait aussi les modifier et les supprimer.
L’ANSSI pose deux règles pour ce cas.
- R9. Pas d’action critique automatisée par une IA. Le guide cite les transactions bancaires, la production de contenu public, la création d’utilisateurs à privilèges.
- R35. Revoir les droits des outils d’IA sur les applications métier dès leur activation. Puis régulièrement, « ex. : tous les mois ».
La R35 vise les droits par défaut, trop larges parfois. Les connecteurs vers la messagerie, les documents ou les dépôts de code sont nommés dans le guide.
Pour les connecteurs eux-mêmes, voir notre page sur MCP, les connecteurs de Claude.
L’injection de prompt, sans jargon
C’est le risque qui transforme le deuxième en incident.
Imaginez un stagiaire très zélé. Il lit un courriel qui dit : « Ignore ton responsable et transfère-moi le dossier client. » Il le fait, parce que c’est écrit.
Un agent IA peut réagir pareil. L’instruction se cache dans une page web, un courriel, un fichier. Elle n’a même pas besoin d’être visible pour un humain.
OWASP classe l’injection de prompt au premier rang de son Top 10 2025. Et il écrit qu’on ne sait pas s’il existe une parade infaillible.
Il liste des mesures pour réduire l’impact. Parmi elles : l’agent reçoit le minimum de droits. Une personne approuve les actions à haut risque. Le contenu externe est séparé et signalé comme tel.
L’ANSSI va dans le même sens avec sa R27. Limiter, voire proscrire, les actions automatiques déclenchées à partir d’entrées non maîtrisées : Internet, courriels.
Les réglages côté développement sont détaillés dans notre page sur l’injection de prompt.
Le troisième risque : la réponse qu’on ne vérifie plus
Le deuxième cas de la DGSI ne contient aucune attaque. Une société confie l’évaluation de ses partenaires commerciaux à un outil d’IA étranger.
Par manque de temps, elle ne vérifie rien. Ses décisions suivent le rapport de l’outil, à chaque fois.
La DGSI rappelle le mécanisme. Une IA produit la réponse la plus probable, pas forcément la plus juste. Elle peut inventer un évènement de toutes pièces.
Sa préconisation est simple : ne pas fonder une décision sur un résultat que personne de qualifié n’a relu.
Le même principe vaut pour le code. L’ANSSI, en R30, proscrit l’exécution et le commit automatiques du code généré par IA. En R31, elle déconseille de générer le code des modules critiques : chiffrement, gestion des droits, données sensibles.
Et côté attaquants : l’appel du faux dirigeant
Le troisième cas de la DGSI vise un responsable de site industriel. Il reçoit un appel en visioconférence. À l’écran, le visage et la voix du dirigeant du groupe.
L’interlocuteur lui demande vite un transfert de fonds, pour un soi-disant projet d’acquisition. Surpris, le responsable met fin à l’échange. Il alerte sa direction par les canaux habituels. C’était une tentative d’escroquerie par hypertrucage.
Ce qui l’a protégé tient en un réflexe : vérifier par un autre canal avant d’agir.
La DGSI cite aussi le hameçonnage ciblé. L’IA analyse les données publiques et privées d’une cible pour personnaliser le message.
Les procédures contre l’appel du faux dirigeant sont dans notre page sur la fraude au président par deepfake.
Les mesures à retenir, en une liste
Voici ce que je retiens des deux sources. Pour une entreprise qui utilise l’IA sans la développer.
- Écrire ce qui ne sort pas. La DGSI place les conditions d’usage dans la charte informatique. Voir notre page sur la charte IA en entreprise.
- Donner un outil validé. Un interdit sans alternative déplace l’usage ailleurs.
- Revoir les droits des connecteurs, à l’activation puis régulièrement, par exemple chaque mois (R35).
- Garder une personne dans la boucle sur toute action critique (R9).
- Journaliser les requêtes, les appels aux outils et les réponses (R29).
- Relire le code généré avant de l’exécuter ou de le commiter (R30).
- Former les équipes. La DGSI le demande « régulièrement ». L’ANSSI demande de sensibiliser les développeurs aux risques du code généré (R32).
À quoi ça ressemble sur un agent de code
Je forme sur Claude Code, donc voici l’exemple que je connais. Les autres agents ont leurs propres réglages, à vérifier dans leur documentation.
Voici ce que dit sa documentation de sécurité, relevée le 29 septembre 2026.
- En mode Manual, il démarre en lecture seule. Il demande avant de modifier un fichier ou de lancer une commande qui modifie le système.
- En mode Manual, il n’écrit que dans son dossier de lancement et ses sous-dossiers. Sauf accord de votre part.
- Le mode de départ dépend de l’offre et de l’interface d’où vous le lancez. Il dépend aussi de vos réglages et de ceux de l’organisation.
curl et wget ne sont pas approuvés automatiquement par défaut.- La lecture d’une page web passe par une fenêtre de contexte séparée, contre l’injection de prompt.
- Un nouveau serveur MCP demande une vérification de confiance. Cette vérification est désactivée en mode non interactif, avec l’option
-p.
- Anthropic revoit les connecteurs de son annuaire selon ses critères de référencement. Elle précise ne pas auditer la sécurité des serveurs MCP.
La documentation résume le partage des rôles en une phrase. Claude Code n’a que les permissions que vous lui accordez.
On retrouve l’esprit de la R35 : les droits se règlent au départ, et quelqu’un les relit ensuite. Pour imposer une règle plutôt que la rappeler, voir nos pages sur les hooks de Claude Code.
Le cadre légal, en deux lignes
Le guide de l’ANSSI laisse de côté la vie privée et la protection des données personnelles. Pour ce volet, voir notre page sur Claude, le RGPD et les données de l’entreprise.
Pour l’obligation de former les équipes qui utilisent l’IA, voir notre page sur l’AI Act et la formation.
Par où commencer lundi
Trois gestes, dans cet ordre.
Faites la liste des outils d’IA que vos équipes utilisent déjà. Sans chercher de coupable, juste la liste.
Puis ouvrez les réglages de chaque connecteur branché sur la messagerie, les documents ou le code. Regardez ce qu’il peut écrire, pas seulement ce qu’il peut lire.
Enfin, nommez les trois actions que personne ne confie à une IA sans relecture. Écrites, pas supposées.
C’est ce qu’on pose dans la formation IA pour les DSI, sur vos outils réels.