Une région tombe, la moitié de la chaîne d’approvisionnement est à l’arrêt
Un risque de concentration en cloud est un risque lié aux chaînes d'approvisionnement.
Le 20 octobre 2025, une partie d’Internet s’est arrêtée. Slack, Snapchat et Atlassian étaient injoignables pendant des heures, les boutiques en ligne ont perdu des commandes, les prestataires logistiques n’ont pas pu traiter les envois. Le déclencheur résidait dans une seule région AWS de la côte Est des États-Unis. Cette panne révèle une vérité inconfortable : la concentration du cloud n’est pas seulement un sujet informatique, mais un risque pour la chaîne d’approvisionnement.
Les points clés en bref
- Une région suffit. La panne AWS d’octobre 2025 a commencé par une entrée DNS vide dans us-east-1, paralysant pendant plus de 15 heures Slack, Snapchat et des milliers de boutiques en ligne.
- La concentration est un risque pour la chaîne d’approvisionnement. La gestion d’entrepôt, le suivi des envois et le traitement des paiements passent par le cloud. Si le cloud tombe, la chaîne d’approvisionnement physique s’arrête avec lui.
- Le multi-cloud n’est rarement la réponse. Un deuxième fournisseur double la complexité et les coûts, pas la sécurité. Pour la plupart des PME, une configuration multi-région testée est la première étape plus judicieuse.
Similaire :Séparer proprement NIS2 et DORA : clusters de conformité dans Kubernetes / Sauvegarde cloud avec IaC : résilience plutôt que risque de restauration
Ce qui s’est passé dans us-east-1
La panne a débuté par une minuscule erreur dans la gestion du DNS du service de base de données DynamoDB. Une condition de concurrence a généré une entrée DNS vide pour le point de terminaison régional. L’automatisation ne l’a pas réparée. Le DNS est le répertoire téléphonique d’Internet. Si l’entrée était vide, les applications ne trouvaient tout simplement plus la base de données.
De ce problème initial sur DynamoDB est née une cascade. Les instances EC2 ne pouvaient plus démarrer, les fonctions Lambda et les tâches Fargate échouaient, les équilibreurs de charge et les services de conteneurs tombaient également. Ce qui a commencé comme une perturbation de base de données de trois heures s’est étalé sur plus de 15 heures, jusqu’à ce que tous les services dépendants soient de nouveau opérationnels.
Pourquoi une région paralyse la moitié du monde
us-east-1 n’est pas une région quelconque. C’est la région AWS la plus ancienne et la plus grande, abritant des fonctions de contrôle dont dépendent d’autres régions. Certains services globaux, comme les mises à jour IAM ou les tables globales DynamoDB, fonctionnent centralement via us-east-1. En cas de panne, cela affecte aussi les clients qui pensent être hébergés ailleurs.
C’est précisément ici que réside l’erreur de raisonnement de nombreux plans de secours. Une entreprise peut répartir proprement son application sur plusieurs régions et rester coincée parce que le niveau de contrôle est concentré dans une seule région. La résilience sur papier n’est pas la même chose que la résilience en situation réelle.
Le problème de la chaîne d’approvisionnement derrière la panne IT
Pour la logistique et le commerce, une telle panne n’est pas un problème technique abstrait. La gestion d’entrepôt, le suivi des envois, la prise de commandes et le traitement des paiements reposent de plus en plus sur des services cloud. Si le cloud tombe, la chaîne d’approvisionnement physique s’arrête avec lui. Une heure d’immobilisation peut coûter cinq chiffres en euros à un commerçant de taille moyenne, et bien plus pour les plus grands.
Les régulateurs l’ont compris. Avec DORA pour le secteur financier et NIS2 plus largement, le risque de concentration se place sous les projecteurs. Les entreprises devront bientôt prouver qu’elles connaissent et maîtrisent leur dépendance envers des fournisseurs et des régions spécifiques. Se référer globalement au cloud ne suffira plus.
Pourquoi le multi-cloud n’est souvent pas une vraie protection
Le réflexe après une telle panne est de passer au multi-cloud. Cependant, faire fonctionner deux fournisseurs en parallèle double d’abord la complexité et les coûts, sans augmenter automatiquement la sécurité. Si la véritable dépendance réside dans un niveau de contrôle partagé ou un service centralisé, l’ajout d’un deuxième fournisseur apporte peu de remède.
Il est plus judicieux de se poser la question honnête de savoir quels services sont réellement critiques et quelles dépendances concrètes ils impliquent. Pour la plupart des PME, une configuration Multi-Region propre chez le fournisseur actuel constitue une première étape plus pertinente qu’un projet coûteux de deuxième cloud, dont personne ne maîtrise les procédures en cas d’urgence.
Ce que l’informatique logistique devrait vérifier dès maintenant
Trois questions doivent être posées. Premièrement : quels processus s’arrêtent si une seule région cloud tombe en panne ? Deuxièmement : disposons-nous de dépendances cachées vis-à-vis de services centraux comme IAM ou DNS, qui sont concentrés sur une seule région ? Troisièmement : avons-nous déjà testé le basculement (failover) dans des conditions réelles, et non uniquement lors de présentations théoriques ?
Celui qui ne peut pas répondre à ces questions ne dispose pas d’un concept de résilience, mais d’une simple espérance. La panne d’octobre 2025 a servi de rappel onéreux que le cloud ne supprime pas la responsabilité en matière de disponibilité, il la déplace simplement.
Foire aux questions
Qu’est-ce qu’un risque de concentration cloud ?
Un risque de concentration survient lorsque trop de processus critiques dépendent d’un seul fournisseur, d’une région unique ou d’un service centralisé. Si ce point unique tombe en panne, un volume disproportionné de systèmes s’effondre. La panne AWS d’octobre 2025 en est un exemple pédagogique.
Pourquoi us-east-1 a-t-il eu des conséquences si graves ?
us-east-1 est la région AWS la plus ancienne et la plus vaste ; elle héberge des fonctions de contrôle globales dont d’autres régions dépendent, telles que les mises à jour IAM et les tables globales DynamoDB. Une panne dans cette région a donc des répercussions bien au-delà de ses frontières.
Le multi-cloud protège-t-il contre de telles pannes ?
Pas automatiquement. Le multi-cloud double la complexité et les coûts, mais ne supprime pas la dépendance inhérente à un service centralisé partagé. Pour de nombreuses entreprises, une configuration Multi-Region testée chez le fournisseur actuel constitue une première étape plus pertinente.
Que demande la réglementation à ce sujet ?
DORA pour le secteur financier et NIS2 de manière plus large exigent que les entreprises connaissent et maîtrisent leurs dépendances envers des fournisseurs et des régions spécifiques. Se référer globalement au cloud ne suffit plus ; le risque de concentration doit être documenté et contrôlé.
Comment tester correctement sa résilience cloud ?
Seul un basculement (failover) exercé dans des conditions réelles est un vrai basculement. Simulez la panne d’une région entière et vérifiez quels processus s’arrêtent et quelles dépendances cachées apparaissent. Une documentation de failover sans test n’est qu’une liste de souhaits.
Suggestions de lecture de la rédaction
- KRITIS dans le cloud : ce qui sécurise la migration
- AWS et Azure sous surveillance de l’UE : le verrouillage vacille
- Cloud Broker : 30 % de coûts multi-cloud en moins
Plus du réseau MBF Media
MyBusinessFutureRetard d’investissement : comment l’IA débloque des budgets cachésDigital ChiefsLe pari des milliards des hyperscalers et votre facture cloudSecurityTodayQuand un appel stoppe la production automobileSource image de une : générée par IA (juillet 2026)
Source de l’image : généré par IA (juillet 2026)
