---
title: Préparez-vous pour la prochaine panne d'Internet
slug: '7-preparez-vous-pour-la-prochaine-panne-d-internet'
date: '2025-06-14T04:05:48+02:00'
categories:
- DevOps
tags:
- architecture
- cloud
summary: >
  Une réflexion sur les récentes pannes d'Internet et les enseignements que j'en
  tire pour construire des services web plus résilients.
---

Jeudi dernier, [Internet est tombé en panne](https://mashable.com/article/google-down-cloudflare-twitch-character-ai-internet-outage).
Encore une fois. Oui, les médias ont transformé une panne de deux heures en une
crise mondiale pour faire du putaclic.

Ce qui a rendu cet incident significatif, ce n'est pas seulement la perturbation
de Google Cloud, mais aussi les centaines de sites web et d'applications qui
sont tombés en panne en même temps. Cela incluait certains grands noms comme
Cloudflare, qui utilise GCP pour certains de ses services. Cloudflare étant un
CDN, un cache et un proxy largement répandus, cela a créé un effet domino et a,
à son tour, fait tomber d'innombrables sites web.

Cela nous rappelle la fragile interconnection de notre monde numérique. Je ne
veux pas pointer du doigt, mais plutôt tirer des leçons de cet incident. Ce
n'était pas juste un incident ; cela a mis en lumière des principes
fondamentaux que, à l'ère du "tout en tant que service", nous avons peut-être
involontairement négligés.

Voici mes principaux enseignements.

## Ne mettez pas tous vos œufs dans le même panier de fournisseurs

Le cloud est devenu synonyme d'une mise à l'échelle infinie, d'un stockage
infini, d'une puissance de calcul infinie, d'une flexibilité infinie. Il est
construit sur la promesse de réduire les coûts (ce qui peut être vrai lorsqu'il
est utilisé correctement). Cependant, cela cache une vérité souvent négligée,
qui est aussi son plus grand risque : la dépendance à un seul fournisseur. La
récente panne a montré comment une panne d'un seul fournisseur, ou même d'un
composant de leur infrastructure, peut avoir un effet en cascade sur la plupart
des services.

Ajoutons à cela que
[AWS, Azure et Google Cloud Platform ont une part de marché combinée de 63 % en valeur](https://www.crn.com/news/cloud/2025/cloud-market-share-q1-2025-aws-dips-microsoft-and-google-show-growth?page=1&itc=refresh).
Même si votre entreprise n'utilise pas directement ces fournisseurs
d'infrastructure, il est probable que vous utilisiez des fournisseurs qui
dépendent d'eux, ou des fournisseurs qui pourraient dépendre d'eux. Oui, il est
probable que votre application SaaS dépende d'au moins l'un de ces fournisseurs.

**Ce que vous pouvez faire** :

* *Cartographiez vos dépendances* : Connaissez-vous vraiment tous les services
  sur lesquels repose votre produit, directement et indirectement ? Quels IaaS,
  PaaS, API, CDN, etc., utilisez-vous ? Lesquels ces services utilisent-ils à
  leur tour ? Dépendez-vous de NpmJS pour construire votre produit ? Votre
  application est-elle déployée avec une action Github ? Plus vous en savez,
  mieux vous êtes préparé.
* *Faites une évaluation approfondie de vos fournisseurs* : Les garanties de
  disponibilité (3 ? 4 ? 5 neufs ?) ne sont que du marketing. Prenez-les comme
  tel. Quelle est l'architecture de votre fournisseur ? Son plan de continuité ?
  Sa transparence sur les incidents ? Ce sont des critères bien plus importants.
* *Envisagez des stratégies multi-cloud* : Vous ne mettriez pas tous vos
  serveurs dans le même centre de données ? Alors ne mettez pas toute votre
  infrastructure chez le même fournisseur IaaS ! (Si vous le feriez, vous
  devriez faire quelque chose à ce sujet !)

## Contrôlez vos données, contrôlez votre entreprise

Le monde du cloud et des API dans lequel nous vivons est formidable. Il nous
permet de construire rapidement, d'itérer rapidement, de tester des choses et
d'améliorer nos solutions. Vous avez besoin d'une authentification, utilisez
Supabase ou Auth0. Paiement en ligne ? Il y a Stripe ou Paypal. E-mails
transactionnels ? Sendgrid et MailChimp. Recherche ? Algolia. La liste peut être
longue, mais maintenant, vous pouvez travailler à créer de la valeur.

Pourtant, comme l'a montré cette panne, si ces services deviennent
indisponibles, vos utilisateurs pourraient être bloqués, ou votre application
pourrait cesser de fonctionner, indépendamment de la santé de votre propre
infrastructure. Cela peut entraîner une perte significative de contrôle sur les
opérations commerciales de base et l'accès aux données. Les services tiers SONT
des points de défaillance uniques !

**Ce que vous pouvez faire** :

* *Mécanismes de repli pour les services principaux* : Si un service devient
  indisponible, comment le remplacez-vous ? Pouvez-vous développer une
  alternative de repli ?
* *Mirroring de données robuste* : Assurez-vous d'avoir des sauvegardes
  régulières et accessibles de vos données critiques, même si elles résident
  principalement chez un tiers. Pouvez-vous les restaurer rapidement dans un
  environnement différent si nécessaire ?

## Construire pour la résilience

La résilience a toujours été une conséquence de la redondance. Vous devriez
toujours avoir un système de secours qui peut assurer le service pendant que
votre système principal est en panne.

Mais il ne suffit pas d'avoir de la redondance. Votre application doit également
être conçue pour être tolérante aux pannes et utiliser tout ou partie du système
de secours lorsque nécessaire. Au moins, elle doit garantir que l'impact pour
vos utilisateurs soit le moindre possible : l'impossibilité d'envoyer un e-mail
ne doit jamais bloquer toute votre application.

**Ce que vous pouvez faire** :

* *Architectures distribuées* : Concevez vos systèmes avec des architectures de
  type microservice. Déployez vos services sur plusieurs fournisseurs IaaS.
  Répliquez les données critiques sur plusieurs fournisseurs. L'objectif est de
  limiter l'impact de toute défaillance d'un seul composant.
* *Systèmes auto-cicatrisants* : Mettez en place des mécanismes qui peuvent
  détecter automatiquement les défaillances, réacheminer le trafic ou redémarrer
  les services sans intervention humaine. Plus votre système peut réagir
  rapidement, moins une panne aura d'impact.
* *Concevoir pour l'échec* : N'attendez pas qu'un événement externe expose vos
  faiblesses. Il sera trop tard. Ajoutez quelques tests de défaillance
  automatisés à votre pipeline CI : que se passe-t-il si le client a une latence
  de 5 secondes avec votre serveur ? Que se passe-t-il si la base de données est
  indisponible ? Que se passe-t-il si un paiement ne peut pas être traité
  immédiatement ? Quelle est l'*expérience utilisateur* lorsque quelque chose ne
  va pas ? Ces problèmes ARRIVERONT.

## Conclusion

La prochaine panne arrivera. C'est certain. Peut-être pas aussi importante, mais
il y en aura qui affecteront votre entreprise.

Soyez préparé :

* Connaissez votre infrastructure, vos fournisseurs, leurs fournisseurs, etc.
* Évaluez les risques régulièrement. Votre application évolue, vos fournisseurs
  aussi. Ce qui est vrai à un moment ne l'est plus au suivant.
* Prévoyez le pire des cas. Les incidents arriveront. Votre travail est de faire
  en sorte que l'expérience utilisateur ne soit pas impactée.
