GitHub en panne le 17 août 2026 : ce qu’il s’est passé

Le 17 août 2026, GitHub — la plateforme détenue par Microsoft et utilisée par environ 225 millions de développeurs — a subi une panne généralisée qui a perturbé le développement logiciel dans le monde entier pendant environ sept heures et demie. Si vous avez vu ce jour-là la page de la licorne rose affichant « No server is currently available to service your request », ou si vos pushes, vos exécutions CI et Copilot sont tous tombés en panne en même temps, voici ce qui s’est passé. L’incident est désormais résolu.

Ce qui ne fonctionnait plus

La panne ne s’est pas limitée à une fonctionnalité : elle a touché un large éventail de services. À son point culminant, GitHub a signalé environ 20 % d’erreurs sur les interfaces web et le trafic API, ainsi qu’environ 50 % d’erreurs sur les téléchargements d’archives et le contenu brut des dépôts. Les services concernés comprenaient le site web, les Pull Requests, les Issues, Actions, les Webhooks, les requêtes API, les opérations Git, Pages et Copilot. Les systèmes d’authentification et d’identité ont également été touchés : l’authentification SAML et OIDC, SCIM et Team Sync figuraient tous sur la liste des services impactés. C’est ce qui a rendu la panne particulièrement pénalisante, y compris pour les équipes dont les workflows principaux auraient normalement pu continuer à fonctionner en mode dégradé.

Chronologie (UTC)

• 13:40 — GitHub ouvre l’incident et signale une dégradation des performances de certains services.
• 13:45 — Première estimation chiffrée : environ 20 % d’erreurs sur les Pull Requests, les Issues et d’autres interfaces.
• 14:04 — Le périmètre s’élargit : environ 20 % d’erreurs sur le trafic web et API, et environ 50 % sur les archives et le contenu brut des dépôts.
• 14:24 — L’authentification SAML/OIDC, SCIM et Team Sync sont ajoutés à la liste des services touchés.
• 14:45–14:58 — Les Pull Requests, Issues, Actions et Webhooks passent d’une dégradation des performances à une dégradation de la disponibilité ; GitHub commence à appliquer des mesures d’atténuation et à surveiller la situation.
• ~16:36 — GitHub identifie le composant problématique, applique une mesure corrective et constate de forts signes de rétablissement.
• ~16:59 — La dégradation est considérée comme maîtrisée pour la plupart des services ; la surveillance continue, Copilot restant en retrait.
• ~21:15 — L’incident est déclaré entièrement résolu, environ sept heures et demie après son début, après de nouvelles interventions sur des échecs de connexion sporadiques affectant Copilot et d’autres services.

Quelle était la cause ?

À ce jour, GitHub n’a pas publié de cause technique précise. Pendant l’incident, la plateforme a indiqué avoir identifié « le composant problématique » et appliqué une mesure corrective. Toutefois, elle n’a pas nommé ce composant et n’a encore publié aucune analyse détaillée de la cause racine. GitHub a précisé qu’elle partagerait une analyse complète dès qu’elle serait disponible.

Quelques points méritent d’être clairement établis, car ce type de panne suscite rapidement des spéculations : GitHub n’a pas attribué l’incident à un fournisseur en amont et n’a fait état d’aucun lien avec Azure. Toute affirmation désignant une cause précise — une panne d’Azure, un problème de base de données ou un déploiement défectueux, par exemple — doit être considérée comme non confirmée jusqu’à la publication de l’analyse officielle de GitHub. Cet article sera mis à jour lorsque cette analyse sera disponible.

Pour replacer l’incident dans un contexte plus large, GitHub subit depuis plusieurs mois la pression liée à l’essor du développement assisté par l’IA. Son directeur technique a indiqué plus tôt en 2026 que l’entreprise avait d’abord prévu de multiplier sa capacité par environ dix, avant de conclure qu’elle devait encore construire une infrastructure capable de supporter une échelle bien supérieure. Ce type de pression peut rendre les incidents majeurs en cascade plus probables, même si elle ne constitue pas la cause confirmée de cette panne.

Que faire pendant une panne de ce type ?

1. Vérifiez que le problème vient bien de GitHub : consultez githubstatus.com et @githubstatus. Si un incident est en cours, le problème vient des serveurs.
2. Ne cherchez pas à diagnostiquer votre propre configuration. Réinstaller vos outils, renouveler vos tokens ou reconfigurer git ne servira à rien lorsque GitHub rencontre lui-même une panne.
3. Mettez en pause les nouvelles tentatives automatiques et les pipelines de déploiement afin d’éviter l’accumulation des tâches échouées pendant que le taux d’erreur reste élevé ; reprenez-les lorsque le statut sera revenu au vert.
4. Patientez et réessayez. Une panne côté serveur ne peut pas être corrigée localement : surveillez le statut et laissez le service se rétablir.

Je publie des retours sur les pannes et les pièges du débogage au fil de mes expériences : si cela peut vous être utile, vous en trouverez d’autres sur Netalith, ou vous pouvez me contacter sur LinkedIn.