Alternatives européennes à GitLab.

On suppose souvent que GitLab est la réponse européenne à GitHub, mais le service hébergé GitLab.com est exploité par GitLab Inc., une société cotée constituée aux États-Unis (Delaware, cotée au NASDAQ sous GTLB). Cela place GitLab.com dans la portée du CLOUD Act américain de la même manière que GitHub, propriété de Microsoft, couvrant le contenu des dépôts, les journaux de CI, les jetons et l'historique des tickets. Cette page situe les alternatives européennes face à GitLab.com, en vérifiant à qui appartient juridiquement chaque service, où résident les données et quelle posture de conformité chacun peut démontrer pour une analyse d'impact des transferts au titre de Schrems II.

Il existe deux voies vers une posture européenne. La première est de passer à une forge européenne : les deux options ici reposent sur Forgejo, le moteur open source géré par Codeberg e.V. en Allemagne. Codeberg (Allemagne, Berlin, association, hébergé dans l'UE, gratuit, exposition au CLOUD Act : Aucune) est le foyer géré par la communauté pour les projets open source, et 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 100 % européenne. La seconde voie, propre à GitLab, est de garder le logiciel mais d'auto-héberger l'édition communautaire de GitLab sur une infrastructure européenne, ce qui supprime l'exposition directe aux États-Unis tout en conservant l'ensemble exact des fonctions.

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

• Dépôts Git avec tout l'historique des branches et des tags (portables par conception).
• Tickets, merge requests (importées comme pull requests), étiquettes, jalons et versions.
• 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 plateforme DevOps complète de GitLab. L'analyse de sécurité intégrée (SAST, DAST, analyse des dépendances et des conteneurs), l'analytique de chaîne de valeur et les fonctions de conformité étroitement intégrées vont au-delà de ce que couvrent les forges basées sur Forgejo. C'est la principale raison pour laquelle certaines équipes choisissent d'auto-héberger GitLab CE.
• La syntaxe CI/CD de GitLab. Les concepts de CI se reportent, mais les pipelines .gitlab-ci.yml doivent être traduits vers Woodpecker ou le format CI de Codebahn.
• Les intégrations spécifiques à GitLab. Les intégrations de la place de marché et en un clic conçues pour GitLab peuvent nécessiter des webhooks ou du câblage par API sur une forge plus petite.
• La hiérarchie des groupes et sous-groupes. Le modèle de groupes profondément imbriqués de GitLab se reporte sur les organisations et les équipes des alternatives, mais des structures très grandes et profondément imbriquées peuvent devoir être aplaties.

Quitter GitLab.com se résume à quelques étapes, quelle que soit la destination choisie.

1. Choisissez d'abord entre une forge européenne et un GitLab CE auto-hébergé. Si votre équipe dépend de l'analyse de sécurité et de l'étendue DevOps de GitLab, auto-héberger GitLab CE sur une infrastructure européenne conserve l'ensemble des fonctions ; si vous utilisez surtout le flux de forge de base, un service basé sur Forgejo est plus léger à exploiter.
2. Utilisez l'outil de migration Forgejo. Pour Codeberg ou Codebahn, le flux « Nouvelle migration » accepte une URL source GitLab et un jeton d'accès, et récupère le code plus les tickets, merge requests, étiquettes, jalons et versions en une seule passe. Un simple git push --mirror couvre un déplacement du code uniquement.
3. Traduisez votre pipeline de CI. Convertissez .gitlab-ci.yml en un pipeline Woodpecker (Codeberg) ou au format CI de Codebahn, et remplacez les modèles de tâches spécifiques à GitLab par des étapes équivalentes.
4. Repointez les clones, les exécuteurs et les intégrations. Mettez à jour git remote set-url chez chaque développeur, enregistrez de nouveaux exécuteurs de CI si nécessaire, et repointez les webhooks de déploiement et les bots vers l'API de la nouvelle forge.
5. Régénérez les jetons et les variables CI/CD. Les secrets et les clés de déploiement ne migrent pas ; recréez-les sur la destination et faites tourner tout ce qui a été exposé.
6. Conservez le projet GitLab en miroir en lecture seule pendant 60 jours. Archivez plutôt que de supprimer, afin que les tâches de CI ailleurs, les tirages de paquets et les liens de documentation ne cassent pas en silence pendant la bascule.