Pourquoi l’architecture zero trust a tenu… et où elle a déçu
L’architecture zero trust a été présentée comme un remède universel, mais les DSI ont vite compris qu’il s’agissait surtout d’un modèle d’urbanisme de la sécurité, proche des recommandations de l’ANSSI sur la défense en profondeur (par exemple le guide « Maîtriser la SSI – principes et bonnes pratiques », version 2.0, 2022). En pratique, ce modèle zero trust impose de repenser la confiance, la sécurité des données et la segmentation du réseau bien avant de parler d’outils, ce qui a surpris plus d’une entreprise déjà saturée de projets cloud et de modernisation des applications. Résultat : la mise en œuvre a souvent été partielle, avec une posture de sécurité améliorée sur quelques ressources critiques, mais une surface de protection encore très hétérogène et des écarts de maturité importants entre métiers.
Le cœur du modèle de sécurité zero trust reste pourtant solide : ne jamais accorder de confiance implicite, vérifier systématiquement l’utilisateur, l’appareil et le contexte avant d’ouvrir l’accès aux services. Cette approche de trust architecture remet en cause les réflexes historiques de sécurité réseau périmétrique, où un seul pare-feu protégeait un vaste réseau interne rempli d’applications et de données peu cloisonnées. Les directions de la sécurité ont dû accepter que la confiance zéro par défaut implique une gestion des identités beaucoup plus fine, une authentification multifacteur généralisée et des contrôles de sécurité continus sur les utilisateurs, les appareils IoT et les postes de nouvelle génération, avec des tableaux de bord de risques plus précis et des indicateurs comme la couverture MFA ou le taux de sessions à risque bloquées.
Ce changement de modèle a aussi révélé un angle mort culturel : beaucoup d’équipes IT confondaient encore outils et architecture, en espérant qu’une solution de type ZTNA suffirait à « faire du zero trust ». Or, sans cartographie des flux, sans gestion des ressources applicatives et sans gouvernance claire des environnements cloud, ces solutions ne peuvent qu’améliorer à la marge la sécurité réseau existante. L’architecture zero trust n’est pas un produit de plus, c’est un cadre d’arbitrage entre risque, coût et effort, qui oblige à prioriser les menaces les plus probables plutôt que de courir après un idéal de confiance totale, tout en documentant les compromis acceptés et les niveaux de risque résiduel.
Les trois piliers qui fonctionnent : ZTNA, micro segmentation et identité continue
Dans les retours d’expérience d’entreprises françaises, trois composants de l’architecture zero trust ressortent comme réellement efficaces. Le premier est le ZTNA, qui remplace progressivement le VPN traditionnel en appliquant un modèle de sécurité par application, par utilisateur et par appareil, au lieu d’ouvrir tout un réseau interne. Ce basculement réduit fortement la surface de protection exposée, car chaque utilisateur n’atteint que les services et les ressources dont il a besoin, avec une confiance contrôlée en continu et des accès révoqués dès qu’un signal de compromission apparaît, ce qui permet souvent de réduire de l’ordre d’un tiers à la moitié le nombre de tunnels réseau trop larges dans les organisations les plus avancées.
Le deuxième pilier est la micro segmentation réseau, souvent mise en œuvre avec des solutions de type VMware NSX, Cisco Secure Workload ou Illumio, qui découpent le réseau en segments logiques alignés sur les applications et les données. Cette segmentation fine permet de limiter la propagation des menaces, en particulier dans les environnements cloud hybrides où le réseau zéro périmétrique n’existe plus vraiment. On ne parle plus d’un grand réseau interne de confiance, mais d’un ensemble de petits domaines de sécurité réseau, chacun protégé par des contrôles de sécurité adaptés à la sensibilité des données et à la criticité des services, avec des règles de filtrage plus lisibles pour les équipes opérationnelles et une réduction mesurable des mouvements latéraux lors des exercices de red team.
Le troisième pilier est la vérification continue d’identité, qui combine gestion des identités, authentification multifacteur résistante au phishing et analyse de la posture de sécurité des utilisateurs et des appareils. En articulant gestion des identités, authentification forte et évaluation de risque en temps réel, les entreprises renforcent la protection des applications critiques sans multiplier les frictions inutiles pour l’utilisateur final. Ce triptyque ZTNA, micro segmentation et identité continue incarne concrètement le trust architecture, en transformant un modèle théorique de confiance zéro en décisions opérationnelles sur qui accède à quoi, depuis quel environnement et dans quelles conditions, avec des scénarios de contrôle clairement priorisés et des KPIs comme la couverture ZTNA ou le pourcentage de comptes à privilèges revus chaque trimestre.
Les chantiers qui s’enlisent : cartographie, POLP applicatif et gestion des exceptions
Les mêmes retours d’expérience montrent pourtant des zones de blocage récurrentes dans la mise en œuvre de l’architecture zero trust. La cartographie exhaustive des flux applicatifs reste un serpent de mer, car peu d’entreprises disposent d’une vision fiable de leurs applications, de leurs dépendances réseau et de leurs échanges de données. Sans cette cartographie, le modèle de sécurité zero trust se heurte vite à la réalité : difficile de définir des politiques de confiance zéro si l’on ignore encore quels services parlent à quelles bases de données dans quels environnements cloud, et avec quels niveaux de sensibilité, ou si l’on ne sait pas mesurer la part de flux effectivement maîtrisés.
Le principe de moindre privilège (POLP) appliqué aux applications et aux utilisateurs se heurte lui aussi à la complexité fonctionnelle et à la pression métier. Les équipes d’architecture doivent arbitrer entre une réduction agressive des droits et la continuité des services, ce qui conduit souvent à des modèles de sécurité hybrides, loin de la confiance zéro théorique. La gestion des exceptions devient alors un chantier à part entière, avec des règles temporaires qui durent, des accès d’urgence qui restent ouverts et une posture de sécurité qui se fragilise au fil des projets, faute de revue régulière et d’outillage adapté pour suivre le volume d’exceptions et leur durée de vie moyenne.
Dans ce contexte, les DSI les plus lucides ont cessé de promettre un réseau zéro confiance parfaitement maîtrisé à court terme. Elles privilégient des itérations ciblées, en concentrant la mise en œuvre du modèle zero trust sur quelques domaines à forte valeur, comme les applications financières, les environnements cloud exposés à Internet ou les services critiques pour la production industrielle. L’enjeu n’est plus de couvrir tout le système d’information d’un coup, mais de réduire progressivement la surface de protection la plus risquée, en alignant les contrôles de sécurité sur les menaces réelles plutôt que sur un idéal d’architecture parfaite, et en s’appuyant sur des indicateurs de progrès partagés avec les métiers, tels que le pourcentage d’applications critiques effectivement segmentées.
Zero trust, NIS2 et conformité : éviter la double peine projet
Pour les architectes SI, l’un des défis majeurs est désormais d’articuler l’architecture zero trust avec les exigences réglementaires comme NIS2 ou les référentiels de type ReCSI (Référentiel de cybersécurité pour les systèmes d’information, publié par l’ANSSI en 2023). La tentation est forte de lancer des projets parallèles, l’un pour la conformité, l’autre pour la sécurité zero trust, au risque de doubler les efforts et de fragmenter la gouvernance. Une approche plus mature consiste à utiliser le modèle de sécurité zero trust comme squelette commun, en alignant les contrôles de sécurité exigés par NIS2 sur les mêmes briques de gestion des identités, de segmentation réseau et de protection des données, afin de mutualiser les investissements et de limiter les redondances.
Concrètement, les obligations de journalisation, de gestion des incidents et de protection des services essentiels peuvent être couvertes par les mêmes solutions de trust architecture déjà déployées pour sécuriser les environnements cloud et les applications internes. Les contrôles de sécurité imposés par les régulateurs deviennent alors des cas d’usage supplémentaires pour les plateformes existantes, plutôt qu’un empilement de solutions redondantes. Cette convergence réduit le coût de mise en œuvre, simplifie la gestion opérationnelle et renforce la cohérence de la posture de sécurité globale de l’entreprise, tout en facilitant les audits et la production de preuves de conformité.
Les groupes qui réussissent ce virage traitent la conformité comme un effet de bord positif d’une architecture zero trust bien pensée, et non comme un objectif isolé. Ils alignent les politiques d’accès, la gestion des identités et la protection des données sur un même modèle de confiance zéro, en évitant de multiplier les référentiels contradictoires. À terme, cette approche permet de transformer des contraintes réglementaires en leviers pour moderniser la sécurité réseau, rationaliser les services de sécurité et clarifier la responsabilité des utilisateurs comme des équipes IT, avec une feuille de route partagée et des jalons de conformité intégrés au programme zero trust.
Arbitrages coût / risque et cas d’école : ralentir pour mieux cadrer
La question qui fâche reste celle du rapport entre l’effort de mise en œuvre et la réduction de risque réellement obtenue. Beaucoup de DSI ont investi dans des solutions zero trust de nouvelle génération sans toujours disposer d’indicateurs clairs sur l’impact réel sur les menaces les plus fréquentes, comme le phishing ou les mouvements latéraux après compromission. Les plus avancées ont réorienté leurs budgets vers des chantiers mesurables, en liant chaque brique de trust architecture à un scénario de risque priorisé et à des métriques de posture de sécurité suivies dans le temps, comme le taux de comptes à privilèges réduits, la couverture ZTNA ou le nombre d’incidents détectés plus tôt.
Un cas d’école anonymisé, issu d’un groupe français de services de plus de 40 000 collaborateurs, illustre cette évolution : après une première phase trop ambitieuse, l’entreprise a volontairement ralenti son programme zero trust. Elle avait tenté de déployer simultanément une micro segmentation réseau globale, une refonte complète de la gestion des identités et une migration massive vers des environnements cloud, avec une pression forte sur les équipes et une multiplication des exceptions. En repartant d’un périmètre plus restreint, centré sur une vingtaine d’applications critiques et sur la protection des données les plus sensibles, le groupe a pu reconstruire un modèle de sécurité plus réaliste, avec une réduction significative des droits à privilèges excessifs et des indicateurs de succès partagés avec la direction.
Ce type de trajectoire illustre une vérité simple que les architectes SI connaissent bien : la confiance zéro n’est pas un absolu, c’est un gradient négocié entre risque, coût et complexité opérationnelle. Plutôt que de viser un réseau zéro confiance théorique, les entreprises gagnent à cibler les zones où la combinaison d’authentification multifacteur, de gestion des identités et de segmentation apporte le meilleur retour sur investissement. La maturité consiste à accepter des compromis explicites, documentés, plutôt qu’une promesse implicite de sécurité totale qui ne résiste jamais à la réalité des projets et aux contraintes budgétaires, en s’appuyant sur quelques KPIs opérationnels pour piloter les arbitrages.
Repenser les fondations : utilisateurs, appareils et données au centre du jeu
Au final, l’architecture zero trust oblige les équipes d’architecture à déplacer le centre de gravité de la sécurité, du réseau vers les utilisateurs, les appareils et les données. La distinction entre utilisateur et utilisateurs appareils devient structurante, car la confiance accordée à un compte dépend désormais autant de la gestion des identités que de la posture de sécurité du terminal ou des appareils IoT utilisés. Les environnements cloud, les applications SaaS et les services exposés sur Internet rendent cette approche incontournable, car il n’existe plus de périmètre réseau unique à protéger et les frontières entre interne et externe se brouillent.
Dans ce contexte, les solutions de sécurité de nouvelle génération qui combinent gestion des identités, contrôle d’accès conditionnel, inspection des flux et protection des données prennent tout leur sens. Elles permettent de mettre en musique le modèle de sécurité zero trust en appliquant des politiques dynamiques, basées sur le contexte, la sensibilité des ressources et le niveau de confiance zéro accordé à chaque session. La surface de protection se redéfinit alors en continu, au gré des connexions, des changements de posture de sécurité des appareils et des signaux de menaces collectés par les services de sécurité managés, avec des tableaux de bord consolidés pour les équipes SOC et des seuils d’alerte alignés sur les risques métier.
Pour les architectes SI, la priorité n’est plus de dessiner un réseau zéro idéal, mais de structurer une trust architecture pragmatique, capable d’absorber l’évolution rapide des usages et des environnements cloud. Cela implique de clarifier les responsabilités entre équipes réseau, équipes identité et équipes sécurité, afin que chaque contrôle de sécurité soit positionné au bon endroit, au bon niveau de granularité. L’architecture zero trust devient alors moins un slogan qu’un langage commun pour aligner les décisions techniques, les contraintes métier et les objectifs de résilience de l’entreprise, tout en facilitant la communication avec la direction générale et la priorisation d’une feuille de route pluriannuelle.
Questions fréquentes sur l’architecture zero trust
En quoi l’architecture zero trust diffère t elle d’une sécurité périmétrique classique ?
L’architecture zero trust part du principe que le réseau interne n’est plus fiable par défaut, contrairement au modèle périmétrique qui considère l’intérieur comme une zone de confiance. Au lieu de protéger uniquement le bord du réseau, la sécurité zero trust applique des contrôles de sécurité à chaque accès, pour chaque utilisateur et chaque appareil, en fonction du contexte et de la sensibilité des ressources. Cette approche réduit la capacité des attaquants à se déplacer latéralement une fois à l’intérieur du système d’information, en combinant segmentation, authentification forte et surveillance continue, avec des politiques d’accès plus granulaires et des journaux d’audit plus exploitables.
Quels sont les premiers chantiers concrets pour démarrer un programme zero trust ?
Les retours d’expérience montrent qu’il est pertinent de commencer par la gestion des identités et l’authentification multifacteur, car ces briques conditionnent tous les autres contrôles. En parallèle, le déploiement d’un ZTNA pour remplacer progressivement les VPN traditionnels permet de sécuriser l’accès aux applications critiques sans refondre immédiatement tout le réseau. Enfin, une première segmentation des environnements cloud et des services exposés à Internet offre un gain rapide sur la réduction de la surface de protection, avec des règles simples à expliquer aux métiers et une feuille de route priorisée en trois étapes : sécuriser les accès, segmenter les applications clés, puis étendre progressivement la couverture.
Comment mesurer l’efficacité d’une mise en œuvre zero trust dans une entreprise ?
Pour évaluer l’impact d’un programme zero trust, les DSI suivent des indicateurs concrets comme la réduction du nombre de comptes à privilèges excessifs, la baisse des accès réseau trop larges ou la diminution des mouvements latéraux observés lors des exercices de red team. Ils mesurent aussi le taux de couverture de l’authentification multifacteur sur les utilisateurs et les applications sensibles, ainsi que le pourcentage de flux applicatifs effectivement segmentés. Ces métriques permettent de relier directement les investissements en trust architecture à une amélioration mesurable de la posture de sécurité et à une meilleure résilience face aux incidents, tout en fournissant des preuves tangibles aux directions métiers.
Zero trust est il compatible avec des systèmes legacy et des applications anciennes ?
La compatibilité avec le legacy est souvent un frein, mais pas un blocage définitif pour l’architecture zero trust. Les entreprises peuvent isoler les applications anciennes dans des segments réseau dédiés, renforcer la protection des accès via des passerelles ZTNA et appliquer des contrôles de sécurité compensatoires autour des systèmes qui ne supportent pas nativement les mécanismes modernes. L’objectif n’est pas de rendre chaque application legacy parfaitement conforme au modèle zero trust, mais de réduire au maximum le risque qu’elle fait peser sur l’ensemble du système d’information, en priorisant les zones les plus exposées et en documentant les écarts acceptés.
Comment articuler zero trust avec les exigences de conformité comme NIS2 ou ReCyF ?
Zero trust et conformité ne sont pas deux mondes séparés, et il est plus efficace de les traiter comme deux faces d’une même stratégie de sécurité. En alignant les contrôles de sécurité exigés par NIS2 ou par des référentiels nationaux comme le ReCSI sur les briques de gestion des identités, de segmentation réseau et de protection des données déjà prévues par l’architecture zero trust, les entreprises évitent de dupliquer les projets. Cette approche permet de transformer les obligations réglementaires en catalyseur pour accélérer la modernisation de la sécurité réseau et des services critiques, tout en améliorant la traçabilité des décisions et la capacité à produire des rapports de conformité.
Chiffres clés sur l’architecture zero trust et la cybersécurité
- Les analyses de l’ANSSI soulignent que le phishing reste à l’origine d’une large majorité des compromissions réussies (par exemple le « Panorama de la menace informatique 2023 » met en avant le rôle central de la compromission d’identifiants dans les incidents majeurs), ce qui renforce l’importance d’une authentification multifacteur robuste dans tout modèle zero trust et d’une gestion des identités rigoureuse.
- Les études de cabinets comme Gartner (« Market Guide for Zero Trust Network Access », 2023) et Forrester (« The State Of Zero Trust Adoption In Europe », 2022) convergent pour montrer que les organisations ayant déployé une micro segmentation réseau ciblée réduisent significativement l’impact des mouvements latéraux lors d’incidents de sécurité, avec des baisses souvent de l’ordre de plusieurs dizaines de pourcents de systèmes touchés en cas de compromission par rapport à des architectures peu segmentées.
- Les rapports sectoriels indiquent que les entreprises qui unifient gestion des identités, ZTNA et protection des données dans une même trust architecture améliorent leur posture de sécurité tout en maîtrisant mieux leurs coûts opérationnels, grâce à une réduction des solutions redondantes et à une meilleure automatisation des contrôles de sécurité et des revues d’accès.
Ressources de référence pour aller plus loin
- ANSSI – Rapports et guides sur la sécurité des systèmes d’information et les bonnes pratiques de segmentation réseau, utiles pour cadrer un programme zero trust dans un contexte français, notamment le guide « Maîtriser la SSI – principes et bonnes pratiques » (2022) et le « Panorama de la menace informatique » (édition 2023).
- Gartner – Analyses sur les architectures zero trust, le ZTNA et la gestion des identités, avec des comparatifs de solutions et des retours d’expérience sectoriels, par exemple le « Market Guide for Zero Trust Network Access » (2023) ou les études sur l’Identity and Access Management.
- Forrester – Études sur le modèle de sécurité zero trust et les stratégies de réduction de la surface de protection, incluant des cas concrets d’entreprises ayant rationalisé leur architecture de sécurité, comme « The State Of Zero Trust Adoption In Europe » (2022) ou les rapports sur Zero Trust Edge.
