Se rendre au contenu

Gouvernance d'abord : Forgejo ou Gitea selon la licence

Découvrez comment choisir entre Forgejo et Gitea en privilégiant gouvernance et licence. Conseils de migration, impacts juridiques et alternative gérée...

Gouvernance d’abord : Forgejo ou Gitea selon la licence

Mains branchant un câble Ethernet au bureau

Pour une nouvelle instance, Forgejo s’impose si vous privilégiez la gouvernance communautaire et la pérennité du logiciel libre. Gitea reste pertinent si vous avez besoin d’un support commercial établi ou d’une licence permissive de type MIT. Les deux couvrent encore les mêmes usages quotidiens (dépôts, tickets, pull requests), mais une migration entre les deux exige de vérifier précisément les versions compatibles avant de vous lancer.

En bref:

  • Forgejo offre une licence GPLv3+ garantissant que toute modification reste open source, tandis que Gitea continue d’utiliser la licence permissive MIT.
  • La migration de Gitea vers Forgejo requiert une sauvegarde complète, un test préalable, et une vérification rigoureuse de la compatibilité avec les versions anciennes.
  • Sur le plan fonctionnel, la gestion quotidienne des dépôts, tickets et pull requests reste similaire, mais Forgejo a développé des fonctionnalités indépendantes en matière de fédération et de sécurité.
  • La gouvernance communautaire et la transparence opérationnelle de Forgejo favorisent une stabilité stratégique à long terme pour les institutions soucieuses d’indépendance.
  • La différence principale à considérer concerne la stratégie du projet, la licence GPLv3+ de Forgejo garantissant une pérennité plus contraignante, là où Gitea privilégie la flexibilité commerciale.

Table des matières

Gouvernance, licence et direction du projet : la vraie ligne de fracture

Forgejo est né en 2022 comme un hard fork de Gitea, déclenché par des tensions sur la gouvernance de ce dernier projet et sur la création d’une entité commerciale autour de son code. Depuis, les deux projets ont pris des trajectoires distinctes : Forgejo s’est placé sous l’égide de Codeberg, une association à but non lucratif, tandis que Gitea continue d’évoluer avec un modèle mêlant communauté ouverte et structure commerciale adossée.

La bascule la plus concrète pour un administrateur ou un contributeur touche la licence. Depuis sa version 9.0, Forgejo a relicencié son code en GPLv3+, un copyleft fort qui oblige toute redistribution modifiée à rester ouverte. Gitea, lui, conserve la licence MIT, beaucoup plus permissive.

Cette divergence a des conséquences concrètes :

  • Intégration commerciale : une entreprise qui veut embarquer le code dans un produit fermé trouvera MIT plus souple que GPLv3+.
  • Contributions externes : le copyleft de Forgejo garantit que les améliorations reviennent à la communauté, ce qui rassure les contributeurs attachés à l’éthique du libre.
  • Stabilité du modèle économique : la structure non lucrative de Codeberg limite le risque qu’un rachat ou une levée de fonds change les règles du jeu, un scénario que redoutent une partie des utilisateurs historiques de Gitea.
  • Feuille de route : Forgejo documente publiquement ses arbitrages face à Gitea, notamment sur la sécurité, la localisation et les tests, ce qui donne une visibilité rare sur les priorités du projet.

Ce choix de gouvernance pèse plus lourd, sur le long terme, que n’importe quelle fonctionnalité isolée.

Ce qui reste identique et ce qui commence à diverger

Au quotidien, un développeur qui bascule d’une plateforme à l’autre ne sera pas dépaysé. Les fonctions cœur restent partagées : gestion des dépôts, pull requests, système de tickets, wikis, prise en charge de Git LFS pour les gros fichiers. L’interface d’administration garde la même logique générale, héritée du code commun d’avant le fork.

Les divergences apparaissent surtout sur les couches ajoutées après la séparation :

  • CI/Actions : les deux projets proposent un système compatible avec la syntaxe GitHub Actions, mais Forgejo a fait évoluer son moteur de manière indépendante, avec des correctifs et des restrictions de sécurité qui ne sont pas systématiquement rétroportés vers Gitea.
  • Registres de paquets : la prise en charge des registries (npm, Docker, Maven) progresse sur les deux forges, à des rythmes parfois différents selon les priorités de chaque équipe.
  • Fonctions récentes : Forgejo a introduit des ajustements sur la fédération et sur la gestion fine des permissions qui n’ont pas d’équivalent direct côté Gitea.
  • Marketplace d’actions : l’écosystème d’actions réutilisables reste globalement interopérable, mais certains modules pensés pour l’un ne se comportent pas toujours de façon identique sur l’autre, notamment sur les runners self-hosted.

Concrètement, un pipeline CI/CD simple migre sans douleur. Un pipeline complexe, avec des actions tierces spécifiques, mérite un test avant bascule.

Sécurité, tests et fiabilité des mises à jour

L’un des arguments les plus solides en faveur de Forgejo tient à sa transparence opérationnelle. Le projet publie une politique de sécurité publique, avec un canal dédié pour signaler les vulnérabilités et un historique des correctifs consultable par tous. Cette politique s’accompagne de tests end-to-end et de tests d’upgrade exécutés à chaque changement, une pratique qui limite le risque de régression silencieuse lors d’une montée de version.

À retenir : des analyses récentes sur les forges Git auto-hébergées convergent sur un point : la différence entre Forgejo et Gitea se joue désormais moins sur les fonctionnalités que sur la gouvernance, la licence, la fédération et la stratégie de tests. Ce sont ces critères qui font pencher la balance dans la durée.

Conseil de pro : avant toute mise à jour majeure, consultez les notes de version et les annonces de sécurité du projet que vous exploitez. Une régression sur les hooks ou les webhooks passe souvent inaperçue jusqu’à ce qu’un pipeline CI casse en production.

Pour un administrateur solo, cette discipline de tests réduit concrètement l’angoisse de la mise à jour. Elle explique aussi pourquoi la cadence de correctifs de sécurité de Forgejo est scrutée de près par les administrateurs qui gèrent un dépôt Git privé auto-hébergé exposé sur internet.

Migrer de Gitea vers Forgejo : chemins et précautions

La compatibilité entre les deux projets n’est pas illimitée. Forgejo documente un chemin de migration supporté, qui couvre typiquement les instances Gitea jusqu’à la version 1.22 vers Forgejo v10, puis les versions plus récentes de Forgejo. Si votre instance Gitea est plus récente que ce chemin balisé, la migration directe devient risquée : le format de base de données ou certains schémas internes peuvent avoir divergé sans compatibilité garantie.

La procédure recommandée suit une logique simple :

  1. Sauvegardez la base de données, les dépôts Git et les fichiers de configuration avant toute opération.
  2. Testez sur une instance clonée : restaurez la sauvegarde sur un environnement séparé et lancez la migration à blanc.
  3. Vérifiez l’intégrité des tickets, pull requests, hooks et webhooks après la migration test.
  4. Prévoyez un export/import via API si la version source n’est pas directement prise en charge par le chemin documenté.
  5. Basculez en production seulement après validation complète sur l’environnement de test.

Conseil de pro : ne migrez jamais un dimanche soir sans filet. Gardez l’ancienne instance Gitea accessible en lecture seule pendant au moins une semaine après la bascule, le temps de confirmer qu’aucun webhook externe n’a été oublié.

Dimensionner et exploiter votre forge au quotidien

Le choix entre Forgejo et Gitea compte moins, au final, que la façon dont vous dimensionnez et exploitez votre infrastructure. Pour un usage solo ou une petite équipe de quelques développeurs, un VPS avec des ressources modestes en CPU et mémoire suffit largement à faire tourner la forge elle-même. Les besoins grimpent vite dès que la CI entre en jeu.

  • CI légère et usage solo : un VPS modeste héberge la forge et le runner sans souci.
  • Petite équipe avec builds fréquents : séparez le runner CI de la forge sur une machine distincte, car les runners consomment nettement plus de ressources CPU et mémoire que la forge elle-même.
  • CI lourde (tests longs, builds Docker multiples) : isolez les runners dans des conteneurs scalables pour éviter qu’un pic de charge ne dégrade l’accès à la forge pour toute l’équipe.
  • Stockage : privilégiez un disque NVMe pour les volumes Git LFS et les registries de paquets, qui génèrent beaucoup d’écritures aléatoires.

Un reverse proxy correctement configuré protège l’instance et simplifie la gestion du certificat TLS. Ajoutez des sauvegardes automatisées et un monitoring basique de l’espace disque et de la charge CPU.

Profil d’usage Ressources recommandées Point d’attention
Solo, quelques dépôts 2 vCPU, 4 Go RAM Sauvegardes régulières suffisent
Petite équipe, CI modérée 4 vCPU, runner séparé Surveiller la charge du runner
CI intensive, plusieurs équipes Runners isolés et scalables, NVMe dédié Isolation stricte forge/CI

Quelle forge choisir selon votre profil

Pour un nouveau déploiement personnel ou associatif, Forgejo constitue le choix le plus cohérent si la pérennité communautaire et une gouvernance transparente comptent pour vous. Sa politique de sécurité publique et sa gouvernance non lucrative rassurent particulièrement les administrateurs qui gèrent un git auto hébergé sur la durée, sans filet commercial.

Restez sur Gitea si votre organisation dépend déjà d’un support commercial existant, ou si la licence MIT est une contrainte contractuelle non négociable pour l’intégration dans un produit propriétaire. Les analyses comparatives publiées début 2026 confirment que Gitea garde sa place naturelle dans l’écosystème d’entreprise, là où la compatibilité avec des outils tiers commerciaux prime sur les considérations de gouvernance.

Planifiez une migration si votre priorité bascule vers l’indépendance du projet vis-à-vis d’intérêts commerciaux, ou si vous voulez profiter des avancées de Forgejo sur la fédération. Priorisez d’abord la sauvegarde et le test à blanc, jamais la bascule directe en production.

Combien de personnes font vivre ces projets au quotidien

La taille et la structure de la communauté conditionnent directement la vitesse de correction des bugs et la richesse de la documentation. Forgejo s’appuie sur l’infrastructure de Codeberg, où les dépôts, les actions et les discussions du projet montrent une activité de développement continue, alimentée par des contributeurs attachés au modèle associatif du forge.

Comparaison de l'activité communautaire entre Forgejo et Gitea

Gitea, de son côté, bénéficie d’un historique plus long et d’une base d’utilisateurs plus large, avec un forum communautaire actif et des canaux Discord fréquentés par des administrateurs venus d’horizons variés, du homelab personnel à l’entreprise.

Dans les deux cas, le canal principal de support technique reste le dépôt de code lui-même : les tickets ouverts sur Codeberg pour Forgejo, ou sur la plateforme équivalente pour Gitea, servent à la fois de forum de support et de suivi de bugs. La documentation officielle de chaque projet reste la référence la plus fiable, les tutoriels tiers vieillissant vite sur un logiciel qui évolue à ce rythme.

Pour un administrateur isolé, la réactivité de la communauté compte autant que la qualité du code. Un ticket de sécurité traité en quelques jours sur Forgejo, avec une annonce publique claire, pèse dans la décision au moins autant qu’une fonctionnalité supplémentaire.

Performances observées en usage réel

Sur le papier, Forgejo et Gitea partagent encore une bonne partie de leur base de code historique, ce qui explique des performances comparables sur les opérations courantes : clonage, affichage des diffs, recherche dans les dépôts. Les écarts observés en conditions réelles tiennent moins au moteur lui-même qu’à la configuration du serveur et à la charge des runners CI.

Un point de friction revient régulièrement chez les administrateurs qui font tourner une CI active sur une machine modeste : la forge elle-même reste légère, mais un runner qui compile des images Docker ou exécute des suites de tests longues peut saturer le CPU et ralentir l’interface web pour tous les utilisateurs connectés. C’est pour cette raison que la séparation runner/forge, déjà évoquée pour le dimensionnement, a un impact direct et mesurable sur la réactivité perçue au quotidien.

Sur de gros dépôts avec un historique volumineux, l’utilisation de Git LFS et un stockage NVMe font davantage de différence que le choix entre les deux forges. Les deux projets gèrent correctement la pagination des listes de dépôts et des tickets, même avec plusieurs milliers d’objets, tant que la base de données sous-jacente (PostgreSQL est recommandé en production) est correctement dimensionnée.

Intégrations et extensions disponibles

Les deux plateformes s’intègrent avec les outils standards de l’écosystème DevOps : clients Git classiques, gestionnaires de secrets, outils de scan de vulnérabilités, et systèmes d’authentification externes comme OAuth2 ou LDAP pour le SSO d’entreprise. La compatibilité avec la syntaxe des actions au format GitHub Actions facilite la reprise de workflows existants sans réécriture complète.

Côté webhooks, les deux forges permettent de déclencher des notifications vers Slack, Discord ou des services de déploiement continu externes. Les intégrations avec des outils de gestion de projet tiers restent généralement gérées via webhooks génériques plutôt que par des plugins natifs, contrairement à des plateformes commerciales plus fermées qui proposent des marketplaces d’extensions dédiées.

La différence la plus notable pour l’avenir concerne la fédération via le protocole ActivityPub, une feuille de route que Forgejo explore activement pour permettre à terme des interactions entre instances indépendantes, à la manière du fédivers. Cette orientation reste un chantier en développement plutôt qu’une fonctionnalité mature, mais elle distingue clairement l’ambition de Forgejo de celle de Gitea sur le long terme.

Ergonomie et personnalisation de l’interface

L’interface des deux plateformes hérite d’une base commune héritée du fork, ce qui explique une prise en main quasi identique pour qui connaît déjà l’une des deux. Navigation par dépôt, vue des pull requests avec diff en ligne, tableau de bord des tickets : rien ne dépayse un développeur habitué à l’une des deux forges.

Les options de personnalisation restent comparables : thèmes clairs et sombres, personnalisation du logo et du nom de l’instance, gestion fine des permissions par équipe et par dépôt. Forgejo a poussé un peu plus loin certains réglages de confidentialité et d’accessibilité, en cohérence avec sa politique de sécurité publique et son attention portée à la localisation des interfaces dans plusieurs langues.

Pour un utilisateur non technique amené à consulter occasionnellement un dépôt (relecture de documentation, suivi d’un ticket), l’ergonomie des deux outils demande un minimum de familiarisation avec les concepts Git. C’est un point commun à toutes les forges auto-hébergées, et une des raisons pour lesquelles certaines équipes sans compétence système en interne se tournent vers une solution gérée plutôt que vers l’auto-hébergement pur.

Pourquoi certaines équipes préfèrent déléguer l’exploitation

Choisir entre Forgejo et Gitea suppose déjà d’accepter la charge d’exploitation : mises à jour, sauvegardes, sécurité réseau, dimensionnement des runners. Pour une équipe sans administrateur système dédié, ou soumise à des exigences de conformité sur la localisation des données, cette charge devient vite le vrai coût caché de l’auto-hébergement.

Yundera propose une alternative gérée : un serveur privé personnalisé, hébergé en France, sur lequel vous conservez la propriété totale de vos données et pouvez les exporter à tout moment. La plateforme regroupe plus de 100 applications open source préinstallées, accessibles via votre propre domaine, sans configuration technique de votre côté. Pour une équipe qui veut la souveraineté d’un dépôt Git privé auto-hébergé sans en porter l’exploitation quotidienne, ou pour une PME qui cherche à réduire ses coûts d’infrastructure, la page dédiée aux serveurs privés Yundera détaille le fonctionnement de l’offre.

Notre avis sur ce choix

La plupart des comparatifs traitent Forgejo et Gitea comme deux logiciels presque interchangeables, en misant tout sur des tableaux de fonctionnalités. C’est une erreur de perspective. La vraie question n’est pas « quelle plateforme fait quoi de mieux aujourd’hui », mais « quelle structure de gouvernance voulez-vous soutenir dans cinq ans ». Le relicenciement de Forgejo en GPLv3+ n’est pas un détail juridique anecdotique : c’est un pari sur la pérennité du code face à toute tentative de fermeture future, un pari que la licence MIT de Gitea ne fait volontairement pas.

Notre avis sur ce choix — overview diagram

Ce qui nous frappe, c’est à quel point les deux projets restent proches sur le plan technique tout en divergeant fondamentalement sur les valeurs qu’ils incarnent. Un administrateur pressé se focalisera sur la CI ou les registries de paquets. Un administrateur qui pense à long terme regardera d’abord qui gouverne le projet et sous quelle licence son travail sera redistribué. Nous pensons que cette seconde grille de lecture vieillit beaucoup mieux que la première, surtout pour un git privé auto hébergé destiné à durer.

Reste un angle mort commun aux deux solutions : ni Forgejo ni Gitea ne résolvent la question de l’exploitation quotidienne hébergée. Le vrai choix, pour beaucoup d’équipes, n’est peut-être pas entre les deux forges, mais entre auto-héberger soi-même et déléguer cette charge à un service géré.

— Yundera

Sources

Recommandations

Se connecter pour laisser un commentaire.