Tous les éditeurs vendent du Zero Trust maintenant. La plupart vendent autre chose sous ce nom. Après avoir vu trois banques et deux opérateurs télécom au Maghreb monter des programmes Zero Trust ces dix-huit derniers mois, nous avons une vision nette de quel cadrage produit vraiment l'amélioration de sécurité que les gens pensaient acheter, et lequel n'est qu'un VPN rebaptisé.
Cet article expose la lecture d'un praticien : ce que Zero Trust exige vraiment au niveau architectural, ce que le paysage des outils ZTNA fournit actuellement, les trois modes d'échec qu'on a vus partir en production, et les éléments spécifiques au contexte marocain et maghrébin qui changent le déploiement.
Le piège du cadrage
L'idée originelle de Zero Trust, formulée par Forrester en 2010 et matérialisée par BeyondCorp dans les années qui ont suivi, est structurelle : cesser de faire confiance au réseau. Remplacer l'accès basé sur la localisation (vous êtes sur le LAN d'entreprise, donc vous pouvez parler à la base de données) par un accès basé sur l'identité et le contexte (cet utilisateur précis, sur ce terminal précis, avec cette posture précise, peut faire cette requête précise vers cette ressource précise).
C'est un changement profond. Il exige :
- Une identité forte du terminal (chaque appareil possède une identité cryptographique, pas « est sur le VPN »)
- Une identité forte de l'utilisateur (SSO avec MFA résistant au phishing, pas nom-d'utilisateur + mot-de-passe + SMS)
- Une autorisation par requête (chaque appel d'API, chaque connexion de base de données, chaque récupération de fichier passe par un point de décision de politique)
- Une évaluation continue de la posture (si le terminal s'écarte de la conformité, l'accès se réduit ou se révoque)
- Un transport chiffré partout, y compris à l'intérieur du réseau
Ce que la plupart des éditeurs vendent aujourd'hui comme Zero Trust, c'est le point 3 seul, restreint à « nous intermédierons les requêtes HTTP au niveau de notre passerelle et vérifierons un token OIDC ». C'est utile. Ce n'est pas Zero Trust. C'est un proxy d'entrée délivré en SaaS, ce qui est nettement meilleur qu'un VPN pour le cas précis de « application web interne accessible depuis l'extérieur », et à peu près équivalent à un VPN pour tout le reste.
Si un éditeur vous pitche du « Zero Trust » et que le démo est une page de connexion SSO bien finie, vous regardez le proxy. Demandez-lui comment il gère la posture de l'appareil pour une connexion SSH, une connexion Postgres depuis le portable d'un développeur, et un appel gRPC de service à service à l'intérieur de votre VPC. Si la réponse est « ce n'est pas dans le périmètre », vous regardez un remplaçant de VPN.
Ce que fait vraiment le paysage actuel des éditeurs
Les outils que nous avons évalués ou fait tourner en production sur des projets maghrébins :
| Outil | Ce que c'est réellement | Là où il prend sa valeur |
|---|---|---|
| Cloudflare Access | Proxy HTTPS conscient de l'identité, plus lanceur d'applications | Applications web internes pour équipes distribuées. Bon marché. Mise en place en quelques heures. |
| Zscaler Private Access | Proxy conscient de l'identité pour HTTP, TCP et UDP | Grandes entreprises avec mandat ZT explicite. Cher. |
| Tailscale | Maillage WireGuard avec identité et ACL | Accès des développeurs à l'infrastructure. Petites équipes. Se rapproche de la forme BeyondCorp via les ACL et le tagging. |
| Twingate | Maillage conscient de l'identité avec moteur de politique | Taille moyenne. Hybride maillage et proxy. |
| Cisco Duo et ISE | MFA et contrôle d'accès réseau | Si vous faites déjà tourner du Cisco en périphérie, la couche ZT s'étend naturellement. |
| AWS Verified Access | Vérification d'identité par requête pour les applications derrière ALB | Boutiques AWS-natives. Périmètre limité. |
| Google BeyondCorp Enterprise | Le plus proche de l'article BeyondCorp original | Complet, mais engagement écosystème Google. |
| OpenZiti | Réseau de recouvrement open source avec identité | Auto-hébergé, communauté en croissance. L'option non-éditeur. |
| Teleport | Proxy conscient de l'identité pour SSH, Postgres, Kubernetes, web | Excellent pour l'accès développeur vers l'infrastructure. La piste d'audit est très bonne. |
Notez ce qui manque dans ce tableau : la posture de l'appareil est universellement sous-implémentée. Cloudflare Access peut vérifier quelques signaux via WARP. Zscaler fait de la posture via ZCC. Tailscale fait de l'autorisation de base sur l'appareil. Mais « ce Mac a FileVault activé ET un niveau de patch à jour ET aucun logiciel risqué installé ET le certificat WireGuard a été émis par notre MDM », c'est quelque chose que personne dans ce tableau ne fait de bout en bout sans MDM séparé (Jamf, Kandji, Intune, Microsoft 365 Endpoint Manager).
L'architecture réaliste de 2026 pour un déploiement sérieux, c'est : couche d'identité (Entra ID, Okta, ou Keycloak auto-hébergé), plus MDM pour la posture (Jamf pour Mac, Intune pour Windows, éventuellement Kandji ou Mosyle), plus outil ZTNA pour l'accès aux applications (l'un de ceux ci-dessus), plus service mesh (Istio, Linkerd, ou Consul Connect) pour l'authentification interne service-à-service, plus secret manager (HashiCorp Vault, AWS Secrets Manager, ou 1Password Business) pour les credentials dont les machines ont encore besoin.
Cela fait cinq catégories d'éditeurs. Quiconque vous dit couvrir tout cela sous une seule marque Zero Trust ment ou vous vend chaque pièce de manière fine.
Ce qui fonctionne dans la banque maghrébine
Les banques marocaines et tunisiennes ont des contraintes spécifiques qui changent la forme du déploiement : pression réglementaire de BAM et de la BCT sur la localisation des données personnelles, réalité opérationnelle où la banque d'agence compte toujours (chaque agence régionale a son réseau), systèmes de core banking hérités qui n'ont pas vu de revue de sécurité depuis leur déploiement de 2008, et le fait que les contrôles physiques (lecteurs de badge, vidéosurveillance) sont encore considérés comme la sécurité de première ligne plutôt que la ligne secondaire qu'ils sont devenus ailleurs.
Trois choses que nous avons vu fonctionner réellement :
1. Déploiement par phases en commençant par l'accès distant. La victoire Zero Trust la plus rapidement crédible, c'est de remplacer le VPN hérité des collaborateurs en télétravail par un proxy ZTNA. Cloudflare Access plus Microsoft Entra ID, c'est un déploiement de 6 semaines pour une banque régionale typique, à environ 7-12 USD par utilisateur et par mois, et cela réduit la surface d'attaque de façon mesurable. Ce n'est pas du Zero Trust complet. C'est une vraie victoire, et cela débloque le budget de la phase suivante.
2. L'identité d'abord, le réseau ensuite. Le plus grand gain unique en posture de sécurité vient de faire enrôler un MFA résistant au phishing sur tous les comptes privilégiés : clés de sécurité FIDO2 pour l'équipe d'administration IT, application Microsoft Authenticator avec number matching pour le reste, aucun fallback SMS nulle part. Cela apporte plus d'amélioration de sécurité que la refonte réseau, plus rapidement, et c'est de toute façon un prérequis pour le reste du programme.
3. Authentification service-à-service auditable avant service mesh. Avant d'introduire un service mesh, atteignez l'état où chaque appel interne service-à-service utilise une identité de charge de travail courte (SPIFFE, rôles IAM AWS, comptes de service GCP) plutôt que des clés d'API longue durée. C'est atteignable en 3-4 mois avec de la discipline. Un service mesh posé sur des clés partagées longue durée n'est pas du Zero Trust, c'est un VPN plus complexe.
Trois modes d'échec qu'on a vus partir en production
Mode d'échec 1 : le proxy fait le mur.
L'équipe achète Cloudflare Access, place l'application RH interne derrière, déclare le Zero Trust complet. Deux mois plus tard, un attaquant phishe le cookie de session d'un développeur, atterrit dans le proxy en tant que ce développeur, et atteint tout ce que ce développeur pouvait atteindre. Ce qui est tout, parce que l'autorisation par requête n'a jamais été construite. Le proxy a authentifié, il n'a pas autorisé ressource par ressource.
Le correctif : chaque ressource protégée a besoin de sa propre politique d'autorisation, exprimée dans les termes que le proxy peut évaluer (attributs de l'utilisateur, posture de l'appareil, forme de la requête) et mise à jour quand la sensibilité de la ressource change. Le proxy est le point de décision de politique, pas la politique.
Mode d'échec 2 : le MDM ment.
La posture de l'appareil vient du MDM. Le MDM rapporte le dernier check-in de l'appareil, le niveau de patch rapporté à ce check-in, et l'état de conformité que le MDM a évalué contre ses propres règles. Trois de ces éléments sont de l'information de seconde main. Un appareil qui était conforme il y a 3 heures et vient de télécharger une extension navigateur malveillante est rapporté conforme jusqu'au prochain cycle de check-in, qui est dans 4-24 heures.
Le correctif : intervalles de check-in courts (15-30 minutes), signaux hors-bande de l'EDR (CrowdStrike, SentinelOne, Microsoft Defender for Endpoint) alimentant la décision d'accès, et une règle dure : tout signal de posture vieux de plus d'une heure force une ré-authentification.
Mode d'échec 3 : la piste d'audit que personne ne lit.
Les outils ZTNA produisent d'excellents logs. Décisions d'accès par requête, contexte d'identité, contexte d'appareil, tentatives refusées, patterns suspects. Ces logs s'accumulent à plusieurs gigaoctets par jour pour une organisation de taille moyenne et finissent dans un SIEM que personne n'interroge jusqu'à ce qu'un auditeur le demande.
Le correctif : au minimum, revue automatisée hebdomadaire des patterns d'accès refusé (un utilisateur authentique refusé est un signal de mauvaise configuration ; une identité anormale refusée est un signal d'attaque). Mieux : un petit ensemble de règles de corrélation SIEM qui se déclenchent sur les patterns qui comptent (tentatives d'escalade de privilège, accès géographique anormal pour un compte, multiples établissements de session depuis des appareils différents dans une courte fenêtre). Wazuh est gratuit et capable ; pour du payant, Sentinel et Splunk font tourner ces règles correctement.
Ce que cela signifie pour vous
Si vous êtes au début d'un programme Zero Trust : choisissez une application, déployez un proxy conscient de l'identité devant, imposez du MFA résistant au phishing sur la couche d'identité, et faites tourner pendant deux mois. Vous apprendrez plus sur votre environnement avec ce seul déploiement qu'avec six mois de schémas d'architecture. Utilisez cet apprentissage pour planifier la phase deux.
Si vous êtes en milieu de programme et découvrez que le pitch de l'éditeur a survendu la couverture : c'est normal. Construisez l'analyse explicite des manques (nous avons l'identité, nous avons l'accès proxy pour HTTP, nous n'avons pas la posture, nous n'avons pas l'authentification service-à-service) et budgétisez la phase suivante contre les manques réels, pas contre le pitch du prochain éditeur.
Si on vous demande s'il faut acheter Zero Trust X ou Zero Trust Y pour votre organisation : la question est mauvaise. La question est laquelle des cinq catégories (identité, MDM, ZTNA, service mesh, gestion de secrets) vous avez aujourd'hui et laquelle il vous faut ensuite. Choisissez la catégorie suivante, puis choisissez l'éditeur à l'intérieur.
Ce qu'on a fait de travers
Nous avons, sur au moins deux missions, traité Zero Trust comme un problème principalement réseau. C'est principalement un problème d'identité et de politique, avec une couche réseau en bas. Les équipes qui livrent les implémentations les plus propres commencent par le côté identité et descendent. Les équipes qui peinent le plus longtemps commencent par le côté réseau et essaient d'y rétrofitter l'identité.
La leçon de 2026 n'est pas nouvelle. Elle était dans l'article BeyondCorp original. Nous avons juste eu à la réapprendre.