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.

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 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.