Le 18 novembre 2025, une partie significative du web a vacillé pendant plusieurs heures à cause d'un incident de configuration BGP côté Cloudflare. Beaucoup de sites WordPress, y compris des sites e-commerce sérieux, étaient injoignables ou répondaient en 522 et 530. Côté WPHelp247, nous avons vu plusieurs sites clients impactés malgré nos garde-fous. Voici ce que cet incident dit des dépendances cachées d'un site WordPress, et la check-list ops qu'on a mise à jour depuis.

Ce qui s'est passé techniquement

Cloudflare opère un réseau global qui annonce des routes BGP pour servir le trafic depuis les datacenters les plus proches des visiteurs. Le 18 novembre, un changement de configuration a propagé une route incorrecte sur une partie du réseau, ce qui a coupé l'accès à plusieurs services internes pendant que les ingénieurs déroulaient un rollback. L'impact a été partiel mais durable, avec un pic d'erreurs entre 11h et 14h UTC, et des effets de cache résiduels jusqu'en début de soirée.

Pour un site WordPress derrière Cloudflare, le symptôme classique a été une réponse 522 (connection timeout) ou 530 (origin DNS error) à intermittence. Côté visiteur, ça donne soit une page d'erreur Cloudflare, soit un blanc. Côté admin WordPress, l'accès au backoffice fonctionnait souvent même quand le frontoffice ne répondait plus, ce qui peut donner l'illusion fausse que tout va bien.

Ce qu'on a vu côté WPHelp247

Notre monitoring a remonté les premières alertes vers 11h12 UTC. Plusieurs sites clients hébergés derrière Cloudflare ont basculé en dégradé. Sur les sites les plus sensibles (e-commerce avec un pic de commandes en cours), nous avons déclenché une procédure de contournement DNS : route directe vers l'origine, désactivation temporaire du proxy Cloudflare, le tout en quelques minutes par site.

Le bilan a été modéré, mais il a confirmé une chose qu'on disait depuis longtemps en interne : un site WordPress sérieux ne devrait pas dépendre d'un seul fournisseur en chemin critique. Pas par méfiance envers Cloudflare, dont les services sont remarquables, mais parce que tout fournisseur a des incidents tôt ou tard, et que le rôle d'un opérateur sérieux est de prévoir ce que personne ne souhaite voir arriver.

Les dépendances cachées d'un site WordPress

Quand on regarde un site WordPress avec attention, on découvre rapidement entre cinq et quinze dépendances externes, dont beaucoup sont invisibles au propriétaire :

  • DNS : Cloudflare, Route 53, OVH DNS, Gandi… La résolution DNS conditionne l'accès au site et l'envoi d'email.
  • CDN et proxy : Cloudflare, BunnyCDN, KeyCDN ou similaires. Ils servent les assets statiques et parfois les pages HTML.
  • Hébergement origin : OVH, Hetzner, AWS, Azure, Foxop… Le serveur qui fait tourner WordPress.
  • Email transactionnel : Brevo, Mailgun, SendGrid, Amazon SES. Sans eux, plus de confirmation de commande ni de reset password.
  • Stripe ou autre passerelle de paiement : leur disponibilité conditionne directement le chiffre d'affaires.
  • Plugins SaaS : Yoast Premium, WP Rocket, formulaires connectés à un CRM externe (HubSpot, Salesforce, Pipedrive).
  • Polices web : Google Fonts, Adobe Fonts, ou auto-hébergées.
  • Images hébergées ailleurs : Cloudinary, Imgix, un CDN d'images.

Chaque dépendance est un point de défaillance possible. Le 18 novembre, c'était Cloudflare. Le 19 décembre 2023, c'était OpenAI dont l'API a coupé pendant trois heures, ce qui a impacté tous les plugins WordPress qui appellent ChatGPT en synchrone. Et ainsi de suite.

Check-list pour réduire votre exposition

Voici la check-list qu'on applique systématiquement sur les sites sous bundle WPHelp247 (Sérénité, Premium, ou Tranquille selon le périmètre), mise à jour depuis l'incident. Sur un plan d'hébergement seul, ces actions restent à votre charge ou peuvent être déléguées via un pack d'heures :

  1. Cartographier les dépendances : faire la liste de tout ce dont le site dépend pour servir une page, valider une commande, envoyer un email. Cinq minutes par site, c'est déjà très instructif.
  2. Tester la route de contournement : si Cloudflare tombe, savoir comment basculer le DNS vers l'origine en moins de 10 minutes. Documenter la procédure, l'avoir testée au moins une fois.
  3. Fallback sur les services critiques : un email transactionnel via Brevo peut être doublé d'un SMTP secondaire (Mailgun, AWS SES) configuré en standby. Idem pour les passerelles de paiement quand c'est pertinent.
  4. Monitoring multi-source : ne pas mesurer la disponibilité du site uniquement depuis Cloudflare. Avoir un check externe (UptimeRobot, Pingdom, ou notre monitoring interne) qui vérifie le site sans passer par le CDN.
  5. Cache aggressif sur les pages froides : un cache HTML correctement configuré (Cloudflare Cache Everything, ou un proxy origin type Varnish) peut servir les pages statiques même si l'origine est temporairement indisponible.
  6. Page d'erreur custom : configurer une page d'erreur 5xx propre côté Cloudflare ou côté CDN, avec un message rassurant et un email de contact. C'est dix fois mieux qu'une page Cloudflare grise.
  7. Communication client préparée : avoir un template d'email et un template de post Twitter/LinkedIn prêt pour le jour où ça arrive. Le silence est le pire choix quand un site est down.

Le rôle de l'hébergeur dans tout ça

Un hébergement WordPress sérieux ne se résume pas à un serveur qui tient. C'est aussi la prévision des défaillances en chaîne, les procédures de contournement documentées, le monitoring multi-source, et la capacité à intervenir dans la fenêtre de quelques minutes quand un incident chez un tiers commence à impacter vos clients.

C'est exactement ce que nous opérons chez WPHelp247. L'hébergement seul (Starter, Pro, Business) fournit l'infrastructure, le staging à la demande (Pro et Business) et la préprod isolée (Business). Pour la veille active, la procédure de bascule en cas d'incident tiers et la communication client le jour J, il faut un bundle qui combine hébergement et heures de maintenance, ou un pack d'heures à consommer à la demande. Si vous voulez d'abord évaluer où sont les dépendances cachées de votre site actuel, commencer par un mini-audit gratuit chez WPCraft est probablement le point d'entrée le plus pragmatique.

Ce qu'on a changé depuis le 18 novembre

Trois choses, concrètement. D'abord, le runbook de contournement DNS a été remis à jour et testé sur l'ensemble des sites sous bundle WPHelp247 (sept minutes en moyenne pour basculer un site, à la louche). Ensuite, le monitoring externe a été doublé pour ne plus dépendre d'une seule source. Enfin, sur les hébergements Business qui incluent une préprod isolée, on a ajouté une route de bascule rapide qui permet de servir le site directement depuis cet environnement en cas d'incident origin majeur.

Aucun de ces garde-fous n'élimine totalement le risque qu'un fournisseur tombe. Ils réduisent juste considérablement la fenêtre de temps où vos clients voient une page d'erreur au lieu de votre site.