Tard dans la nuit du 6 août 2026, GitHub, le plus grand hébergeur de code au monde, a subi une panne majeure. Son service d’automatisation, GitHub Actions, a été frappé par des défaillances massives : des tâches sont restées bloquées en file d’attente pendant des heures sans démarrer, des processus en cours ont échoué en masse, le service d’hébergement web Pages a subi des dégradations et les fonctionnalités de revue de code de l’assistant IA Copilot ont fonctionné de manière intermittente. Un fil de discussion sur la communauté de développeurs Hacker News a accumulé 299 points et 253 commentaires en seulement huit heures. Les développeurs ont rapidement recoupé les indices : ce qui a poussé la plateforme au point de rupture est très probablement l’explosion du code généré par l’IA. Les données partagées par Kyle Daigle, directeur des opérations chez GitHub, révèlent que le temps d’exécution hebdomadaire d’Actions est passé de 500 millions de minutes en 2023 à 1 milliard en 2025, pour atteindre 2,1 milliards de minutes cette semaine — un chiffre qui a quadruplé en seulement deux ans.
Pour les lecteurs non développeurs, un peu de contexte : GitHub est la plateforme centrale de collaboration pour le développement logiciel, hébergeant le code de millions de projets dans le monde. Actions est son moteur d’automatisation intégré — un majordome virtuel pour le code. Les développeurs définissent des règles, et à chaque modification du code, Actions exécute automatiquement les tests, l’assemblage et le déploiement. Ce qui nécessitait une demi-heure de travail manuel est accompli par la machine en quelques minutes.
Image : Couverture de la récente panne de GitHub. Source : The Register
Le rapport d’incident officiel dresse un constat très clair : vers 23h00 (heure UTC+8) le 6 août, les files d’attente ont commencé à s’accumuler, les délais d’expiration ont été dépassés et le taux de réussite a chuté temporairement entre 30 % et 40 %. Alors que les ingénieurs restreignaient le trafic et déployaient des correctifs, seulement 15 % des notifications de modification de code ont été traitées, laissant d’immenses volumes de changements sans déclenchement de tâches ultérieures. Bien que le taux de réussite soit revenu à 99 % au bout de huit heures, Copilot et Pages ont continué de présenter des instabilités, et les services de migration de données d’entreprise ont été purement et simplement suspendus. Il ne s’agit pas d’un cas isolé : une panne similaire d’Actions s’est produite le 29 juillet, et la page de statut officielle a recensé 26 incidents en juillet, auxquels s’ajoutent 6 autres au cours des six premiers jours d’août. Malgré les excuses présentées par GitHub en avril et les promesses de refonte structurelle faites par les dirigeants en juin, l’infrastructure a de nouveau cédé un mois plus tard.
Image : Historique de la panne sur la page de statut officielle de GitHub, environ 8 heures entre la dégradation et le rétablissement. Source : githubstatus.com
Un détail du rapport d’incident mérite une attention particulière : « Les machines d’exécution se sont vu attribuer des tâches obsolètes et se sont retrouvées bloquées dans des boucles de réitération. » En clair : les serveurs d’exécution recevaient des ordres de travail annulés ; après les avoir exécutés et constaté leur inutilité, ils réclamaient de nouvelles tâches, pour se voir attribuer à nouveau des ordres annulés. Plus le système s’engorgeait, plus le nombre de tâches caduques augmentait, alimentant une boucle infernale. C’est un mode de défaillance classique des systèmes à très haute charge.
D’où vient ce volume : l’IA multiplie les commandes en cuisine
Les chiffres officiels sont saisissants. Sur l’ensemble de l’année 2025, GitHub a enregistré 1 milliard de commits. Aujourd’hui, la plateforme en reçoit 275 millions par semaine, ce qui représente un rythme annuel de 14 milliards de commits. Le temps d’exécution d’Actions a quadruplé en deux ans. Pour traduire cela en grandeurs perceptibles : 2,1 milliards de minutes par semaine signifient qu’à chaque instant, plus de 200 000 serveurs travaillent simultanément sur GitHub pour le compte de développeurs du monde entier. 275 millions de commits par semaine équivalent à une moyenne de 450 commits par seconde. La plateforme doit traiter 450 demandes chaque seconde tout en allouant dynamiquement des machines pour chaque tâche.
Image : Le temps d’exécution hebdomadaire d’Actions a quadruplé en deux ans ; les commits hebdomadaires ont atteint environ 14 fois la moyenne de 2025. Source : Données officielles de GitHub (COO Kyle Daigle), graphique par l’auteur
D’où provient cette explosion de volume ? De la programmation assistée par IA. Les assistants IA actuels sont capables de lire du code, de le modifier, de soumettre des commits et d’exécuter des tests de manière autonome, enchaînant des dizaines d’itérations par session, chaque boucle déclenchant une chaîne de tâches automatisées. Là où un ingénieur humain soumettait du code une ou deux fois par jour, l’IA soumet des dizaines de commits quotidiens. Les statistiques de la communauté montrent que les demandes de fusion (pull requests) générées par IA sont passées de 4 millions par mois en septembre dernier à 17 millions en mars. À lui seul, l’outil Claude Code génère 2,6 millions de commits par semaine, soit une multiplication par 25 en six mois. Si le code humain équivaut à passer une commande au restaurant, le code IA revient à décupler le volume de commandes de toute la cuisine du jour au lendemain.
Lorsque les commandes explosent sans que la cuisine ne soit agrandie, la réaction en chaîne est inévitable. Comme l’a expliqué sur Hacker News l’ingénieur système cortesoft, les systèmes à haute charge sont conçus avec des marges de sécurité, mais dès que l’utilisation dépasse 90 à 95 %, la moindre fluctuation provoque une explosion : les tâches s’accumulent, les délais spirent, les clients réessaient et ces tentatives génèrent encore plus d’attente. C’est l’équivalent d’une autoroute : fluide à 80 % de capacité, mais à 95 %, un simple coup de frein paralyse des kilomètres de voies. Il a souligné sans détour qu’ajouter des machines en plein engorgement s’avère inefficace, car les goulets d’étranglement se déplacent vers des composants inattendus.
Des correctifs officiels jugés insuffisants par les utilisateurs
Les réactions des deux côtés révèlent une vive tension. GitHub a reconnu des contraintes de capacité et a déclaré que ses ingénieurs avaient identifié la cause racine et déployaient des correctifs. Cependant, les clients payants n’en démordent pas : un utilisateur entreprise exploitant des serveurs hébergés par ses soins s’est plaint que même ses propres machines payantes soient restées paralysées toute une journée. L’utilisateur zehaeva, inscrit sur GitHub depuis 2009, s’est montré encore plus virulent en soulignant que la disponibilité de GitHub était passée en un an de « quatre neufs » (99,99 %) à « un neuf » (90 %). Quatre neufs autorisent moins d’une heure d’interruption par an, tandis qu’un neuf implique plus de 30 jours de panne annuelle — une dégradation qu’il relie directement à l’explosion de l’utilisation de l’IA.
Les discussions ont également relancé un ancien débat : la migration des infrastructures. Depuis son rachat par Microsoft, GitHub migre progressivement son infrastructure de ses propres centres de données vers le cloud Azure. L’utilisateur toomuchtodo a rappelé que l’époque des serveurs dédiés physiques offrait une meilleure stabilité, estimant que la migration aurait dû conserver la charge de base sur site pour ne basculer que les surplus vers le cloud. D’autres soupçonnent un calendrier de migration trop agressif. À l’inverse, un autre intervenant a fait remarquer que bien que Microsoft ait racheté GitHub il y a huit ans, les plaintes ne se sont multipliées qu’au cours des douze derniers mois, ce qui coïncide exactement avec l’explosion de la programmation IA. Bien que les avis divergent, deux faits demeurent incontestables : la fréquence des pannes de GitHub a nettement augmenté et la croissance du trafic est bel et bien réelle.
La course entre la vitesse de l’IA et le monde physique
En quoi cela concerne-t-il le grand public ? La quasi-totalité des mises à jour, des corrections de bugs et des déploiements d’applications sur votre téléphone passe par les chaînes d’automatisation de GitHub. Quand la plateforme stagne une journée, les rythmes de publication de milliers d’équipes logicielles s’en trouvent perturbés à l’échelle mondiale. Sur un plan plus fondamental, cela illustre une course entre la vitesse de production numérique et les contraintes du monde physique. L’IA permet d’accroître la production de logiciels de manière exponentielle, mais l’extension des serveurs, de la bande passante et des centres de données reste un processus physique soumis à des limites réelles. GitHub avait fixé en octobre dernier un objectif de décuplement de sa capacité, révisé à 30 fois en février, mais le trafic continue de dépasser ses capacités. Des rapports indiquent même que Microsoft a dû louer temporairement de la capacité chez son concurrent AWS pour secourir GitHub — une image qui en dit long sur la pression subie.
« Tout automatiser » est la promesse la plus séduisante de l’ère de l’IA. La réalité est que les tâches générées automatiquement doivent in fine faire la queue devant des machines physiques. Cette panne de GitHub constitue un signal clair : lorsque tout le monde produit plus vite, la ressource la plus rare devient l’infrastructure qui porte l’ensemble. La vitesse de production de l’IA est un problème logiciel ; l’expansion des infrastructures est un problème physique. Quand la physique ne parvient plus à suivre le logiciel, c’est le sol sous nos pieds qui finit par s’effondrer.
Liens de référence :
- GitHub Status : Rapport d’incident sur Actions et Pages
- Discussion HN (item?id=49198302)
- The Register : Latest GitHub outage squeezes Actions, Pages to death
- Waxell : GitHub’s AI Agent Crisis: What 9 Outages Cost
- danilchenko.dev : GitHub’s AI Agent Problem: 17 Million PRs, Five Outages, and a Kill Switch
