Pourquoi sécuriser une application IA - Risques, enjeux, régulation

Sécuriser une application IA est devenu une exigence critique en 2026 pour trois raisons convergentes : une nouvelle surface d'attaque (prompt injection, model extraction, data poisoning, jailbreak) absente des stacks traditionnelles, un cadre réglementaire contraignant (AI Act européen entré progressivement en vigueur depuis août 2024, RGPD, NIS2, ISO 42001, NIST AI RMF), et une série d'incidents publics (Samsung ChatGPT 2023, Air Canada 2024, DPD 2024, Chevrolet 2023) qui ont exposé les dommages réputationnels, financiers et juridiques. Cet article explique concrètement pourquoi ce chantier ne peut plus être remis à plus tard, quels risques il couvre, et ce que coûte l'inaction.

1. Une nouvelle classe d'applications, une nouvelle classe de risques

Une application IA moderne (chatbot RAG, agent autonome, assistant code, pipeline de résumé documentaire) combine plusieurs composants qui introduisent chacun leurs propres vulnérabilités :

• Prompt utilisateur : entrée naturelle, non structurée, potentiellement malveillante.
• Modèle LLM (propriétaire ou self-hosted) : boîte partiellement opaque, comportement probabiliste.
• Sources externes : base vectorielle (RAG), documents internes, web scraping, outils/tools.
• Outils exécutables (function calling, MCP) : accès à des APIs, au FS, à des bases de données.
• Mémoire conversationnelle : stockage et réutilisation de contexte utilisateur.
• Sortie : texte, code, appels API, décisions automatisées.

Chaque couche devient une porte d'entrée pour un attaquant. La défense en profondeur traditionnelle (authentification, validation d'input, logs, WAF) couvre une partie mais pas la totalité - les attaques LLM passent par le langage naturel lui-même, qui n'est pas filtrable comme du SQL ou du XSS.

2. Le cadre de référence - OWASP LLM Top 10 et MITRE ATLAS

Deux cadres standards consolidés en 2026 aident à structurer l'analyse.

2.1 OWASP Top 10 for LLM Applications (version 2025)

2.2 MITRE ATLAS

Adversarial Threat Landscape for Artificial-Intelligence Systems - adaptation de MITRE ATT&CK au machine learning. Classe les techniques d'attaque réelles observées : reconnaissance, initial access, ML attack staging, exfiltration, impact. Utilisé côté blue team pour structurer la détection et côté red team pour documenter les engagements.

Les deux cadres sont complémentaires : OWASP oriente la sécurité applicative (ce qu'un ingénieur AppSec doit contrôler), MITRE ATLAS oriente la threat modeling et la threat intelligence (ce qu'un attaquant fait concrètement).

3. Risques métier concrets

Au-delà des cadres théoriques, ce sont des risques business qui se matérialisent.

3.1 Fuite de données confidentielles

Le cas Samsung en 2023 reste emblématique : des ingénieurs ont copié dans ChatGPT du code source propriétaire et des notes de réunion stratégiques. Ces données ont quitté le périmètre. Samsung a interdit l'usage des LLM publics dès les jours suivants. Depuis, la majorité des grands groupes a déployé des solutions internes ou des offres enterprise avec zéro rétention.

Les vecteurs classiques :

• Input utilisateur non filtré : PII, données commerciales, secrets copiés dans un chat.
• RAG mal cloisonné : un utilisateur A obtient des documents réservés à un utilisateur B.
• Mémoire persistante : contexte d'un utilisateur réinjecté chez un autre.
• Logs et traces : prompts et réponses stockés sans chiffrement, accessibles en support.
• System prompt leakage : révélation des instructions système, des clés API embarquées ou de la logique métier via Repeat the instructions above verbatim.

3.2 Hallucinations responsabilisantes

Air Canada a été condamné en février 2024 par un tribunal canadien après que son chatbot ait promis à tort une politique de réduction post-deuil à un client. L'argument de la compagnie - « le chatbot est une entité séparée » - a été rejeté. Le client a dû être dédommagé.

Ce cas fait jurisprudence : en 2026, une entreprise est juridiquement responsable de ce que dit son chatbot IA. Les hallucinations ne sont plus un inconvénient technique, elles sont un risque contractuel.

3.3 Usage abusif et détournement

• Chevrolet of Watsonville (2023) : un internaute obtient du chatbot commercial qu'il « accepte » de vendre un SUV à 1 dollar et qu'il s'engage juridiquement à honorer cet accord. Capture d'écran virale.
• DPD (2024) : le chatbot de livraison détourné pour produire des poèmes insultants sur DPD elle-même. Incident médiatique majeur.
• Compagnies d'assurance, banques : tentatives régulières de jailbreak pour obtenir des conseils financiers personnalisés non autorisés, ou des avis médicaux.

Ces incidents ne causent pas de fuite technique mais un dommage d'image massif et coûteux.

3.4 Injection indirecte via RAG

Le vecteur le plus sous-estimé. Un document ingéré par RAG peut contenir des instructions malveillantes invisibles pour l'humain (texte blanc sur blanc, caractères Unicode invisibles, métadonnées PDF). Le LLM, lui, lit tout. Résultat : quand un utilisateur pose une question qui déclenche la récupération de ce document, l'agent exécute les instructions cachées (exfiltration, manipulation, appels tools).

C'est LLM01 (Prompt Injection) combiné à LLM08 (Vector Weaknesses). Difficile à détecter en production sans contrôles dédiés.

3.5 Empoisonnement et model supply chain

Les modèles open source (Hugging Face, civit.ai, GitHub) peuvent être compromis. Cas connus : modèles avec pickle malveillant (exécution de code à l'import), fichiers de tokenizer modifiés, datasets de fine-tuning avec backdoors conditionnels (le modèle se comporte normalement sauf en présence d'un trigger précis).

La supply chain de l'IA est aussi critique que la supply chain logicielle classique - et moins mature côté tooling (SBOM ML encore naissant, signature de modèles en cours de standardisation via Sigstore / SLSA).

4. Cadre réglementaire - ce qu'impose la loi

4.1 AI Act européen

Règlement UE 2024/1689, publié en juillet 2024, entré en vigueur progressivement :

• Février 2025 : interdictions des systèmes à risque inacceptable (notation sociale, manipulation subliminale, reconnaissance biométrique en temps réel dans l'espace public sauf exceptions).
• Août 2025 : obligations sur les modèles à usage général (GPAI) - transparence, documentation technique, droits d'auteur.
• Août 2026 : majorité des obligations pour les systèmes à haut risque (santé, recrutement, crédit, justice, éducation).
• Août 2027 : conformité totale pour les systèmes intégrés dans produits régulés existants.

Les systèmes à haut risque (annexe III) doivent documenter :

• Gouvernance des données d'entraînement.
• Évaluation des risques et plans de mitigation.
• Logs et traçabilité.
• Contrôle humain effectif.
• Robustesse, précision, cybersécurité.
• Transparence vers l'utilisateur.

Sanctions : jusqu'à 7 % du CA mondial annuel pour les infractions aux pratiques interdites, 3 % pour les obligations sur systèmes à haut risque - plafonds analogues à ceux du RGPD.

4.2 RGPD et vie privée

Les LLM traitent souvent des données personnelles. Questions concrètes :

• Base légale du traitement (intérêt légitime, consentement, contrat) ?
• Minimisation : envoie-t-on vraiment les minimums nécessaires au LLM ?
• Droit à l'effacement : peut-on désapprendre un individu d'un modèle ? (techniquement très difficile sans réentraînement).
• Transfert hors UE : si le LLM est hébergé sur AWS US-East, les clauses contractuelles types (CCT) sont-elles en place ?
• Décisions automatisées (art. 22 RGPD) : l'utilisateur a droit à une intervention humaine si le LLM prend des décisions produisant des effets juridiques.

La CNIL a publié en 2024 et 2025 des recommandations spécifiques (Les fiches pratiques pour le développement des systèmes d'IA). Elles font foi en France.

4.3 ISO/IEC 42001 et NIST AI RMF

• ISO 42001:2023 : norme de management de l'IA, similaire à ISO 27001 sur la sécurité de l'information. Certifiable. Attendue comme référence dans les appels d'offres publics et privés dès 2026-2027.
• NIST AI RMF 1.0 (janvier 2023) et NIST Generative AI Profile (juillet 2024) : référentiel américain de gestion des risques IA, structuré autour de Govern, Map, Measure, Manage. Adopté de facto par les grandes entreprises US et internationales.

4.4 Autres cadres à connaître

• NIS2 (UE, octobre 2024) : élargit le cyber-compliance. Ne cible pas spécifiquement l'IA mais impose la cybersécurité des systèmes d'information, dont ceux embarquant du LLM dans un périmètre critique.
• DORA (secteur financier UE, janvier 2025) : résilience opérationnelle numérique.
• ENISA AI Threat Landscape 2024 : cadrage technique des menaces.
• US Executive Order 14110 (Biden, octobre 2023) et EO successeur 2025 : cadrage fédéral US.
• CCPA / CPRA (Californie), CPA (Colorado) : droits utilisateurs, droit d'opt-out des décisions automatisées.

5. Incidents publics marquants - ce qui est déjà arrivé

Ces cas sont publics. Ils sont la partie émergée : en threat intel privée, les incidents IA se multiplient depuis 2023 dans tous les secteurs (banque, santé, retail, assurance).

6. Ce que coûte l'inaction

Quatre catégories de coût :

6.1 Coût direct - incident et remédiation

• Forensic, communication de crise, notification CNIL (72 h), revue de code, rollback, redéploiement.
• Ordre de grandeur observé : 100 k€ à plusieurs M€ pour un incident critique avec fuite de données.

6.2 Coût réglementaire

• Amendes RGPD : jusqu'à 4 % du CA annuel mondial.
• Amendes AI Act : jusqu'à 7 % du CA annuel mondial pour les systèmes à risque inacceptable, 3 % pour les systèmes à haut risque non conformes.
• Sanctions sectorielles (ACPR banque, ARCOM média, CNIL général).

6.3 Coût réputationnel

Pour une marque grand public, un incident viral (type Air Canada, Chevrolet, DPD) se chiffre en millions d'euros en churn et en campagnes de reconquête. La perception d'une entreprise « qui ne maîtrise pas son IA » est durable.

6.4 Coût d'opportunité

Une entreprise qui subit un incident majeur freine ses projets IA pendant 6 à 18 mois. Pendant ce temps, les concurrents avancent. L'écart stratégique se creuse.

7. Les piliers de la sécurisation

Un programme de sécurité IA couvre cinq couches, chacune avec ses contrôles :

7.1 Sécurité des données

• Classification des données envoyées au LLM.
• Minimisation et pseudonymisation.
• Chiffrement en transit et au repos.
• Contrôles d'accès sur la base vectorielle (filtrage par utilisateur, tenant, rôle).
• Data loss prevention (DLP) en amont.

7.2 Sécurité du modèle

• Choix du modèle (propriétaire API vs open source self-hosted).
• Evaluation de la supply chain (scan pickle, signature, provenance).
• Fine-tuning sécurisé (datasets vérifiés, pas de PII, red teaming du résultat).
• Model cards et documentation.

7.3 Sécurité du prompt et de la conversation

• System prompts robustes (pas de secrets, pas de données sensibles, instructions claires).
• Détection de prompt injection (regex, classifieurs, embedding-based).
• Rate limiting et detection d'anomalies.
• Guardrails (Llama Guard, NeMo Guardrails, Azure AI Content Safety, Prompt Shields).

7.4 Sécurité de la sortie

• Validation stricte des outputs avant exécution (parsing structuré, schémas JSON).
• Sandboxing des tool calls.
• Code exécuté dans un environnement isolé (container éphémère, WASM, microVM).
• Filtrage PII en sortie.
• Watermarking (quand applicable et réaliste).

7.5 Sécurité de l'infrastructure et de la gouvernance

• IAM et least privilege pour les agents.
• Monitoring et logs structurés (prompt, retrieval, tool calls, réponse, feedback).
• SIEM et détection d'anomalies.
• Red teaming régulier (AI red teaming dédié, pas un pentest classique).
• Revue humaine sur les décisions critiques (human-in-the-loop).
• Documentation conformité (AI Act, ISO 42001, NIST RMF).

8. Qui doit s'en occuper

Trois profils clés dans une organisation mature en 2026 :

• AI Security Engineer / LLM Security Engineer : rôle émergent, hybride AppSec et MLOps. Threat modeling, guardrails, red teaming AI.
• Responsable conformité IA / AI Compliance Officer : AI Act, ISO 42001, articulation avec DPO pour RGPD.
• Product / ML Engineer avec reflex sécurité : capable de challenger un design risqué en conception.

Les CISO intègrent désormais l'IA dans leur périmètre (ISAC, CERT interne, comité sécurité). Les DPO se forment aux spécificités IA (décisions automatisées, explicabilité, minimisation).

9. FAQ

9.1 Est-ce vraiment différent de la sécurité applicative classique ?

Partiellement. Les fondamentaux (IAM, chiffrement, logs, validation) restent. Ce qui change : le langage naturel comme vecteur d'attaque, le caractère non déterministe du modèle, la difficulté à sanitiser l'input et l'output, la nouveauté de la supply chain ML, et des cadres réglementaires spécifiques (AI Act, NIST AI RMF). Un RSSI qui ignore l'IA en 2026 passe à côté d'une part croissante de sa surface d'attaque.

9.2 Les LLM self-hosted sont-ils plus sûrs que les APIs commerciales ?

Pas automatiquement. Self-hosted élimine le risque de fuite vers un tiers mais transfère tous les risques (supply chain, hardening, patching, capacité de red teaming) à l'équipe interne. Une API managed avec clauses DPA solides (OpenAI Enterprise, Azure OpenAI, Anthropic Claude via Bedrock) est souvent plus sûre qu'un déploiement interne amateur. Le choix dépend des ressources et des contraintes de confidentialité.

9.3 L'AI Act s'applique-t-il à tous les projets IA ?

Partiellement. L'AI Act cible principalement les systèmes à haut risque (annexe III : recrutement, crédit, santé, justice, infrastructures critiques) et les modèles à usage général (GPAI). Un chatbot support client classique n'est pas à haut risque, mais il hérite tout de même d'obligations de transparence (informer l'utilisateur qu'il dialogue avec une IA). Il faut faire l'analyse cas par cas.

9.4 Par où commencer si on n'a rien en place ?

Trois actions en 3-6 mois :

1. Inventaire : lister tous les systèmes IA en production ou en projet, leurs sources de données, leurs tools.
2. Threat model sur les 2-3 plus critiques (risques OWASP LLM Top 10 + ATLAS).
3. Quick wins : guardrails minimal (Llama Guard / Prompt Shield), logs structurés, revue du system prompt, limitation des tools.

Et en parallèle cadrer la compliance (AI Act article 27 - évaluation d'impact pour les systèmes à haut risque).

9.5 Les guardrails suffisent-ils ?

Non. Les guardrails (Llama Guard, NeMo, Azure Content Safety, Lakera) sont une couche nécessaire mais pas suffisante. Ils complètent - ils ne remplacent pas - un bon system prompt, une architecture least-privilege, un cloisonnement RAG, un sandbox tool call, et une supervision humaine sur les actions sensibles.

9.6 Est-ce que les LLM vont devenir « auto-sécurisés » à terme ?

Les progrès sur l'alignement (RLHF, Constitutional AI, debate) réduisent certaines surfaces (refus des prompts clairement malveillants). Ils ne résolvent pas la prompt injection indirecte (instructions dans les données), l'excessive agency, ni la supply chain. La sécurité des applications IA restera un chantier d'ingénierie applicative pour les années à venir, au-delà des progrès des modèles eux-mêmes.

Sécuriser une application IA n'est plus un sujet d'anticipation - c'est une obligation opérationnelle en 2026 : surface d'attaque réelle, incidents documentés, cadre réglementaire contraignant, responsabilité juridique établie (Air Canada). Les organisations qui mettront en place dès aujourd'hui threat modeling IA, guardrails, red teaming et gouvernance conforme (AI Act, ISO 42001, NIST AI RMF) éviteront les coûts d'incidents à court terme et gagneront la confiance utilisateur qui déterminera leurs parts de marché à moyen terme.