GitHub a vécu une dégradation multi-services à travers le 28-29 avril qui a mis GitHub Issues hors ligne pendant 20 heures 24 minutes, GitHub Pages hors ligne pendant 20 heures 24 minutes, pis GitHub Actions hors ligne pendant 14 heures 6 minutes, selon la propre page de statut de GitHub telle que suivie par StatusGator. Les rapports sur DownDetector ont surgé vers 9 h 05 CET le 28 avril. Le titre publié de l'incident, c'était « Incomplete pull request results in repositories. » La panne tombe dans la même semaine que GitHub a annoncé le passage à un tarif AI Credits à l'usage pour Copilot — ensemble, la semaine rend l'argument « ne dépendez pas d'un seul hôte git » plus facile à faire que depuis des années.
La durée compte plus que le déclencheur. Une panne de 20 heures sur Issues pis Pages, pis 14 heures sur Actions, ça met des grosses portions du flux de travail développeur hors ligne. Issues, c'est là où la gestion de bugs pis de projets vit pour la plupart des projets open source. Pages, c'est là où beaucoup de petits projets hébergent leur documentation pis leurs démos. Actions, c'est le substrat CI/CD sous le graphe de distribution de paquets de facto de la planète — quand Actions est en panne, les paquets sortent pas des pipelines canoniques, les pushes vers GitHub Container Registry échouent, pis n'importe quel projet qui a attaché son processus de release aux runners Actions arrête de releaser. Le titre racine unique — « Incomplete pull request results in repositories » — masque la cascade : les métadonnées liées aux PR alimentent les triggers Actions, qui alimentent les déploiements Pages, qui alimentent les flux de tickets Issues. Quand la couche de données des pull requests vacille, tout le graphe au-dessus vacille avec.
GitHub, c'est ce qui se rapproche le plus d'un point unique de défaillance dans l'écosystème développeur. Y a environ 200 millions de développeurs sur GitHub, pis une fraction non triviale du CI open source mondial roule sur GitHub Actions. L'histoire de fiabilité cette semaine, c'est inconfortable : une panne Issues de 20 heures, c'est pas un pépin de 20 minutes, pis la cause étant un problème de couche de données PR suggère que la défaillance était plus profonde que du bruit d'infrastructure. Combinée avec le reset de prix Copilot vers AI Credits annoncé le 28 avril, la semaine se lit comme « plateforme centrale avec des systèmes fragiles est aussi sur le point de te charger plus pour les fonctions IA. » Attendez-vous à un saut mesurable d'intérêt pour GitLab, Codeberg, Forgejo pis Gitea auto-hébergé dans les prochaines semaines. Le saut sera pas un exode de masse — les coûts de switching sont énormes — mais les mainteneurs de projets open source à fort trafic vont commencer à penser plus sérieusement aux mirrors pis aux fallbacks.
Pour les builders, trois choses à faire pour vrai. Premièrement, audite ta dépendance de processus de release sur GitHub Actions spécifiquement : si ton pipeline de release de paquet, de build de container ou de déploiement de doc tire seulement quand les runners Actions sont en santé, t'as un point unique de défaillance caché. Mirror sur un deuxième fournisseur de CI (CircleCI, Buildkite, GitLab CI, runners auto-hébergés) pour les jobs critiques, même si tu gardes le jour-le-jour sur Actions. Deuxièmement, fais du push-mirror de ton repo sur un deuxième hôte. Le setup de 90 secondes d'un remote sur GitLab ou Codeberg se rentabilise la première fois que GitHub Issues arrête d'accepter les écritures. Troisièmement, le reset de prix Copilot plus cette panne va rendre les « outils dev IA qui marchent hors ligne ou sur infrastructure alternative » un pitch plus convaincant — surveille les lancements de produits dans le prochain mois qui mènent avec « ton assistant de codage IA roule sur ton infrastructure, pas celle de GitHub. »