En 2021, une organisation sur deux déclarait avoir « lancé son initiative Zero Trust ». En 2026, selon le rapport Forrester State of Zero Trust, 42 % d'entre elles ont une architecture incomplète — identité traitée, réseau non segmenté ; ou microsegmentation déployée, mais MFA contournable sur les accès machines. Ce n'est pas un état d'avancement acceptable. Les données l'indiquent clairement : les organisations à mi-parcours Zero Trust présentent un profil d'exposition plus dégradé que celles qui n'ont pas encore commencé. L'explication tient en une ligne — et en trois angles morts que cet article décrit.
Le contexte : Zero Trust n'est pas un produit, c'est une posture cohérente
Zero Trust est entré dans le vocabulaire de la sécurité enterprise au tournant des années 2010. Le modèle de John Kindervag (Forrester, 2010) et les publications NIST SP 800-207 (2020) ont donné un cadre formel à ce qui était jusqu'alors une intention diffuse. Le principe est simple : ne jamais faire confiance implicitement à un flux, un utilisateur, un appareil — même à l'intérieur du périmètre réseau. Vérifier explicitement, appliquer le moindre privilège, supposer la compromission.
Ce qui s'est passé dans la pratique est prévisible : les éditeurs ont transformé le principe en catalogue de produits. Identity Zero Trust (MFA, SSO, ZTNA), Network Zero Trust (microsegmentation, SD-WAN sécurisé), Device Zero Trust (EDR, MDM, posture checks), Data Zero Trust (DLP, chiffrement granulaire). Les organisations ont acheté. Elles ont déployé. Rarement en cohérence.
Le résultat structurel : une architecture hybride où les hypothèses de confiance de l'ancien monde coexistent avec les contrôles du nouveau. Et c'est précisément dans cette coexistence que les attaquants trouvent leur route.
Angle mort 1 : la microsegmentation sans inventaire des flux est aveugle
La microsegmentation — diviser le réseau en zones étroites avec des politiques de contrôle d'accès granulaires — est l'un des piliers les plus cités d'une architecture Zero Trust. Elle est aussi l'une des plus mal implémentées.
Le problème n'est pas technique. Il est opérationnel. Dans la quasi-totalité des déploiements de microsegmentation que nous observons en mission, la phase d'inventaire des flux légitimes n'a pas été conduite suffisamment en amont. Les politiques ont été construites sur des hypothèses héritées de l'architecture historique — et les exceptions se sont accumulées. En 2025, une étude Illumio portant sur 1 000 responsables sécurité enterprise montre que 67 % des organisations ayant déployé une microsegmentation ont maintenu des zones d'exception non documentées représentant plus de 20 % de leur trafic est-ouest.
Concrètement, cela signifie qu'un attaquant qui compromet un endpoint dans une zone "segmentée" peut, dans 67 % des cas, atteindre au moins un système critique via une exception non révisée. La segmentation a créé une illusion de contrôle — pas un contrôle effectif.
L'erreur courante à éviter : déployer la segmentation à partir d'un modèle théorique sans cartographier les flux réels observés pendant au minimum 30 jours. Ce que font les organisations matures : commencer par une phase d'observation en mode journalisation complète, puis construire les politiques à partir des données réelles.
Angle mort 2 : l'identité forte ne couvre pas les comptes non-humains
L'identité est souvent le premier chantier lancé dans un déploiement Zero Trust, parce que c'est le plus visible et le plus vendable. MFA renforcé, SSO, conditional access basé sur la posture de l'appareil. C'est bien. C'est insuffisant si les comptes de service, d'application, et d'infrastructure continuent à opérer avec des credentials statiques à privilèges élevés.
Les données sont sans ambiguïté. L'enquête Mandiant M-Trends 2025 montre que 58 % des compromissions initiales réussies passent par des identifiants de comptes de service ou d'administration. Ces comptes ne bénéficient presque jamais du MFA (contraintes techniques de compatibilité). Ils n'entrent pas dans le scope des politiques de conditional access. Ils sont souvent documentés dans des configurations qui persistent des années après leur création.
Une organisation accompagnée en 2025 avait déployé un programme Identity Zero Trust exemplaire pour ses 2 400 utilisateurs humains — MFA TOTP, ZTNA pour les accès distants, revue trimestrielle des accès. Lors de l'audit, nous avons identifié 147 comptes de service actifs, dont 38 % avec des droits administrateurs locaux non documentés. Un seul de ces comptes, utilisé par une application legacy de gestion de parc, avait accès en lecture à l'Active Directory complet. L'initiative Zero Trust "identité" ne les avait pas touchés.
L'erreur courante à éviter : traiter le périmètre MFA comme étant le périmètre Zero Trust pour l'identité. Les comptes non-humains représentent souvent 3 à 5 fois le nombre de comptes humains dans un environnement mid-market. Leur inventaire et leur gouvernance sont le chantier qui révèle l'état réel du programme.
Angle mort 3 : le Zero Trust documenté et le Zero Trust opéré sont deux organisations différentes
Le troisième angle mort est celui que les audits réglementaires NIS2 et DORA commencent à documenter systématiquement : l'écart entre la politique Zero Trust validée par le COMEX et la réalité opérationnelle de son application quotidienne.
Cet écart se manifeste concrètement. Une politique de conditional access prévoit que tout accès depuis un appareil non-managé est refusé. Dans la pratique, une exception a été accordée en urgence pour un prestataire il y a 14 mois — et n'a pas été révoquée. Une politique de microsegmentation interdit les flux directs entre la zone de production et la zone de développement. Dans la pratique, un pipeline CI/CD a besoin de cet accès depuis 8 mois — et l'exception n'a pas de date d'expiration.
La CISA a publié en mars 2026 une analyse sur les architectures Zero Trust de 62 agences fédérales américaines. Conclusion : 71 % avaient une documentation ZT à jour ; 43 % avaient des exceptions non-tracées représentant des écarts significatifs entre la politique et le déploiement réel. Le ratio politique/réalité est le vrai indicateur de maturité — pas le score de conformité documentaire.
Ce qui distingue le Zero Trust opéré du Zero Trust documenté : la révision périodique des exceptions (trimestrielle au minimum), l'expiration automatique des dérogations dans les outils (pas dans les documents), et la capacité à répondre en moins d'une heure à la question "quels flux sont actuellement autorisés en dehors de la politique standard". Si cette réponse nécessite une investigation, le programme est documenté, pas opéré.
Évaluer votre maturité Zero Trust réelle en trois questions
Avant d'investir dans une couche technologique supplémentaire, posez-vous ces trois questions. Premièrement : pouvez-vous lister, en moins de 30 minutes, toutes les exceptions actives à vos politiques Zero Trust, avec leur justification et leur date d'expiration ? Deuxièmement : votre inventaire des identités non-humaines (comptes de service, d'application, d'automatisation) est-il à jour et lié à votre programme de gouvernance des accès ? Troisièmement : quel était le dernier flux est-ouest documenté entre vos zones de microsegmentation — et avez-vous la certitude qu'il était prévu par votre politique ?
Si l'une de ces réponses est "non" ou "je ne sais pas", vous êtes dans la configuration de risque aggravé décrite en introduction. Le prochain investissement utile n'est pas un nouvel outil — c'est un audit de cohérence de l'existant. Valtieri accompagne les organisations dans ces diagnostics d'architecture Zero Trust, avec une intégration dans la posture de conformité NIS2 et DORA. Voir aussi : les vecteurs d'attaque dominants en PME et la checklist NIS2 pour votre organisation. 30 minutes pour qualifier votre état actuel.
Conclusion
Trois insights à retenir. La microsegmentation sans inventaire des flux réels crée une illusion de contrôle, pas un contrôle effectif — l'observation précède la politique. L'identité forte ne couvre que les humains dans la majorité des déploiements ; les comptes non-humains représentent la surface d'attaque que les programmes Zero Trust n'ont pas encore touchée. Enfin, l'écart entre la politique Zero Trust documentée et son application opérationnelle est le vrai indicateur de maturité — une exception non-tracée annule partiellement la valeur de l'architecture qui l'entoure.
Les organisations qui sortiront du mi-parcours Zero Trust ne sont pas celles qui achèteront la prochaine couche technologique. Ce sont celles qui auditeront l'écart entre ce qu'elles ont documenté et ce qu'elles opèrent réellement — et qui fermeront les exceptions avant que celles-ci ne deviennent le chemin d'entrée d'un incident.
Et dans votre contexte : si un attaquant compromettait aujourd'hui un endpoint dans votre zone "la plus sécurisée", combien de systèmes critiques pourrait-il atteindre via des exceptions non-révisées ? Parlons-en.