GitHub est en train de couler
(dbushell.com)- Depuis le rachat par Microsoft, la disponibilité (uptime) de GitHub s’est nettement dégradée ; même la page d’état officielle affiche des chiffres inquiétants, et les pages d’état non officielles décrivent une situation encore plus grave
- Avec l’abus de Copilot et l’inondation de code médiocre généré par l’IA (slop), GitHub en vient à se DDoS lui-même ; les bots et l’économie des fausses étoiles sapent la confiance dans la plateforme
- Git est un système de gestion de versions distribué open source, qui fonctionne sans GitHub ; il faut donc cesser d’assimiler GitHub à Git lui-même
- Il existe de nombreuses forges Git alternatives comme Codeberg, Tangled, Gitea, GitLab ou Forgejo en auto-hébergement, et il faut commencer la migration immédiatement
- Plusieurs développeurs de premier plan publient coup sur coup des billets annonçant leur départ de GitHub, faisant de la sortie de cette dépendance à GitHub un enjeu pour l’ensemble de l’écosystème
Pourquoi il faut quitter GitHub
- GitHub est critiqué pour la baisse de sa disponibilité et de l’expérience utilisateur depuis son rachat par Microsoft, et l’on estime que la page d’état des incidents manquants montre une tendance plus dégradée que le statut officiel
- Le graphique GitHub’s Historic Uptime est utilisé pour montrer que la disponibilité moyenne mensuelle est devenue instable depuis le rachat par Microsoft
- Après le rachat de GitHub, Microsoft a multiplié les produits liés à Copilot, et GitHub subit au point de publier lui-même une mise à jour sur ses problèmes de disponibilité tant il est rongé par le « slop »
- Des billets récents se multiplient sur le départ de GitHub ou sur un retour aux pratiques de développement d’avant GitHub
Git ≠ GitHub
- GitHub est devenu synonyme de « gestion du code source », mais trop d’utilisateurs ignorent encore que Git n’est pas GitHub
- Git et GitHub ne sont pas la même chose, et la technologie centrale de Git est open source et distribuée ; tous les dépôts sont donc égaux et peuvent fonctionner sans service centralisé
- Les services centralisés sont le produit d’une commodité sociale ; GitHub n’était à l’origine qu’un outil complémentaire utile, que Microsoft a transformé en passif coûteux
- L’effet de réseau est puissant, mais l’économie des fausses étoiles de GitHub n’a aucune valeur, et la plateforme déborde de bots et de slop
- GitHub Actions fait partie de pipelines CI devenus excessivement complexes. Chercher d’autres solutions est fastidieux, mais il faut se demander si l’on peut encore faire confiance à la stabilité de GitHub
- Le navire est en train de couler ; même sans tout déplacer d’un coup, il faut engager la migration immédiatement
Alternatives et méthodes de migration
- La voie de sortie la plus proche consiste à passer à une autre forge Git centralisée ; il suffit de s’inscrire puis de pousser le dépôt vers un nouvel upstream
- Certains services peuvent automatiser la migration et prendre en charge l’import des issues, mais il est aussi possible de laisser les issues telles quelles sur GitHub
- Aucune des alternatives ci-dessous n’est parfaite ; leur seul point commun est de ne pas être GitHub
-
Alternatives de forges Git centralisées
- Codeberg — projet à but non lucratif et porté par la communauté, alternative sûre avec un historique éprouvé. C’est l’instance de référence de Forgejo
- Tangled — startup en phase alpha, dont l’intégration au protocole AT constitue une option intéressante. À envisager pour de petits projets personnels
- Gitea — propose un hébergement Git managé dans le cloud, et correspond au projet open source d’origine dont Codeberg/Forgejo est issu
- GitLab — de niveau entreprise, donc lourd et confus, mais potentiellement adapté à une prise de décision en organisation
- Bitbucket — non recommandé, mais entre tout de même dans la catégorie « pas GitHub »
- Game of Trees, Radicle, Sourcehut — autres alternatives à étudier directement
-
Auto-hébergement
- Les organisations comme les particuliers peuvent auto-héberger une forge Git et exploiter aussi les actions et les releases
- L’option d’auto-hébergement recommandée est Forgejo
- Il existe des discussions sur la fédération entre instances Forgejo, et Tangled a également publié un billet sur la fédération, mais cela ne semble pas près d’aboutir
- Si une collaboration publique est nécessaire, il reste possible de pousser une copie sur Codeberg
- Gitea et GitLab proposent également des options d’auto-hébergement, mais GitLab est nettement plus lourd
- Comme GitHub, les autres forges sont distinctes de Git lui-même, et l’on peut se demander si les fonctions annexes de la forge sont vraiment nécessaires
- Git peut être utilisé directement via SSH
git clone user@192.168.1.67:/path/to/repo
- La manière de collaborer est une question distincte, mais si Linux peut être maintenu en échangeant des patchs via des listes de diffusion par e-mail, il est difficile d’affirmer que ce serait impossible pour la seule raison de l’échelle
- Les forges Git centralisées peuvent constituer un compromis réaliste, mais il faut toujours avoir un plan de sortie en tête, en gardant à l’esprit qu’elles peuvent s’effondrer comme GitHub
2 commentaires
Vu les fonctionnalités proposées, c’est presque étonnant qu’ils en tirent plus de 99 %.
Réactions sur Hacker News
Tout le monde veut attribuer ça au rachat par Microsoft ou à l’incompétence, mais d’après les données publiées par GitHub, le volume de code commité sur GitHub a été multiplié par 10 à cause de l’IA, et il semble assez clair que les effets se répercutent partout, du CI à Actions en passant par la collecte de code
L’auteur pointe du doigt des éléments bizarres comme MS Copilot, mais on a plus l’impression d’une liste de choses qu’il n’aime pas que d’un véritable lien de causalité
Il ignore au contraire l’éléphant au milieu de la pièce : l’explosion du code provoquée par l’IA
OpenAI a sorti GPT-3.5 en novembre 2022, en pratique décembre, et le codage à base de grands modèles de langage / agents tel que décrit n’a vraiment décollé qu’en 2024, voire plutôt en 2025
Dans ce cas, comment expliquer la mauvaise disponibilité pendant environ 4 ans après le rachat, avant même qu’on commence à parler d’IA ?
C’est bien de critiquer Microsoft, mais il ne faut pas rater l’éléphant au milieu de la pièce
Même si un remplaçant parfait de GitHub apparaissait demain, qu’est-ce qui empêcherait des millions de lignes de code généré par l’IA de ruiner aussi son infrastructure ?
L’hébergement de code centralisé semble presque condamné par l’IA. Un peu comme ce qui arrive aux réseaux sociaux
10 ans, c’est long, et le résultat se voit
GitHub Actions, Copilot, et cette recherche IA hideuse qu’on ne peut même pas désactiver. Sans parler de la migration vers Azure
Microsoft a réussi à détruire les effets de réseau, et les incidents n’étaient que la goutte d’eau qui a fait déborder le vase
L’entreprise a d’énormes bases de code en interne et environ 200 000 employés
Surtout qu’elle a pris en toute connaissance de cause des décisions comme la gratuité des dépôts privés, donc ça tient difficilement comme excuse
Chaque fois que GitHub tombe, je me dis : « quelqu’un a dû mettre à jour le Windows Server qui fait tourner GH et il a fallu tout redémarrer »
Je suis sûr à 99 % que ce n’est pas vrai, mais cette idée me rassure et me fait même un peu rire à chaque panne
Aujourd’hui, je voulais consulter un dépôt sur GitHub
J’ai cliqué sur le lien « xxx commits » pour voir l’historique, et j’ai reçu un message disant d’attendre parce que j’avais atteint la secondary rate limit
Je suis la seule personne de ce réseau à consulter GitHub, et la connexion utilise une IP dédiée, pas du CGN
Ensuite, la page se charge normalement
En réalité, depuis des années, ce n’est plus une rate limit mais quasiment un refus par défaut, et ils refusent d’adapter le message à la réalité
« GitLab — “enterprise-grade” veut dire massif, confus, mais suffisamment impressionnant pour votre manager. Si son choix exige plusieurs réunions, c’est celui-là qu’il faut prendre.”
C’est drôle
Même pour les choses les plus simples, l’UI est trop compliquée. Par exemple, pour approuver une MR, il faut en pratique cliquer sur un bouton qui est en fait un menu, les diff sont pénibles à lire, et la “To-do list” contient même des MR déjà fusionnées. En quoi est-ce encore une tâche actionnable ?
Le problème des MR déjà fusionnées qui restent dans la “To-do list” a été signalé il y a des années, et pourtant ça n’a pas l’air d’avancer vite
À l’inverse, le rejet de Bitbucket me surprend un peu. L’UI est très simple et claire, et les nouveaux arrivants ont le même ressenti. Avec Script Runner, on peut faire des choses assez bluffantes, et il gère bien les très gros dépôts
GitLab n’est pas spécialement plus massif ou plus confus que GitHub
Et ce n’est même pas vraiment un logiciel enterprise-grade. Si c’est ça que vous cherchez, regardez Jira ou n’importe quoi produit par Microsoft
On utilise un GitLab auto-hébergé, et c’est moi qui l’ai choisi parce qu’il y a git et un registre de conteneurs
Si on n’utilise pas souvent l’UI web, l’interface peut effectivement sembler déroutante
Pour 5 dollars par mois, on peut héberger un serveur et y mettre plusieurs projets
Le dépôt n’aura pas un million d’étoiles, mais pour mes besoins ça fonctionne très bien, et je peux aussi donner l’accès à qui je veux
Je ne sais pas trop comment lire ce graphique
D’un côté, la disponibilité a peut-être empiré à cause du rachat de GitHub
D’un autre côté, voir la disponibilité d’avant rachat affichée à 100,00 % est suspect, et je me demande si ce n’est pas simplement la page de statut qui a commencé à être mieux mise à jour
Je sais qu’il y a récemment des problèmes de disponibilité sur GitHub, mais sur le graphique, le problème semble commencer en 2020 sans pour autant s’aggraver fortement
On a l’impression qu’il est impossible de laisser tranquilles les grands dépôts open source à long terme
Je me souviens de la dégradation de SourceForge, et voir la même chose arriver à GitHub est vraiment triste
Au passage, j’ai lu l’URL comme “dBus hell”. On est tous déjà passés par là
Je me demande souvent ce que je ferais si je dirigeais une entreprise
J’aimerais vraiment voir ce que donnerait un système où toutes les revues de code passent par e-mail
Les dépôts pourraient vivre sur un simple serveur type VPS avec accès SSH réservé à git, avec un espace de noms de branches
for-review/pour le code à relire, et le CI serait un bot qui attend l’apparition d’une branche puis ajoute un commentaire ou un tag sur la ref pour indiquer le résultat. Il pourrait aussi répondre dans le fil d’e-mailsLa mailing list pourrait évidemment avoir une interface d’archives web pour consulter les anciennes revues. Il existe déjà plein de solutions de ce genre, ce n’est que du HTML
Pour le chat, de l’IRC suffit, avec un bot pour archiver le canal. C’est ultra simple
Tout le système pourrait tourner sur des serveurs très bon marché, à part les runners de CI qui demanderaient du matériel plus costaud
GitHub est bien trop surconçu par rapport à ce qu’il faut réellement pour mener des projets logiciels. Regardez le noyau Linux : il fonctionne avec une simple mailing list, et il est difficile de contester que c’est l’un des projets logiciels les plus réussis de l’histoire
En revanche, le suivi des issues / bugs me fait un peu plus peur. J’aurais peur de me lancer à bricoler une solution et d’y consacrer plus d’énergie qu’au vrai métier de l’entreprise. Peut-être qu’il faudrait carrément devenir une société de logiciel de suivi de bugs ?
Autrement dit, je veux pouvoir voir exactement à quelle ligne un commentaire était attaché, quand cette ligne a été modifiée, et naviguer dans les deux sens
L’e-mail peut suffire comme protocole d’échange pour ces données, mais je ne pense pas que les clients mail soient une bonne manière de les visualiser
Il faudrait peut-être aussi un système de revue de code distribué
Vivre en Europe de l’Est a aussi ses avantages
Grâce au fuseau horaire, je remarque rarement les grosses pannes de GitHub
Et je suis satisfait de la générosité de l’offre en hébergement gratuit et en Actions
Depuis que j’ai installé Forgejo sur mon serveur à la maison, je n’ai pas regardé en arrière
Le seul problème, c’est quand on veut héberger des applications sur DigitalOcean App Platform, Vercel, etc., car ils ne se connectent qu’à GitHub
DigitalOcean App Platformprend en charge les déploiements non seulement depuis GitHub mais aussi depuis GitLabEn revanche, il faut utiliser l’instance hébergée sur gitlab.com, pas une instance GitLab auto-hébergée
Si vous avez déjà déployé votre propre forge auto-hébergée, vous pouvez utiliser gitlab.com comme passerelle vers DigitalOcean App Platform. Il suffit de créer un compte gitlab.com une fois, puis de faire envoyer un miroir par votre forge auto-hébergée vers gitlab.com. Pas vraiment besoin d’utiliser GitLab autrement
Malgré tout, c’est absurde que DigitalOcean, qui vend de l’IaaS/PaaS, ne permette pas de se connecter à une Forgejo auto-hébergée ou équivalent tournant sur sa propre infrastructure
Et quand on pense qu’il y a probablement beaucoup de gens qui veulent héberger leur propre forge sans pour autant vouloir la configurer et l’exploiter eux-mêmes, c’est aussi étrange que DigitalOcean n’intègre pas Forgejo ou une alternative pour proposer une option de déploiement semi-gérée en un clic à prix cassé, disons 20 dollars par an, avec une intégration de premier plan à App Platform
J’utilise DigitalOcean, mais uniquement pour des VPS
Il ne faut pas se rendre dépendant de ces couches intermédiaires propriétaires ; il vaut mieux garder le contrôle et viser des couches de stack aussi universelles que possible
J’ai migré vers Gitea il y a quelques années, avant le fork Forgejo, et je ne l’ai jamais regretté
Quand GitHub est nécessaire, j’ai pu faire fonctionner les choses en y mirroring mes dépôts. En revanche, synchroniser le code reste pénible
Si GitHub souffre, c’est parce que le nombre de commits a été multiplié par 14 au cours de l’année écoulée à cause du codage dopé à l’IA, et que le rythme accélère encore
Le site a du mal à suivre
Le COO de GitHub l’a confirmé ici : https://x.com/kdaigle/status/2040164759836778878
L’activité sur la plateforme explose. Il y a eu 1 milliard de commits en 2025, et maintenant on est à 275 millions par semaine, soit un rythme de 14 milliards sur l’année même si la croissance restait simplement linéaire. Bien sûr, elle ne s’arrêtera probablement pas là
GitHub Actions est passé de 500 millions de minutes par semaine en 2023 à 1 milliard de minutes par semaine en 2025, et cette semaine on est déjà à 2,1 milliards de minutes à l’heure actuelle
Ils poussent donc très fort sur davantage de CPU, l’extension des services et le renforcement des fonctions cœur de GitHub