Sur 18 novembre 2025, Un seul incident technique chez Cloudflare a suffi pour que des centaines de millions de personnes aient l'impression qu'une grande partie de l'internet est “en panne”.

Pendant quelques heures, les utilisateurs qui tentaient d'accéder à des plateformes telles que X, ChatGPT, Spotify, Canva, Grindr et des milliers d'autres sites ont été accueillis par le même message : une “erreur de serveur interne sur le réseau de Cloudflare” et des pages 500 génériques au lieu des services sur lesquels ils comptent tous les jours. Cloudflare, qui gère environ un cinquième du trafic web mondial, a signalé une erreur de serveur interne sur son réseau. question du réseau mondial qui a entraîné un grand nombre d'erreurs (500) et a eu des répercussions sur son tableau de bord et son API, avant de déployer progressivement un correctif et de stabiliser son infrastructure.

Des incidents se produisent. Des bogues existent. Aucun système n'est parfait.

Le vrai problème est que l'ensemble de notre écosystème numérique est aujourd'hui profondément dépendant de quelques points d'étranglement infrastructurels - et la plupart des organisations ne disposent même pas d'une carte claire de ces dépendances.

C'est de cela que je veux parler ici : non pas pour pointer du doigt Cloudflare, mais pour utiliser cette panne comme un rappel concret et global de la raison pour laquelle résilience et dépendance numérique doivent devenir des sujets de premier ordre dans toutes les salles de réunion.

Cloudflare comme point de défaillance unique

Cloudflare fait ce qu'il est censé faire : absorber les attaques, accélérer le trafic, mettre le contenu en cache à la périphérie, mettre fin à TLS et rendre les “mauvais jours” moins visibles.

Mais la panne d'aujourd'hui a montré le revers de la médaille :

• Lorsque vous placez une grande partie de votre trafic en contact avec la clientèle derrière un site Web, vous pouvez vous concentrer sur la gestion de votre trafic. intermédiaire unique,
• Et lorsque cet intermédiaire fournit également DNS, WAF, CDN, protection DDoS, passerelles API, filtrage des robots, Turnstile/captcha, etc.,
• Un seul bogue latent ou un problème de réseau interne dans cet intermédiaire peut alors s'amplifier en une panne systémique affectant des milliers de services simultanément.

La plupart des utilisateurs n'ont pas dit “Cloudflare est en panne” aujourd'hui.
Ils ont dit “X est en panne”, “ChatGPT est en panne”, “le site web de ma banque ne fonctionne pas”, “mon outil SaaS est en panne”.

D'un point de vue technique, nombre de ces services étaient sains à l'origine. Le problème se situait au milieu : dans le tissu conjonctif de l'internet.

La dépendance numérique n'est pas abstraite, elle est stratifiée

Lorsque nous parlons de dépendance numérique, Il ne s'agit pas seulement de dire “nous utilisons Cloudflare” ou “nous sommes sur AWS”.

Il s'agit de les chaînes de dépendance:

• Votre application dépend d'un CDN ou d'un fournisseur de reverse-proxy.
• Ce fournisseur dépend de plusieurs opérateurs de transit et de liaisons dorsales.
• Votre DNS dépend d'un bureau d'enregistrement spécifique et d'un petit nombre de fournisseurs faisant autorité.
• Votre authentification peut dépendre d'un fournisseur d'identité tiers.
• Votre service client peut dépendre d'un seul chatbot SaaS ou d'une seule plateforme de billetterie.
• Et tout cela relève souvent d'une ou deux juridictions.

La plupart des organisations n'ont pas de vue structurée de ces dépendances.
Ils voient leurs propres applications, peut-être leur fournisseur de services en nuage. Mais ils ne voient pas l'ensemble de la pile de.. :

• Logiciel
• Infrastructure
• Services de tiers
• Exposition juridictionnelle et géopolitique

L'incident d'aujourd'hui est exactement le type d'événement qui met en évidence cet angle mort.

Présentation de l'IRN : Indice de Résilience Numérique

Au cours des derniers mois, j'ai travaillé avec d'autres personnes sur une norme ouverte appelée IRN - Indice de Résilience Numérique.

Vous trouverez plus d'informations ici : resiliencenumerique.com.

L'idée qui sous-tend l'IRN est simple mais ambitieuse :

Fournir une méthode structurée et transparente pour mesurer et visualiser la résilience d'un système d'information en cartographiant ses dépendances dans les domaines technique, organisationnel, juridique et géopolitique.

Concrètement, l'IRN est destiné à aider les organisations :

• Identifier leur composants critiques et les chaînes de dépendance qui les sous-tendent (DNS, CDN, PaaS, SaaS, centres de données, juridictions, fournisseurs...).
• Comprendre où ils se trouvent trop dépendant sur un seul fournisseur, une seule région ou une seule technologie.
• Simulez l'impact d'événements tels que la panne de Cloudflare d'aujourd'hui ou une panne de nuage à l'échelle régionale.
• Plan stratégies d'atténuationLes questions suivantes peuvent être posées : DNS multi-fournisseurs, multi-CDN, multi-cloud, fallback on-prem, clauses contractuelles, etc.

L'IRN n'est pas un produit, c'est une langage et méthodologie communs.
Une norme ouverte que chacun peut adopter, étendre ou mettre en œuvre.

Un petit pas pragmatique vers l'open source : le basculement multi-DNS et multi-CDN

Parallèlement à ce travail conceptuel, j'ai voulu proposer quelque chose d'immédiatement utilisable aujourd'hui.

J'ai donc publié un projet open source sur GitHub qui met en œuvre un système de gestion de l'information. une résilience très pragmatique autour du type d'événement que nous avons vu aujourd'hui :

Un minimum Boîte à outils de basculement multi-DNS / multi-CDN qui maintient la synchronisation entre Cloudflare DNS et deSEC (EU and open-source based + free) DNS, et vous permet de basculer automatiquement le trafic entre Cloudflare et un CDN secondaire (par exemple Bunny) lorsque le chemin principal n'est pas sain.

Les idées maîtresses :

• Utilisation Cloudflare + deSEC en tant que fournisseurs de DNS faisant autorité (multi-NS).
• Modélisez un petit sous-ensemble de votre zone DNS dans un fichier YAML (non destructif ; il ne touche jamais aux enregistrements que vous ne déclarez pas).
• Introduire un web-router.example.com CNAME qui pointe soit vers :
  • cf-front.example.com (devant Cloudflare), ou
  • cdn2-front.example.com (front CDN secondaire).
• Utilisez un petit script Python pour :
  • Vérifiez l'état de santé de votre chemin principal,
  • Revenir au chemin secondaire si nécessaire,
  • Mettre à jour le CNAME du routeur dans à la fois Cloudflare et deSEC via API.

Il ne s'agit pas d'une “solution à tout”.
Mais il s'agit d'un élément concret que vous pouvez intégrer à votre propre infrastructure dans le cadre d'une stratégie de résilience plus large.

La résilience est un état d'esprit, pas une case à cocher

S'il y a une leçon que j'espère que nous retiendrons tous d'aujourd'hui, c'est celle-ci :

• Interruptions chez les hyperscalaires et les fournisseurs d'accès internet critiques volonté se reproduire.
• Elles ne sont pas totalement évitables.
• Ce que nous pouvons changer, c'est l'ampleur des dégâts qu'ils causent à nos sociétés, à nos organisations et à nos utilisateurs.

En d'autres termes :

• Cartographier systématiquement nos dépendances (c'est l'objectif de l'IRN).
• Concevoir des architectures qui supposent que les fournisseurs peuvent tomber en panne (multi-DNS, multi-CDN, multi-cloud, dégradation gracieuse).
• Tester régulièrement nos scénarios (ingénierie du chaos, journées de jeu, exercices de l'équipe rouge).
• Sortir les discussions sur la résilience du domaine purement technique pour les intégrer dans la stratégie, la gouvernance et la réglementation.

La panne de Cloudflare survenue aujourd'hui en a gêné plus d'un.
Demain, un événement similaire pourrait avoir un impact sur soins de santé, énergie, sécurité publique, stabilité financière si nous n'y prenons pas garde.

Si vous êtes intéressé par ces sujets, la résilience, la dépendance numérique, l'IRN ou les outils open source que je publie, n'hésitez pas à me contacter. Ce travail avancera plus vite si nous le construisons ensemble.