Threat modeling — guide complet 2026.

Qu'est-ce que le threat modeling ?

Le threat modeling (modélisation des menaces) est la pratique d'ingénierie sécurité qui consiste à identifier, analyser et hiérarchiser les menaces pesant sur un système — avant qu'elles soient exploitées. C'est la couche structurante qui transforme une intuition sécurité ("on a un risque") en un livrable décisionnel ("voici les 12 menaces priorisées, voici le plan").

Adam Shostack (Microsoft, auteur de référence sur le sujet) résume la pratique en quatre questions :

1. On construit quoi ?
2. Qu'est-ce qui peut mal tourner ?
3. Qu'est-ce qu'on fait à ce sujet ?
4. A-t-on fait du bon travail ?

Le livrable type d'un exercice de threat modeling combine un diagramme de flux de données (DFD) à plusieurs niveaux d'abstraction, un catalogue de menaces priorisées (par CVSS, DREAD ou risque métier), et un plan de mitigation aligné sur l'architecture cible. Ce livrable est ce qu'un auditeur ISO 27001 (A.8.25, A.8.27), SOC 2 (CC7.1, CC8.1) ou un évaluateur AI Act (Article 9) va lire pour valider la posture sécurité du système.

Méthode WeeSec — threat modeling en 5 étapes

La méthode WeeSec consolide STRIDE, LINDDUN, PASTA et l'OWASP LLM Top 10 dans un cadre unique applicable aux systèmes produit, IA et agents.

1. Cadrage et inventaire — système concerné, périmètre, parties prenantes, niveau de criticité métier, exigences réglementaires applicables (CRA, AI Act, NIS2, DORA, RGPD).
2. Diagramme de flux de données (DFD) — niveau 0 (contexte), niveau 1 (composants principaux), niveau 2 (interactions internes critiques). Identification des frontières de confiance (trust boundaries).
3. Identification des menaces — par catégorie STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege), LINDDUN (vie privée) si données personnelles, OWASP LLM Top 10 (prompt injection, data leakage, jailbreak, hijack d'agent) si LLM.
4. Priorisation — chaque menace est notée CVSS 3.1 (ou CVSS 4.0 pour les nouveaux), DREAD si scoring qualitatif préféré, et croisée avec l'impact métier réel pour produire une matrice de priorisation actionnable.
5. Plan de mitigation et validation — contre-mesures architecture (chiffrement, isolation, authentification forte, RBAC, supervision), contre-mesures process (code review sécurité, SAST/DAST/SCA, runbooks d'incident). Validation par revue avec l'équipe puis test empirique (pentest ou red team) sur les zones les plus critiques.

STRIDE — le cadre Microsoft de référence

STRIDE est le cadre de threat modeling le plus utilisé en 2026. Acronyme de six catégories de menaces :

• Spoofing — usurpation d'identité (utilisateur, service, certificat).
• Tampering — altération non autorisée des données ou du code.
• Repudiation — déni d'une action (manque de logs auditables).
• Information disclosure — fuite d'informations sensibles.
• Denial of service — épuisement de ressources, indisponibilité.
• Elevation of privilege — élévation de privilèges, prise de contrôle.

STRIDE s'applique à chaque élément du DFD : pour un processus, on examine les 6 catégories ; pour un flux, on examine au minimum Tampering et Information disclosure ; pour un data store, on examine Tampering, Information disclosure et Repudiation. Chaque "case" produit une ligne de catalogue à examiner ou justifier.

LINDDUN — threat modeling vie privée et RGPD

LINDDUN (Linkability, Identifiability, Non-repudiation, Detectability, Disclosure of information, Unawareness, Non-compliance) est le cadre dédié aux menaces de vie privée. Quand le système traite des données personnelles (RGPD), LINDDUN complète STRIDE en couvrant explicitement les menaces qui n'apparaissent pas comme techniques mais qui sont des risques de conformité majeurs : ré-identification croisée, traçabilité non souhaitée, profilage, déduction.

Cadre incontournable pour les systèmes santé (HDS), fintech (RGPD + DORA), e-commerce et tout SaaS B2B traitant des données employés de ses clients.

OWASP LLM Top 10 et MITRE ATLAS — threat modeling pour systèmes IA

Les cadres classiques (STRIDE, LINDDUN) sous-estiment les menaces spécifiques aux systèmes IA. Pour les LLM en production, le threat modeling WeeSec combine deux référentiels dédiés.

OWASP LLM Top 10 (édition 2025-2026) liste les 10 vulnérabilités majeures spécifiques aux applications LLM :

• LLM01 Prompt Injection — directe (utilisateur) et indirecte (cachée dans document RAG, page web fetched, email parsé). Le vecteur dominant contre les agents 2026.
• LLM02 Sensitive Information Disclosure — fuite d'informations sensibles par le modèle.
• LLM03 Supply Chain Vulnerabilities — composants tiers (modèles, datasets, plugins) compromis.
• LLM04 Data and Model Poisoning — empoisonnement des données d'entraînement.
• LLM05 Improper Output Handling — sorties LLM non sanitisées passées à des composants downstream.
• LLM06 Excessive Agency — autonomie excessive des agents tool-using.
• LLM07 System Prompt Leakage — fuite du system prompt vers l'utilisateur.
• LLM08 Vector and Embedding Weaknesses — attaques sur RAG, embeddings, vector stores.
• LLM09 Misinformation — hallucinations et désinformation générée.
• LLM10 Unbounded Consumption — model DoS, coût incontrôlé.

MITRE ATLAS (Adversarial Threat Landscape for AI Systems) est l'équivalent IA de MITRE ATT&CK : tactiques et techniques adversariales spécifiques aux systèmes IA. À utiliser pour structurer la phase d'identification des menaces côté adversaire (pas côté défenseur).

Threat modeling pour agents autonomes (MCP, Claude Agent SDK, LangGraph)

Les agents LLM autonomes (Claude Agent SDK, LangGraph, AutoGen, CrewAI, et tous les MCP servers) introduisent une classe de menaces dédiée. Au-delà des risques LLM classiques, on ajoute :

• Hijack d'agent — prise de contrôle de l'agent via prompt injection indirecte (instruction cachée dans un document ingéré, un email parsé, une page web fetched).
• Excessive agency / privilege escalation — l'agent exécute des actions au-delà de son périmètre légitime.
• Tool abuse — utilisation détournée des outils légitimes exposés (envoi d'email, modification de base de données, lancement de processus).
• Multi-agent collusion — dans les architectures multi-agents, exploitation de l'interaction entre agents pour atteindre un objectif malveillant.

Quatre couches de défense WeeSec : (1) périmètre de privilèges minimum (least privilege explicite par outil), (2) sandbox d'exécution (microVM Firecracker, gVisor, container isolé), (3) validation humaine sur les actions à fort impact, (4) audit log immuable de toutes les invocations de tools.

Outils de threat modeling — sélection 2026

Outils OSS (open source) :

• OWASP Threat Dragon — gratuit, communautaire, web-based ou Electron desktop. Format JSON exportable et versionnable dans un repo Git. Idéal pour démarrer.
• Microsoft Threat Modeling Tool — gratuit, Windows-only, focalisé STRIDE, intégré aux outils Microsoft.
• pytm (OWASP) — threat modeling as code en Python. Le DFD et les menaces sont décrits en code, versionnés dans le repo. Best pratique pour intégrer le threat modeling au DevSecOps.

Outils commerciaux :

• IriusRisk — leader marché 2026, fort sur les intégrations CI/CD, gros catalogue de templates, scoring automatisé.
• ThreatModeler — entreprise, automation forte (templates AWS / Azure / GCP), génération automatique du DFD depuis l'infrastructure.
• SD Elements (Security Compass) — orienté SDLC, génère les exigences de sécurité et les contre-mesures à partir du contexte du système.

Spécifique threat modeling IA :

• Garak (NVIDIA) — scanner LLM open source, détection de prompt injection, jailbreak, hallucinations, fuite de données.
• PyRIT (Microsoft AI Red Team) — Python Risk Identification Tool, framework de red teaming automatisé pour LLM.
• Promptfoo — évaluation et testing de prompts, détection de régressions sécurité, intégration CI/CD.

Threat modeling et conformité réglementaire

Le threat modeling n'est pas un exercice optionnel — il matérialise plusieurs obligations réglementaires :

• ISO/IEC 27001:2022 — contrôle A.8.27 "Secure system architecture and engineering principles" et A.8.25 "Secure development life cycle" impliquent une démarche de modélisation des menaces formalisée sur les développements internes.
• SOC 2 Type II — Trust Services Criteria CC7.1 (System operations) et CC8.1 (Change management) attendent la même démarche structurée.
• AI Act (Règlement UE 2024/1689) — Article 9 "Système de gestion des risques" impose explicitement l'identification, l'analyse et l'évaluation des risques connus et raisonnablement prévisibles pour les systèmes IA à haut risque (Annexe III). Le threat modeling est le livrable opérationnel qui matérialise cette exigence. Application opérationnelle : 02 août 2026.
• Cyber Resilience Act (Règlement UE 2024/2847) — l'analyse de risques cybersécurité (Annexe I.1) attend une démarche structurée d'identification des menaces — donc en pratique un threat model documenté.
• NIST SP 800-154 — guide officiel NIST "Guide to Data-Centric System Threat Modeling".
• NIST AI RMF GenAI Profile (NIST AI 600-1, juillet 2024) — recommande explicitement le threat modeling adversarial pour les systèmes GenAI.

Threat modeling vs pentest vs red team — articulation

Trois activités complémentaires, séquentielles. Aucune ne remplace l'autre.

• Threat modeling — exercice théorique amont (avant ou pendant le design). Sortie : DFD, catalogue de menaces, plan de mitigation. Identifie ce qui pourrait mal tourner.
• Pentest — exercice empirique aval (sur système fonctionnel). Sortie : rapport de vulnérabilités exploitables sur un périmètre cadré. Confirme ce qui peut effectivement mal tourner.
• Red team — exercice empirique avancé (sur production ou pré-production). Sortie : rapport d'objectifs métier atteints par un adversaire simulé. Mesure ce qui peut mal tourner en condition réelle.

Le threat modeling permet de cadrer ce qu'il faut tester en priorité par pentest ou red team — et de réduire le périmètre de l'incertitude avant tout test offensif. C'est l'investissement le plus rentable en cybersécurité produit : il coûte une fraction du pentest et identifie les menaces structurelles que le pentest ne verra jamais.

Intégrer le threat modeling au DevSecOps

Trois points d'ancrage opérationnels pour ne pas tomber dans le théâtre.

1. En amont du sprint, sur les features à fort impact — atelier 2 heures avec dev, sécurité, produit, sur les features qui modifient l'auth, l'autorisation, le périmètre des données, ou l'intégration LLM. Sortie : DFD léger + top 5 menaces + plan de mitigation. Outil : Threat Dragon ou pytm en code.
2. Threat modeling as code — pytm ou Threat Dragon avec export JSON versionné dans le repo. Le DFD vit dans le code. Diff visible en code review quand l'architecture change. Pas de Drive perdu.
3. Gate en pré-prod — pour les déploiements à fort impact (nouveau service, refonte d'auth, intégration LLM, agent autonome) : un threat model à jour est en checklist de release. Permet de garder la pratique vivante sans devenir un goulet d'étranglement.

Threat modeling — accompagnement WeeSec

Trois formats de mission selon votre maturité.

• Threat modeling sprint (4 heures, 1 atelier) — sur une feature critique ou un microservice à fort risque. Sortie : DFD niveau composants, top 10 menaces, plan de mitigation. Fourchette : 1 500 € — 3 500 €.
• Threat modeling produit (2-4 semaines) — sur un SaaS ou un produit avec plusieurs flux critiques. Sortie : DFD multi-niveaux, catalogue 50-150 menaces priorisées CVSS, runbook de mitigation, plan d'audit. Fourchette : 6 000 € — 18 000 €.
• Threat modeling IA / agent (3-6 semaines) — système avec LLM en production, RAG, agents tool-using ou architecture multi-agents. Sortie : mapping OWASP LLM Top 10 complet, MITRE ATLAS coverage, design des guardrails, plan de red teaming aligné Garak/PyRIT/Promptfoo. Fourchette : 15 000 € — 40 000 €.

Mission menée directement par Aroua Biri (ingénieure docteure en cybersécurité Télécom SudParis, MIT Applied AI certified, ISO 27001 Lead Auditor, 15+ ans d'expérience). Vendor-neutral systématique. NDA signé avant tout échange technique détaillé.