Dans beaucoup d’organisations, la sécurité entre en scène trop tard. L’architecture est dessinée, les choix structurants sont gelés, le développement est lancé — et c’est seulement à l’approche de la mise en production qu’un audit ou un test d’intrusion vient révéler ce qu’il aurait fallu décider des mois plus tôt. On colmate alors dans l’urgence : un pare-feu ici, un chiffrement là, une exception de conformité pour tenir la date.

Cette séquence est coûteuse et, surtout, elle protège mal. La sécurité n’est pas une couche que l’on superpose : c’est une propriété du système, qui découle de la façon dont il est structuré. La traiter par conception — security by design — signifie l’inscrire dans les vues d’architecture, au même rang que la performance, la disponibilité ou le coût. Voici ce que cela change concrètement.

Le symptôme : la sécurité comme couche terminale

Le schéma est familier. Un projet avance selon ses jalons fonctionnels. La sécurité est perçue comme une contrainte de fin de parcours, portée par une équipe distincte, sollicitée au moment de la revue de conformité. À ce stade, les marges de manœuvre sont presque nulles : changer un modèle d’authentification, recloisonner un réseau ou revoir la circulation des données suppose de défaire des décisions déjà bétonnées.

Le résultat se décline de plusieurs façons. Des contournements documentés comme « dette à traiter plus tard » — et jamais traités. Des contrôles ajoutés en périphérie qui donnent une illusion de protection sans réduire la surface d’attaque réelle. Et une tension permanente entre l’équipe projet, qui veut livrer, et l’équipe sécurité, perçue comme le service qui dit non.

La racine du problème n’est pas un manque d’outils. C’est un problème de séquence : la décision de sécurité arrive après la décision d’architecture, alors qu’elle en fait partie.

Pourquoi la sécurité est une décision d’architecture

Les propriétés de sécurité les plus déterminantes ne s’achètent pas, elles se dessinent. Trois exemples le montrent clairement.

La surface d’attaque est une conséquence directe de la structure. Un système monolithique exposé d’un bloc, un système découpé en services aux frontières nettes, ou un système où tout communique avec tout n’ont pas la même exposition — et cela se décide au moment où l’on trace les composants et leurs liens, pas après.

Le rayon d’impact (blast radius) d’une compromission dépend du cloisonnement. Si un attaquant qui prend pied dans un composant peut se déplacer latéralement vers l’ensemble du SI, c’est une question d’architecture réseau et d’identité, pas de produit de sécurité.

La circulation des données sensibles — où elles sont stockées, par où elles transitent, qui peut les lire — est dessinée dans les vues de données et de flux. Une donnée bien architecturée est protégeable ; une donnée qui se répand partout ne l’est plus, quel que soit l’outillage déployé.

Dans les trois cas, la sécurité est déterminée par des choix structurants pris très en amont. C’est précisément le terrain de l’architecte d’entreprise : non pas remplacer le RSSI, mais faire entrer ses exigences dans le dessin du système, au moment où elles sont encore négociables.

Modéliser la menace dès les premières vues

La modélisation des menaces (threat modeling) est l’exercice qui ancre la sécurité dans la conception. L’idée est simple : avant de construire, se demander systématiquement qu’est-ce qui peut mal tourner ? Elle ne requiert pas d’outil sophistiqué — un diagramme de flux de données et une discussion structurée suffisent pour démarrer.

Quatre questions structurent l’exercice :

  • Que construisons-nous ? On part d’un schéma de flux de données : les composants, les échanges, les frontières de confiance (là où la donnée passe d’une zone maîtrisée à une zone qui l’est moins).
  • Qu’est-ce qui peut mal tourner ? Pour chaque flux et chaque frontière, on énumère les menaces. Une grille comme STRIDE — usurpation, falsification, répudiation, divulgation, déni de service, élévation de privilèges — aide à ne rien oublier.
  • Qu’allons-nous faire ? À chaque menace jugée crédible, on associe une parade : un contrôle, un choix de conception, ou une décision assumée d’accepter le risque.
  • Avons-nous bien fait ? On revalide après coup, car l’architecture évolue et les menaces aussi.

Mené au stade du dessin, cet exercice ne coûte que quelques ateliers. Mené après la mise en production, le même constat impose des reprises lourdes. L’écart de coût entre « corriger sur un schéma » et « corriger en production » est la meilleure justification économique du security by design.

Trois principes d’architecture qui font le gros du travail

Au-delà de la modélisation, quelques principes structurants portent l’essentiel de la résilience d’un système. Ils ne sont pas nouveaux ; ils sont simplement trop souvent invoqués sans être réellement architecturés.

La segmentation et le moindre privilège

Segmenter, c’est diviser le système en zones dont les communications sont explicitement contrôlées, de sorte qu’une compromission reste confinée. Le moindre privilège applique la même logique aux droits : chaque composant, chaque identité, chaque service ne dispose que des accès strictement nécessaires à sa fonction.

Ces deux principes répondent à une réalité incontournable : on ne peut pas garantir qu’aucune brèche n’arrivera jamais. La question utile n’est donc pas seulement « comment empêcher l’intrusion ? » mais « jusqu’où un intrus peut-il aller une fois entré ? ». Un système bien segmenté transforme une compromission catastrophique en incident localisé. Cela se décide sur le schéma d’architecture, en traçant les frontières et les flux autorisés.

La défense en profondeur

Aucun contrôle n’est infaillible. La défense en profondeur consiste à superposer plusieurs lignes indépendantes, de sorte que la défaillance de l’une ne suffise pas à compromettre l’ensemble : authentification, autorisation, chiffrement, journalisation, supervision. L’enjeu architectural est de s’assurer que ces couches sont réellement indépendantes — un empilement de contrôles qui partagent tous le même point de faiblesse ne constitue pas une défense en profondeur, seulement une illusion d’épaisseur.

Ne pas faire confiance par défaut

L’approche dite zero trust renverse une hypothèse longtemps tenue pour acquise : l’idée qu’à l’intérieur du périmètre réseau, tout est digne de confiance. Dans un SI moderne — services distribués, cloud, partenaires, mobilité — ce périmètre n’existe plus vraiment. Le principe devient : vérifier explicitement chaque accès, quelle que soit son origine, plutôt que de présumer la légitimité d’une requête parce qu’elle vient « de l’intérieur ». C’est un parti pris d’architecture d’identité et de réseau, pas un produit que l’on installe.

La souveraineté et la localisation des données

Pour les organisations soumises à des exigences réglementaires fortes — secteur public, santé, finance — la sécurité ne se limite pas à empêcher les intrusions. Elle englobe la maîtrise du lieu où vivent les données et des juridictions auxquelles elles sont soumises. Ces exigences de souveraineté sont, elles aussi, des contraintes d’architecture.

Où une donnée est-elle stockée ? Sous quelle juridiction tombe le fournisseur d’hébergement ? Quelles données peuvent quitter le territoire et lesquelles ne le peuvent pas ? Quelles dépendances vis-à-vis d’un fournisseur unique crée-t-on, et à quel point sont-elles réversibles ? Ces questions doivent être posées au moment où l’on choisit les plateformes et où l’on dessine les flux — pas découvertes lors d’un contrôle de conformité.

Concevoir pour la souveraineté ne veut pas dire renoncer au cloud ou aux services managés. Cela veut dire expliciter ces choix dans l’architecture : classifier les données selon leur sensibilité, tracer précisément leur circulation, et documenter les options de réversibilité. Une architecture qui rend visibles la localisation et la trajectoire des données sensibles est une architecture qui peut prouver sa conformité — au lieu de l’espérer.

Inscrire la sécurité dans la gouvernance d’architecture

Pour que la sécurité soit traitée par conception, elle doit cesser d’être un jalon ponctuel pour devenir une dimension permanente de la gouvernance d’architecture. Quelques leviers concrets le permettent.

Des exigences non fonctionnelles formalisées. Confidentialité, intégrité, disponibilité, traçabilité, exigences de localisation : ces attributs doivent figurer explicitement dans les exigences, au même titre que les fonctionnalités. Ce qui n’est pas écrit ne sera pas arbitré.

Des points de contrôle aux bons moments. Plutôt qu’une revue de sécurité unique en fin de parcours, des points de décision aux jalons d’architecture — choix de plateforme, dessin des flux, modèle d’identité — là où les décisions sont encore réversibles.

Un langage commun. Le RSSI raisonne en risques, l’architecte en composants et en flux. La valeur de l’architecte d’entreprise est de faire le pont : traduire une exigence de risque en contrainte de conception, et rendre lisible, pour la direction, le compromis entre niveau de protection, coût et agilité.

Le compromis assumé plutôt que la fausse promesse

La sécurité par conception n’est pas la promesse d’un système inviolable — cette promesse n’existe pas. C’est la discipline qui consiste à prendre les décisions de sécurité au moment où elles sont les moins coûteuses et les plus efficaces : pendant la conception, sur le schéma, quand tout est encore négociable.

Cela suppose un changement de posture. La sécurité cesse d’être le service qui dit non en fin de course pour devenir un critère de conception parmi d’autres, arbitré en pleine conscience. Certaines protections ont un coût en performance, en complexité ou en agilité ; l’enjeu n’est pas de tout protéger au maximum, mais de décider, en connaissance de cause, ce que l’on protège, contre quoi, et à quel prix.

C’est précisément le rôle de l’architecture d’entreprise : rendre ces compromis visibles et explicites, au lieu de les subir une fois qu’il est trop tard pour les corriger.