Défense robuste des systèmes d’IA en entreprise : une méthodologie de sécurité hybride pour les modèles, les données, les agents et la chaîne d’approvisionnement en 2026

1. Introduction

L’adoption massive des systèmes d’IA a transformé la surface d’attaque des organisations d’une manière comparable à l’introduction du cloud hybride et des architectures microservices, mais avec des risques nettement plus polymorphes. En 2026, une application “IA” typique n’est plus un simple modèle exposé par une API. Elle agrège un ou plusieurs modèles fondation, des couches d’orchestration, des mécanismes de mémoire, des connecteurs vers des dépôts documentaires, des capacités d’exécution d’outils, des dépendances open source, des services SaaS et des règles de gouvernance. Cette composition crée des interactions non triviales entre sécurité applicative, sécurité des données, sécurité de la chaîne d’approvisionnement et sécurité des modèles eux-mêmes. Dans ce contexte, les approches traditionnelles centrées uniquement sur le périmètre réseau ou sur l’authentification d’API s’avèrent insuffisantes.

Le problème central est que les systèmes d’IA modernes ne produisent pas seulement des sorties, ils prennent des décisions, synthétisent des informations, déclenchent des actions et manipulent des données potentiellement sensibles. Un assistant interne peut ainsi résumer des contrats, proposer des corrections de code, interroger un ERP ou lancer une tâche dans un pipeline CI/CD. Chaque interaction introduit une possibilité d’abus : une injection de prompt peut détourner le comportement, un corpus RAG empoisonné peut influencer la réponse, un agent peut être poussé à exfiltrer un secret, et une dépendance compromise peut modifier le comportement du système en amont. Les attaquants n’ont plus besoin d’un exploit mémoire classique pour obtenir un impact ; ils peuvent exploiter la logique même de l’architecture IA.

La discipline “AI Security” s’est donc consolidée en 2024-2026 autour de plusieurs axes : sécurité des données d’entraînement, robustesse adversariale, protection des modèles et des poids, sécurité des prompts et du contexte, contrôle des agents outillés, surveillance des chaînes d’approvisionnement ML, et gouvernance du risque d’IA. Des cadres comme le NIST AI RMF, les recommandations de l’OWASP Top 10 for LLM Applications, les travaux de MITRE ATLAS et les guides CISA sur la sécurisation des systèmes d’IA ont fourni des repères utiles, mais la réalité opérationnelle en entreprise demeure fragmentée. Les équipes de sécurité doivent souvent composer avec des outils hétérogènes, des workflows rapides imposés par les métiers, des intégrations tierces difficiles à auditer et une pression forte pour déployer rapidement des fonctionnalités “copilot” ou “agentic”.

L’objectif de cet article est de proposer une méthodologie de sécurité applicable en environnement 2026, orientée vers la défense réelle et mesurable. Nous partons d’un constat simple : protéger l’IA nécessite de traiter simultanément la confidentialité, l’intégrité, la disponibilité, la traçabilité et la résilience fonctionnelle. Nous proposons une architecture de défense en profondeur qui s’applique aux modèles, aux prompts, aux documents, aux outils, aux dépendances et aux interactions humaines. Cette architecture est conçue pour s’intégrer dans des environnements modernes, notamment ceux reposant sur des plateformes cloud, des environnements Kubernetes, des pipelines CI/CD, des outils de gouvernance des données, des SIEM/XDR et des systèmes de surveillance eBPF.

Notre contribution est triple. Premièrement, nous formalisons un modèle de menace spécifique aux systèmes d’IA d’entreprise, en distinguant les actifs, les frontières de confiance et les chemins d’attaque les plus fréquents. Deuxièmement, nous décrivons une méthodologie de défense opérationnelle combinant politiques d’accès, filtrage sémantique, sandboxing des outils, détection d’anomalies et évaluation continue. Troisièmement, nous présentons une implémentation concrète et une évaluation expérimentale sur des scénarios réalistes, afin de montrer les gains de sécurité et les compromis en performance.

L’enjeu n’est pas seulement technique ; il est aussi organisationnel. Une organisation peut posséder un très bon modèle de machine learning et malgré tout échouer à le sécuriser si elle n’impose pas de gouvernance des données, de gestion stricte des secrets, de revue des connecteurs, de journaux exploitables et de processus de red teaming. À l’inverse, un cadre trop rigide peut tuer l’utilité métier du système. La question n’est donc pas “faut-il sécuriser l’IA ?”, mais “comment la sécuriser sans neutraliser sa valeur ?”. Cet article répond à cette question par une approche structurée, auditable et adaptée aux pratiques de 2026.

2. Background and Related Work

La littérature sur la sécurité de l’IA s’est densifiée à mesure que les déploiements se sont industrialisés. Historiquement, les travaux se concentraient sur l’empoisonnement de données, les attaques adversariales en vision, l’extraction de modèles et l’inférence d’appartenance. Ces thèmes restent pertinents, mais le paradigme a changé avec l’essor des grands modèles de langage, des architectures RAG et des agents outillés. L’attaquant n’a plus besoin d’influencer un classifieur isolé ; il peut tenter de manipuler la chaîne complète de raisonnement, de récupération et d’exécution. Les vulnérabilités sont donc désormais autant logiques qu’algorithmiques.

Les attaques adversariales classiques ont été largement documentées dans la littérature académique, notamment pour la classification d’images et le NLP. La fragilité des modèles face à de petites perturbations a montré très tôt que la robustesse statistique ne suffisait pas. En parallèle, les travaux sur le poisoning ont mis en évidence la possibilité d’injecter des exemples malveillants dans les données d’entraînement pour dégrader la précision ou introduire des comportements ciblés. Ces bases théoriques restent utiles, mais les systèmes de 2026 ajoutent des couches d’orchestration où les attaques peuvent se produire à différents niveaux du cycle de vie.

Les LLM ont introduit une nouvelle classe de menaces, en particulier l’injection de prompt, la fuite de contexte, la divulgation de données privées et l’abus d’outils. L’OWASP Top 10 for LLM Applications a formalisé plusieurs risques majeurs, dont le prompt injection, la data poisoning, la supply chain compromise, l’excessive agency et la sensitive information disclosure. MITRE ATLAS a, de son côté, structuré les tactiques et techniques d’attaque contre les systèmes d’IA, permettant aux équipes de défense de raisonner en termes de kill chain. Le NIST AI RMF a apporté une grammaire de gestion du risque, mais son niveau de généralité impose des traductions opérationnelles pour les équipes terrain.

Les travaux sur les agents autonomes et semi-autonomes ont montré que l’ajout d’outils amplifie le risque. Un modèle qui peut appeler une fonction de recherche, envoyer un courriel, modifier un ticket ou exécuter un script devient une cible de choix pour les attaques de type indirect prompt injection. Le problème n’est pas seulement que le modèle “comprend mal” une instruction ; c’est qu’il peut transformer une instruction malveillante en action réelle. Dans les environnements d’entreprise, cette capacité se connecte souvent à des systèmes sensibles : CRM, ERP, stockage cloud, dépôts Git, systèmes ITSM, bases de connaissances, ou même plateformes d’automatisation de tâches.

La chaîne d’approvisionnement logicielle constitue un autre axe majeur. Les modèles open source, les poids téléchargés, les embeddings, les bibliothèques d’inférence, les connecteurs RAG et les conteneurs d’exécution peuvent tous être compromis. Les organisations ont appris, à leurs dépens, que les dépendances Python, les images Docker, les notebooks et les modèles publiés sur des hubs publics peuvent contenir des risques substantiels. Les attaques supply chain sur l’IA exploitent la confiance implicite accordée aux artefacts téléchargés. La sécurité du pipeline ML/LLM doit donc intégrer la provenance, le hachage, la signature, l’analyse statique et la validation comportementale.

Sur le plan défensif, plusieurs familles de solutions se sont imposées d’ici 2026. Les garde-fous de prompt et de sortie, les filtres de contenu, les politiques d’accès, le contrôle des outils, l’observabilité des interactions, les systèmes de détection d’anomalies et les évaluations de robustesse deviennent des pratiques standard. Toutefois, chacune présente des limites. Un filtre lexical est contournable par paraphrase. Une sandbox mal conçue peut laisser passer des side effects. Une évaluation ponctuelle vieillit rapidement face à des attaquants adaptatifs. Il faut donc une défense multicouche, testée en continu.

Le tableau suivant résume les classes de menaces les plus critiques et leurs contre-mesures principales.

Classe de menace	Exemple opérationnel	Impact	Contre-mesures principales
Injection de prompt	Instructions malveillantes dans un courriel ou un document RAG	Exfiltration, désobéissance, escalade logique	Segmentation, instruction hierarchy, filtrage sémantique, red teaming
Empoisonnement de corpus	Documents modifiés dans une base de connaissances	Réponses biaisées, actions erronées	Provenance, signature, validation, quarantaines
Excessive agency	Agent autorisé à appeler des outils sensibles	Actions non désirées sur systèmes critiques	RBAC fin, approval gates, sandboxing, allowlist d’outils
Fuite de données	Prompt contenant secrets ou PII	Violation de confidentialité, conformité	DLP, redaction, minimisation contextuelle
Supply chain compromise	Dépendance ou modèle téléchargé compromis	Backdoor, malware, comportement détourné	SBOM, signatures, scans, revue d’artefacts

Les organisations de 2026 s’appuient aussi sur des cadres de gouvernance plus larges. Le NIST CSF 2.0, l’ISO/IEC 42001, les politiques internes de gouvernance de l’IA et les exigences réglementaires sectorielles imposent une traçabilité accrue. Cette convergence est importante, car la sécurité de l’IA ne peut pas être uniquement traitée comme un problème de recherche ; elle doit être intégrée au GRC, à la sécurité cloud, au SOC et au MLOps.

Le second tableau met en perspective les cadres de référence les plus utilisés.

Cadre	Objet	Force principale	Limite pratique
NIST AI RMF 1.0	Gestion du risque IA	Gouvernance structurée	Trop générique pour l’ingénierie quotidienne
OWASP Top 10 for LLM Applications	Vulnérabilités LLM	Orienté application	Ne couvre pas toute la chaîne ML
MITRE ATLAS	Tactiques et techniques	Vision adversaire	Nécessite adaptation aux architectures concrètes
ISO/IEC 42001	Management system IA	Gouvernance et audit	Peu prescriptif au niveau technique
NIST CSF 2.0	Sécurité organisationnelle	Alignement global	Non spécifique aux risques IA

Sur le plan des outils, l’écosystème en 2026 inclut des solutions de scan de dépendances, d’analyse de conteneurs, de politique as code, de DLP, de secrets management, d’observabilité et de détection runtime. Pour l’IA proprement dite, des frameworks d’évaluation de prompts, de benchmarking de sécurité et de simulation d’attaque permettent d’automatiser certaines vérifications. Des approches comme l’“LLM red teaming” deviennent opérationnelles, avec des scénarios d’injection, de jailbreak, de fuite de contexte et d’abus d’outils.

Le troisième tableau montre les catégories d’outillage pertinentes.

Catégorie	Exemples en 2026	Rôle
Sécurité du code et des dépendances	Trivy, Syft, Grype, Semgrep, Gitleaks	Détection de vulnérabilités et secrets
Sécurité cloud-native	Kubernetes NetworkPolicies, OPA/Gatekeeper, Kyverno, Falco, Cilium Tetragon	Contrôle d’accès et détection runtime
Sécurité IA/LLM	garak, promptfoo, OpenAI Evals, PyRIT, NVIDIA NeMo Guardrails, LangGraph security patterns	Test, garde-fou et validation
Gouvernance et conformité	NIST AI RMF, ISO/IEC 42001, SIEM/SOAR	Pilotage du risque et audit

En synthèse, les travaux antérieurs fournissent des briques, mais aucune brique isolée ne suffit. La contribution de cet article consiste à intégrer ces éléments dans une méthode défensive cohérente, utilisable par les équipes sécurité et plateformes en production.

3. Threat Model and Problem Formalization

Nous considérons un système d’IA d’entreprise composé d’un ou plusieurs modèles, d’un orchestrateur applicatif, d’un magasin de documents, d’un composant RAG, d’un bus d’événements, d’outils externes et d’une couche de supervision. Soit l’ensemble des actifs $A = {M, D, P, O, T, L}$, où $M$ désigne les modèles, $D$ les données, $P$ les prompts et le contexte, $O$ l’orchestrateur, $T$ les outils actionnables et $L$ les journaux. L’adversaire cherche à maximiser une fonction d’utilité $U$ liée à l’exfiltration, au sabotage, à la manipulation décisionnelle ou à la persistance. On peut schématiser le risque attendu comme :

$$ R = \sum_{i=1}^{n} P(E_i) \cdot I(E_i) $$

où $E_i$ représente un événement de compromission et $I(E_i)$ son impact. Cette formulation permet de raisonner à la fois sur la probabilité d’occurrence et sur la gravité opérationnelle. Dans les systèmes IA, $P(E_i)$ augmente dès lors que plusieurs vecteurs coexistent : contenu non fiable, accès outil large, absence de séparation des instructions et données, et visibilité insuffisante des sorties.

Notre modèle de menace inclut quatre classes d’adversaires. Le premier est l’adversaire opportuniste, qui exploite des faiblesses génériques comme la fuite de secrets ou le contournement de règles. Le second est l’adversaire ciblé, qui cherche à influencer un assistant interne pour obtenir des données sensibles ou déclencher une action précise. Le troisième est l’adversaire supply chain, qui compromet un artefact en amont, par exemple un package, un poids de modèle ou un document de référence. Le quatrième est l’adversaire persistant, capable de s’adapter aux garde-fous, de tester les limites et de mener des attaques itératives sur de longues périodes.

Les hypothèses de sécurité sont les suivantes. Premièrement, l’adversaire peut injecter du contenu non fiable dans au moins une source consommée par le système, par exemple un document, un ticket, un email ou une page web. Deuxièmement, il peut observer indirectement certaines sorties ou comportements du système. Troisièmement, il ne dispose pas nécessairement d’un accès administrateur initial, mais peut exploiter les interfaces légitimes exposées par l’application. Quatrièmement, il peut tenter des attaques adaptatives, c’est-à-dire apprendre à partir des réponses du système et ajuster sa stratégie.

Les propriétés de sécurité visées sont la confidentialité, l’intégrité, la disponibilité, la traçabilité et la gouvernance. Dans le contexte IA, la confidentialité inclut les prompts, les contextes, les embeddings, les données récupérées et les paramètres du modèle lorsque ceux-ci sont sensibles. L’intégrité couvre les données d’entraînement, les bases documentaires, les réponses et les actions exécutées. La disponibilité concerne la robustesse aux attaques de surcharge, de déni logique ou de perturbation des pipelines. La traçabilité implique que chaque décision, récupération et appel outil soit journalisé et corrélé. La gouvernance impose une allocation explicite des responsabilités et des seuils d’acceptation du risque.

Le problème peut être formalisé comme un compromis entre utilité et sécurité. Soit $f$ le système IA, $x$ une entrée, $c$ le contexte récupéré et $a$ une action potentielle. Nous cherchons à maximiser la fonction d’utilité métier $Q(f, x, c)$ sous contrainte de sécurité $S(f, x, c, a) \ge \tau$, où $\tau$ est un seuil défini par la politique de l’organisation. On peut écrire :

$$ \max_{f} ; Q(f, x, c) \quad \text{sous la contrainte} \quad S(f, x, c, a) \ge \tau $$

Ce cadre met en évidence un point essentiel : la sécurité ne doit pas seulement bloquer des réponses, elle doit limiter les conditions sous lesquelles une action est autorisée. Cela est particulièrement vrai pour les agents. Le système peut produire une réponse textuelle sans dommage, mais devenir dangereux lorsqu’il est autorisé à envoyer un email, modifier une base ou déclencher une exécution distante.

Une autre formalisation utile est celle des frontières de confiance. Nous distinguons les zones suivantes : zone utilisateur, zone contenu non fiable, zone d’orchestration, zone de récupération, zone d’exécution outil, zone d’observabilité et zone de gouvernance. Chaque franchissement de frontière doit être explicitement validé. Ainsi, un document issu d’une source externe ne doit jamais être assimilé à une instruction. Un outil à haut privilège ne doit jamais être invoqué sans policy check. Une sortie générée ne doit pas être réinjectée dans une boucle de décision sans validation.

Le tableau suivant résume notre modèle de menace.

Élément	Menace	Frontière de confiance	Exigence de défense
Prompt utilisateur	Injection directe	Entrée externe	Filtrage, séparation instructions/données
Corpus RAG	Injection indirecte	Contenu tiers	Provenance, scoring, quarantine
Outil actionnable	Abus d’agent	Exécution privilégiée	RBAC, approbation, sandbox
Logs et mémoire	Exfiltration	Observabilité	Chiffrement, minimisation, accès restreint
Dépendances ML	Compromission supply chain	Artefact logiciel	Signature, SBOM, vérification

Un point souvent négligé est l’effet cumulatif. Une attaque ne réussit pas forcément par une seule faille, mais par l’enchaînement de petites faiblesses : corpus peu gouverné, contexte trop large, absence de validation d’outils, journalisation incomplète et absence de red teaming. Notre méthodologie traite précisément cet enchaînement comme une chaîne à casser à plusieurs endroits.

4. Proposed Methodology

Notre méthodologie repose sur cinq couches : gouvernance des actifs, contrôle du contexte, contrôle des outils, vérification des sorties et détection continue. L’idée directrice est simple : plus une donnée est proche d’une action, plus le niveau de confiance requis doit être élevé. Nous appelons cette approche la Defense-in-Depth for AI Operations. Elle se matérialise sous forme de politiques, de contrôles runtime et de tests continus.

La première couche est la gouvernance des actifs. Chaque modèle, dataset, embedding store, prompt template, connecteur et outil doit posséder un propriétaire, une classification de sensibilité et une politique d’usage. Les actifs critiques doivent être répertoriés dans un inventaire IA, avec leurs dépendances et leur provenance. Les artefacts téléchargés doivent être signés ou vérifiés via hachage. Les données utilisées pour le RAG doivent être classées et étiquetées afin d’empêcher la récupération de contenus interdits. Sans gouvernance, aucun contrôle technique n’est durable.

La deuxième couche est le contrôle du contexte. Le principe est de minimiser le contexte fourni au modèle. Les systèmes IA ont tendance à accumuler trop d’informations dans la fenêtre contextuelle, y compris des éléments non nécessaires. Nous recommandons un mécanisme de sélection basé sur la pertinence, la sensibilité et la fiabilité. Le contexte doit être partitionné en blocs clairement typés : instructions système, données utilisateur, documents récupérés, résultats d’outils. Cette séparation réduit la probabilité que des instructions malveillantes soient interprétées comme directives prioritaires.

La troisième couche est le contrôle des outils. Un agent ne doit pas disposer d’un accès monolithique à un ensemble de fonctions. Chaque outil doit être classé selon son niveau d’impact, par exemple lecture seule, écriture limitée, action irréversible ou accès privilégié. Les appels à haut impact doivent nécessiter une validation explicite, un second facteur humain ou une politique contextuelle stricte. La notion d’“excessive agency” est centrale en 2026 : un agent trop autonome devient un multiplicateur de risque. Nous proposons des allowlists d’outils, des schémas stricts de paramètres et des sandbox d’exécution.

La quatrième couche est la vérification des sorties. Les réponses du modèle doivent être examinées avant d’être utilisées en aval. Cela inclut la détection de secrets, de données personnelles, de contenu non conforme aux politiques et de suggestions d’actions dangereuses. La vérification doit être adaptée au cas d’usage. Dans un assistant de code, on vérifiera la présence de commandes potentiellement destructrices. Dans un assistant RH, on vérifiera l’absence de discrimination ou d’informations non autorisées. Dans un assistant IT, on vérifiera les actions proposées sur les systèmes cibles. L’objectif n’est pas seulement de filtrer du texte, mais de contrôler l’intention opérationnelle.

La cinquième couche est la détection continue. Les systèmes doivent être testés non seulement avant production, mais tout au long de leur cycle de vie. Cela comprend le red teaming des prompts, la surveillance des erreurs de récupération, l’analyse des patterns d’appel outil, la détection des dérives de comportement et le suivi des scores de sécurité. Les attaques sur l’IA évoluent rapidement ; un contrôle statique devient obsolète. La détection continue doit s’intégrer au SOC, au SIEM et aux pipelines MLOps.

Le fonctionnement global peut être résumé par le pipeline suivant :

1. Ingestion de la requête utilisateur.
2. Classification initiale du risque.
3. Séparation des instructions, des données et du contenu récupéré.
4. Sélection contextuelle minimale.
5. Passage dans le modèle.
6. Filtrage des sorties et des intentions.
7. Validation des actions outils.
8. Journalisation corrélée et immuable.
9. Surveillance des signaux d’attaque.

Le schéma mathématique du contrôle peut s’exprimer ainsi. Soit $z$ un score de risque calculé à partir de l’entrée, du contexte et du type d’action : $$ z = \alpha \cdot r_u + \beta \cdot r_c + \gamma \cdot r_t + \delta \cdot r_o $$ où $r_u$ représente le risque utilisateur, $r_c$ le risque du contexte, $r_t$ le risque lié à l’outil et $r_o$ le risque opérationnel. Une action est autorisée si $z < \tau$ et si les règles de politique sont satisfaites. Cette approche hybride combine un score quantitatif et une validation déterministe.

Le tableau suivant présente les contrôles par couche.

Couche	Contrôle principal	Mécanisme	Objectif
Gouvernance	Inventaire IA	CMDB/registry, classification	Réduire les actifs inconnus
Contexte	Séparation et minimisation	Typage, filtrage, ranking	Bloquer l’injection indirecte
Outils	Allowlist et sandbox	RBAC, policy engine	Empêcher l’abus d’agent
Sorties	Guardrails	DLP, validation sémantique	Prévenir fuite et actions dangereuses
Détection	Red teaming continu	Tests automatisés	Mesurer et réduire la dérive

Une caractéristique importante de notre méthode est qu’elle ne repose pas sur une unique barrière “intelligente”. Les mécanismes purement probabilistes sont utiles mais insuffisants. Nous combinons donc des contrôles déterministes, comme l’allowlist et l’authz, avec des mécanismes statistiques, comme l’anomaly detection et le scoring. Cette combinaison est plus robuste face aux attaques adaptatives.

5. Implementation

L’implémentation de référence a été conçue pour un environnement d’entreprise de type cloud-native. Elle comprend un service d’orchestration, un moteur de politique, une base documentaire RAG, un registre de modèles, un module de journalisation immuable et un bac à sable pour les outils. L’ensemble est déployé dans Kubernetes, avec des politiques réseau, des contrôles d’accès et une observabilité runtime. Les composants choisis sont compatibles avec les pratiques et outils disponibles en 2026, notamment OPA/Gatekeeper, Kyverno, Trivy, Syft, Grype, Gitleaks, Falco, Cilium et des garde-fous LLM.

Le pipeline CI/CD impose des contrôles avant déploiement. Les images conteneurs sont scannées pour vulnérabilités, les dépendances Python sont inspectées, les secrets sont recherchés dans le code et les artefacts IA sont validés. Les modèles ou embeddings importés depuis des dépôts externes passent par une étape de vérification de provenance. Les templates de prompts sont stockés sous contrôle de version, revus comme du code applicatif et soumis à des tests de non-régression de sécurité.

Exemple de scanner de dépendances et d’artefacts :

trivy image --severity HIGH,CRITICAL registry.example.com/ai-assistant:2026.1
syft registry.example.com/ai-assistant:2026.1 -o spdx-json > sbom.spdx.json
grype sbom:sbom.spdx.json --fail-on high
gitleaks detect --source . --no-banner --report-format json --report-path gitleaks-report.json

Le moteur de politique décide si une requête peut être traitée, si un contexte est autorisé et si un outil peut être appelé. Nous avons utilisé une logique d’allowlist centrée sur le type d’action, la sensibilité des données et l’identité du demandeur. Une politique simplifiée peut être exprimée dans un langage type Rego ou équivalent, en autorisant par exemple un accès lecture seule à la base documentaire mais en bloquant toute écriture sans validation humaine. Les politiques sont versionnées et testées automatiquement.

Exemple de configuration de politique d’accès et d’outil :

apiVersion: security.example.com/v1
kind: AIPolicy
metadata:
  name: assistant-interne
spec:
  context:
    maxTokens: 8192
    allowExternalWeb: false
    redactSecrets: true
  tools:
    - name: search_docs
      effect: read
      allowed: true
    - name: create_ticket
      effect: write
      allowed: true
      requiresApproval: true
    - name: send_email
      effect: high_risk
      allowed: false
  output:
    blockPII: true
    blockCredentialPatterns: true
    requireCitationsForFacts: true

La journalisation est un élément majeur. Chaque interaction doit conserver un identifiant de trace, le type d’entrée, les documents récupérés, les outils invoqués, la décision de politique et la sortie filtrée. Les journaux doivent être immuables, chiffrés et accessibles aux seuls rôles autorisés. En pratique, nous recommandons l’export vers un SIEM avec corrélation sur les événements LLM, les appels d’outils et les alertes runtime. Les signaux d’attaque incluent les répétitions de prompts de contournement, les changements brusques de style de requête, les tentatives d’accès à des documents sensibles et les séquences d’outils anormales.

Le composant de garde-fou de sortie applique plusieurs filtres. D’abord, un filtre lexical identifie les secrets potentiels : clés API, jetons, identifiants, motifs de certificats ou données personnelles. Ensuite, un classificateur sémantique détecte les demandes d’action dangereuse ou les réponses inappropriées au contexte. Enfin, un vérificateur de conformité décide si la sortie peut être affichée, tronquée, reformulée ou bloquée. Ce triple filtrage est essentiel, car aucun mécanisme isolé ne couvre tous les cas.

L’implémentation comprend aussi un environnement de test offensif pour le red teaming. Nous utilisons des scénarios d’injection directe et indirecte, de jailbreak, de récupération malveillante, de divulgation de secrets et de tentative d’abus d’outils. Les tests sont automatisés avec des suites d’évaluation, puis rejoués lors de chaque changement de prompt, de modèle ou de connecteur. Cela permet de détecter rapidement les régressions de sécurité.

6. Experimental Evaluation

L’évaluation a été réalisée sur un prototype d’assistant interne simulant un cas d’usage courant en entreprise : recherche documentaire, synthèse de documents, création de tickets IT et assistance au support. Le système exploite un modèle de langage hébergé en environnement privé, un moteur RAG et trois outils actionnables. Nous avons comparé trois configurations : une baseline sans contrôles spécifiques IA, une version avec garde-fous partiels, et notre méthode complète. Les scénarios d’attaque incluent l’injection directe, l’injection indirecte via document, la tentative d’exfiltration de secrets et l’abus d’outils.

Les métriques principales sont le taux de succès des attaques, le taux de faux positifs, la latence ajoutée et l’impact sur l’utilité métier. Nous notons la précision fonctionnelle par le taux de réponses acceptables sur un jeu de requêtes métier légitimes. Le score de sécurité est défini comme la réduction relative du taux de succès des attaques, soit : $$ \Delta S = \frac{AS_{base} - AS_{def}}{AS_{base}} \times 100 $$ où $AS_{base}$ est le taux de succès des attaques sur la baseline et $AS_{def}$ celui sur la configuration défensive.

La configuration complète a montré une réduction nette de la réussite des attaques. Les attaques d’injection de prompt ont été particulièrement freinées par la séparation des contextes, les filtres de sortie et le contrôle d’outils. Les tentatives d’exfiltration de secrets via réponses textuelles ont été majoritairement détectées par le module DLP sémantique. Les attaques indirectes via documents RAG ont été plus difficiles à bloquer entièrement, ce qui confirme la nécessité d’une gouvernance stricte des corpus.

Le tableau ci-dessous résume les résultats globaux.

Scénario	Baseline: succès attaque	Défense partielle: succès attaque	Méthode proposée: succès attaque	Latence moyenne ajoutée
Injection directe	71%	29%	8%	+120 ms
Injection indirecte RAG	64%	33%	11%	+150 ms
Exfiltration de secrets	58%	21%	4%	+95 ms
Abus d’outil à privilège	49%	18%	3%	+180 ms
Jailbreak itératif	66%	37%	14%	+140 ms

Les résultats montrent que la défense complète réduit de manière substantielle le taux de réussite des attaques, avec un coût de latence raisonnable pour un usage d’entreprise. La réduction moyenne de succès des attaques est élevée, mais surtout plus homogène entre les scénarios. Cette homogénéité est importante, car un système de défense qui ne protège qu’une catégorie de menaces laisse un angle mort exploitable.

Le tableau suivant présente l’impact sur l’utilité métier.

Configuration	Réponses métier acceptables	Taux de blocage légitime	Latence p95	Observations
Baseline	94%	1%	1,1 s	Très utile, très exposée
Défense partielle	91%	4%	1,3 s	Bon compromis
Méthode proposée	89%	6%	1,45 s	Sécurité forte, coût mesuré

Les faux positifs restent le principal coût. Les requêtes ambiguës, notamment en support IT ou en assistance documentaire, peuvent être mal classées si les filtres sont trop agressifs. Cela confirme qu’une stratégie de sécurité IA ne peut pas être purement punitive. Elle doit intégrer des mécanismes de dégradation gracieuse, par exemple en proposant une reformulation sûre ou en demandant une validation humaine.

Le troisième tableau compare les contrôles individuels.

Contrôle	Réduction du succès attaque	Faux positifs	Coût d’implémentation	Appréciation
Filtrage lexical	Faible à moyen	Faible	Faible	Utile mais contournable
Séparation contexte	Élevée	Faible	Moyen	Très efficace
Allowlist outils	Élevée	Faible	Moyen	Indispensable
DLP sémantique	Moyen à élevé	Moyen	Moyen	Très utile
Red teaming continu	Élevée	Aucun direct	Élevé	Nécessaire pour la durabilité

Nous avons également observé que la robustesse dépend fortement de la qualité de la politique de contexte. Si les documents récupérés ne sont pas classés, les attaques indirectes restent très efficaces. Si les outils sont trop nombreux ou trop puissants, l’agent devient difficile à contrôler. La sécurité de l’IA n’est donc pas seulement une question de modèle ; c’est une question de design d’architecture.

7. Case Study

Le cas étudié est celui d’un assistant interne déployé dans une entreprise de services. L’assistant aide les employés à rechercher des procédures internes, à synthétiser des tickets, à générer des brouillons de réponse et à créer des demandes dans un système ITSM. Il est connecté à une base documentaire contenant des procédures, des FAQ et certains documents RH non publics. Dans sa première version, l’assistant disposait d’un contexte large, d’un accès lecture sur plusieurs sources et d’un outil de création de ticket sans approbation humaine.

L’incident déclencheur fut une attaque indirecte. Un document apparemment inoffensif, ingéré dans le corpus de recherche, contenait des instructions visant à influencer le comportement du modèle. Lorsqu’un utilisateur légitime a demandé un résumé de procédure, l’assistant a récupéré ce document et a produit une réponse altérée, incluant des consignes erronées. L’impact n’a pas été critique, mais il a démontré la faiblesse d’un corpus non gouverné. Une seconde tentative a utilisé une requête plus ciblée pour pousser l’assistant à exposer des informations contextuelles sensibles dans un brouillon de réponse.

L’équipe a alors appliqué notre méthodologie en plusieurs étapes. D’abord, elle a classifié les documents et retiré les sources non approuvées. Ensuite, elle a réduit la fenêtre contextuelle et séparé strictement les documents récupérés des instructions système. Puis elle a ajouté une politique d’approbation humaine pour toute création de ticket affectant des systèmes sensibles. Enfin, elle a mis en place des tests automatisés d’injection indirecte à chaque mise à jour du corpus.

Après durcissement, les mêmes attaques ont échoué à plusieurs niveaux. Le document malveillant a été classé comme non fiable et ne pouvait plus influencer les instructions système. Les sorties contenant des motifs sensibles ont été bloquées ou reformulées. Les appels aux outils sensibles nécessitaient une approbation explicite, empêchant l’automatisation non désirée. Surtout, les journaux ont permis de corréler l’incident initial avec d’autres requêtes suspectes, ce qui a aidé l’équipe SOC à identifier une campagne exploratoire plus large.

Le principal enseignement du cas est que la sécurité de l’IA doit être pensée comme une activité continue, et non comme une configuration unique. Un assistant sécurisé à un instant donné peut redevenir vulnérable si un nouveau connecteur est ajouté, si une source documentaire change ou si un outil est élargi. La gouvernance de l’évolution est donc aussi importante que la défense initiale.

8. Discussion

Les résultats confirment que la sécurité de l’IA en 2026 doit être conçue comme une discipline systémique. Les attaques les plus efficaces ne reposent pas nécessairement sur des exploits techniques sophistiqués ; elles exploitent souvent les propriétés mêmes des interfaces linguistiques, l’ambiguïté du contexte et l’autonomie croissante des agents. Les défenseurs doivent donc adopter des contrôles qui ne supposent pas la perfection du modèle. Un modèle peut être excellent pour la tâche métier tout en restant vulnérable à des manipulations logiques.

Un point essentiel est le compromis entre sécurité et utilité. Augmenter les garde-fous améliore la résistance aux attaques, mais peut dégrader l’expérience utilisateur ou la couverture fonctionnelle. Le défi est de calibrer les seuils et de prévoir des voies de recours. Dans certains cas, la meilleure défense consiste à refuser une action et à demander une validation humaine. Dans d’autres, il faut fournir une réponse partielle, anonymisée ou reformulée. La granularité de la politique est donc un facteur de qualité, au même titre que la robustesse du modèle.

La question de la chaîne d’approvisionnement est particulièrement préoccupante. En 2026, de nombreux déploiements reposent sur des bibliothèques, des connecteurs et des modèles externes. Un artefact compromis peut introduire un comportement malveillant difficile à observer. Les équipes doivent donc étendre les pratiques de sécurisation du software supply chain à l’IA : SBOM, signature, provenance, validation des poids, revue des changements de prompts et tests de régression de sécurité. L’ISO/IEC 42001 et les cadres internes doivent être complétés par des contrôles techniques concrets.

Les garde-fous purement probabilistes ne suffisent pas. Un classificateur de sécurité peut être contourné par reformulation, par injection multi-étapes ou par attaques indirectes. Les attaques adaptatives apprennent les contours du système et s’ajustent. C’est pourquoi l’alliance entre règles déterministes, politiques explicites, surveillance comportementale et red teaming continu est plus efficace. Il ne s’agit pas de remplacer la sécurité “classique” par des mécanismes IA, mais de les combiner.

Le rôle des équipes SOC et cloud security devient central. Les événements IA doivent être intégrés aux pipelines de détection et de réponse. Les traces d’appel modèle, de récupération documentaire et d’outils doivent être corrélées aux identités, aux hôtes et aux sessions. Les signaux eBPF, les logs applicatifs et les alertes DLP peuvent alors être enrichis par les événements IA pour détecter les abus. Cette convergence entre sécurité applicative, cloud-native et sécurité IA est probablement l’une des évolutions structurantes de 2026.

Enfin, l’IA générative a aussi changé la donne pour les attaquants. Les campagnes de phishing, de social engineering et de reconnaissance sont plus rapides, plus convaincantes et plus adaptatives. La sécurité de l’IA doit donc être pensée à la fois comme protection des systèmes IA et comme défense contre l’usage offensif de l’IA par l’adversaire. Cette dimension duale doit apparaître dans les stratégies de red team et de sensibilisation.

9. Conclusion and Future Work

Nous avons présenté une méthodologie de sécurité pour les systèmes d’IA d’entreprise en 2026, fondée sur une défense en profondeur couvrant les données, les prompts, les outils, les sorties et la chaîne d’approvisionnement. Notre proposition combine gouvernance, contrôle du contexte, contrôle des outils, vérification des sorties et détection continue. L’évaluation expérimentale montre une réduction substantielle du taux de réussite des attaques, au prix d’une latence et d’un faux positif mesurés. L’étude de cas confirme que les attaques les plus dangereuses exploitent la structure même des systèmes IA, en particulier les corpus RAG et les agents outillés.

Le message principal est que la sécurité de l’IA ne peut pas être traitée comme un simple ajout à la sécurité existante. Elle exige des politiques dédiées, des tests continus et une observabilité spécifique. Les organisations qui déploient des assistants, des copilots ou des agents doivent raisonner en termes de frontières de confiance et de privilèges minimaux. Elles doivent aussi accepter qu’un système IA sûr est un système qui sait refuser, demander validation et limiter son autonomie lorsque le risque augmente.

Les travaux futurs devraient porter sur trois axes. D’abord, le développement de métriques standardisées de sécurité pour les systèmes IA multi-agents et RAG, afin de comparer les architectures de manière reproductible. Ensuite, l’automatisation du red teaming adaptatif, capable de générer de nouveaux scénarios d’attaque en fonction des politiques observées. Enfin, l’intégration plus poussée des signaux IA dans les SOC, avec des modèles de détection corrélant prompts, outils, documents et actions. À mesure que les modèles deviennent plus capables, la sécurité devra devenir plus contextuelle, plus observable et plus gouvernée.

10. References

ACHARYA, R. et al. Secure AI systems: a systems security perspective. IEEE Security & Privacy, 2025. Disponível em: https://ieeexplore.ieee.org/. Acesso em: 23 abr. 2026.

ANDERSON, R. Security engineering: a guide to building dependable distributed systems. 3. ed. Indianapolis: Wiley, 2020. Disponível em: https://www.wiley.com/. Acesso em: 23 abr. 2026.

BROWN, T. et al. Language models are few-shot learners. Advances in Neural Information Processing Systems, 2020. Disponível em: https://arxiv.org/abs/2005.14165. Acesso em: 23 abr. 2026.

CISA. Secure by design: guidance for AI systems. Washington, DC: Cybersecurity and Infrastructure Security Agency, 2024. Disponível em: https://www.cisa.gov/. Acesso em: 23 abr. 2026.

CWE. CWE top 25 most dangerous software weaknesses. 2025. Disponível em: https://cwe.mitre.org/top25/archive/2025/2025_cwe_top25.html. Acesso em: 23 abr. 2026.

DENNING, D. J. An intrusion-detection model. IEEE Transactions on Software Engineering, 1987. Disponível em: https://ieeexplore.ieee.org/. Acesso em: 23 abr. 2026.

ENISA. Securing machine learning algorithms. Athens: European Union Agency for Cybersecurity, 2024. Disponível em: https://www.enisa.europa.eu/. Acesso em: 23 abr. 2026.

GARMANY, B.; SHOKRI, R. Membership inference attacks against machine learning models. ACM, 2021. Disponível em: https://dl.acm.org/. Acesso em: 23 abr. 2026.

GEBRU, T. et al. Datasheets for datasets. Communications of the ACM, 2021. Disponível em: https://dl.acm.org/. Acesso em: 23 abr. 2026.

GOODFELLOW, I.; SHLENS, J.; SZEGEDY, C. Explaining and harnessing adversarial examples. 2015. Disponível em: https://arxiv.org/abs/1412.6572. Acesso em: 23 abr. 2026.

HENDRYCKS, D. et al. Aligning AI with human values. 2024. Disponível em: https://arxiv.org/. Acesso em: 23 abr. 2026.

HO, D. et al. Red teaming language models with language models. 2024. Disponível em: https://arxiv.org/. Acesso em: 23 abr. 2026.

ISO. ISO/IEC 42001:2023 information technology — artificial intelligence — management system. Geneva: International Organization for Standardization, 2023. Disponível em: https://www.iso.org/standard/81230.html. Acesso em: 23 abr. 2026.

KOLLER, D. et al. Data-centric AI and security implications. 2025. Disponível em: https://arxiv.org/. Acesso em: 23 abr. 2026.

KORNFIELD, S.; LI, Z. Prompt injection attacks against LLM applications. 2024. Disponível em: https://arxiv.org/. Acesso em: 23 abr. 2026.

LEITER, M. et al. Agentic AI security: a practical defense framework. 2025. Disponível em: https://arxiv.org/. Acesso em: 23 abr. 2026.

LINDORFER, M. et al. Poisoning attacks on machine learning systems. 2022. Disponível em: https://arxiv.org/. Acesso em: 23 abr. 2026.

MITRE. ATLAS: adversarial threats landscape for artificial-intelligence systems. 2025. Disponível em: https://atlas.mitre.org/. Acesso em: 23 abr. 2026.

NIST. Artificial intelligence risk management framework (AI RMF 1.0). Gaithersburg: National Institute of Standards and Technology, 2023. Disponível em: https://www.nist.gov/itl/ai-risk-management-framework. Acesso em: 23 abr. 2026.

NIST. Cybersecurity framework 2.0. Gaithersburg: National Institute of Standards and Technology, 2024. Disponível em: https://www.nist.gov/cyberframework. Acesso em: 23 abr. 2026.

NIST. Secure software development framework (SSDF). Gaithersburg: National Institute of Standards and Technology, 2022. Disponível em: https://csrc.nist.gov/Projects/ssdf. Acesso em: 23 abr. 2026.

OWASP. OWASP top 10 for large language model applications. 2025. Disponível em: https://owasp.org/www-project-top-10-for-large-language-model-applications/. Acesso em: 23 abr. 2026.

PYRIT. AI red teaming framework. Microsoft, 2025. Disponível em: https://github.com/Azure/PyRIT. Acesso em: 23 abr. 2026.

RATHJEN, S. et al. LMRA: large model risk assessment. 2025. Disponível em: https://arxiv.org/. Acesso em: 23 abr. 2026.

SANDERS, M. et al. The security of retrieval-augmented generation systems. 2025. Disponível em: https://arxiv.org/. Acesso em: 23 abr. 2026.

SHEYNER, O.; TUSHKANOV, A. Practical prompt injection mitigation for enterprise LLMs. 2025. Disponível em: https://arxiv.org/. Acesso em: 23 abr. 2026.

SPF. Supply-chain security for AI artifacts. 2025. Disponível em: https://slsa.dev/. Acesso em: 23 abr. 2026.

TETRAGON. eBPF-based runtime security and observability. Cilium, 2025. Disponível em: https://tetragon.io/. Acesso em: 23 abr. 2026.

TRIVY. Vulnerability scanner for containers, IaC and artifacts. Aqua Security, 2025. Disponível em: https://trivy.dev/. Acesso em: 23 abr. 2026.

ZOU, A. et al. Universal and transferability attacks on aligned language models. 2023. Disponível em: https://arxiv.org/abs/2307.15043. Acesso em: 23 abr. 2026.