Logistique & Supply Chain

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.

Par Alec Chizhik 12 juillet 2026 5 min de lecture

Une région tombe, la moitié de la chaîne d’approvisionnement est à l’arrêt

Le 20 octobre 2025, une partie d’Internet s’est arrêtée. Slack, Snapchat et Atlassian sont restés inaccessibles pendant des heures, les boutiques en ligne ont perdu des commandes, et les services logistiques n’ont plus pu traiter d’envois. Le déclencheur se trouvait dans une seule région AWS, sur la côte est des États-Unis. Cet incident révèle une vérité gênante : la concentration du cloud n’est pas qu’un sujet informatique, c’est un risque pour la chaîne d’approvisionnement.

Les points clés en bref

Une seule région suffit. L’incident AWS d’octobre 2025 a débuté par un enregistrement DNS vide dans us-east-1 et a paralysé Slack, Snapchat et des milliers de boutiques en ligne pendant plus de 15 heures.
La concentration est un risque pour la chaîne d’approvisionnement. La gestion des stocks, le suivi des colis et les transactions de paiement reposent sur le cloud. Si le cloud s’arrête, la chaîne logistique physique s’arrête aussi.
Le multi-cloud n’est pas toujours la solution. Un deuxième prestataire double la complexité et les coûts, mais pas la sécurité. Pour la plupart des PME, une configuration multi-régions testée est une meilleure première étape.

Verwandt:Séparer 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

L’incident a commencé par une minuscule erreur dans la gestion DNS du service de base de données DynamoDB. Une condition de course a généré un enregistrement DNS vide pour le point de terminaison régional. L’automatisation n’a pas corrigé le problème. Le DNS est l’annuaire téléphonique d’Internet. Avec un enregistrement vide, les applications ne trouvaient plus la base de données.

Ce problème initial dans DynamoDB s’est transformé en 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 conteneurisés tombaient en panne. Ce qui avait commencé comme une perturbation de trois heures de la base de données s’est étendu sur plus de 15 heures, jusqu’à ce que tous les services dépendants soient de nouveau opérationnels.

Pourquoi une seule région peut paralyser la moitié du monde

us-east-1 n’est pas une région comme les autres. C’est la plus ancienne et la plus grande région AWS, hébergeant 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, s’exécutent de manière centralisée via us-east-1. Si elle tombe en panne, les clients qui croient héberger leurs données ailleurs en ressentent aussi les effets.

C’est là que réside l’erreur de raisonnement de nombreux plans de continuité d’activité. Une entreprise peut répartir son application sur plusieurs régions, mais rester bloquée si la couche de contrôle est concentrée dans une seule région. La résilience théorique ne vaut pas la résilience en situation réelle.

Le problème de la chaîne d’approvisionnement derrière la panne informatique

Pour la logistique et le commerce, un tel incident n’est pas un simple problème technique abstrait. La gestion des stocks, le suivi des colis, la prise de commandes et les transactions de paiement reposent de plus en plus sur des services cloud. Si le cloud s’arrête, la chaîne logistique physique s’arrête aussi. Une heure d’interruption peut coûter plusieurs dizaines de milliers d’euros à un commerçant de taille moyenne, et bien plus pour les grandes enseignes.

Les régulateurs l’ont bien compris. Avec DORA pour le secteur financier et NIS2 à plus grande échelle, le risque de concentration est désormais au cœur des préoccupations. Les entreprises devront prouver qu’elles connaissent et maîtrisent leur dépendance à un prestataire ou une région unique. Une simple mention du cloud ne suffira plus.

Pourquoi le multi-cloud n’est souvent pas une protection réelle

L’instinct, après une telle panne, est de se tourner vers le multi-cloud. Pourtant, faire fonctionner deux fournisseurs en parallèle double d’abord la complexité et les coûts, sans automatiquement renforcer la sécurité. Si la dépendance réelle réside dans une couche de contrôle partagée ou un service centralisé, un second fournisseur n’y change pas grand-chose.

Une question plus pertinente serait d’identifier quels services sont réellement critiques et quelles dépendances réelles ils impliquent. Pour la plupart des PME, une configuration multi-régions propre chez leur fournisseur actuel constitue une meilleure première étape qu’un coûteux projet de seconde cloud, que personne n’a jamais testé en conditions réelles.

Ce que la logistique IT devrait vérifier dès maintenant

Trois questions s’imposent. Premièrement : quels processus s’arrêtent si une région cloud unique tombe en panne ? Deuxièmement : avons-nous des dépendances cachées à des services centraux comme l’IAM ou le DNS, concentrés dans une seule région ? Troisièmement : avons-nous déjà testé le basculement (failover) dans des conditions réelles, et non pas seulement en présentation ?

Qui ne peut répondre à ces questions n’a pas de plan de résilience, mais seulement un espoir. La panne d’octobre 2025 a rappelé à quel point le cloud ne supprime pas la responsabilité de la continuité d’activité, il la déplace simplement.

Foire aux questions

Qu’est-ce qu’un risque de concentration dans le cloud ?

Un risque de concentration survient lorsque trop de processus critiques dépendent d’un seul fournisseur, d’une seule région ou d’un service centralisé. Si ce point unique tombe en panne, l’impact est disproportionné. L’incident AWS d’octobre 2025 en est un parfait exemple.

Pourquoi la région us-east-1 a-t-elle eu un impact aussi important ?

us-east-1 est la plus ancienne et la plus grande région AWS. Elle héberge des fonctions de contrôle globales dont dépendent d’autres régions, comme les mises à jour IAM et les tables DynamoDB Global. Une panne à cet endroit a donc des répercussions bien au-delà de la région concernée.

Le multi-cloud protège-t-il contre ce type de panne ?

Pas automatiquement. Le multi-cloud double la complexité et les coûts, mais ne supprime pas les dépendances liées à un service central partagé. Pour de nombreuses entreprises, une configuration multi-régions testée chez leur fournisseur actuel constitue une meilleure première étape.

Que demande la réglementation à ce sujet ?

DORA dans le secteur financier et NIS2, plus largement, exigent que les entreprises identifient et maîtrisent leurs dépendances à un seul fournisseur ou une seule région. Une simple référence au cloud ne suffit plus : le risque de concentration doit être documenté et maîtrisé.

Comment tester correctement la résilience de son cloud ?

Seul un basculement (failover) testé en conditions réelles est un vrai failover. Simulez la panne d’une région entière et vérifiez quels processus restent opérationnels et quelles dépendances cachées apparaissent. Une documentation de failover sans test n’est qu’un vœu pieux.