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, quittait GitHub. Il est l’utilisateur GitHub 1299, inscrit depuis février 2008, et a utilisé la plateforme presque tous les jours pendant plus de 18 ans. Pourtant, le jour de son annonce, une panne de GitHub Actions a bloqué ses révisions de pull requests pendant deux heures. Son constat est direct : « Ce n’est plus un endroit pour un travail sérieux si cela vous bloque des heures par jour, tous les jours. »

Essayez Apidog aujourd’hui

Si vous créez des outils pour développeurs, cette annonce mérite plus qu’une lecture rapide. Hashimoto n’est pas un utilisateur occasionnel : il a cofondé HashiCorp, livré Terraform, Vagrant, Vault, Consul et Boundary via GitHub, et fait partie des premiers utilisateurs historiques de la plateforme. Quand ce type de profil quitte l’outil dominant du développement logiciel pour des raisons de fiabilité, le sujet dépasse largement Ghostty.

Pour un contexte plus large sur les workflows de développement à l’ère de l’IA, consultez comment écrire des fichiers AGENTS.md, l’utilisation et la facturation de l’API GitHub Copilot pour les équipes, ainsi que l’article sur le bot de triage Clawsweeper.

TL;DR

• Mitchell Hashimoto a annoncé le 28 avril 2026 que Ghostty quitterait GitHub pour une forge encore non nommée.
• La cause principale : des pannes récurrentes de GitHub Actions et de la plateforme, documentées dans un journal personnel.
• Le dépôt Ghostty sur GitHub restera un miroir en lecture seule ; le développement actif migrera progressivement ailleurs.
• Le signal important n’est pas la destination de Ghostty, mais la raison du départ : la fiabilité.
• Pour les créateurs d’outils développeurs, la leçon est claire : dès que votre outil devient critique, la fiabilité pèse plus lourd que les fonctionnalités.
• Pour les équipes API, la réponse pratique est le découplage : mocks, tests multi-fournisseurs, CI redondant et chemins de migration testés à l’avance. Apidog s’inscrit dans ce modèle.

Ce que Hashimoto a annoncé

Dans son article d’annonce, Hashimoto ne publie ni manifeste, ni attaque contre Microsoft, ni promotion d’une forge concurrente. Il décrit simplement une accumulation de pannes.

Son raisonnement tient en trois points :

1. Il a commencé à consigner les incidents GitHub.
2. Le journal s’est rempli plus vite que prévu.
3. Le jour de l’annonce, GitHub Actions a bloqué ses révisions de PR pendant deux heures.

La panne du 27 avril 2026 a affecté GitHub Actions, Packages et une partie de l’API. Mais elle n’a pas créé la décision : elle l’a accélérée. Hashimoto indique que le départ était déjà en préparation.

Le plan annoncé est progressif :

• Ghostty quitte GitHub pour le développement actif.
• Le dépôt ghostty-org/ghostty restera accessible en miroir lecture seule.
• Les issues, pull requests et pipelines CI migreront vers une autre forge.
• Ses autres projets restent sur GitHub pour l’instant.
• La destination finale n’est pas encore annoncée.

Ce qui frappe surtout, c’est ce qu’il ne mentionne pas : pas de débat sur les prix, Copilot, l’IA, Microsoft ou les fonctionnalités. Le problème est plus fondamental : l’outil n’est plus assez fiable pour son usage quotidien.

Pourquoi la fiabilité est le vrai sujet

La question intéressante n’est pas seulement : « Où Ghostty va-t-il migrer ? »

La vraie question est : comment une plateforme aussi centrale que GitHub peut-elle perdre la confiance d’un utilisateur aussi historique pour des raisons de disponibilité ?

Pour les développeurs et les équipes produit, cette annonce expose trois signaux faibles.

1. Le profil de l’utilisateur compte

Hashimoto a construit des outils d’infrastructure utilisés à grande échelle. Lorsqu’il écrit que GitHub n’est plus fiable pour son travail, le message est lu par des mainteneurs open source, des équipes plateforme, des CTO et des responsables DevOps.

Ce n’est pas un tweet d’humeur. C’est un retour d’expérience d’un utilisateur expert.

2. La cause est difficile à contester

Il ne part pas pour une préférence idéologique ou un désaccord produit. Il part parce que le service tombe trop souvent en panne sur son chemin critique.

C’est le critère le plus dur pour un outil développeur :

Est-ce que l’outil fonctionne quand j’en ai besoin ?

Si la réponse devient incertaine, la confiance diminue rapidement.

3. Le ton est celui d’un post-mortem

L’article ne cherche pas le conflit. Il ressemble à une décision opérationnelle prise après trop d’incidents.

C’est précisément ce qui le rend convaincant. Une page d’état peut minimiser une panne. Un journal utilisateur répété pendant des mois est plus difficile à ignorer.

Test de résistance pour votre propre outil développeur

Si votre produit est utilisé dans un workflow de développement, appliquez ce test à votre propre service.

Question 1 : vos utilisateurs pourraient-ils tenir le même journal ?

Prenez les 90 derniers jours et listez :

• incidents publics ;
• dégradations non publiées ;
• lenteurs connues ;
• files d’attente bloquées ;
• erreurs API intermittentes ;
• échecs CI causés par votre service.

Ensuite, mappez ces incidents avec les heures de travail de vos clients les plus actifs.

Si un utilisateur intensif perd plusieurs heures par semaine à cause de votre service, vous avez un problème de confiance, même si votre SLA global semble correct.

Question 2 : votre fiabilité s’améliore-t-elle ou se dégrade-t-elle ?

Un taux de disponibilité stable est une chose. Une dégradation progressive en est une autre.

Suivez la tendance, pas seulement la moyenne :

Semaine 1 : 1 incident mineur
Semaine 2 : 2 incidents mineurs
Semaine 3 : 1 incident majeur
Semaine 4 : 3 incidents partiels

Même si chaque incident semble acceptable isolément, la dérivée est mauvaise.

À mettre en place :

• budget d’erreur par composant ;
• revue hebdomadaire des incidents ;
• suivi du temps perdu côté utilisateur ;
• alertes sur les dégradations partielles, pas seulement les pannes totales.

Question 3 : votre page d’état reflète-t-elle la réalité ?

Les utilisateurs commencent à tenir leurs propres journaux lorsqu’ils ne font plus confiance au signal officiel.

Une bonne page d’état doit signaler :

• latence élevée ;
• erreurs partielles ;
• régions dégradées ;
• backlog de workers ;
• retards dans les webhooks ;
• temps d’exécution CI anormal ;
• erreurs API intermittentes.

Ne publiez pas seulement les pannes totales. Pour les développeurs, une fonctionnalité lente ou instable peut suffire à bloquer une livraison.

Question 4 : mesurez-vous la disponibilité au bon endroit ?

Un uptime de 99,95 % peut masquer un problème si les pannes tombent pendant les heures de travail critiques.

Exemple :

Disponibilité globale : 99,95 %
Panne : 2 heures
Moment : fenêtre quotidienne de revue PR
Impact réel : une session entière perdue

Mesurez donc la disponibilité par rapport à l’usage réel :

• heures de travail des utilisateurs ;
• pics CI/CD ;
• fenêtres de release ;
• périodes de revue de code ;
• workflows critiques par segment client.

Le coût caché du « toujours GitHub »

Hashimoto écrit qu’il n’a jamais vraiment envisagé autre chose que GitHub pour ses projets. C’est précisément là que se trouve le risque : l’habitude devient une dépendance.

Git est portable. Mais une plateforme de développement moderne ne contient pas seulement du Git.

Elle contient aussi :

• issues ;
• pull requests ;
• commentaires de revue ;
• workflows CI ;
• secrets ;
• permissions ;
• CODEOWNERS ;
• packages ;
• releases ;
• webhooks ;
• intégrations OAuth ;
• automatisations Marketplace ;
• identité développeur.

Cloner un dépôt est facile :

git clone git@github.com:org/project.git

Migrer tout l’écosystème autour du dépôt est beaucoup plus coûteux.

Si votre outil dépend fortement de GitHub Actions, GitHub OAuth, GitHub Packages et GitHub Marketplace, votre fiabilité devient mécaniquement dérivée de celle de GitHub.

Même si votre propre code fonctionne, vos utilisateurs peuvent percevoir votre outil comme indisponible dès que GitHub est dégradé.

Comment réduire le verrouillage plateforme

Le découplage doit être traité comme une tâche d’ingénierie, pas comme une intention abstraite.

1. Encapsulez les appels GitHub

Évitez de disperser des appels GitHub partout dans votre codebase.

À éviter :

import { Octokit } from "@octokit/rest";

const github = new Octokit({ auth: process.env.GITHUB_TOKEN });

await github.rest.issues.create({
  owner,
  repo,
  title,
  body,
});

Préférez une interface :

interface IssueProvider {
  createIssue(input: {
    project: string;
    title: string;
    body: string;
  }): Promise<{ id: string; url: string }>;
}

Puis implémentez des adaptateurs :

class GitHubIssueProvider implements IssueProvider {
  async createIssue(input) {
    // appel GitHub
  }
}

class GitLabIssueProvider implements IssueProvider {
  async createIssue(input) {
    // appel GitLab
  }
}

class ForgejoIssueProvider implements IssueProvider {
  async createIssue(input) {
    // appel Forgejo
  }
}

Même si vous n’implémentez qu’un fournisseur au départ, cette séparation rend la migration possible.

2. Miroitez vos dépôts

Un miroir hebdomadaire vers une deuxième forge est peu coûteux.

Exemple de job GitHub Actions simple :

name: Mirror repository

on:
  schedule:
    - cron: "0 3 * * 1"
  workflow_dispatch:

jobs:
  mirror:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout full history
        uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Push mirror
        run: |
          git remote add mirror "$MIRROR_URL"
          git push --mirror mirror
        env:
          MIRROR_URL: ${{ secrets.MIRROR_URL }}

Ce job ne résout pas tout, mais il garantit qu’une copie exploitable existe ailleurs.

3. Documentez le chemin manuel

Quand le pipeline principal est en panne, que fait l’équipe ?

Créez une procédure courte :

Si GitHub Actions est indisponible :
1. Vérifier que le tag de release est signé.
2. Lancer le build local avec `make release`.
3. Publier l’artefact via le runner secondaire.
4. Mettre à jour la release manuellement.
5. Créer un incident interne avec horodatage.

Si ce chemin n’est pas documenté, il n’existe pas.

4. Testez le plan de sortie

Un plan de migration non testé est une hypothèse.

À tester chaque trimestre :

• restauration depuis le miroir ;
• exécution CI sur un runner alternatif ;
• publication sans GitHub Actions ;
• rotation des secrets ;
• création d’issue sur une forge secondaire ;
• bascule DNS ou documentation si nécessaire.

Alternatives de forge, en bref

Hashimoto n’a pas annoncé de destination finale. Voici les options courantes et leurs compromis.

• Forgejo : fork dur de Gitea, entièrement FOSS, maintenu par Codeberg e.V. La fédération via ActivityPub est sur la feuille de route et partiellement implémentée.
• Codeberg : instance Forgejo hébergée, gérée comme une association à but non lucratif. Adaptée à l’open source, mais sans équivalent complet de GitHub Actions à grande échelle.
• GitLab : CI/CD robuste, forte couverture fonctionnelle, support commercial. Certaines évolutions de licence peuvent freiner des projets FOSS.
• Sourcehut : workflow par e-mail, minimaliste et rapide. Très apprécié par son public, mais plus niche.
• Forgejo ou Gitea auto-hébergé : contrôle maximal, responsabilité opérationnelle maximale.
• Radicle : approche pair-à-pair sans hôte central. Prometteur pour la fédération, mais encore jeune pour des projets grand public.

Le point important : aucune option ne remplace parfaitement toute la surface GitHub. C’est justement le problème lorsqu’une seule plateforme absorbe dépôt, CI, issues, identité et distribution.

Leçon pour les équipes API

Si vous construisez des API ou des outils API, remplacez simplement les noms :

• « GitHub Actions » devient « API amont critique » ;
• « issues et PR » devient « canal de support ou d’intégration client » ;
• « forge » devient « fournisseur externe ».

La question reste la même :

Quelle part du travail de vos utilisateurs dépend d’un service que vous ne contrôlez pas ?

Trois pratiques réduisent fortement le risque.

1. Mockez toutes les dépendances critiques

Vos développeurs et vos clients doivent pouvoir continuer à travailler quand une API amont est indisponible.

Un serveur de mock doit couvrir :

• développement local ;
• tests automatisés ;
• intégration CI ;
• démos produit ;
• scénarios d’erreur ;
• réponses lentes ou partielles.

Avec Apidog, les définitions de requêtes et réponses peuvent servir à générer un mock réaliste. Le même contrat utilisé pour tester l’API réelle sert aussi à simuler son comportement.

Pour un exemple orienté fournisseurs IA, consultez comment utiliser l’API GPT-5.5.

2. Testez plusieurs fournisseurs

Si votre produit dépend d’un fournisseur IA, de paiement, d’e-mail ou de stockage, ne testez pas uniquement le fournisseur principal.

Exemple de matrice :

Provider principal : OpenAI
Fallback 1         : Anthropic
Fallback 2         : Mistral
Fallback 3         : Google

Votre suite de tests devrait pouvoir s’exécuter contre chaque fournisseur supporté.

Avec des variables d’environnement, le changement doit rester simple :

API_PROVIDER=openai npm test
API_PROVIDER=anthropic npm test
API_PROVIDER=mistral npm test

L’objectif n’est pas de rendre tous les fournisseurs parfaitement interchangeables, mais d’identifier tôt les écarts de contrat.

3. Découplez publication et hébergement

Si votre CI dépend entièrement de GitHub Actions, une panne GitHub bloque vos releases.

Options possibles :

• runner auto-hébergé pour les chemins critiques ;
• pipeline secondaire sur GitLab CI ;
• build reproductible localement ;
• publication manuelle documentée ;
• miroir de registry ou artefacts ;
• job périodique de vérification de récupération.

Le coût existe, mais il est inférieur au coût d’une incapacité totale à livrer pendant un incident fournisseur.

Exemple de workflow API résilient avec Apidog

Voici une approche simple pour éviter qu’une API amont bloque toute votre équipe.

1. Téléchargez Apidog et créez un projet pour chaque surface API critique.
2. Définissez les schémas de requête et réponse une seule fois.
3. Générez un serveur de mock à partir de ces schémas.
4. Créez des environnements séparés :
   • dev : mock ;
   • staging : sandbox ;
   • prod : API réelle.
5. Stockez les clés API comme secrets d’environnement.
6. Écrivez des tests de contrat réutilisables.
7. Exécutez les mêmes tests sur chaque fournisseur supporté.
8. En cas de panne amont, basculez temporairement vers le mock pour continuer le développement.

Exemple de logique côté application :

const baseUrl =
  process.env.API_MODE === "mock"
    ? process.env.MOCK_API_URL
    : process.env.UPSTREAM_API_URL;

const response = await fetch(`${baseUrl}/v1/messages`, {
  method: "POST",
  headers: {
    Authorization: `Bearer ${process.env.API_TOKEN}`,
    "Content-Type": "application/json",
  },
  body: JSON.stringify(payload),
});

Ce type de bascule simple évite de figer toute une équipe pendant qu’un fournisseur externe corrige son incident.

Ce que les développeurs retiennent de l’annonce

Les réactions se regroupent en quatre catégories.

« Il a raison »

Des utilisateurs intensifs de GitHub, frustrés par des dégradations répétées, voient dans cette annonce une validation de leur propre expérience. Certains utilisaient déjà un miroir secondaire et envisagent maintenant d’en faire leur dépôt principal.

« Ce n’est qu’une panne »

D’autres rappellent que GitHub garde une disponibilité globale compétitive. C’est vrai au niveau macro, mais cela ignore le point central : la tendance et l’impact réel sur les workflows critiques.

« Migrer est difficile »

Les ingénieurs ayant déjà migré une forge savent que le dépôt Git est la partie facile. Les issues, PR, commentaires, secrets, permissions et pipelines CI sont la vraie dette de migration.

C’est pourquoi l’approche incrémentale de Hashimoto est pragmatique.

« Dois-je m’inquiéter pour mes dépôts ? »

Oui pour la forme du risque. Non nécessairement pour l’urgence.

Un projet personnel de week-end n’a pas le même coût d’indisponibilité qu’un outil utilisé quotidiennement par des milliers de développeurs. Votre stratégie doit dépendre de votre criticité.

Checklist pratique pour votre pile

Utilisez cette liste comme point de départ.

• [ ] Miroiter les dépôts actifs vers une deuxième forge.
• [ ] Tester la restauration depuis ce miroir.
• [ ] Identifier tous les services externes sur le chemin critique.
• [ ] Pour chaque service, documenter : « que fait-on si cela tombe pendant 4 heures ? »
• [ ] Encapsuler les API fournisseurs derrière des adaptateurs.
• [ ] Ajouter un mode mock pour les dépendances critiques.
• [ ] Exécuter les tests de contrat contre plusieurs fournisseurs.
• [ ] Prévoir un runner CI secondaire pour les releases critiques.
• [ ] Documenter une procédure de publication manuelle.
• [ ] Suivre la tendance des incidents, pas seulement le SLA global.
• [ ] Publier des statuts détaillés lors des dégradations partielles.
• [ ] Revoir chaque trimestre le plan de sortie fournisseur.

Pour un autre exemple appliqué aux outils API, l’article sur la construction de workflows durables qui survivent aux pannes de fournisseur montre le même principe avec DeepSeek et OpenAI.

FAQ

Où Ghostty déménage-t-il ?

Hashimoto n’a pas annoncé de destination finale. Il a indiqué être en discussion avec plusieurs fournisseurs, commerciaux et FOSS. La migration sera progressive, et le dépôt GitHub actuel restera un miroir en lecture seule.

GitHub est-il vraiment si peu fiable ?

Les chiffres globaux de disponibilité de GitHub restent compétitifs. Le problème soulevé par Hashimoto concerne surtout les pannes partielles et répétées qui s’accumulent en heures perdues pour les utilisateurs dont le travail dépend directement de GitHub.

Dois-je quitter GitHub maintenant ?

Pas nécessairement. En revanche, mettre en place un miroir secondaire est une mesure peu coûteuse et utile. Faire d’une autre forge votre plateforme principale dépend du coût de migration de vos issues, PR, workflows CI et intégrations.

Cela concerne-t-il GitHub Copilot ou GitHub Actions ?

L’article de Hashimoto ne vise pas spécifiquement Copilot. GitHub Actions est mentionné comme déclencheur immédiat, car la panne du jour a bloqué ses revues de PR. Pour Copilot, consultez l’utilisation et la facturation de l’API GitHub Copilot pour les équipes.

Qu’est-ce que cela implique pour les outils IA qui dépendent de GitHub ?

Les bots de revue, outils de triage, serveurs MCP et assistants qui utilisent l’API GitHub héritent de son profil de fiabilité. Pour réduire le risque : cachez agressivement, tolérez les pannes partielles, mockez l’amont et prévoyez un fournisseur ou une forge alternative. L’article sur le bot de triage Clawsweeper donne un exemple concret.

Est-ce le début d’une tendance de départ de GitHub ?

Probablement, mais lentement. Migrer un projet non trivial hors de GitHub demande du temps. Le signal fort est qu’un utilisateur historique estime désormais que le coût de migration vaut la peine d’être payé.

Qui est concerné par ces leçons ?

Toute personne qui construit un outil utilisé par des développeurs dans leur workflow quotidien : terminaux, éditeurs, CI, clients API, outils de monitoring, registres de paquets, bots de revue ou assistants IA. Si votre outil se trouve entre un développeur et sa capacité à livrer, la fiabilité est une fonctionnalité centrale.