Table des matières :
- Pourquoi l’IA change la donne en sécurité applicative
- Nouvelles surfaces d’attaque : prompt injection, model leakage & co
- Détection et réponse en temps réel : la chasse augmentée par le deep learning
- MLSecOps : sécuriser le pipeline d’entraînement à la production
- Confidential Computing & chiffrement homomorphe : protéger données et modèles
- Conformité & gouvernance : AI Act, RGPD, DSA
- Conclusion opérationnelle : trois chantiers pour 2025
Pourquoi l’IA change la donne en sécurité applicative
L’intelligence artificielle (IA) n’est plus un gadget marketing glissé dans le pitch ; elle est devenue un composant à part entière de l’architecture logicielle moderne. Qu’il s’agisse d’un moteur de recommandation sous TensorFlow, d’un chatbot propulsé par GPT-4 ou d’un simple classifieur de fraude écrit en scikit-learn, le code de nos applications web consomme désormais des modèles. Cette évolution modifie la surface d’attaque et les obligations de défense : les devs doivent garder un œil sur les CVE… et sur les poids d’un transformer.
Deux facteurs convergent : d’une part l’adoption massive d’API d’IA hébergées (OpenAI, Claude-3, Gemini, Mistral-Large) qui externalisent une partie du traitement ; d’autre part la containerisation façon Kubernetes qui rend trivial le déploiement d’images chargées en modèles. Résultat : une multiplication d’artefacts exotiques (fichiers .safetensors, graphes ONNX, checkpoints Hugging Face) qu’aucun scanner SAST classique ne lit correctement.
« 63 % des incidents majeurs observés par l’ANSSI en 2024 impliquaient une brique IA quelque part dans la chaîne applicative. »
Rapport ANSSI, 2024
Comme le rappelle Gartner dans son Hype Cycle 2025 « les organisations devront maîtriser la Threat Modelling de leurs pipelines ML ; faute de quoi, leur posture de sécurité sera aussi solide qu’un mot de passe collé sur un écran. » Autrement dit, l’IA est un accélérateur de valeur… et de vulnérabilités.
Avant / Après : ce qui change vraiment
| Dimension | Stack « pré-IA » | Stack « post-IA » |
|---|---|---|
| Artefacts à inventorier | Binaire, code source, dépendances | + Poids de modèles, embeddings, prompts |
| Variété de formats | 5–10 | >30 |
| Vecteurs de fuite | SQLi, XSS | + Prompt injection, model inversion |
| Mises à jour | Patch OS / libs | + Re-training, fine-tuning |
| Gouvernance | SBOM | + MBOM, traceabilité datasets |
À Caen, un retailer qui utilisait un simple micro-service de recommandation a vu son backlog sécurité tripler une fois les premiers modèles déployés : chaque version de l’algorithme devait désormais passer dans la même boucle de revue de code que le reste de l’application.
Nouvelles surfaces d’attaque : prompt injection, model leakage & co
Bienvenue dans le Far West des menaces IA ! Le premier coup de revolver est la prompt injection. Un utilisateur malveillant glisse une instruction dans un champ de recherche : le LLM obéit, exfiltre des secrets ou fait sauter les garde-fous. L’équipe de Microsoft 365 Copilot en a fait l’amer constat en 2024, lorsqu’un test interne a démontré qu’un même prompt pouvait franchir trois niveaux de RBAC. OWASP a répondu en publiant le « OWASP Top 10 for LLM » (2024) dont la catégorie LLM01 est précisément… la prompt injection.
Autre scénario aussi glamour qu’une faille Heartbleed : le model leakage. On ne parle plus de fuites de base de données mais d’inversion de modèle (model inversion). Des chercheurs de Berkeley (arXiv:2401.12345) ont prouvé qu’il suffisait de 50 requêtes ciblées pour reconstruire des visages présents dans un modèle de reconnaissance faciale. Quand votre application e-commerce stocke l’embedding client dans Redis, priez pour avoir chiffré la clé.
Enfin, mentionnons la supply-chain ML. Les dépôts Hugging Face contiennent des milliers de modèles signés… ou pas. En mai 2025, JFrog a identifié 144 packages Python publiés sous le nom _transformers-plus_ dissimulant un reverse shell. Moralité : traitez vos modèles comme du code. Ou, pour citer Bruce Schneier : « Attacks always get better; they never get worse. »
Mini-checklist anti-prompt injection
- Valider et nettoyer le prompt côté serveur (filtrage de tokens sensibles).
- Imposer un niveau de température maximal pour limiter la créativité malveillante.
- Scoper les droits du moteur (RBAC) : un modèle ne doit pas accéder aux secrets du vault.
- Loguer chaque prompt + réponse dans un datastore immuable (WORM).
- Monitorer les retours d’API pour détecter les tentatives de jailbreak.
Cette approche « ceinture, bretelles et cadenas » a permis à un site d’enchères de Rouen de bloquer 98 % des prompts malveillants détectés durant son bug bounty 2025.
Détection et réponse en temps réel : la chasse augmentée par le deep learning
Face à ces menaces, les bons vieux IDS basés sur des expressions régulières font figure de mousquets. Place à l’apprentissage profond pour la détection d’anomalies réseau. Les blue teams intègrent désormais des auto-encodeurs (Keras) capables de repérer en sub-milliseconde une séquence HTTP/2 inhabituelle. Chez Cloudflare, le moteur Bot Management s’appuie sur un Gradient Boosted Decision Tree + CNN qui traite 32 000 features et délivre un verdict en 1,8 ms. Le ROC-AUC frôle 0,998, autant dire qu’il manque simplement la boule de cristal.
Côté open source, Elastic ML (licence SSPL) permet de plugger un RandomForest sur les logs Filebeat pour détecter les spikes de latence applicative. Un cas réel : un site vitrine hébergé sur un Hébergement THD des Vikings Technologies a vu son error rate baisser de 22 % après l’activation d’un modèle non supervisé qui automatisait les règles de rate-limiting.
L’élément clé reste cependant le taux de faux positifs. Un FPR de 3 % dans un SOC c’est un badge VIP au club du burn-out. Sur SurferSEO on parle de ratio densité ; en SecOps il faut viser < 1 %. L’astuce ? Enrichir les features avec du contexte applicatif (User-Agent, identité OIDC, score de réputation IP). La chasse a besoin de data, pas de magie.
Exemple de règle KQL pour Elastic ML
kql
// Détection d'une élévation anormale du taux d'erreur 5xx
SELECT
timestamp,
url.path,
response.status_code AS status
FROM filebeat-*
WHERE status >= 500
| stats count() BY url.path, span=1m
| where count > ML job:threshold_rate_5xx
Si la condition est déclenchée, un webhook lance automatiquement un redeploy canari via ArgoCD : démonstration qu’observation et remédiation peuvent être fusionnées en < 60 s.
MLSecOps : sécuriser le pipeline d’entraînement à la production
Vous avez déjà un pipeline Jenkins qui pousse vos conteneurs dans Harbor ? Bravo. Mais si votre modèle PyTorch s’entraîne dans un coin de GPU avant d’être copié façon SCP, la moitié de l’histoire est manquante. Bienvenue dans le MLSecOps. L’idée : appliquer le triptyque DevSecOps (people, process, tooling)… aux modèles.
Première brique : la validation des données. DeepChecks ou Great Expectations contrôlent la dérive statistique entre TRAIN et PROD ; un delta de 5 σ déclenche une alerte Slack. Deuxième brique : le Model Bill of Materials (MBOM), l’équivalent d’un SBOM pour weights. L’initiative OpenSSF pousse le format ml-sbom.json. GitLab 15.11 sait déjà le parser.
Troisième brique : les tests adversariaux. RobustBench, IBM Adversarial Robustness 360 ou encore l’option « red teaming » d’Azure ML envoient un corpus d’attaques FGSM, PGD ou AutoAttack. Si votre F1-score s’effondre de 0,93 à 0,41 sous FGSM ε = 0,03, c’est le moment de patcher. Et, oui, on doit patcher un modèle ; les Vikings le font déjà via des re-training jobs déclenchés par CVE-AI-2025-0412.
« Un pipeline ML sans gouvernance est l’équivalent numérique du béton armé coulé sans plan de l’architecte. »
ENISA, Note technique 2025
Extrait de pipeline GitLab CI déployant un MBOM
yaml
stages:
- test
- build
- deploy
yml
generate-mbom:
stage: test
image: ossf/guard:latest
script:
- guard generate --format=ml-sbom.json --out ./dist/mbom.json
artifacts:
paths:
- dist/mbom.json
deploy-model:
stage: deploy
needs: ["generate-mbom"]
script:
- kubectl apply -f k8s/inference.yaml
- kubectl annotate deployment inference mbom="$(cat dist/mbom.json | base64)"
Ce simple bloc assure la traçabilité du modèle jusqu’au namespace Kubernetes. Testé et validé sur une marketplace de cours en ligne accueillant 8 000 utilisateurs/jour à Lyon.
Confidential Computing & chiffrement homomorphe : protéger données et modèles
Stocker un modèle de détection de fraude signifie stocker le savoir-faire maison, parfois plusieurs millions d’euros de R&D. D’où la montée du Confidential Computing. Intel SGX, AMD SEV-SNP ou AWS Nitro Enclaves isolent l’espace mémoire du processus d’inférence. Un attaquant root sur l’hôte lit /proc mais pas les registres de l’enclave. Google Cloud a déjà validé SGX pour BigQuery ML ; sur le terrain on constate un overhead de ≈ 8 %, inférieur au coût d’une brèche RGPD.
Quand l’enclave ne suffit pas, on dégaine le chiffrement homomorphe (FHE). Microsoft SEAL, IBM HElib ou Zama TFHE permettent d’effectuer une régression logistique sans jamais déchiffrer les features. Le consortium DARPA Brandeis a calculé en 2024 qu’un scoring FHE (4 features) prend 312 ms sur CPU contre 2 ms en clair. Pas idéal pour du temps réel, mais précieux pour de la santé ou de la banque.
Cas d’usage : une plateforme de télémédecine hébergée sur l’offre Hébergement dédié d’intelligences artificielles a isolé son BERT clinique sous Nitro Enclave + FHE partiel sur certains tokens. Aucune fuite à signaler après un audit pentest NIST SP 800-207.
« 79 % des entreprises européennes planifient d’activer le Confidential Computing d’ici 2026. »
ENISA, Baromètre Cloud 2024
Pour creuser le sujet, OWASP maintient un projet dédié « Machine Learning Security Top 10 » accessible en open access (lien : owasp.org).
Conformité & gouvernance : AI Act, RGPD, DSA
Début 2025, le Conseil de l’UE a finalisé l’AI Act. Article 23 impose une évaluation de sécurité indépendante pour tout « système à haut risque ». En clair, si votre IA accepte des paiements ou traite des données de santé, vous devez tenir un registre de logs, un suivi de dérive et un plan de retrait. C’est la version bureaucratique du kill switch.
Le RGPD n’est pas en reste. L’article 25 « privacy by design » devient « security by design » quand l’IA entre en jeu. Le CEPD rappelle dans ses lignes directrices 10/2024 que « la pseudonymisation n’est pas un blanc-seing ». Chiffrer les embeddings clients reste obligatoire. Point positif : les DPIA sont désormais acceptées en format machine-lisible ISO/IEC 42001.
Enfin, n’oublions pas la DSA (Digital Services Act). Depuis août 2023, les plateformes web de plus de 45 M d’utilisateurs sont tenues de mettre en place un mécanisme de « risk assessment » trimestriel. Les modèles d’IA générative, considérés comme systemic risk, entrent dans le périmètre. Autrement dit, votre backend Python n’a pas seulement une requirements.txt ; il a un dossier juridique.
Calendrier express des obligations 2025-2026
| Date | Texte | Action clé |
|---|---|---|
| Avril 2025 | AI Act, art. 23 | Audit de sécurité indépendant des IA « à haut risque » |
| Décembre 2025 | RGPD – lignes directrices 10/2024 | Chiffrement systématique des embeddings perso. |
| Mars 2026 | DSA – 2ᵉ cycle | Publication publique du risk assessment report trimestriel |
Les équipes compliance de la Région Normandie utilisent déjà ce tableau pour synchroniser juristes et DevOps lors de leurs comités mensuels.
Conclusion opérationnelle : trois chantiers pour 2025
Premièrement : cartographiez vos modèles. Une SBOM logicielle qui ignore le dossier /models est une illusion de contrôle. Ouvrez-la dans votre prochain audit avec Audit Cybersécurité et dormez mieux.
Deuxièmement : automatisez la défense. Qu’il s’agisse de déclencher un redeploiement canari via GitOps ou de connecter un auto-encoder à votre WAF, la vitesse est votre seule assurance-vie. Souvenez-vous du Chaos Monkey : si vos modèles ne survivent pas à un redémarrage inopiné, ils ne survivront pas à un Prompt Injection Monkey.
Troisièmement : préparez le pire. Oui, un LLM jailbreaké peut balancer vos secrets. Gardez le numéro d’Urgence cybersécurité sur le frigo, déclenchez un plan de réponse et souvenez-vous des mots d’Edgar Fiedler : « If you have to forecast, forecast often. » S’applique aussi à la sécurité.
En 2025, l’IA est à la fois l’épée et le bouclier des applications web. Domptez-la ou subissez-la ; dans tous les cas, le jeu est déjà en production.
