N’attendez pas la prochaine panne : la stratégie de sortie GitHub d’un CTO

Vous n’exécuteriez pas la production dans une seule zone de disponibilité. Ne faites pas tourner votre organisation d’ingénierie sur une seule forge de code.

Ces dernières semaines, nous avons eu un rappel constant que GitHub est une dépendance, pas une garantie : la divulgation d’une CVE d’exécution de code à distance, une mise à jour publique d’incident de disponibilité, le projet Ghostty annonçant publiquement qu’il quitte GitHub, et HardenedBSD s’installant sur Radicle. Rien de tout cela ne signifie « paniquez et migrez demain ». Cela signifie agir en propriétaire de plateforme lucide : couvrez votre risque dès maintenant afin de pouvoir migrer plus tard — sans drame.

Ce billet propose un cadre de décision et une architecture concrète pour une stratégie Git à double hébergement : conservez GitHub comme primaire, mettez en place une seconde maison sur laquelle vous pourrez basculer en quelques heures, pas en semaines. Vous aurez aussi un plan 30–60–90 jours et les pièges que nous avons observés de près en livrant cela pour des équipes américaines avec nos ingénieurs plateforme basés au Brésil.

Pourquoi une couverture GitHub est rationnelle (pas réactionnaire)

• Dépendance à une seule forge. Si vos dépôts, CI, packages et la recherche de code sont tous derrière un seul fournisseur, une panne d’authentification côté fournisseur peut arrêter l’ingénierie en quelques minutes. Cela se mesure en coût horaire moyen d’ingénierie, pas en décimales de SLA.
• Des événements de sécurité arrivent. Des RCE et des bugs de fuite de jetons continueront de survenir sur toutes les forges. La mitigation n’est pas « changer de fournisseur ». C’est « supposer une compromission, contenir le rayon d’explosion, basculer rapidement ».
• Politiques et tarification évoluent. Des changements de CGU (ToS) ou de prix (pensez modules IA facturés à l’usage ou inflation du prix par siège) peuvent impacter le budget en milieu d’année. Vous avez besoin de levier avant le renouvellement, pas après.
• Conformité et souveraineté. Certains clients (notamment enterprise ou régulés) exigent de plus en plus une provenance de code démontrable et un plan de sortie fournisseur. Un miroir avec des builds signés rassure les auditeurs qui demandent : « Et si GitHub était indisponible pendant 48 heures ? »

Rester sur GitHub est très bien. Rester uniquement sur GitHub, sans échappatoire testée, ne l’est pas.

Le cadre de décision : trois niveaux de préparation

Niveau 0 : statu quo (n’y restez pas)

• Tous les dépôts, issues, CI/CD, packages sur GitHub.
• Jetons d’accès personnels pour l’automatisation.
• Aucune sauvegarde hors site, aucune signature de commits, aucune provenance.

Délai de sortie : des jours à des semaines, avec des lacunes douloureuses et des pertes de données.

Niveau 1 : Couverture (commencez ici, 0–30 jours)

• Sauvegardes nocturnes de dépôts bare hors site (chiffrées), y compris Git LFS.
• Signature sans clés des builds via Sigstore (Fulcio/Rekor) et métadonnées de provenance (SLSA L2+).
• GitHub Actions utilisent OIDC vers le cloud pour les identifiants ; pas de secrets longue durée.
• Artéfacts de packages mis en miroir vers un registre neutre (p. ex., ECR/Artifact Registry/Quay), pas uniquement GitHub Packages.

Délai de sortie : 48–72 heures avec heures supplémentaires et un peu de retravail manuel.

Niveau 2 : Double hébergement (ce que vous voulez réellement, 30–90 jours)

• GitHub reste primaire. Forgejo/Gitea/GitLab CE est mis en place comme miroir actif (lecture seule par politique).
• Tous les dépôts sont mis en miroir par push à chaque commit ; issues/discussions sont synchronisées selon un calendrier.
• Les définitions CI/CD sont neutres vis-à-vis des runners avec un pipeline parallèle sur WoodpeckerCI/Drone, Buildkite ou Tekton.
• Sourcegraph/Zoekt indexent les deux forges.
• Journée de simulation de bascule trimestrielle et étapes de cutover documentées.

Délai de sortie : 4–8 heures, principalement coordination des DNS/URLs et bascule des pipelines.

Niveau 3 : Migration complète (uniquement si nécessaire)

• Le primaire passe sur un Forgejo/GitLab CE auto-hébergé ou une alternative hébergée (SourceHut, Codeberg, GitLab Cloud).
• GitHub reste un miroir en lecture seule pour la continuité de l’historique et la portée écosystème.

Temps nécessaire : 2 à 6 semaines avec un traitement soigneux de l’historique des issues/PR.

L’architecture de référence : un Git qui bascule comme la prod

Forges et miroirs

• Primaire : GitHub (Enterprise recommandé pour SSO, audit et listes d’autorisations IP).
• Secondaire : Forgejo (fork communautaire de Gitea), Gitea, ou GitLab CE. Pour les plus aventureux ou les cas OSS, ajoutez un remote Radicle pour la réplication pair-à-pair.

Schéma de mise en miroir :

1. Protégez votre branche primaire sur GitHub ; seuls la CI ou les files d’attente de merge peuvent écrire.
2. Au push sur les branches protégées, exécutez un job de push-mirror depuis un runner durci qui dispose d’une clé de déploiement en écriture seule vers la forge secondaire. Utilisez git push --mirror pour les nouveaux dépôts et git push --prune pour la synchronisation continue.
3. Excluez les secrets et les notes Git privées. Synchronisez explicitement Git LFS via git lfs fetch --all et git lfs push --all.

Coûts : Une VM 4 vCPU/16 Go pour Forgejo plus Postgres coûte généralement 60–120 $/mois sur un grand cloud, plus du stockage compatible S3 pour les dépôts/LFS (environ 0,023 $/Go-mois). Le temps d’admin est le vrai coût : comptez 3–5 h/semaine une fois stabilisé pour des organisations de 50 ingénieurs et 200–400 dépôts.

Identité et permissions

• Centralisez sur le SSO (Okta/Entra/Google) pour les deux forges.
• Utilisez des jetons de courte durée via OIDC pour toute l’automatisation ; interdisez les jetons d’accès personnels en CI.
• Répliquez les permissions équipe→dépôt vers la secondaire via un exporteur (GitHub GraphQL) et un importeur (API Forgejo/GitLab). Générez un diff nocturne et alertez en cas de dérive.

Neutralité CI/CD

• Conservez GitHub Actions pour l’ergonomie développeur, mais définissez des pipelines de manière portable :
• Pour le build/test : Miroirez le graphe des jobs dans WoodpeckerCI ou Drone (le YAML est proche d’Actions), ou utilisez Buildkite si vous souhaitez un plan de contrôle managé avec vos propres runners.
• Pour les organisations K8s-natives : Tekton vous donne un contrôle total, mais attendez-vous à plus de plomberie.
• Identifiants : Utilisez OIDC vers le cloud (AWS/GCP/Azure) depuis les deux systèmes de CI afin que les secrets soient identiques. Pas de secrets valables pour toute la durée d’un environnement ; chaque étape reçoit des identifiants frais et à portée réduite.
• Provenance des artéfacts : Signez conteneurs et binaires avec Sigstore, joignez la provenance SLSA aux releases, et vérifiez-la au déploiement. Cela rend la question « quelle forge a construit ceci ? » sans objet.

Issues, PR et revue de code

C’est la partie la plus difficile à rendre portable. Choisissez un seul système de référence pour la collaboration tout en dupliquant les métadonnées pour la continuité.

• Source de vérité : Conservez les issues/PR sur GitHub pendant le double hébergement. En bascule, gelez GitHub (droits d’écriture désactivés au niveau de l’organisation) et promouvez la secondaire en lecture-écriture.
• Mise en miroir : Utilisez des exporteurs pour synchroniser issues/étiquettes/jalons vers la secondaire chaque nuit. Pour Forgejo/GitLab, les outils de migration peuvent importer la plupart des métadonnées ; les revues et discussions de PR perdent souvent en fidélité. Capturez des instantanés des PR en HTML statique sur S3 pour le juridique/l’archivage.
• Notifications : Faites transiter les webhooks via un relais de diffusion (par exemple, un petit service derrière API Gateway/Cloud Run) qui achemine vers les deux systèmes de CI et le chat, afin que le basculement ne casse pas les automatisations.

Recherche et expérience développeur

• Recherche de code : Pointez Sourcegraph (self-hosted ou cloud) ou Zoekt sur les deux forges. Les développeurs conservent une seule barre de recherche, quel que soit le remote primaire.
• Devcontainers et templates : Conservez-les dans les dépôts et agnostiques au fournisseur. Évitez les steps composites uniquement Actions pour les opérations fondamentales ; encapsulez-les dans des makefiles ou de petits CLIs Go/Node que votre CI alternative peut appeler.

Basculement : à quoi ressemblent vraiment « quatre heures »

Si vous avez correctement atteint le Niveau 2, voici votre runbook pour un basculement planifié ou d’urgence.

1. Geler les écritures sur GitHub. Passez les permissions org/dépôt en lecture seule. Annoncez une indisponibilité de 30 minutes.
2. Promouvoir la secondaire en lecture-écriture. Supprimez temporairement les politiques de protection en écriture si nécessaire ; préservez les protections de branche.
3. Basculer la CI/CD. Mettez en pause Actions à l’échelle de l’organisation, activez les pipelines sur la secondaire (Woodpecker/Buildkite/Tekton). Vérifiez la disponibilité des runners et l’autoscaling.
4. Mettre à jour les remotes en masse. Pour les monorepos et les équipes trunk-based, mettez à jour les URLs d’origine via des scripts centralisés pour les dépôts internes ; les dépôts OSS conservent GitHub comme miroir pour la communauté.
5. Repointer les webhooks et la publication de packages. Votre relais doit en faire un simple bouton, pas une refonte. Validez les signatures d’artéfacts en staging, puis en production.
6. Surveiller et communiquer. Suivez les temps de file de merge, la durée de la CI, les canaux d’incident. Décidez sous 24 heures de rester ou de revenir en arrière.

Les frictions les plus courantes : des développeurs avec des branches de fonctionnalités longue durée qui n’étaient pas mises en miroir, et des pipelines atypiques utilisant des Actions obsolètes. Un dry-run sur une équipe pilote révèle ces points.

Les chiffres qui comptent pour votre pitch au CFO

• Les coûts par siège ne disparaissent pas. Le double hébergement n’a pas pour but principal d’économiser des sièges. La tarification par utilisateur de GitHub Enterprise reste pertinente pour la plupart des équipes. La couverture est une prime d’assurance, pas un remplacement.
• Les postes d’infrastructure sont modestes. Comptez 150–400 $/mois pour l’infra de la forge secondaire à 50–100 ingénieurs, plus 50–150 $ pour une petite instance Sourcegraph/Zoekt si vous l’auto-hébergez.
• Le time-to-value est court. Les équipes que nous avons aidées atteignent le Niveau 2 en 6–10 semaines avec un ingénieur plateforme ~50 % alloué et un DevOps/SRE ~30 % alloué. Les journées d’exercice prennent 2–3 heures chaque trimestre.
• L’arithmétique des pannes est implacable. Si votre coût moyen par ingénieur est de 150 $/h et que 60 ingénieurs sont bloqués pendant 3 heures, cela fait 27 000 $. Un seul incident finance des années d’infra de couverture.

Pièges et comment les éviter

• Surprises Git LFS. Mettez explicitement en miroir LFS et vérifiez que les comptes d’objets correspondent aux deux extrémités. Beaucoup d’équipes supposent que --mirror inclut LFS ; ce n’est pas le cas.
• Perte de l’historique de revue. Vous ne porterez pas 1:1 les fils de revue de PR. Archivez-les (HTML statique + cycle de vie S3) et passez à autre chose. Conservez GitHub en lecture seule pendant un trimestre pour que les liens continuent de fonctionner.
• Prolifération des secrets. Le double hébergement double les lieux de fuite potentielle des secrets à moins de standardiser sur OIDC et des identifiants éphémères. N’importez pas les vieux péchés.
• Dérive des outils « shadow ». Maintenez un diff hebdomadaire des dépôts, équipes et protections de branche entre les forges. Échouez vite en cas de dérive plutôt que de le découvrir au basculement.
• Sur-abstraction de la CI. Visez 80 % de portabilité, pas un DSL « plus petit dénominateur commun » qui ralentit l’équipe. Qu’il y ait 20 % de jobs spécifiques au fournisseur, c’est acceptable.

Et Radicle et le code entièrement décentralisé ?

Radicle (qu’HardenedBSD utilise désormais) est convaincant pour la résistance à la censure et la réplication pair-à-pair. Aujourd’hui, c’est un complément, pas un remplacement, pour la plupart des équipes commerciales :

• Cas d’usage : miroirs OSS, réplication d’urgence vers les machines des développeurs, et assurance supplémentaire pour les dépôts clés.
• Lacunes : maturité SSO/autorisations entreprise et UX PR/revue par rapport à GitHub/GitLab.

Si vous faites beaucoup d’OSS ou avez des contraintes de souveraineté particulières, ajouter un remote Radicle est une assurance bon marché. Traitez-le comme une troisième copie de vos dépôts les plus critiques.

Un plan 30–60–90 jours réellement exécutable

Jours 0–30 : Défenses rapides

• Recensez tous les dépôts, l’usage de LFS, les Actions, les runners, les secrets, les webhooks et les packages.
• Activez la signature Sigstore dans les builds et joignez la provenance SLSA aux artéfacts.
• Remplacez les secrets de CI par OIDC. Interdisez les jetons d’accès personnels dans l’automatisation.
• Mettez en place des sauvegardes nocturnes de dépôts bare + LFS vers S3 avec des règles de cycle de vie.
• Déplacez la publication des artéfacts vers un registre neutre et mettez en miroir depuis celui-ci vers GitHub Packages (et non l’inverse).

Jours 31–60 : Construire la seconde maison

• Mettez en place Forgejo/GitLab CE avec SSO et des permissions par équipe.
• Mettez en œuvre le push-mirror à chaque commit pour toutes les branches protégées ; rattrapez les gros dépôts hors ligne.
• Montez une CI parallèle (Woodpecker/Buildkite/Tekton). Rapprochez 70–80 % des jobs Actions.
• Indexez les deux forges dans Sourcegraph/Zoekt.
• Mettez en miroir issues/étiquettes/jalons chaque nuit ; archivez les historiques de PR chaque semaine sur S3.
• Pilotez une journée d’exercice avec une squad produit et un service non critique.

Jours 61–90 : Prouver la bascule

• Exécutez une journée de bascule de 2 heures à l’échelle de l’entreprise. Mesurez le temps jusqu’au merge et la stabilité de la CI.
• Publiez un runbook de cutover avec des propriétaires clairement nommés et des SLA.
• Automatisez la détection de dérive (équipes, dépôts, protections de branche) et l’alerte.
• Intégrez le plan dans les documents de risque fournisseur et de PCA (BCP) pour les audits et les clients enterprise.

Où un partenaire nearshore aide (et où vous n’en avez pas besoin)

Vous n’avez pas besoin d’aide pour activer Sigstore et les sauvegardes. Vous pourriez en vouloir lorsque :

• Vous avez 200+ dépôts, plusieurs langages et des runners CI hétérogènes.
• Vous devez préserver les preuves SOC 2 tout en modifiant la CI/CD et les flux d’artéfacts.
• Vous avez besoin de 6–8 heures/jour de recouvrement horaire pour mener les fenêtres de migration sans brûler vos soirées et week-ends.

Une équipe plateforme expérimentée prendra en charge en amont les parties épineuses : synchronisation LFS, cartographie identité/SSO, vérification de la provenance au déploiement, et bascules à blanc. Ensuite, l’exploitation en régime établi est légère.

En bref

Le départ de Ghostty de GitHub, l’élan de Radicle auprès des projets d’OS durcis, et les propres rapports d’incident de GitHub doivent affûter votre réflexion — pas provoquer une migration irréfléchie. La bonne approche est une résilience posée : continuez d’utiliser GitHub là où il excelle, mais donnez-vous un vrai plan B. Vous investissez déjà dans le multi-AZ, le multi-région et des runbooks pour la prod. Votre plateforme de code mérite la même rigueur.

Points clés

• Ne quittez pas GitHub sur un coup de tête — couvrez le risque. Double-hébergez votre code, votre CI et vos artéfacts pour qu’un cutover prenne des heures, pas des semaines.
• La provenance prime sur la plateforme. Signez vos builds, joignez SLSA et utilisez OIDC de sorte que la propriété et l’intégrité ne dépendent d’aucune forge.
• Attendez-vous à 150–400 $/mois d’infra pour une forge secondaire à 50–100 ingénieurs ; la première panne finance la couverture pendant des années.
• La partie la plus difficile concerne les issues/PR. Mettez en miroir ce que vous pouvez, archivez le reste, et gardez GitHub en lecture seule pour la continuité.
• Organisez une journée de bascule trimestrielle. Si vous n’avez jamais testé votre sortie, vous n’en avez pas.