Panda SecurityLa chute de la principale plateforme d’infrastructure cloud au monde a provoqué une panne généralisée de sites, d’applications et de réseaux sociaux dépourvus de plans de secours. Sans plan B, c’est la paralysie totale — et parfois l’invisibilité — augmentant les risques d’intrusion.
Le moteur s’est arrêté
Le lundi matin 20 octobre 2025, de nombreux sites web, applications et réseaux sociaux se sont retrouvés dans le noir à cause d’une panne mondiale d’Amazon Web Services (AWS), la plus grande plateforme d’infrastructure cloud au monde. Aux États-Unis, il a été impossible d’accéder à Amazon, Alexa, Prime Video, Crunchyroll, Canva, Perplexity et Duolingo, ainsi qu’à des réseaux comme Snapchat ou Goodreads, et à des jeux tels que Fortnite, Roblox ou Clash Royale. En Europe, plusieurs services ont également connu les mêmes problèmes d’accessibilité.
Conséquences immédiates sur l’expérience utilisateur et la disponibilité des services
« Cela arrive parce que de nombreuses pièces invisibles d’Internet vivent dans AWS », explique Hervé Lambert, Global Consumer Operations Manager chez Panda Security. « Quand cette plateforme tombe, ce n’est pas seulement un serveur qui s’éteint : ce sont des services essentiels dont dépendent sites, applications et réseaux sociaux — qu’ils soient internes ou tiers — qui cessent de fonctionner. » En d’autres termes, « tout s’arrête car ils partagent la même infrastructure et les mêmes services de base — calcul, stockage, DNS, authentification et CDN — qu’ils soient hébergés sur AWS ou sur des prestataires qui en dépendent. Si ces couches échouent et qu’il n’existe ni architecture multi-région ni plan de secours, toute l’expérience utilisateur — charger, se connecter, payer ou publier — s’effondre en cascade. »
Lors d’une panne de cette ampleur, poursuit Lambert, « certaines applications ne disposent plus de ressources pour servir les pages, les API ou les flux, car elles fonctionnent sur EC2, EKS ou Lambda ; un incident peut survenir au niveau des nœuds ou du plan de contrôle. Il n’y a plus d’endroit où lire ou stocker les données : le site ou l’application ne peut plus charger de contenu ni authentifier les utilisateurs.
L’identification échoue, car les systèmes d’authentification comme Cognito, STS/AssumeRole ou SSO hébergés sur AWS cessent d’émettre des jetons ; le trafic ne sait plus où aller : si le DNS ne résout plus ou si le CDN ne peut plus atteindre la source, les domaines ne répondent pas ou le font de manière erratique. Et même si une application n’est pas hébergée sur AWS, elle subit tout de même des perturbations si ses prestataires y sont, car la chaîne entière fonctionne comme un château de cartes. »
Pourquoi les pannes d’AWS impactent services et applications
Mais il y a pire encore : lorsque AWS tombe ou se dégrade, « certaines entreprises peuvent se retrouver complètement aveugles, car leur observabilité dépend de cette même plateforme », avertit le responsable de Panda Security. « C’est le cas, par exemple, lorsqu’elles hébergent dans la même région leurs outils CloudWatch, CloudTrail, GuardDuty, leurs SIEM, tableaux de bord, alertes SNS/SES ou leur SSO », énumère Lambert, ajoutant que « si ces éléments tombent ou prennent du retard, les sites peuvent se retrouver sans métriques, sans journaux et sans moyen d’accès avec des identifiants valides, donc exposés. » Tout cela peut être évité « si la supervision, les journaux et les identités disposent d’une sortie d’urgence en dehors de la zone affectée. »
Beaucoup d’entreprises, toutefois, concentrent tout dans une seule région et un seul compte — « y compris les sauvegardes et les clés KMS », précise l’expert de Panda Security. « Sans bascule multi-région, l’indisponibilité est totale. Sous la pression, certaines équipes ouvrent des security groups, désactivent le WAF ou élargissent les permissions IAM pour faire redémarrer les systèmes, provoquant souvent des dégâts supplémentaires ou exposant davantage l’application. »
L’importance d’un « plan B »
Pourquoi, alors, n’existe-t-il pas de plans de secours, alors que les risques de panne sont si importants ?
« Parce qu’ils ne sont pas encouragés, semblent coûteux et demandent un effort technique », résume Lambert en trois raisons. « Beaucoup de sites, d’applications et de réseaux sociaux n’ont pas de plan B parce que leurs priorités sont mal alignées : le business valorise la rapidité plutôt que la résilience ; il existe une fausse impression de sécurité et l’on pense que “cela n’arrivera pas chez nous”. De plus, la multi-région, la multi-compte, la réplication des données, les identités redondantes, les runbooks et les tests paraissent doubler les coûts. On part du principe qu’AWS ne tombera pas ou que le SLA couvrira les pertes — ce qui est faux. »
C’est là qu’entre en jeu le concept — encore trop peu répandu — de security by design. « Aujourd’hui encore, beaucoup d’organisations n’intègrent pas la cybersécurité dès les premières phases de développement de leurs produits, services ou infrastructures. Cela ne signifie pas que les entreprises touchées aujourd’hui ont mal fait, mais il est fréquent que, plutôt que de construire des systèmes résilients dès le départ, on ajoute des mesures réactives en fin de cycle de vie. Cette approche réactive, en plus d’être moins efficace, s’avère à long terme beaucoup plus coûteuse et difficile à maintenir. »
Pour rompre ce cercle vicieux, il faut, conclut Lambert, « intégrer la résilience dans les indicateurs clés de performance, séparer comptes et régions, automatiser les sauvegardes et les garde-fous, et réaliser des tests de bascule. Ce sera toujours moins cher que d’expliquer à des milliers d’utilisateurs pourquoi votre service a disparu. »
