Panne majeure chez Railway : comment la restriction d’un compte Google Cloud a fait tomber toute la plateforme

Fin mai, la plateforme pour développeurs Railway a connu une panne majeure qui a rendu indisponibles pendant plusieurs heures son tableau de bord, ses API, ses déploiements et de nombreuses applications hébergées.

L’origine du problème : Google Cloud a automatiquement placé le compte de production de Railway dans un état « restreint », supprimant l’accès à plusieurs ressources d’infrastructure critiques.

Même si le service a finalement été rétabli, l’incident illustre à quel point l’infrastructure d’une plateforme peut dépendre d’un seul fournisseur cloud — même lorsque certains composants fonctionnent ailleurs.

Chronologie de la panne

La panne a commencé entre 22 h 20 et 22 h 29 UTC le 19 mai. Les systèmes de Railway ont soudainement perdu l’accès à plusieurs ressources essentielles hébergées sur Google Cloud. Très vite, les utilisateurs ont signalé des anomalies : le tableau de bord ne chargeait plus, l’authentification échouait et certaines applications renvoyaient des erreurs "upstream".

Les ingénieurs de Railway ont ensuite indiqué que leur compte Google Cloud avait été placé en statut “restricted”, ce qui a entraîné la suppression automatique de plusieurs ressources liées à ce compte.

Le rétablissement complet a pris plusieurs heures, le temps que l’équipe collabore avec le support Google Cloud pour récupérer l’accès et restaurer les services. Selon des témoignages de la communauté, même avec des contacts de support entreprise, il a fallu du temps pour comprendre l’origine de la restriction et débloquer la situation.

Pourquoi les services essentiels ont immédiatement cessé de fonctionner

La restriction a touché des composants dont dépendaient à la fois les charges de travail des clients et les systèmes internes de Railway.

D’après la mise à jour publiée par l’entreprise, plusieurs éléments clés ont disparu en même temps :

• CloudSQL, qui stockait des données de la plateforme
• L’API de Railway, dépendance centrale du système
• Des machines virtuelles d’overflow, utilisées pour absorber les pics de calcul

Lorsque l’API a été supprimée, une dépendance majeure du plan de contrôle de la plateforme est devenue indisponible. De nombreux services internes reposant dessus se sont donc retrouvés interrompus.

Sans ces briques fondamentales, Railway ne pouvait plus faire fonctionner correctement :

• le tableau de bord et les connexions utilisateur
• les workflows de déploiement
• le routage vers les applications en cours d’exécution
• la construction et le provisionnement de nouveaux services

Résultat : l’interface développeur et les applications hébergées sont devenues instables ou inaccessibles pendant la durée de l’incident.

Pourquoi la panne s’est propagée à toute la plateforme

La perturbation ne s’est pas limitée aux ressources initialement supprimées. Elle s’est propagée parce que les couches d’orchestration et de routage dépendaient aussi de ces services.

Les ingénieurs de Railway ont indiqué que certains utilisateurs pouvaient récupérer leurs applications en redéployant leurs projets, ce qui permettait de les router vers une machine saine une fois certaines parties de l’infrastructure restaurées.

Cela suggère que le plan de contrôle — responsable de la planification, du routage et de la reconstruction des charges de travail — ne pouvait pas se rétablir automatiquement tant que les ressources Google Cloud restaient inaccessibles.

Certaines analyses de la communauté ont également avancé que des workloads hébergés en dehors de Google Cloud — par exemple sur AWS ou sur le matériel propre à Railway — pouvaient être affectés parce que l’état de routage de la plateforme ne pouvait plus être mis à jour. Cependant, le mécanisme technique exact derrière cette propagation n’a pas encore été confirmé par un post‑mortem public détaillé.

Le mythe de la résilience « multi‑cloud »

Un point particulièrement discuté après la panne concerne l’architecture multi‑cloud.

Railway exploite de l’infrastructure répartie entre plusieurs environnements — notamment AWS et du matériel dédié. Pourtant, l’incident a montré que la véritable résilience dépend surtout de l’endroit où se trouve le plan de contrôle.

Si les systèmes qui gèrent l’orchestration, l’identité, le routage ou les bases de données reposent sur un seul compte chez un fournisseur cloud, ce fournisseur devient de fait un point de défaillance unique.

La perte de ce compte ne signifie pas seulement la perte de ressources de calcul. Elle peut aussi empêcher les systèmes qui :

• suivent les déploiements
• gèrent le routage
• provisionnent l’infrastructure
• restaurent les charges de travail

De fonctionner correctement.

Les inquiétudes autour de l’automatisation des sanctions cloud

La panne a également relancé le débat sur les mécanismes automatisés d’application des règles chez les fournisseurs cloud.

Les grandes plateformes peuvent restreindre ou suspendre automatiquement un compte pour diverses raisons : problème de facturation, suspicion d’abus, violation de politiques ou incident de sécurité.

Dans ce cas précis, la raison exacte de la restriction appliquée par Google Cloud n’a pas été confirmée publiquement. On ignore donc s’il s’agissait d’une mesure automatique, d’une erreur ou d’un autre type d’incident opérationnel.

L’épisode met en évidence deux risques opérationnels :

• une action automatisée peut désactiver instantanément une infrastructure critique
• même avec un support entreprise, l’enquête et la restauration peuvent prendre plusieurs heures

Ce qui reste encore inconnu

Malgré les mises à jour publiées et les discussions dans la communauté, plusieurs points restent flous :

• la raison précise de la restriction du compte Google Cloud
• la cartographie exacte des dépendances internes entre CloudSQL, l’API, le routage et l’infrastructure de calcul
• la confirmation technique de certains effets en cascade évoqués par des observateurs

En attendant un post‑mortem détaillé, l’explication publique reste une reconstruction basée sur les informations disponibles.

La leçon pour les plateformes cloud

La panne du 19 mai rappelle une réalité souvent sous‑estimée dans les architectures modernes : les dépendances du plan de contrôle comptent plus que la diversité de l’infrastructure.

Une plateforme peut répartir ses serveurs entre plusieurs clouds, mais si le système qui gère le routage, les déploiements et l’orchestration dépend d’un seul compte fournisseur, la perte de ce compte peut suffire à arrêter toute la plateforme.

Pour les startups et les fournisseurs d’infrastructure, l’incident rappelle un défi d’ingénierie bien connu : éviter les points de défaillance uniques cachés dans les systèmes censés tout contrôler.