GitHub a publié jeudi son récit de la panne du dix-sept août, et la cause racine est l'une des plus instructives que nous ayons lues cette année. Aucune mise en production. Aucun changement de configuration. Le trafic a simplement atteint un nouveau pic, un proxy sidecar Istio du centre de données Central US a saturé sa limite de traitement concurrent, et l'autoscaling ne surveillait que le conteneur applicatif à côté, donc il n'a rien vu qui mérite une réaction. Ont suivi sept heures et quarante-sept minutes de service dégradé, aggravées par un défaut de relance dans Visual Studio Code qui a fait passer un service d'authentification de neuf mille requêtes par seconde à cent mille.
The short answer
Le directeur technique de GitHub, Vladimir Fedorov, a publié le post-mortem du dix-sept août le jeudi vingt août. Un proxy sidecar Istio du centre de données Central US a atteint sa limite de traitement concurrent quand le trafic a battu un record, et les règles d'autoscaling ne surveillaient que le conteneur applicatif : rien n'a été mis à l'échelle. La saturation a gagné la couche HAProxy et fait tomber l'authentification interne. Un défaut de relance dans Visual Studio Code a ensuite porté le service de jetons Copilot de 9 000 à 100 000 requêtes par seconde, retardant d'autant le rétablissement.
La plupart des post-mortems publics vous disent quel changement a cassé la production. Celui-ci vous dit que rien n'a changé, et c'est la version qui devrait inquiéter quiconque exploite un maillage de services.
Le composant que personne ne mettait à l'échelle
GitHub fait tourner ses services avec Istio : une requête entre deux services internes ne va pas directement d'un conteneur applicatif à un autre. Elle traverse un proxy sidecar exécuté dans le même pod, qui prend en charge le routage, les relances, la télémétrie et l'authentification mutuelle pour le compte de l'application.
Le dix-sept août, le trafic a atteint un nouveau pic et ce sidecar a atteint sa limite de traitement concurrent dans le centre de données Central US. Les règles d'autoscaling lisaient l'état du conteneur applicatif principal, pas celui du sidecar à côté : les pods paraissaient sains et aucune extension n'a été déclenchée.
C'est le point sur lequel il faut s'arrêter. L'application allait bien. La métrique à laquelle tout le monde faisait confiance allait bien. Le composant qui portait réellement chaque requête n'avait plus de marge, et il était invisible pour la boucle de contrôle chargée d'en ajouter.
La saturation s'est ensuite propagée vers l'extérieur. Les répartiteurs de charge HAProxy en amont ont atteint leurs propres limites de traitement, les chemins d'authentification internes sont devenus instables, et comme presque toutes les surfaces de GitHub s'authentifient contre eux, la panne s'est présentée comme un ensemble légèrement cassé partout à la fois plutôt que comme un service à l'arrêt.
La tempête de relances par-dessus
Le rétablissement ne consistait pas seulement à ajouter de la capacité, parce qu'un défaut côté client luttait activement contre la restauration.
Visual Studio Code relançait agressivement quand l'authentification Copilot échouait, sans temporisation efficace. Chaque éditeur qui rencontrait une erreur revenait aussitôt. GitHub donne les chiffres sans détour : le service qui délivre les jetons d'authentification Copilot voit normalement 7 000 à 9 000 requêtes par seconde, et il en a vu 70 000 à 100 000 pendant l'incident.
Une amplification par dix qui arrive précisément au moment où un service est le moins capable de répondre, c'est la tempête de relances classique, et elle s'auto-entretient. La panne produit la charge qui empêche la panne de se terminer. GitHub a dû atténuer ce comportement avant de pouvoir réacheminer le trafic sans risque, ce qui explique que Copilot soit revenu plus tard que le reste de la plateforme.
Si vous écrivez des clients, c'est le rappel qu'il faut vérifier ce que fait le vôtre face à une erreur 5xx. Une relance sans budget n'est pas de la résilience, c'est un multiplicateur de charge qui ne s'active que pendant les incidents.
Les chiffres de croissance expliquent la forme du problème
Le post-mortem contient des données qu'on voit rarement publiées, et elles recadrent l'incident autrement que comme de la négligence.
Les contributions mensuelles sont passées de 1,4 milliard en avril à 2,9 milliards en août. Les exécutions de tâches Actions ont atteint 115,4 millions en août. Azure sert désormais environ 58 pour cent de la charge de la plateforme et la moitié des opérations Git, contre 12 pour cent de la charge en mai.
Ce ne sont pas des courbes douces. Une plateforme qui double son volume d'écriture en quatre mois tout en migrant la majorité de sa charge vers un autre socle va rencontrer des plafonds, et elle les rencontrera dans les composants que personne n'a pensé à instrumenter. Fedorov est clair : ni l'incident du dix-sept août ni la dégradation d'Actions du six août ne viennent d'un changement de code ou de configuration. Les deux sont des défaillances de capacité.
Ce que GitHub s'engage à faire
Le plan de remédiation se répartit entre capacité, discipline des relances et rayon d'impact.
Côté capacité, plus de 3 millions de cœurs de calcul, 120 pétaoctets de stockage rapide et de la capacité réseau supplémentaire ont été ajoutés, avec une migration Azure accélérée.
Côté relances, des limites de relance, des budgets de relance et des délais d'attente variables sont appliqués de façon homogène aux échanges entre services, précisément pour empêcher les tempêtes de relances et les charges en cascade. C'est la bonne leçon à tirer des chiffres sur les jetons Copilot, et elle vaut autant pour le maillage interne que pour l'éditeur.
Côté rayon d'impact, GitHub revoit ses alertes processeur et mémoire de faible priorité pour identifier les composants susceptibles de céder pendant un pic, et isole les systèmes critiques afin que des dépendances partagées ne puissent plus emporter plusieurs produits ensemble.
Ce que nous en retenons
Trois enseignements se transposent directement à des parcs plus modestes.
Mettez à l'échelle sur ce qui sature, pas sur ce que vous avez nommé. Si vous exploitez un maillage de services, votre autoscaler horizontal lit probablement le processeur du conteneur applicatif. Le proxy a sa propre limite de concurrence, son propre pool de connexions et ses propres métriques, et Envoy les expose. Un autoscaler qui ne voit pas le proxy regardera tranquillement un pod étouffer.
Donnez un budget à chaque relance. Les limites seules ne suffisent pas, parce qu'une limite autorise toujours tous les clients à relancer en même temps. Un budget plafonne les relances en proportion du trafic total, ce qui borne l'amplification quel que soit le nombre d'appelants en échec.
Traitez vos alertes de faible priorité comme un carnet de capacité. GitHub reprend explicitement les alertes qu'il avait déclassées pour trouver les composants qui peuvent céder sous un pic. La plupart des équipes ont la même liste, qui se déclenche discrètement toutes les quelques semaines et se referme tout aussi discrètement. Le sidecar est quelque part dedans.
Sources et pour aller plus loin
- The August 17 outage, and the work ahead, The GitHub Blog, 20 août 2026
- GitHub's ~8-Hour Outage Caused by Capacity Shortage, BigGo Finance, août 2026
- GitHub now sees 2.9 billion commits a month, The New Stack, août 2026
- GitHub Status
Questions fréquentes
Qu est-ce qui a réellement lâché pendant la panne GitHub du 17 août ?
Un proxy sidecar. GitHub utilise Istio, donc le trafic entre services ne va pas directement d'un conteneur applicatif à un autre. Il traverse un conteneur sidecar placé dans le même pod, qui prend en charge le routage, les relances, la télémétrie et l'authentification mutuelle. Quand le volume de requêtes a atteint un nouveau sommet, ce sidecar a atteint sa limite de traitement concurrent. Les règles d'autoscaling observaient le service principal et non le sidecar : du point de vue de l'ordonnanceur, tout allait bien et aucune capacité n'a été ajoutée. La saturation s'est ensuite propagée aux répartiteurs de charge HAProxy, qui ont atteint leurs propres limites et déstabilisé les chemins d'authentification internes dont presque tout le reste dépend.
Combien de temps GitHub a-t-il été indisponible et sur quels services ?
L'incident a duré sept heures et quarante-sept minutes le dix-sept août 2026, en gros de 13 h 28 à 21 h 15 UTC. Il s'agissait d'une dégradation plutôt que d'une coupure nette, ce qui est souvent plus pénible à traverser. Les taux d'erreur tournaient autour de vingt pour cent pour l'interface web et l'API, et autour de cinquante pour cent pour les téléchargements d'archives et le contenu brut des dépôts. L'authentification, Actions, les demandes de fusion, les tickets et Copilot ont tous été touchés. C'est cette irrégularité qui explique pourquoi GitHub semblait fonctionner chez un collègue et pas chez vous.
Quel est le rapport avec Visual Studio Code ?
Il a transformé une mauvaise heure en une très longue journée. Un défaut de Visual Studio Code relançait agressivement les appels quand l'authentification Copilot échouait, sans temporisation efficace. Chaque session d'éditeur qui rencontrait une erreur revenait immédiatement. Le service qui délivre les jetons d'authentification Copilot est passé de 7 000 à 9 000 requêtes par seconde en temps normal à une fourchette de 70 000 à 100 000. C'est une tempête de relances côté client, et elle s'auto-entretient : la charge produite par la panne empêche le rétablissement qui mettrait fin à la panne. GitHub a dû neutraliser ce comportement avant de pouvoir rétablir le trafic sans risque.
Est-ce la faute des agents IA qui martèlent la plateforme ?
Pas directement, mais la courbe de croissance derrière l'incident est difficile à séparer de l'outillage automatisé. GitHub indique que les contributions mensuelles sont passées de 1,4 milliard en avril à 2,9 milliards en août, et que les exécutions de tâches Actions ont atteint 115,4 millions en août. Azure porte désormais environ 58 pour cent de la charge de la plateforme et la moitié des opérations Git, contre 12 pour cent de la charge en mai. L'entreprise est explicite : ni cet incident ni la dégradation d'Actions du six août ne viennent d'un changement de code ou de configuration. Ce sont des défaillances de capacité, une catégorie différente et plus difficile à tester.
Que change GitHub pour éviter la récidive ?
Trois axes. D'abord la capacité brute : plus de 3 millions de cœurs de calcul, 120 pétaoctets de stockage rapide et de la capacité réseau supplémentaire ont déjà été ajoutés, en plus d'une migration Azure accélérée. Ensuite la discipline des relances, avec des limites de relance, des budgets de relance et des délais d'attente variables appliqués de façon homogène aux appels entre services, pour qu'une défaillance partielle ne puisse plus s'amplifier elle-même. Enfin l'observabilité et le rayon d'impact, avec une revue des alertes processeur et mémoire de faible priorité qui auraient pu signaler plus tôt le composant saturé, et l'isolation des systèmes critiques pour supprimer les dépendances partagées entre eux.