Le 16 juillet 2026, pendant un peu plus de trois heures, une série de sites et d'applications ont renvoyé des erreurs à leurs visiteurs partout dans le monde. Des services aussi connus que Hugging Face ou la plateforme éducative Canvas étaient inaccessibles. La cause n'était pas un piratage ni un bug dans ces sites. C'était une panne chez Amazon Web Services, plus précisément dans CloudFront, le réseau de diffusion de contenu qui se trouve « devant » une grande partie d'internet.
L'incident est réglé, et il n'a rien d'exceptionnel dans sa mécanique. Mais il illustre parfaitement une réalité que beaucoup de dirigeants découvrent le jour où leur site tombe : un site web n'est pas un objet posé quelque part, c'est une chaîne de dépendances. Et une chaîne casse au maillon le plus faible.
Ce qui s'est passé, en clair
CloudFront est un CDN (content delivery network) : un réseau de serveurs répartis dans le monde qui délivrent votre site rapidement au visiteur le plus proche. Le 16 juillet, une fonctionnalité récente de CloudFront, appelée VPC Origins, a atteint une limite interne. Le système chargé de distribuer la bonne configuration de routage n'a plus chargé les bonnes données, et les requêtes concernées se sont mises à échouer.
La panne a duré environ trois heures et demie, de 7h45 à 11h18 en heure universelle. Sa cause était étroite : seuls les clients utilisant cette fonctionnalité précise étaient touchés, les autres configurations fonctionnaient. Mais sa portée était mondiale, parce que quand un maillon aussi central qu'un grand CDN vacille, tout ce qui dépend de lui vacille en même temps.
Ce n'est pas la première fois. En octobre 2025, une panne AWS bien plus longue avait mis à genoux des milliers de services pendant de longues heures. À chaque fois, le schéma est le même : une brique d'infrastructure mutualisée par des dizaines de milliers d'entreprises tombe, et l'effet domino est immédiat.
Votre site est une chaîne, pas un bloc
Voici ce que la plupart des propriétaires de site ne voient pas, parce que ça se passe sous le capot. Afficher une page, ce n'est pas un seul service, c'est une succession de maillons qui doivent tous fonctionner :
| Maillon | Rôle | Si ça tombe |
|---|
| DNS | Traduit votre nom de domaine en adresse de serveur | Le site devient introuvable |
| CDN | Distribue et met en cache le contenu au plus près du visiteur | Erreurs d'affichage, site lent ou inaccessible |
| Hébergeur / serveur | Fait tourner l'application et sert les pages | Plus rien ne répond |
| Base de données | Stocke les contenus, comptes, commandes | Pages vides ou erreurs |
| API tierces (paiement, réservation, avis) | Fonctions branchées sur des services externes | Panier bloqué, réservation impossible |
Un site vitrine simple dépend de trois ou quatre de ces maillons. Un e-commerce ou une application métier peut en cumuler dix, entre le paiement, la livraison, l'ERP et les outils marketing. Plus la chaîne est longue, plus il y a de points de défaillance possibles. La panne du 16 juillet, c'est un seul maillon lointain qui lâche et qui fait tomber des milliers de sites qui n'avaient pourtant aucun problème « chez eux ».
Zéro panne n'existe pas. Bien encaisser la panne, si.
Soyons honnêtes : aucun prestataire sérieux ne vous promettra un site qui ne tombe jamais. Même les géants du cloud tombent, on vient de le voir. La vraie question n'est pas « comment garantir 100 % de disponibilité » (c'est un mensonge commercial), mais « qu'est-ce qui se passe quand un maillon lâche, et à quelle vitesse on s'en remet ».
C'est là que le travail d'ingénierie fait la différence. Quelques principes concrets :
- La redondance. Ne pas faire reposer chaque fonction critique sur un point unique. Un DNS avec plusieurs opérateurs, un hébergement dont on connaît le plan de bascule, des sauvegardes ailleurs que sur le serveur principal.
- La page de repli. Quand un service tiers ne répond pas, le site doit se dégrader proprement (afficher une version simplifiée, un message clair) plutôt que de renvoyer une erreur brute au visiteur.
- La surveillance. Être prévenu que le site est tombé par un outil de monitoring, pas par un client mécontent au téléphone. La différence entre réagir en dix minutes et découvrir la panne trois heures plus tard.
- Le plan de reprise. Savoir à l'avance qui fait quoi, où sont les sauvegardes, combien de temps prend une restauration. Un plan écrit, pas une improvisation le jour J.
Les bonnes questions à poser à votre prestataire
Vous n'avez pas besoin d'être technicien pour évaluer si votre site est correctement protégé. Il suffit de poser les bonnes questions et d'écouter si les réponses sont précises ou évasives :
- Où est hébergé mon site, et que se passe-t-il si cet hébergeur tombe ?
- À quelle fréquence sont faites les sauvegardes, et où sont-elles stockées ?
- Combien de temps prendrait une remise en ligne complète après un incident majeur ?
- Comment suis-je (ou êtes-vous) prévenu quand le site est indisponible ?
- De quels services tiers mon site dépend-il, et lesquels sont critiques ?
Si personne ne sait répondre, ce n'est pas votre faute : c'est le signe que la résilience n'a jamais été pensée. C'est exactement le genre de dette invisible qu'on ne voit que le jour de la panne. Nous avons abordé le sujet voisin de l'entretien continu dans notre article sur le contrat de maintenance et la sécurité d'un site web : un site est un système vivant, pas un livrable qu'on pose et qu'on oublie.
Ce qu'on en retient
La panne AWS du 16 juillet n'est pas une anomalie, c'est un rappel. Concentrer toute son infrastructure derrière un seul fournisseur, sans redondance ni plan de reprise, c'est accepter que sa présence en ligne s'arrête quand ce fournisseur éternue. Pour un site vitrine, quelques heures d'indisponibilité sont gênantes. Pour une boutique en ligne ou une application métier sur laquelle repose votre activité, elles se comptent en chiffre d'affaires perdu et en confiance entamée.
Chez Axiom Marketing, studio d'ingénierie web à La Réunion, nous concevons les sites et applications avec cette question en tête dès le départ : que se passe-t-il quand ça casse. Si vous ne savez pas comment votre site réagirait à une panne comme celle-ci, notre audit gratuit inclut un état des lieux de votre hébergement et de vos dépendances. Vous pouvez aussi en parler avec notre agence web à La Réunion ou nous écrire via la page contact. Mieux vaut poser ces questions un jour calme que le jour où le site est déjà tombé.
