Cinq cents zones Cloudflare, une par commune raccordée à un réseau intercommunal de sites headless partageant la même base WordPress multisite et le même front Next.js mutualisé. Sur le papier, l’homogénéité semblait acquise : même code, même thème, même architecture de déploiement. En pratique, l’audit mené sur l’ensemble du parc a recensé 47 variantes différentes de règles de cache, certaines datant de la création du réseau plusieurs années auparavant, jamais alignées avec les évolutions ultérieures de la plateforme mutualisée.
Comment un réseau homogène finit par se fragmenter
Le réseau avait grandi progressivement, une commune après l’autre, chacune avec sa propre zone Cloudflare provisionnée au moment de son adhésion. Les premières communes raccordées avaient reçu une configuration de cache écrite manuellement, avant que l’équipe ne standardise sa procédure via un script de provisioning automatisé. Les configurations manuelles initiales, elles, n’avaient jamais été rétroactivement mises à jour, chaque commune conservant ses propres règles héritées du jour de son adhésion.
Ce que l’audit a révélé, zone par zone
| Type d’écart constaté | Nombre de zones concernées | Risque associé |
|---|---|---|
| Durée de cache par défaut différente (entre 1 minute et 24 heures) | 212 | Contenu obsolète ou charge serveur excessive |
| Règles de purge automatique absentes après webhook | 89 | Contenu périmé affiché après publication |
| En-têtes de sécurité (CSP, HSTS) incomplets ou absents | 134 | Exposition à des attaques par script |
| Règles de limitation de débit (rate limiting) absentes | 301 | Vulnérabilité aux pics de trafic malveillant |
L’origine profonde du problème : pas de source de vérité unique
Aucune des 500 zones n’était gérée depuis une configuration centralisée : chaque zone avait été créée et modifiée au fil du temps via l’interface web Cloudflare, sans jamais passer par une gestion en tant que code (infrastructure as code). Cette absence de source de vérité rendait tout audit manuel extrêmement long, et surtout rendait impossible toute garantie que deux communes, en apparence identiques, appliquaient réellement les mêmes protections.
Le correctif : un modèle de configuration commun via Terraform
La solution retenue s’appuie sur le fournisseur Terraform officiel de Cloudflare, permettant de décrire l’ensemble des règles (cache, sécurité, limitation de débit) dans un module réutilisable, appliqué ensuite à chacune des 500 zones avec uniquement les paramètres réellement variables d’une commune à l’autre (nom de domaine, identifiant de zone) :
module "commune_cache_rules" {
source = "./modules/cloudflare-commune"
zone_id = var.zone_id
cache_ttl = 300
purge_on_webhook = true
security_headers = {
csp = "default-src 'self'; img-src * data:;"
hsts = "max-age=63072000; includeSubDomains"
}
rate_limit_threshold = 200
}Le déploiement progressif, zone par zone
Appliquer directement ce modèle commun aux 500 zones d’un coup présentait un risque trop important en cas d’erreur de configuration. Le déploiement s’est fait par vagues de vingt communes, avec une période d’observation de 48 heures entre chaque vague, permettant de détecter rapidement tout effet de bord avant d’étendre le changement au reste du réseau.
- Migration vers une gestion en tant que code de l’ensemble des zones Cloudflare du réseau.
- Déploiement par vagues, avec période d’observation entre chaque lot de communes.
- Contrôle automatisé mensuel comparant la configuration réelle de chaque zone au modèle de référence attendu.
Un réseau qui grandit une entité à la fois finit toujours, sans discipline explicite, par accumuler des divergences invisibles ; la seule parade durable reste une configuration décrite comme du code, jamais comme une suite de clics dans une interface.
En résumé
L’homogénéité apparente d’un réseau de sites headless mutualisés ne garantit en rien l’homogénéité réelle de sa configuration d’infrastructure, particulièrement sur un service tiers comme Cloudflare, géré historiquement zone par zone. Le passage à une gestion en tant que code, bien que coûteux à mettre en place sur un parc de 500 sites, reste la seule façon de garantir durablement que toutes les communes du réseau bénéficient effectivement des mêmes protections.
