Quitter un WAF d'entreprise hérité : la checklist de migration

Pourquoi on migre — et pourquoi on hésite

Beaucoup d’équipes vivent avec un pare-feu applicatif d’entreprise qu’elles n’aiment plus : facturation opaque, règles impossibles à auditer, données journalisées dans une juridiction qui n’est pas la leur, support qui répond en jours. L’envie de partir est réelle. Ce qui bloque, c’est la peur : un WAF est en coupure sur le chemin de tout votre trafic. Une migration ratée ne ralentit pas un rapport interne — elle met votre site hors ligne ou laisse passer des attaques.

Cette peur est saine, et la bonne réponse n’est pas le courage mais la méthode. Une migration de WAF se réussit exactement comme un déploiement à haut risque : par étapes réversibles, avec une observation avant tout basculement, et un plan de retour arrière écrit avant de commencer. Voici la checklist.

1. Inventorier ce que le WAF actuel fait réellement

Avant de reproduire une protection, il faut savoir ce qu’elle couvre. Le piège est de supposer que votre WAF hérité applique « les bonnes règles » sans jamais l’avoir vérifié :

• Quelles familles d’attaques sont réellement bloquées ? La plupart des protections se ramènent à un socle que le jeu de règles OWASP couvre nativement — vous partez donc rarement de zéro.
• Quelles règles personnalisées ont été ajoutées au fil des ans ? Ce sont elles le vrai travail : exceptions métier, patchs virtuels posés lors d’incidents passés, blocages géographiques. Documentez chacune et sa raison d’être.
• Qu’est-ce qui est en blocage, qu’est-ce qui est en simple alerte ? Vous serez surpris du nombre de règles « actives » qui ne font en réalité que journaliser.

2. Basculer en mode observation, pas en coupure

La règle d’or : ne mettez jamais un nouveau WAF en blocage direct sur la production le premier jour. Faites d’abord passer le trafic à travers le nouvel edge en mode observation — il évalue chaque requête et journalise ce qu’il aurait bloqué, sans rien bloquer. Vous comparez alors, sur votre vrai trafic, ce que l’ancien et le nouveau système décident. Les écarts révèlent les règles à ajuster avant qu’un seul client ne soit affecté. Ce travail de réglage est détaillé dans l’article sur le dompter les faux positifs.

3. Reproduire les règles personnalisées, pas les copier aveuglément

Chaque règle héritée mérite la question : est-elle encore nécessaire ? Beaucoup ont été posées pour un incident vieux de plusieurs années, contre une faille depuis corrigée. Une migration est l’occasion de faire le ménage. Pour ce qui reste pertinent — un blocage géographique, une exception sur un point de terminaison — reproduisez l’intention à la périphérie, testée en observation d’abord.

4. Vérifier la question qui a peut-être motivé le départ : la souveraineté

Si vous partez en partie pour la résidence des données, la migration est le moment de la garantir. Nos nœuds tournent dans l’UE (Hetzner, OVH, Scaleway) par conception, et la journalisation reste sous droit européen — un point développé dans l’article sur la journalisation conforme au RGPD. Vérifiez concrètement où atterrissent les logs du nouveau système avant de couper l’ancien.

5. Basculer progressivement, avec un retour arrière prêt

Une fois l’observation propre et les règles reproduites, on bascule — mais par paliers. Un sous-domaine d’abord, ou une fraction du trafic, en surveillant le journal d’audit immuable. Le certificat TLS de chaque domaine est émis automatiquement par locataire, ce qui évite la manipulation manuelle qui plombe souvent les migrations. Et surtout : gardez la configuration DNS de l’ancien WAF prête à être réactivée. Un retour arrière est un changement DNS, pas une reconstruction. Voyez comment ça fonctionne et les tarifs.

Ce que nous ne prétendons pas

Nous ne prétendons pas qu’une migration de WAF est sans risque ni instantanée. Elle demande de l’inventaire, de l’observation et des tests — nous ne vendons pas un bouton « migrer » magique. Ce que nous offrons, c’est un chemin réversible à chaque étape, une résidence UE par défaut et la visibilité pour comparer avant de couper. Côté performance, le filtrage tient dans un budget de conception de ≤5 ms, mesuré en staging et jamais présenté comme un benchmark de production.

Vous envisagez de quitter un WAF hérité ? Parlez-nous de votre configuration actuelle — donnez-nous votre domaine.