Les trois erreurs de d\u00e9ploiement SASE les plus fr\u00e9quentes consistent \u00e0 traiter la migration comme un \u00e9change d’outils plut\u00f4t que comme un changement d’architecture, \u00e0 copier les r\u00e8gles d’acc\u00e8s VPN h\u00e9rit\u00e9es dans un mod\u00e8le ZTNA sans les repenser, et \u00e0 laisser fonctionner l’ancienne infrastructure \u00ab\u00a0au cas o\u00f9\u00a0\u00bb longtemps apr\u00e8s qu’elle aurait d\u00fb \u00eatre mise hors service. Chaque cas ajoute des mois au calendrier et \u00e9rode les gains de s\u00e9curit\u00e9 qui justifiaient le projet en premier lieu. <\/p>\n
Apr\u00e8s avoir aid\u00e9 des dizaines d’entreprises de taille moyenne \u00e0 d\u00e9ployer SASE, trois erreurs de d\u00e9ploiement de SASE se r\u00e9p\u00e8tent. Il ne s’agit pas de cas techniques exceptionnels. Il s’agit de sch\u00e9mas organisationnels qui transforment un projet de six semaines en un projet de six mois. Au d\u00e9but de l’ann\u00e9e, nous avons \u00e9crit sur les 10 erreurs les plus courantes en mati\u00e8re de ZTNA<\/a>. La liste qui suit est plus large. Il s’agit des sch\u00e9mas qui bloquent des programmes SASE entiers, et pas seulement des configurations ZTNA. <\/p>\n L’erreur la plus pr\u00e9judiciable se produit avant la r\u00e9daction de la premi\u00e8re politique. Les \u00e9quipes abordent le SASE comme un achat de produit et non comme un changement d’architecture. Elles le placent \u00e0 c\u00f4t\u00e9 des pare-feu et des VPN existants, comme une couche suppl\u00e9mentaire, plut\u00f4t que comme le remplacement de la plupart d’entre eux. <\/p>\n C’est ce que nous avons constat\u00e9 r\u00e9cemment avec une entreprise de logistique de 200 utilisateurs. Son responsable informatique a achet\u00e9 une licence SASE, l’a configur\u00e9e parall\u00e8lement \u00e0 son cluster de pare-feu existant et a commenc\u00e9 \u00e0 acheminer une partie du trafic via la nouvelle plateforme. Six mois plus tard, il utilisait les deux syst\u00e8mes en parall\u00e8le, payait pour les deux et g\u00e9rait les politiques dans deux consoles. Le dispositif de s\u00e9curit\u00e9 avait \u00e0 peine chang\u00e9, car personne n’avait d\u00e9cid\u00e9 quel syst\u00e8me faisait autorit\u00e9. <\/p>\n Ce sch\u00e9ma est plus courant que ne l’admettent la plupart des fournisseurs. L’\u00e9tude de Gartner sugg\u00e8re que moins d’une organisation sur dix tire la pleine valeur de son investissement SASE. La raison n’est presque jamais la technologie. C’est l’incapacit\u00e9 \u00e0 consid\u00e9rer le SASE comme un projet de consolidation plut\u00f4t que comme un ajout. <\/p>\n La solution commence avant la passation des march\u00e9s. D\u00e9finissez les outils que SASE va remplacer et non compl\u00e9ter. Cartographiez votre stack actuel, vos firewalls, concentrateurs VPN, passerelles web, SD-WAN autonomes, et marquez chacun d’entre eux avec une date cible de mise \u00e0 la retraite. Si vous ne pouvez pas nommer ce que SASE remplace, vous ajoutez de la complexit\u00e9 au lieu de la supprimer. L’article intitul\u00e9 \u00a0\u00bb Escaping the Frankenstack\u00a0\u00bb<\/a> d\u00e9crit en d\u00e9tail cette logique de consolidation. <\/p>\n Conseil pratique : avant de signer quoi que ce soit, \u00e9crivez une phrase qui compl\u00e8te \u00ab\u00a0apr\u00e8s le d\u00e9ploiement complet de SASE, nous n’aurons plus besoin de ______\u00a0\u00bb. Si cette phrase est difficile \u00e0 \u00e9crire, prenez du recul et revoyez votre plan d’architecture. <\/p>\n La deuxi\u00e8me erreur est plus subtile. Les \u00e9quipes migrent leur ancien pare-feu et leurs r\u00e8gles d’acc\u00e8s VPN directement dans le nouveau mod\u00e8le ZTNA. L'\u00a0\u00bb\u00e9quipe financi\u00e8re\u00a0\u00bb b\u00e9n\u00e9ficie du m\u00eame acc\u00e8s \u00e9tendu que celui qu’elle avait par le biais du tunnel VPN. Les \u00ab\u00a0travailleurs \u00e0 distance\u00a0\u00bb h\u00e9ritent des m\u00eames politiques de groupe. L’ancienne structure de permission re\u00e7oit une nouvelle \u00e9tiquette. Rien ne change en r\u00e9alit\u00e9. <\/p>\n C’est le pi\u00e8ge du \u00ab\u00a0lift-and-shift\u00a0\u00bb. Il donne l’impression d’\u00eatre efficace parce qu’il permet d’\u00e9viter les conversations difficiles sur qui a vraiment besoin d’acc\u00e9der \u00e0 quoi. Mais il va \u00e0 l’encontre de l’objectif de la confiance z\u00e9ro. Un compte compromis dans un d\u00e9ploiement ZTNA \u00ab\u00a0lift-and-shift\u00a0\u00bb a le m\u00eame rayon d’action qu’un compte VPN compromis, c’est-\u00e0-dire beaucoup trop large. <\/p>\n Le probl\u00e8me le plus profond est g\u00e9n\u00e9ralement l’encrassement des donn\u00e9es d’identit\u00e9. La plupart des entreprises de taille moyenne ont des fournisseurs d’identit\u00e9 remplis de membres de groupes p\u00e9rim\u00e9s, de permissions h\u00e9rit\u00e9es et de comptes de service g\u00e9n\u00e9riques que personne n’a audit\u00e9s depuis des ann\u00e9es. Brancher ce d\u00e9sordre sur une plateforme ZTNA ne fait que num\u00e9riser le dysfonctionnement. Les donn\u00e9es de l’industrie montrent r\u00e9guli\u00e8rement que les probl\u00e8mes d’hygi\u00e8ne de l’identit\u00e9 sont parmi les principales causes d’\u00e9chec du contr\u00f4le d’acc\u00e8s, et qu’ils sont tout \u00e0 fait \u00e9vitables. <\/p>\n La solution comporte quatre \u00e9tapes. Premi\u00e8rement, assainissez votre fournisseur d’identit\u00e9 avant la migration. Supprimez les comptes p\u00e9rim\u00e9s, v\u00e9rifiez l’appartenance aux groupes et alignez les groupes sur les r\u00f4les r\u00e9els de l’entreprise. Deuxi\u00e8mement, associez les utilisateurs aux applications, et non aux r\u00e9seaux. Posez la question suivante : \u00ab\u00a0Quelles sont les trois applications utilis\u00e9es quotidiennement par cette personne ?\u00a0\u00bb plut\u00f4t que \u00ab\u00a0De quel segment de r\u00e9seau a-t-elle besoin ?\u00a0\u00bb. Troisi\u00e8mement, commencez par des applications en lecture seule et \u00e0 faible risque dans votre projet pilote. Un wiki ou un syst\u00e8me de chronom\u00e9trage permet \u00e0 votre \u00e9quipe d’apprendre le mod\u00e8le avant que les enjeux ne soient \u00e9lev\u00e9s. Quatri\u00e8mement, activez les contr\u00f4les de posture des appareils d\u00e8s le premier jour. En les omettant pendant le projet pilote, ce que de nombreuses \u00e9quipes font pour r\u00e9duire les frictions, vous entra\u00eenez les utilisateurs \u00e0 s’attendre \u00e0 un acc\u00e8s sans validation de s\u00e9curit\u00e9. <\/p>\n Ce dernier point est plus important qu’il n’y para\u00eet. Une fois que vous avez \u00e9tabli le pr\u00e9c\u00e9dent selon lequel les appareils non g\u00e9r\u00e9s ont le m\u00eame acc\u00e8s que les appareils g\u00e9r\u00e9s, revenir sur cette attente devient un combat politique. Faites-le correctement d\u00e8s le d\u00e9part. <\/p>\n Pour un examen plus approfondi de la mani\u00e8re dont les fournisseurs d’identit\u00e9 s’int\u00e8grent \u00e0 l’acc\u00e8s Zero Trust<\/a>, ce guide couvre les mod\u00e8les d’int\u00e9gration sp\u00e9cifiques qui permettent d’\u00e9viter cette erreur.<\/p>\n La troisi\u00e8me erreur est celle qui, tout en se sentant responsable, sape discr\u00e8tement tout ce qui se passe. Les \u00e9quipes terminent le d\u00e9ploiement de SASE. Les utilisateurs sont connect\u00e9s via ZTNA. Les politiques fonctionnent. Puis quelqu’un dit : \u00ab\u00a0Gardons l’ancienne passerelle VPN comme solution de repli. Juste au cas o\u00f9\u00a0\u00bb. <\/p>\n Des mois plus tard, le VPN est toujours actif. Les anciennes r\u00e8gles du pare-feu existent toujours. Les serveurs de saut qui \u00e9taient cens\u00e9s \u00eatre mis hors service sont toujours accessibles. Chacun d’entre eux est une voie d’acc\u00e8s non surveill\u00e9e qui contourne tous les contr\u00f4les de confiance z\u00e9ro que vous venez de mettre en place. <\/p>\n Nous avons vu cela dans presque tous les engagements. Le raisonnement semble toujours prudent. \u00ab\u00a0Que se passe-t-il si la nouvelle plateforme est en panne ?\u00a0\u00bb \u00ab\u00a0Et si nous devions revenir en arri\u00e8re ?\u00a0\u00bb Mais le calcul du risque est \u00e0 l’envers. Un concentrateur VPN dormant avec un firmware p\u00e9rim\u00e9 et des r\u00e8gles d’acc\u00e8s \u00e9tendues n’est pas un filet de s\u00e9curit\u00e9. C’est une surface d’attaque. Les donn\u00e9es de 2025 sur les demandes d’indemnisation des cyberassurances montrent que l’infrastructure VPN existante est impliqu\u00e9e dans la majorit\u00e9 des points d’entr\u00e9e des ransomwares dans le Benelux. Les syst\u00e8mes que les \u00e9quipes conservent \u00ab\u00a0au cas o\u00f9\u00a0\u00bb sont ceux qui sont compromis. <\/p>\n La solution consiste \u00e0 \u00e9tablir un calendrier de d\u00e9classement, \u00e0 le consigner par \u00e9crit et \u00e0 l’attribuer. Pour chaque application que vous migrez vers SASE, fixez une date \u00e0 laquelle l’ancien chemin d’acc\u00e8s sera d\u00e9sactiv\u00e9. Pas \u00ab\u00a0\u00e9ventuellement\u00a0\u00bb. Une date pr\u00e9cise, g\u00e9n\u00e9ralement deux \u00e0 quatre semaines apr\u00e8s une migration r\u00e9ussie, avec une proc\u00e9dure de secours document\u00e9e en cas de probl\u00e8me pendant cette p\u00e9riode. <\/p>\n Voici ce que cela donne en pratique :<\/p>\nPremi\u00e8re erreur : traiter le SASE comme un outil suppl\u00e9mentaire<\/h2>\n
Erreur 2 : copier les r\u00e8gles VPN dans ZTNA et l’appeler Zero Trust<\/h2>\n
Troisi\u00e8me erreur : laisser fonctionner l’infrastructure existante \u00ab\u00a0au cas o\u00f9\u00a0\u00bb.<\/h2>\n