Arrêt de GitHub causé par une augmentation du trafic pilotée par l’IA et une erreur de configuration

Le 9 février de cette année, à minuit heure de Pékin, des dizaines de millions de développeurs à travers le monde ont ouvert GitHub et vu la même page.

Pas un 404, mais quelque chose de plus angoissant — cette barre d'avertissement jaune qui glace le dos de tous les ingénieurs, accompagnée d'une rangée de voyants sur la page d'état passant du vert au rouge.

github.com est hors ligne.

L'API est hors ligne.

GitHub Actions est en panne.

Les opérations Git ont échoué — même Copilot n'a pas été épargné.

Cette nuit-là, la chaîne CI/CD de certains s'est arrêtée au point critique, les déploiements automatisés de d'autres sont restés en suspens, et d'autres encore attendaient un PR qui ne pouvait toujours pas être fusionné — derrière tout cela se cachait une fonctionnalité en attente de mise en ligne, attendue par des utilisateurs réels.

GitHub a publié un rapport d'incident après coup. La cause racine, en termes techniques, est « un cluster de base de données central responsable de l'authentification et de la gestion des utilisateurs surchargé ». Mais ces quelques mots cachent une chaîne de déclenchement choquante —

Il y a deux jours, l'équipe technique a modifié le temps de rafraîchissement du cache des paramètres utilisateurs de 12 heures à 2 heures afin de déployer rapidement un nouveau modèle aux utilisateurs. Il s'agissait uniquement de ce changement de valeur de configuration.

En conséquence, la réécriture du cache, initialement répartie sur 12 heures, a été compressée en seulement 2 heures, créant une « tempête de réécriture du cache » intensive qui a submergé instantanément la file d'attente des tâches asynchrones, provoquant la panne des composants d'infrastructure partagés. Cette réaction en chaîne a affecté le service chargé des opérations HTTPS Git par proxy, entraînant finalement l'épuisement de toutes les connexions de la plateforme.

Un chiffre, passé de 12 à 2.

GitHub a été compromis par une configuration que j'ai modifiée moi-même.

Mais si tu ne vois que ce seul changement de configuration, tu as probablement manqué la partie la plus importante de cette histoire.

L'accident du 9 février n'est pas un événement isolé.

En réalité, les trois premiers mois de 2026 ont vu GitHub connaître au moins huit incidents majeurs. Un seul mois de février a enregistré 37 pannes, grandes et petites. Plus tard, le CTO de GitHub, Vlad Fedorov, a reconnu dans un billet de blog que, pendant ces deux mois, GitHub n'avait pas pu maintenir la disponibilité « trois neuf » de 99,9 % promise à ses clients entreprises.

En consultant les dossiers d'incidents des deux derniers mois, vous remarquerez un motif étrange : chaque incident semble avoir une cause différente.

2 février : Problème chez le fournisseur de calcul Azure, GitHub Actions hors ligne pendant près de 4 heures, Copilot, CodeQL et Dependabot affectés.

9 février : tempête de réécriture du cache, surcharge de la base de données d'authentification.

5 mars : Panne du cluster Redis ; 95 % des workflows GitHub Actions n'ont pas pu démarrer dans les 5 minutes, avec un délai moyen de 30 minutes.

18 mars : le retard des Webhooks a augmenté jusqu'à 32 fois le niveau normal.

Chaque incident semble être une « surprise », et chaque cause directe est différente. Mais l'explication de Fedorov les relie tous dans une même histoire. Il affirme que ces accidents ont trois causes structurelles communes : « une croissance rapide de la charge, une forte couplage entre les services entraînant la propagation des pannes locales, et l'absence de protection du système contre les flux de clients anormaux. »

En termes d'ingénieur, les fondations de GitHub commencent à se fissurer sous la pression de nouvelles charges.

Et ce « nouvel équilibrage » a un nom spécifique.

Données clés

Volume total des commits pour l'année 2025 : environ 1 milliard

Nombre de commits hebdomadaires en 2026 : 275 millions

À ce rythme, la prévision pour l'ensemble de l'année 2026 : 14 milliards (une augmentation de 14 fois sur un an)

Quantité de calcul GitHub Actions : 5 milliards de minutes par semaine en 2023 → 10 milliards en 2025 → 21 milliards de minutes lors d'une semaine au début de 2026

Si vous étiez ingénieur infrastructure chez GitHub, la comparaison des tableaux de bord de surveillance entre 2025 et 2026 vous laisserait sans voix.

Au cours de l'année 2025, GitHub a traité environ 1 milliard de commits. Ce chiffre, déjà considérable, est le résultat d'une accumulation sur plusieurs années sur la plateforme GitHub. Mais en 2026, le nombre de commits hebdomadaires a atteint 275 millions. En extrapolant — si ce rythme se maintient sur toute l'année — le volume total de commits en 2026 approcherait 14 milliards, soit exactement 14 fois celui de l'année 2025.

Ce n'est pas une courbe de croissance fluide, mais une pente abrupte. Les données d'utilisation des Actions de GitHub illustrent mieux ce phénomène : 500 millions de minutes consommées par semaine en 2023, doublées à 1 milliard en 2025, puis soudainement passées à 2,1 milliards de minutes lors d'une semaine au début de 2026.

Qu'est-ce qui soumet frénétiquement du code ?

Pas un développeur humain.

Les données de GitHub montrent que les AI Agents deviennent le « utilisateur » le plus actif sur cette plateforme. Un seul outil, Claude Code, contribue désormais à 4,5 % de l'ensemble des commits des dépôts publics de GitHub. 2,6 millions de commits par semaine, contre seulement 100 000 à la fin septembre 2025 — une augmentation de 25 fois en trois mois.

Le nombre de PR ouverts par les agents IA explose également. En septembre 2025, les PR générés par l’IA s’élevaient à environ 4 millions par mois ; en mars 2026, ce chiffre a bondi à 17 millions — plus de quatre fois plus en six mois.

Il y a une image qui peut vous aider à comprendre ce que cela signifie.

Auparavant, les « utilisateurs » de GitHub étaient principalement des programmeurs humains. Ils travaillaient pendant la journée, dormaient la nuit et se reposaient le week-end ; chaque commit était précédé d'une réflexion, d'hésitations, et leur vitesse de frappe avait une limite. La charge du système suivait le rythme humain, présentant des pics et des creux prévisibles.

De plus en plus d'« utilisateurs » sont aujourd'hui des agents IA. Ils ne dorment pas, ne se reposent pas, ne hésitent pas ; on peut lancer plusieurs agents parallèles pour une même tâche, chacun soumettant par heure un volume dépassant facilement le travail d'un ingénieur humain sur une semaine. Plus important encore, ils ne se contentent pas de soumettre du code, mais créent constamment de nouveaux dépôts, traitant ces derniers comme des « produits de sortie » des flux de travail, et non comme des « espaces de travail » humains.

Les ingénieurs infrastructure de GitHub font face à un problème de nature complètement différente, et non simplement à une version à plus fort trafic du même problème.

Les pannes fréquentes ne sont qu’un côté du problème ; GitHub présente un autre souci plus préoccupant : en faisant le bilan, on se rend compte qu’on a perdu de l’argent.

La logique de tarification initiale de Copilot reposait sur une hypothèse raisonnable : les utilisateurs l'utilisaient principalement pour des complétions d'assistance, chaque interaction étant brève et le calcul prévisible. Le modèle personnel à 10 $ par mois et le modèle professionnel à 19 $ par mois, facturé par siège, a fonctionné efficacement ces dernières années.

Ensuite, l'IA agente est arrivée.

Les flux agentic et la complétion traditionnelle sont deux espèces différentes. La complétion de code standard repose sur des requêtes linéaires et prévisibles, avec des cycles de calcul courts. En revanche, une session de codage agentic peut durer plusieurs heures, lancer plusieurs threads parallèles, effectuer des raisonnements en plusieurs étapes, s'auto-corriger et restructurer à travers des dépôts multiples — une seule session consommant facilement plus de tokens que les abonnements mensuels d'un utilisateur moyen.

GitHub fait face à une situation où un petit nombre d'utilisateurs intensifs d'Agentic consomment des ressources de calcul équivalentes à plusieurs centaines de dollars en échange d'un abonnement mensuel de quelques dollars.

Face à cette situation, la réaction de GitHub est directe — d'abord limiter le flux, puis ajuster le prix.

Au début de cette année, GitHub a mis en œuvre deux mécanismes de limitation parallèles pour Copilot : une limite de durée de session et une limite d'utilisation hebdomadaire, toutes deux calculées en fonction de la consommation de jetons multipliée par un poids de calcul du modèle. Parallèlement, l'inscription de nouveaux utilisateurs a été suspendue pour certains abonnements personnels Copilot.

Le 1er juin, GitHub a mis en œuvre une réforme tarifaire plus fondamentale : Copilot a entièrement basculé vers un modèle de facturation à l'utilisation, remplaçant les abonnements par des « AI Credits », où 1 AI Credit équivaut à 1 cent d'USD, avec une consommation calculée en temps réel en fonction des tokens utilisés.

L'ère des frais basés sur le siège atteint sa fin face à l'IA agente.

Cette transition ne concerne pas seulement GitHub. C’est une crise de tarification collective que l’ensemble de l’industrie des outils IA traverse en 2026 — lorsque l’IA commence à remplacer les humains dans l’exécution de flux de travail complets, et non plus simplement à « aider » les humains, tous les modèles d’abonnement basés sur « par personne et par mois » deviennent obsolètes.

Revenons à la question de l’infrastructure. Comment GitHub compte-t-il répondre à cette « augmentation de 14 fois » ?

Il y a un détail qui illustre la gravité de la situation :

À la fin de décembre 2025, les flux Agentic ont soudainement commencé à s'accélérer. Les ingénieurs de GitHub ont réalisé que multiplier par 10 n'était pas suffisant. En février 2026, après la panne majeure, GitHub a annoncé qu'il fallait redessiner l'architecture pour une échelle 30 fois supérieure à celle d'aujourd'hui.

Ce n'est pas une mise à l'échelle, c'est une refonte.

La différence entre ces deux termes est considérable. L'extension consiste à augmenter le nombre de machines existantes ou à ajouter de la mémoire aux bases de données existantes — l'orientation reste la même, seule la taille augmente. Une refonte signifie que les hypothèses sous-jacentes de l'architecture actuelle échoueront systématiquement à une échelle 30 fois plus grande, et qu'il faut repenser en profondeur la séparation des services, les flux de données et l'isolation des pannes.

Les mesures spécifiques divulguées par GitHub incluent le découplage des services critiques pour prévenir les défaillances en cascade, l'introduction de mécanismes de rétroaction et de capacité de dégradation du trafic, le déploiement de serveurs dédiés pour les services à fort trafic, l'élimination des points uniques de défaillance, ainsi qu'une gestion des changements plus rigoureuse — évitant de déployer directement des modifications telles que « changer la TTL du cache de 12 heures à 2 heures » sans tests de charge adéquats.

Il est à noter que GitHub n'est pas seul.

Stripe a déjà rencontré des problèmes de création massive de comptes par des agents IA ; AWS est en train de développer un système d'identité dédié aux agents, un système de journalisation et des mécanismes de contrôle en production. Ces mesures ne sont pas préventives, mais une réponse à des signaux déjà apparus sur les tableaux de bord de surveillance.

GitHub n'est que le premier à avoir été compromis — car il se trouve au cœur même de la chaîne d'outils AI.

Arrêtez-vous un instant pour réfléchir à la nature de l'ensemble de cette affaire.

Qu'est-ce que GitHub ? La réponse la plus intuitive est que c'est l'endroit où les programmeurs stockent leur code. Mais au-delà, c'est l'infrastructure de la collaboration logicielle humaine — les commits sont la trace de la collaboration, les PR sont des conteneurs de discussion, les Issues conservent les intentions, et les Actions sont des canaux d'exécution. Tout ce système est conçu pour s'adapter au rythme de travail, à la pensée et aux modes de collaboration humains.

L'agent IA a tout changé.

Lorsqu’un agent IA peut soumettre des centaines de codes par jour, et que derrière chaque « soumission » il n’y a aucune réflexion ni évaluation humaine, seulement une étape de progression dans une boucle de tâche — le dépôt de code est-il encore un « conteneur de collaboration » ?

Lorsque les outils IA génèrent automatiquement des dépôts, ouvrent automatiquement des PR, exécutent automatiquement les CI et fusionnent automatiquement — les développeurs restent-ils les acteurs principaux de ce processus, ou sont-ils devenus de simples « réviseurs » voire des « spectateurs » ?

Le CTO de GitHub a utilisé l'expression « croissance rapide de la charge » pour décrire cette crise. Mais cette expression sous-estime probablement la nature même du problème — ce n'est pas seulement une augmentation quantitative, mais une transformation qualitative de l'utilisation. Dans l'ancien modèle, GitHub était « un outil pour les développeurs » ; dans le nouveau modèle, GitHub est en train de devenir « le tuyau d'échappement de l'IA », un canal de sortie pour des flux de travail automatisés.

Cela signifie-t-il quelque chose pour GitHub ? Il n'y a pas encore de réponse. Une mise à l'échelle de 30 fois peut résoudre les problèmes de trafic, mais pas la redéfinition du modèle économique, ni la question de l'identité : « Qui sont mes véritables utilisateurs ? »

Récemment, un phénomène assez significatif s'est produit : après une panne, GitHub a publié de nombreux articles de blog techniques détaillant exhaustivement les causes profondes de chaque incident, atteignant un niveau de transparence presque surprenant. Certains estiment que GitHub cherche activement à établir la confiance, tandis que d'autres pensent qu'il échange sa transparence contre la patience de la communauté des développeurs — car une période de refonte à venir comportera encore davantage d'instabilités.

Une plateforme, après avoir été percée par son propre succès, doit se démonter et se reconstruire — et ce processus même constitue un test pour savoir si elle peut tenir le coup.

Ce soir du 9 février, l'ingénieur qui attendait la fusion de la PR a probablement fini par recevoir le feu vert. Mais il n'a peut-être pas réalisé que la panne qui l'avait fait attendre n'était pas une simple accident de GitHub, mais le signal d'un nouveau chapitre pour l'industrie du développement logiciel.

Cet article provient du compte WeChat « GeekPark » (ID : geekpark), auteur : Yu Hang Yuan