Calendrier de mise en œuvre de SASE : du projet pilote au déploiement complet en 90 jours

Combien de temps dure la mise en œuvre d’un SASE ?

Le déploiement d’un SASE natif dans le nuage pour une organisation de taille moyenne comptant de 50 à 400 utilisateurs suit six phases et prend de 60 à 90 jours, de la définition du champ d’application au déploiement complet. Ces phases sont les suivantes : évaluation, conception de l’identité et de la politique, pilote contrôlé, expansion progressive, démantèlement de l’héritage et optimisation continue. Des plateformes telles que Jimber, conçues pour une intégration rapide, permettent à un groupe pilote d’être opérationnel en quelques jours, et non en quelques semaines, car il n’y a pas de matériel à acheter ou à installer.

La plupart des équipes informatiques pensent que la migration SASE ressemblera aux projets de remplacement des pare-feu qu’elles redoutent déjà. Douze mois de planification. Six mois de fonctionnement en parallèle. Trois mois à réparer ce qui est cassé. Cette attente provient de projets centrés sur le matériel où chaque site a besoin d’un camion, d’un rack et d’une fenêtre de changement. Le SASE natif dans le nuage fonctionne différemment. Les politiques sont définies de manière centralisée et mises en œuvre instantanément. Les utilisateurs se connectent par l’intermédiaire d’un logiciel, et non d’appareils spécifiques à un site. L’ensemble du calendrier de mise en œuvre de SASE se résume à quelques semaines au lieu de quelques trimestres. Ce guide présente chaque phase avec des étapes concrètes, les responsabilités de l’équipe et les obstacles courants qui ralentissent les déploiements.

Phase 1 : évaluation et délimitation du champ d’application (semaines 1-2)

Chaque déploiement de SASE commence par une image claire de ce que vous avez et de ce qui doit changer en premier. Si vous sautez cette étape, vous reproduisez d’anciens schémas d’accès VPN dans un nouvel outil, ce qui va à l’encontre du but recherché.

Commencez par dresser la carte de votre système de sécurité actuel. Dressez la liste de tous les appareils, abonnements et consoles gérés par votre équipe. Pour la plupart des entreprises de taille moyenne, cet exercice révèle à lui seul la fragmentation : un concentrateur VPN ici, un filtre web autonome là, des pare-feu de branche avec leurs propres ensembles de règles et un outil de point final que plus personne ne vérifie.

Ensuite, associez les utilisateurs aux applications. Pas « l’équipe de vente utilise le réseau ». Des applications spécifiques. CRM, ERP, partages de fichiers, portail de facturation, tableau de bord de contrôle de la production. Cet inventaire servira plus tard de base à vos politiques ZTNA. La plupart des entreprises découvrent que l’utilisateur moyen a besoin d’accéder à trois ou cinq applications, et non à l’ensemble du réseau que le VPN autorisait.

Définissez vos gains rapides. Quel est le groupe d’utilisateurs qui subit le plus de frictions VPN ? En général, les travailleurs à distance et les ingénieurs de terrain. Quelle est l’application qui génère le plus de tickets d’assistance ? Commencez par là. Votre guide de comparaison des fournisseurs SASE devrait vous indiquer quelle plateforme correspond à vos besoins.

Enfin, convenez de critères de réussite avant de commencer. Des objectifs mesurables tels que « réduire de 50 % les tickets d’assistance liés au VPN » ou « obtenir une latence inférieure à 30 ms pour les utilisateurs distants accédant aux applications en nuage » donnent au projet une ligne d’arrivée claire plutôt qu’une boucle d’optimisation sans fin.

Phase 2 : conception de l’identité et de la politique (semaines 2-3)

L’identité est le fondement de SASE. Sans l’intégration d’un fournisseur d’identité, rien d’autre ne fonctionne. Cette phase se déroule en partie parallèlement à la fin de l’évaluation.

Connectez d’abord votre fournisseur d’identité. Microsoft Entra ID, Okta, Google Workspace ou tout autre fournisseur d’identité utilisé par votre organisation. Synchronisez les groupes d’utilisateurs et vérifiez que les attributions de rôles correspondent aux fonctions de l’entreprise, et non aux groupes AD hérités qui se sont accumulés au fil des ans. Notre guide sur les fournisseurs d’identité explique en détail les modèles d’intégration pour SAML et OIDC.

Définissez ensuite vos politiques d’accès. Le principe est simple : chaque utilisateur n’a accès qu’aux applications que son rôle exige. Rien de plus. Un membre de l’équipe financière accède au système de facturation et au portail de reporting. Un ingénieur accède à l’outil de surveillance de la production et au dépôt de code. Aucun des deux ne voit les applications de l’autre.

Définissez des lignes de base pour la posture des appareils en même temps que des politiques d’accès. Déterminez les signaux importants pour votre organisation : Version du système d’exploitation, état du chiffrement du disque, protection des points d’accès en cours d’exécution, enregistrement de l’appareil. La plateforme Jimber applique ces contrôles au point d’accès, de sorte que les appareils non conformes sont automatiquement bloqués ou restreints. Pour une démonstration étape par étape, consultez notre guide sur les contrôles de posture des appareils pour NIS2.

Documentez vos décisions politiques. Cette documentation devient plus tard une preuve de conformité et évite les conversations du type « pourquoi cela a-t-il été configuré de cette façon ?

Phase 3 : pilote contrôlé (semaines 3 à 5)

Le projet pilote prouve que la plate-forme fonctionne dans votre environnement avant que vous n’engagiez le reste de l’organisation. Commencez petit, mesurez tout, réparez ce qui est cassé.

Sélectionnez 10 à 20 % de vos utilisateurs pour le projet pilote. Les travailleurs à distance constituent le premier groupe idéal pour deux raisons. Ce sont eux qui subissent le plus de frictions avec le VPN, et ils remarquent donc immédiatement les améliorations. De plus, ils testent le scénario d’accès le plus difficile : se connecter à partir de réseaux imprévisibles par l’intermédiaire de fournisseurs d’accès Internet grand public.

Publiez deux ou trois applications par l’intermédiaire de ZTNA. Choisissez des applications qui sont très utilisées mais qui présentent peu de risques en cas de problème. Un wiki interne, un système d’enregistrement des heures ou un outil de gestion de projet. Cela permet à votre équipe d’apprendre comment la plateforme se comporte dans la pratique, tout en gardant les enjeux à un niveau raisonnable.

Les plateformes cloud-natives comme Jimber peuvent embarquer un groupe pilote en quelques jours, et non en quelques semaines, car il n’y a pas de matériel à expédier ou à configurer. L’administrateur crée les définitions d’application dans la console, les affecte au groupe pilote et les utilisateurs se connectent par le biais d’un agent léger ou d’un accès par navigateur.

Faites fonctionner le VPN en parallèle pendant toute la durée du projet pilote. Les utilisateurs ont besoin d’une solution de repli s’ils rencontrent un cas limite que la configuration ZTNA ne couvre pas encore. Surveillez de près trois éléments : l’expérience de l’utilisateur (latence, stabilité de la connexion), le volume des tickets d’assistance et les journaux d’accès montrant les succès et les blocages de la politique. Ces données déterminent le plan de déploiement de la phase 4.

Exécutez le projet pilote pendant au moins deux semaines. Une semaine n’est pas suffisante pour détecter les problèmes intermittents tels que les problèmes de renouvellement des certificats ou les cas limites de résolution DNS.

Phase 4 : déploiement progressif (semaines 5 à 10)

Avec les données pilotes en main, étendez la couverture méthodiquement. L’objectif est d’atteindre 80 % ou plus des utilisateurs et des applications avant de toucher à l’infrastructure existante.

Déployez le système site par site ou département par département. Chaque vague suit le même schéma : synchronisation du groupe d’utilisateurs, publication de leurs applications, activation des contrôles de posture des appareils, surveillance pendant deux ou trois jours, puis passage à la vague suivante. Grâce à la console unique de Jimber, les changements de politique se propagent instantanément sur tous les sites. Il n’y a pas de dérive de configuration par site à gérer.

Ajoutez les applications essentielles à l’entreprise au cours de cette phase. ERP, CRM, systèmes financiers et toute application qui touche des données sensibles. Ces applications requièrent des règles de posture et des politiques d’accès plus strictes que les applications pilotes. Définissez des flux de travail d’exception pour les cas particuliers : un entrepreneur qui a besoin d’un accès temporaire, un poste de travail partagé dans un entrepôt, une application héritée qui ne parle que le RDP.

Pour les organisations dotées d’environnements OT, cette phase comprend le déploiement du matériel NIAC pour les appareils sans agent. Les imprimantes, les caméras, les contrôleurs industriels et les capteurs IoT ne peuvent pas exécuter d’agent ZTNA. Les appliances NIAC de Jimber se placent en ligne entre l’appareil et le réseau, appliquant les contrôles Zero Trust sans nécessiter de logiciel sur l’appareil lui-même.

Les partenaires de service qui gèrent plusieurs clients bénéficient de l’architecture multi-locataires au cours de cette phase. Chaque environnement client est isolé, mais les modèles et les politiques de base peuvent être partagés entre les locataires. Notre article sur la façon dont les MSP fournissent des SASE gérés couvre le modèle opérationnel en détail.

Suivez vos critères de réussite de la phase 1 tout au long du déploiement. Si les tickets d’assistance VPN ne diminuent pas, c’est qu’il y a quelque chose à régler dans la configuration avant d’aller plus loin.

Phase 5 : démantèlement de l’héritage (semaine 8-12)

Une fois que la couverture des applications atteint 80 % ou plus et que les données pilotes confirment des performances stables, commencez à retirer l’infrastructure existante. C’est à ce stade que les économies se matérialisent.

Commencez par le VPN. Désactivez l’accès VPN pour les applications qui sont entièrement publiées via ZTNA. Procédez par étapes : retirez l’application de la configuration VPN, surveillez-la pendant une semaine, puis passez à l’application suivante. Conservez des procédures de secours documentées jusqu’à ce que vous soyez certain que la transition est terminée.

Ensuite, mettez à la retraite les pare-feu des succursales. Le FWaaS fourni par le cloud remplace le matériel de pare-feu sur site pour chaque site. Pour la plupart des entreprises de taille moyenne, cela élimine les cycles de mise à jour du micrologiciel, la gestion des jeux de règles et les coûts de rafraîchissement du matériel qui consommaient une part disproportionnée du temps des informaticiens.

Grâce à la console unique de Jimber, les équipes informatiques n’ont pas à gérer deux tableaux de bord pendant la période de transition. Les politiques d’accès, la sécurité web, la connectivité SD-WAN et la journalisation sont regroupées dans une seule interface dès le premier jour. La transition consiste à supprimer l’ancienne infrastructure, et non à apprendre de nouveaux outils.

Réduisez progressivement les contrats et les licences pour les produits déclassés. Les contrats d’assistance pour les concentrateurs VPN, les abonnements aux filtres web autonomes et les licences de pare-feu par site peuvent représenter des coûts annuels importants. Une société belge de gestion de patrimoine a réduit ses coûts totaux de sécurité de 58 % après avoir réalisé cette consolidation.

Phase 6 : optimisation et suivi (en cours)

SASE n’est pas un déploiement « prêt à l’emploi ». C’est au cours de la phase continue que vous affinez les politiques sur la base de données d’utilisation réelles et que vous constituez les preuves de conformité attendues par les auditeurs.

Examinez les journaux d’accès tous les mois. Recherchez les utilisateurs qui disposent de permissions qu’ils n’exercent jamais et renforcez leur champ d’application. Recherchez les applications qui génèrent des blocages fréquents et vérifiez si la politique est trop restrictive ou si quelqu’un essaie d’accéder à quelque chose qu’il ne devrait pas.

Effectuez un audit trimestriel des politiques. Vérifiez que les groupes d’utilisateurs reflètent toujours les rôles réels, que les bases de la posture des appareils sont à jour (les seuils de version du système d’exploitation doivent être mis à jour à mesure que les fournisseurs sortent de nouvelles versions) et que les politiques d’exception ne se sont pas transformées en solutions de contournement permanentes.

Pour les organisations réglementées par NIS2, les capacités de journalisation et de reporting de votre plateforme SASE sont votre moteur de conformité. La journalisation intégrée à Jimber et les vérifications de la posture des appareils couvrent plusieurs exigences NIS2 dès le premier jour : documentation du contrôle d’accès, détection des incidents dans les 24 heures et preuves de la conformité des appareils. Notre check-list de conformité NIS2 met en correspondance ces exigences avec les fonctionnalités spécifiques de la plateforme.

Ce qui ralentit les déploiements SASE (et comment l’éviter)

Le délai de 90 jours indiqué ci-dessus suppose une exécution compétente. Dans la pratique, quatre obstacles courants prolongent inutilement les déploiements.

Pas de préparation du fournisseur d’identité. Si votre IdP est mal configuré, a des groupes d’utilisateurs périmés ou n’applique pas le MFA, l’intégration de SASE s’arrête à la phase 2. Nettoyez votre répertoire avant de commencer. Supprimez les comptes orphelins, vérifiez l’appartenance aux groupes et activez le MFA. Ce travail de préparation est payant.

Mauvaise configuration du DNS. Les environnements DNS fractionnés, les résolveurs DNS personnalisés et les applications qui codent en dur les serveurs DNS sont autant de sources de problèmes lorsque l’acheminement du trafic change. Auditez votre configuration DNS pendant l’évaluation. Documentez chaque zone DNS interne et chaque résolveur personnalisé.

Pas de parrainage exécutif. Le déploiement de SASE concerne tous les utilisateurs de l’organisation. Sans un soutien visible de la direction, les différents services repoussent les changements, les projets pilotes sont bloqués dans l’attente des approbations et les anciens contrats sont renouvelés « au cas où ». Obtenez un sponsor au niveau du conseil d’administration avant la phase 1.

Pas de plan d’extinction de l’héritage. Certaines équipes déploient parfaitement SASE mais ne mettent jamais hors service l’ancienne infrastructure. Le VPN continue de fonctionner « pour la sauvegarde ». Les pare-feu des succursales continuent d’être corrigés. L’organisation paie pour les deux systèmes indéfiniment. Fixez une date d’expiration lors de la définition du champ d’application et tenez-vous-en à cette date.

Comment les échéances du NIS2 affectent-elles votre calendrier de mise en œuvre de SASE ?

La date limite de vérification des Cyberfondamentaux (CyFun) de la Belgique, fixée à avril 2026, est dépassée. Les organisations qui devaient démontrer leur conformité au niveau Basique ou Important devraient déjà avoir mis en place leurs contrôles techniques. Pour celles qui travaillent encore à leur mise en conformité, chaque semaine de retard est une semaine d’exposition à des mesures d’application.

L’article 21 de la NIS2 exige des contrôles d’accès documentés, des capacités de détection des incidents et des mesures de sécurité de la chaîne d’approvisionnement. Une plateforme SASE répond à environ 90 % de ces exigences techniques grâce à l’accès basé sur l’identité, à la journalisation centralisée et à l’application de la posture de l’appareil. L’aperçu de la conformité NIS2 couvre l’ensemble du contexte réglementaire.

L’implication pratique pour votre calendrier de mise en œuvre de SASE : ne traitez pas le déploiement comme un projet de plusieurs trimestres. L’horloge de la conformité est déjà en marche. Une mise en œuvre de 90 jours qui fournit des contrôles fonctionnels vaut plus qu’un plan de 12 mois qui produit une feuille de route parfaitement documentée et aucune protection.

Pour les organisations aux Pays-Bas, la Cyberbeveiligingswet est entrée en vigueur au début de l’année 2026. Au Royaume-Uni, la réglementation NIS suit son propre calendrier d’application. Quelle que soit la juridiction, l’orientation est la même : des contrôles techniques démontrables, et non des intentions documentées.

Questions fréquemment posées

Pouvons-nous utiliser SASE en même temps que notre pare-feu actuel ?

Oui, et vous devriez le faire pendant la transition. Les plateformes SASE sont conçues pour un déploiement progressif. Maintenez vos pare-feu actifs pendant que vous migrez les applications vers ZTNA et que vous transférez la sécurité web vers SWG. Une fois que la couverture atteint 80 % ou plus, mettez hors service les pare-feu des succursales. Certaines organisations conservent un pare-feu périmétrique au centre de données pour des contrôles spécifiques du trafic nord-sud pendant la transition, mais la direction à long terme est la consolidation complète.

Combien d’utilisateurs devraient participer au projet pilote ?

Visez 10 à 20 % de votre base d’utilisateurs, avec un minimum de 15 à 20 utilisateurs pour générer des données significatives. Incluez les travailleurs à distance, les grands voyageurs et au moins un service qui accède à des applications sensibles. Si vous avez trop peu d’utilisateurs, vous ne pourrez pas détecter les cas particuliers. S’ils sont trop nombreux, vous perdrez l’environnement contrôlé qui fait l’utilité d’un projet pilote.

Devons-nous remplacer notre SD-WAN ?

Pas nécessairement. Si vous disposez déjà d’un déploiement SD-WAN opérationnel et que vous n’avez besoin que d’une sécurité fournie par le cloud, le SSE (Security Service Edge) peut suffire. Si vos contrats SD-WAN arrivent à échéance ou si vous souhaitez un plan de gestion unique pour les utilisateurs distants et les succursales, le SASE unifié est la meilleure solution. Notre guide sur l’architecture SASE explique la distinction entre SSE et SASE complet.

Qu’en est-il des appareils qui ne peuvent pas exécuter d’agents ?

Les imprimantes, les capteurs IoT, les caméras et les équipements industriels ont besoin d’une isolation en ligne plutôt que d’une protection basée sur des agents. Le matériel NIAC place ces appareils derrière des contrôles d’accès basés sur l’identité qui limitent la communication à des flux explicitement définis. L’appareil se connecte uniquement à sa destination désignée. Rien d’autre. Cela permet de fermer l’angle mort que les outils de sécurité traditionnels ignorent.

Comment le déploiement de SASE fonctionne-t-il pour les organisations ayant plusieurs sites ?

Le SD-WAN gère la connectivité multi-sites dans le cadre de la plateforme SASE. Les succursales se connectent par le biais de tunnels cryptés sur des liaisons internet standard. L’approvisionnement sans contact signifie qu’un appareil est expédié sur le site, qu’il est branché par du personnel non technique et qu’il récupère automatiquement sa configuration dans le nuage. Le temps de déploiement par site passe de quelques jours à quelques minutes.

Que se passe-t-il si notre informatique est gérée par un partenaire de service ?

Les partenaires de service accélèrent le calendrier. Ils apportent l’expérience de déploiement de leurs clients précédents, et les plateformes SASE multi-locataires leur permettent de gérer votre environnement à partir de la même console que celle qu’ils utilisent pour leurs autres clients. Les modèles de politique, les lignes de base standardisées et les processus d’intégration reproductibles signifient que le partenaire ne part pas de zéro pour chaque engagement.

Prêt à établir un calendrier de mise en œuvre de SASE pour votre organisation ? Réservez une démonstration et découvrez un plan de déploiement adapté à la taille de votre équipe, au nombre de sites et aux exigences de conformité. La plateforme Jimber est conçue pour les entreprises de taille moyenne qui ont besoin d’une sécurité de niveau entreprise sans avoir besoin d’un projet d’implémentation de 12 mois.