Introduction
Le 17 août 2026, GitHub a cessé de fonctionner pendant sept heures et quarante-sept minutes. Authentification, APIs, Actions, Copilot, pull requests, issues : l'ensemble de la plateforme est tombé simultanément, privant des millions de développeurs de leur outil central. Ce n'était pas le premier incident du mois — GitHub avait déjà connu une panne de plus de sept heures sur Actions le 6 août. Mais l'ampleur du 17 août, et surtout la précision du postmortem publié trois jours plus tard, en font un cas d'école sur la fragilité des infrastructures cloud modernes.
Une cascade, pas un bug
La cause première n'est ni un déploiement raté, ni une faille logicielle, ni une cyberattaque. C'est une défaillance de capacité déclenchée par un volume de trafic sans précédent.
Au cœur du problème : un sidecar Istio — ce composant chargé de médiatiser les communications entre services dans un environnement de service mesh — a atteint sa limite de traitement concurrent dans le centre de données américain de GitHub. Or, le mécanisme d'auto-scaling surveillait l'état du service principal, pas celui de son sidecar. Aucun signal n'a déclenché de montée en charge. Quatre serveurs HAProxy, les répartiteurs de charge internes de la plateforme, ont absorbé l'excès jusqu'à saturation, bloquant les flux d'authentification et créant un effet domino sur l'ensemble des services.
Un second mécanisme a dramatiquement allongé l'incident : un bug latent dans le client VS Code de Copilot, qui réessayait les appels en erreur sans limite. Ce comportement a multiplié le volume de requêtes par dix — de 7 000 à 9 000 requêtes par seconde en temps normal à plus de 100 000 en phase de crise. La tempête de retries, phénomène bien documenté dans les architectures distribuées, a empêché toute tentative de stabilisation pendant plusieurs heures.
La croissance qui fragilise
En arrière-plan, une donnée éclaire le contexte : les commits mensuels traités par GitHub sont passés de 1,4 milliard en avril à 2,9 milliards en août, soit un doublement en quatre mois. Une croissance portée largement par l'adoption des outils d'automatisation et d'assistance au code, qui génèrent des volumes de commits sans commune mesure avec les pratiques manuelles.
Ce rythme change fondamentalement les calculs de capacité. Une infrastructure dimensionnée six mois plus tôt peut devenir insuffisante bien avant la prochaine revue annuelle. Et lorsque les courbes de croissance s'emballent, les angles morts de l'observabilité — comme une politique d'auto-scaling qui ne couvre pas tous les composants d'une chaîne critique — deviennent des vulnérabilités structurelles.
Les chantiers engagés
Face à l'ampleur de l'incident, GitHub a annoncé plusieurs mesures concrètes : ajout de plus de 3 millions de cœurs CPU et de 120 pétaoctets de stockage, accélération de la migration vers l'infrastructure Azure — qui absorbe désormais environ 58 % de la charge de la plateforme —, limitation des politiques de retry sur les services critiques, et renforcement de l'isolation entre composants pour éviter qu'une défaillance locale se propage à l'ensemble du système.
Ce que cela change pour les équipes infrastructure
L'incident illustre une réalité inconfortable : dans les architectures de service mesh modernes, l'observabilité partielle est aussi dangereuse que l'absence d'observabilité. Surveiller un service sans surveiller ses dépendances directes — sidecars, proxys, load balancers — crée des angles morts qui ne se révèlent qu'en conditions extrêmes.
Pour les équipes en charge d'infrastructures critiques, les enseignements sont clairs : les configurations d'auto-scaling doivent couvrir l'ensemble de la chaîne de traitement, les politiques de retry doivent être auditées régulièrement, et les plans de capacité doivent anticiper des courbes de croissance non-linéaires. Ce que ce postmortem documente avec une précision rare, c'est l'anatomie d'une panne que de nombreuses organisations — bien au-delà du seul GitHub — risquent de reproduire.