Gitea et les alternatives à GitHub : quel hébergement choisir en 2026 ?

GitLab est le choix le plus solide pour remplacer largement GitHub ; Gitea arrive en tête de liste si vous souhaitez administrer la plateforme vous-même. Ces 7 alternatives à GitHub se répartissent entre services gérés et logiciels auto-hébergés. Mais le vrai critère est ce qui doit suivre votre code : revues, tickets, CI/CD et contrôles d’accès.

Informations vérifiées sur les pages officielles des éditeurs le 5 novembre 2026. Ce comparatif repose sur la documentation et les tarifs, sans test pratique de migration. La disponibilité signifie que l’éditeur propose actuellement une inscription, un achat ou une installation ; elle ne signifie pas qu’un compte a été créé ou qu’un contrat a été approuvé.

Les alternatives à GitHub en un coup d’œil

Choisissez le mode d’exploitation avant le fournisseur. Un service géré exploite la plateforme d’hébergement de code pour vous. Un logiciel auto-hébergé vous laisse la maîtrise de son installation, de ses sauvegardes et de sa restauration. Un runner CI auto-hébergé, la machine qui exécute les tâches de compilation, ne suffit pas à transformer un hébergement de code dans le cloud en plateforme auto-hébergée.

Ces prix sont des points d’entrée, pas des forfaits équivalents. Les liens tarifaires de chaque section précisent les conditions de l’éditeur. Une licence logicielle gratuite ne finance pas votre serveur ; un abonnement à un hébergement de dépôts n’inclut pas nécessairement un assistant IA, un outil de suivi des tickets ou une capacité de build illimitée.

Avant de migrer pour le seul prix, comparez l’alternative à la grille tarifaire actuelle de GitHub et à notre analyse des tarifs GitHub. Notez précisément la fonctionnalité qui impose le changement. Sinon, un coût par utilisateur plus bas peut masquer une facture de migration et de maintenance plus élevée.

Quelles alternatives gérées à GitHub choisir ?

L’hébergement géré est le choix logique si personne dans l’équipe n’est responsable de la disponibilité de l’infrastructure de développement. Vos ingénieurs peuvent conserver la maîtrise des permissions des dépôts et exploiter des machines de build privées ; le fournisseur entretient l’application d’hébergement. Dans cette catégorie, la distinction essentielle oppose les plateformes de développement généralistes aux services conçus pour une communauté ou un cloud particulier.

GitLab : le remplacement généraliste le plus solide

GitLab réunit dépôts, suivi des tickets, merge requests et CI/CD, c’est-à-dire l’automatisation de la compilation, des tests et de la livraison du logiciel. C’est la première solution à évaluer pour une entreprise qui souhaite garder ensemble revue de code et livraison après GitHub. Une équipe produit disposant de code applicatif, d’un backlog et d’un pipeline de publication peut examiner tout son cycle de travail dans une même destination. La limite : il s’agit toujours d’une migration de plateforme. Des concepts familiers ne rendent pas les permissions, l’automatisation ou les discussions historiques identiques.

Pour qui : Les responsables techniques qui remplacent plusieurs workflows GitHub liés entre eux.
Point fort : Un importateur GitHub qui prend en charge les métadonnées de collaboration ainsi que les données du dépôt.
Tarifs : Free $0 ; Premium à partir de $29/utilisateur/mois, facturé annuellement, selon la page des tarifs GitLab.
Essai gratuit : L’éditeur propose un essai des offres payantes en complément de l’offre Free permanente.

CI/CD, tickets et revues : Tout fait partie de la plateforme. Les merge requests correspondent aux pull requests de GitHub : des propositions de modification dont les relecteurs discutent avant la fusion. GitLab.com Free affiche une limite de 5 utilisateurs par groupe de premier niveau et 400 minutes de calcul par mois. Un groupe de premier niveau est le conteneur organisationnel qui rassemble projets et membres. Ne transposez pas ces quotas hébergés à une installation administrée par vos soins, et n’y voyez pas l’achat de ressources de calcul dédiées.

Assistant de développement IA : GitLab Duo est l’offre IA de l’éditeur, avec une assistance dans les extensions pour IDE et l’interface GitLab, ainsi que des agents et des workflows automatisés. Un IDE est l’environnement d’édition dans lequel les développeurs écrivent et déboguent leur code. La disponibilité et l’utilisation dépendent de l’offre, du déploiement et des GitLab Credits ; un compte d’hébergement Free ne garantit pas l’accès gratuit à toutes les fonctionnalités Duo. La documentation Duo décrit aussi l’hébergement de modèles compatibles et d’une passerelle IA, dont le déploiement doit être évalué séparément.

Import depuis GitHub : La documentation de l’importateur GitHub couvre les données du dépôt, les tickets, les pull requests, les commentaires et d’autres métadonnées du projet. Les organisations ou groupes GitHub ne sont pas migrés en tant qu’organisations ou groupes. L’import des pièces jointes Markdown est facultatif : supprimer trop tôt la source peut donc casser des liens historiques. La nuance compte lorsqu’un ancien ticket d’incident contient la seule capture d’écran expliquant une panne en production.

GitLab vs GitHub : le critère qui fait basculer le choix

Choisissez GitLab si réunir livraison et collaboration justifie de modifier votre façon de travailler. Restez sur GitHub si votre principale difficulté peut être résolue par une politique d’accès ou des contrôles de facturation, et si vos publications dépendent fortement des intégrations existantes. Partir parce qu’un assistant déplaît, sans vérifier si Duo sera lui aussi activé, ne résout pas la question de politique interne.

Pour le pilote, choisissez un dépôt dont l’historique révélera les problèmes : une revue clôturée avec des commentaires, une pièce jointe à un ticket et un processus de publication actif. Un dépôt presque vide ne démontre pas grand-chose. Faites examiner le résultat par un développeur et par la personne qui valide les mises en production ; ils repèrent des défauts différents.

1. 1

   Préparer la destination et limiter les accès d’import

   Créez le groupe de destination et vérifiez que l’utilisateur chargé de l’import possède le rôle Maintainer ou Owner requis. Activez la source d’import GitHub si vous administrez GitLab vous-même. Utilisez une connexion OAuth approuvée ou la méthode documentée par jeton, avec un périmètre limité à la migration.

2. 2

   Lancer l’importateur GitHub

   Sélectionnez Create new, puis New project/repository, Import project et GitHub. Autorisez l’accès, choisissez le dépôt et vérifiez l’espace de noms de destination ainsi que les paramètres facultatifs des pièces jointes avant de démarrer.

3. 3

   Valider séparément l’historique de collaboration

   Comparez les branches, tags, tickets, commentaires de revue et pièces jointes à la source. Vérifiez explicitement les identités et les accès. Conservez GitHub pendant la résolution des écarts ; un import terminé ne prouve pas que tous les liens historiques fonctionnent.

4. 4

   Reconstruire le circuit de publication avant la bascule

   Configurez le pipeline de destination, les identifiants et les validations de publication. Répétez une publication et un retour arrière. Désignez ensuite le nouveau dépôt de référence et supprimez les accès temporaires de migration. La mise en miroir des dépôts de GitLab ne synchronise pas les modifications ultérieures des pull requests GitHub.

Bitbucket Cloud : pertinent quand Jira organise déjà le travail

Bitbucket Cloud est le service géré de dépôts et de revue de code d’Atlassian, avec Pipelines pour les builds et les déploiements. Il convient aux entreprises dont les développeurs planifient déjà leur travail dans Jira et souhaitent relier l’activité des dépôts aux tâches correspondantes. L’intérêt concret est de garder chaque modification reliée au besoin qui l’a motivée. La limite concerne les tickets : les fonctions natives Issues et Wikis de Bitbucket ont été retirées. Ce n’est donc plus un choix pertinent pour qui cherche précisément un petit outil de suivi autonome à côté de chaque dépôt.

Pour qui : Les équipes disposant déjà d’un workflow Jira bien établi.
Point fort : L’activité des dépôts et des pipelines reliée au suivi du travail.
Tarifs : Gratuit jusqu’à 5 utilisateurs ; Standard à partir de $3.65/utilisateur/mois selon la page des tarifs Bitbucket.
Essai gratuit : Des essais Standard et Premium sont proposés.

CI/CD, tickets et revues : Pipelines est intégré ; l’offre Free annonce 50 minutes de build par mois. Les pull requests et les relecteurs sont pris en charge, tandis que les contrôles de fusion obligatoires sont à examiner dans les offres payantes. Pour les tickets, prévoyez Jira ou un autre outil. L’annonce de retrait d’Issues et Wikis confirme leur suppression le 20 août 2026.

Assistant de développement IA : L’offre d’Atlassian est Rovo Dev, qui comprend l’assistance au développement et la revue de code, mais son conditionnement commercial évolue. L’avis de transition Rovo Dev indique que le produit autonome approche de sa fin de vie, que Code Reviewer rejoint les abonnements Jira et Teamwork Collection éligibles, et que la CLI évolue vers Rovo CLI. La date définitive de fin de vie du produit autonome n’était pas confirmée sur la page consultée. Demandez quels droits s’appliquent à votre organisation ; ne construisez pas votre budget en supposant qu’un siège Bitbucket inclut automatiquement un assistant autonome inchangé.

Import depuis GitHub : Passez par Create, Repository, puis Import repository, avec l’URL du dépôt GitHub et une authentification si nécessaire. Atlassian documente un importateur de dépôt, pas un transfert complet des tickets GitHub, des revues et des politiques organisationnelles. Traitez ces éléments comme des chantiers distincts.

Pour une équipe qui utilise déjà Jira, rattacher les tickets GitHub au projet existant peut être une remise en ordre utile. Pour une petite entreprise qui n’utilise que GitHub Issues, cela peut au contraire ajouter un système à administrer. Déterminez qui entretiendra les liens entre tickets et les références historiques avant de considérer le prix par siège comme une économie.

Verdict : Bitbucket se justifie par le workflow Atlassian. Si vous ne voulez pas de Jira, cet avantage perd beaucoup de poids.

Azure DevOps Services : solide pour la planification et la livraison dans l’écosystème Microsoft

Azure DevOps Services est la suite hébergée de Microsoft qui rassemble Repos, Boards et Pipelines. Elle convient lorsque les éléments de travail, les processus de publication et l’administration de l’organisation comptent davantage que la reproduction de l’expérience communautaire de GitHub. Une entreprise qui développe des applications internes peut conserver dans la suite la tâche, la modification de code et les discussions de déploiement. Sa limite tient au périmètre : migrer vers Azure Repos ne préserve pas toutes les fonctions propres à GitHub, y compris celles qui portent le nom Copilot.

Pour qui : Les organisations qui souhaitent réunir planification et infrastructure de livraison.
Point fort : Les éléments de travail Boards reliés aux dépôts et aux pipelines.
Tarifs : Basic comprend les 5 premiers utilisateurs gratuits, puis $6/utilisateur supplémentaire/mois, selon la page des tarifs Azure DevOps.
Essai gratuit : Le quota gratuit Basic est permanent ; il est distinct de l’essai Test Plans.

CI/CD, tickets et revues : Azure Pipelines assure la CI/CD, Boards suit les éléments de travail et Repos propose les pull requests. Le quota gratuit de pipelines hébergés annoncé comprend un job parallèle avec 1,800 minutes par mois. Un job parallèle est la capacité d’exécuter un job à la fois, pas la promesse que tous les builds en attente démarrent ensemble. La documentation actuelle des jobs parallèles précise que l’association d’un abonnement Azure valide active le quota gratuit pour les projets privés.

Assistant de développement IA : La revue de code GitHub Copilot pour Azure Repos est en préversion publique, avec des contrôles au niveau de l’organisation et du dépôt, et une facturation via un abonnement Azure lié. Elle peut commenter les modifications avant la revue humaine. En revanche, la fonction distincte d’Azure Boards qui demande à Copilot d’implémenter un élément de travail exige toujours un dépôt GitHub. La documentation de revue Azure Repos et les prérequis de l’intégration de développement Boards décrivent des intégrations différentes. Affirmer globalement que « Copilot fonctionne » ou que « Copilot est indisponible » manque de précision pour cet achat.

Import depuis GitHub : Utilisez le parcours d’import de dépôt avec l’URL Git source et l’authentification requise. Le guide d’import Git de Microsoft couvre l’import vers un dépôt de destination nouveau ou vide. Large File Storage, ou LFS, conserve les gros fichiers binaires hors des objets Git ordinaires : ses pointeurs peuvent arriver avec le dépôt alors que les fichiers sous-jacents restent à transférer. Traitez séparément les tickets GitHub et l’historique des pull requests.

Le pilote utile porte sur un service existant avec un artefact de build et une validation de déploiement, plutôt que sur une bibliothèque ne contenant que du code source. Demandez au responsable des publications de suivre une modification depuis son élément de travail Boards jusqu’au déploiement terminé. Si ce parcours est plus clair que l’actuel, la suite rend service. Si les développeurs doivent désormais mettre à jour manuellement plusieurs outils de suivi, la migration a créé un problème de coordination.

Codeberg : excellent pour le logiciel libre, inadapté à un produit propriétaire privé

Codeberg est une forge hébergée à but non lucratif : un service de code et de collaboration fondé sur Forgejo. C’est un choix solide pour une bibliothèque publique ou un projet communautaire dont les contributeurs souhaitent une gouvernance du logiciel libre. Sa limite est l’éligibilité : ce n’est pas un hébergement commercial généraliste pour le code privé de votre SaaS. La mission et les règles d’utilisation des ressources font partie du choix du produit ; elles ne sont pas des détails à régler après la migration.

Pour qui : Les projets libres et open source en accord avec la mission de l’association.
Point fort : Un hébergement communautaire avec une position explicite sur l’entraînement de l’IA.
Tarifs : $0 pour les usages éligibles, financés par des dons facultatifs et les adhésions, selon la FAQ Codeberg.
Essai gratuit : L’hébergement éligible est permanent ; il n’existe pas de parcours commercial allant de l’essai à une offre supérieure.

CI/CD, tickets et revues : Les tickets et les pull requests sont disponibles. Woodpecker CI nécessite une demande d’accès et une approbation manuelle. Forgejo Actions peut utiliser des runners auto-hébergés ; un service hébergé limité est en alpha ouverte. La documentation CI expose ces conditions. « CI disponible » ne signifie pas que chaque nouveau projet reçoit immédiatement une flotte de runners gérés.

Assistant de développement IA : Aucun assistant de développement maison n’est annoncé dans les pages produit consultées. Codeberg affirme ne pas utiliser les données des projets ou des utilisateurs hébergés pour entraîner l’IA générative, et restreint les projets largement générés par des LLM. Son explication publique de cette politique distingue aussi les communautés actives établies et les contributions générées occasionnelles des projets créés ou entretenus massivement par des agents. N’en déduisez pas que toute contribution historique issue de l’IA exclut automatiquement un projet.

Import depuis GitHub : Choisissez le menu plus, New Migration puis GitHub ; fournissez ensuite le jeton d’accès requis et sélectionnez les métadonnées à transférer. Le guide de migration Codeberg couvre les tickets, étiquettes, publications, jalons et autres métadonnées prises en charge. Choisir la source Git générique transfère le contenu du dépôt sans ces métadonnées supplémentaires. Révoquez le jeton de migration après validation du transfert.

Pour une dépendance publique entretenue par des bénévoles, la première expérience d’un nouveau contributeur compte autant que l’import. Publiez les nouvelles consignes de contribution, expliquez où se déroulent les revues et indiquez sans ambiguïté l’emplacement de référence du projet. Déplacer le dépôt sans faire évoluer les habitudes de la communauté oblige les mainteneurs à surveiller deux endroits.

Codeberg exploite la plupart de ses services sur son propre matériel à Berlin, mais sa FAQ décrit d’autres lieux et fournisseurs pour certaines tâches. C’est une information utile sur l’infrastructure, pas un engagement contractuel garantissant que chaque copie de données reste en Allemagne. Pour une entreprise de logiciel propriétaire soumise à des exigences strictes de localisation, évaluez votre propre déploiement hébergé plutôt que de chercher à obtenir une exception par un don.

SourceHut : choisir en connaissance de cause le workflow par e-mail et la politique IA

SourceHut est une suite de développement open source centrée sur Git, les listes de diffusion, le suivi des tickets et les builds. Elle convient aux mainteneurs qui veulent relire les patchs par e-mail, avec des outils web en complément, plutôt que reproduire les pull requests de GitHub. Un projet dont les contributions sont déjà discutées sur une liste de diffusion a une raison claire de l’évaluer. Ses limites sont le changement de workflow, son statut d’alpha publique et une politique IA du service hébergé qui exclut de nombreuses pratiques actuelles de développement.

Pour qui : Les projets qui préfèrent explicitement la revue de patchs par e-mail.
Point fort : Une collaboration de développement construite autour des listes de diffusion.
Tarifs : Les abonnements d’hébergement commencent à $4/mois avant taxes applicables ; tous les niveaux payants donnent accès aux mêmes services, selon la page des tarifs SourceHut.
Essai gratuit : Le paiement est actuellement facultatif pour de nombreux services pendant l’alpha, mais les builds sont payants ; les contributeurs n’ont pas à payer pour simplement participer.

CI/CD, tickets et revues : La suite comprend builds.sr.ht pour la CI, todo.sr.ht pour les tickets et la revue de patchs par liste de diffusion, avec des outils web. Un patch est une proposition de modification du code envoyée pour relecture ; les mainteneurs en discutent et appliquent une révision acceptée. L’automatisation de la livraison reste à configurer pour votre projet. L’abonnement ne fournit pas un système de publication prêt à l’emploi.

Assistant de développement IA : SourceHut annonce explicitement l’absence de fonctions IA. Son changement de politique sur l’IA est allé plus loin pour les nouveaux projets à compter du 10 septembre 2026 : les contenus originaux écrits ou assistés par l’IA générative, ainsi que les logiciels facilitant l’IA générative, sont interdits sur le service hébergé, sous réserve de l’interprétation et des exceptions précisées. L’explication autorise l’analyse ou la revue privée si vous rédigez ensuite vous-même le contenu original. Une équipe qui soumet régulièrement du code écrit par un assistant ne devrait pas choisir ce service hébergé.

Import depuis GitHub : Le manuel du service Git décrit comment reprendre des sources hébergées ailleurs en les clonant puis en les ajoutant à git.sr.ht. Il s’agit d’un parcours de transfert Git. Cela ne prouve pas que les discussions des pull requests GitHub deviendront des fils de liste de diffusion équivalents, ni que les tickets seront automatiquement repris dans l’outil de suivi. Inventoriez-les séparément et décidez de ce qui doit rester consultable en archive.

Avant de transférer un projet d’entreprise, demandez à une personne nouvellement arrivée de suivre les consignes de contribution prévues. Peut-elle soumettre un patch, répondre aux retours et retrouver la révision acceptée ? Un workflow limpide pour un mainteneur expérimenté peut imposer un effort d’apprentissage à tous les autres. Cela peut se justifier, mais doit relever d’un choix d’exploitation délibéré.

Le logiciel peut aussi être auto-hébergé. Distinguez cette possibilité de l’éligibilité au service hébergé de SourceHut : exécuter le logiciel sur une infrastructure que vous administrez implique un autre modèle de déploiement et de responsabilité.

AWS CodeCommit : de nouveau disponible, avec un périmètre plus restreint

AWS CodeCommit est un service géré de dépôts Git privés destiné aux organisations qui veulent inscrire l’accès aux dépôts dans leur modèle d’exploitation AWS. Il mérite une place dans la sélection lorsque les permissions d’identité AWS et les frontières réseau sont des exigences centrales. L’annonce de réouverture d’AWS indique explicitement qu’il accepte de nouveau les nouveaux clients. Certaines anciennes bannières de pages AWS disent encore le contraire ; l’annonce de réouverture et l’historique actuel de la documentation remplacent cet avis de fermeture.

Pour qui : Les organisations centrées sur AWS ayant une exigence précise sur le périmètre d’accès aux dépôts.
Point fort : L’accès aux dépôts intégré aux services d’identité et d’infrastructure AWS.
Tarifs : Un quota gratuit est disponible ; l’usage payant coûte $1/utilisateur actif/mois, plus les dépassements applicables, selon la FAQ tarifaire CodeCommit.
Essai gratuit : L’éditeur publie un quota permanent, pas un essai à durée limitée de toute une plateforme.

CI/CD, tickets et revues : CodeCommit prend en charge les pull requests et la collaboration de revue. L’automatisation des builds et de la livraison passe par des services distincts comme AWS CodeBuild et AWS CodePipeline. Prévoyez séparément le suivi des tickets. Il s’agit d’un assemblage de services : comparez le workflow et les factures qui en résultent plutôt que d’assimiler l’hébergement des dépôts à un abonnement de développement tout-en-un.

Assistant de développement IA : AWS propose Amazon Q Developer pour l’assistance au développement. C’est une offre distincte ; acheter CodeCommit ne prouve pas qu’un assistant natif sera automatiquement ajouté à chaque dépôt ou revue. Séparez le choix de l’hébergement des dépôts et les droits d’accès à l’assistant.

Import depuis GitHub : AWS documente une migration de dépôt Git : récupérer le dépôt Git existant, créer la destination CodeCommit et transférer le code. Ce parcours n’importe pas pour autant GitHub Issues, les conversations des pull requests ou les workflows Actions. Ce sont des systèmes distincts à remplacer ou à conserver.

Le bon pilote démontre le fonctionnement des accès et de la livraison dans la configuration AWS prévue. L’identité développeur attendue peut-elle récupérer le dépôt ? L’identité de build peut-elle accéder uniquement aux sources nécessaires ? La publication peut-elle se dérouler avec les permissions prévues ? Ces questions expliquent pourquoi une équipe peut choisir CodeCommit même lorsqu’une autre forge propose une interface plus unifiée.

Verdict : Retenez-le si l’intégration AWS motive le changement. Pour un fondateur qui cherche simplement un remplacement familier de GitHub, évaluez d’abord GitLab ou Gitea.

Auto-hébergement : Gitea, GitLab et le travail d’exploitation

L’auto-hébergement convient surtout si vous devez choisir l’infrastructure, administrer l’application et maîtriser sa restauration. Il vous donne aussi la responsabilité des pannes. La question décisive est de savoir si quelqu’un pourra restaurer le service après une défaillance de disque, de base de données ou de mise à jour, plutôt que de juger la simplicité apparente de l’installation.

Gitea : le premier choix à évaluer pour une forge auto-hébergée

Gitea est une forge open source réunissant dépôts, tickets, pull requests et automatisation. C’est le meilleur point de départ pour une petite organisation technique qui souhaite exploiter sa propre plateforme de code sans adopter d’emblée une suite plus vaste. Une équipe chargée des outils internes peut conserver les revues et les tâches près des dépôts tout en choisissant où le service s’exécute. Sa limite tient à la responsabilité d’exploitation : la licence gratuite ne fournit ni sauvegardes, ni supervision, ni isolation des runners, ni personne chargée de la restauration.

Pour qui : Les équipes qui veulent une forge administrée par leurs soins et peuvent en assumer l’exploitation.
Point fort : Dépôts, tickets, pull requests et Actions dans le produit open source.
Tarifs : Open Source coûte $0 sous licence MIT ; hébergement et administration s’ajoutent, selon la page des tarifs Gitea.
Essai gratuit : L’usage open source est permanent ; l’éditeur propose séparément des essais commerciaux.

CI/CD, tickets et revues : Gitea comprend les tickets et les pull requests, avec Gitea Actions pour la CI/CD. Sa documentation Actions précise que le système est en grande partie compatible avec GitHub Actions et utilise un programme runner distinct. « En grande partie » compte. Un fichier de workflow familier facilite la migration ; il ne prouve pas que chaque action, hypothèse de permission et intégration se comportera à l’identique.

Assistant de développement IA : Aucun assistant de développement maison n’est annoncé sur les pages produit et tarifaires de l’éditeur consultées. Cette observation est plus restreinte qu’une interdiction de l’IA. Si vous utilisez un assistant d’éditeur ou un bot de revue distinct, évaluez indépendamment son accès aux dépôts, son traitement des données et la prise en charge des intégrations.

Import depuis GitHub : La documentation de migration Gitea décrit son formulaire intégré de migration GitHub, notamment les tickets et les pull requests lorsque les informations de compte requises sont fournies. Importez un projet représentatif, puis examinez les discussions et les identités. Faites de la configuration Actions et des secrets un autre test de validation.

Une application interne privée peut, par exemple, avoir un workflow de test simple mais un job de publication qui suppose la présence d’un fournisseur d’identité hébergé particulier. Réutiliser le job de test ne valide pas celui de publication. Votre pilote doit atteindre l’environnement de déploiement et démontrer la restauration avant que vous annonciez la migration comme terminée.

Gitea commercialise aussi des offres gérées Cloud et Enterprise ; le produit n’est donc pas exclusivement auto-hébergé. Cette recommandation concerne le déploiement Open Source que vous administrez. Les contrôles d’entreprise comme l’authentification unique SAML, qui relie la connexion au système d’identité de votre organisation, doivent être vérifiés pour l’édition choisie plutôt que supposés présents dans l’installation gratuite.

Gitea vs GitLab : choisir le périmètre d’exploitation nécessaire

Choisissez Gitea si une forge ciblée couvre vos besoins et si vous pouvez l’exploiter. Choisissez GitLab Self-Managed si le workflow GitLab plus étendu motive le changement et si vous acceptez l’administration qu’il impose. Ne retenez ni l’un ni l’autre au seul motif que le logiciel se télécharge sans facture d’hébergement. Le coût d’exploitation comprend la personne qui enquête sur une sauvegarde défaillante et le temps perdu par les développeurs pendant une panne.

Codeberg est le service géré ; Forgejo est le logiciel sur lequel il repose. Auto-héberger Forgejo est une option distincte de l’ouverture d’un compte Codeberg. Le logiciel SourceHut peut lui aussi être installé sur votre infrastructure. Ces distinctions évitent une erreur fréquente : confondre un service hébergé open source avec la promesse que son fournisseur exploitera votre installation privée.

L’offre auto-administrée de Bitbucket exige une vérification d’éligibilité distincte. La page Hybrid License d’Atlassian précise que cette offre s’adresse aux clients existants de Bitbucket ou Bamboo Server/Data Center. Ce n’est pas une voie d’auto-hébergement pour une entreprise qui part de GitHub sans installation existante. De même, l’annonce générale du retrait de Data Center ne signifie pas que tout le produit Bitbucket auto-administré disparaît.

Quelle alternative à GitHub pour votre équipe ?

Si le prix est le principal problème, comparez l’environnement de travail complet avant de migrer. Pour une petite entreprise, commencez par les quotas gratuits hébergés. Incluez la capacité de build, le suivi des tickets, les contrôles d’identité requis et l’accès aux assistants. Ne changez que si l’économie ou le gain de maîtrise résiste au travail nécessaire pour reproduire votre processus de publication.

Si la maîtrise de l’infrastructure est impérative, commencez par Gitea et GitLab Self-Managed. Le choix penche vers GitLab lorsque la plateforme élargie remplace suffisamment d’outils distincts pour justifier son périmètre d’exploitation. Il penche vers Gitea lorsque le besoin se limite aux dépôts, tickets, revues et à un dispositif CI adapté.

Si l’intégration à un écosystème prime, suivez l’endroit où le travail est déjà coordonné. Bitbucket convient à une planification dans Jira. Azure DevOps convient à un workflow Boards et Pipelines. CodeCommit répond à une exigence précise de dépôt AWS. Adopter un nouvel écosystème pour éviter une facture peut créer davantage d’administration qu’il n’en supprime.

Si le projet est public et porté par une communauté, faites de l’adéquation aux contributeurs le critère décisif. Codeberg est le choix le plus évident pour un projet libre qui veut une forge familière. SourceHut s’adresse aux mainteneurs qui choisissent activement son workflow de revue de patchs et peuvent respecter ses règles sur l’IA. Aucun des deux ne devrait être retenu uniquement parce qu’un titre le présente comme gratuit.

Alternatives à GitHub Actions : tester d’abord le job de publication

GitLab CI/CD, Bitbucket Pipelines, Azure Pipelines, Gitea Actions, les options CI de Codeberg et les builds SourceHut couvrent différents modèles d’exploitation. CodeCommit se connecte à une chaîne de livraison AWS distincte. L’unité à migrer est donc le pipeline qui fonctionne, pas son fichier de configuration.

Inventoriez les étapes qui dépendent de l’hébergeur actuel : récupération du code, caches, accès aux paquets, identifiants de déploiement, étapes de validation et notifications. Testez tôt le job de publication le plus contraint. S’il ne peut pas s’exécuter en sécurité sur la destination, un import de dépôt réussi n’a pas levé le blocage. La compatibilité de Gitea peut réduire la réécriture, mais ne doit pas supprimer ce test.

Alternatives à GitHub Copilot : distinguer l’assistant de l’hébergeur

Changer le remote Git ne décide ni de l’assistant qu’un développeur peut utiliser, ni de la destination du contexte qu’il transmet. GitLab propose Duo ; Atlassian propose des outils Rovo pour développeurs en cours de transition ; l’intégration de revue Azure Repos de Microsoft utilise GitHub Copilot ; AWS propose Amazon Q Developer séparément. Les pages Gitea examinées n’annoncent pas d’équivalent natif, tandis que Codeberg et SourceHut font des choix de politique qui dépassent la seule sélection d’un assistant.

Rédigez précisément l’exigence : aucun entraînement sur le code soumis, aucun traitement externe, aucune contribution générée ou aucune dépendance envers un fournisseur particulier. Ce sont des politiques différentes. Une plateforme peut en satisfaire une et échouer sur une autre. Utilisez notre guide des tarifs GitHub Copilot pour évaluer la facture de l’assistant séparément de l’hébergement des dépôts.

Résidence des données : suivre le code au-delà du dépôt

L’emplacement du dépôt n’est qu’une partie de la question de localisation des données. Un runner de build peut recevoir du code source, un journal peut contenir des sorties sensibles et un service IA peut recevoir des extraits indépendamment du lieu de stockage des objets Git. Pour un responsable technique qui répond à une exigence client, le livrable utile est une cartographie de ces transferts et des contrats qui les encadrent.

La documentation Microsoft sur la localisation des données Azure DevOps décrit les zones géographiques sélectionnables, notamment l’Europe et le Canada, ainsi que des exceptions limitées à la localisation des données client. Codeberg décrit l’emplacement de ses infrastructures, mais ne remplace pas un contrat d’hébergement commercial privé. L’auto-hébergement vous donne le choix du déploiement ; il ne contraint pas automatiquement un assistant externe ou un service de build.

Demandez où résident dépôts, bases de données, sauvegardes et journaux ; depuis où le support peut y accéder ; et quels sous-traitants reçoivent du code. Faites ensuite la même vérification pour la CI et l’IA. Si l’exigence est « aucun code ne sort de cet environnement », appliquez-la aux connexions concernées plutôt que de considérer le choix d’une région d’hébergement comme une réponse complète.

Ce que vous perdez en quittant GitHub

Vous renoncez à une partie de la facilité qu’offre le réseau GitHub : les contributeurs potentiels ont déjà un compte, connaissent l’interface de revue et peuvent découvrir un projet via des profils et des dépôts familiers. Vous perdez aussi la possibilité de présumer qu’un composant de la marketplace Actions fonctionnera tel quel, avec les mêmes permissions et intégrations, sur la destination. La découverte de votre projet open source repose davantage sur vous, même si l’alternative possède une communauté compétente. Ces coûts comptent davantage pour un outil public destiné aux développeurs qui recrute des contributeurs que pour une application interne privée. Un miroir public peut préserver la visibilité, mais il exige des consignes de contribution sans ambiguïté et un emplacement de référence clair ; sinon, vous créez des tickets et des revues en double que les mainteneurs devront surveiller.

Comment cette sélection a été établie

La sélection privilégie les éléments nécessaires à une décision complète plutôt que le classement par nombre de fonctionnalités. Chaque solution a été vérifiée sur sa disponibilité actuelle, son mode d’hébergement, sa CI/CD, ses tickets et revues, l’offre IA annoncée par l’éditeur, le parcours d’import GitHub et le tarif d’entrée publié. GitLab, Bitbucket, Azure DevOps et Gitea affichaient des parcours d’inscription, d’achat, d’essai ou de téléchargement ; Codeberg et SourceHut proposaient l’inscription ; AWS confirmait explicitement la réouverture des inscriptions.

Le comparatif a été vérifié le 5 novembre 2026 à partir des pages officielles de produits, de tarifs et de documentation. Aucune mesure de performance, aucun test de délai de réponse du support et aucune migration d’essai n’ont été réalisés. Les recommandations expriment un jugement sur l’adéquation aux workflows à partir de ces éléments. Une appréciation favorable ne prime pas sur les règles d’éligibilité d’un projet ni sur la nécessité de tester son véritable processus de publication.

Les choix à écarter selon votre situation

Écartez Codeberg pour une entreprise qui développe un produit propriétaire privé. Sa mission est une raison de le choisir pour le logiciel libre et de l’exclure pour l’hébergement commercial privé ordinaire. Des dons facultatifs n’achètent pas une autre politique d’utilisation acceptable.

Écartez SourceHut hébergé si votre processus normal de contribution dépend de code généré ou si votre produit facilite l’IA générative. Sa politique actuelle pose un véritable problème de compatibilité, pas une question de réglage facultatif d’assistant. Écartez-le aussi si vos contributeurs ont besoin d’une expérience de revue proche de GitHub et si personne n’a prévu le temps de formation au workflow.

Ne considérez pas Bitbucket Hybrid comme une voie d’achat pour un nouvel auto-hébergement. La page d’éligibilité vise explicitement les clients existants. Évaluez l’offre Cloud présentée ici, ou choisissez un logiciel que vous pouvez déployer vous-même.

Écartez CodeCommit comme remplacement tout-en-un par défaut. Il peut être le bon service de dépôts AWS, mais le workflow de tickets et de livraison qui l’entoure reste à concevoir. Son ancienne fermeture aux nouveaux inscrits n’est plus une raison valable de l’écarter.

Écartez toute migration dont la seule preuve est un clone réussi. Si les relecteurs ne retrouvent pas les décisions à l’origine du code, ou si la destination ne permet pas de le publier, la migration de plateforme n’est pas terminée.

Votre checklist de validation de migration

Validez la migration couche par couche pour éviter qu’un transfert de dépôt propre masque un workflow défaillant. La checklist ci-dessous est un cadre d’évaluation ; elle n’affirme pas que chaque importateur transfère toutes les couches.

1. 1

   Vérifier que le dépôt est complet

   Comparez les branches et tags attendus, examinez des commits représentatifs et confirmez que les gros fichiers sont récupérables. Gardez une sauvegarde indépendante et conservez la source jusqu’à la validation de la migration.

2. 2

   Vérifier que les décisions restent consultables

   Examinez un ticket, une revue clôturée, une pièce jointe et une note de publication. Décidez quels éléments historiques manquants seront importés, archivés ou reliés par un lien. Confiez à quelqu’un la résolution des références cassées.

3. 3

   Vérifier que la destination permet de publier

   Configurez explicitement les identifiants, l’accès aux artefacts et les validations de déploiement. Exécutez le processus de publication vers une cible sans risque, puis répétez la restauration. Révoquez les identifiants temporaires d’import après validation.

4. 4

   Vérifier les accès et les responsabilités de bascule

   Contrôlez les accès d’un développeur, d’un relecteur, d’une identité de build et d’un utilisateur quittant l’organisation. Planifiez la synchronisation finale, annoncez où soumettre les nouvelles contributions et désignez la personne habilitée à revenir en arrière.

Votre prochaine séance de travail devrait produire le résultat d’un pilote : choisissez la destination qui répond à la contrainte impérative, migrez un dépôt représentatif et faites valider le workflow par son responsable de publication. Élargissez ensuite le périmètre à partir de ces preuves.

Questions fréquentes

Quelle est la meilleure alternative à GitHub ?

GitLab est le remplacement généraliste le plus solide si vous voulez réunir dépôts, tickets, revues et CI/CD. Gitea est la première option auto-hébergée à évaluer si une forge ciblée couvre vos besoins et si vous pouvez l’exploiter. La dépendance à Jira, les règles communautaires ou un périmètre AWS peuvent modifier cette recommandation.

Vaut-il mieux utiliser TFS ou Git ?

Ce sont des outils de nature différente. Team Foundation Server, le prédécesseur d’Azure DevOps Server, est une plateforme de développement. Git est un système distribué de gestion de versions. Si vous comparez Git à Team Foundation Version Control, la présentation de TFVC par Microsoft explique cette alternative centralisée. Changer d’hébergeur de dépôts ne vous oblige pas à abandonner Git.

La NASA utilise-t-elle Git ?

Oui. La NASA décrit son utilisation de GitHub pour publier des logiciels open source dans sa présentation du développement open source. Cela établit un usage réel de dépôts Git, sans constituer une règle universelle pour tous ses systèmes.

GitHub est-il toujours open source ?

La plateforme hébergée de GitHub est propriétaire. Git, l’outil de gestion de versions sous-jacent, est open source, et GitHub héberge de nombreux projets open source. Ce sont des choses différentes : choisir un projet open source ne revient pas à choisir une plateforme d’hébergement open source.

Pourquoi certains boycottent-ils GitHub ?

Les raisons varient : opposition à l’hébergement propriétaire, à la dépendance fournisseur ou à l’usage de l’IA, entre autres. Codeberg et SourceHut publient des positions explicites sur l’IA et la gouvernance du logiciel, présentées plus haut. Pour votre organisation, traduisez la préoccupation en une exigence vérifiable plutôt que de supposer que toutes les alternatives appliquent les mêmes politiques.

À quoi sert GitHub, expliqué simplement ?

GitHub est un espace de travail partagé pour le code. Il conserve l’historique des modifications, permet de proposer et de relire des mises à jour, et prend en charge le suivi des tickets et l’automatisation. Les alternatives diffèrent par l’étendue de cet espace de travail et par l’acteur qui l’exploite.

GitHub présente-t-il des risques ?

La question utile est celle du risque à maîtriser : accès aux comptes, identifiants exposés, permissions des dépôts, automatisations tierces ou transferts de données. Changer de fournisseur ne supprime pas ces responsabilités. L’auto-hébergement ajoute aussi la responsabilité des correctifs, des sauvegardes et de la restauration.

GitHub appartient-il à 100% à Microsoft ?

Oui. Microsoft a finalisé l’acquisition de GitHub en 2018, comme le rappelle son annonce d’acquisition. Passer à Azure DevOps change la plateforme tout en conservant Microsoft comme fournisseur.

Le gouvernement américain utilise-t-il GitHub ?

Oui. L’usage publié par la NASA constitue un exemple fédéral documenté. Cela ne signifie pas que GitHub, ou une autre solution, est approuvé pour chaque projet public ou chaque catégorie d’information.

Avant de modifier votre environnement de développement, obtenez la checklist d’audit des workflows IA en entreprise pour cartographier ce que le nouveau workflow doit préserver.