Le 17 août, GitHub est resté à genoux pendant 7 heures et 47 minutes. Push impossible, pull requests bloquées, Copilot en carafe, authentification qui saute. Si tu as essayé de livrer du code ce jour-là, tu t'en souviens.
La cause ? Pas un bug. Pas une faille. Un pic de trafic inédit, largement nourri par les bots et les agents IA. Vlad Fedorov, directeur technique de GitHub, l'a écrit noir sur blanc dans son post-mortem : « Si vous avez essayé de livrer du code ce jour-là, on vous a laissé tomber. »
Cet incident dit quelque chose de plus large. Les plateformes dev encaissent une charge IA qu'elles n'avaient jamais vue. Et ça vous concerne, même si votre boîte est à Villeurbanne et pas dans un data center Central US.
Ce qui s'est vraiment passé le 17 août
La chronologie est nette. Vers 15h40 heure française, un ticket d'incident s'ouvre. Des utilisateurs signalent des lenteurs. En moins de vingt minutes, la liste des services touchés s'allonge service après service : API Requests, Actions, Webhooks, Issues, puis Pull Requests.
Vingt minutes après les premiers signaux, GitHub communique sur une hausse de +50 % d'erreurs. Le retour à la normale n'arrive qu'après 20h00 pour la plupart des services. L'authentification Copilot, elle, traîne encore.
L'origine technique tient en une phrase. Le trafic a atteint un nouveau pic, et un composant d'infrastructure critique dans le data center Central US n'a pas réussi à monter en charge assez vite. La pression s'est propagée, les échecs d'authentification ont suivi, et plusieurs services ont lâché en cascade.
La tempête de retries, le coup de grâce
Le plus instructif, c'est ce qui a rallongé la panne. Certains services Copilot ont mis plus de temps à revenir. Les erreurs sur ces services ont déclenché des boucles de nouvelles tentatives côté client. Résultat : le trafic Copilot a été multiplié par 10, notamment via des retries répétés depuis VS Code, pendant la phase de récupération.
Traduction : les clients qui réessayaient en boucle ont aggravé le problème qu'ils subissaient. C'est le piège classique de la surcharge infrastructure IA. Un service tombe, des milliers de clients bombardent pour se reconnecter, et la charge repart de plus belle. GitHub a dû réduire les retries au niveau des gateways et bloquer temporairement des requêtes de tokens avec des réponses 403 avant de rétablir le trafic progressivement.
Ajoutez à ça des attaques de scraping sur les endpoints codeload. Pas la cause première, mais du bruit en plus lors d'une journée déjà pourrie.
Pourquoi l'IA fait plier les plateformes dev
Le chiffre qui résume tout : depuis avril, les commits mensuels sur GitHub sont passés de 1,4 milliard à 2,9 milliards. En quelques mois. Cette explosion vient des agents et des assistants de code qui commitent, requêtent et s'authentifient sans arrêt.
GitHub pointe directement les bots et agents IA pour une utilisation en flèche qu'elle n'a pas pu absorber. Et le phénomène dépasse GitHub. Selon le baromètre DataDome, le trafic généré par les agents IA a progressé de 45 % entre avril et juin 2026, passant de 12,2 à 17,7 milliards de requêtes.
Le problème, c'est que les agents ne se comportent pas comme des humains. Un dev fatigué finit par arrêter de cliquer. Un agent, lui, réessaie. Encore. Et encore. Multipliez par des milliers d'instances qui tournent en parallèle, et vous obtenez une pression de charge qui n'a plus rien à voir avec l'usage manuel d'il y a deux ans.
Ce n'est pas un cas isolé. La panne GitHub IA du 17 août était le deuxième incident significatif du mois, après une panne d'Actions le 6 août. C'était le cinquième incident notable en trois semaines. Et une semaine après le post-mortem, Actions retombait en panne. La fiabilité reste un chantier ouvert.
Ce que ça vous coûte vraiment
Une panne de 8 heures sur votre outil central, ce n'est pas juste un désagrément. C'est du concret.
- Livraisons bloquées. Pas de push, pas de merge, pas de déploiement. Vos features attendent, vos correctifs urgents aussi.
- CI/CD à l'arrêt. Actions down, c'est toute votre chaîne de tests et de build qui gèle.
- Équipes désœuvrées. Des devs payés à attendre que ça revienne, ou à contourner en catastrophe.
- Effet domino IA. Si vos propres agents dépendent de Copilot ou des API GitHub, ils tombent aussi. Ou pire, ils saturent en retries.
Le vrai coût dépend d'une question simple : à quel point votre production dépend d'une seule plateforme que vous ne contrôlez pas ? Pour beaucoup d'équipes de la région, la réponse est inconfortable.
Pistes de résilience pour les équipes tech de la région
La bonne nouvelle : les mesures que GitHub a annoncées pour lui-même sont aussi vos leçons. La résilience outils développeurs ne demande pas des millions de cœurs CPU. Elle demande de la méthode.
1. Cartographiez vos dépendances critiques
Faites la liste de tout ce qui casse si GitHub tombe. Dépôts, CI, secrets, authentification, agents IA branchés dessus. Notez pour chaque élément ce qui reste possible en mode dégradé. Beaucoup d'équipes découvrent le jour de la panne qu'elles ne peuvent même plus déployer un hotfix. Trop tard.
2. Domptez vos propres retries
C'est la leçon centrale de cet incident. GitHub applique désormais des limites de retry cohérentes, des budgets de retry et des délais d'expiration variables entre services. Faites pareil dans vos clients et vos agents. Backoff exponentiel, jitter, plafond de tentatives. Sans ça, vos agents transforment une panne courte en panne longue, chez vous comme chez votre fournisseur. Si vous déployez des agents en production, ce garde-fou n'est pas optionnel. On en parle dans notre guide sur les cinq garde-fous à poser pour vos agents IA en production.
3. Prévoyez une redondance minimale
Pas besoin de tout dupliquer. Mais un miroir de vos dépôts critiques ailleurs (GitLab, un remote self-hosted, une sauvegarde régulière) vous garantit de garder accès à votre code. Automatisez ces sauvegardes et vérifiez qu'elles fonctionnent vraiment, sujet que nous détaillons dans automatiser ses sauvegardes et vérifier qu'elles fonctionnent.
4. Écrivez un plan de continuité, même court
Une page suffit pour commencer. Qui prévient l'équipe ? Sur quel canal quand GitHub est down ? Comment livre-t-on un correctif urgent en attendant ? Quels services on met en pause côté client pour ne pas empirer la charge ? Ce réflexe de gestion de crise, on l'a déjà décrit pour d'autres incidents dans la leçon de gestion de crise Solimut.
5. Surveillez les bons seuils
GitHub revoit ses alertes CPU et mémoire jusqu'ici jugées de priorité basse pour repérer les composants qui lâchent lors de pics soudains. Même logique chez vous : ne surveillez pas que les erreurs 500. Surveillez la saturation, la latence, le volume de retries. Ce sont les signaux avant-coureurs.
Le vrai enseignement
La surcharge infrastructure IA n'est pas un problème de géant américain. C'est le nouveau régime de charge de tout l'écosystème dev. Les agents IA génèrent un trafic qui ne dort jamais, ne se lasse jamais, et réessaie sans limite si personne ne l'encadre.
Deux choses à retenir. D'abord, aucune plateforme externe n'est infaillible, pas même celle qui héberge le code de la moitié de la planète. Ensuite, une partie de la résilience est entre vos mains : budgets de retry, redondance, plan de continuité.
Prenez une heure cette semaine. Listez ce qui tombe si votre outil dev central disparaît demain matin. Écrivez le plan B. C'est moins glamour que déployer un nouvel agent IA, mais le jour où GitHub retombe, et il retombera, vous ne serez pas le dev qui attend en regardant la page de statut.
Laisser un commentaire