La plupart des équipes de développement construisent leurs systèmes en pensant à leurs utilisateurs. C’est le bon réflexe. Mais dans les secteurs à forts enjeux, un réflexe supplémentaire est indispensable : concevoir aussi pour celui qui veut faire échouer le système.
Ce n’est pas du pessimisme. C’est une discipline. La modélisation des menaces consiste à se poser les questions inconfortables dès la phase de conception, avant que le code existe, pendant qu’il coûte encore peu de changer d’avis.
Le problème de la sécurité en couche
L’approche dominante dans l’industrie consiste à construire d’abord, puis à sécuriser. On développe l’application, on la livre, et au moment du déploiement on ajoute un WAF, on active le HTTPS, on installe un scanner de vulnérabilités. C’est la sécurité en couche : une enveloppe protectrice posée sur un objet qui n’a pas été conçu pour être protégé.
Cette approche a un défaut structurel. Les vulnérabilités les plus critiques ne sont pas des oublis de configuration. Elles sont architecturales. Elles sont inscrites dans le modèle de données, dans la façon dont les composants communiquent, dans les hypothèses implicites sur qui peut appeler quelle API. Un scanner ne les voit pas. Un WAF ne les corrige pas.
Penser comme l’adversaire
La sécurité n’est pas une fonctionnalité qu’on ajoute. C’est une propriété du système qu’on choisit de construire ou qu’on choisit d’ignorer.
La modélisation des menaces force une question précise : qui veut nuire à ce système, et comment ? Dans un contexte de défense, la réponse est différente de celle d’une application de gestion RH. Dans un contexte médical, les motivations d’un attaquant et les conséquences d’une compromission sont différentes encore.
Cette question en entraîne d’autres. Quels actifs valent la peine d’être protégés ? Par quels chemins un attaquant peut-il les atteindre ? Quelles hypothèses l’application fait-elle sur ses entrées, ses appelants, son environnement ? Chaque hypothèse implicite est une surface d’attaque potentielle.
Ce que ça change en pratique
Concevoir pour l’adversaire change la nature des décisions prises à chaque étape. Au moment du choix du modèle de données, on se demande ce qu’un accès non autorisé à cette table révèle sur l’ensemble du système. Au moment de définir une API, on pose la question de l’authentification et de l’autorisation avant même la logique métier.
Le coût de cette discipline est réel. Elle ralentit légèrement les premières phases de conception. Elle génère des questions inconfortables auxquelles les équipes produit préfèrent parfois ne pas répondre. Mais comparé au coût d’une remédiation architecturale après livraison, ce surcoût est négligeable. Et comparé au coût d’un incident dans un environnement à forts enjeux, il est inexistant.
Pour les décideurs techniques
Si vous lisez ceci en tant que DSI ou directeur technique, la question n’est pas de savoir si vos équipes font du bon travail. Elle est de savoir si elles ont été outillées pour poser les bonnes questions au bon moment.
La modélisation des menaces n’est pas une expertise rare. C’est une pratique qui s’apprend, qui se structure, et qui produit des livrables concrets : des diagrammes de flux de données, des registres de menaces, des décisions d’architecture documentées et justifiées. Ces livrables ne servent pas seulement à sécuriser le système — ils constituent une trace auditée de votre posture de sécurité.
Dans les secteurs régulés, cette trace a une valeur propre. Elle démontre une démarche, pas seulement un résultat.