Alternatives européennes à GitHub.

GitHub est le foyer par défaut du code source pour la majeure partie de l'industrie logicielle, mais il reste un produit américain : GitHub, Inc. est une filiale à 100 % de Microsoft Corporation, fonctionne en grande partie sur une infrastructure contrôlée par Microsoft et relève du CLOUD Act américain. Pour un dépôt, cette portée couvre non seulement le code mais aussi l'historique des tickets, les journaux de CI, les jetons d'accès et les avis de sécurité. Cette page situe les alternatives européennes face à GitHub, en vérifiant à qui appartient juridiquement chaque service, où résident physiquement les données et quelle posture de conformité chacun peut démontrer : le profil dont une équipe d'achats européenne a besoin pour une analyse d'impact des transferts au titre de Schrems II.

Les deux services européens ici reposent tous deux sur Forgejo, la forge open source gérée par Codeberg e.V. en Allemagne, ce qui signifie que le moteur sous-jacent reste auditable et auto-hébergeable quel que soit le choix. Codeberg (Allemagne, Berlin, association, hébergé dans l'UE, gratuit, exposition au CLOUD Act : Aucune) est l'option gérée par la communauté et le foyer naturel des projets open source. Codebahn (opérateur suédois, hébergé en France, payant et pris en charge, exposition au CLOUD Act : Aucune) est l'option commerciale gérée avec un DPA public et une chaîne de sous-traitants entièrement constitués dans l'UE, destinée aux équipes ayant besoin de garanties contractuelles.

Alors, qu'est-ce qui se transfère réellement depuis un compte GitHub ?

• Dépôts Git avec tout l'historique des branches et des tags (portables par conception).
• Tickets, pull requests, étiquettes, jalons et versions (migrés par l'outil Forgejo).
• Revue de code avec commentaires en ligne et règles de protection de branche.
• CI/CD hébergée (Codeberg CI sur Woodpecker, ou les exécuteurs UE de Codebahn).
• Registre de paquets et registre de conteneurs.
• Webhooks et une API REST pour vos propres intégrations.

Tout ne fait cependant pas le voyage :

• La place de marché GitHub Actions. Les concepts de CI se reportent, mais pas la syntaxe des workflows ni l'écosystème des actions tierces ; les pipelines doivent être réécrits.
• GitHub Copilot et les fonctions d'IA. Les forges européennes sont livrées sans IA hébergée aux États-Unis par défaut, car cela irait à l'encontre de l'argument de souveraineté ; vous pouvez intégrer séparément un assistant d'IA européen.
• L'effet de réseau et la découvrabilité. Le graphe social de GitHub, les étoiles et les contributions spontanées sont difficiles à reproduire. Codeberg a une communauté open source active, mais plus petite.
• La grande place de marché d'intégrations. De nombreux outils SaaS s'intègrent d'emblée à GitHub ; avec une forge plus petite, vous aurez peut-être besoin de webhooks ou de l'API plutôt que d'une application en un clic.

Déplacer un dépôt hors de GitHub se résume à quelques étapes, quelle que soit la forge européenne choisie.

1. Commencez par l'outil de migration Forgejo. Codeberg et Codebahn exposent tous deux le flux « Nouvelle migration » de Forgejo : collez l'URL du dépôt GitHub et un jeton d'accès personnel, et il récupère le code plus les tickets, pull requests, étiquettes, jalons, versions et le wiki en une seule passe. Pour un déplacement du code uniquement, git push --mirror vers le nouveau dépôt distant fonctionne aussi.
2. Réécrivez votre pipeline de CI. C'est généralement la tâche la plus importante. Traduisez le workflow GitHub Actions en un pipeline Woodpecker (Codeberg) ou au format CI de Codebahn, et remplacez les actions de la place de marché par des étapes ou scripts équivalents.
3. Repointez les clones locaux et les intégrations. Mettez à jour git remote set-url chez chaque développeur, et repointez les webhooks de déploiement, les vérifications de statut ou les bots vers l'API de la nouvelle forge.
4. Régénérez les jetons et secrets. Les secrets de CI et les clés de déploiement ne migrent pas ; recréez-les sur la nouvelle forge et faites tourner tout ce qui a été exposé à GitHub.
5. Prévenez les collaborateurs et mettez à jour les liens. Les badges du README, les liens de documentation et les références de registre de paquets pointant vers github.com doivent être mis à jour ; envoyez aux collaborateurs la nouvelle URL du dépôt.
6. Conservez le dépôt GitHub en miroir en lecture seule pendant 60 jours. Les dépôts accumulent des dépendances silencieuses : une tâche de CI ailleurs, un gestionnaire de paquets tirant un tag, un lien dans la doc de quelqu'un. Archivez le dépôt GitHub plutôt que de le supprimer, afin que rien ne casse en silence pendant la bascule.