Le 9 février de cette année, tard dans la nuit à l’heure de Pékin, des dizaines de millions de développeurs à travers le monde ont ouvert GitHub pour voir la même page.
Pas une erreur 404, mais quelque chose de plus angoissant qu’un 404 – cette barre d’alerte jaune qui glace le sang de tout ingénieur, accompagnée d’une série de voyants passant du vert au rouge sur la page de statut.
github.com était hors service.
L’API était hors service.
GitHub Actions était hors service.
Les opérations Git étaient hors service – et même Copilot n’y a pas échappé.
Cette nuit-là, des pipelines CI/CD se sont arrêtés à l’étape la plus critique, des déploiements automatisés se sont figés en plein vol, et des personnes attendaient une PR qui ne pouvait pas être fusionnée – derrière laquelle se cachait une fonctionnalité en attente de mise en ligne, destinée à de vrais utilisateurs.
Après coup, GitHub a publié un rapport d’incident. La cause racine, en termes techniques, était « la surcharge d’un cluster de bases de données central responsable de l’authentification et de la gestion des utilisateurs ». Mais derrière ces mots se cache une chaîne de déclenchement alarmante –
Deux jours plus tôt, l’équipe d’ingénierie, pour livrer rapidement un nouveau modèle aux utilisateurs, avait modifié le temps de rafraîchissement d’un « cache des paramètres utilisateur » de 12 heures à 2 heures. Juste un changement d’un chiffre de configuration.
Résultat : ce qui était auparavant étalé sur 12 heures a été compressé en 2 heures, créant une « tempête de réécriture de cache » intense, la file d’attente des tâches asynchrones a été instantanément saturée, les composants d’infrastructure partagés se sont effondrés, la réaction en chaîne s’est propagée au service responsable de la gestion des opérations Git HTTPS via proxy, et finalement, les connexions de toute la plateforme ont été épuisées.
Un chiffre, passé de 12 à 2.
GitHub, a été transpercé par la modification d’un de ses propres paramètres de configuration.
Mais si vous ne voyez que ce changement de configuration, vous passez probablement à côté de la partie la plus importante de cette histoire.
01 Pas un accident, mais dix accidents
L’incident du 9 février n’est pas un événement isolé.
En réalité, au cours des trois premiers mois de 2026, GitHub a connu au moins 8 incidents majeurs. Rien qu’en février, 37 pannes de diverses ampleurs ont été enregistrées. Le CTO de GitHub, Vlad Fedorov, a admis plus tard dans un billet de blog que pendant ces deux mois, GitHub n’avait pas réussi à maintenir les « trois neuf » – 99,9% de disponibilité – promis à ses clients entreprises.
En parcourant les archives des incidents de ces deux mois, on découvre un schéma particulier : chaque incident semble avoir une cause différente.
2 février : Un problème avec le fournisseur de calcul Azure a paralysé GitHub Actions pendant près de 4 heures, affectant également l’agent de codage Copilot, CodeQL, et Dependabot.
9 février : Tempête de réécriture de cache, surcharge de la base de données d’authentification.
5 mars : Panne d’un cluster Redis, 95% des workflows GitHub Actions n’ont pas pu démarrer en moins de 5 minutes, avec un délai moyen de 30 minutes.
18 mars : La latence des webhooks a explosé, atteignant jusqu’à 32 fois le niveau normal.
Chaque fois, cela semble être un « accident », chaque cause directe est différente. Mais l’explication de Fedorov les relie en une seule et même histoire. Il dit que derrière ces incidents se cachent trois causes structurelles communes : « une croissance rapide de la charge, un couplage étroit entre les services conduisant à la propagation de pannes locales, et un manque de capacité du système à protéger le trafic contre les clients anormaux. »
En langage d’ingénieur, les fondations de GitHub commencent à se fissurer sous la pression de cette nouvelle charge.
Et cette « nouvelle charge » a un nom précis.
02 275 millions de commits par semaine
Données clés
Volume total de commits pour l’année 2025 : environ 1 milliard
Volume de commits pour une semaine en 2026 : 275 millions
À ce rythme, estimation pour l’année 2026 : 14 milliards (une multiplication par 14 par rapport à l’année précédente)
Capacité de calcul GitHub Actions : 5 milliards de minutes par semaine en 2023 → 10 milliards en 2025 → 21 milliards de minutes pour une semaine début 2026
Si vous êtes ingénieur d’infrastructure chez GitHub, la comparaison des tableaux de bord de surveillance entre 2025 et 2026 vous laissera probablement bouche bée.
Sur toute l’année 2025, GitHub a traité environ 1 milliard de commits de code. Ce chiffre en lui-même est déjà énorme, résultat de plusieurs années d’accumulation sur la plateforme. Mais en 2026, le nombre de commits pour une seule semaine a atteint 275 millions. Un simple calcul – si ce rythme se maintient toute l’année, le nombre total de commits pour 2026 approchera les 14 milliards, soit 14 fois le total de toute l’année 2025.
Ce n’est pas une courbe de croissance lisse, c’est un mur. L’évolution de la capacité de calcul consommée par GitHub Actions est encore plus parlante : 5 milliards de minutes par semaine en 2023, doublé à 10 milliards en 2025, puis pour une semaine début 2026, le chiffre a directement grimpé à 21 milliards de minutes.
Qu’est-ce qui soumet du code aussi frénétiquement ?
Pas les développeurs humains.
Les données de GitHub montrent que les Agents IA deviennent les « utilisateurs » les plus actifs de cette plateforme. Claude Code, à lui seul, contribue maintenant à 4,5% de tous les commits sur les dépôts publics de GitHub. 2,6 millions de commits par semaine, alors qu’à la fin septembre 2025, ce chiffre n’était que de 100 000 – une multiplication par 25 en trois mois.
Le nombre de PR ouvertes par les Agents IA explose aussi. En septembre 2025, les PR générées par l’IA étaient d’environ 4 millions par mois. En mars 2026, ce nombre est passé à 17 millions – multiplié par plus de quatre en six mois.
Voici une image pour comprendre ce que cela signifie.
Avant, les « utilisateurs » de GitHub étaient principalement des programmeurs humains. Ils travaillaient le jour, dormaient la nuit, se reposaient le week-end, réfléchissaient et hésitaient avant chaque commit, leur vitesse de frappe avait une limite. La charge du système suivait le rythme humain, avec des pics et des creux, elle était prévisible.
Maintenant, de plus en plus d’« utilisateurs » sont des Agents IA. Ils ne dorment pas, ne se reposent pas, n’hésitent pas, une tâche peut lancer plusieurs agents en parallèle, et chaque agent peut facilement soumettre plus de code en une heure qu’un véritable ingénieur en une semaine. Plus important encore, ils ne font pas que soumettre du code, ils créent aussi constamment de nouveaux dépôts – utilisant le dépôt comme un « produit de sortie » de workflow, et non comme un « espace de travail » humain.
Les ingénieurs d’infrastructure de GitHub ne font plus face à un problème de même nature avec plus de trafic, mais à un problème qualitativement différent.
03 L’argent de Copilot ne suffit plus à couvrir les coûts
La fréquence des incidents n’est qu’un aspect du problème. GitHub a un autre souci plus épineux – en faisant les comptes, ils se sont rendu compte qu’ils perdaient de l’argent.
La logique de tarification initiale de Copilot reposait sur une hypothèse raisonnable : l’utilisation par les utilisateurs était principalement de type « complétion assistée », chaque interaction était brève et la consommation de calcul prévisible. La version individuelle à 10 $ par mois, la version commerciale à 19 $ par mois, par siège – ce modèle a bien fonctionné ces dernières années.
Puis, l’IA Agentique est arrivée.
Les workflows agentiques et la complétion traditionnelle sont deux espèces différentes. La complétion de code standard génère des requêtes linéaires, prévisibles, avec des cycles de calcul courts. Alors qu’une session de codage agentique peut durer plusieurs heures, lancer plusieurs threads en parallèle, effectuer des raisonnements multi-étapes, de l’auto-correction, des refontes de code entre dépôts – le nombre de tokens consommés par une seule session peut facilement dépasser le coût d’un abonnement mensuel pour un utilisateur ordinaire.
La situation à laquelle GitHub fait face est la suivante : quelques utilisateurs intensifs d’IA agentique, avec un abonnement mensuel de quelques dollars, consomment des ressources de calcul équivalentes à des centaines de dollars.
Face à cette situation, la réaction de GitHub a été directe – d’abord limiter le flux, puis modifier les prix.
Début de cette année, GitHub a mis en place 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 tokens multipliée par un poids de calcul du modèle. Parallèlement, l’inscription de nouveaux utilisateurs a été suspendue pour certains forfaits Copilot individuels.
Le 1er juin, GitHub a achevé une réforme tarifaire plus fondamentale : Copilot est entièrement passé à une facturation à l’usage, remplaçant les forfaits précédents par des « Crédits IA », 1 Crédit IA équivalant à 1 centime, la consommation étant calculée en temps réel en fonction de l’utilisation des tokens.
L’ère de la tarification par siège, face à l’IA agentique, a touché à sa fin.
Cette transition n’est pas seulement un problème pour GitHub. C’est une crise tarifaire collective que traverse toute l’industrie des outils IA en 2026 – quand l’IA commence à remplacer les humains pour exécuter des workflows complets, et pas seulement à les « assister », toute la logique d’abonnement basée sur « par personne par mois » s’effondre.
04 30 fois, pas 10 fois
Revenons au problème d’infrastructure. Comment GitHub prévoit-il vraiment de faire face à cette « croissance par 14 » ?
Un détail permet de comprendre la gravité de la situation :
Fin décembre 2025, les workflows agentiques ont soudainement commencé à s’accélérer. Les ingénieurs de GitHub ont réalisé que multiplier par 10 ne suffirait pas. En février 2026, c’est-à-dire après cette grave panne, GitHub a annoncé avoir besoin de reconcevoir son architecture pour une échelle 30 fois supérieure à celle d’aujourd’hui.
Pas une simple augmentation de capacité, mais une reconception.
La différence entre ces deux termes est grande. Augmenter la capacité, c’est ajouter plus de machines, mettre plus de mémoire dans les bases de données existantes – la direction reste la même, seul l’échelle change. Reconcevoir signifie que les hypothèses de l’architecture actuelle échoueront systématiquement à une échelle 30 fois supérieure, qu’il faut repenser depuis la base la manière de découper les services, les flux de données, l’isolation des pannes.
Les orientations spécifiques dévoilées par GitHub incluent le découplage des services critiques pour éviter les défaillances en cascade, l’introduction de mécanismes de contre-pression et de capacités de déclassement de trafic, le déploiement d’hôtes dédiés pour les services critiques, l’élimination des points de défaillance uniques, ainsi qu’une gestion des changements plus rigoureuse – pour éviter qu’une opération comme « modifier le TTL du cache de 12h à 2h » ne soit déployée en production sans tests de charge suffisants.
Il est à noter que GitHub n’est pas seul.
Stripe a déjà rencontré des problèmes de création de comptes en masse par des Agents IA, AWS est en train de construire des systèmes d’identité, de journalisation et des mécanismes de contrôle de production dédiés aux Agents. Ces actions ne sont pas de la prévoyance, mais des réponses à des signaux déjà visibles sur les tableaux de bord de surveillance et qu’il faut absolument résoudre.
GitHub n’est que le premier à avoir été transpercé – parce qu’il est au cœur même de la chaîne d’outils de l’IA.
05 Le dépôt de code, en train de devenir le pot d’échappement de l’IA
Arrêtons-nous un instant pour réfléchir à la nature même de cette affaire.
Qu’est-ce que GitHub ? La réponse la plus intuitive est : l’endroit où les programmeurs stockent leur code. Mais plus profondément, c’est l’infrastructure de la collaboration logicielle humaine – l’historique des commits est la trace de la collaboration, la PR est le conteneur de discussion, les Issues sont la conservation de l’intention, Action est le pipeline d’exécution. L’ensemble du système est conçu pour le rythme de travail, le mode de pensée et les schémas de collaboration humains.
Les Agents IA ont changé tout cela.
Quand un Agent IA peut soumettre des centaines de commits de code par jour, chaque « commit » n’étant plus le fruit d’une réflexion et d’un arbitrage humain, mais simplement une étape dans la progression d’une boucle de tâches – le dépôt de code est-il encore un « conteneur de collaboration » ?
Quand les outils IA génèrent automatiquement des dépôts, ouvrent automatiquement des PR, exécutent automatiquement le CI, fusionnent automatiquement – le développeur est-il encore le sujet de ce processus, ou est-il en train de dégénérer en « examinateur » voire en « simple observateur » ?
Le CTO de GitHub, en décrivant cette crise, a utilisé les mots « croissance rapide de la charge ». Mais ces mots sous-estiment probablement la nature du problème – il ne s’agit pas seulement d’une croissance quantitative, mais d’un changement qualitatif du mode d’utilisation. Dans l’ancien modèle, GitHub était un « outil pour développeurs » ; dans le nouveau modèle, GitHub est en train de devenir le « pot d’échappement de l’IA », un canal de sortie pour les workflows automatisés.
Ce que cela signifie pour GitHub, la réponse n’existe pas encore. Multiplier la capacité par 30 peut résoudre le problème de trafic, mais ne résoudra pas la redéfinition du modèle économique, ni la question identitaire de « qui est mon véritable utilisateur ».
Un phénomène récent est assez révélateur : après les pannes, GitHub a publié un grand nombre d’articles de blog techniques, décrivant de manière très détaillée la cause racine de chaque incident, avec un niveau de transparence presque surprenant. Certains y voient une volonté active de GitHub d’établir la confiance, d’autres pensent que c’est un échange de transparence contre la patience de la communauté des développeurs – car la période de reconstruction à venir sera encore semée d’instabilité.
Une plateforme, après avoir été transpercée par son propre succès, doit se démonter et se reconstruire – et ce processus en lui-même est aussi un test pour savoir si elle pourra tenir le coup.
Le soir du 9 février, ce développeur qui attendait la fusion de sa PR a probablement fini par voir le feu vert. Mais il n’a peut-être pas réalisé que cette panne qui l’a fait attendre n’était pas un simple accident pour GitHub, mais une retentissante annonce de l’entrée de toute l’industrie du développement logiciel dans une nouvelle ère.
Cet article provient du compte WeChat public « Geek Park » (ID : geekpark), auteur : Yu Hangyuan
