Blog

Ghostty quitte GitHub : Implications pour les créateurs d'outils de développement

Ashley Innocent

Ashley Innocent

30 April 2026

Ghostty quitte GitHub : Implications pour les créateurs d'outils de développement

Le 28 avril 2026, Mitchell Hashimoto a annoncé que Ghostty, son émulateur de terminal open-source, quitte GitHub. Il est l'utilisateur GitHub 1299. Il a rejoint la plateforme en février 2008. Il a utilisé la plateforme presque tous les jours pendant plus de 18 ans. Rien de tout cela n'a compté le jour où il a écrit l'article ; il tenait déjà un journal des pannes "presque tous les jours il y a un X", et une défaillance de GitHub Actions le jour de l'annonce a bloqué ses révisions de PR pendant deux heures. Son verdict a été direct : "Ce n'est plus un endroit pour un travail sérieux si cela vous bloque des heures par jour, tous les jours."

Si vous créez des outils pour développeurs, c'est l'annonce à lire deux fois. Hashimoto n'est pas un utilisateur occasionnel de GitHub ; il a cofondé HashiCorp en s'appuyant sur GitHub, a livré Terraform, Vagrant, Vault, Consul et Boundary par son intermédiaire, et est l'utilisateur GitHub 1299. Lorsqu'un tel profil d'utilisateur abandonne la plateforme de développement dominante sur Terre, l'histoire est plus grande qu'un simple émulateur de terminal choisissant une nouvelle demeure. C'est un signal concernant la fiabilité, le verrouillage ("lock-in"), et le coût de la création d'un outil dont d'autres développeurs dépendent chaque jour. Cet article décortique ce que Hashimoto a dit, ce que cela signifie pour quiconque livre des outils pour développeurs, et les modèles qui protègent votre propre pile du même piège.

Pour un contexte plus large sur la façon dont les outils de développement de l'ère de l'IA transforment le flux de travail natif de GitHub, consultez comment écrire des fichiers AGENTS.md et l'utilisation et la facturation de l'API GitHub Copilot pour les équipes. Pour la perspective d'une équipe sur l'automatisation face aux lacunes de fiabilité de GitHub, consultez l'article sur le bot de triage Clawsweeper.

button

TL;DR

Ce que Hashimoto a dit dans l'article

L'article d'annonce est court, ce qui fait partie du message. Il n'y a pas de manifeste, pas de pique à Microsoft, pas de publicité pour une forge alternative. Hashimoto présente la chronologie simplement : il a commencé à tenir un journal des pannes de GitHub, le journal s'est rempli plus vite qu'il ne l'avait prévu, et le matin où il a écrit l'article, une défaillance de GitHub Actions l'a empêché de réviser les PRs pendant deux heures. Il a conclu que la plateforme n'est plus suffisamment fiable pour le type de travail qu'il effectue sur Ghostty.

Les chiffres entourant l'annonce méritent d'être précisés. Le 27 avril 2026, la veille de l'article de Hashimoto, une panne majeure de GitHub a affecté les Actions, les packages et la surface de l'API. Le journal qu'il mentionne dans l'article est antérieur à cette panne ; il suit ce modèle depuis des mois. Il présente le déménagement comme quelque chose qui a été planifié discrètement, et non comme une réaction à une seule mauvaise journée. La panne du 27 avril a précipité le moment, mais pas la décision.

Il est également explicite quant aux limites. Ghostty part ; ses autres projets restent sur GitHub pour l'instant. Le dépôt Ghostty restera un miroir en lecture seule à l'URL actuelle ; une nouvelle forge hébergera le développement actif, y compris les problèmes, les demandes de tirage (pull requests) et le CI. Il est en pourparlers avec plusieurs fournisseurs, commerciaux et FOSS, et ne s'est pas encore engagé sur une destination. La migration se fera de manière incrémentale, et non en un seul jour.

L'omission en dit autant que les mots. Hashimoto ne mentionne pas les fonctionnalités, les prix ou l'orientation du produit. La plainte est que la surface dont il dépendait cesse de répondre pendant des heures, et un projet qui livre des logiciels ne peut pas fonctionner sur un substrat qui ne fonctionne pas.

Pourquoi l'angle de la fiabilité importe plus que la migration

La plupart des couvertures de l'annonce posent la mauvaise question. La question intéressante n'est pas où Ghostty atterrit ; la question intéressante est comment une plateforme avec la profondeur d'ingénierie de GitHub en est arrivée au point où son deuxième utilisateur OG le plus éminent est parti pour des raisons de fiabilité. La deuxième question la plus intéressante est ce que cela dit sur les outils que nous construisons, nous autres.

Trois choses distinguent cette annonce des publications habituelles du type "Je quitte X".

L'utilisateur. Hashimoto n'est pas un nouveau développeur ; il a construit des outils d'infrastructure utilisés par des entreprises du Fortune 500. Lorsqu'il affirme que GitHub n'est pas fiable, l'audience qui reçoit ce message inclut les personnes qui décident où réside le code source de leur entreprise. Les listes de diffusion des CTO étaient déjà pleines de cet article le matin du 29 avril.

La raison. Il n'est pas parti à cause de Copilot, de Microsoft, de la formation à l'IA, des contrats ICE, des prix, ou de tout autre sujet de départ habituel. Il est parti parce que le service n'arrêtait pas de tomber en panne. Cela réduit la conversation à l'axe sur lequel tout le monde s'accorde : l'outil fonctionne-t-il quand vous en avez besoin ?

Le ton. Il n'y a pas de rage. L'article se lit comme un post-mortem écrit par quelqu'un qui a fait de grands efforts pour rester. Le manque de drame est ce qui le rend plus percutant que n'importe quel article plus bruyant n'aurait pu l'être. Les gens le croient.

Pour quiconque gère un outil de développement, cette combinaison est le scénario du pire. Un utilisateur de longue date, sans motif politique, sans dispute publique, seulement une accumulation silencieuse d'entrées "la chose n'a pas fonctionné aujourd'hui" jusqu'à ce que le calcul n'ait plus de sens. Il n'y a pas de réponse des relations publiques à un journal.

Ce que cela signifie si vous créez des outils pour développeurs

Si votre produit se situe sur le chemin critique d'un développeur, l'annonce de Hashimoto est un test de résistance. Appliquez-le à votre propre service.

Première question : quelle fraction de vos utilisateurs pourrait écrire le même journal à votre sujet ?

Récupérez les incidents des 90 derniers jours de votre page d'état, plus les dégradations non signalées que votre équipe connaît mais que la page d'état ne mentionne pas. Mappez-les par rapport aux heures de travail de vos 20 meilleurs clients. Comptez combien d'heures ont été perdues à vous attendre. Si la réponse est "plus de zéro par semaine par utilisateur intensif", vous êtes sur la même trajectoire.

Deuxième question : quelle est la dérivée seconde de votre fiabilité ?

Une fiabilité qui stagne est acceptable. Une fiabilité qui se dégrade silencieusement est le piège. Le journal de Hashimoto documente un modèle, pas un événement unique. Si vous n'avez pas de budget d'erreur par composant que quelqu'un lit le lundi matin, vous ne pouvez pas savoir dans quelle direction vos chiffres évoluent.

Troisième question : publiez-vous suffisamment d'informations pour que les utilisateurs n'aient pas besoin de tenir un journal ?

Les journaux existent parce que les utilisateurs ne font pas confiance au signal public. Votre page d'état devrait être active ("hot"), pas froide. Si une fonctionnalité est dégradée, signalez-le. Si une région est lente, signalez-le. Si votre file d'attente en arrière-plan a 30 minutes de retard, signalez-le. Les utilisateurs qui peuvent voir la vérité en temps réel ne commencent pas à tenir des journaux.

Quatrième question : êtes-vous fiable pour un travail sérieux ou pour la démonstration ?

Un temps de disponibilité de 99,95 % qui regroupe tous les temps d'arrêt pendant les heures de travail des développeurs est pire qu'un temps de disponibilité de 99,9 % réparti uniformément. Si votre charge de travail est une session de révision de PR de quatre heures, deux heures de panne à tout moment sont sans importance ; deux heures de panne pendant cette session représentent toute la session. Mesurez la disponibilité par rapport à la courbe d'utilisation réelle du client, pas la vôtre.

Le verrouillage et le coût du "toujours GitHub"

L'expression que Hashimoto a utilisée à son propre sujet est la phrase la plus citée de l'article : "Pour moi, il n'y a jamais eu de question quant à l'endroit où je mettrais mes projets : toujours GitHub." C'est le coût de l'habitude, et c'est le coût que la plupart des développeurs ne calculent pas correctement.

Lorsqu'une seule plateforme est la valeur par défaut pour les dépôts, les problèmes, les PR, le CI, la distribution de paquets, les releases et l'identité, la surface du "verrouillage" est bien plus grande que la surface de "l'historique Git". Vous pouvez cloner un dépôt Git n'importe où ; vous ne pouvez pas cloner un traqueur de problèmes, un historique de révision de PR, un fil de discussion, le stockage des secrets de GitHub Actions ou le workflow de révision lié aux CODEOWNERS avec une seule commande. Le coût de migration a la forme d'un iceberg.

Ce coût se compose pour les créateurs d'outils. Si votre outil de développement vit à l'intérieur d'une GitHub Action, est distribué via la Marketplace, s'authentifie via GitHub OAuth et livre des releases via GitHub Packages, la fiabilité de votre outil est un dérivé de la fiabilité de GitHub. Votre budget d'erreur est une fraction du leur. Vos clients subissent votre temps d'arrêt lorsqu'ils utilisent votre outil, mais ils subissent également votre temps d'arrêt lorsque GitHub tombe en panne et que votre outil cesse de répondre. L'attribution des responsabilités n'est pas toujours précise ; l'expérience client l'est.

Le travail de découplage n'est pas glamour, et c'est un travail. Rendez chaque dépendance remplaçable. Traitez GitHub comme un fournisseur parmi d'autres, et non comme une infrastructure. Testez le chemin alternatif trimestriellement. Migrez les parties qui s'adaptent mieux à une forge différente ; conservez celles qui ne le font pas. La ligne de conduite de Hashimoto sur la "migration incrémentale" est le bon modèle pour tout le monde, pas seulement pour lui.

Les alternatives de forge, en bref

Hashimoto ne s'est explicitement engagé sur aucune. Le signal dans le silence est qu'aucune des options n'est un remplacement évident pour tout ce que GitHub fait, ce qui est le but : lorsqu'une plateforme absorbe toute la pile, la remplacer proprement est intrinsèquement difficile.

La leçon pour les équipes API

Si vous créez des API ou des outils API au lieu d'émulateurs de terminal, le même schéma s'applique, les noms étant modifiés. Remplacez "GitHub Actions" par "l'API en amont dont dépend votre produit". Remplacez "problèmes et PR" par "la boîte de réception où vos clients vous signalent que quelque chose ne va pas". La question structurelle est la même : quelle part du travail de votre client dépend d'un service que vous ne contrôlez pas, et comment restez-vous utile lorsque ce service tombe en panne ?

Trois schémas résistent au contact de la réalité.

Mocker tout ce dont vous dépendez. Vos clients devraient pouvoir continuer à construire lorsque l'API en amont est en panne. Cela signifie que la suite de tests, la boucle de développement locale et le pipeline CI ont tous besoin d'un serveur de mock qui renvoie des réponses réalistes sans appel réseau. Apidog propose cela comme une fonctionnalité de premier ordre ; les mêmes définitions de données que vous utilisez pour tester l'API en direct génèrent le mock. Le schéma est simple et le coût est payé une seule fois. Voir la comparaison avec l'écosystème de forme OpenAI dans comment utiliser l'API GPT-5.5 pour voir à quoi ressemble une histoire de mocking multi-fournisseurs en pratique.

Tester avec plusieurs fournisseurs. OpenAI, Anthropic, Mistral, DeepSeek, Google et xAI exposent tous des points de terminaison de complétion de chat avec des formes qui se chevauchent. Si votre produit enveloppe l'un d'entre eux, la différence entre "nous sommes en panne parce qu'OpenAI est en panne" et "nous avons transparentement redirigé vers un fournisseur de secours" représente deux jours de travail d'intégration. Exécutez votre suite de tests sur chaque fournisseur que vous supportez, pas seulement le principal. Les variables d'environnement d'Apidog font du changement une modification de configuration d'une seule ligne.

Découplez votre pipeline de publication de votre plateforme d'hébergement. Si votre CI réside entièrement sur GitHub Actions et que GitHub Actions connaît un après-midi difficile, votre publication n'aboutira à rien. La mise en miroir du CI vers un deuxième exécuteur, ou l'auto-hébergement d'au moins les chemins critiques, élimine le point de défaillance unique. Le coût est réel ; l'alternative est d'être incapable de livrer pendant que la page d'état de votre fournisseur principal change de couleur.

À quoi ressemble un workflow de type Apidog pour un travail API résilient

  1. Téléchargez Apidog et créez un projet par surface API en amont dont vous dépendez.
  2. Définissez les schémas de requête et de réponse une seule fois. Apidog génère un serveur de mock à partir du schéma afin que la boucle de développement ne soit jamais bloquée par le service en amont.
  3. Stockez les identifiants sous forme de secrets à portée d'environnement. La même forme de requête s'exécute contre dev (mock), staging (bac à sable) et prod (en direct) en changeant d'environnement.
  4. Rédigez des tests de contrat qui s'exécutent à chaque release ; les mêmes tests s'exécutent sur chaque fournisseur que vous supportez, de sorte qu'une régression sur le fournisseur A apparaît avant que les clients ne la voient.
  5. Lorsqu'une API en amont est dégradée, basculez l'environnement en mode mock et continuez à avancer. Le produit est toujours livré même si le service en amont ne l'est pas.

Ce schéma n'est pas spécifique à Ghostty ni à l'IA ; c'est le schéma d'API résiliente qui a porté ses fruits pour chaque équipe l'ayant adopté avant d'en avoir besoin. L'article de Hashimoto est le dernier rappel que vous l'adoptez avant d'en avoir besoin, pas après.

Ce que les développeurs retiennent de l'annonce

Les réactions des 48 premières heures se répartissent en quelques catégories.

Le camp des "tant mieux pour lui". Des utilisateurs expérimentés de GitHub, frustrés en silence depuis des mois, qui ont vu dans l'article une permission de rendre publiques leurs propres doléances. Beaucoup d'entre eux utilisent déjà un miroir vers une deuxième forge ; l'article les a poussés à faire de ce miroir leur principal dépôt.

Les sceptiques du "ce n'est qu'une panne". Des personnes soulignant que le temps de disponibilité global de GitHub est compétitif par rapport aux normes de l'industrie et que toute grande plateforme a ses mauvais jours. Ils n'ont pas tort sur le chiffre macro, mais ils passent à côté du point de la dérivée seconde : c'est la tendance, et non le chiffre absolu, qui a déclenché Hashimoto.

Les pragmatiques du "quitter la plateforme est difficile, on se voit dans six mois". Des ingénieurs qui ont déjà effectué une migration de forge et savent que le traqueur de problèmes, l'historique des PR et la surface du CI sont là où réside le coût de la migration. Ils ont raison, et le plan de Hashimoto "incrémental, avec un miroir en lecture seule" est la bonne approche pour cette contrainte.

Les inquiets du "quid de mes dépôts". Des mainteneurs plus modestes se demandant si leurs projets sont exposés au même risque. La réponse est oui en termes de forme, non en termes d'échelle ; une panne qui ferait perdre à Hashimoto une journée facturable chez HashiCorp est un inconvénient mineur pour un projet de week-end. Votre calcul de migration est différent.

Les réactions qui comptent ne sont pas sur les réseaux sociaux. Elles se trouvent au sein des organisations d'ingénierie qui ont choisi GitHub comme substrat pour tout ce qu'elles livrent. Les conversations ont lieu sur Slack en ce moment : comment réduire ce risque, à quoi ressemble notre politique interne en matière de mirroring sur une deuxième forge, et quel est le plan de sortie ?

Enseignements pratiques pour votre propre pile technologique

Une courte liste de vérification, basée sur des opinions :

Pour un exemple concret spécifique aux outils API, l'article sur la construction de workflows durables qui survivent aux pannes de fournisseur parcourt le même schéma avec du code, en utilisant DeepSeek et OpenAI comme exemple de double fournisseur. Les formes changent ; le principe, lui, ne change pas.

FAQ

button

Pratiquez le Design-first d'API dans Apidog

Découvrez une manière plus simple de créer et utiliser des API

S'inscrire gratuitementTélécharger