GitHub peine à maintenir une disponibilité de 99,9 % malgré ses engagements

• Les pannes de service fréquentes de GitHub se multiplient récemment, au point qu’il semble difficile d’atteindre non seulement le standard du secteur des « 5 nines » (99,999 %), mais même les « 3 nines » (99,9 %)
• Le 9 février, des fonctions majeures comme Actions, Pull Request, notifications et Copilot ont subi des pannes simultanées, et certains services ont connu des retards de plusieurs heures
• En raison d’un problème de propagation des politiques Copilot, certains utilisateurs ont constaté jusqu’au matin du 10 février une erreur d’affichage des modèles
• Après que GitHub a modifié la structure de sa page d’état, il est devenu difficile de suivre la disponibilité sur les 90 derniers jours, et des données non officielles montrent aussi des périodes où la disponibilité est passée sous les 90 %
• Bien que le SLA Enterprise Cloud mentionne 99,9 % d’uptime, cela n’est pas garanti pour tous les utilisateurs, ce qui renforce la nécessité de prévoir une stratégie opérationnelle face aux temps d’arrêt

---

Baisse de disponibilité de GitHub et pannes de service répétées

• Alors que les pannes fréquentes des services cloud tendent à se banaliser, GitHub rencontre lui aussi des problèmes de stabilité
  • On en vient à entendre qu’« il est rare qu’une journée se passe sans incident », au point qu’il serait difficile d’atteindre non seulement les « 5 nines » (99,999 %), mais même « 1 nine » (90 %)
• Le 9 février (UTC), les principales fonctions de GitHub — Actions, Pull Request, notifications et Copilot — ont toutes subi des incidents
  • GitHub a indiqué vers 15 h 54 que « certains services rencontraient des problèmes » et a annoncé un retard des notifications d’environ 50 minutes
  • À 17 h 57, ce retard avait été réduit à environ 30 minutes, puis GitHub a annoncé un retour à la normale à 19 h 29
• Les incidents liés à Copilot ont duré plus longtemps
  • Du 9 février à 16 h 29 au 10 février à 9 h 57, certains utilisateurs ont été affectés par un problème de propagation des politiques Copilot
  • Cela a entraîné des cas où des modèles nouvellement activés n’étaient pas affichés pour les utilisateurs
• GitHub a modifié la structure de sa page d’état, rendant plus difficile le suivi de la disponibilité sur les 90 derniers jours
  • Des informations détaillées restent fournies, mais la nouvelle présentation rend plus difficile la lecture visuelle de la tendance globale d’uptime
  • Les données d’une page de restauration non officielle (mrshu.github.io/github-statuses/) montrent qu’en 2025, la disponibilité est tombée à un moment donné sous les 90 %
• Le SLA Enterprise Cloud de GitHub indique 99,9 % d’uptime, mais ne le garantit pas à tous les utilisateurs
  • Dans le secteur, les « 5 nines » sont considérés comme la référence idéale, mais certains fournisseurs sont jugés incapables de maintenir ne serait-ce que 90 %
  • Cette situation suggère que les clients doivent préparer des plans d’exploitation en partant du principe qu’il y aura des interruptions

Contexte et cas connexes

• GitHub a récemment traversé plusieurs controverses autour de ses fonctions IA et de changements de politique
  • Examen d’un « kill switch » pour bloquer le code IA dans les Pull Requests

  • Annulation du projet de tarification des runners auto-hébergés

    • Il existe un cas où le projet du langage Zig a quitté GitHub en invoquant la politique centrée sur l’IA de Microsoft
    • Avec ces événements, la dégradation de la stabilité du service alimente aussi le mécontentement de la communauté des développeurs

Conclusion

• Les incidents récents de GitHub mettent en lumière un problème de disponibilité qui semble empêcher d’atteindre ne serait-ce que « trois 9 » (99,9 %)
• Alors que l’instabilité de fonctions clés comme Copilot se poursuit, la fiabilité des plateformes de développement cloud devient un enjeu majeur
• La nécessité d’élaborer une stratégie de résilience face aux temps d’arrêt est une nouvelle fois mise en avant

[elbanic]

GitHub est un service gratuit, donc s’attendre à de la haute disponibilité en soi…

[cosine20]

Est-ce que vous tiendrez le même discours si KakaoTalk tombe en panne aussi...

[malkeu]

On dirait qu’il suffirait de faire git reset --hard.

[master6559]

Si seulement GitHub pouvait éviter les pannes, ça me conviendrait très bien comme ça.

[GN⁺]

Réactions sur Hacker News

• Les problèmes de disponibilité (uptime) de GitHub sont clairement sérieux, mais dire que « GitHub entier est en panne » parce que toutes les fonctionnalités se sont arrêtées en même temps me paraît excessif
  Je n’utilise presque jamais Copilot, donc même si ce service tombe souvent, cela m’importe peu
  Ce qui compte vraiment, c’est la stabilité des fonctions essentielles comme Git, le site web, l’API et Actions

  • D’accord. Mais au cours des 90 derniers jours, aucun service individuel n’a atteint une disponibilité de 3x9 (99,9 %)
    Selon le SLA Enterprise de GitHub, au moins 99,9 % doivent être garantis pour chaque service, et les chiffres réels sont visibles ici
  • Dire que « GitHub est en panne » est certes exagéré, mais en réalité même l’API n’est qu’à 99,69 %, soit seulement deux 9
    Copilot est au niveau d’un seul 9, et c’est aussi le cas de services centraux comme Git et Actions
  • Cette entreprise fait partie du portefeuille d’un groupe mondial valorisé à 1 000 milliards de dollars
    Une société avec de telles ressources n’a aucune excuse pour abandonner ses clients
  • Le « 5 nines » dont parlent les grandes entreprises aujourd’hui relève presque de la fiction
    En pratique, même des réponses en erreur sont comptées comme du « fonctionnement normal »
    Il est rare d’atteindre un vrai 99,999 % comme dans le secteur réseau, et le plus souvent on se contente de trucs de découpage des données pour garder la page de statut en vert

• J’étais déjà inquiet quand le CTO de GitHub a annoncé en 2025 qu’ils allaient tout migrer vers Azure pour améliorer la fiabilité
  Avant, la communauté réclamait « ajoutez plus vite de nouvelles fonctionnalités », mais aujourd’hui ce dont on a le plus besoin, c’est de stabilité et de fiabilité

  • Malgré tout, GitHub reste lent même pour ajouter de nouvelles fonctionnalités
  • Si on n’utilise pas uniquement des plateformes géantes, il existe aussi des alternatives petites et d’une stabilité presque ennuyeuse
  • J’ai rejoint à cette époque, et le simple fait de pouvoir partager publiquement mon dépôt me semblait extraordinaire
  • Globalement, la fiabilité du secteur s’est améliorée, mais aujourd’hui il y a d’innombrables dépendances imbriquées, si bien qu’un problème en un seul point peut tout faire vaciller
  • J’espère presque qu’au moment du basculement complet vers Azure, ils oublieront encore une fois l’accès IPv6

• GitHub subit en ce moment une triple peine : migration vers Azure, changements d’infrastructure pilotés par l’IA et explosion du trafic lié à l’IA
  Sur les projets populaires, des dizaines de PR générées par l’IA arrivent quelques minutes après l’ouverture d’une issue
  Il est difficile d’absorber une telle charge, et les « N 9s » d’avant l’IA n’ont rien à voir avec les « N 9s » d’après

  • Exact. GitHub n’a pas été conçu à l’origine pour un tel environnement d’emballement d’agents IA

• Si l’on regarde la page de statut de GitHub, on est en réalité à 90,21 %, soit à peine un seul 9
  Dans les archives de 2019, on comptait 1 à 4 incidents par mois, alors qu’aujourd’hui c’est presque un par jour

  • Si ce chiffre paraît mauvais, c’est parce qu’il inclut non seulement les pannes, mais aussi les dégradations de performance (degraded performance)
  • En plaisantant, certains disent que c’est quand même mieux que status.claude.com de Claude

• Tandis que GitHub s’obsède pour les fonctionnalités IA, la sécurité de la plateforme s’effondre
  Récemment, Aqua Security a été attaqué et plusieurs dépôts ont été infectés, dans un cas exploitant la vulnérabilité de référence mutable de GitHub Actions
  GitHub connaissait ce problème et ne l’a pourtant pas corrigé

  • En mesure provisoire, il vaut mieux épingler (pin) les versions d’Actions avec un hash
    Exemple : uses: actions/checkout@11bd7190...
    Pour l’automatisation, voir mheap/pin-github-action
  • Je pense que la CI/CD est devenue excessivement embrouillée à cause de la complexité basée sur YAML
    Autrefois, on déployait avec Jenkins et les tests simples se faisaient avec des scripts, alors qu’aujourd’hui c’est devenu un enfer YAML distribué
  • La sécurité de GHA est à un point tel qu’on dit qu’il y a « plus de trous que dans du gruyère »
  • Il existe aussi une discussion communautaire sur ce problème laissé en plan depuis des années

• Les 90 % de disponibilité incluent tous les services, donc la perception réelle peut varier
  Mais même les 96,47 % de Copilot ne représentent qu’un seul 9
  GitHub recommande d’« utiliser toutes les fonctionnalités ensemble », mais plus on le fait, plus la fiabilité chute brutalement

  • En plus, les cas où « c’est lent mais ça marche » n’entrent pas dans les statistiques
    Par exemple, ouvrir un simple diff de PR peut prendre plus de 30 secondes
  • Certains incidents sont aussi signalés en retard de manière officielle
    Il y a même eu des cas où la CI/CD, git et les fonctionnalités de PR étaient toutes à l’arrêt
  • Comparé aux données de 2019, la situation s’est dégradée de plus de 10 fois
  • 96 %, c’est vraiment un chiffre épouvantable

• Pour avoir déjà exploité moi-même GitHub Enterprise Server, ces problèmes ne m’étonnent pas
  Pas de support active-active, pas de mise à niveau sans interruption, pas de rollback possible : il ne remplit pas les exigences élémentaires de haute disponibilité
  En cas de bug, il n’y a pas d’autre solution que de restaurer une sauvegarde, et ce processus entraîne une perte de données
  Vendre un tel produit à des clients haut de gamme est la preuve d’une indifférence à la disponibilité

  • Notre entreprise aussi a fini par abandonner GHES pour migrer vers GHEC

• Microsoft a un talent certain pour dégrader de bons produits
  Skype en est l’exemple type, et c’est pareil pour Windows, Notepad et Explorer
  Il y a aussi une forte confusion de marque allant de Office → Office 365 → Microsoft 365 → Copilot 365

  • On verra sans doute bientôt arriver « GitHub for Business »

• Dans notre entreprise, on lance un scan de sécurité via GitHub Actions sur chaque PR
  Quand GitHub tombe, la barrière de sécurité tombe elle aussi, et les développeurs fusionnent sans vérification
  Du code vulnérable peut alors entrer, alors que GitHub continue de concentrer ses effectifs sur Copilot

  • Certains demandaient s’il existait des cas publics à ce sujet

• Le fait d’ignorer IPv6 symbolise la négligence technique de GitHub
  Le problème plus grave, c’est de savoir pourquoi, dans cet état, l’entreprise continue de réussir ses audits de sécurité
  Quand on lit la documentation de sécurité de GitHub, cela semble n’être qu’un vernis formel

  • La qualité des audits serait aussi médiocre que l’architecture elle-même