- 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
Aucun commentaire pour le moment.