Tout le monde a entendu le slogan « ne faites confiance à rien ni personne ». Mais derrière la punchline, comment une petite structure normande peut-elle implémenter le Zero Trust sans se perdre dans la complexité ? L’ANSSI a publié en juin 2025 un document de référence — sous Licence Ouverte v2.0 — qui clarifie les fondamentaux, les bénéfices et les pièges du modèle. Nous en tirons ici une lecture opérationnelle, pensée pour les TPE/PME, illustrée par notre pratique de terrain.
Ce que le Zero Trust change… et ce qu’il ne change pas
Le cœur du Zero Trust est simple : réduire la confiance implicite quand un utilisateur, un équipement ou un service veut accéder à une ressource. Pour y arriver, les contrôles deviennent granulaires, dynamiques et réguliers : besoin d’en connaître, moindre privilège, mêmes contrôles depuis l’intérieur ou l’extérieur, et réévaluations au fil du temps. Autrement dit, on ne s’appuie plus sur le seul « réseau interne » comme périmètre de sécurité ; on évalue en continu le contexte (qui, quoi, où, quand, avec quel poste).
Attention toutefois : l’ANSSI ne présente pas le Zero Trust comme un remplacement des protections périmétriques, mais comme une brique de la défense en profondeur. Dans la vraie vie, on garde les bons réflexes (segmentation, pare-feu, supervision) et on ajoute cette couche d’évaluation continue pour limiter les impacts d’une compromission.
L’architecture en clair : PIP, PDP, PEP… et vos applications
Dans une approche Zero Trust, trois fonctions dialoguent pour décider si l’accès est autorisé. Le PIP (Policy Information Point) fournit les attributs : identité et rôle du sujet, sensibilité de la ressource, état du poste, localisation, horaire, niveau de menace. Le PDP (Policy Decision Point) évalue ces attributs et prend la décision selon les règles métier. Le PEP (Policy Enforcement Point) applique la décision sur le flux (ouvrir/refuser, imposer des conditions).
Le plan de contrôle calcule et impose les conditions d’accès ; le plan de données transporte les échanges applicatifs sous ces conditions. Concrètement : authentification, évaluation des attributs, établissement d’une session sécurisée, puis réauthentification et réévaluation périodiques.
Les briques indispensables à mettre en place d’abord
Identités et authentification. Chaque sujet (humain, service, équipement) doit être identifié de façon unique et prouver son identité avec des mécaniques fortes. Pour les utilisateurs, privilégiez l’authentification multifacteur et la protection matérielle des secrets (par exemple un jeton physique ou FIDO2), en évitant les mécanismes « passifs » peu robustes.
Postes et actifs. Un poste maîtrisé par l’entreprise n’a pas le même niveau de confiance qu’un BYOD. L’intégrité du démarrage (Secure/Measured Boot), les mises à jour centralisées, la liste d’applications autorisées et la détection type EDR contribuent au niveau de confiance de l’équipement, qui devient une condition d’accès essentielle dans un modèle Zero Trust.
Données et labels. Inventoriez et catégorisez vos données, puis appliquez-leur des attributs de sécurité (sensibilité, propriétaire, contraintes DIC) pour que les règles s’expriment finement : qui peut créer, lire, exporter, et dans quelles conditions. Sans ce travail, la politique d’accès reste théorique.
Règles d’accès et sessions. Les décisions s’appuient sur des critères de conformité (rôle, heure, lieu, posture du poste) et peuvent intégrer un score de confiance (comportements, détection de menaces). Ce score reste un complément, pas l’unique arbitre. Les sessions sont établies chiffrées, avec réauthentification et ajustements à la volée si le contexte se dégrade.
Accès réseau et applicatif : sélectionner le bon « chemin »
Sur le réseau, les approches de type Software-Defined Perimeter permettent d’ouvrir à la demande un tunnel vers des ressources précises, après authentification forte et calcul des conditions d’accès ; le filtrage s’appuie sur l’identité, pas uniquement sur l’IP. Côté applications exposées, un reverse-proxy Zero Trust contrôle l’accès après authentification, et peut ajouter des contrôles applicatifs (par exemple un WAF), sans imposer d’agent sur le poste — utile avec des partenaires ou des postes personnels. Dans les deux cas, la décision est pilotée par le plan de contrôle et reste réévaluable.
Au niveau données, l’objectif est d’imposer la labellisation à la création ou à l’import, de limiter l’export quand le contexte n’est pas sain, et au besoin de masquer dynamiquement certaines informations. Ces contrôles s’additionnent aux protections cryptographiques au repos et en transit.
Les limites à anticiper (et comment les gérer)
Deux risques reviennent souvent : la centralisation des décisions (une brique transverse désormais critique) et la qualité/actualité des attributs (si les sources sont indisponibles ou altérées, on bloque à tort… ou on laisse passer). S’ajoutent la justesse d’un score comportemental, l’interopérabilité entre éditeurs et l’impact performance de contrôles trop fins. Rien d’insurmontable, à condition de dimensionner les composants, de segmenter le plan de contrôle et de prévoir la montée en charge et la redondance.
C’est pour cela qu’une approche par les risques, des jalons réalistes, des campagnes de tests pour traquer les refus à tort et une organisation prête à accompagner les utilisateurs (support, messages, parcours d’escalade) sont indispensables.
Roadmap pragmatique pour une TPE/PME de Bayeux
Chez Guarde, nous démarrons par un état des lieux : actifs, identités, données, dépendances SaaS et contraintes réglementaires. Puis nous sélectionnons quelques cas d’usage à fort ROI sécurité (accès partenaires à un portail, télétravail vers l’ERP, administrateurs vers l’infra), avec une cartographie précise « qui accède à quoi, comment, quand ». On définit les attributs disponibles dès aujourd’hui (rôle, géo, heure, version de l’OS, conformité EDR), on documente leurs sources et leur fraîcheur, et l’on bâtit des règles de moindre privilège qui n’utilisent pas le score de confiance comme unique levier. Ensuite, on industrialise : SSO/MFA avec certificats, tunnel IPSec pour les accès à privilèges, proxy ou reverse-proxy Zero Trust pour les services publics, segmentation stricte entre plan de contrôle et plan de données. Et on mesure : latence, taux de refus, dérives, expérience utilisateur.
Cette démarche respecte des principes d’architecture simples : cloisonner le réseau, séparer administration et usages, sécuriser tous les échanges entre plan de données et plan de contrôle par canaux authentifiés et chiffrés, et répartir les services de décision pour éviter le point unique de défaillance.
Résultat attendu
À l’arrivée, vous conservez vos barrières classiques, mais vous ajoutez une grille de lecture « contexte-aware ». Le même utilisateur, sur la même application, obtient des décisions différentes si la demande vient d’un poste non conforme, d’un pays inattendu ou hors plage horaire. Vous réduisez la fenêtre d’attaque, limitez l’ampleur d’un incident et préparez votre entreprise aux exigences croissantes de vos clients et assureurs.
Mentions et source
Ce billet s’appuie sur le document « Modèle Zero Trust – Les fondamentaux » (version 1.0, 20/06/2025) publié par l’ANSSI sous Licence Ouverte v2.0. Nous en citons et reformulons les éléments clefs avec attribution, conformément aux conditions de réutilisation.
Envie d’aller plus loin ?
Guarde peut réaliser un diagnostic Zero Trust (attributs disponibles, règles cibles, choix proxy/SDP, jalons de déploiement), mettre en place MFA/SSO avec certificats, déployer un reverse-proxy Zero Trust pour vos applications exposées et vous accompagner dans la mise à jour continue des règles — sans sacrifier l’ergonomie terrain.
