Le 17 août, alors que le trafic atteignait un nouveau pic, GitHub a connu une panne qui a duré 7 heures et 47 minutes, voici ce qui s'est passé

D'après le CTO de Github, Vlad Fedorov

Un pic de trafic survenu le 17 août 2026 a mis en évidence une faille critique dans l'infrastructure de GitHub, provoquant une panne de 7 heures et 47 minutes qui a perturbé plusieurs services de la plateforme à l'échelle mondiale. Selon Vlad Fedorov, le directeur technique, la panne a pris naissance dans un centre de données situé au cœur des États-Unis et a été aggravée par une boucle de réessais qui a saturé les systèmes au milieu de la procédure de rétablissement. Fedorov a qualifié cet incident de deuxième défaillance majeure de la plateforme en un mois, après une panne de GitHub Actions survenue le 6 août dernier. Il a précisé qu'aucune de ces deux pannes n'avait été causée par une modification du code, mais par un système qui n'avait pas su s'adapter à l'augmentation du volume de commits, qui a plus que doublé depuis avril.

GitHub est une plateforme propriétaire destinée aux développeurs qui leur permet de créer, stocker, gérer et partager leur code. Elle utilise Git pour assurer un contrôle de version distribué, et GitHub propose lui-même des fonctionnalités de contrôle d'accès, de suivi des bogues, de gestion des demandes de nouvelles fonctionnalités, de gestion des tâches, d'intégration continue et de wikis pour chaque projet. GitHub, dont le siège social est situé à San Francisco, est exploité par GitHub, Inc., une filiale de Microsoft depuis 2018.

Le 17 août 2026, GitHub a subi une nouvelle panne mondiale d'une durée de près de huit heures. L’incident a débuté vers 15 h 40 en France métropolitaine, puis a été déclaré résolu à 23 h 15. L’entreprise a attribué cet incident à un dysfonctionnement de l'autoscaling, ainsi qu'à une vague de tentatives de reconnexion dans VS Code. Ces tentatives répétées ont intensifié la pression sur une infrastructure déjà surchargée, aggravant ainsi les défaillances sur l’ensemble de la plateforme. La panne a touché les API, les pull requests, les webhooks, GitHub Actions et l'authentification. Au plus fort de l'incident, GitHub a signalé un taux d'erreur d'environ 20 % pour le trafic Web et API, et un taux stupéfiant de 50 % pour les téléchargements bruts de dépôts et d'archives. Cet panne a mis en évidence les inconvénients de la centralisation de la chaîne de valeur DevOps.


Dans un communiqué publié le 20 août 2026, Vlad Fedorov, directeur des technologies de GitHub, a détaillé la panne ayant perturbé les services et présenté les mesures engagées pour renforcer la fiabilité de la plateforme. Voici le communiqué de Vlad Fedorov : «

Le 17 août, GitHub a subi une panne qui a duré 7 heures et 47 minutes. Celle-ci a perturbé le fonctionnement de github.com, de l’authentification, de GitHub Actions, des API, des pull requests, des tickets et de Copilot, affectant ainsi les développeurs et les organisations du monde entier. Si vous essayiez de déployer un logiciel ce jour-là, nous vous avons déçus.

Il s’agissait de notre deuxième incident majeur en août, après une défaillance de GitHub Actions le 6 août. En mars et avril, je vous avais fait part des travaux en cours visant à améliorer la fiabilité de GitHub. Nous avons réalisé des progrès, mais ces incidents montrent clairement que nous devons accélérer ces efforts.

Ce qui s'est passé

Notre enquête a révélé que la panne a commencé lorsque le trafic a atteint un nouveau pic et qu'un composant critique de l'infrastructure de notre centre de données situé dans le centre des États-Unis n'a pas réussi à s'adapter à cette augmentation. La pression sur la capacité qui en a résulté s'est propagée à l'ensemble de nos systèmes, provoquant des échecs d'authentification et perturbant plusieurs services GitHub.

La remise en service a nécessité plusieurs actions coordonnées. Les équipes ont redirigé le trafic, isolé les infrastructures concernées et rétabli les services par étapes. La plupart des services GitHub ont été rétablis plus tôt dans la journée, mais certains services Copilot ont pris plus de temps. Des erreurs au sein de ces services ont déclenché une boucle de réessais côté client qui a entraîné une augmentation du trafic pendant la remise en service. Nous avons dû atténuer ce comportement avant de pouvoir rétablir le trafic en toute sécurité. L'analyse complète des causes profondes comprend une chronologie technique détaillée.

Aucune de ces deux pannes n'a été causée par une modification du code ou de la configuration. Ces deux incidents étaient essentiellement dus à des problèmes de capacité. Nous n'avons pas su faire évoluer les composants critiques avant que la demande ne dépasse leur capacité. Depuis avril, le nombre de commits mensuels est passé de 1,4 milliard à 2,9 milliards. Cette croissance explique la pression exercée sur nos systèmes, mais elle ne justifie en rien ces pannes.


Ce que nous avons fait et ce qui nous attend

Dans le cadre des engagements en matière de fiabilité que nous avons pris en début d’année, nous nous sommes concentrés sur trois priorités : augmenter la capacité, améliorer l’efficacité et éliminer les goulots d’étranglement architecturaux. Depuis, nous avons ajouté plus de 3 millions de cœurs de processeur, 120 pétaoctets de stockage haut débit et une capacité réseau considérable. Nous avons installé autant de matériel que la puissance disponible le permettait dans nos centres de données existants, tout en accélérant notre migration vers Azure.

Aujourd’hui, Azure prend en charge environ 58 % de la charge de la plateforme GitHub et la moitié de toutes les opérations Git, contre 12 % de la charge de la plateforme en mai. Cette présence accrue a également soutenu la croissance du nombre d’exécutions de tâches GitHub Actions, comme le montre le graphique ci-dessous.


L'infrastructure et la capacité d'Azure ont également permis d'accélérer nos travaux visant à faire évoluer les plus grands monorepos. Notre prochaine étape consiste à mettre en place une architecture dont la capacité de lecture évolue de manière linéaire en fonction du nombre de lecteurs, ce qui permettra d'effectuer un nombre illimité d'opérations de lecture. Nous la déploierons progressivement, en commençant par les plus grands monorepos.


L'échelle n'est pas notre seul défi. À mesure que le rythme et la complexité des changements s'intensifiaient, nos pratiques opérationnelles existantes ne suivaient plus. Nous avons réorienté nos équipes et nos ressources vers la disponibilité et investi dans des tests plus rigoureux, des déploiements plus sûrs, une meilleure observabilité et des alertes plus efficaces. Nous avons fait des progrès, mais ce travail n'est pas terminé.

Par ailleurs, nous isolons également les systèmes critiques et supprimons les dépendances partagées entre eux. Ce travail vise à réduire le risque de panne et à limiter son impact lorsqu’elle survient.

Nous tirons les leçons de chaque panne et intégrons de nouvelles tâches à notre programme de travail dédié à la disponibilité. Les incidents survenus les 6 et 17 août ont donné lieu à deux changements immédiats. Premièrement, nous appliquons des limites de tentatives de réessai, des budgets de réessai et des délais d'expiration variables cohérents pour toutes les interactions entre services, afin d'éviter les « tempêtes de réessais » et les effets en cascade sur la charge. Deuxièmement, nous réexaminons les alertes de moindre priorité liées au processeur et à la mémoire afin d'identifier les composants susceptibles de tomber en panne lors de pics de trafic soudains.

Notre engagement en faveur d'une haute disponibilité n'est pas seulement une promesse technique. La communauté des développeurs compte sur GitHub pour créer, publier et exploiter ses projets. Cela n'est possible que si vous pouvez compter sur nous, ce qui n'a pas été le cas le 17 août. Il est de notre responsabilité d'y remédier. Nous regagnerons votre confiance grâce à l'évolutivité et à la fiabilité de la plateforme. »


À propos de Vlad Fedorov

Vladimir Fedorov est directeur technique chez GitHub. Il apporte plusieurs décennies d’expérience dans le domaine du leadership technique et de l’innovation. Fervent défenseur de la productivité des développeurs, Vlad Fedorov dirige l’équipe d’ingénierie de GitHub afin de façonner l’avenir des outils de développement et de l’innovation, en adoptant une approche centrée sur les développeurs.

Avant de rejoindre GitHub, Vlad Fedorov a cofondé UserClouds, une start-up spécialisée dans la gouvernance des données et la protection de la vie privée. Il a passé 12 ans chez Facebook, désormais Meta, en tant que vice-président senior, où il a dirigé des équipes d’ingénieurs comptant plus de 2 000 personnes dans les domaines de la protection de la vie privée, de la publicité et de la plateforme. Au début de sa carrière, Vlad Fedorov a travaillé chez Microsoft et a obtenu une licence et un master en informatique à Caltech. Il siège actuellement au conseil d’administration de Codepath.org, une organisation qui se consacre à la refonte de l’enseignement supérieur afin de former la première génération d’ingénieurs, de directeurs techniques et de fondateurs natifs de l’IA. Vlad Fedorov vit dans la région de la Baie de San Francisco et, lorsqu'il ne travaille pas, il aime passer du temps en plein air et sur l'eau avec sa famille.

Source : Communiqué de GitHub

Et vous ?

Quel est votre avis sur le sujet ?
Trouvez-vous cette initiative de GitHub crédible ou pertinente ?

Voir aussi :

Suite aux récentes pannes de GitHub, OpenAI développe son propre référentiel de code rival de GitHub et envisage de le mettre à la disposition des clients d'OpenAI, en concurrence directe avec Microsoft

Les grandes entreprises en urgence après une attaque sur GitHub ayant exposé leurs données sensibles, l'incident révèle les limites de la sécurité dans l'open source actuel

GitHub sous tension : certains utilisateurs mécontents se rebellent contre les fonctionnalités IA Copilot imposées, quand l'aide optionnelle au codage se transforme en prison numérique

GitHub n'est plus indépendant de Microsoft, son PDG Thomas Dohmke démissionne et ne sera pas remplacé, GitHub sera ainsi directement intégré à l'organisation Microsoft