Quelles sont les erreurs les plus courantes en matière de déploiement de SASE ?
Les trois erreurs de déploiement SASE les plus fréquentes consistent à traiter la migration comme un échange d’outils plutôt que comme un changement d’architecture, à copier les règles d’accès VPN héritées dans un modèle ZTNA sans les repenser, et à laisser fonctionner l’ancienne infrastructure « au cas où » longtemps après qu’elle aurait dû être mise hors service. Chaque cas ajoute des mois au calendrier et érode les gains de sécurité qui justifiaient le projet en premier lieu.
Après avoir aidé des dizaines d’entreprises de taille moyenne à déployer SASE, trois erreurs de déploiement de SASE se répètent. Il ne s’agit pas de cas techniques exceptionnels. Il s’agit de schémas organisationnels qui transforment un projet de six semaines en un projet de six mois. Au début de l’année, nous avons écrit sur les 10 erreurs les plus courantes en matière de ZTNA. La liste qui suit est plus large. Il s’agit des schémas qui bloquent des programmes SASE entiers, et pas seulement des configurations ZTNA.
Première erreur : traiter le SASE comme un outil supplémentaire
L’erreur la plus préjudiciable se produit avant la rédaction de la première politique. Les équipes abordent le SASE comme un achat de produit et non comme un changement d’architecture. Elles le placent à côté des pare-feu et des VPN existants, comme une couche supplémentaire, plutôt que comme le remplacement de la plupart d’entre eux.
C’est ce que nous avons constaté récemment avec une entreprise de logistique de 200 utilisateurs. Son responsable informatique a acheté une licence SASE, l’a configurée parallèlement à son cluster de pare-feu existant et a commencé à acheminer une partie du trafic via la nouvelle plateforme. Six mois plus tard, il utilisait les deux systèmes en parallèle, payait pour les deux et gérait les politiques dans deux consoles. Le dispositif de sécurité avait à peine changé, car personne n’avait décidé quel système faisait autorité.
Ce schéma est plus courant que ne l’admettent la plupart des fournisseurs. L’étude de Gartner suggère 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é à considérer le SASE comme un projet de consolidation plutôt que comme un ajout.
La solution commence avant la passation des marchés. Définissez les outils que SASE va remplacer et non compléter. 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 à la retraite. Si vous ne pouvez pas nommer ce que SASE remplace, vous ajoutez de la complexité au lieu de la supprimer. L’article intitulé » Escaping the Frankenstack » décrit en détail cette logique de consolidation.
Conseil pratique : avant de signer quoi que ce soit, écrivez une phrase qui complète « après le déploiement complet de SASE, nous n’aurons plus besoin de ______ ». Si cette phrase est difficile à écrire, prenez du recul et revoyez votre plan d’architecture.
Erreur 2 : copier les règles VPN dans ZTNA et l’appeler Zero Trust
La deuxième erreur est plus subtile. Les équipes migrent leur ancien pare-feu et leurs règles d’accès VPN directement dans le nouveau modèle ZTNA. L' »équipe financière » bénéficie du même accès étendu que celui qu’elle avait par le biais du tunnel VPN. Les « travailleurs à distance » héritent des mêmes politiques de groupe. L’ancienne structure de permission reçoit une nouvelle étiquette. Rien ne change en réalité.
C’est le piège du « lift-and-shift ». Il donne l’impression d’être efficace parce qu’il permet d’éviter les conversations difficiles sur qui a vraiment besoin d’accéder à quoi. Mais il va à l’encontre de l’objectif de la confiance zéro. Un compte compromis dans un déploiement ZTNA « lift-and-shift » a le même rayon d’action qu’un compte VPN compromis, c’est-à-dire beaucoup trop large.
Le problème le plus profond est généralement l’encrassement des données d’identité. La plupart des entreprises de taille moyenne ont des fournisseurs d’identité remplis de membres de groupes périmés, de permissions héritées et de comptes de service génériques que personne n’a audités depuis des années. Brancher ce désordre sur une plateforme ZTNA ne fait que numériser le dysfonctionnement. Les données de l’industrie montrent régulièrement que les problèmes d’hygiène de l’identité sont parmi les principales causes d’échec du contrôle d’accès, et qu’ils sont tout à fait évitables.
La solution comporte quatre étapes. Premièrement, assainissez votre fournisseur d’identité avant la migration. Supprimez les comptes périmés, vérifiez l’appartenance aux groupes et alignez les groupes sur les rôles réels de l’entreprise. Deuxièmement, associez les utilisateurs aux applications, et non aux réseaux. Posez la question suivante : « Quelles sont les trois applications utilisées quotidiennement par cette personne ? » plutôt que « De quel segment de réseau a-t-elle besoin ? ». Troisièmement, commencez par des applications en lecture seule et à faible risque dans votre projet pilote. Un wiki ou un système de chronométrage permet à votre équipe d’apprendre le modèle avant que les enjeux ne soient élevés. Quatrièmement, activez les contrôles de posture des appareils dès le premier jour. En les omettant pendant le projet pilote, ce que de nombreuses équipes font pour réduire les frictions, vous entraînez les utilisateurs à s’attendre à un accès sans validation de sécurité.
Ce dernier point est plus important qu’il n’y paraît. Une fois que vous avez établi le précédent selon lequel les appareils non gérés ont le même accès que les appareils gérés, revenir sur cette attente devient un combat politique. Faites-le correctement dès le départ.
Pour un examen plus approfondi de la manière dont les fournisseurs d’identité s’intègrent à l’accès Zero Trust, ce guide couvre les modèles d’intégration spécifiques qui permettent d’éviter cette erreur.
Troisième erreur : laisser fonctionner l’infrastructure existante « au cas où ».
La troisième erreur est celle qui, tout en se sentant responsable, sape discrètement tout ce qui se passe. Les équipes terminent le déploiement de SASE. Les utilisateurs sont connectés via ZTNA. Les politiques fonctionnent. Puis quelqu’un dit : « Gardons l’ancienne passerelle VPN comme solution de repli. Juste au cas où ».
Des mois plus tard, le VPN est toujours actif. Les anciennes règles du pare-feu existent toujours. Les serveurs de saut qui étaient censés être mis hors service sont toujours accessibles. Chacun d’entre eux est une voie d’accès non surveillée qui contourne tous les contrôles de confiance zéro que vous venez de mettre en place.
Nous avons vu cela dans presque tous les engagements. Le raisonnement semble toujours prudent. « Que se passe-t-il si la nouvelle plateforme est en panne ? » « Et si nous devions revenir en arrière ? » Mais le calcul du risque est à l’envers. Un concentrateur VPN dormant avec un firmware périmé et des règles d’accès étendues n’est pas un filet de sécurité. C’est une surface d’attaque. Les données de 2025 sur les demandes d’indemnisation des cyberassurances montrent que l’infrastructure VPN existante est impliquée dans la majorité des points d’entrée des ransomwares dans le Benelux. Les systèmes que les équipes conservent « au cas où » sont ceux qui sont compromis.
La solution consiste à établir un calendrier de déclassement, à le consigner par écrit et à l’attribuer. Pour chaque application que vous migrez vers SASE, fixez une date à laquelle l’ancien chemin d’accès sera désactivé. Pas « éventuellement ». Une date précise, généralement deux à quatre semaines après une migration réussie, avec une procédure de secours documentée en cas de problème pendant cette période.
Voici ce que cela donne en pratique :
| Phase de l’action | Action | Calendrier |
|---|---|---|
| Migration terminée | Application vérifiée sur SASE, utilisateurs confirmés | Jour 0 |
| Période de surveillance | Surveillez les problèmes d’accès, suivez les tickets d’assistance | Jours 1 à 14 |
| Ancien chemin désactivé | Règle VPN/pare-feu supprimée, documentée | Jour 15 |
| Infrastructure mise hors service | Matériel mis hors service, licences annulées | 30ème jour |
L’idée clé : le déclassement n’est pas une tâche de nettoyage que vous effectuez après le projet. Il fait partie du projet. Chaque phase du déploiement de votre architecture SASE doit inclure la « mise hors service de ce qui est remplacé » comme un produit livrable, et non comme une réflexion a posteriori.
Comment repérer ces schémas avant qu’ils ne vous ralentissent ?
Si vous pouvez répondre honnêtement à trois questions avant le début du déploiement, vous éviterez environ 80 % des retards que nous constatons sur le terrain.
Premièrement : qu’allons-nous désactiver exactement après le déploiement de SASE ? Si la réponse est « rien », vous ajoutez un outil, vous ne changez pas votre architecture. Revenez au plan d’architecture.
Deuxièmement : avons-nous contrôlé notre fournisseur d’identité au cours des six derniers mois ? Si l’appartenance à un groupe et les autorisations n’ont pas été vérifiées, vous importerez des problèmes directement dans ZTNA. Des données d’identité propres sont le meilleur indicateur d’un déploiement sans heurts.
Troisièmement : à qui appartient le calendrier de déclassement ? Si personne n’inscrit un nom et une date à côté de chaque composant patrimonial, ces composants fonctionneront encore dans un an. Nommez le propriétaire. Fixez les dates.
Les organisations qui répondent à ces trois questions avant de commencer ont tendance à terminer dans les temps. Celles qui les ignorent ont tendance à nous appeler six mois plus tard pour nous demander pourquoi tout prend tant de temps.
Pour les équipes qui évaluent actuellement les fournisseurs, le cadre de comparaison des fournisseurs de SASE couvre ce qu’il faut rechercher au-delà des listes de contrôle des fonctionnalités, y compris la façon d’évaluer si l’architecture d’une plate-forme prend réellement en charge la consolidation et la simplicité qui permettent d’éviter ces erreurs.
Questions fréquemment posées
Quelle est la durée d’une phase pilote de SASE ?
Deux à quatre semaines pour le projet pilote initial couvrant l’accès à distance pour 50 à 100 utilisateurs sont typiques pour les organisations de taille moyenne. Le projet pilote devrait inclure au moins trois à cinq applications, avec des vérifications de l’état des appareils activées dès le départ. La prolongation du projet pilote au-delà de six semaines signifie généralement que l’équipe évite de prendre une décision plutôt que de recueillir des données.
Devons-nous mettre notre pare-feu hors service avant ou après le déploiement de SASE ?
Après. Exécutez les deux en parallèle pendant la migration, mais avec un calendrier de mise hors service ferme. La plupart des organisations conservent des pare-feu périmétriques pour le trafic nord-sud pendant la transition et les retirent lorsque la couverture SASE s’étend pour couvrir ces fonctions. Le danger n’est pas de faire fonctionner les deux de manière temporaire. Le danger est d’utiliser les deux en permanence.
Quelle est la principale perte de temps dans le cadre d’un déploiement SASE ?
Des données d’identité sales. Les organisations qui commencent à migrer avant d’avoir nettoyé leur fournisseur d’identité passent des semaines à résoudre des problèmes d’accès qui n’ont rien à voir avec la plateforme SASE. Les membres de groupes périmés, les comptes orphelins et les définitions de rôles vagues créent des frictions à chaque étape. Prévoyez au moins une semaine pour l’hygiène de l’identité avant le début de la migration technique.
Avons-nous besoin d’un chef de projet dédié à SASE ?
Il ne s’agit pas nécessairement d’un chef de projet à plein temps, mais quelqu’un doit être responsable du calendrier, du calendrier de démantèlement et de la coordination entre les équipes. SASE touche au réseau, à la sécurité et à l’identité, trois domaines qui relèvent souvent d’équipes différentes. Si personne ne veille à ce que les trois domaines soient alignés, les décisions sont bloquées. Pour les équipes de taille moyenne, il s’agit souvent du responsable informatique ou d’un ingénieur principal doté d’un mandat clair.
Pouvons-nous déployer SASE sans perturber les activités quotidiennes ?
Oui, si vous adoptez une approche progressive. Commencez par l’accès à distance via ZTNA, puis ajoutez une couche de sécurité web, puis ajoutez la connectivité du site via SD-WAN. Chaque phase apporte de la valeur indépendamment tout en maintenant l’infrastructure existante active comme solution de repli. La combinaison d’une architecture cloud-native et d’une console de gestion unique rend le déploiement progressif pratique, même pour les petites équipes. C’est pourquoi nous avons construit Jimber pour supporter exactement ce modèle, composant par composant, sans nécessiter une migration de grande ampleur.
Prêt à éviter les erreurs qui ralentissent la plupart des déploiements de SASE ? Réservez une démonstration et nous élaborerons un déploiement progressif adapté à votre calendrier et à votre équipe.
