GitHub Developer Exodus 2026 : faut-il vraiment partir ?

J'étais à mi-chemin de l'examen d'une pull request lorsque la notification X est arrivée. Mitchell Hashimoto – le gars qui a construit Vagrant, Terraform et Ghostty – retirait son projet de terminal de 50 000 étoiles sur GitHub. Il était l'utilisateur 1299 de GitHub depuis février 2008. Il avait ouvert le site, selon ses propres calculs, pratiquement tous les jours pendant plus de dix-huit ans.

J'ai lu son message deux fois. Ensuite, j'ai fermé le PR que j'examinais, ouvert un nouvel onglet et commencé à taper "GitHub alternatives 2026" dans une barre de recherche dans laquelle je n'aurais jamais pensé taper cette phrase.

Le fait est que je ne suis pas Mitchell Hashimoto. Je n'ai pas de projet à 50 000 étoiles. Je n'ai aucun effet de levier auprès de plusieurs « fournisseurs commerciaux et FOSS » prêts à m'héberger. Je suis un ingénieur en activité avec peut-être quarante repos actifs sur mejba.me, Ramlit Limited et une poignée de projets clients. Le calcul pour savoir si Je dois quitter GitHub n'est pas le même calcul que le sien.

Mais la question est devenue suffisamment forte cette semaine pour que je ne puisse pas l'ignorer. J'ai donc passé quatre jours à analyser les chiffres – à tester GitLab, Codeberg et SourceHut par rapport au workflows que j'utilise quotidiennement – et ce que j'ai trouvé m'a surpris. Pas parce que l’un d’eux est visiblement meilleur. Ce n’est pas le cas. La surprise est ce que révèle la comparaison sur ce que GitHub est réellement devenu en 2026, et sur le type spécifique de développeur qui devrait agir en ce moment par rapport au type spécifique qui devrait absolument rester sur place et simplement s'adapter.

C’est le message que j’aurais aimé que quelqu’un écrive avant de perdre un dimanche.

La semaine qui a brisé l'hypothèse « GitHub est éternel »

Vous connaissez déjà les gros titres. Permettez-moi de fixer un calendrier serré, car l'ordre compte plus que les incidents individuels.

23 avril 2026. Entre 16h05 UTC et 20h43 UTC, une régression dans la file d'attente de fusion de GitHub produisait silencieusement des validations de fusion incorrectes chaque fois qu'un groupe de files d'attente contenait plusieurs PR à l'aide de la méthode de fusion squash. Selon le propre incident report de GitHub, 2 092 demandes d'extraction sur 230 repositories ont été affectées. Le bug n'était pas un échec de disponibilité : les opérations Git ont continué à fonctionner, le API a continué à renvoyer des données, la page d'état est restée en grande partie verte. Le bug était que l'exactitude de la validation était cassée. Le code que les équipes pensaient avoir fusionné a été annulé lors des fusions ultérieures dans la même file d'attente. Il a fallu trois heures et trente-trois minutes à GitHub pour remarquer, car aucun moniteur automatisé ne surveillait « la fusion a-t-elle réellement fait ce qu'elle avait dit ? ».

Relisez ce paragraphe si vous en avez besoin. Une plate-forme de contrôle de version a brièvement arrêté le suivi fiable des versions.

27 avril 2026. Le cluster Elasticsearch de GitHub (le sous-système qui alimente les vues de liste PR, la recherche de problèmes, les filtres du tableau de bord de projet et la plupart de l'interface utilisateur sur laquelle vous cliquez réellement) a été submergé. Le CTO de GitHub l'a publiquement décrit comme une attaque de botnet s'ajoutant au trafic organique avec lequel le cluster était déjà aux prises. Pendant des heures, les données sous-jacentes étaient correctes, mais l'interface qui trouve les données a menti aux développeurs. Les gens accusaient leurs coéquipiers de supprimer un travail qui n'avait pas été supprimé. Les équipes ont organisé des réunions en partant du principe que les PR qu'elles ne pouvaient pas voir n'existaient plus.

28 avril 2026. Trois choses se sont produites au cours du même cycle d'actualité. GitHub a publié des excuses publiques en matière de fiabilité, faisant basculer l'entreprise vers une position « La disponibilité d'abord ». Wiz Research a divulgué CVE-2026-3854 — un RCE critique CVSS 8.7 qui permet à tout utilisateur authentifié d'exécuter du code à distance sur le backend de GitHub avec un seul git push, en injectant des données non nettoyées dans l'en-tête interne X-Stat. Et Mitchell Hashimoto a publié "Ghostty quitte GitHub".

Trois échecs, trois couches différentes de la pile, une semaine. Ce sont les données.

Mais voici la partie qui ne figurait pas sur la première page de Hacker News : La disponibilité surveillée par un tiers de GitHub est tombée en dessous de 90 % en 2025 et a encore diminué jusqu'en avril 2026, atteignant environ 86 % pour le mois. AWS S3, pour le contexte, fonctionne sur un objectif de conception « onze neuf » : 99,999999999 %. La page de statut public de GitHub a continué à revendiquer un taux supérieur à 99 % tout le temps. Cet écart, entre ce que la page d'état reports et ce que les développeurs ont réellement vécu, est ce qui érode la confiance plus rapidement que n'importe quelle panne unique.

Lorsque le développeur solo le plus respecté du monde open source déclare qu’une plateforme n’est « plus un endroit pour un travail sérieux », le reste d’entre nous doit au moins faire le calcul.

Ce que j'ai réellement testé (et le verdict honnête)

Avant de me lancer dans le comparatif, voici la règle que je me suis donnée : je n'allais évaluer aucune plateforme à partir de sa page marketing. Je migrerais un vrai projet vers chacun, j'exécuterais mon workflow réel dessus pendant une journée et j'écrirais ce qui s'est cassé.

Le projet que j'ai choisi était un projet parallèle privé de Laravel avec environ 240 commits, des actions GitHub pour CI, deux PR ouverts, trois jalons, douze problèmes et un fichier CODEOWNERS. Pas un jouet. Pas non plus un monstre de 50 000 étoiles. C’est à peu près la forme du travail que font réellement la plupart des lecteurs de ce site.

Voici ce qui s'est passé.

GitLab : la migration sécurisée qui n'est pas tout à fait sécurisée

GitLab est le premier arrêt évident. C'est la plate-forme avec laquelle chaque liste "GitHub alternatives 2026" mène, et la raison est simple : c'est le seul concurrent avec une surface de fonctionnalités comparable. CI/CD, suivi des problèmes, registre de conteneurs, registre de packages, analyse de sécurité, le tout regroupé dans un seul produit au lieu d'être assemblé entre les actions, packages, Dependabot et sécurité avancée GitHub.

J'ai migré le projet Laravel vers GitLab.com (le SaaS, non auto-hébergé) à l'aide de leur importateur GitHub intégré. Temps total entre le clic sur « importer » et l'affichage de mon repo avec tous les PR, problèmes et jalons intacts : environ onze minutes. L'importateur a apporté :

Historique complet de Git (évidemment)
Problèmes avec les étiquettes et les jalons
Demandes d'extraction en tant que demandes de fusion
Configuration CI/CD (avec réécritures — .github/workflows/*.yml ne fonctionne pas sur GitLab ; vous avez besoin d'un .gitlab-ci.yml)
Règles de protection des branches (réappliquées manuellement)
Webhooks (il a fallu recréer)

La réécriture de CI représentait le coût réel. Mes actions GitHub workflow ont exécuté PHPUnit, exécuté Pint pour le formatage, exécuté une analyse statique via Larastan et déployé un environnement de prévisualisation sur un Hetzner VPS. Traduire cela en GitLab CI m'a pris environ quatre-vingt-dix minutes, principalement parce que le bloc services: de GitLab pour faire tourner un conteneur MySQL est vraiment plus agréable que celui de GitHub, mais la syntaxe rules: pour les tâches conditionnelles est plus détaillée. Vous ne pouvez pas copier-coller ; il faut réfléchir.

Ce que GitLab fait mieux que GitHub en ce moment, point final, c'est l'intégration DevOps de première partie. Si vous êtes une startup qui souhaite une plate-forme pour le code, le CI, le registre de conteneurs, le registre de packages et l'analyse de sécurité, et que vous l'assembleriez autrement à partir de GitHub et de trois autres fournisseurs, GitLab est le pari le plus propre. L'histoire tout-en-un est réelle.

Le problème – et c'est le problème que personne ne signale assez fort – est que GitLab.com a connu sa propre panne importante en 2025 et fonctionne sur la même pression de mise à l'échelle fondamentale que GitHub. Migrer d'un grand hôte SaaS Git vers un autre grand hôte SaaS Git parce que vous vous inquiétez de la fiabilité est, charitablement, une stratégie incomplète. Vous avez modifié votre point de défaillance unique, mais vous ne l'avez pas supprimé.

La version de GitLab qui résout réellement le problème de fiabilité est GitLab auto-hébergé – soit l'édition communautaire gratuite, soit le niveau Premium payant. C'est une conversation différente. C'est un travail d'administrateur système. C'est un serveur qui a besoin de correctifs, de sauvegardes, d'un certificat SSL, d'un relais SMTP et d'un runbook pour le jour où il tombe en panne à 2 heures du matin. Si vous êtes seul ou en petite équipe, la taxe opérationnelle dépasse généralement le gain de fiabilité.

Verdict GitLab : Un véritable concurrent du GitHub en termes de fonctionnalités. Un concurrent discutable de GitHub sur la fiabilité si vous restez sur GitLab.com. Une véritable fiabilité ne joue que si vous vous auto-hébergez - et l'auto-hébergement est un travail, pas une case à cocher.

Codeberg : Celui qui m'a surpris

Codeberg est la plateforme que je m'attendais à rejeter dans vingt minutes. Je suis sorti du test en le prenant plus au sérieux que tout ce que j'avais évalué.

Contexte rapide : Codeberg est une organisation allemande à but non lucratif qui gère une instance de Forgejo, un soft fork de Gitea géré par la communauté. Il n'y a pas d'investisseurs, pas de publicité, pas de feuille de route d'entreprise, pas de fonctionnalités AI boulonnées sur le dessus, pas de poussée "agent workflow" gonflant artificiellement la charge. Il est financé par des dons. Sa philosophie est explicite : être un foyer sûr pour les logiciels libres et open source. Il est hébergé dans l'UE sous une fondation, ce qui compte discrètement mais énormément si vous êtes exposé à GDPR.

J'ai importé le projet Laravel – enfin, un fork convivial de celui-ci. Les propres conditions de Codeberg vous demandent d'héberger principalement des œuvres sources gratuites de /open, ce qui constitue la bonne limite pour une organisation à but non lucratif financée par des dons. L'importation a duré environ sept minutes. L'interface est incontestablement "GitHub vers 2018" - et je dis cela comme un compliment. Vue PR, vue des problèmes, vue des jalons, recherche de code, le tout immédiatement lisible. Aucune suggestion AI. Pas de vente incitative de Copilot. Pas de flux « explorer » conçu pour vous maintenir sur le site.

Le système CI de Forgejo, Forgejo Actions, est compatible API avec GitHub Actions. Mon .github/workflows/ci.yml fonctionnait avec deux modifications mineures : une étiquette d'exécution renommée et une action que j'avais extraite du marché GitHub a dû être remplacée par un équivalent publié dans le propre registre d'actions de Codeberg. Environ quarante-cinq minutes de travail pour se mettre au vert.

Voici la partie qui m'a fait asseoir. La semaine du 23 au 28 avril, alors que GitHub était visiblement en difficulté, la page d'état de Codeberg indiquait des opérations normales sur chaque composant. Ce n'est pas une affirmation fantaisiste, c'est un avantage structurel. Codeberg n'est pas une cible pour les mêmes botnets à la même échelle, n'est pas martelé par la même charge agentique AI workflow, n'essaie pas de multiplier par 30 son infrastructure pour suivre le trafic synthétique. La plate-forme est suffisamment petite pour rester fiable, contrairement aux géants actuels.

Les limites honnêtes : Codeberg n'est intentionnellement pas destiné aux travaux propriétaires à code source fermé. Les minutes CI disponibles sont conservatrices car quelqu'un fait un don pour les conserver. Il n'existe pas de graphe social de style LinkedIn qui stimule la découverte. Si la stratégie de croissance de votre projet dépend de la page « Tendances » de GitHub, vous ne pouvez pas la reproduire ici.

Verdict Codeberg : Si vous expédiez des logiciels open source, notamment dans l'UE, notamment en tant qu'individu ou petite équipe, il s'agit de l'objectif de migration le plus sous-estimé en 2026. Il ne s'agit pas d'un remplacement de GitHub. C'est quelque chose de mieux dans les dimensions spécifiques pour lesquelles GitHub a cessé d'être bon : silencieux, fiable, appartenant à la communauté qu'il dessert.

SourceHut : Celui conçu pour l'ingénieur que vous n'êtes probablement pas

SourceHut est la plateforme la plus avisée que j'ai testée. Drew DeVault l'a construit sur une thèse claire : la plupart de ce qui rend l'hébergement Git moderne « puissant » est en fait du bruit, et un workflow piloté par courrier électronique et sans JavaScript est plus rapide pour le développement logiciel sérieux que n'importe quelle alternative lourde en interface utilisateur. Le prix commence gratuitement ; les niveaux payants coûtent environ 20 $ à 50 $ /year selon l'utilisation.

Je vais être honnête avec vous. J'ai importé le projet Laravel, exécuté le workflow pendant une journée et abandonné vers la sixième heure.

Pas parce que SourceHut est mauvais. Parce que SourceHut est conçu pour un workflow que je n'utilise pas réellement. La révision du code sur SourceHut s'effectue via les listes de diffusion et git send-email. Le suivi des bugs s'effectue via un tracker délibérément spartiate. CI fonctionne via builds.sr.ht et est véritablement rapide et propre. Mais le delta culturel – passer de l’évaluation basée sur PR à l’évaluation des correctifs par e-mail – est énorme. Les responsables du noyau Linux l'adorent. La plupart d’entre nous, moi y compris, avons construit une décennie de mémoire musculaire en cliquant sur « Approuver » dans une interface Web.

La plate-forme elle-même est impeccablement conçue. Chaque page s'affiche en moins d'une seconde. Il n'y a aucun JavaScript nulle part. La transparence du responsable sur les coûts et les décisions d'infrastructure est quelque chose que personne d'autre dans cet espace n'égale. Si vous êtes le genre de développeur qui exécute mutt pour le courrier électronique et considère un bouton d'interface utilisateur comme une insulte personnelle, SourceHut est la plateforme qui récompense enfin votre esthétique.

Verdict SourceHut : Ce n'est pas une alternative à GitHub pour la plupart des équipes. Un paradigme différent pour le sous-ensemble spécifique de développeurs qui souhaitent réellement un correctif par courrier électronique workflows. Respectez la philosophie, mais soyez honnête quant à savoir si vous êtes réellement cet ingénieur.

Les mathématiques de la migration que personne ne vous montre

Voici où je veux rompre avec chaque liste des « meilleures alternatives GitHub » que vous avez lu cette semaine.

La plupart d’entre eux s’arrêtent à la comparaison des fonctionnalités. La comparaison des fonctionnalités est la partie facile. La comparaison des fonctionnalités ne prend pas en compte le coût réel de quitter GitHub, et si vous ne fixez pas ce coût honnêtement, soit vous migrerez quand vous ne devriez pas, soit vous resterez quand vous ne devriez pas.

Voici le vrai calcul.

Ce que GitHub vous offre réellement au-delà de l'hébergement

Lorsque vous hébergez sur GitHub, vous ne payez pas pour que git push fonctionne. git push fonctionne sur un VPS à 5 $ avec un repo nu et une clé SSH. Vous payez – explicitement avec les dollars d'abonnement, implicitement avec vos données – pour une pile de services interconnectés dont la plupart n'ont aucun remplacement sur Codeberg, SourceHut ou même GitLab.

Découverte et contributeurs entrants. La page « Tendances », le graphique d'exploration, la preuve sociale des étoiles et des fourchettes, la recherche native GitHub qui permet à un étranger de tomber sur votre projet — ce sont des atouts commerciaux énormes pour tout responsable open source, et ils ne migrent pas. Mitchell Hashimoto peut déplacer Ghostty de GitHub car Ghostty est déjà célèbre. Un nouveau projet essayant de construire un public ne le peut pas.

CI/CD ubiquité. GitHub Actions est devenu la cible d'intégration de déploiement de facto pour chaque fournisseur de cloud, chaque registre de packages, chaque outil de version. AWS publie des actions. Cloudflare publie des actions. Vercel publie Actions. Il n’est pas impossible de reproduire cette surface d’intégration ailleurs, mais c’est rarement clé en main.

L’écosystème du marché. Actions tierces, applications GitHub, couche d'intégration : rien de tout cela n'existe avec la même densité ailleurs. Si votre workflow dépend de cinq actions Marketplace, la migration signifie la reconstruction ou le remplacement de cinq intégrations.

Recrutement et identité. Votre profil GitHub est, pour de nombreuses entreprises, votre CV. Votre graphique de contribution est un identifiant. Votre nom d'utilisateur est une marque. Rien de tout cela n’est transféré proprement vers une nouvelle plate-forme – et l’effet de réseau ne circule que dans un sens.

La feuille de calcul du coût de la migration

Voici la feuille de travail que j’aurais aimé avoir dimanche matin. Exécutez votre projet avant de prendre une décision dans un sens ou dans l'autre.

1. Temps de migration du dépôt. Pour un projet avec moins de 500 commits et problèmes standard /PRs : environ 30 minutes par repo pour l'importation seule. Multipliez par votre nombre repo.

2. Temps de réécriture du CI. GitHub Actions vers le CI GitLab : budget de 1 à 3 heures par workflow non trivial. Actions GitHub pour les actions Forgejo sur Codeberg : budget de 30 à 90 minutes par workflow. Actions GitHub sur les builds SourceHut : prévoyez une demi-journée par workflow si vous n'en avez jamais écrit auparavant.

3. Webhook et recâblage de l'intégration. Chaque service externe qui publie sur votre repo (Slack, Discord, hooks de déploiement, vérifications de statut) doit être reconfiguré. Prévoyez 15 minutes par intégration, plus si le format du webhook de la nouvelle plateforme diffère.

4. Protection des succursales et autorisations des équipes. Rien de tout cela ne migre automatiquement. Auditer et recréer. Prévoyez environ 2 heures pour une configuration d'équipe typique.

5. Mises à jour de la documentation. Chaque badge README, chaque lien wiki, chaque document externe indiquant « retrouvez-nous sur GitHub ». C’est un travail peu glamour qui prend plus de temps que vous ne le pensez.

6. Le coût du contributeur. Si vous avez des contributeurs externes, ils doivent également migrer. Certains ne le feront pas. Vous perdrez une certaine vélocité des contributeurs pendant au moins le premier trimestre suivant la migration. Tenez compte de cela dans votre décision.

7. Le coût de recrutement et de visibilité. Si votre projet gagne des contributeurs via la découverte, l'effet réseau de GitHub s'inscrit dans votre stratégie de croissance. Partir signifie reconstruire ce pipeline quelque part avec des effets de réseau plus faibles.

Pour ma configuration personnelle /work de quarante repo, mon estimation honnête de quitter complètement GitHub s'est soldée par environ 60 heures de travail d'ingénierie ciblé plus une suite de plusieurs mois de petites réparations. C'est un vrai chiffre. Une fraction significative d'un quart de productivité, échangée contre une quantité inconnue de fiabilité future.

Pour une startup de vingt ingénieurs, multipliez cela par le nombre de repos et d'intégrations et vous obtenez un projet d'un mois avec un coût d'opportunité réel. Pour un projet public de 50 000 étoiles comme Ghostty, c'est encore plus grand, sauf que Hashimoto a le pouvoir de négocier avec les fournisseurs et la marque pour que les contributeurs restent attentifs tout au long de la transition.

Pour la plupart des lecteurs de cet article : le coût de migration est supérieur au coût de fiabilité nécessaire pour rester pendant la récupération de GitHub, sauf si l'une des trois conditions spécifiques est vraie.

Quand vous devriez réellement migrer (et quand vous ne devriez pas)

Après avoir exécuté les calculs sur le vrai workflows, voici le framework que j'utilise personnellement et que je recommande aux clients.

Migrez maintenant si :

Votre travail dépend de l'exactitude de la file d'attente de fusion pour le monorepos à haute vitesse. L'incident du 23 avril a spécifiquement rompu l'exactitude de la validation dans les files d'attente. Si votre équipe fusionne des dizaines de PR par jour via des files d'attente automatisées et que vous ne pouvez pas tolérer ne serait-ce qu'une faible probabilité de retours silencieux, l'écart de confiance est trop grand pour attendre. Les trains de fusion de GitLab ou une alternative auto-hébergée constituent des couvertures raisonnables.

Vous avez une exposition GDPR ou des exigences de souveraineté des données de l'UE et vous avez traité "GitHub convient pour cela" comme une hypothèse de travail que vous n'avez pas réellement examinée. Codeberg ou Forgejo auto-hébergé sur l'infrastructure de l'UE clarifie votre histoire de conformité d'une manière que GitHub complique désormais activement.

Vous exécutez GitHub Enterprise Server. C'est celui pour lequel je pense sincèrement que vous devriez agir aujourd'hui, pas le trimestre prochain. CVE-2026-3854 a affecté environ 88 % des instances GHES au moment de leur divulgation. Si vous n'avez pas encore effectué la mise à niveau vers GHES 3.19.3 ou version ultérieure, c'est votre premier pas, quelle que soit la question de migration. La chaîne RCE – injecter un faux rails_env, rediriger le répertoire du hook, installer un hook de pré-réception, obtenir l'exécution du code en tant qu'utilisateur git – est suffisamment simple pour que l'exploitation dans la nature soit une question de moment et non de si.

Rester (avec ajustements) si :

Vous êtes un développeur solo ou une petite équipe exécutant workflows standard basé sur PR sur repos public pour plus de visibilité. Le coût de migration est réel, le coût de découverte est important et la plupart des échecs récents de GitHub n'ont pas réellement cassé Git lui-même. Ils ont brisé la couche d'interface utilisateur qui trouve votre travail. La bonne décision consiste à se protéger contre les défaillances de la couche d'interface utilisateur (utilisez gh CLI, créez un script pour parcourir l'interface utilisateur Web, mettez en miroir repos critique ailleurs comme sauvegarde à froid) plutôt qu'une migration complète.

Votre entreprise dépend d'intégrations natives GitHub telles que Copilot, Advanced Security ou des actions de marché spécifiques que vous ne pouvez pas facilement remplacer. Évaluer honnêtement la perte d’intégration pousse souvent « migrer » vers « pas encore ».

Vous exécutez un projet dont la croissance dépend de la découverte de contributeurs entrants. Vous utilisez l'effet de réseau de GitHub même si vous n'y pensez pas de cette façon. Ne le sous-évaluez pas.

La pièce hybride que je fais actuellement

Pour mon propre travail, je ne migre pas. Je refère. Chacun de mes repo qui compte dispose désormais d'un miroir nocturne automatisé sur un compte Codeberg privé. Si GitHub connaît une autre mauvaise semaine, j'ai une deuxième copie fonctionnelle. Si GitHub n'a jamais eu une autre mauvaise semaine, j'ai passé environ trois heures sur l'automatisation du miroir et j'ai obtenu une sauvegarde hors plate-forme qui est de toute façon une bonne pratique.

La configuration comprend environ trente lignes de bash plus une tâche cron. Codeberg accepte les push de n'importe quel client Git standard, de sorte que la configuration du miroir est identique à celle de n'importe quelle autre télécommande. J'utilise git push --mirror selon un planning, avec des informations d'identification dans un coffre-fort distinct de mes informations d'identification GitHub. Le tout est le genre de redondance à faibles enjeux que vous auriez aimé construire avant d’en avoir besoin. (Si vous avez déjà investi dans un [Claude Code workflow pour le développement piloté par terminal] (https://www.mejba.me/ghostty-terminal-claude-code-workflow), le câbler en tant que tâche en arrière-plan planifiée est une tâche de 20 minutes.)

Ce que cela dit sur la destination de l'infrastructure des développeurs

Je veux conclure sur la partie qui est plus grande que n'importe quelle plate-forme individuelle.

Le CTO de GitHub a décrit la courbe de charge frappant la plate-forme comme un « développement agent workflows » arrivant « comme un buffet gratuit ». Cette phrase m’est restée toute la semaine. Il n'a pas tort. Chaque agent Claude Code, chaque exécution de Codex, chaque tâche en arrière-plan du curseur, chaque pipeline autonome que vous et moi exécutons en 2026 atteint le API de GitHub plus qu'un humain ne le ferait jamais. Nous sommes, collectivement et accidentellement, le fardeau qui l’a brisé.

L'architecture que GitHub utilisait en 2024 était dimensionnée pour les développeurs humains. L'architecture dont elle a besoin en 2026 est dimensionnée pour les agents et les humains, et l'écart entre ces deux chiffres s'avère être d'environ 30x. C’est l’objectif de mise à l’échelle auquel l’entreprise s’est désormais publiquement engagée. C'est un énorme projet d'ingénierie. Qu’ils l’atteignent dans douze ou trente-six mois, c’est la vraie question qui détermine si les incidents d’avril 2026 étaient un point douloureux de transition ou le début d’un déclin à plus long terme.

Ce qui est également vrai, c'est que la même poussée agentique de workflow modifiant la courbe de charge de GitHub modifie ce que les développeurs apprécient dans un hôte Git. Nous nous soucions davantage de la fiabilité de API que de la finition de l'interface utilisateur, davantage de l'accès programmatique que des fonctionnalités sociales, davantage des coûts prévisibles que des listes de fonctionnalités d'entreprise. Codeberg et SourceHut, par accident ou par conception, ont été conçus pour ce public des années avant que celui-ci n'existe à grande échelle. Leur moment est maintenant. Si vous [créez des agents AI qui frappent continuellement les API de contrôle de version] (https://www.mejba.me/anthropic-agent-sdk-guide), l'hôte que vous choisissez est une décision lourde, comme ce n'était pas le cas il y a deux ans.

La chose dont je suis le plus sûr, après cette semaine : l'ère où « GitHub » était synonyme de « où vit le code » touche à sa fin. Ce n’est pas parce que GitHub s’effondre : Microsoft dispose du capital, des ingénieurs et des raisons stratégiques pour résoudre ce problème. Mais parce que l’hypothèse de l’inévitabilité a disparu. Nous avons vu le développeur solo le plus visible de l'open source faire ses valises et partir. Nous avons vu l'entreprise elle-même admettre publiquement que sa disponibilité est inférieure à 86 %. La valeur par défaut est fissurée, et une valeur par défaut fissurée est un autre type de défaut.

Vous n'êtes pas obligé de partir. Je ne pars pas. Mais revenir en somnambule à l’hypothèse selon laquelle GitHub est la seule option sérieuse pour héberger du code en 2026 est une chose qu’aucun de nous ne peut plus faire. La question est enfin de nouveau sur la table – et c’est cela, plus que n’importe quel incident individuel, qui a changé ce mois-ci.

Voici donc les devoirs. Au cours des sept prochains jours, réglez une minuterie d'une heure. Choisissez la feuille de calcul plus tôt dans cet article. Exécutez-le sur un de vos projets qui compte vraiment. Juste un. Découvrez quel serait le coût réel de la migration pour vous, sur votre code, avec vos intégrations.

Vous ne bougerez probablement pas. Mais vous ne serez plus jamais obligé de prendre cette décision dans des conditions de panique, comme ont fini par le faire la moitié des responsables de l'ingénierie avec qui j'ai parlé cette semaine. C'est la vraie victoire. Pas la migration. La clarté.

Questions fréquemment posées

GitHub est-il en panne en ce moment ?

GitHub est généralement disponible mais fonctionne en deçà de ses objectifs de fiabilité historiques : la surveillance tierce place la disponibilité d'avril 2026 à environ 86 %, bien en dessous du récit de la page d'état de la plate-forme. Des incidents spécifiques survenus le 23 avril (corruption de la file d'attente de fusion) et le 27 avril (panne de recherche d'Elasticsearch) ont provoqué des perturbations de plusieurs heures. Pour connaître l'état en temps réel, consultez les moniteurs tiers plutôt que la page d'état officielle.

GitLab est-il réellement plus fiable que GitHub ?

Pas catégoriquement. GitLab.com fonctionne sur la même pression de mise à l'échelle SaaS que GitHub et a connu ses propres pannes importantes en 2025. GitLab est plus fiable que GitHub uniquement si vous vous auto-hébergez, ce qui échange les gains de fiabilité contre le coût opérationnel de l'exploitation de votre propre serveur. Pour la plupart des équipes, changer de fournisseur SaaS ne résout pas la question sous-jacente de la fiabilité.

Qu'est-ce que Codeberg et est-ce une véritable alternative à GitHub ?

Codeberg est une organisation allemande à but non lucratif qui gère Forgejo, une plateforme Git gérée par la communauté. Il s’agit d’une véritable alternative aux projets libres et open source, notamment face aux besoins de souveraineté des données de l’UE. Ce n'est intentionnellement pas adapté aux travaux propriétaires à code source fermé. CI est compatible API avec les actions GitHub, et la plateforme est restée pleinement opérationnelle lors des incidents de GitHub en avril 2026.

Dois-je migrer mon repos privé hors GitHub dès maintenant ?

Probablement pas, sauf si vous appartenez à l'un des trois compartiments : monorepos à haute vitesse en fonction de l'exactitude de la file d'attente de fusion, exigences de souveraineté GDPR/EU ou instances de serveur d'entreprise GitHub qui n'ont pas encore corrigé CVE-2026-3854. Pour la plupart des développeurs solo et des petites équipes, le coût de la migration dépasse le coût actuel de la fiabilité. Une solution intermédiaire plus intelligente consiste à mettre en miroir le repos critique sur un deuxième hôte en tant que sauvegarde à froid.

Qu'est-ce que CVE-2026-3854 et est-ce que cela m'affecte ?

CVE-2026-3854 est une vulnérabilité d'exécution de code à distance CVSS 8.7 divulguée par Wiz Research le 28 avril 2026, exploitable par tout utilisateur authentifié via un seul git push avec des options push spécialement conçues. GitHub.com a été corrigé en mars 2026 : aucune action n'est requise pour les utilisateurs du cloud. Les utilisateurs de GitHub Enterprise Server doivent effectuer une mise à niveau vers GHES 3.19.3 ou version ultérieure ; on estime que 88 % des instances GHES étaient encore vulnérables au moment de la divulgation.

Travaillons ensemble

Vous cherchez à créer des systèmes AI, à automatiser workflows ou à faire évoluer votre infrastructure technologique ? J'aimerais aider.

Fiverr (versions et intégrations personnalisées) : fiverr.com/s/EgxYmWD
Portefeuille : mejba.me
Ramlit Limited (solutions d'entreprise) : ramlit.com
ColorPark (conception et image de marque) : colorpark.io
xCyberSecurity (services de sécurité) : xcybersecurity.io