Le lundi 17 août à 13 h 28 UTC, GitHub s'est mis à renvoyer des erreurs, et pas quelques-unes : au pic, environ une requête web ou API sur cinq échouait, et près d'une archive ou d'un téléchargement de contenu brut sur deux.2 La page d'erreur à la licorne s'est affichée pour des développeurs sur six continents ; le premier signalement utilisateur est arrivé chez le service de supervision StatusGator à 12 h 47 UTC, plus de quarante minutes avant que la page de statut de GitHub ne reconnaisse quoi que ce soit.3

L'incident a officiellement couru de 13 h 28 à 21 h 15 UTC — sept heures quarante-sept minutes — en touchant à des degrés divers Issues, pull requests, API, Actions, webhooks, opérations Git, Pages, connexion SAML et OIDC, provisioning SCIM, Team Sync et Copilot.12

Si celle-ci mérite l'autopsie, c'est parce que la chaîne de défaillance s'est révélée d'une lisibilité rare une fois que GitHub a publié son analyse de cause racine le jour même de la résolution, puis un postmortem trois jours plus tard signé du CTO Vlad Fedorov12 : un pod sidecar a atteint une limite, la machinerie chargée de s'en apercevoir regardait un autre compteur, quatre répartiteurs de charge sont tombés avec lui, puis les clients de la plateforme — y compris son propre éditeur — ont rallongé la récupération de plusieurs heures en voulant trop bien faire.

Lundi, 13 h 28

La chronologie publique vaut le détour, parce qu'elle montre à quelle vitesse un problème localisé est devenu le problème de tout le monde.2

Le premier avis « investigating » est monté à 13 h 40 UTC, douze minutes après le début officiel, l'API étant déjà en train de se dégrader ; Actions et les webhooks ont suivi en quatre minutes. À 13 h 45, GitHub a posé un chiffre : environ 20 % d'erreurs sur de nombreuses expériences. Pull Requests et Issues ont rejoint la liste des services dégradés avant 14 h. À 14 h 24 arrive le détail qui change la classe de gravité : SAML, OIDC, SCIM et Team Sync sont touchés. Le site qui passait un mauvais après-midi devenait autre chose — les organisations dont l'authentification unique transite par GitHub ne pouvaient plus se connecter de façon fiable.

Copilot a rejoint la liste à 14 h 31 et les opérations Git à 15 h 21. Entre 15 h 42 et 16 h 16, les ingénieurs appliquent des atténuations sans encore avoir trouvé la cause racine. Le virage vient à 16 h 36, quand le composant fautif est identifié et corrigé, avec ce que GitHub appelle de forts signes de récupération ; la plupart des services se stabilisent à mesure que le data center du centre des États-Unis revient.2

L'avis de résolution n'arrive pourtant qu'à 21 h 15. Entre ces deux horaires se loge la partie la plus instructive de toute l'histoire.

La cascade

Voici le mécanisme, dans l'ordre.2

Le trafic atteint un nouveau pic, et dans le data center du centre des États-Unis un pod sidecar Istio — le petit proxy collé à chaque service dans un mesh, qui porte son trafic réseau — atteint ses limites de concurrence. Survivable sur le papier : le mesh doit simplement faire monter le service en charge et passer au suivant.

Sauf que la politique d'autoscaling avait été mal configurée, surveillant la capacité du service hôte tout en ignorant les limites du sidecar lui-même, si bien que le composant chargé d'ajouter de la capacité mesurait tout sauf le composant qui venait d'en manquer. Les requêtes continuaient d'arriver, le proxy restait cloué à son plafond, et la panne commençait à s'étendre.

Quatre nœuds HAProxy finissent par épuiser leurs limites de flux ; ils siègent sur le chemin d'authentification de la passerelle, donc le symptôme visible devient latence d'authentification, puis échecs francs, sur des services qui n'avaient rien à voir directement avec le pod d'origine. On se connecte et on attend, on réessaie et on échoue, et toute surface authentifiée hérite du problème.

Puis vient le détail qui transforme un incident de capacité en panne prolongée : la logique de retry du système, qualifiée d'optimiste par GitHub, s'est mise à saturer les répartiteurs internes de tentatives répétées,2 offrant à un système en difficulté du travail supplémentaire précisément parce qu'il échouait.

La couverture indépendante a relevé la même absurdité que connaissent tous les ingénieurs : comme le résumait The Register en commentant la RCA, une mauvaise configuration et une tempête de retries avaient dégradé une infrastructure critique « dont dépendent beaucoup d'organisations ».4

Le mauvais compteur

Il faut s'arrêter sur le bug d'autoscaling : plus petite pièce de la chaîne, et pourtant sa leçon la plus transportable.

Un autoscaler ne réagit qu'aux signaux qu'on lui donne, et ici le signal sain existait, observable dans la concurrence du sidecar ; la politique de scaling était simplement braquée sur les métriques du service hôte.2 Rien n'était cassé dans la machinerie elle-même — elle regardait fidèlement un compteur qui n'allait jamais bouger pendant que le vrai goulot se remplissait.

Après coup, personne ne paraît négligent, et c'est précisément pourquoi cette classe de bug survit aux revues : quelqu'un a configuré le scaling du service, quelqu'un d'autre déploie les sidecars, et personne n'a jamais testé le câblage entre ces deux décisions contre le scénario qui comptait — que se passe-t-il quand le sidecar, plutôt que le service, manque de place le premier ?

La liste de correctifs de GitHub concède exactement ce point, promettant des politiques d'autoscaling corrigées pour prendre en compte la concurrence des sidecars du mesh et un audit des plafonds Istio — appels, concurrence, scaling — sur tous les services touchés.2 Traduction : nous allons chercher partout où le compteur et le goulot divergent.

Pause générale

Le premier geste de réparation semble à l'envers : mettre en pause simultanément HAProxy sur les quatre nœuds touchés a produit, selon les mots de GitHub, un rétablissement général immédiat.2

La logique devient claire dès qu'on se rappelle ce que font quatre points d'étranglement épuisés tout l'après-midi — accepter du trafic auquel ils ne peuvent pas répondre, et offrir à chaque client déçu une raison neuve de ressayer. Les sortir du circuit au même instant coupe la boucle, la demande cesse d'affluer vers un chemin incapable de la traiter, et le reste du système reprend son souffle. Une partie du trafic en échec avait déjà été redirigée vers le nord de la Virginie, servi correctement pendant que les ingénieurs débattaient avec le centre des États-Unis.2

À 16 h 36 UTC, l'atténuation générale était en place ; si l'histoire s'était arrêtée là, nous parlerions d'un incident banal de trois heures et demie plutôt que d'une panne de presque huit heures.

Dix fois trop fort

Pendant que le trafic basculait vers la Virginie, des réponses tardives d'un point de terminaison interne unique ont déclenché ce que GitHub appelle un bug de retry latent dans VS Code:2 confronté à des réponses lentes pendant la panne, l'éditeur a généré des tentatives répétées bien au-delà de ce que la situation justifiait, multipliant par environ dix le trafic vers le Copilot Token Service.

Les chiffres méritent qu'on les regarde en face. Le trafic normal de ce service tourne entre 7 000 et 9 000 requêtes par seconde ; pendant la tempête il a atteint 70 000 à 100 000 req/s,2 chaque opération de token ratée générant des appels supplémentaires capables d'entrer dans des boucles de retry bien à eux. La récupération se battait désormais sur deux fronts — la saturation d'origine, plus le logiciel client de la plateforme exigeant des tokens à dix fois le volume normal.

Les contre-mesures ressemblent à du triage : les ingénieurs ont temporairement réduit la logique de retry de la passerelle — en poussant, pour ainsi dire, une pull request en pleine panne pour dire à l'infrastructure d'arrêter d'être aussi serviable2 — puis bloqué à hauteur des load balancers les requêtes entrantes vers le Copilot Token Service avec des réponses HTTP 403, avant de remonter le trafic progressivement, site par site, pour que les appelants réussissent au lieu de retomber dans leurs boucles. Le choix du 403 compte pour une raison précise : contrairement à un timeout ou à un 5xx, il ne porte aucune invitation polie à ressayer.

Le rétablissement a aussi eu des invités surprise : des attaques de scraping sur les points de terminaison codeload ont ajouté de la charge pendant la fenêtre, listées par GitHub parmi les facteurs qui ont gêné la progression.2 Actions est dégagé vers 18 h 03, Issues se stabilise à 20 h 22, les derniers échecs d'authentification Copilot prennent fin quand le Token Service se rétablit complètement à 21 h 02, et l'incident est clos à 21 h 15.2

Le motif mérite un nom : la défaillance initiale a été contenue en nettement moins de la moitié du temps total de l'incident, et tout ce qui suit 16 h 36 a servi à dompter l'amplification de charge — la logique de retry générique d'abord, puis un client précis porteur d'un bug précis.5

Déjà vu en février

Aucun de ces mécanismes ne surprendra qui a lu les billets de GitHub au printemps, car le 17 août appartient à une famille d'incidents documentée depuis février.67

Le 9 février, le cluster central qui portait l'authentification et les comptes utilisateurs a été submergé. Deux applications clientes fraîchement publiées avaient involontairement fait bondir leur trafic de lecture de plus de dix fois, et un déploiement du 7 février avait changé un TTL de cache de rafraîchissement de 12 heures à 2, multipliant les écritures. La charge du week-end avait masqué la combinaison jusqu'à ce que lundi arrive avec son pic habituel, les mises à jour des applications et une autre sortie de modèle ensemble. On retrouve ce motif du lundi, et cette amplification par dix — venue cette fois des clients, braquée droit sur un cluster central.6

Le mois précédent, les runners hébergés étaient tombés dans toutes les régions après qu'un trou de télémétrie a fait appliquer des politiques de sécurité aux comptes de stockage internes. En mars, un failover Redis laissait un cluster sans primaire inscriptible à cause d'une configuration latente. Le 23 avril, une régression de merge queue inversait silencieusement des changements dans 658 dépôts, touchant 2 092 pull requests ; le 27 avril, un cluster Elasticsearch, vraisemblablement sous attaque par botnet, cessait de renvoyer des résultats de recherche — un système que GitHub admettait ne pas avoir encore isolé comme point de défaillance unique.67

Entre ces incidents d'avril et le 17 août s'est glissé le 6 août : un déploiement banal sur un service Actions interne exposait une faiblesse de capacité préexistante, les pods se crashaient en chaîne, et au pic 71 % des exécutions de workflows subissaient des défaillances d'infrastructure. Les runners se coinçaient ensuite à ressayer des jobs invalides — encore des retries — traînant le rétablissement au-delà de neuf heures.8

Lus ensemble, ces incidents partagent une signature : une dépendance partagée sous croissance brutale, un garde-fou qui regardait ailleurs, et des clients dont les réflexes d'auto-réparation aggravent les choses. En mars, GitHub nommait ses trois causes structurelles sans détour — croissance rapide de la charge, couplage architectural qui laisse les problèmes locaux se propager, incapacité à délester les clients qui se comportent mal.6 Six mois et plusieurs postmortems plus tard, les trois se présentaient au rendez-vous du 17 août en costumes différents.

La critique honnête vaut dans les deux sens ici. Publier des RCA détaillés en quelques jours est une pratique vraiment bonne, la précision de l'analyse du 17 août dépasse nettement la norme du secteur, et la discussion Hacker News qui a récolté 636 points a surtout disputé de mécanique plutôt que de dissimulation.10 La récurrence reste le résultat, cependant : connaître ses modes de défaillance en février ne les retirait pas en août, et seule une reconstruction y parvient.

Trois millions de cœurs

Alors, qu'est-ce que GitHub a construit ? La réponse du postmortem est concrète1 : depuis les engagements de fiabilité pris au printemps, plus de 3 millions de cœurs CPU et 120 péaoctets de stockage rapide sont entrés dans la plateforme, plus une capacité réseau significative. Un détail physique se cache dans ces chiffres — le matériel est allé jusqu'à ce que la puissance disponible le permette dans les data centers existants — et même une plateforme de la taille de GitHub rencontre le mur où l'électricité rencontre le béton, ce qui explique en partie pourquoi la migration vers Azure compte au-delà des feuilles de coûts.

Azure sert aujourd'hui environ 58 % de la charge de plateforme de GitHub et la moitié des opérations Git, contre 12 % de la charge en mai. Pour situer : en mars, l'entreprise célébrait 12,5 % du trafic sur Azure et visait 50 % en juillet ; le rapport de disponibilité de juillet relevait un pic de trafic de lecture du monolithe à 52,75 % le 28 juillet, un trafic Git sur Azure à 47 %, et notait que le cœur d'Actions tournait encore entièrement dans les data centers maison — signalé alors comme facteur des problèmes de capacité qu'Actions allait rencontrer six jours plus tard.69

La courbe de demande explique l'urgence : depuis avril, les commits mensuels sont passés de 1,4 milliard à 2,9 milliards, un doublement en quatre mois. Les graphiques du postmortem montrent environ 130 millions de pull requests fusionnées par mois et autour de 24 millions de nouveaux dépôts par mois, avec une accélération visible à travers 2025 et 2026.1 Fedorov attribue le basculement sans détour : aucun des deux incidents d'août n'a été causé par un changement de code ou de configuration, et tous deux étaient au fond des défaillances de capacité. « We failed to scale critical components before demand exceeded their capacity », écrit-il — nous n'avons pas fait évoluer des composants critiques avant que la demande n'excède leur capacité. Et d'ajouter : « Cette croissance explique la pression sur nos systèmes, mais elle n'excuse pas ces pannes. »1

La mise à jour d'avril avait déjà tracé l'origine de la croissance : des flux de développement agentique qui s'accélèrent brutalement depuis la seconde moitié de décembre 2025, poussant ensemble création de dépôts, activité de PR, usage des API, automatisation et charges monorepo.7 Les plans de capacité dessinés pour une croissance de 10X en octobre 2025 étaient redessinés pour 30X dès février. Et quand des agents écrivent, chaque commit entraîne derrière lui ses exécutions CI, ses appels API, ses webhooks et ses authentifications de tokens, si bien que la charge de la plateforme cesse d'être proportionnelle à la vitesse de frappe humaine.

Lire sans plafond

L'architecture annoncée pour la suite tient en une promesse discrètement radicale : une capacité de lecture qui évolue linéairement avec le nombre de lecteurs, permettant des opérations de lecture illimitées.1

Des lectures illimitées casseraient le couplage actuel entre popularité et douleur, parce que quand un dépôt grimpe — projet viral, clonage massif pendant un incident — le débit de fetch plafonne aujourd'hui. Le propre graphique de GitHub montre un chemin de fetch qui s'aplatit autour de 1 000 opérations par seconde avant de retomber, à côté d'un chemin redessiné qui monte en marches vers 1 800 OPS/S, et le déploiement commence par les plus gros monorepos, précisément les charges que le développement agentique gonfle en premier.1

Les travaux d'isolation continuent en parallèle : retirer les dépendances partagées entre systèmes critiques pour qu'un composant saturé ne puisse plus traverser les produits comme l'a fait le chemin d'authentification du 17 août. Le rapport de juillet résumait la stratégie en une ligne à garder — GitHub devient moins dépendant d'infrastructures partagées et de lieux physiques individuels.9

Des budgets pour les retries

Deux changements immédiats sortent des incidents d'août, et tous deux ciblent la couche d'amplification plutôt qu'un composant quelconque.1

Premier : des limites de retry, des budgets de retry et des timeouts variables cohérents sur tous les échanges entre services, pour prévenir les tempêtes de retries et la charge en cascade. Second : repasser les alertes CPU et mémoire jugées secondaires afin de repérer les composants capables de céder pendant un pic soudain de trafic — refermer exactement l'angle mort où vivait la politique du sidecar.

Un budget de retry mérite une définition en clair, parce que chaque équipe qui construit sur des systèmes distribués en aura besoin tôt ou tard. Le retry convertit une requête échouée en plusieurs tentatives, échangeant de la charge supplémentaire contre de la résilience aux fautes passagères, et cet échange fonctionne tant que les échecs sont rares et indépendants. En surcharge, les échecs deviennent fréquents et corrélés, donc les retries cessent d'être une assurance pour devenir du trafic d'attaque venu de l'intérieur. Un budget plafonne l'échange : une part du trafic peut être du retry, et passé cette ligne le système échoue vite au lieu de se nourrir de lui-même. Combiné à un backoff avec gigue et des timeouts variables selon l'opération, il empêche une dépendance lente de recruter tous les clients contre vous.

La RCA ajoute le miroir côté clients : revoir limites de retry et comportements de backoff sur les passerelles comme sur les clients, traiter spécifiquement le comportement de VS Code, améliorer la surveillance de capacité des load balancers et construire des garde-fous de bascule régionale.2 Le mot intéressant est « clients » : GitHub traite désormais le comportement de retry des logiciels qu'il livre — éditeurs, CLIs, applications — comme faisant partie de sa propre surface de fiabilité, ce qu'aucun achat de matériel n'aurait réglé. Votre panne inclut ce que font les outils de vos utilisateurs quand vous hoqutez.

Ce qui reste

Retirez les noms de marque, et la chaîne du 17 août devient une liste de contrôle que n'importe quel builder peut passer sur sa propre pile, à n'importe quelle échelle.25

Surveillez le compteur de ce qui sature en premier — dans votre pile, ce sera peut-être un pool de workers, un plafond de connexions SQL, une profondeur de file, un limiteur de débit, quoi que ce soit qui touche son plafond avant les beaux tableaux de bord — car un autoscaling braqué ailleurs n'est que de la décoration. Budgétez aussi vos retries des deux côtés du fil : caps serveur et échec rapide en charge d'un côté, hypothèse côté client que votre application tournera pendant la mauvaise journée de quelqu'un d'autre de l'autre, parce que la leçon de VS Code généralise de façon inconfortable et que le code que vous livrez devient la charge d'incident de quelqu'un d'autre.

Testez le rétablissement plutôt que la seule panne : celui de GitHub a réussi quand des opérateurs ont cassé les boucles à la main, pause simultanée des proxies, blocage des requêtes de tokens, remontée progressive des sites, rien de tout ça n'étant automatique — alors si votre plan suppose que le système guérit tout seul, injectez de la latence dans un game day de staging et regardez si vos retries tiennent leurs promesses.

Continuez aussi d'écrire des postmortems honnêtes : une qualité de document pareille est la raison pour laquelle cet incident peut être étudié, et la récurrence à travers février, avril et août est la raison pour laquelle l'étudier compte. L'artisanat de l'infrastructure, comme tout artisanat, se juge à ce qui arrive quand la matière résiste.