GitHub est de nouveau en panne : Mirrors, alternatives et comment rester en ligne

Si vous avez récemment tenté de pousser une branche, de lancer un pipeline CI ou d'installer un paquet pour tomber sur une page d'erreur, vous n'étiez pas seul. GitHub a connu ces derniers temps bien plus de pannes et de dégradations que d'habitude, et pour une plateforme au cœur du développement logiciel moderne, chaque minute de Downtime se fait sentir dans toute l'industrie.

Cet article n'est pas une charge. Avant tout, c'est un mot de remerciement. Et ensuite, parce que nous avons tous encore du travail à livrer, un guide pratique des alternatives à GitHub, des Git Mirrors et de ce qu'il faut faire pour que la prochaine panne n'arrête pas votre projet — et ne passe pas inaperçue auprès de vos utilisateurs.

Merci, GitHub

On oublie facilement à quel point une seule plateforme a changé les choses. GitHub a transformé l'hébergement de code en communauté et, depuis près de vingt ans, c'est le foyer par défaut de l'open source. Voici ce que nous tenons aujourd'hui pour acquis :

• Les pull requests et le code review social — le workflow qu'une génération entière de développeurs a appris sur GitHub.
• Un foyer pour des millions de projets — des expériences de week-end à l'infrastructure d'Internet.
• GitHub Actions, Pages et Packages — une chaîne d'outils complète qui faisait paraître les petites équipes énormes.
• Les effets de réseau — les étoiles, les issues, les discussions et la culture du README qui rendaient la découverte de logiciels agréable.

Rien de tout cela ne disparaît à cause de quelques mauvais jours. Les pannes arrivent à tout le monde ; plus une plateforme est réussie, plus le monde entier ressent ses mauvais jours. La réaction saine n'est pas la colère. C'est la gratitude — plus un plan B. Et honnêtement, GitHub rend ses mauvais jours faciles à suivre grâce à sa propre page de statut. Mais vous ne devriez pas avoir à la consulter vous-même.

Ce qui casse vraiment quand GitHub tombe

github.com a un mauvais jour, le rayon d'impact est plus grand qu'on ne le pense :

• Clone, push et pull requests — les bases quotidiennes s'arrêtent.
• Les pipelines CI/CD (Actions) — les builds s'accumulent ou échouent, les releases glissent.
• GitHub Pages — les sites de documentation et marketing s'éteignent.
• L'installation de paquets — les dépendances qui récupèrent des endpoints GitHub commencent à échouer.
• Les webhooks et intégrations — les événements sont retardés ou perdus, cassant discrètement l'automatisation.

Si votre processus de release, votre documentation ou votre produit touche à l'un de ces éléments, votre Uptime est désormais couplé à celui de GitHub. C'est un risque que vous pouvez vraiment réduire.

Les Git Mirrors : votre première ligne de défense

Un Git Mirror est une copie complète et continuellement mise à jour de votre dépôt sur un autre hôte. Un miroir n'est ni une migration ni une protestation — c'est de la redondance. Quand GitHub a un mauvais jour, votre historique, vos branches et vos tags vivent ailleurs.

1. Choisissez un second foyer. GitLab, Codeberg ou un Gitea ou Forgejo auto-hébergé fonctionnent très bien.
2. Poussez tout une fois : clonez avec git clone --mirror, puis lancez git push --mirror vers le nouveau remote.
3. Gardez-le synchronisé : soit ajoutez un second remote (git remote add mirror <url>) et poussez vers les deux, soit lancez git push --mirror depuis un job planifié — une entrée cron horaire suffit pour la plupart des équipes.
4. Ou laissez la copie s'entretenir elle-même : GitLab, Gitea et Forgejo peuvent créer des pull-mirrors depuis GitHub selon un calendrier, sans cron.
5. Vérifiez le miroir de temps en temps. Un miroir jamais testé est une fausse sensation de sécurité.

Un miroir ne vous donne pas un second CI ni un suivi d'issues, mais il protège ce que vous avez de plus précieux : votre code et son historique.

Les alternatives à GitHub à connaître

Vous n'avez pas besoin de quitter GitHub pour vous préparer à un jour de pluie. Connaître les alternatives — et y garder un miroir — c'est tout simplement du bon engineering. Chacune de ces plateformes a gagné une vraie confiance communautaire :

• GitLab — une plateforme DevOps complète avec CI/CD intégré, registre de conteneurs et un mirroring de dépôts de premier ordre dans les deux sens. Le plan B le plus naturel pour les équipes.
• Codeberg — une plateforme à but non lucratif gérée par la communauté, propulsée par Forgejo. Un foyer réellement indépendant pour le logiciel libre et open source.
• Sourcehut — minimal, rapide et orienté e-mail. Une approche rafraîchissante et sans fioritures des forges.
• Gitea et Forgejo — des forges open source légers que vous pouvez auto-héberger. Contrôle total, faible empreinte, support des miroirs intégré.
• Bitbucket — l'option Atlassian historique avec une intégration Jira profonde.

L'objectif n'est pas d'abandonner GitHub. C'est de pouvoir dire, en toute honnêteté, qu'on n'en a jamais été totalement dépendant.

Découplez ce que vous pouvez

Les miroirs protègent votre code. Mais le Downtime fait le plus mal quand tout le reste dépend du même hôte. Répartissez la charge :

• Documentation et landing pages — ne les servez pas uniquement depuis GitHub Pages. Hébergez-les comme les sites de production qu'elles sont.
• Paquets — publiez sur plus d'un registre, par exemple npm plus un registre privé ou une seconde plateforme.
• Releases — conservez les artefacts sur votre propre stockage ou CDN en plus des GitHub Releases.
• CI — un second pipeline sur GitLab ou vos propres runners peut prendre le relais quand Actions est down.
• Badges et liens profonds — si votre README ou votre site référence raw.githubusercontent.com, traitez cette URL comme une dépendance et surveillez-la comme telle.

Sachez-le avant vos utilisateurs

Apprendre une panne par les réseaux sociaux signifie que vous êtes en retard. La solution est ennuyeuse mais efficace : surveillez ce dont vous dépendez — GitHub lui-même, votre site Pages, vos endpoints de clone et bien sûr votre propre produit.

C'est exactement pourquoi nous avons construit isthisthing.online. Ajoutez des Monitors HTTP, TCP ou ping pour chaque saut entre vous et vos utilisateurs : github.com, api.github.com, votre URL GitHub Pages et vos endpoints de production. Les Checks s'exécutent depuis jusqu'à 10 emplacements mondiaux à des intervalles descendant jusqu'à 30 secondes, et les alertes arrivent dans Slack, Microsoft Teams, Discord ou n'importe où via Webhooks dès que quelque chose se dégrade.

Quand GitHub tombe, votre Monitoring vous dit en quelques secondes si c'est GitHub ou votre propre stack — ainsi vous basculez vers votre miroir, vous changez un enregistrement DNS ou vous cessez simplement de déboguer la panne de quelqu'un d'autre.

Et quand c'est vous qui avez un mauvais jour, une Status Page mise à jour automatiquement garde vos utilisateurs informés au lieu de les laisser rafraîchir votre boîte de support.

Une checklist de résilience pratique

1. Créez un miroir de chaque dépôt critique et gardez-le synchronisé.
2. Ajoutez un second pipeline CI à vos projets les plus importants.
3. Publiez les paquets et artefacts de release à plus d'un endroit.
4. N'hébergez pas documentation et pages marketing sur une seule plateforme.
5. Surveillez github.com, api.github.com, vos URLs Pages et vos propres endpoints avec des Checks rapides.
6. Acheminez les alertes vers Slack, Teams ou Discord pour que les bonnes personnes l'apprennent en premier.
7. Publiez une Status Page publique pour que vos utilisateurs n'aient jamais à deviner.
8. Répétez le failover une fois, avant d'en avoir vraiment besoin.

GitHub a bâti des décennies de goodwill, et quelques pannes ne changent rien à cela. Restez reconnaissant, restez en miroir — et restez surveillé.

Prêt pour la prochaine panne ? Créez votre compte isthisthing.online gratuit et transformez le prochain pépin de GitHub en pause de cinq minutes plutôt qu'en après-midi perdue.