GitHub attribue (encore) sa panne du 17 août à un problème de capacité Too fast too furious Illustration : Flock Alexandre Laurent Le 21 août à 10h43 GitHub a été victime lundi d’une panne globale qui a entraîné une interruption de service de plus de 7 heures. Dans son post-mortem, la plateforme invoque une nouvelle fois un problème de capacité, dû à l’explosion du volume de requêtes découlant des pratiques liées à l’IA générative. Et promet, encore, qu’on ne l’y reprendra plus.

Une erreur ? La panne du 17 août a finalement duré 7 heures et 47 minutes, d’après le décompte officiel. « Si vous avez essayé de livrer du code ce jour-là, on vous a laissé tomber », admet Vlad Fedorov, directeur technique de GitHub, dans un billet de blog en forme de post-mortem.

L’incident, largement relayé sur les réseaux sociaux, a en effet touché la quasi-totalité des services de la plateforme, qu’il s’agisse de l’authentification, du site Web proprement dit, de l’accès aux dépôts, des pull requests ou des fonctions d’IA générative Copilot. Le mea culpa se justifie d’autant plus que cet incident n’est pas isolé. Comme le rappelle Fedorov, GitHub a déjà été victime d’une panne de grande ampleur le 6 août dernier.

Les premiers mois de l’année ont eux aussi été marqués par une série de dysfonctionnements ponctuels ou de ralentissements. Elle avait conduit l’entreprise, propriété de Microsoft, à présenter ses excuses aux développeurs en avril dernier. Un pic de trafic le 17 août Que s’est-il précisément passé lundi ?

GitHub indique que la panne n’est due ni à une faille de sécurité, ni à une erreur manuelle. D’après Fedorov, elle découle purement et simplement d’un pic de trafic que les infrastructures en place n’ont pas été capables d’absorber correctement. « 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 », décrit l’intéressé.

C’est au niveau d’un composant critique, hébergé dans le datacenter Central US, que la congestion est intervenue, comme le révèle le rapport d’incident associé : « À l’origine, ce problème était dû à un pod sidecar Istio ayant atteint ses limites de concurrence et ne parvenant pas à une mise à l’échelle automatique correcte en raison d’une politique mal configurée qui surveillait le service hôte mais pas les limites du sidecar. Cette défaillance s’est propagée en cascade, et finalement quatre nœuds HAProxy ont atteint leurs limites de flux, dégradant le chemin d’authentification de la passerelle et provoquant une latence et des échecs d’authentification généralisés. » En réponse, les équipes techniques ont mis en place des routes parallèles, isolé l’infrastructure concernée, suspendu HAProxy sur les nœuds concernés et lancé la restauration des différents services tombés, mais le plan de continuité ne s’est pas déroulé tout à fait comme prévu. « Des erreurs dans ces services ont déclenché une boucle de nouvelles tentatives côté client, ce qui a augmenté le trafic pendant la récupération.

Nous avons dû atténuer ce comportement avant de pouvoir rétablir le trafic en toute sécurité », explique le CTO. Le service Copilot est quant à lui resté interrompu plusieurs heures supplémentaires, en raison d’un autre problème inédit : « Une partie du trafic défaillant a été redirigée du centre des États-Unis vers le nord de la Virginie, où elle a été acheminée avec succès jusqu’à ce que la panne réseau dans le centre des États-Unis soit identifiée et résolue. Des réponses tardives à un point de terminaison interne ont déclenché un bug latent de nouvelle tentative dans VS Code, amplifiant le trafic d’environ 10 fois et provoquant un retard de rétablissement pour le service de tokens Copilot. » Le volume de commits a doublé depuis avril Comment GitHub a-t-il pu subir un pareil incident, alors que le service assurait en avril prendre toutes les mesures nécessaires pour dimensionner correctement son infrastructure ?

Les efforts mis en œuvre semblent ne pas avoir suffi à absorber l’augmentation continue du nombre de requêtes, dont le volume aurait plus que doublé entre avril et août, passant de 1,4 milliard à 2,9 milliards de commits par mois. GitHub enregistrerait 130 millions de pull requests et 2,9 milliards de commits sur le seul mois d’août – crédit GitHub GitHub affirme avoir été limité par la capacité électrique de ses propres infrastructures. « Depuis, nous avons ajouté plus de 3 millions de cœurs CPU, 120 pétaoctets de stockage haute vitesse 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 », écrit Vlad Fedorov. A priori conscient de ses propres carences, GitHub avait annoncé en octobre 2025 son intention de migrer progressivement ses services vers Azure, l’infrastructure cloud globale de Microsoft. Le mouvement semble s’être considérablement accéléré depuis avril : « Aujourd’hui, Azure prend en charge environ 58 % de la charge de la plateforme GitHub et la moitié des opérations Git, contre 12 % en mai », affirme le CTO.

Problème : en matière de ressources disponibles sur Azure, GitHub entre en concurrence avec le reste des services Microsoft, et surtout avec l’offre commerciale cloud de l’éditeur. À tel point que GitHub envisagerait désormais une stratégie multi-cloud, qui conduirait à aller louer de l’infrastructure chez le grand rival, Amazon Web Services (AWS). En attendant, GitHub temporise, et affirme avoir mis en place plusieurs optimisations pour réduire les risques de défaillance.

Entre autres actions de suivi, la plateforme s’engage ainsi à corriger ses politiques de mise à l’échelle automatique, à renforcer les limites de nouvelle tentative (pour éviter l’effet boule de neige qui sature l’infra en cas de défaillance), à corriger les problèmes de VS Code et à surveiller plus efficacement tous les mécanismes d’équilibre de charge et de bascule. Ses difficultés favoriseront peut-être l’essor d’Origin, la nouvelle forge logicielle (calquée sur GitHub) tout juste lancée par Cursor après son rachat par SpaceX. Cet article est en accès libre, mais il est le produit d'une rédaction qui ne travaille que pour ses lecteurs, sur un média sans pub et sans tracker.

Soutenez le journalisme tech de qualité en vous abonnant. Accédez en illimité aux articles d'un média expert Profitez d'au moins 1 To de stockage pour vos sauvegardes Intégrez la communauté et prenez part aux débats Partagez des articles premium à vos contacts Abonnez-vous Bhasher Premium Il y a 34 minutes Message 1 Signaler Bloquer cet utilisateur L'alternative à Microsoft est donc SpaceX? alex.d. Premium Il y a 25 minutes Message 2 Signaler Bloquer cet utilisateur Tout ça est causé par l'IA.

L'arroseur arrosé, en quelque sorte. Sala2 Premium Il y a 25 minutes Message 3 Signaler Bloquer cet utilisateur Miam miam toujours plus de consommation et de serveurs pour traiter et stocker des bennes de slop lui même produit par toujours plus de matériel SebGF Premium Il y a 14 minutes Message 4 Signaler Bloquer cet utilisateur À tel point que GitHub envisagerait désormais une stratégie multi-cloud, qui conduirait à aller louer de l’infrastructure chez le grand rival, Amazon Web Services (AWS)..... Ou à retourner d'où ils viennent Une partie des services GitHub étaient sur AWS avant le rachat par Microsoft, et même après.

Par exemple les LFS pointaient vers des S3. Nozalys Premium À l'instant Message 5 Signaler Bloquer cet utilisateur 2,9 milliards de commits par mois ça fait presque 1100 commits par seconde.C'est démentiel quand on prend le temps d'y songer. Signaler un commentaire Voulez-vous vraiment signaler ce commentaire ?

Non Oui