Actualités

Pourquoi parler de migration firewall en 2025 ? Parce qu’on continue à les rater ! La migration d’un firewall devrait être un projet maîtrisé, orchestré comme une partition de sécurité. Pourtant, les incidents post-migration explosent encore dans des environnements pourtant matures. Pourquoi ? Parce que la migration est abordée comme un simple transfert d’équipement, un remplacement technique. 

Pourtant, changer de pare-feu, ce n’est pas “remplacer une boîte par une autre”. C’est modifier le point névralgique de votre contrôle réseau, renégocier toutes les règles qui gouvernent vos flux métiers. Et cela suppose de multiples précautions. 

Dans cet article, vous allez découvrir les 5 erreurs les plus critiques commises lors des migrations firewall. Et surtout, ce que vous pouvez mettre en place concrètement pour les éviter.

 

Erreur n°1 : répliquer sans réfléchir

C’est l’erreur la plus répandue : reprendre à l’identique l’ensemble des règles de l’ancien pare-feu, souvent à coups de scripts ou d’outils d’export/import, en espérant que tout continue à fonctionner “comme avant”.

Sauf que ce que vous importez, ce n’est pas uniquement de la configuration. C’est de la dette technique, de l’obsolescence et des approximations historiques. Résultat : un firewall tout neuf... déjà alourdi, vulnérable et illisible, potentiellement sujet à un incident ou une perte de contrôle fonctionnel. 

 

Que faire à la place ? La migration comme opportunité de refonte

Voici comment inverser la logique :

• Réalisez un audit de la politique existante : avec des outils comme Tufin ou AlgoSec, identifiez les règles non utilisées depuis X mois.
• Menez à bien une reprise fonctionnelle et non technique : cartographiez les besoins applicatifs actuels, et réécrivez vos règles à partir de ce périmètre.
• Opérez un nettoyage drastique : supprimez les règles orphelines, non documentées ou sans responsable métier identifié.

La migration, si elle est bien menée, devient une opportunité de remise à zéro stratégique, un acte de gouvernance autant qu’un projet IT.

 

Erreur n°2 : ignorer les flux métiers

Vous pensez que tout est sous contrôle parce que vos règles sont listées, vos ports documentés, vos IP bien rangées ? Fausse sécurité. Ce que vous avez sous les yeux, ce sont des configurations. Pas des flux métiers.

De nombreuses structures tombent dans le piège : elles migrent des objets techniques sans comprendre ce qu'elles protègent. Elles déplacent des règles sans savoir si elles concernent une interface de paiement, un extranet critique ou un outil de supervision vital.

Ignorer les flux métiers, c’est comme changer les serrures d’un immeuble sans savoir qui habite dans quel appartement. Résultat : des utilisateurs bloqués, des appels d’urgence, des équipes en panique.

Comment redonner du sens aux flux ?

La seule approche solide consiste à partir du métier vers la technique : 

• Cartographiez vos flux applicatifs : utilisez des outils comme NetFlow, Zeek ou vos solutions NDR pour observer les échanges réels.
• Travaillez avec les métiers : identifiez qui consomme quoi, à travers quelles applications, avec quels niveaux de criticité.
• Structurez votre politique de sécurité par service métier, pas uniquement par adresse IP ou zone réseau.

Le firewall n’est pas juste une frontière. C’est le reflet de vos dépendances business. Si vous ne les tracez pas, vous prenez le risque de les couper sans vous en rendre compte.

 

Erreur n°3 : oublier le shadowing 

Le shadowing, cette capacité à faire tourner le nouveau firewall en parallèle, en mode observation, est votre meilleure assurance qualité. Il permet de :

• capturer les anomalies, les flux bloqués, les écarts entre la configuration attendue et le comportement réel ;
• valider la couverture fonctionnelle avant de couper quoi que ce soit ;
• gagner la confiance des métiers en démontrant que la migration est pilotée, mesurée, maîtrisée.

Et pourtant, trop d’équipes sautent cette étape. Faute de temps, de budget ou de pression projet.

Prenons le cas réel d’un hôpital public qui migre son firewall principal, sans environnement de test isolé. Le jour J, tout fonctionne. Deux heures après, la plateforme de gestion des urgences tombe. Un flux sortant vers un prestataire de télémédecine a été filtré par erreur. Aucun rollback n’est prêt, les anciens équipements sont déjà décommissionnés.

Résultat ? Une heure d’indisponibilité, une cellule de crise. Coût estimé : 30 000 €... sans compter la perte de confiance.

 

Erreur n°4 : travailler en silo

C’est l’un des pièges les plus fréquents : la migration firewall confiée uniquement à l’équipe réseau ou sécurité, sans coordination active avec le reste de l’écosystème.

Résultat ? Les DevOps ne sont pas informés des nouvelles règles de NAT, les métiers ne comprennent pas pourquoi leurs flux changent, les équipes infra découvrent les modifications après coup… et vous vous retrouvez seul à gérer les conséquences.

Travailler en silo, c’est sacrifier l’intelligence collective sur l’autel de la vitesse. Ce que vous gagnez en rapidité d'exécution, vous le perdez en qualité, en robustesse et en acceptation.

 

Bonnes pratiques : inclure le métier, les DevOps et la conformité

Voici comment casser ce schéma :

• Montez un comité de migration multi-acteurs : sécurité, réseau, métiers, conformité, DPO si nécessaire.
• Planifiez des ateliers par zone fonctionnelle : pas juste pour informer, mais pour co-construire les règles, valider les flux critiques, anticiper les besoins spécifiques.
• Impliquez les DevOps en amont : ils vous diront ce qui risque de casser, ce qui dépend de DNS privés, de tunnels API, de règles codées en dur.

Et surtout : rendez les métiers propriétaires de leurs flux, donnez-leur la responsabilité de valider ce qui est essentiel pour leur activité. Vous n’êtes pas là pour décider à leur place, mais pour sécuriser ce qu’ils font.

Erreur n°5 : ne pas prévoir de rollback planifié

Vous êtes confiant. Les règles sont prêtes, les tests semblent concluants, la fenêtre de maintenance est calée. Vous lancez la migration. Tout se passe bien… jusqu’à ce que quelque chose coince : un flux critique qui ne passe plus, une API qui ne répond plus, une latence inexpliquée.

Et là, une question surgit : peut-on revenir en arrière ? Si la réponse est “non”, ou pire “on verra”, alors vous êtes en terrain miné. Car en cas de problème, sans rollback clair, vous n’avez plus de filet. Vous êtes exposé, et surtout, vous êtes seul. Sans filet, sans marge d’erreur. 

 

Le plan de rollback, un investissement de sérénité

Preuve d’une maturité opérationnelle, le rollback doit contenir :

• Une image ou configuration complète de l’ancienne plateforme, testée et prête à être remise en service.
• Des étapes précises de retour arrière, documentées, validées, avec les rôles attribués.
• Un temps de bascule mesuré, pour évaluer la faisabilité du retour sans impact démesuré.
• Un go/no go formel avant mise en production, basé sur des critères objectifs (tests, validations métiers, stabilité).

Le rollback, c’est ce qui vous permet de dormir la veille de la migration, et de garder votre calme quand une alerte critique survient.

 

Cette liste de mauvaises pratiques n’est pas exhaustive. On pourrait aussi parler de l'absence de documentation ou de la sous exploitation du nouveau firewall... Ce sont autant de portes ouvertes pour bien comprendre que la migration firewall doit être abordée comme une occasion de remettre à plat votre politique de sécurité, vos flux critiques, votre gouvernance. 

Les RSSI qui transforment cette étape technique en levier stratégique renforcent leur posture, améliorent la lisibilité de leur architecture et crédibilisent leur rôle au sein de l’organisation. À l’inverse, ceux qui migrent “en aveugle”, “à l’identique”, ou “sous pression” courent vers des déboires évitables. La migration firewall n’est pas qu’un chantier technique. C’est un moment de vérité qu’il convient de bien préparer.