Ce que la panne d’AWS nous apprend sur la centralisation du cloud et la résilience d’Internet

🚨 Et si l’incident survenu la semaine dernière chez AWS (le 20 octobre 2025) était une alerte majeure – pas seulement pour AWS, mais pour l’ensemble de notre vision du cloud et de l’Internet ?

Imaginez : un matin comme les autres, vos services tournent – vos clients accèdent à vos applis, vos données circulent, les équipes collaborent. Et puis : panne. Une panne qui ne touche pas seulement un serveur ou un datacenter, mais un acteur majeur du cloud. Non pas une petite perturbation locale, mais une interruption généralisée qui ébranle des milliers de services dans le monde.
Cette semaine, AWS a vacillé. Et nous, acteurs B2B, devons tirer les enseignements.

1. La centralisation massive chez les hyperscalers

L’architecture de l’Internet moderne repose sur quelques géants du cloud — AWS, Microsoft Azure, Google Cloud. Selon certaines estimations, AWS détient près de 40 % du marché IaaS.
Quand AWS est victime d’un bug DNS dans sa région US-EAST-1 – comme ce fut le cas, entraînant l’échec de la résolution DNS, la chute d’API clés de services comme DynamoDB, et un effet domino – cela se propage vite.

« The internet was designed to be resilient; many other channels existed for routing around problems … but we’ve lost some of that resilience by becoming so dependent on a handful of giant tech companies. » (The Guardian)

2. Notre vision de l’Internet : interconnecté, distribué, résilient… en danger

Le modèle originel de l’Internet imagine un réseau de réseaux, distribué, capable de rediriger, de contourner les pannes. Ce modèle est mis à l’épreuve quand un seul fournisseur de cloud provoque l’interruption de services bancaires, d’apps grand public, de plateformes de streaming.
On voit bien que l’architecture globale est plus vulnérable qu’on ne l’imaginait.

3. Changer pour un fournisseur « souverain » ne suffit pas

Il est tentant de réagir en disant : “Ok, je quitte les hyperscaler mondiaux, je vais vers un acteur plus local, plus souverain, plus proche.” Mais en réalité, cela ne règle pas la question : le risque de centralisation (et d’un point de défaillance unique) demeure.
Même un cloud souverain, s’il concentre toutes vos charges critiques, reste un fournisseur unique, avec ses propres vulnérabilités.

4. La vraie solution : la résilience par la diversification – le multi-cloud

Pour les services critiques, où la haute disponibilité est non négociable, la logique est claire : ne pas mettre « tous les œufs dans le même panier ». Un modèle multi-cloud (ou du moins multi-région / multi-zone) réduit la dépendance vis-à-vis d’un seul fournisseur.

5. Mais attention : coûts financiers, complexité, empreinte écologique

Toute cette résilience à toute épreuve a un coût :

Il faut donc trouver le juste équilibre : quel niveau de disponibilité suis-je prêt à payer ? Quelle tolérance de panne est acceptable pour mon business ?

Pour les dirigeants et responsables IT B2B, plusieurs questions se posent désormais avec urgence.

a) Quelle est la véritable dépendance de mon entreprise aux hyperscalers ?
Beaucoup de services gagnent à être dans le cloud ; mais combien d’entre eux dépendent d’un seul fournisseur ou d’une seule région sans plan B ? L’incident AWS montre que même un acteur ultra-fiable peut chuter.
C’est un moment pour auditer : quelles ressources critiques sont sur un seul cloud/région ? Quelle est la surface d’exposition ?

b) Quelle est ma définition de “disponibilité nécessaire” ?
Si j’offre un service stratégique (paiement, santé, infrastructure critique), je dois viser très haut (99,99 %, voire 100 % ?). Mais est-ce réaliste ? Le “zéro panne” est un mythe. Il faut accepter une part de risque — et aider le business à comprendre ce compromis.

c) Dois-je repenser mon modèle d’infrastructure vers le multi-cloud ou hybride ?
Le multi-cloud est bien une stratégie valable pour atténuer le risque fournisseur unique. Mais attention : ce n’est pas “installer deux clouds et on est ok”. Il faut maîtriser les aspects suivants :

d) Comment intégrer l’écologie et les coûts dans cette réflexion ?
Souvent, on considère la disponibilité comme une variable unique : plus c’est haut, mieux c’est. Mais il faut élargir la vue : quel est le coût marginal pour gagner la dernière “neuf-neuf” ou “six neuf” (99,9999 %) ? Quelle est l’empreinte énergétique de cette architecture redondante ?
Il s’agit d’aligner la stratégie d’infrastructure avec les objectifs financiers et RSE de l’entreprise.

e) Et finalement : quelle gouvernance, quel pilotage ?
Une panne majeure comme celle d’AWS doit être traitée au niveau du board ou de l’équipe exécutive : la disponibilité devient un enjeu business — pas seulement un sujet IT. Les indicateurs de résilience, la capacité de réagir, la visibilité sur les dépendances doivent être intégrés aux revues de performance.

À la lumière de ce qui vient de se passer : l’hyperscaler a faibli, l’Internet a toussé. Mais ce n’est pas une raison de tout remettre en question de façon radicale — plutôt une invitation à repenser, affiner, équilibrer.

✅ Oui : la centralisation autour de quelques géants du cloud est un réel risque.
✅ Oui : changer de fournisseur pour un acteur “souverain” ne suffit pas si je reste dépendant d’un seul.
✅ Oui : une architecture multi-cloud, multi-région est la meilleure réponse pour les services à très haute disponibilité.
⚠️ Non : cela ne veut pas dire « 100 % sans coût, sans complexité ».

Votre mission maintenant : faire le point.

Sinabe Sàrl
Promenade Le Corbusier 11
2300 La Chaux-de-Fonds
Hébergé en Suisse par SwissNubes
© Sinabe Sàrl 2013-2025