GitHub : incident sur les opérations Git

 (githubstatus.com)
3 points par GN⁺ 2025-11-20 | 1 commentaires | Partager sur WhatsApp
  • Le 18 novembre 2025 (UTC), GitHub a subi un échec de toutes les opérations Git, interrompant les clients SSH et HTTP ainsi que l’accès aux fichiers bruts
  • La cause du problème a été identifiée comme étant l’expiration d’un certificat TLS utilisé pour la communication entre services internes
  • GitHub a remplacé le certificat expiré et redémarré les services affectés, achevant ainsi un rétablissement complet
  • Depuis, l’entreprise renforce les alertes de surveillance de l’expiration des certificats et mène une transition vers l’automatisation pour supprimer les certificats gérés manuellement
  • Cet incident a affecté Git Operations et Codespaces de GitHub, et tous les services sont revenus à la normale après la restauration

Rapport d’incident sur les opérations Git

  • Entre le 18 novembre 2025 à 20:30 et 21:34 UTC, GitHub a subi un échec de toutes les opérations Git

    • Les interactions des clients Git en SSH et HTTP, ainsi que l’accès aux fichiers bruts, ont tous été affectés
    • Les produits dépendant des opérations Git ont également subi le même incident

  • La cause a été identifiée comme un certificat TLS expiré utilisé pour la communication entre services internes

    • GitHub a résolu le problème en remplaçant le certificat et en redémarrant les services affectés
    • Après le redémarrage des services, un rétablissement complet a été obtenu

  • Pour éviter qu’un problème similaire ne se reproduise, GitHub a renforcé le système d’alerte sur l’expiration des certificats

    • Des vérifications de surveillance et d’automatisation sont également en cours pour d’autres certificats dans les zones concernées
    • L’entreprise accélère la suppression des certificats encore gérés manuellement et la mise en place d’un système automatisé de communication entre services

Déroulement de l’incident et étapes de rétablissement

  • 20:39 UTC : signalement d’une dégradation de disponibilité sur les opérations Git et Codespaces
  • 20:52 UTC : confirmation de l’échec de certaines opérations Git en HTTP
  • 21:11 UTC : confirmation de l’échec de toutes les opérations Git
  • 21:25 UTC : dégradation de disponibilité persistante sur Codespaces
  • 21:27 UTC : cause identifiée, lancement du correctif
  • 21:36 UTC : début d’un rétablissement partiel après le déploiement du correctif
  • 21:55 UTC : retour à la normale de tous les services, rétablissement de Codespaces terminé
  • 21:56 UTC : confirmation du fonctionnement normal des opérations Git
  • 21:59 UTC : incident clôturé et rapport publié

Services affectés

  • Git Operations
    • Ensemble des opérations Git via SSH et HTTP
  • Codespaces
    • Dégradation temporaire de disponibilité

Actions de suivi

  • Renforcement de la surveillance de l’expiration des certificats et de l’automatisation
    • Mise en place d’un système d’alerte avant expiration
    • Vérification des processus de renouvellement automatique pour tous les certificats internes
  • Extension de l’automatisation de la sécurité et des opérations
    • Suppression de la gestion manuelle des certificats
    • Mise en place d’une communication automatisée entre services conforme aux pratiques de sécurité les plus récentes

À lire aussi

1 commentaires

 
GN⁺ 2025-11-20
Avis sur Hacker News

  • Il est inquiétant de voir les pannes majeures de systèmes logiciels se produire si souvent ces derniers temps
    L’an dernier, il n’y en a eu que quatre ayant affecté mon travail, mais c’est déjà la quatrième ce trimestre
    J’ai l’impression que la résilience des logiciels réseau disparaît peu à peu
    Notre équipe utilise une architecture monolithique, mais avec de nombreuses dépendances comme Redis, S3 et des services d’intégration externes
    Nous avons donc simplifié l’ensemble en documentant les conditions de panne, en renforçant l’automatisation des tests et des déploiements, et en migrant du cloud vers des VPS
    Résultat : le système est devenu bien plus stable et prévisible
    Sans ce travail ingrat mais indispensable, la complexité n’aurait fait qu’augmenter et le système serait devenu encore plus fragile
    Les pannes récentes que nous avons subies concernaient AWS us-east-1, Azure Front Door, Cloudflare et GitHub

    • Au fond, je pense que le problème, c’est l’argent
      Les clients ne veulent pas dépenser pour la résilience ou une infrastructure redondante
      Depuis 2008, j’ai travaillé sur une dizaine de projets, et dans la plupart des cas l’attitude était : « on va juste compter sur la chance »
    • D’accord. La réduction des coûts finit par nous faire « oublier comment construire des systèmes qui tiennent même en cas de panne »
    • Pour être volontairement provocateur, je pense aussi que la hausse de l’usage des LLM contribue à ce phénomène

  • Git est un système de gestion de versions distribué, donc on peut travailler même sans GitHub
    GitHub n’est qu’un hub pratique

    • Sauf pour les entreprises entièrement dépendantes de GitHub Actions, qui sont complètement bloquées dans un cas comme celui-ci
    • C’est un peu la situation : « Cet escalator est temporairement transformé en escalier. Nous vous prions de nous excuser pour la gêne occasionnée. »
    • Le fond du problème, c’est que GitHub est en panne, pas git lui-même
    • Sans GitHub, on perd sa fonction de hub de collaboration avec les autres
    • Si on est sur Hacker News en ce moment, c’est parce qu’on ne peut pas travailler

  • Le manque de fiabilité de GitHub semble sérieux
    Pour ceux qui dépendent de la CI/CD, c’est critique
    En interne, on dirait que c’est perçu seulement comme « la CI/CD de notre équipe est cassée », sans prendre en compte le fait que « la moitié du monde est à l’arrêt »
    Cette culture en silos et cette attitude du type « ce n’est pas notre problème » finissent par dégrader la fiabilité
    En plus, sa position dominante fait que les clients n’ont guère d’autre choix que de continuer à l’utiliser
    Cela rappelle l’attitude déjà vue chez Verio ou Verisign : « de toute façon, vous n’irez nulle part ailleurs »

  • Je me demande si les pannes cloud/SaaS sont vraiment plus fréquentes en ce moment
    Je ne sais pas si c’est simplement plus médiatisé, ou si la fréquence a réellement augmenté
    Est-ce à cause des coupes budgétaires, des suppressions de postes, de l’adoption de l’IA ou d’une croissance excessive ?

    • Microsoft semble penser que tout ira mieux en migrant GitHub sur Azure
    • En tant qu’utilisateur de longue date, je ressens clairement une augmentation de la fréquence des pannes
      Avant, c’était une ou deux fois par an ; aujourd’hui, c’est presque tous les mois, et récemment presque toutes les semaines
    • Lors d’une panne Cloudflare, quelqu’un a dit que la « culture du code pilotée par l’IA » aggravait ce genre de problèmes
      De petits fragments de code générés par IA peuvent déclencher des pannes en cascade
    • Comme le suggère un article de Techrights,
      les licenciements massifs ont pu contribuer à la baisse de fiabilité
    • À cause du FOMO (peur de rater quelque chose) lié à l’IA, les calendriers de projet deviennent plus tendus,
      et les 10 % finaux du travail de stabilisation semblent finalement être ignorés

  • Comme le push ne passait pas, j’ai d’abord cru que le problème venait de moi
    J’ai finalement décidé d’abandonner pour aujourd’hui et de réessayer demain

    • L’authentification fonctionnait, mais le push non, une expérience vraiment à s’arracher les cheveux
    • Même en ajoutant une nouvelle clé SSH, ça n’a servi à rien. Au début, j’avais juste des erreurs bizarres, puis finalement le message « upstream unhealthy »
    • J’ai failli moi aussi reconfigurer tout mon environnement depuis zéro

  • Je n’avais déjà pas envie de travailler aujourd’hui, et après Cloudflare voilà GitHub qui tombe aussi ; on dirait presque un signe qu’il faut se reposer

    • Le problème, c’est cette dépendance centralisée à la technologie centrée sur les États-Unis
      Il faut davantage de souveraineté technologique et de décentralisation

  • Parmi les services que j’ai utilisés ces cinq dernières années, GitHub est celui qui a été le plus instable
    Je me demande si GitLab est meilleur. À ce stade, ma confiance dans GitHub est quasiment nulle

    • Dans notre entreprise, nous auto-hébergeons GitLab, mais le serveur Gitaly tombe souvent
      C’est probablement lié à notre gros environnement en mono-repo, mais il y a clairement des problèmes de scalabilité
    • GitLab a beaucoup de fonctionnalités, mais l’intégration est brouillonne et l’ensemble manque de finition
      Cela dit, le fait de pouvoir réunir dépôt, CI/CD, issues et wiki au même endroit est un avantage
    • J’utilise à la fois GitHub.com et un GitLab auto-hébergé ;
      GitHub est vulnérable aux pannes du cloud, tandis que GitLab souffre souvent d’échecs de mise à niveau automatique
      Chacun a ses avantages et ses inconvénients
    • Le problème avec GitLab, c’est qu’il est lent et lourd
      Il charge plusieurs Mo de JS, donc sur un réseau lent les pages s’affichent à peine
    • En on-premise, on peut obtenir autant de fiabilité qu’on le souhaite

  • En urgence, on peut modifier directement des fichiers depuis l’interface web de GitHub
    Mais actions/checkout@v4 de GH Actions ne fonctionne pas actuellement à cause du problème git

    • En réalité, n’importe quel hôte accessible en SSH permet de faire du git push/pull
    • Nous étions nous aussi en train de faire un hotfix en production, et nous avons été bloqués. Je ne sais pas ce qui se passe avec Internet ces temps-ci
    • CircleCI échoue lui aussi sur les opérations git à cause d’un problème de reconnaissance des clés SSH GitHub
    • Cette fois, l’IA de GitHub m’a indiqué de vérifier githubstatus.com, ce qui a été étonnamment utile
    • Je me demande s’il est possible de créer une branche depuis l’interface GitHub

  • En dix ans passés entre grands groupes et startups, j’ai observé un schéma récurrent
    startup → réponse aux clients enterprise → refonte complexe → idéalisme → recherche du profit → obésité produit → départ des ingénieurs clés → baisse de qualité
    Ce cycle se répète aussi chez les géants du cloud (AWS, Cloudflare, GCP, etc.)
    En interne aussi, chaque service est fragmenté en petites unités business qui fonctionnent avant tout selon une logique de rentabilité
    Au final, même l’infrastructure de base est affaiblie par la pression sur les marges
    L’idée que « AWS ou GCP sont trop gros pour tomber » me paraît dangereuse

    • D’accord. Dans la réponse aux besoins enterprise, il est inévitable que le produit devienne plus complexe et plus lourd
      Mais la dette technique et les problèmes de sécurité des startups au début étaient eux aussi très graves
      Au fond, il est naturel que les fissures d’un système apparaissent au cours d’une croissance à grande échelle

  • La page de statut de GitHub affiche encore la formule « certains utilisateurs peuvent rencontrer des problèmes »
    Pourtant, dans les faits, non seulement HTTPS mais aussi tous les push SSH échouent

    • On dirait que les responsables de la page de statut n’arrivent pas à sortir de cette formule « certains utilisateurs »
      Une communication transparente, plutôt que des euphémismes façon RP, renforcerait davantage la confiance
      D’autant que les mises à jour de la page de statut arrivent souvent en retard
    • Un ami m’a dit qu’il avait réussi à faire un push brièvement, mais pour la plupart des gens c’est toujours l’état erreur fatale