Quand un fournisseur tombe, tout tombe : le risque de concentration dans le cloud
Les pannes d'AWS en octobre 2025 et de Cloudflare en novembre 2025 ont rappelé qu'une dépendance partagée est un risque de groupe. Comment le cartographier sans tout dupliquer.
Le 20 octobre 2025, une panne partie de la région US-EAST-1 d'AWS, liée à un problème de résolution DNS touchant un service de base de données, s'est propagée à de nombreux services dépendants. Le 18 novembre 2025, un changement de configuration interne chez Cloudflare a perturbé son trafic pendant plusieurs heures et affecté de très nombreux sites et applications (TechTarget, SoftwareSeni). Les ampleurs avancées varient selon les sources ; le constat, lui, est solide : quelques fournisseurs portent une part considérable de l'Internet.
Concentration n'est pas verrouillage
Le vendor lock-in décrit le coût de sortie d'un fournisseur. Le risque de concentration décrit autre chose : l'impact simultané sur un grand nombre d'organisations quand un fournisseur très répandu tombe. On peut ne pas être verrouillé et rester exposé, si tous les services dont on dépend reposent, sans qu'on le sache, sur la même infrastructure.
Pourquoi c'est un sujet de groupe
Dans une structure à plusieurs sociétés, chaque entité fait ses propres choix techniques, et la dépendance commune est souvent invisible. La messagerie d'une filiale, le site d'une autre et l'outil de facturation du groupe peuvent dépendre du même fournisseur d'identité, du même DNS ou du même réseau de diffusion. Une panne unique devient alors une panne du groupe entier, au moment même où l'on aurait besoin de communiquer.
Quatre gestes utiles, sans tout dupliquer
- Cartographier les dépendances partagées : DNS, identité et authentification, messagerie, hébergement, réseau de diffusion, paiement. L'objectif est de savoir lesquelles sont communes à plusieurs entités.
- Distinguer les services critiques des autres : on n'a pas besoin de redondance pour tout, mais pour ce dont l'arrêt est inacceptable plus de quelques heures.
- Prévoir un mode dégradé : un canal de communication de secours indépendant de l'infrastructure principale, des copies locales des données indispensables, une procédure manuelle de repli.
- Tester la reprise : un plan de reprise jamais exécuté est une hypothèse. Les analyses de ces pannes insistent sur le fait que la reprise doit marcher même quand la console du fournisseur, le chemin d'identité ou l'automatisation habituelle sont indisponibles.
Ce qu'on ne peut pas supprimer
Le risque de concentration ne se réduit pas à zéro. La bonne question n'est pas « comment l'éliminer ? » mais « la dépendance restante est-elle connue, proportionnée au service concerné, et adossée à un chemin de reprise éprouvé ? ». Diversifier les fournisseurs a un coût de complexité qui peut lui-même créer des pannes ; la maîtrise vient de la lucidité sur les dépendances plus que de leur multiplication.
Le lien avec la gouvernance
Cette cartographie fait partie des questions que la direction d'un groupe peut poser à ses entités, au même titre que celles sur la sécurité ou l'IA. Elle rejoint notre conviction sur les technologies ouvertes et réversibles, développée dans l'article consacré à ce sujet : pouvoir changer de fournisseur ou reprendre la main est une forme de résilience.