La modélisation de sécurité consiste à représenter de manière formelle les menaces, les actifs et les contrôles d’un système pour anticiper les failles avant qu’elles ne soient exploitées. Le terme « sec model » recouvre aussi bien les frameworks de threat modeling (STRIDE, PASTA, LINDDUN) que les modèles de protection multicouche appliqués aux infrastructures cloud ou on-premise. Malgré la maturité de ces approches, certaines erreurs de conception reviennent avec une régularité frappante, y compris dans des organisations disposant d’équipes dédiées.
Périmètre flou du modèle de sécurité : la source de la plupart des erreurs
Un sec model commence toujours par une question de périmètre. Quels systèmes, quelles données, quels flux sont inclus dans l’analyse ? Quand cette délimitation reste implicite ou négociée à la hâte, le modèle produit des résultats décalés par rapport aux risques réels.
Le cas le plus fréquent : un modèle conçu autour de l’application principale, qui ignore les API tierces, les files de messages ou les buckets de stockage cloud utilisés en périphérie. Ces composants hors périmètre concentrent pourtant une part significative des vulnérabilités exploitées. Les analyses récentes confirment que le contrôle d’accès cassé et la mauvaise configuration dominent les taxonomies de risque, notamment dans le classement OWASP, ce qui pointe directement vers des éléments d’architecture souvent exclus du modèle initial.
Définir le périmètre ne se résume pas à lister des serveurs. Cela implique de cartographier les flux de données entre composants, d’identifier les points de confiance (trust boundaries) et de formaliser ce qui est « dedans » et « dehors ». Sans cette étape, le modèle ne protège qu’une fraction du système réel.
Erreurs de threat modeling liées aux hypothèses de confiance
Une deuxième catégorie d’erreurs porte sur les hypothèses implicites de confiance entre composants. Dans beaucoup de modèles, les échanges internes sont considérés comme sûrs par défaut. Cette supposition s’effondre dès qu’un attaquant obtient un accès latéral, par exemple via un conteneur compromis ou un compte de service surprivilégié.
Le rapport Red Hat State of Cloud-Native Security (publié en 2025) identifie la mauvaise configuration comme la première faiblesse opérationnelle dans les environnements cloud-native. Ce constat illustre un problème structurel : la complexité multi-cloud et conteneurs dépasse les hypothèses de confiance classiques. Les modèles qui supposent un réseau interne fiable ne résistent pas à la réalité des architectures distribuées actuelles.
Pour corriger cela, chaque flux entre deux composants doit être évalué indépendamment. La question à poser n’est pas « ce service est-il interne ? » mais « que se passe-t-il si ce service est compromis ? ».
Modèle de sécurité statique : le piège de la conception figée
Un sec model produit à un instant T perd sa valeur s’il n’est jamais révisé. C’est une erreur de conception au sens propre : traiter le modèle comme un livrable ponctuel au lieu d’un artefact vivant. Les architectures évoluent, les dépendances changent, de nouvelles API sont exposées, et le modèle initial devient silencieusement obsolète.
Plusieurs signaux doivent déclencher une mise à jour du modèle :
- Ajout ou suppression d’un composant dans l’architecture (microservice, base de données, endpoint API)
- Changement de fournisseur cloud ou migration d’un service vers un autre provider
- Modification des droits d’accès ou du mécanisme d’authentification
- Publication d’une nouvelle vulnérabilité affectant une brique technologique utilisée
Le Cyber Resilience Act européen, dont la guidance finale a été publiée en juillet 2026, introduit une exigence explicite de gestion du cycle de vie des vulnérabilités pour les produits numériques. Cette obligation réglementaire rend d’autant plus risqué le maintien d’un modèle de sécurité figé.
Risques liés à l’absence de tests sur le sec model
Construire un modèle sans le confronter à des scénarios d’attaque concrets revient à rédiger un plan d’évacuation sans jamais faire d’exercice. Les tests de pénétration, les exercices red team ou les revues de code orientées sécurité servent précisément à valider (ou invalider) les hypothèses du modèle.
L’erreur fréquente consiste à considérer le test comme une étape séparée, menée après le développement, plutôt que comme un mécanisme de feedback intégré au cycle de modélisation. Un modèle prédit qu’un contrôle d’accès bloque tel scénario ; le test vérifie si c’est le cas. Sans cette boucle de validation, le modèle reste théorique.
Certaines organisations limitent aussi les tests aux périmètres couverts par le modèle, ce qui reproduit l’erreur de périmètre décrite plus haut. Les tests doivent volontairement déborder du cadre modélisé pour identifier les angles morts.
Intégrer le test dans le cycle de développement
L’approche la plus efficace couple le threat modeling au pipeline CI/CD. À chaque modification significative du code ou de l’infrastructure, les scénarios de menace associés sont rejoués automatiquement ou signalés pour revue manuelle. Ce couplage garantit que le modèle et le système réel restent synchronisés.
Erreur humaine et modélisation de sécurité : un facteur sous-modélisé
Les modèles de sécurité se concentrent naturellement sur les vecteurs techniques : injection SQL, élévation de privilèges, exfiltration réseau. Le facteur humain, lui, reste souvent traité comme une variable externe, hors du périmètre de la modélisation. Les données disponibles pour 2026 indiquent pourtant que l’erreur humaine reste le principal facteur de pertes cyber, devant les attaques automatisées ou les exploits zero-day.
Modéliser le facteur humain suppose d’inclure dans le sec model des scénarios où un utilisateur légitime commet une action non prévue :
- Partage accidentel de credentials via un canal non sécurisé
- Modification de configuration en production sans validation par un pair
- Attribution de droits d’accès excessifs par commodité ou méconnaissance
Ces scénarios ne relèvent pas du social engineering classique (phishing, pretexting), mais de la protection contre les erreurs involontaires de personnels autorisés. Les intégrer au modèle change la nature des contrôles recommandés : on passe de la détection d’intrusion à la prévention d’erreurs, avec des mécanismes comme la validation à quatre yeux ou les guardrails automatiques sur les changements de configuration.
Un sec model fiable se distingue moins par la sophistication de ses diagrammes que par la rigueur de ses hypothèses et la fréquence de ses révisions. Les erreurs les plus coûteuses ne viennent pas de menaces exotiques, mais de périmètres mal définis, d’hypothèses de confiance jamais questionnées et de modèles que personne ne met à jour.
Traiter le modèle comme un document vivant, soumis à des tests réguliers et enrichi du facteur humain, reste le levier le plus direct pour réduire l’écart entre la protection théorique et la surface d’attaque réelle.
