Le rapport de fiabilité cloud et SaaS d'IncidentHub pour le premier semestre 2026 recense 30,246 pannes chez 1,082 fournisseurs entre janvier et juin, avec un pic en mai à 6 070 incidents ; la seule catégorie des fournisseurs cloud représente 4 723 pannes réparties sur 86 acteurs. Le rapport résume le semestre en une expression : le risque de dépendance — des défaillances qui se propagent en cascade à travers les plans de contrôle, les réseaux edge et CDN, les fournisseurs d'identité et les API d'IA.

Trois cas à retenir

  • Railway, 19 mai, environ 8 heures : l'élément déclencheur fut une suspension automatisée de compte chez Google Cloud, qui a mis hors service le plan de contrôle, l'API et les bases de données de Railway et rendu toutes les charges de travail inaccessibles — y compris celles tournant sur le matériel propre de Railway et sur AWS. Rien n'était cassé au sens matériel : il s'agissait de l'application automatisée d'une politique de plateforme, que le rapport isole comme une catégorie de risque émergente.
  • Google Cloud, incendie de centre de données à Delhi/Mumbai : le trafic des régions indiennes a subi 21 jours et 12 heures de dégradation. GCP n'a enregistré que 2 incidents sur le semestre — la preuve qu'un faible nombre d'incidents ne dit rien du rayon d'impact.
  • Azure, 24 avril, plan de contrôle East US indisponible plus de 12 heures : contention de verrous et bascule incomplète. Quand un plan de contrôle tombe, le plan de données continue souvent de servir, mais vous ne pouvez plus rien créer, dimensionner ni modifier — précisément les opérations dont une gestion d'incident a besoin.

Deux autres chiffres méritent d'être notés : Cloudflare a enregistré 487 incidents sur le semestre (avec un pic à 98 en avril), et le stockage objet de Hetzner a connu 27 jours et 16 heures de dégradation sur nbg1 et 31 jours et 13 heures sur hel1. La tendance : des pannes plus courtes mais plus fréquentes — celles qui ne font jamais la une, mais qui transforment votre système d'alerte en bruit de fond.

Séparez le plan de contrôle du plan de données

La plupart des gens imaginent « le fournisseur est tombé » comme un site inaccessible. Le vrai dommage est souvent plus retors : le site continue de répondre, mais vous ne pouvez plus rien changer — pas de mise à l'échelle, pas d'édition de pare-feu, pas d'émission de certificat, pas de connexion à la console. Un plan d'incident utilisable répond séparément à deux questions : que se passe-t-il quand le service est indisponible, et que se passe-t-il quand le service fonctionne mais que vous en avez perdu le contrôle.

Dessinez la carte des dépendances (moins d'une demi-heure)

Une ligne par tiers, trois colonnes : ce qui casse s'il tombe, le temps nécessaire pour le remplacer, et l'existence d'une alternative.

  • DNS : l'élément qu'il faut le plus impérativement tenir à l'écart de votre fournisseur de CDN. Un DNS hébergé ailleurs est ce qui permet de contourner un CDN défaillant.
  • CDN / proxy inverse : vérifiez que votre origine peut servir seule, sans le CDN — certificat compris. Beaucoup d'origines n'acceptent que les plages de sortie du CDN, ce qui les rend totalement injoignables dès l'instant où le CDN est le problème.
  • Émission de certificats : êtes-vous alerté quand un renouvellement ACME échoue ? Existe-t-il quelque part un certificat de secours émis manuellement ?
  • Stockage objet et sauvegardes : au moins une copie doit résider chez un autre fournisseur, et la restauration doit avoir été répétée. Le multi-AZ chez un même fournisseur ne protège pas des événements au niveau du compte.
  • Le compte et la facturation eux-mêmes : moyen de paiement expiré, adresse de contact morte, signalement automatique — le cas Railway montre que cela suffit à tout remettre à zéro. Revérifiez périodiquement contacts de facturation, moyens de paiement et état de vérification du compte.
  • Accès hors bande : clés privées SSH, codes de récupération de console, points d'entrée du support — en existe-t-il une copie qui ne nécessite pas de se connecter à la plateforme qui vient de tomber ?

Pourquoi un VPS indépendant et sans fioritures constitue un utile filet de sécurité

Il ne s'agit pas d'affirmer que l'auto-hébergement est plus fiable : une machine n'a pas de multi-AZ, et du matériel mort reste mort. Mais dans une architecture empilant des services managés, une instance que vous contrôlez entièrement, joignable directement en SSH et capable de servir seule des pages statiques et des services de base, constitue un maillon réellement utile de la chaîne de reprise : un hébergement pour la page de maintenance, une origine temporaire après une bascule DNS, un second point de chute pour les sauvegardes. SharkCloud dispose de nœuds au Japon, à Singapour, à Hong Kong et aux États-Unis — et placer cette instance de secours chez un autre fournisseur, dans une autre région, est la case la plus simple à remplir sur votre carte des dépendances.