Migration SonicWall vers SASE : un guide pratique pour les équipes du mid-market en 2026

Comment migrer de SonicWall à SASE ?

Une entreprise moyenne (50 à 400 utilisateurs) effectue la migration en quatre à six semaines. Le processus se déroule en cinq phases : audit de votre configuration SonicWall actuelle, mise en correspondance des règles de pare-feu avec les équivalents SASE, expérimentation avec les utilisateurs distants, déploiement progressif sur l’ensemble des sites et extinction du matériel SonicWall. Les plateformes SASE cloud-natives comme Jimber remplacent l’ensemble de la pile SonicWall, des règles de pare-feu aux tunnels VPN en passant par le filtrage de contenu, par une console unique gérée dans le cloud. Pas de nouveau matériel, pas de déplacement de camion.

Les pare-feu SonicWall ont bien servi les équipes informatiques du marché intermédiaire. Ils sont familiers, bien documentés et profondément ancrés dans les architectures de réseau en Belgique, aux Pays-Bas et dans l’ensemble du Benelux. Mais le calcul est en train de changer. Le matériel de génération 6 arrive en fin de support le 16 avril 2026. Les CVE liés aux VPN sont exploités dans les heures qui suivent leur divulgation. L’application de la norme NIS2 attend des contrôles qu’un pare-feu autonome ne peut assurer seul. La migration n’a pas besoin d’être douloureuse. Ce guide présente l’ensemble du processus, du mappage des politiques à l’exécution en parallèle, afin que votre équipe puisse planifier en toute confiance.

Pourquoi les clients de SonicWall envisagent-ils d’autres solutions en 2026 ?

Trois pressions convergentes poussent les clients de SonicWall à changer d’architecture. Chacune d’entre elles peut être gérée isolément. Ensemble, elles constituent un argument convaincant pour repenser entièrement le modèle centré sur le pare-feu.

Les délais de fin de soutien se rapprochent. Les pare-feu SonicWall de génération 6, y compris les séries TZ300, TZ400, TZ500, TZ600 et NSa 2650 à 6650, largement déployés, sont entrés en mode de retrait limité en avril 2024. Après le 16 avril 2026, ces dispositifs ne recevront plus de mises à jour de micrologiciels, de correctifs de sécurité ni d’assistance technique. L’utilisation de pare-feu non corrigés sur un périmètre public est un risque qu’aucun cadre de conformité n’acceptera.

L’exploitation des CVE s’accélère. La faille de contrôle d’accès CVE-2024-40766 est devenue le principal point d’entrée de la campagne du groupe Akira ransomware contre les dispositifs SonicWall à partir de la mi-2025. La CISA a confirmé une exploitation active. Arctic Wolf a observé une vague d’intrusions ciblant les appareils SonicWall en juillet 2025, avec un chiffrement complet en moins d’une heure après l’intrusion initiale dans certains cas. Même les appareils ayant fait l’objet d’un correctif sont restés vulnérables lorsque les informations d’identification locales n’avaient pas été réinitialisées après la migration de la version 6 à la version 7 du micrologiciel.

NIS2 nécessite plus qu’un filtrage du périmètre. La mise en œuvre de NIS2 en Belgique est active, avec des échéances de certification CyberFundamentals (CyFun) en avril 2026 pour les entités essentielles. La directive exige un contrôle d’accès basé sur l’identité, une journalisation centralisée, un rapport d’incident dans les 24 heures et une segmentation démontrable du réseau. Un pare-feu SonicWall prend en charge certaines de ces exigences. Mais pas toutes. Les organisations qui s’appuient uniquement sur les règles de pare-feu et l’accès VPN auront du mal à produire les preuves attendues par les auditeurs.

Ce que SonicWall vous apporte et ce qu’il ne vous apporte pas

SonicWall mérite d’être félicité. Les séries TZ et NSa sont des appareils qui ont fait leurs preuves. Les administrateurs connaissent l’interface. Le tableau de bord NSM (Network Security Manager) centralise la surveillance de base sur plusieurs appareils. Le moteur d’inspection approfondie des paquets de SonicWall est solide et la licence AGSS/CGSS regroupe l’antivirus de passerelle, l’IPS et le filtrage de contenu en un seul abonnement.

C’est sur le plan architectural que SonicWall n’est pas à la hauteur. La plateforme a été construite autour d’un modèle de périmètre : le trafic passe par un boîtier, le boîtier applique des règles et tout ce qui se trouve à l’intérieur du périmètre est approuvé par défaut. Ce modèle présente trois lacunes structurelles qui auront de l’importance en 2026.

Tout d’abord, il n’y a pas d’accès natif au réseau sans confiance. NetExtender et Mobile Connect fournissent des tunnels VPN SSL qui accordent un accès au niveau du réseau. Une fois qu’un utilisateur est connecté, il peut accéder à tout ce qui se trouve sur le sous-réseau, à moins que vous ne mettiez en place des règles de pare-feu complexes pour le restreindre. C’est le contraire de l’accès au moindre privilège.

Deuxièmement, une capacité cloud-native limitée. Le Cloud Secure Edge (CSE) de SonicWall existe, mais les commentaires des utilisateurs font systématiquement état d’une complexité de configuration et d’un changement de modèle de licence (mise en commun par utilisateur) qui diffère considérablement du modèle par appareil auquel les équipes du marché intermédiaire sont habituées.

Troisièmement, il n’y a pas d’isolation des appareils sans agent. Les imprimantes, les capteurs IoT et les équipements OT sont présents sur le réseau en tant que points d’extrémité fiables. SonicWall n’offre aucun mécanisme permettant d’isoler ces appareils au niveau de l’application sans matériel supplémentaire ni jeux de règles complexes.

Jimber s’attaque à ces trois problèmes. ZTNA remplace les tunnels VPN par un accès basé sur l’identité et par application. Secure Web Gateway et FWaaS gèrent le filtrage web et la politique de pare-feu depuis le cloud. Le matériel NIAC isole les appareils sans agent en ligne, sans nécessiter d’installation logicielle. Et tout fonctionne à partir d’une console de gestion unique.

Mappage de la configuration : SonicWall vers SASE

L’étape la plus pratique de la planification de la migration consiste à comparer ce que vous possédez à ce qui le remplace. Ce tableau présente les principaux composants SonicWall et leurs équivalents SASE.

La console unique de Jimber réunit tous ces composants dans un seul moteur de règles. Au lieu de gérer des règles à travers des pare-feux TZ individuels par site, vous définissez les politiques une seule fois et elles s’appliquent globalement, avec des exceptions par site ou par utilisateur si nécessaire.

Calendrier de migration étape par étape

Une approche progressive permet de limiter les risques et de réaliser des progrès mesurables à chaque étape. Voici un calendrier réaliste pour une entreprise de taille moyenne comptant de 50 à 400 utilisateurs répartis sur deux à cinq sites.

Semaine 1 à 2 : Audit et découverte. Cartographiez toutes les applications auxquelles vous accédez actuellement via NetExtender ou le VPN site à site. Documentez les groupes d’utilisateurs, les exigences d’accès et les types d’appareils. Exportez vos règles de pare-feu SonicWall et identifiez celles qui sont actives, celles qui sont redondantes et celles qui sont conflictuelles. Cette étape révèle souvent que 30 à 40 % des règles ne sont plus nécessaires. Identifiez tous les dispositifs sans agent (imprimantes, systèmes de gestion des bâtiments, équipements de production) qui devront être isolés par le NIAC plutôt que par un accès basé sur un agent.

Semaine 2 à 3 : Intégration de l’identité et conception des politiques. Connectez votre fournisseur d’identité (Azure AD/Entra ID, Google Workspace ou autre IdP) à la plateforme SASE. Synchronisez les groupes d’utilisateurs et mettez-les en correspondance avec les politiques d’accès aux applications. Concevez des lignes de base pour la posture de l’appareil : version minimale du système d’exploitation, chiffrement du disque, état de la protection des points d’extrémité. C’est ici que la migration diffère fondamentalement d’une mise à jour matérielle. Vous passez de règles basées sur l’IP à des politiques basées sur l’identité.

Semaine 3 à 4 : Pilote avec des utilisateurs distants. Déployez ZTNA pour deux ou trois applications à faible risque et à forte utilisation. Les travailleurs à distance constituent le groupe pilote idéal, car ce sont eux qui subissent le plus de frictions avec le VPN et qui bénéficient immédiatement d’un accès plus rapide et plus fiable. Exécutez ZTNA parallèlement au VPN SonicWall existant pendant le projet pilote. Surveillez l’expérience des utilisateurs, les journaux d’accès et les tickets de support. Affinez les règles de sécurité en fonction de l’état réel des appareils.

Semaines 4 et 5 : Mise en œuvre progressive. Étendre ZTNA aux applications critiques pour l’entreprise : ERP, CRM, partage de fichiers, outils internes. Activez les politiques SWG et FWaaS pour le trafic web. Déployez des superpositions SD-WAN pour remplacer les tunnels IPsec de site à site. Chaque application publiée via ZTNA réduit le trafic passant par le SonicWall, transférant progressivement la charge vers la plateforme SASE.

Semaine 5 à 6 : Coucher de soleil chez SonicWall. Une fois que la couverture des applications atteint 80 % ou plus et que le volume des tickets de support se stabilise, commencez le déclassement. Désactivez l’accès VPN pour les applications migrées. Supprimez les règles de pare-feu qui ont été remplacées par des règles SASE. Certaines organisations conservent un SonicWall à la périphérie du centre de données pendant une période d’observation. Cela ne pose aucun problème. L’objectif est d’y parvenir en l’espace d’un trimestre, et non pas de forcer un basculement en un seul week-end.

Nous avons publié des guides similaires pour les clients Fortinet qui migrent du VPN SSL. Le schéma est le même : une migration par étapes avec un fonctionnement en parallèle donne les meilleurs résultats. Pour une vue détaillée de la manière dont le déploiement complet s’articule, consultez la chronologie de la mise en œuvre de SASE.

Exécution en parallèle de SonicWall et de SASE

La période de transition est le moment où la plupart des équipes s’inquiètent. La bonne nouvelle : le SASE natif dans le nuage n’entre pas en conflit avec les pare-feu sur site. Les deux peuvent fonctionner simultanément.

Pendant la phase parallèle, configurez un tunnel IPsec entre votre appliance SonicWall et le point de présence dans le nuage de SASE. Cela crée un chemin hybride où les utilisateurs migrés passent par SASE tandis que les utilisateurs non migrés continuent à travers le pare-feu. Le DNS joue un rôle clé. Les requêtes DNS internes pour les applications migrées doivent être résolues vers la passerelle SASE. Les requêtes pour les applications qui se trouvent encore derrière le SonicWall sont dirigées vers le réseau local comme auparavant. La configuration Split DNS gère cela proprement.

L’architecture cloud-native de Jimber signifie qu’il n’y a pas de conflit matériel pendant la transition. Il n’y a pas de concurrence pour l’espace de rack, pas de conflit de port, pas de problème de compatibilité de firmware. La plateforme SASE fonctionne entièrement dans le nuage. Votre SonicWall continue de fonctionner comme il l’a toujours fait jusqu’à ce que vous soyez prêt à le mettre au rebut.

Commencez par les utilisateurs qui souffrent le plus du VPN : les travailleurs à distance, les voyageurs fréquents et les entrepreneurs. Ils bénéficient immédiatement d’un accès plus rapide et d’une meilleure fiabilité. Au fur et à mesure que chaque groupe migre, réduisez la portée du VPN. Désactivez l’accès à NetExtender pour des groupes d’utilisateurs spécifiques une fois qu’ils sont confirmés sur ZTNA. Conservez une procédure de retour en arrière documentée jusqu’à ce que vous soyez certain que la migration est terminée.

Le rapport sur les risques liés aux anciens VPN explique en détail pourquoi le maintien d’un accès VPN plus longtemps que nécessaire augmente l’exposition. Chaque semaine où les deux systèmes fonctionnent est une semaine avec deux surfaces d’attaque au lieu d’une.

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

C’est la question à laquelle les clients de SonicWall pensent rarement, jusqu’à ce qu’elle devienne un problème. Les imprimantes, les caméras IP, les systèmes de gestion des bâtiments, les appareils médicaux et les contrôleurs industriels se trouvent sur le même réseau que les points finaux gérés. SonicWall les traite comme des périphériques de confiance sur le sous-réseau local. Si un pirate compromet l’un d’entre eux, il obtient un point d’ancrage que le pare-feu ne peut pas voir.

SASE avec le matériel NIAC change complètement la donne. Le NIAC de Jimber isole les dispositifs sans agent en ligne, en limitant chaque dispositif à des flux de communication explicitement définis. Une imprimante peut atteindre le serveur d’impression. Un capteur IoT peut atteindre son point de terminaison dans le nuage. Rien d’autre. Le reste du réseau est invisible pour l’appareil.

Pour les organisations dotées d’équipements OT, cette passerelle IT-OT est particulièrement précieuse. Les contrôleurs de production, les automates programmables et les systèmes SCADA prennent rarement en charge les agents logiciels. En les plaçant derrière un système d’isolation NIAC, on obtient un accès segmenté sans perturber les processus de production ni annuler les garanties de l’équipement. Les fournisseurs de services de maintenance externes bénéficient d’un accès limité dans le temps à des machines spécifiques, par l’intermédiaire d’un courtier. L’usine reste isolée.

Le guide de migration IPsec VPN vs ZTNA explique comment la gestion des appareils sans agent s’inscrit dans une stratégie de migration plus large, y compris comment NIAC fonctionne avec les contrôles de posture des appareils pour les terminaux gérés.

Pour qui Jimber a-t-il été construit ?

Plutôt que de définir quand SonicWall peut encore être le bon choix, voici le profil des organisations pour lesquelles Jimber fournit les meilleurs résultats.

Vous avez entre 50 et 400 utilisateurs répartis sur plusieurs sites ou avec une importante main-d’œuvre à distance. Votre équipe informatique est réduite, généralement de deux à cinq personnes, et la gestion de plusieurs consoles empiète sur votre temps productif. Vous devez respecter les délais de conformité NIS2 ou CyFun et vous avez besoin d’une journalisation centralisée, d’un accès basé sur l’identité et de rapports d’audit. Vous avez des appareils sans agent sur votre réseau qui ont besoin d’être isolés, et pas seulement de règles de pare-feu. Vous travaillez avec un partenaire de service (MSP) qui a besoin d’une visibilité multi-tenant sur sa base de clients. Et vous voulez une tarification transparente, sans supplément de bande passante ni coûts supplémentaires cachés.

Si cette description vous convient, le cadre de comparaison des fournisseurs de SASE peut vous aider à structurer votre évaluation en fonction de l’architecture, du prix, du support technique et de la souveraineté des données.

Questions fréquemment posées

Puis-je migrer de SonicWall à SASE sans interruption de service ?

Oui. Le fonctionnement en parallèle signifie que les utilisateurs ne sont jamais privés d’accès. Pendant la transition, les deux systèmes fonctionnent simultanément. Les applications migrent une par une. Les utilisateurs passent progressivement à ZTNA. À aucun moment, il n’est nécessaire d’éteindre le SonicWall pour que la plate-forme SASE fonctionne. La plupart des organisations achèvent la migration sans la moindre interruption non planifiée.

Qu’advient-il de mon matériel SonicWall après la migration ?

Les appareils de la génération 6 qui arrivent en fin de vie ont une valeur limitée en termes de revente ou de réutilisation. Certaines organisations conservent une seule unité comme solution de repli temporaire pendant la période d’observation. Les appliances de génération 7 ou 8 peuvent être reconverties en simples routeurs ou vendues par l’intermédiaire de votre partenaire de distribution existant. Une fois que SASE est entièrement déployé, le matériel n’est plus nécessaire pour la mise en œuvre de la sécurité.

Dois-je également remplacer mes commutateurs SonicWall ?

Non. SASE opère au niveau de l’application et de l’identité, et non au niveau de la commutation. Vos commutateurs, points d’accès et câblages existants restent en place. Le matériel NIAC se connecte en ligne pour isoler les appareils sans agent, mais ne nécessite pas le remplacement de votre infrastructure de commutation.

Comment la tarification de SASE se compare-t-elle à celle de SonicWall AGSS ?

Le modèle de licence de SonicWall regroupe les services de sécurité (AGSS/CGSS) par appliance, avec des coûts distincts pour chaque pare-feu de votre environnement. SASE consolide toutes les fonctions de sécurité en un seul abonnement par utilisateur. Vous éliminez les cycles d’approvisionnement en matériel, les licences spécifiques aux appliances et les coûts cachés liés à la maintenance des microprogrammes, à l’alimentation électrique et à l’espace rack. Pour les déploiements multi-sites, la différence de coût est significative car vous n’avez plus besoin d’un pare-feu dédié et d’un ensemble de licences pour chaque site.

Mon MSP peut-il gérer la migration pour moi ?

Absolument. Les plateformes SASE avec architecture multi-tenant sont conçues pour que les partenaires de services puissent gérer plusieurs environnements clients à partir d’une seule console. Votre MSP peut modéliser les politiques, standardiser les lignes de base et exécuter la migration en utilisant des processus reproductibles à partir des déploiements précédents. La liste de contrôle de conformité NIS2 couvre les contrôles que votre partenaire de service doit mettre en œuvre parallèlement à la migration.

La migration vers SASE permet-elle d’assurer la conformité à NIS2 ?

Il répond à environ 80 à 90 % des contrôles techniques prévus à l’article 21 de la NIS2. L’accès basé sur l’identité répond aux exigences en matière de contrôle d’accès. La journalisation centralisée permet de respecter l’obligation de notification des incidents dans les 24 heures. Les contrôles de posture des dispositifs démontrent la gouvernance des points d’extrémité. La segmentation du réseau par le NIAC et le FWaaS montre la compartimentation des risques. Un pare-feu autonome couvre certains de ces aspects. Une plateforme SASE unifiée couvre la plupart d’entre eux à partir d’une seule source de preuves. Lisez la chronologie de la déchéance du VPN SSL pour comprendre pourquoi l’ensemble du secteur s’éloigne de l’accès VPN traditionnel.

Prêt à planifier votre migration SonicWall ? Réservez une démonstration et découvrez un plan de déploiement adapté à votre environnement, au nombre de sites et aux exigences de conformité. La plateforme Jimber est conçue pour les équipes du mid-market qui ont besoin d’avancer rapidement sans avoir à se lancer dans un projet d’implémentation de 12 mois.