Le déploiement instantané, c’est pratique, mais rarement indispensable.

Cloudflare contextualise ainsi sa décision d’appliquer aux changements de configuration le même processus de contrôle que pour le code.

Lors de mises à jour logicielles, chaque version binaire a plusieurs étapes de validation à franchir. Toute équipe possédant un service doit définir un plan de déploiement, des indicateurs de réussite/échec et les actions à entreprendre en cas de problème. Un système automatisé exécute ce plan et déclenche si nécessaire une restauration, en alertant éventuellement l’équipe.

Ce mécanisme sera également appliqué aux changements de configuration d’ici à fin mars sur toute la prod, nous promet-on.

En toile de fond, les deux pannes importantes survenues le 18 novembre et le 5 décembre 2025. L’un et l’autre furent déclenchées par un changement de configuration (dans le classificateur de bots pour la première ; dans un outil de sécurité pour la seconde).

Isoler les défaillances

Cloudflare a un autre engagement d’ici à fin mars : réviser les contrats d’interface entre chaque produit et service critique, pour mieux anticiper et isoler les défaillances.

L’incident de novembre est un exemple en la matière. Deux interfaces-clés auraient pu être gérées différemment, estime Cloudflare. D’une part, celle qui lisait le fichier de configuration (il aurait dû exister un ensemble de valeur par défaut validées permettant au trafic de continuer à circuler). De l’autre, celle située entre le logiciel central et le module de gestion des bots (en cas de défaillance de ce dernier, le trafic n’aurait pas dû être bloqué par défaut).

Éliminer – ou contourner – les dépendances circulaires

Cloudflare entend aussi supprimer les dépendances circulaires, ou tout du moins permettre de les « contourner » rapidement en cas d’incident. Exemple : lors de l’incident de novembre, l’indisponibilité de Turnstile (alternative aux CAPTCHA) a empêché les clients d’accéder au tableau de bord à moins qu’ils eussent une session active ou un jeton d’API.

En parallèle, il est question de faire évoluer les procédures internes de type break glass (élévations temporaires de privilèges) pour avoir accès aux bons outils le plus rapidement possible.

Un « code orange » pour la deuxième fois

Pour mettre en place ce plan de résilience, Cloudflare a décrété un « code orange ». Cette procédure permet de réorienter la plupart des ressources techniques vers la résolution d’un incident. Elle a été mise en œuvre une fois par le passé. C’était fin 2023, après une panne de courant dans un des principaux datacenters de Cloudflare (PDX01, dans l’Oregon), hébergeant le plan de contrôle de nombreux services. Le déclencheur : des opérations de maintenance réalisées par l’exploitant du réseau électrique et qui avaient entraîné un défaut de terre dans l’installation.

Illustration générée par IA

The post Cloudflare engage un plan de résilience : les grands axes appeared first on Silicon.fr.