Amazon Web Services (AWS) en panne à cause de Cloudflare le 18 novembre 2025 : que s’est-il vraiment passé ?
Ce mardi 18 novembre 2025, une partie d’Internet s’est retrouvée au ralenti, voire totalement KO. En cause : une panne majeure chez Cloudflare, l’un des principaux acteurs de l’infrastructure du Web, qui a provoqué des erreurs en cascade sur de nombreux services, dont certains s’appuyant sur Amazon Web Services (AWS).
Si le lien de causalité direct entre Cloudflare et une éventuelle panne globale d’AWS reste nuancé, les clients d’AWS ont clairement ressenti la tempête : applications inaccessibles, tableaux de bord lents ou indisponibles, et messages d’erreur à répétition.
Une panne Cloudflare qui met le Web à genoux
En fin de matinée, de nombreux internautes commencent à rencontrer des erreurs « 500 » ou « internal server error » sur des services qui, en apparence, n’avaient jamais posé de problème particulier. En creusant un peu, un point commun ressort : le trafic passe par Cloudflare.
Cloudflare joue plusieurs rôles clés pour des millions de sites et d’applications :
- CDN (Content Delivery Network) pour accélérer le chargement des contenus.
- Bouclier de sécurité contre les attaques DDoS et le trafic malveillant.
- Reverse proxy qui se place entre l’internaute et le serveur d’origine (souvent hébergé chez AWS ou un autre cloud).
Lorsque Cloudflare dysfonctionne, le trafic ne parvient tout simplement plus jusqu’aux serveurs d’origine. Résultat : pour l’utilisateur final, le site ou l’application est « en panne », même si, techniquement, les serveurs continuent de tourner.
AWS touché… par ricochet
Officiellement, AWS n’a pas subi ce jour-là une panne interne massive comparable à certains incidents passés. Pourtant, dans les faits, de nombreux services hébergés chez AWS sont devenus inaccessibles, non pas parce que le cloud d’Amazon était cassé, mais parce que l’« entrée » vers ces services – assurée par Cloudflare – était bloquée.
Pour un client AWS qui utilise Cloudflare comme couche frontale, le scénario est simple :
- L’utilisateur saisit l’URL de l’application.
- La requête arrive d’abord chez Cloudflare.
- Cloudflare doit ensuite contacter les serveurs AWS.
- Si Cloudflare rencontre un problème (réseau, configuration, routage, surcharge), la requête n’atteint jamais AWS.
- L’application est perçue comme hors service, alors même que l’infrastructure AWS fonctionne.
C’est ce décalage entre la réalité technique et la perception qui amène beaucoup d’utilisateurs à dire qu’« AWS est tombé à cause de Cloudflare ». Du point de vue de l’utilisateur final, la nuance importe peu : ça ne marche pas.
Un écosystème ultra-interconnecté et fragile
L’épisode du 18 novembre 2025 illustre un problème structurel : la très forte concentration de l’infrastructure du Web entre quelques acteurs majeurs.
D’un côté, les grands clouds :
- Amazon Web Services
- Google Cloud
- Microsoft Azure
De l’autre, les grands acteurs de l’edge, des CDN et des proxies :
- Cloudflare
- Akamai
- Fastly
Entre eux, les interconnexions sont permanentes : un site peut être hébergé sur AWS, protégé par Cloudflare, avec du trafic optimisé par un autre fournisseur, et s’appuyer sur des APIs externes elles-mêmes hébergées sur un troisième cloud.
Conséquence :
- Une panne Cloudflare peut donner l’impression qu’AWS, Azure ou Google Cloud sont « en panne », alors que seuls les points d’entrée sont affectés.
- Une panne majeure d’un cloud peut, à l’inverse, faire exploser la charge sur les CDN, ou rendre instables les services qui en dépendent indirectement.
Internet ressemble de plus en plus à un château de cartes géant : solide dans son ensemble, mais vulnérable lorsqu’un acteur clé flanche.
Les conséquences pour les entreprises et les utilisateurs
Pour les entreprises qui avaient construit leurs services sur AWS avec Cloudflare en façade, la journée a pu être compliquée :
- Applications SaaS indisponibles : outils métiers, CRM, plateformes de facturation, intranets.
- Sites e-commerce perturbés : impossibilité de se connecter, de consulter son compte ou de finaliser une commande.
- Support surchargé : afflux de tickets, d’appels et de messages d’utilisateurs mécontents.
Dans certains cas, seule une partie des utilisateurs était impactée, selon :
- leur localisation géographique ;
- la route réseau empruntée ;
- le ou les datacenters Cloudflare utilisés ;
- l’existence (ou non) de mécanismes de bascule vers d’autres fournisseurs.
Mais pour la plupart des clients finaux, une seule conclusion : « ça ne marche pas ».
Ce qu’ont communiqué Cloudflare et AWS
Du côté de Cloudflare, la panne du 18 novembre est reconnue comme un incident majeur, avec une hausse très importante des erreurs 5xx sur une partie du réseau et un travail d’investigation annoncé sur les causes profondes.
Du côté d’AWS, les tableaux de bord de santé des services peuvent très bien rester au vert, ou n’afficher que des perturbations limitées : le cœur de l’infrastructure n’est pas forcément en cause. Pourtant, de nombreux clients AWS souffrent concrètement, parce que leur exposition au Web dépend d’un intermédiaire défaillant.
On se retrouve donc avec :
- Cloudflare qui assume une panne notable, affectant des millions de requêtes.
- AWS qui n’est pas la source de la panne, mais qui voit une partie de ses clients impactés par ce point de défaillance externe qu’ils ont choisi pour mettre leurs services en vitrine sur Internet.
Le vrai sujet : la dépendance à un seul point d’entrée
L’épisode met en lumière un angle mort de beaucoup d’architectures : la dépendance à un seul fournisseur pour la couche « front » (DNS, CDN, proxy, sécurité). Pour simplifier la gestion, réduire les coûts ou profiter de fonctionnalités avancées, les entreprises concentrent parfois l’intégralité de leur exposition Web sur un seul acteur.
En théorie, cette centralisation simplifie la vie. En pratique, elle crée un point de défaillance unique : si ce fournisseur tombe, tout suit.
Ce 18 novembre 2025, de nombreuses équipes techniques ont pris conscience que leur résilience ne dépendait pas seulement de la qualité de leurs instances AWS, de leurs bases de données ou de leur code… mais aussi, et parfois surtout, de la robustesse du maillon unique qui relie leurs serveurs au reste d’Internet.
Que peuvent faire les DSI et développeurs maintenant ?
Même si tous les détails techniques de la panne ne sont pas encore disséqués dans le moindre log, on peut déjà tirer plusieurs leçons pratiques.
1. Diversifier les fournisseurs critiques
- Éviter, quand c’est possible, de confier DNS + CDN + proxy + sécurité à un seul acteur.
- Envisager un second fournisseur de CDN/proxy, même utilisé uniquement en secours.
2. Prévoir des scénarios de bascule
- Documenter une procédure claire pour changer rapidement les enregistrements DNS en cas de panne d’un fournisseur.
- Prévoir un domaine ou sous-domaine de secours pointant directement vers les endpoints AWS.
3. Garder une porte d’entrée « directe »
- Maintenir des interfaces d’administration ou de supervision accessibles sans passer par le fournisseur en panne.
- Permettre aux équipes internes de vérifier, en cas d’incident, si les serveurs AWS fonctionnent réellement.
4. Améliorer la communication de crise
- Préparer des messages types pour expliquer aux clients qu’un incident d’infrastructure externe affecte temporairement le service.
- Être transparent sur les actions entreprises pour réduire l’impact et sur les mesures prévues pour l’avenir.
5. Tester la résilience, pas seulement les fonctionnalités
- Simuler régulièrement la coupure d’un fournisseur clé (DNS, CDN, proxy) en environnement de test.
- Mesurer la capacité de l’entreprise à continuer à opérer malgré une panne d’un acteur majeur.
AWS « en panne à cause de Cloudflare » : une formule simplifiée pour une réalité complexe
Dire qu’« AWS est tombé à cause de Cloudflare » résume le ressenti d’innombrables utilisateurs le 18 novembre 2025. Dans les faits, la situation est plus subtile :
- Cloudflare a subi une panne majeure, très visible à l’échelle du Web.
- AWS a été surtout touché par ricochet, via les architectures de ses clients qui reposaient entièrement sur Cloudflare pour exposer leurs services.
- L’incident révèle à quel point les interconnexions entre grands fournisseurs d’infrastructure peuvent engendrer des vulnérabilités systémiques.
Pour l’internaute, la conclusion reste simple : si la page ne charge pas, « c’est en panne ».
Pour les architectes, DSI et développeurs, cet épisode doit servir d’avertissement : la haute disponibilité ne se joue pas seulement dans les datacenters d’AWS, mais aussi dans tous les maillons intermédiaires – à commencer par ces acteurs, comme Cloudflare, qui se trouvent désormais au cœur de l’Internet moderne.
