Le Zero Trust n'est pas une solution que l'on achète, mais un modèle qui consiste à ne plus accorder de confiance implicite à un utilisateur, un poste ou une application du seul fait de sa position sur le réseau. Chaque accès à une ressource est évalué selon l'identité du sujet, l'état de son équipement, le contexte et la sensibilité de la ressource. Passer du concept à la pratique demande donc moins un grand projet d'infrastructure qu'une feuille de route progressive, construite cas d'usage par cas d'usage.
Les deux références les plus utiles pour cadrer cette démarche sont la publication spéciale 800-207 du NIST, qui pose l'architecture de référence, et les publications de l'ANSSI, qui en précisent les conditions de réussite et les risques. Leur lecture croisée conduit à une conclusion pragmatique : le Zero Trust est un complément de la défense en profondeur, pas son remplaçant, et une adoption mal maîtrisée peut affaiblir le système d'information au lieu de le renforcer.
Cet article résume ce que disent ces référentiels, les prérequis souvent sous-estimés et une méthode pour bâtir une feuille de route Zero Trust réaliste.
Ce que dit vraiment le NIST SP 800-207
Publiée en août 2020, la SP 800-207 définit le Zero Trust comme un ensemble de principes qui déplacent la défense des périmètres réseau étendus vers des ressources individuelles ou de petits groupes de ressources 1. Son point central est que ni la localisation réseau ni la propriété d'un équipement ne suffisent à accorder une confiance implicite : l'authentification du sujet et celle de l'équipement sont des étapes distinctes, réalisées avant l'établissement d'une session avec la ressource 1.
Le document décrit une architecture logique articulée autour de trois composants. Le moteur de politique (Policy Engine) prend la décision d'accès ; l'administrateur de politique (Policy Administrator) l'exécute en établissant ou en coupant la session ; le point d'application (Policy Enforcement Point) se place sur le chemin d'accès et applique la décision 1. Ces composants se nourrissent de sources d'information multiples : annuaire, état de conformité des postes, renseignement sur les menaces, journaux d'activité.
Cette architecture a une conséquence directe sur la feuille de route : la qualité des décisions dépend entièrement de la qualité des signaux. Un moteur de politique alimenté par un inventaire incomplet ou des attributs obsolètes prend de mauvaises décisions, rapidement et à grande échelle.
La position de l'ANSSI : un complément, pas un substitut
L'ANSSI a actualisé sa doctrine en juin 2025 avec deux documents : « Modèle Zero Trust – Les fondamentaux » (ANSSI-PA-111) et une synthèse dans la collection « Les Essentiels » 34. L'objectif affiché du modèle y est de « réduire la confiance implicite accordée à un sujet souhaitant accéder au système d'information » 3.
Le message le plus important est sans ambiguïté : le Zero Trust doit s'inscrire dans une défense en profondeur et « ne doit en aucun cas être vu comme un remplacement d'une défense périmétrique » 3. L'agence ajoute qu'il ne s'agit ni d'une technologie ni d'une solution clé en main, et que son adoption « doit être maîtrisée et progressive sous peine d'affaiblir le SI », avec le risque d'un faux sentiment de sécurité 4.
L'ANSSI recommande un contrôle d'accès fondé sur les attributs (ABAC), portant sur le sujet, la ressource et l'environnement, et précise que la politique doit reposer « uniquement sur la base d'attributs maîtrisés », c'est-à-dire dont l'organisation connaît la mise à jour, la couverture et la qualité 4. Elle identifie aussi les risques propres au modèle : centralisation des décisions, indisponibilité ou manque d'intégrité des attributs, faux positifs, dépendance aux éditeurs et impacts sur les performances 3.
Un moteur de politique alimenté par de mauvais attributs prend de mauvaises décisions, rapidement et à grande échelle.
Les prérequis qu'une feuille de route Zero Trust ne peut pas contourner
La plupart des difficultés rencontrées sur le terrain ne viennent pas des briques Zero Trust elles-mêmes, mais de fondations insuffisantes. Les fondamentaux de l'ANSSI en listent plusieurs, qui constituent de fait le socle de tout programme 34.
Cartographie et inventaire
L'ANSSI demande de définir, de manière itérative, la cartographie détaillée des composants du périmètre retenu et de dresser un inventaire de l'ensemble des actifs, en comparant l'état réel à l'état attendu : correctifs, configurations, vulnérabilités 3. Sans cet inventaire, l'évaluation de l'état de sécurité d'un poste est impossible.
Identités et authentification
Chaque accès doit être identifié de manière unique et authentifié, de préférence par certificat, et tout utilisateur doit disposer d'un second facteur, idéalement un jeton matériel 3. L'agence rappelle qu'« un fort niveau d'assurance sur l'identité de l'utilisateur est essentiel » 4. Le cycle de vie des comptes et des authentifiants doit être maîtrisé et progressivement automatisé 4.
Administration et équipements
Les accès d'administration doivent passer par des postes à haut niveau de confiance et une chaîne d'accès distincte de celle des utilisateurs 3. Les équipements personnels sont à considérer par défaut comme de faible confiance, avec des accès limités aux services non critiques 3.
Supervision
Une supervision de sécurité à faible taux de faux positifs et de faux négatifs est présentée comme un prérequis à toute décision d'accès dynamique 4. Un signal de compromission qui n'arrive pas, ou qui arrive noyé dans le bruit, ne peut pas alimenter le moteur de politique.
Construire la feuille de route par cas d'usage
L'ANSSI recommande une trajectoire progressive, ciblée sur les cas d'usage pour lesquels le modèle répond à un objectif de sécurité précis : qui accède, dans quels contextes, à quelles ressources 4. Elle demande de définir des jalons intermédiaires, de réévaluer l'efficacité à chaque itération et de tester la sécurité et le fonctionnement avant la mise en production, pendant une durée suffisante 34. Une feuille de route réaliste peut s'organiser ainsi :
- Choisir deux ou trois cas d'usage à forte valeur : accès distant des prestataires à une application métier, administration des environnements cloud, accès des collaborateurs nomades à la messagerie et aux outils collaboratifs.
- Pour chaque cas, décrire les sujets, les ressources, les flux et les attributs disponibles, en vérifiant leur fiabilité avant de les utiliser dans une politique.
- Combler les prérequis manquants : inventaire des postes concernés, authentification forte, postes d'administration dédiés, remontée des journaux au SOC.
- Déployer le point d'application devant la ressource en mode observation, comparer les décisions simulées aux accès réels, puis passer en mode bloquant.
- Mesurer : part des accès évalués par la politique, taux de refus injustifiés, délai de révocation d'un accès, disponibilité du point de décision.
- Retirer les accès hérités (VPN à plat, règles de pare-feu trop larges) uniquement lorsque le nouveau chemin est stable, et seulement pour le périmètre concerné.
Le NIST fournit des exemples concrets de mise en œuvre. Son guide pratique SP 1800-35, publié dans sa version finale en juin 2025, documente 19 implémentations d'architectures Zero Trust réalisées avec 24 éditeurs, et rattache les capacités de sécurité au Cybersecurity Framework et au catalogue SP 800-53 2. Ces implémentations sont utiles pour comparer des choix d'intégration plutôt que pour copier une architecture clé en main.
Gouvernance et pièges à éviter
Le premier piège est de traiter le moteur de décision comme un composant ordinaire. L'ANSSI souligne qu'il devient une dépendance transverse, susceptible d'être critique pour le fonctionnement ou la sécurité du SI, et recommande des mécanismes de redondance et de synchronisation des états sur le plan de contrôle, ainsi qu'une segmentation de ces services par type d'usage 3. Sa compromission ou son indisponibilité doivent figurer dans l'analyse de risques et dans le plan de continuité.
Le deuxième piège est la dépendance à un éditeur unique. Une architecture Zero Trust touche l'identité, le poste, le réseau et les applications : verrouiller l'ensemble dans un seul écosystème simplifie l'intégration initiale mais réduit la capacité à faire évoluer chaque brique. Le choix de standards ouverts pour les identités, les journaux et les politiques limite ce risque.
Le troisième piège est organisationnel. Une politique d'accès dynamique engage les équipes réseau, poste de travail, identité, applications et SOC. Sans un responsable clairement désigné pour la politique d'accès et un comité qui arbitre les exceptions, les règles s'accumulent et la confiance implicite revient par la porte des dérogations.
Conclusion
Le Zero Trust est un changement de modèle de contrôle d'accès qui s'inscrit dans la durée. Les organisations qui réussissent commencent par fiabiliser l'inventaire, les identités et la supervision, choisissent quelques cas d'usage mesurables et étendent le périmètre à mesure que les signaux gagnent en qualité, sans démanteler prématurément leurs défenses périmétriques. DATASWING accompagne ses clients dans ce cadrage, en s'appuyant sur les référentiels du NIST et de l'ANSSI.
— Questions fréquentes
Ce qu'on nous demande souvent
Le Zero Trust remplace-t-il le pare-feu et le VPN ?+
Non. L'ANSSI indique explicitement que le Zero Trust ne doit en aucun cas être vu comme un remplacement de la défense périmétrique, mais comme un complément inscrit dans une défense en profondeur. Les VPN et règles de pare-feu peuvent être réduits progressivement pour les cas d'usage migrés, une fois le nouveau chemin d'accès stable et supervisé, mais le filtrage périmétrique conserve son rôle.
Par où commencer une démarche Zero Trust ?+
Par les prérequis et un cas d'usage limité. Il faut d'abord fiabiliser l'inventaire des actifs, l'authentification multifacteur et la supervision, puis choisir un scénario précis, comme l'accès des prestataires à une application ou l'administration du cloud. Ce premier cas permet de valider les attributs, l'outillage et la gouvernance avant d'étendre le modèle à d'autres périmètres.
Qu'est-ce que le NIST SP 800-207 ?+
C'est la publication du NIST, parue en août 2020, qui définit l'architecture Zero Trust de référence. Elle pose le principe d'absence de confiance implicite liée à la localisation réseau ou à la propriété d'un équipement, et décrit les composants logiques de décision et d'application des politiques d'accès, ainsi que des modèles de déploiement et des cas d'usage.
Combien de temps dure un projet Zero Trust ?+
Il n'existe pas de durée type, car le Zero Trust n'est pas un projet à date de fin mais une trajectoire. La durée dépend de la maturité de l'inventaire, des identités et de la supervision, et du nombre de cas d'usage visés. L'ANSSI recommande de fixer des jalons intermédiaires et de réévaluer l'efficacité à chaque itération plutôt que de viser une bascule globale.
— Sources
Références citées
Les textes réglementaires et documentations évoluent : vérifiez la version en vigueur avant toute décision. Cet article n'est pas un avis juridique.
-
[1]
SP 800-207, Zero Trust Architecture ↗NIST · 2020-08
- [2]
-
[3]
Modèle Zero Trust – Les fondamentaux (ANSSI-PA-111, v1.0) ↗ANSSI · 2025-06
-
[4]
Les Essentiels – Modèle Zero Trust (v1.0) ↗ANSSI · 2025-06
