Panne sur GitHub affectant les Issues, Actions et les opérations Git

 (githubstatus.com)
1 points par GN⁺ 2026-02-10 | 1 commentaires | Partager sur WhatsApp
  • Des dégradations de performance et des erreurs ont été signalées sur des services majeurs de GitHub, notamment Actions, Issues et les opérations Git
  • L’impact s’est étendu à Webhooks, Pull Requests, Packages, Pages et Codespaces
  • GitHub a appliqué des mesures d’atténuation (mitigation) et constaté une reprise progressive, avant un retour à la normale de l’ensemble des services
  • L’incident a aussi affecté certains services comme Dependabot et Copilot, qui sont finalement revenus à un état de fonctionnement normal
  • GitHub prévoit de publier ultérieurement une analyse des causes profondes (RCA) et a remercié les utilisateurs pour leur patience et leur coopération

Aperçu de l’incident

  • GitHub a annoncé enquêter sur des signalements de dégradation de performance concernant Actions, les opérations Git et Issues
    • Au début de l’incident, des réponses lentes et des requêtes en échec, ainsi que des tâches Actions retardées, ont été observées
    • L’incident a été signalé pour la première fois le 9 février 2026 à 19:01 UTC

Services affectés

  • Les composants touchés comprenaient les opérations Git, Webhooks, Issues, Pull Requests, Actions, Packages, Pages et Codespaces
    • Des problèmes ont ensuite également été constatés sur Dependabot et Copilot
    • Chaque service était indiqué en état de “degraded performance” (performance dégradée)

Réponse et processus de rétablissement

  • GitHub a indiqué avoir observé des signes de reprise après l’application de mesures d’atténuation
    • Une récupération progressive a commencé après 19:29 UTC
    • À 19:54 UTC, plusieurs services avaient été rétablis, mais certains restaient encore en cours d’investigation
  • À 20:08 UTC, il a été indiqué que « tous les services fonctionnaient normalement »
    • À 20:09 UTC, l’incident est passé à l’état résolu (Resolved)

État final et suites

  • GitHub a précisé que tous les services étaient revenus à un fonctionnement normal
    • Actions, Codespaces, les opérations Git, Issues, Packages, Pages, Pull Requests et Webhooks ont tous été rétablis
  • Une analyse des causes profondes (Root Cause Analysis) sera partagée lorsqu’elle sera prête
  • GitHub a remercié les utilisateurs pour leur patience et leur compréhension

Résumé

  • Cet incident a affecté l’ensemble du workflow de développement central de GitHub
  • La publication d’une RCA est prévue après le rétablissement complet, avec des améliorations attendues pour prévenir des incidents similaires à l’avenir
  • Le fait qu’un autre incident ait été signalé le même jour met en évidence l’importance de la gestion de la stabilité

À lire aussi

1 commentaires

 
GN⁺ 2026-02-10
Avis Hacker News

  • À cause des pannes partielles récurrentes de GitHub, certains envisagent de migrer toute leur entreprise vers un autre fournisseur
    Des fonctionnalités qui marchaient bien autrefois sont désormais lentes, et Actions ne s’exécute plus à temps
    Copilot est appréciable, mais si la forge git ne fonctionne pas correctement, partir devient inévitable

    • Totalement d’accord. Avant c’était excellent, maintenant même les fonctions de base sont instables
      Ouvrir un simple diff de PR peut prendre plus de 15 secondes, et l’interface semble se figer à répétition
      Il est surprenant de voir cette dégradation anormale des performances traitée comme quelque chose de normal
    • Dire qu’on « aime Copilot » sonne presque comme une blague
    • Ironiquement, Linus Torvalds a conçu git pour une architecture non centralisée
      Au fond, l’essence de git est justement de pouvoir faire tourner les pipelines CI en local
      Pour ma part, je n’utilise GH que pour la synchronisation
    • Autrefois, GitHub publiait souvent des postmortems, mais c’est devenu très rare récemment
      En relisant les anciens billets, on voit qu’ils se heurtaient déjà aux limites de scalabilité de leur base SQL
      C’est comparable au cas d’extension de Postgres chez OpenAI : scaling-postgres, sauf que GitHub semble moins bien s’en sortir
    • Certains estiment qu’« attendre un produit fiable est illusoire » et y voient un problème propre à Microsoft

  • Les pannes fréquentes de GitHub servent au contraire à tester la résilience des pipelines de déploiement
    La plupart des équipes dépendent totalement de GitHub, donc les déploiements s’arrêtent en cas d’incident
    D’où quelques alternatives mises en place :

    1. miroir des dépôts critiques vers GitLab ou Gitea
    2. mise en cache des dépendances pour éviter les échecs de build
    3. préparation d’un runbook permettant un déploiement manuel sans GitHub Actions
      La page d’état officielle étant toujours mise à jour en retard, elle est désormais considérée comme une information simplement « eventually consistent »

  • GitHub subit peut-être la charge liée à l’explosion des workflows de développement automatisés
    Les commits dans les dépôts personnels ont explosé, mais les conversions vers des offres payantes restent quasi nulles

    • Le problème avait en fait commencé dès le rachat par Microsoft
      La gratuité des dépôts privés en 2019 aurait fait manquer une occasion de monétisation
    • En réalité, les incidents fréquents viendraient de la migration d’AWS vers Azure
      Et il y aurait aussi un manque de sens des responsabilités vis-à-vis du downtime
    • Au final, ils se heurtent aux limites de scalabilité
    • La génération de code par IA fait exploser le nombre de dépôts, de commits et de jeux de données
    • Le tout se résume par : « vivre grâce au boom des agents IA, mourir lors de l’effondrement des agents IA »

  • Certains avancent que GitLab est l’alternative
    GitHub serait désormais entièrement focalisé sur une stratégie centrée sur l’IA, au détriment de la plateforme elle-même
    Le taux d’adoption de Copilot serait faible, et les entreprises utiliseraient davantage Claude
    Si Microsoft change encore de direction, la situation pourrait empirer

    • Une question revient : Copilot repose-t-il sur son propre modèle ?
    • Mais GitLab n’est pas parfait non plus
      Des fonctionnalités sortent dans un état à moitié terminé, et les performances sont lentes
      Les avantages du modèle open core paraissent désormais bien moins nets
    • GitLab aussi s’oriente vers l’IA
      Dev → DevOps → DevSecOps → AI DevSecOps, mais
      à chaque étape, la finition laisse à désirer, et des montées de licence deviennent nécessaires, ce qui est contraignant

  • Le problème viendrait aussi du fait de regrouper CI/CD et hébergement du code dans une seule et même plateforme
    Même si tout fonctionne parfaitement, cela n’empêche pas le lock-in fournisseur
    À l’origine, il devait suffire de changer de remote, mais désormais tout est entremêlé avec les PR, le wiki, etc.

    • Pour certains, ce n’est pas une erreur mais une stratégie de verrouillage délibérée
    • Utiliser un système CI indépendant, comme la solution open source forgejo, serait déjà mieux

  • Les pannes de GitHub ressemblent désormais moins à un simple problème SaaS qu’à une panne au niveau cloud
    C’est pourquoi de nombreuses équipes migrent vers du GitLab/Gitea auto-hébergé

    • Deux startups ont utilisé GitLab avec succès
      Une grande entreprise utilisait GitLab Enterprise on-premise pour des raisons de sécurité,
      et des projets personnels tournent sur Forgejo
      Git, les issues, les boards et le wiki fonctionnent bien, et les labels scoped y sont gratuits
    • L’auto-hébergement de Gitea est aussi une bonne option, à condition de bien gérer les sauvegardes
    • L’auto-hébergement de la version complète de GitLab vaut largement son coût
    • L’auto-hébergement de GitLab donne clairement satisfaction

  • Il existe une page qui visualise l’historique des incidents multiples de GitHub
    Visible sur mrshu.github.io/github-statuses

    • updog.ai/status/github s’appuie aussi sur des données Datadog
    • En revanche, la mise à jour semble arrêtée (la dernière date du 6 février)

  • On trouve aussi un commentaire en forme de plaisanterie : « Équipe GitHub, prenez votre temps »

  • Certains veulent quitter GitHub, mais ont besoin d’une CI stable et d’un registre de conteneurs
    Ils sont prêts à payer pour une solution qui « fonctionne, tout simplement »

    • Lithus.eu est recommandé : CI basée sur Forgejo + Firecracker VM
      Adaptée aux workloads importants, mais avec un coût initial élevé
    • GitLab CI est simple et puissant
      La gestion des permissions du registre est un peu complexe, mais l’intégration globale est bonne
    • Certains se demandent si le dépôt doit vraiment être responsable de la CI
      Selon la philosophie Unix, il vaudrait mieux revenir à des outils à objectif unique
    • nix-ci.com est aussi recommandé par certains
    • CircleCI reste également une alternative fiable

  • Un graphique montrant la corrélation entre le taux d’adoption de l’IA et la fréquence des pannes serait intéressant à voir

    • Bien sûr, d’autres facteurs jouent probablement aussi un rôle