Le 20 octobre 2025, l’hébergeur AWS1 a connu une panne sérieuse sur l’un de ses sites, panne qui a mené au dysfonctionnement ou à l’arrêt de nombreux services Internet, dont pas mal de sites Web très visibles, comme Snapchat. D’innombrables articles ont été écrits depuis sur cette panne, et la plupart sont déjà oubliés. Il y a pourtant des leçons à en tirer. Le Web est-il mortel ? Les pannes de deux autres gros acteurs, Azure le 29 octobre et Cloudflare le 18 novembre, ont relancé la question. Sur quoi repose le Web ?

AWS est un gros hébergeur de serveurs, très utilisé dans le monde. Comme son nom l’indique, il est propriété d’Amazon.

Amazon a publié une description assez détaillée de l’incident. La panne était purement logicielle et affectait un des innombrables services d’AWS, DynamoDB. Ce service est à son tour utilisé par bien des services Amazon, comme EC2 qui gère les machines virtuelles. Résultat, beaucoup de problèmes un peu partout sur l’Internet, pour le Web, bien sûr, mais pas uniquement puisque la messagerie sécurisée Signal a également souffert. La panne a duré plusieurs heures, avec des conséquences plus ou moins fortes selon le moment. Comme presque toujours dans le monde numérique, il n’y a pas eu d’étude indépendante et publique de la panne, contrairement à ce qui se fait, par exemple, dans l’aviation et il faut donc être prudent, on n’est pas sûr de tous les faits.

Tout AWS n’était pas en panne, loin de là. Les services d’AWS sont répartis en régions, elles-même comprenant une ou plusieurs AZ2 . Le client choisit région et AZ. Ce 20 octobre, seule la région us-east-1 (côte Est des États-Unis) était affectée et donc seuls les services qui avaient choisi de s’installer là étaient touchés.

Les réactions dans les médias ont, comme d’habitude, été assez sensationnalistes (« la moitié de l’Internet est en panne ») et souvent mal informés, malgré le compte-rendu très précis techniquement qu’a publié Amazon. Même chose après la panne de Cloudflare le 18 novembre, pourtant là aussi bien analysée par l’hébergeur. Les leçons tirées sur le moment ont souvent été plutôt simplistes (« c’est un scandale », « que fait le gouvernement ? », « il aurait fallu faire ceci ou cela »). Le but de cet article est de creuser la question et de voir ce que cet incident nous apprend. (...)

Amazon était-il en tort ?

Gérer un système de la taille d’AWS ou de Cloudflare est vraiment très difficile. Beaucoup de ceux qui se sont exprimés sur la panne en s’indignant de ce qu’un service aussi important qu’AWS ne soit pas « mieux géré » auraient dû être plus prudents dans leur indignation. On parle quand même d’un système technique qui n’a pas beaucoup de précédents dans l’histoire, les pannes sont inévitables.

On sait comment faire des systèmes plus robustes (qui ont quand même des pannes, mais beaucoup moins). Cela implique notamment de diminuer leur complexité en offrant moins de services. Mais le marketing s’y opposerait (...)

Il faut donc savoir ce qu’on veut. La personne énervée qui crie sur Twitter que cette panne est intolérable serait sans doute la première à ne pas vouloir choisir un concurrent d’AWS qui offre davantage de robustesse mais moins de services. (...)

Mais a-t-on vraiment besoin de tant de robustesse ?

Malgré ce que le marketing essaie de faire croire, en abusant de termes éthérés comme « cloud », « serverless » et « virtuel », le Web dépend de ressources bien concrètes et des personnes qui les font fonctionner.

Arrivé là, il faut se poser une question : a-t-on besoin de tant de robustesse ? Si Snapchat est en panne quelques heures, est-ce tellement grave ? La question va être compliquée, d’autant plus qu’AWS héberge à la fois des services de distraction et des services bien plus critiques.

On évalue souvent la robustesse en pourcentage de temps de panne. Une robustesse de 99 % veut dire qu’on accepte plus de trois jours complets de panne par an. Une robustesse de 99,9 % signifie qu’on ne tolère que moins de neuf heures de panne dans l’année (AWS ne pourra pas atteindre cet objectif en 2025). Et une robustesse de 99,99 % oblige à ne pas avoir plus de cinquante minutes de panne dans toute l’année. (...)

Le point important est que passer de 99 % à 99,9 % coûte très cher. Un tel objectif ne laisse guère de marge d’erreur et nécessite donc un système soigneusement conçu, avec des doublons partout. Réclamer qu’un prestataire ait une telle robustesse, pourquoi pas, mais il faut être prêt à en payer le prix.

Bref, il n’y a pas de mal à accepter une certaine dose de pannes, pour des services qui ne sont pas critiques, mais il faut en être conscient et assumer de prendre des risques.

L’autre problème caché derrière celui-ci est qu’on se rend parfois dépendant de l’Internet sans bonne raison. Pendant la panne AWS, des utilisateurs de lits connectés (!) ont été réveillés car le lit faisait n’importe quoi lorsqu’il n’arrivait pas à joindre le serveur de l’entreprise qui les fabriquait. Ici, la solution n’aurait pas été d’augmenter la disponibilité d’AWS mais de faire des lits qui arrivent à fonctionner, quitte à ce que ce soit en mode un peu dégradé, pendant une coupure de l’accès distant. Face à ce genre de conséquences, on ne peut pas se dire autre chose que « il faudrait une régulation bien plus stricte des gadgets connectés, et tant pis si on est accusé de freiner l’innovation ». (...)

De la même façon, supprimer les accès physiques aux services publics et imposer le passage par un service en ligne n’est pas une conséquence inévitable de lois scientifiques, c’est un choix politique et dont une des conséquences est la vulnérabilité de ces services en cas de panne. (...)

L’autonomie numérique

Un autre sujet important, que la panne d’AWS avait fait ressortir, est celui de l’autonomie numérique. Je ne vais pas parler de « souveraineté numérique », à la fois parce que ce terme est souvent indicatif d’un certain positionnement politique (vers la droite…) et parce qu’il est en général restreint à la souveraineté du pays, identifié à son gouvernement. Si on comprend qu’un pays souhaite garder sa souveraineté et ne pas être dépendant de services Web étrangers (qui peuvent lui couper l’accès ou bien capter des données), il faut aussi se rappeler que l’État national n’est pas toujours bienveillant et qu’il faut aussi défendre la souveraineté du citoyen ou de la citoyenne. Les appels à défendre « la souveraineté », de la part des gouvernements, sont souvent hypocrites. Je vais donc plutôt parler d’autonomie, aussi bien celle de la France vis-à-vis des États-Unis que celle de la citoyenne ou du citoyen vis-à-vis de son gouvernement. (...)

Migrer vers un service « souverain » dans l’espoir de ne pas avoir de panne serait naïf. En outre, des mauvaises pratiques d’Amazon, par exemple en matière de surveillance et de captation des données, peuvent également être utilisées par un acteur national. Un hébergeur français peut aussi vous censurer, par exemple à la demande du très puissant lobby des ayants droit. C’est un bon exemple de l’importance de distinguer souveraineté nationale et autonomie des individus et organisations.

Est-ce que ça veut dire que la situation actuelle, avec de nombreuses organisations qui dépendent d’AWS est satisfaisante et qu’il ne faut rien faire ? Non, je ne le pense pas. Quand un acteur a un rôle crucial, il a du pouvoir, et il va forcément en abuser. Il est donc très important, non pas de remplacer AWS par un « AWS souverain » qui poserait les mêmes problèmes mais de décentraliser l’Internet et le Web. (...)

Comme le disait ma grand-mère « mettre tous ses œufs dans le même panier, c’est pratique, mais si le panier tombe, tout est cassé ».

Concernant les conséquences des pannes, il faut quand même noter que le décideur pourrait estimer que choisir l’acteur dominant pour son hébergement présente un gros avantage, celui de l’irresponsabilité. (...)

En conclusion

Il n’y a pas de solution parfaite : les pannes techniques existeront toujours. On peut limiter leur probabilité (par exemple en préférant des services simples et limités, plus faciles à fiabiliser) et leurs conséquences (en décentralisant) mais on ne peut pas les supprimer.

Déjà, il faut essayer de connaître son graphe de dépendance, les services dont on dépend, parfois transitivement (on dépend de A qui lui-même dépend de B, ce dont on ne s’apercevra que lorsque B sera en panne). Beaucoup d’acteurs du Web ne sont pas réellement conscients des dépendances de leur site. Ce n’est pas grave si c’est le site Web du boulanger du coin de la rue mais c’est plus inquiétant s’il s’agit d’un service important.

On peut alors au moins essayer de produire des messages d’erreur clairs. (...)

Ensuite, il faut se préparer à la grande panne : a-t-on un plan B ? Que se passerait-il si X ou Y était en panne ? Veille-t-on à ne pas mettre tous ses œufs dans le même panier ? On a vu plus haut que, même si on reste uniquement chez AWS, il existe plusieurs régions et seule us-east-1 était en panne. Bien des services affectés par la panne auraient eu moins de problèmes s’ils avaient, comme Amazon le conseille, répartis leur service sur plusieurs AZ. Oui, cela coûte plus cher. Il faut donc analyser le risque de panne et mettre cela en rapport avec le coût de la robustesse. Le résultat dépendra évidemment de la criticité du service. (...)

Et, pour les services les plus critiques, il faut prévoir des solutions non numériques. C’est le cas par exemple pour les services publics qui, pour cette raison et d’autres, ne devraient jamais être 100 % en ligne.