Tout le Web dépend de l’hébergeur AWS ?

Le 20 octobre 2025, l'hébergeur AWS¹ 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 ?

Les faits

« Les alternants ont commencé à râler quand ils n'ont pas pu se connecter à Brawl Stars (jeu sur smartphone), ça m'a mis la puce à l'oreille. » (Témoignage sur la liste de diffusion FRnog).

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 AZ² . 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.

Un exemple de mauvaise analyse ? Les innombrables articles disant que la panne AWS était « un problème DNS³  ». Il s'agissait en fait d'une bogue dans un de leurs programmes qui assurent le fonctionnement de la plate-forme. Que ce programme gérait des enregistrements DNS est un détail : le DNS, comme système global, marchait parfaitement.

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 : le nombre et la variété des services sur AWS est justement un des arguments de vente les plus forts d'Amazon. 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.

Et puis, comme je l'ai dit plus haut, Amazon a bien communiqué pendant la panne et a finalement produit un retour d'expérience vraiment détaillé (mais pas forcément sincère : il n'a pas été évalué de manière indépendante), ce que très peu d'entreprises françaises feraient, dans le cas d'une panne équivalente ; on peut admirer un contre-exemple chez CleverCloud.

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. (Notez que certains opérateurs « trichent » en ne comptant pas comme panne les maintenances planifiées. Ce n'est évidemment pas très acceptable : imagine t-on AWS annoncer « le 11 novembre, tout sera arrêté de 1500 UTC à 2200 UTC » ?)

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. (Cela dit, je n'ai pas entendu parler de service public français en ligne injoignable pendant cette panne particulière d'AWS.)

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. ⁴

D'abord, relativisons un peu le problème. Contrairement aux titres sensationnalistes de bien des médias, on n'avait pas « la moitié de l'Internet en panne ». De nombreuses personnes ne se sont même aperçues de rien et ont continué à travailler comme avant. D'accord, la panne était sérieuse et touchait bien des services, mais elle était loin d'être totale. Les médias et les analystes bon marché ont tendance à réduire l'Internet au Web et le Web à la dizaine de services centralisés étasuniens qu'ils connaissent, mais l'Internet reste divers et décentralisé (malgré des tendances très claires à la centralisation). Gardons donc la tête froide : la panne d'une des AZ d'AWS, ou celle de Cloudflare, ne nous ramène pas aux années 1970, avant l'Internet.

Ensuite, plusieurs commentateurs ont critiqué la dépendance vis-à-vis d'un service étasunien et insisté sur la nécessité de disposer de services « souverains » et de les utiliser. Il faut distinguer ici le problème pratique (le risque de panne) et le problème de sécurité. Les acteurs français ou européens tombent en panne aussi (et peut-être davantage : Amazon a plutôt un bon bilan). 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. Il faut qu'il y ait de nombreux prestataires, à la fois pour que les pannes (inévitables) de l'un d'eux n'aient pas de conséquence trop graves et pour éviter la concentration du pouvoir dans une seule entreprise (ou un seul État). 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é. Si un·e DSI⁵ choisit AWS, lorsque AWS est en panne, on ne pourra rien lui reprocher puisque « la moitié de l'Internet était en panne ». Si ielle choisit au contraire un petit acteur peu connu, gageons que ce choix sera fortement critiqué lorsque cet acteur aura un problème technique.

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. Un site Web moderne fabrique souvent ses pages en combinant des résultats venus de plusieurs (micro-)services différents, et une panne va souvent produire des effets qui sont surprenants pour l'utilisateur (pensez à une panne d'un gros CDN⁶ qui héberge les CSS). Il faut donc également analyser ce qui se passe en cas de panne partielle.

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. (Personnellement, je pense qu'une panne de TikTok de douze heures ne serait pas grave. Mais, le lendemain de la panne, la BBC titrait « Snapchat et les banques repartent », mettant les deux sur un pied d'égalité.)

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.