Comment migrer de GitHub vers Codeberg

Pourquoi migrer de GitHub vers Codeberg ?

GitHub est la plateforme d’hébergement Git dominante en 2026. C’est aussi une plateforme détenue par Microsoft, hébergée sur une infrastructure américaine soumise au CLOUD Act, et qui se transforme de plus en plus en source de données d’entraînement pour l’IA, que vous y ayez consenti ou non. Pour les projets open source européens, les développeurs individuels et les organisations qui veulent que leur code soit sous juridiction européenne, Codeberg est l’alternative crédible.

Codeberg est un service allemand d’hébergement Git à but non lucratif basé sur Forgejo (le fork maintenu par la communauté de Gitea). Gratuit pour les projets open source, financé par les dons, résident dans l’UE, et construit explicitement autour des valeurs de pérennité du FOSS et de souveraineté numérique. Ce qui se rapproche le plus, pour la communauté open source, d’un « GitHub mais européen ».

Pour le code commercial propriétaire, l’alternative naturelle est Forgejo auto-hébergé sur Hetzner — même logiciel, hébergé sur votre propre infrastructure, pour environ 5-30 €/mois au total, quelle que soit la taille de l’équipe. Ce guide se concentre sur Codeberg en particulier, mais les étapes de migration fonctionnent à l’identique pour Forgejo auto-hébergé.

Étapes détaillées de la migration

Étape 1 : créer un compte Codeberg

Rendez-vous sur codeberg.org et créez un compte. Gratuit, requiert uniquement un e-mail. Pas de carte bancaire.

Pour les organisations qui migrent, créez un compte d’organisation après l’inscription individuelle — cela vous permet de transférer ou de forker des dépôts sous l’espace de noms de l’organisation.

Étape 2 : décider quoi migrer

Soyez sélectif. La migration est plus rapide quand vous n’emportez pas avec vous dix ans de dépôts morts.

Migrer entièrement :

• Projets open source actifs
• Projets personnels que vous seriez triste de perdre si GitHub devenait hostile
• Dépôts avec du code ou de la logique métier sensible

Envisager la mise en miroir (synchro lecture seule GitHub → Codeberg) :

• Dépôts inactifs mais référencés
• Projets publics où la visibilité GitHub a encore son importance

Ignorer / archiver :

• Expériences personnelles depuis longtemps abandonnées
• Dépôts qui n’existent que comme références ou forks

Pour le code commercial propriétaire, évaluez Forgejo auto-hébergé sur Hetzner plutôt que Codeberg. La mission de Codeberg est l’hébergement communautaire open source ; les dépôts commerciaux sont acceptés mais le caractère de la plateforme convient mieux au travail FOSS.

Étape 3 : utiliser l’import GitHub de Codeberg

Codeberg dispose d’un import GitHub intégré :

1. Cliquez sur + → Nouvelle migration
2. Choisissez GitHub
3. Authentifiez-vous via OAuth GitHub (ou utilisez un jeton d’accès personnel)
4. Sélectionnez le dépôt à importer
5. Choisissez ce qu’il faut migrer :
   • ✅ Wiki
   • ✅ Issues
   • ✅ Étiquettes
   • ✅ Pull Requests (en Issues, car GitHub PRs ↔ Codeberg PRs ne sont pas compatibles 1:1)
   • ✅ Releases
   • ✅ Milestones
6. Cliquez sur Migrer le dépôt

Pour les dépôts comptant des milliers d’issues, la migration peut prendre 30-60 minutes. Ne vous inquiétez pas de faire autre chose pendant ce temps — Codeberg gère cela de façon asynchrone.

Étape 4 : mettre à jour les références CI/CD

Codeberg utilise Woodpecker CI (analogue à GitHub Actions). Traduisez vos .github/workflows/*.yml en .woodpecker.yml :

# Exemple : .woodpecker.yml
steps:
  build:
    image: node:20
    commands:
      - npm install
      - npm run build
      - npm test

Pour les workflows GitHub Actions complexes, la traduction peut être non triviale. Alternatives pragmatiques :

• Fournisseurs CI externes prenant en charge Codeberg : Drone Cloud, CircleCI (avec leur intégration Git générique)
• CI auto-hébergé sur Hetzner : GitLab Runner pointé vers Codeberg, ou Woodpecker auto-hébergé

Pour la plupart des projets, la traduction du workflow prend quelques heures et produit une configuration CI plus simple et plus lisible.

Étape 5 : configurer les clés SSH et les remotes Git

Ajoutez votre clé SSH :

1. Codeberg → User Settings → SSH/GPG Keys
2. Collez votre clé publique

Mettez à jour les remotes Git locaux :

# Changer le remote de GitHub vers Codeberg
git remote set-url origin git@codeberg.org:username/repo-name.git

# Ou ajouter Codeberg comme remote supplémentaire (pour la période de run parallèle)
git remote add codeberg git@codeberg.org:username/repo-name.git
git push codeberg --all
git push codeberg --tags

Étape 6 : mettre à jour les README et badges

Les badges et liens spécifiques à GitHub doivent être mis à jour :

• Badges de statut de build → utilisez les badges Woodpecker CI
• Badges de version → Codeberg prend en charge les motifs shields.io
• Compteurs de téléchargements → les releases Codeberg ont des API similaires
• Liens d’issues dans la doc → mise à jour de github.com/user/repo/issues vers codeberg.org/user/repo/issues

Étape 7 : configurer un miroir GitHub (facultatif)

Pour les projets où la visibilité GitHub compte encore (projets open source découverts via la recherche GitHub), conservez GitHub comme miroir en lecture seule :

# Codeberg a une fonctionnalité "Push Mirror" intégrée
# Repository Settings > Repository > Push Mirror
# Ajoutez github.com/user/repo avec un jeton d'accès personnel

Cela conserve Codeberg comme source de vérité tout en maintenant une présence sur GitHub.

Étape 8 : archiver ou supprimer les dépôts GitHub

Après 30 jours de confiance :

• Archiver (recommandé) : Repository Settings → Archive this repository. En lecture seule, conserve l’historique, signale « déplacé » aux visiteurs.
• Supprimer (si vous êtes certain) : Settings → Danger Zone → Delete this repository.

Les deux options fonctionnent. L’archivage est l’option par défaut la plus sûre — elle préserve la trace de migration et vous donne une issue de secours si vous découvrez quelque chose qui n’a pas migré.

Conseils pour une migration fluide

• Migrez d’abord un dépôt comme test. Choisissez un dépôt à faible enjeu pour valider le workflow avant de vous engager dans une migration en masse.
• La complexité de GitHub Actions est la principale friction de migration. Si vos workflows utilisent intensivement des Actions tierces, prévoyez du temps pour les traduire ou les remplacer.
• L’API de Codeberg est similaire mais pas identique à celle de GitHub. L’outillage personnalisé appelant l’API GitHub devra être mis à jour pour utiliser l’API compatible Forgejo de Codeberg.
• Les limites de ressources de Codeberg sont conçues pour le FOSS. Si vous avez de très gros dépôts ou exécutez beaucoup de CI, envisagez Forgejo auto-hébergé sur Hetzner — même logiciel, vos propres ressources.
• Faites un don. Codeberg est financé par les dons. Si vous l’utilisez à long terme, contribuez pour le pérenniser. 5-10 €/mois est significatif pour le projet.
• Pour les organisations qui migrent de grandes bases de code : envisagez Forgejo auto-hébergé comme principal avec un miroir Codeberg pour les projets communautaires. Le meilleur des deux mondes — contrôle complet + visibilité là où elle compte.
• Ne migrez pas tout d’un coup. La plupart des entreprises qui ont réussi à migrer vers Codeberg l’ont fait projet par projet sur 3-6 mois, en validant chacun avant de passer au suivant.