La panne de GitHub : une charge de commits doublée

Sept Heures Quarante-Sept Minutes, Attribuées À Un Proxy Saturé

Le rapport de GitHub, publié sur son propre blog d'ingénierie sous le titre 'The August 17 outage, and the work ahead', attribue la défaillance à un proxy sidecar Istio dans son centre de données Central US qui a atteint sa capacité maximale de traitement concurrent. La politique d'autoscaling qui surveillait cette capacité n'évaluait que le service applicatif lui-même, pas l'état de connexion et de concurrence des sidecars placés devant lui, si bien que rien n'a été mis à l'échelle quand les sidecars ont atteint leur limite. Une fois ces proxys saturés, les requêtes se sont déplacées vers d'autres nœuds, qui ont à leur tour atteint leurs propres plafonds de capacité, et la logique de nouvelle tentative automatique de GitHub a aggravé la spirale en envoyant de nouvelles requêtes vers des répartiteurs de charge déjà surchargés. Un bug de nouvelle tentative distinct, selon The Register logé dans une extension VS Code utilisée pour l'authentification de GitHub Copilot, a encore aggravé la défaillance : il redemandait sans pause de nouveaux jetons d'authentification, poussant le service d'émission de jetons de GitHub d'une base normale de 7 000 à 9 000 requêtes par seconde jusqu'à 70 000 à 100 000 requêtes par seconde, soit environ dix fois la charge habituelle.

Les Chiffres Derrière Un Mauvais Après-Midi

La panne s'est étendue du 17 août 2026, de 13h28 à 21h15 UTC, et les propres mises à jour de statut de GitHub ont situé les taux d'erreur maximaux autour de 20 pour cent sur le trafic web et API et environ 50 pour cent sur les téléchargements d'archives et de contenu brut, exactement le type de requête dont dépendent un pipeline de build ou une récupération de dépendance. Issues, pull requests, API, Actions et Copilot ont tous été dégradés, tout comme l'authentification SAML et OIDC, SCIM et Team Sync ; la plupart des services se sont rétablis vers 16h36 UTC, Actions vers 18h03 UTC, et le service de jetons Copilot en dernier, à 21h02 UTC. GitHub a précisé explicitement que ni cet incident ni la panne plus petite d'Actions du 6 août n'ont été causés par un changement de code ou de configuration ; les deux ont été, selon les mots mêmes de l'entreprise, des défaillances de capacité dans leur essence, c'est-à-dire que le système a manqué de marge plutôt que de tomber en panne à cause d'un bug livré.

Le Volume De Commits A Presque Doublé En Quatre Mois

Enfoui dans ce même rapport se trouve le chiffre qui transforme cette histoire de panne en histoire d'infrastructure : GitHub affirme que le volume mensuel de commits est passé de 1,4 à 2,9 milliards depuis avril 2026, pratiquement doublé en environ quatre mois, accompagné de graphiques montrant les pull requests fusionnées approcher 130 millions par mois et les nouveaux dépôts approcher 24 millions par mois. GitHub avait déjà signalé la cause dans son rapport de disponibilité de mai 2026, où l'entreprise reconnaissait que la programmation assistée par l'IA et les flux de travail agentiques ajoutaient de la pression sur son infrastructure, et Microsoft a déclaré publiquement que l'IA écrit désormais jusqu'à 30 pour cent du code dans certains de ses propres dépôts, sous réserve de révision humaine. Une plateforme dimensionnée pour un monde où les commits arrivaient au rythme de la frappe humaine absorbe désormais un schéma de charge dicté par des agents de codage qui écrivent, créent des branches et poussent en continu, et la réponse de GitHub jusqu'ici a consisté à ajouter de la capacité : plus de 3 millions de cœurs CPU et 120 pétaoctets de stockage haute vitesse, Azure portant désormais environ 58 pour cent de la charge de la plateforme, contre 12 pour cent en mai.

GitHub Actions A Enregistré Treize Incidents En Dix-Sept Jours

Tech Times, après avoir analysé l'historique des incidents et les données de statut de GitHub, a rapporté que GitHub Actions à elle seule a enregistré 13 incidents distincts sur une période de 17 jours ce mois d'août, et que sa disponibilité sur 90 jours est passée de 99,39 pour cent avant la panne du 17 août à 99,33 pour cent après, une baisse d'environ 13 heures de temps d'arrêt cumulé sur trois mois à environ 14,5 heures. Ce média a estimé que l'incident du 17 août avait à lui seul consommé presque tout un budget annuel de temps d'arrêt autorisé face à un objectif de trois neuf. Le rapport de GitHub compte différemment et qualifie le 17 août de deuxième incident significatif du mois après la panne d'Actions du 6 août, un décompte juste des grandes pannes à l'échelle de la plateforme, mais qui ne dit rien des perturbations d'Actions plus petites et plus fréquentes qui restent en dessous. Les deux décomptes peuvent être vrais à la fois, et ensemble ils décrivent un problème de fiabilité à deux niveaux : le service Git central tient mieux que le pipeline CI/CD construit par-dessus, et c'est précisément ce pipeline qui porte la majeure partie de la nouvelle charge du développement assisté par l'IA.

Une Plateforme, Chaque Pipeline : Le Risque De Concentration

Pour une entreprise qui fait passer tout son flux d'ingénierie par GitHub, c'est-à-dire le contrôle de version, la CI via Actions, son registre de paquets et Copilot pour la génération de code, rien de tout cela n'est du bruit de fond ; c'est un fournisseur unique placé sur le chemin critique de chaque publication. Une équipe de développement européenne ressent cela comme une équipe américaine pendant la fenêtre même de la panne, mais porte une couche d'exposition supplémentaire : les échéances contractuelles de livraison, les engagements de niveau de service envers des clients de l'UE et les obligations de signalement d'incidents prévues par des cadres comme NIS2 ne s'arrêtent pas parce que la panne est née dans un centre de données américain hors du contrôle de l'équipe. Traiter 'GitHub est en panne' comme du bruit de fond cesse d'avoir un sens dès que les chiffres sous-jacents montrent pourquoi c'est arrivé : une infrastructure construite pour un monde plus lent et cadencé humainement absorbe désormais un schéma de charge qui a presque doublé en quatre mois, sur une plateforme qui, de son propre aveu, a passé le mois d'août à corriger deux fois la même catégorie de défaillance de capacité.

À Quoi Ressemble Vraiment La Redondance

Rien de tout cela ne plaide pour abandonner GitHub, qui reste le choix par défaut pour de bonnes raisons, mais c'est un argument concret pour traiter la dépendance à un fournisseur unique comme un risque planifié plutôt que comme une idée après coup découverte en pleine panne. Cela signifie garder une copie miroir des dépôts critiques sur un second hôte ou un serveur Git auto-hébergé, une configuration alternative de runner CI capable de prendre en charge les builds quand Actions est dégradé et pas seulement quand il est totalement en panne, et un cache local ou auto-hébergé pour les dépendances de paquets, afin qu'une panne du registre n'arrête pas chaque build du pipeline. Aucune de ces mesures n'a besoin de tourner en continu ; elles doivent exister, être testées de temps en temps et être documentées assez bien pour qu'une équipe sous pression lors du prochain incident n'improvise pas une solution pour la première fois pendant que l'horloge d'une échéance client continue de tourner.

À lire ensuite: Votre Second Hébergeur Git S'Est Activé Seul  |  L'Irlande annule son marché Microsoft