Table of Contents

Les organisations ont déployé des systèmes IA tout au long de 2023, 2024 et 2025 à un rythme que les orientations défensives, les outils de sécurité et les pratiques opérationnelles n’ont pas suivi. Le résultat en 2026 est une large surface d’attaque mal instrumentée connectée à de véritables systèmes métiers, avec des défenses encore en cours d’assemblage.

Je veux être précis sur ce qui me préoccupe et pourquoi. Ce n’est pas un avertissement général sur les risques de l’IA. C’est une description de ce à quoi ressemble réellement la surface d’attaque, où les lacunes sont documentées, et ce que les organisations doivent traiter.

Pourquoi cet écart existe

La sécurité des logiciels traditionnels a mûri sur environ trois décennies. Des décennies d’expérience en réponse aux incidents, de recherche sur les vulnérabilités, de développement d’outils et de connaissances opérationnelles durement acquises ont produit les cadres, les produits et les pratiques sur lesquels les programmes de sécurité modernes s’appuient.

L’IA générative en entreprise a atteint des millions de déploiements en production en à peine deux ans.

Les disciplines qui font fonctionner la sécurité des logiciels — modélisation des menaces pour des architectures spécifiques, schémas de déploiement renforcés, playbooks de réponse aux incidents matures, pratiques d’audit et d’observabilité établies — n’ont pas eu le temps de se développer avant que les organisations ne commencent à déployer l’IA à grande échelle. Les orientations sont arrivées après le déploiement. Les outils sont arrivés après les orientations. L’expertise opérationnelle est encore en développement.

Ce n’est pas une attribution de responsabilité. C’est une explication pour laquelle les lacunes sont structurelles plutôt qu’accidentelles.

Les quatre couches de la sécurité de l’IA

Une grande partie de la confusion dans les discussions sur la sécurité de l’IA vient du fait que les documents de gouvernance, la taxonomie des menaces, les orientations d’ingénierie et les contrôles opérationnels sont traités comme s’ils étaient la même chose. Ils ne le sont pas.

La couche 1 est la gouvernance. NIST AI RMF, ISO/IEC 42001 et l’EU AI Act opèrent au niveau organisationnel et des processus. Ils décrivent comment gérer les risques IA, structurer la supervision et documenter la responsabilité. Ce sont des cadres de gouvernance, pas des contrôles techniques.

La couche 2 est la taxonomie des menaces. MITRE ATLAS documente les tactiques adversariales contre les systèmes IA. L’OWASP Top 10 pour les LLM et l’OWASP Agentic AI Top 10 énumèrent des classes d’attaques spécifiques. Ces documents nomment les attaques. Ils ne prescrivent pas de défenses.

La couche 3 est les orientations d’ingénierie. Google SAIF, Microsoft AI SDL, OWASP AI Exchange et NIST AI 600-1 fournissent des orientations sur la façon de construire et déployer l’IA de manière sécurisée. NIST AI 600-1 est substantiellement plus spécifique que le cadre AI RMF de base, couvrant l’injection de prompt, l’empoisonnement de données et les risques d’information pour les déploiements d’IA générative.

La couche 4 est les opérations. La surveillance, la réponse aux incidents, les contrôles d’exécution, la journalisation, le moindre privilège, les pipelines d’évaluation et la gouvernance des accès sont des pratiques opérationnelles. Ils nécessitent un processus organisationnel, pas seulement de la documentation.

La plupart des organisations ont une couverture incomplète aux couches 3 et 4. C’est là que vit presque tout le risque opérationnel.

Ce qui est en production

L’IA en entreprise en 2026, ce ne sont pas seulement des chatbots. Les systèmes en production comprennent :

  • Des systèmes RAG tirant de référentiels de documents internes, wikis, bases de données et enregistrements clients
  • Des agents de support client avec accès aux informations de compte et aux systèmes de gestion des cas
  • Des assistants de productivité internes intégrés à la messagerie, aux calendriers, aux systèmes de fichiers et aux plateformes de communication
  • Des outils de revue et génération de code avec accès aux référentiels sources
  • Des agents automatisés exécutant des workflows planifiés avec des identifiants pour des API internes
  • Des traiteurs de documents, contrats et données financières
  • Des modèles IA intégrés dans les décisions de détection de fraude, de recrutement et de contrôle d’accès

Chaque système représente une surface d’attaque différente. Un système RAG sur votre base de connaissances interne est simultanément un risque de divulgation d’informations et une cible d’injection de prompt. Un agent avec accès à la messagerie et des identifiants persistants est un processus autonome avec un vrai levier sur de vrais systèmes.

Les équipes de sécurité n’étaient souvent pas impliquées dans la décision de déployer ces systèmes. Elles découvrent fréquemment des déploiements IA existants par audit plutôt que par revue de conception.

L’IA est maintenant des deux côtés

Les mêmes capacités IA disponibles pour votre équipe de sécurité sont disponibles pour les attaquants.

Le développement assisté par IA réduit le temps nécessaire pour adapter les divulgations publiques de vulnérabilités en preuves de concept fonctionnelles et en outils opérationnels. La vitesse de passage de la lecture d’un CVE à du code fonctionnel a diminué pour quiconque utilise ces outils, y compris les attaquants.

Le contenu de phishing généré par IA produit des e-mails avec une meilleure grammaire, un contexte plus convaincant et moins d’erreurs détectables que de nombreuses attaques écrites par des humains. Les signaux de formatage et les patterns linguistiques sur lesquels vos utilisateurs ont été formés à repérer sont moins fiables quand le contenu est généré par IA.

Le clonage vocal pour les campagnes de vishing usurpe l’identité de dirigeants et de collègues lors d’appels en temps réel. La barrière à l’entrée pour l’ingénierie sociale ciblée a baissé avec l’amélioration de la qualité de la synthèse vocale et la baisse des coûts d’accès.

La vidéo deepfake pour la compromission des e-mails professionnels est passée de théorique à opérationnelle. La fraude financière utilisant des vidéos générées par IA de dirigeants autorisant des transactions a été documentée dans plusieurs secteurs depuis 2024. Votre formation de sensibilisation a été construite pour un modèle de menace différent.

Injection de prompt et empoisonnement de contexte

Comprendre l’injection de prompt est le point de départ pour comprendre la sécurité des systèmes IA.

Un modèle de langage suit les instructions intégrées dans sa fenêtre de contexte. La fenêtre de contexte comprend le prompt système, l’historique de conversation, les sorties d’outils et les documents récupérés. Le modèle ne peut pas distinguer de manière fiable les instructions du développeur d’application des instructions qu’un attaquant a intégrées dans le contenu que le modèle traite. C’est le cœur de l’injection de prompt telle que l’OWASP la définit.

L’injection directe de prompt cible directement l’entrée du modèle. L’utilisateur fournit du texte conçu pour supplanter les instructions système.

L’injection indirecte de prompt est plus grave pour les déploiements en entreprise. Votre agent RAG récupère un document de votre base de connaissances. Ce document contient des instructions disant à l’agent d’effectuer une action différente. Votre outil de synthèse traite une page web contenant des directives cachées. Votre bot de support lit une pièce jointe client contenant des instructions. L’agent traite les instructions et agit en conséquence.

L’empoisonnement de contexte est une catégorie plus large. Les attaquants n’ont pas besoin de compromettre votre modèle pour compromettre votre système IA. Ils ont besoin d’introduire du contenu malveillant dans le contexte de votre modèle. Cela inclut les documents RAG empoisonnés, les entrées mémoire empoisonnées, le contenu d’e-mail malveillant que votre agent traite, les PDF adversariaux et les pages web contrôlées par l’attaquant que votre agent de navigation visite. Ces cas diffèrent de l’empoisonnement du modèle. Le modèle va bien. Le contexte, non.

La défense en profondeur réduit ce risque. Le filtrage des entrées, la validation des sorties, les périmètres d’outils à privilèges limités, l’exécution en sandbox et les points d’approbation humaine sur les actions à enjeux élevés aident tous. Aucune de ces défenses ne ferme la classe d’attaque. OWASP, NIST, Anthropic, OpenAI et Microsoft recommandent tous des approches en couches parce qu’aucun contrôle unique n’est suffisant.

Concevez en partant de l’hypothèse que l’injection de prompt réussira sur un certain pourcentage d’entrées. Limitez les conséquences en conséquence.

Agents IA, limites de permissions et le problème du rayon d’explosion

Les agents diffèrent des chatbots d’une façon opérationnellement critique : ils prennent des actions.

Un agent connecté à votre messagerie, GitHub, Jira, Slack, Salesforce, AWS et des API internes est un processus autonome avec accès aux mêmes systèmes que vos employés les plus connectés. Une injection de prompt réussie contre cet agent ne produit pas une réponse textuelle indésirable. Elle produit une action indésirable sur un système réel.

Le rayon d’explosion d’une compromission est déterminé par ce à quoi l’agent a accès. La plupart des déploiements d’agents actuels détiennent un accès bien au-delà de ce que toute tâche individuelle nécessite. Un agent qui doit lire un ticket Jira ne devrait pas non plus avoir un accès en écriture à votre branche principale GitHub. Un agent traitant des demandes de support ne devrait pas détenir des identifiants pour votre système de facturation.

L’autorisation IA est un problème distinct de l’autorisation utilisateur. Les applications traditionnelles demandent si un utilisateur est autorisé pour une action. Les architectures d’agents nécessitent de demander si cet agent est autorisé à effectuer cette action spécifique pour cet utilisateur spécifique à ce moment spécifique, basé sur le contexte actuel. La plupart des déploiements d’agents actuels ne l’implémentent pas.

Les workflows d’approbation humaine sont censés être le dernier recours pour les actions d’agents à enjeux élevés. Les organisations découvrent qu’elles font également face à une fatigue d’approbation. Quand les agents demandent régulièrement l’approbation pour des actions routinières, les utilisateurs commencent à approuver automatiquement sans examiner la demande. Le dernier recours devient une formalité.

L’identité IA est un problème de sécurité en entreprise

Les agents détiennent des identifiants. Les tokens OAuth, les clés API, les identifiants de compte de service et les rôles IAM cloud apparaissent tous dans les déploiements d’agents IA. Ce sont des identités non humaines avec un vrai accès.

Lacunes spécifiques dans les déploiements actuels :

  • Les identifiants des agents sont souvent de longue durée et ne sont pas renouvelés selon des calendriers comparables aux comptes de service
  • Les portées des tokens d’agents sont fréquemment plus larges que ce que les tâches effectuées par l’agent nécessitent
  • La journalisation d’audit pour les actions effectuées sous des identités d’agents varie considérablement
  • La fuite d’identifiants via les prompts est un risque documenté. Un agent qui inclut ses clés API dans son contexte ou ses sorties les expose à quiconque lit la sortie ou récupère la conversation.
  • Les agents obtenant des identifiants supplémentaires via des appels d’outils créent des chaînes d’identités difficiles à auditer

Gérez vos identités d’agents de la même manière que vous gérez les comptes de service privilégiés. Cela nécessite actuellement un effort délibéré car la plupart des outils de gouvernance des identités n’ont pas de support natif pour les patterns d’identité des agents IA.

La mémoire persistante des agents crée une surface d’attaque à long horizon

Les agents avec une mémoire persistante présentent une surface d’attaque qui n’existe pas dans les systèmes sans état.

Un attaquant qui peut injecter dans la mémoire d’un agent construit une position qui persiste d’une session à l’autre. L’attaque n’a pas besoin de réussir en une seule interaction. L’influence accumulée en mémoire sur des jours ou des semaines façonne le comportement futur de l’agent. C’est parfois appelé une attaque à long horizon ou sleeper-context.

Très peu d’orientations opérationnelles existent pour ce risque spécifique. Les organisations déployant des agents avec stockage de mémoire persistante doivent :

  • Traiter les stockages de mémoire comme des données de haute valeur nécessitant des contrôles d’accès
  • Valider le contenu de la mémoire avant que les agents n’agissent en conséquence
  • Intégrer la capacité d’auditer et de revenir à un état mémoire antérieur dans leur architecture

La chaîne d’approvisionnement des modèles n’est pas traitée comme la chaîne d’approvisionnement logicielle

Les organisations téléchargeant des modèles pré-entraînés depuis des référentiels publics acceptent des artefacts IA exécutables de sources externes. La rigueur appliquée à ces téléchargements ne correspond généralement pas à ce que ces mêmes organisations appliquent aux paquets npm, PyPI ou Maven.

Risques spécifiques dans les référentiels de modèles :

  • Les fichiers de modèles au format pickle PyTorch exécutent du code Python arbitraire lors du chargement. Cela a été exploité dans des attaques documentées de la chaîne d’approvisionnement. SafeTensors est le format conçu pour résoudre ce problème spécifiquement. Préférez-le quand il est disponible.
  • Des chargeurs de modèles malveillants qui installent des dépendances ou exécutent du code de configuration à côté du modèle
  • Des modèles entraînés sur des jeux de données empoisonnés produisant des sorties subtilement incorrectes dans des contextes spécifiques
  • Des modèles avec des portes dérobées intégrées qui s’activent dans des conditions de déclenchement
  • Le name-squatting de référentiels pour livrer des modèles malveillants sous des noms familiers

Peu d’organisations maintiennent une nomenclature logicielle couvrant leurs systèmes IA. La plupart ne peuvent pas vous dire de quel modèle de base est parti un système en production, quelle version des données d’entraînement a été utilisée pour le fine-tuning, ou si les poids en déploiement correspondent aux poids qui ont été évalués en dernier. Ce niveau de traçabilité est une condition préalable à une sécurité significative de la chaîne d’approvisionnement. Il n’est pas répandu aujourd’hui.

L’IA fantôme crée des flux de données non contrôlés

Les comptes IA grand public personnels sont l’endroit où vos données se déplacent sans contrôles.

ChatGPT Enterprise, Claude Enterprise et Microsoft Copilot for M365 incluent des protections contractuelles pour les données des clients. Les comptes personnels ChatGPT, Claude, Gemini et similaires ne fournissent pas ces garanties par défaut.

Les employés utilisant des comptes personnels pour traiter des documents de travail déplacent des documents de stratégie juridique, des enregistrements clients, du code source, des projections financières, des décisions de personnel et des communications internes à travers des pipelines que votre organisation ne contrôle pas. Les équipes de sécurité n’ont fréquemment pas d’informations précises sur le volume de cette activité ou sur les catégories de données impliquées.

Vos contrôles DLP ne capturent pas les données se déplaçant via un navigateur web vers un service IA grand public. Vos politiques de rétention des données ne s’appliquent pas à l’historique des conversations sur une plateforme tierce. Vos obligations réglementaires au titre du RGPD, de l’HIPAA, de la SOX et des règles sectorielles spécifiques ne changent pas selon que les données sont parties accidentellement ou via un onglet de navigateur.

Découvrir la portée réelle avant de construire des contrôles est la première étape nécessaire. Ce que vous supposez sur ce problème est presque certainement une sous-estimation.

Les systèmes IA fuient des données d’une façon que les applications traditionnelles ne font pas

La sur-récupération RAG retourne des documents à des utilisateurs qui ne devraient pas y avoir accès. Un employé pose une question. Le composant de récupération retourne un document d’un segment restreint de la base de connaissances. La réponse inclut des informations de ce document. La défaillance du contrôle d’accès s’est produite au niveau de la couche de récupération, pas de la couche d’application. De nombreux déploiements RAG ont été construits sans appliquer des permissions au niveau du document correspondant au système source.

La fuite du prompt système révèle les instructions opérationnelles intégrées dans votre produit IA. Les prompts système doivent être traités comme confidentiels.

Les défaillances d’isolation multi-locataire se produisent quand des modèles fine-tunés sur les données de plusieurs clients exposent les informations d’un client dans le contexte d’un autre. C’est une catégorie de risque documentée pour les produits SaaS IA multi-locataires.

La mémorisation des modèles amène les modèles à reproduire verbatim le contenu des données d’entraînement. Le risque n’est pas éliminé, particulièrement pour les modèles fine-tunés sur des jeux de données privés petits ou insuffisamment dédupliqués.

Les organisations manquent de visibilité au moment de l’inférence

La plupart des déploiements IA n’ont pas une couverture équivalente de leurs composants IA par rapport à leur infrastructure.

La surveillance d’un modèle de langage ou d’un agent déployé nécessite une télémétrie différente de celle d’un serveur d’application. Les organisations doivent collecter :

  • Le contenu des prompts et sorties dans un format adapté à la revue des politiques et à la détection d’anomalies
  • Les journaux d’invocations d’outils pour les agents, y compris les noms d’outils, les arguments et les réponses
  • Les journaux de récupération pour les systèmes RAG, y compris les requêtes, les documents retournés et les décisions de contrôle d’accès
  • Les signaux de classification pour les tentatives de jailbreak et d’injection
  • La surveillance de la cohérence des sorties pour détecter la dérive comportementale entre les versions de modèle
  • Les patterns de latence susceptibles d’indiquer des tentatives de bourrage de contexte

De nombreuses organisations qui ont déployé l’IA en 2023 et 2024 ont des codes de statut HTTP et des métriques de latence. La télémétrie nécessaire pour détecter ou enquêter sur un incident de sécurité IA n’existe souvent pas dans ces environnements. Avant un incident n’est pas le bon moment pour le découvrir.

La réponse aux incidents IA nécessite ses propres playbooks

Vos playbooks IR existants couvrent les terminaux, les réseaux, les applications et l’identité. Ils ne couvrent pas les scénarios spécifiques à l’IA.

Questions auxquelles votre équipe IR sera confrontée que les playbooks actuels n’adressent pas :

  • Comment déterminer si un modèle a été empoisonné pendant un run de fine-tuning
  • Comment évaluer le rayon d’explosion d’une injection indirecte réussie contre un agent avec accès en écriture à plusieurs systèmes
  • Comment évaluer si des données d’entraînement ou de fine-tuning ont été exfiltrées lors d’une compromission de la chaîne d’approvisionnement
  • Comment établir une baseline comportementale pour un modèle et la comparer après un incident
  • Comment répondre quand une mise à jour de modèle d’un fournisseur tiers introduit un comportement qui semble intentionnel plutôt qu’accidentel
  • Comment déterminer si le stockage mémoire d’un agent a été manipulé dans le temps

Ces scénarios nécessitent une préparation avant qu’ils ne surviennent. Vous avez besoin de télémétrie en place avant l’incident. Vous avez besoin de baselines de comportement de modèle documentées avant d’avoir besoin de les comparer.

Ce que vous devriez faire

Inventoriez ce qui est déployé. Sachez ce qui tourne, quelles données il accède, quels identifiants il détient, quels outils il appelle et quelles actions il effectue. C’est le prérequis pour tout le reste.

Traitez les agents IA comme des comptes privilégiés. Appliquez le moindre privilège. Limitez les identifiants à l’accès minimum requis pour chaque tâche. Auditez ce à quoi chaque agent a accès et supprimez ce qui n’est pas nécessaire.

Implémentez une observabilité spécifique à l’IA avant le déploiement, pas après un incident. La journalisation des prompts et sorties, la journalisation des invocations d’outils et la journalisation des récupérations sont la télémétrie minimale pour l’analyse de sécurité.

Évaluez votre exposition à l’IA fantôme. Trouvez quels services IA les employés utilisent pour les tâches de travail. Déterminez quelles catégories de données transitent par des comptes personnels. Construisez des politiques et des contrôles basés sur les résultats réels.

Appliquez des contrôles d’accès au niveau du document dans les systèmes RAG. Si votre couche de récupération n’applique pas les règles d’accès de vos systèmes sources, corrigez-le avant qu’il ne présente un document restreint à un utilisateur non autorisé.

Auditez votre chaîne d’approvisionnement de modèles. Documentez chaque modèle de base utilisé. Préférez SafeTensors aux formats pickle. Appliquez la rigueur de la chaîne d’approvisionnement aux artefacts de modèle comparable à ce que vous appliquez aux dépendances logicielles.

Gouvernez les identités des agents. Gérez les tokens OAuth et clés API des agents avec les mêmes pratiques de cycle de vie, de revue de portée et de rotation que vous appliquez aux comptes de service privilégiés.

Construisez des runbooks IR spécifiques à l’IA maintenant. Définissez avant un incident comment vous enquêteriez sur des scénarios spécifiques à l’IA, quelles preuves vous avez besoin et quelles sont vos options de réponse.

Exécutez des évaluations avant de déployer l’IA dans des contextes à enjeux élevés. Commencez avec les cadres publics disponibles si vous n’avez pas d’outils internes.

Ne traitez pas la conformité de gouvernance comme une posture de sécurité. Les cadres de gouvernance décrivent les processus et la gestion des risques. Ils ne décrivent pas des systèmes techniquement défensifs. Les deux sont nécessaires.

Références

  • NIST AI Risk Management Framework (AI RMF 1.0), 2023
  • NIST AI 600-1: Generative AI Profile, 2024
  • OWASP Top 10 for Large Language Model Applications, 2025
  • OWASP Agentic AI Top 10
  • OWASP AI Exchange
  • MITRE ATLAS: Adversarial Threat Landscape for AI Systems
  • Google Secure AI Framework (SAIF)
  • Microsoft AI Security SDL
  • CISA Guidance on AI Cybersecurity, 2024
  • ISO/IEC 42001:2023 Artificial Intelligence Management Systems
  • EU AI Act, Regulation (EU) 2024/1689
  • SafeTensors format documentation, Hugging Face