Trouver un service ou un site

Saisissez au moins 2 caractères.

Panne mondiale de GitHub : l'API, les demandes de tirage et Copilot touchés alors que les taux d'erreur explosent

Panne mondiale de GitHub : l'API, les demandes de tirage et Copilot touchés alors que les taux d'erreur explosent

17 août 2026

Ce qui a échoué et quand

GitHub a subi une disruption de service mondiale le lundi 17 août, débutant aux alentours de 13:40 UTC (6:40 a.m. PT), selon les chronologies rapportées par BetaNews et The Register. BetaNews a écrit que GitHub a d'abord déclaré qu'il enquêtait sur des problèmes de performance, avant de confirmer des problèmes plus larges touchant plusieurs composants. The Register a également placé le début de l'incident à 13:40 UTC. GeekWire a fixé le début à 6:40 a.m. Pacific, alignant les rapports.

Tout au long de la matinée, des éditeurs ont relayé les mises à jour de statut de l'entreprise décrivant une dégradation généralisée. BleepingComputer a rapporté que les développeurs rencontraient des erreurs sur le site web, les demandes API, les actions, les webhooks, les problèmes et les demandes de tirage, avec Copilot ajouté plus tard à la liste des services touchés. Engadget et Tech Edition ont également noté des problèmes avec l'activité API, les demandes de tirage, les webhooks et Copilot.

Qui a été touché et à quelle échelle

GeekWire a décrit GitHub comme une plateforme détenue par Microsoft avec 225 millions d'utilisateurs et a déclaré que la panne perturbait le travail de développement dans le monde entier. BetaNews a également caractérisé l'événement comme un incident mondial massif. Bien que ces médias n'aient pas chiffré le nombre d'utilisateurs pendant la disruption, plusieurs éditeurs ont relayé les métriques instantanées de la plateforme à partir de sa page de statut.

BetaNews a rapporté qu'à 14:04 UTC, GitHub a cité un taux d'erreur d'environ 20 % pour le trafic web et API, avec des téléchargements d'archives et de dépôts bruts échouant environ 50 % du temps. Hindustan Times et Engadget ont répété cette métrique plus tard le matin aux États-Unis, notant qu'à environ 11:42 a.m. ET, GitHub a déclaré qu'il mettait en œuvre des atténuations tout en rapportant les mêmes chiffres de 20 % et 50 %. The Register a souligné le taux d'échec de 50 % pour les téléchargements de contenu des dépôts. BleepingComputer a ajouté que certains utilisateurs ont rencontré des erreurs de serveur lors du chargement des commits, des dépôts et des pages de demandes de tirage pendant la période de l'incident. Les clients d'entreprise ont également ressenti l'impact : tant BleepingComputer que BetaNews ont déclaré que l'authentification SAML et OIDC, SCIM et la synchronisation des équipes étaient affectées.

Ce que GitHub et Microsoft ont dit pendant la récupération

Les éditeurs ont relayé une séquence de mises à jour de la page de statut tout au long de la matinée et du début d'après-midi. BetaNews a rapporté qu'à 16:36 UTC, Microsoft a déclaré avoir identifié un composant problématique et avoir pris des mesures correctives, notant des signes de récupération tout en reconnaissant que les taux d'erreur demeuraient élevés. Peu après, BetaNews a écrit que Microsoft a déclaré que la dégradation affectant les demandes API, les actions, les opérations Git, les problèmes, les pages, les demandes de tirage et les webhooks avait été atténuée et que les équipes surveillaient la stabilité.

Depuis la côte ouest des États-Unis, GeekWire a rapporté que GitHub a déclaré avoir trouvé la source du problème peu après 9:30 a.m. PT et avoir maîtrisé la panne vers 10:00 a.m. PT, avec des services en cours de récupération. GeekWire a ajouté que Copilot restait listé comme un incident actif pendant que l'entreprise continuait à surveiller la stabilité globale. BleepingComputer a placé la disponibilité dégradée de Copilot à 10:31 a.m. ET. BleepingComputer a également noté que les opérations Git, les packages, les pages et les espaces de code étaient indiqués comme opérationnels alors que plusieurs autres parties de la plateforme restaient dégradées. Aucune de ces mises à jour n'a affirmé que la restauration était complète.

Cause et questions en suspens

Au moment des publications citées par les médias, GitHub n'avait pas divulgué de cause profonde pour la panne. GeekWire a déclaré que l'entreprise n'avait pas détaillé la source ou la cause du problème au moment de son rapport, et BleepingComputer et Tech Edition ont également déclaré que l'enquête était en cours et que la cause restait floue. CyberSecurityNews a également écrit que la cause profonde n'avait pas été divulguée publiquement. Lorsque des chiffres ont été publiés, ils représentaient des instantanés pris à partir de la page de statut à des moments spécifiques ; par exemple, les taux d'erreur de 20 % et 50 % ont été rapportés comme des mesures à un instant donné plutôt que comme des totaux finaux. Si GitHub fournit une analyse post-incident, cela pourrait clarifier si une défaillance d'un composant ou une chaîne de dépendances plus large a déclenché la disruption de lundi ; jusqu'à présent, la cause reste non confirmée dans les rapports publics.

Surveiller les services dont vous dépendez

Pour une vue plus large des disruptions en cours, consultez l'archive des pannes Internet et le répertoire des sites et services. Status Is Down propose des plans pour aider les équipes à surveiller les services et sites web sur lesquels elles s'appuient, et les lecteurs peuvent s'inscrire pour choisir la couverture qui leur convient.

Sources

Crédit image : ID 176448931 © Transversospinales | Dreamstime.com

Recent Outage News and Features

Loading...

🌐 This article is available in other languages:

English·Español·Português·中文·العربية·हिन्दी·日本語·Русский·Deutsch·Bahasa Indonesia·Türkçe·한국어·Kiswahili·Italiano·Nederlands·Polski·Tiếng Việt·Filipino·বাংলা