Forge Git self-hosted pour équipe PME : Gitea, Forgejo, GitLab CE (2026)

GitHub trop coûteux, Bitbucket opaque, code source hébergé à l’étranger : en 2026, des centaines de PME africaines et francophones franchissent le cap du self-hosting de leur forge Git. Ce guide exhaustif compare Gitea, Forgejo et GitLab CE sur tous les critères qui comptent pour une équipe de 5 à 50 développeurs, avec une adaptation complète au contexte ouest-africain.

Introduction — GitHub, le prix de la commodité

GitHub est devenu l’infrastructure par défaut du développement logiciel mondial. Sa domination est compréhensible : interface soignée, Actions CI/CD puissantes, intégrations illimitées, communauté de dizaines de millions de développeurs. Mais cette commodité a un coût que les PME africaines ressentent de plus en plus concrètement, et pas seulement sur la ligne budget.

Côté financier d’abord. Le plan GitHub Team coûte 4 USD par utilisateur et par mois en 2026, ce qui peut paraître modeste pour un développeur européen mais représente un poste non négligeable pour une structure dakaroise ou abidjanaise qui compte 15 à 30 contributeurs. Multipliez par l’équipe, ajoutez les features avancées comme le stockage LFS étendu, les runners CI auto-hébergés supplémentaires ou la gestion avancée des secrets, et la facture mensuelle en devises étrangères dépasse rapidement 150 000 à 300 000 FCFA. À cela s’ajoutent les plans Enterprise à 21 USD par utilisateur pour les fonctionnalités de sécurité avancées. Pour une structure qui facture en FCFA, payer en USD avec un taux de change qui ronge le budget n’est pas une option pérenne.

Mais le coût pécuniaire n’est que la surface visible du problème. La vraie question — que les responsables techniques africains posent de plus en plus — est celle de la souveraineté du code. Héberger l’ensemble du code source d’un projet stratégique chez un prestataire américain, sous juridiction du CLOUD Act, signifie accepter qu’un tiers puisse y accéder sur injonction judiciaire américaine sans nécessairement en informer la structure cliente. Pour une PME qui développe des logiciels pour des institutions gouvernementales, des structures financières ou des opérateurs de santé, cette dépendance juridique est un risque réel qui devrait figurer dans toute analyse de risque sérieuse.

Le cadre réglementaire africain renforce cette analyse. En Côte d’Ivoire, l’ARTCI (Autorité de Régulation des Télécommunications et TIC) a progressivement développé des exigences de localisation des données pour certaines catégories de données sensibles. Au Sénégal, la Commission de Protection des Données Personnelles (CDP) établit un cadre similaire. Si votre code embarque des données personnelles ou des logiques métier critiques, leur hébergement chez un cloud américain peut entrer en tension avec ces cadres réglementaires émergents. Self-héberger une forge Git sur un VPS en Europe — en attendant des offres IaaS africaines plus matures — constitue une posture bien plus défendable sur le plan de la conformité.

Enfin, il y a la question de la dépendance opérationnelle. GitHub a connu plusieurs incidents majeurs ces dernières années : pannes prolongées affectant les Actions, dégradations de service sur les API, modifications des politiques d’utilisation. Pour une équipe dont la livraison continue dépend d’une forge externe, chaque panne se traduit par un arrêt de production. Une forge self-hosted, même plus modeste techniquement, garantit une disponibilité maîtrisée et une continuité de service que vous contrôlez de bout en bout.

Ce pilier explore les trois solutions les plus sérieuses du marché open-source en 2026 — Gitea, Forgejo et GitLab CE — pour vous aider à choisir, déployer et opérer la forge qui correspond à la réalité de votre équipe et de votre contexte. Trois tutoriels satellites accompagnent ce guide pour les mises en pratique pas à pas.

Pourquoi self-hoster sa forge Git en 2026

La question revient souvent dans les discussions techniques : est-ce vraiment utile de se donner la peine d’héberger une forge Git alors que GitHub propose un plan gratuit pour les projets publics ? La réponse nuancée est oui — mais pour des raisons qui dépendent étroitement de la taille de l’équipe, de la nature des projets et du contexte opérationnel.

La maîtrise des données et du code source est la raison première. Une forge self-hosted signifie que votre code, vos issues, vos pipelines CI/CD, vos clés de déploiement et vos secrets de projet résident sur une infrastructure que vous contrôlez physiquement. Pour tout projet dont le code constitue un actif compétitif ou contient des logiques métier propriétaires, cette maîtrise est fondamentale. Même en utilisant les plans privés de GitHub ou GitLab.com, vous déléguez à un tiers la garde de votre propriété intellectuelle. Sur une forge self-hosted, la question ne se pose pas : vous êtes le seul opérateur.

La réduction du coût total de possession est tangible à moyen terme. Un VPS Hetzner CX22 à 3,79 euros par mois — 4 Go de RAM, 2 vCPU, 40 Go NVMe, 20 To de trafic — suffit à faire tourner Forgejo pour une équipe de 20 développeurs. Ce coût mensuel, converti en FCFA, représente environ 2 500 FCFA. Même en ajoutant un VPS légèrement plus puissant pour le runner CI et les sauvegardes vers Hetzner Object Storage, vous restez sous 15 000 FCFA par mois pour une infrastructure complète et souveraine. L’économie par rapport aux plans commerciaux est réelle et croît proportionnellement à la taille de l’équipe.

La personnalisation profonde est un avantage sous-estimé. Les forges self-hosted permettent des intégrations impossibles ou coûteuses sur les plateformes commerciales. Connecter votre forge à votre serveur WhatsApp Business via webhooks pour notifier les développeurs d’un merge request, synchroniser vos issues avec un système de gestion de projet interne, ou déployer automatiquement sur un cloud africain qui n’est pas supporté nativement par GitHub Actions — tout cela devient possible et même simple avec une forge maîtrisée.

L’indépendance vis-à-vis des politiques tarifaires et des changements de conditions d’utilisation. Le secteur du cloud et des outils dev a connu plusieurs vagues de rationalisation tarifaire ces dernières années : GitHub a supprimé des fonctionnalités gratuites, GitLab.com a durci ses limitations de pipelines CI gratuits, Bitbucket a modifié ses politiques d’équipes gratuites. Avec une forge self-hosted, vous êtes immunisé contre ces décisions unilatérales. La version que vous avez installée continue de fonctionner, indépendamment des choix commerciaux de l’éditeur amont.

La formation interne et le développement des compétences. Opérer une forge Git en production — même modeste — développe des compétences transversales précieuses : administration Linux, Docker, gestion de base de données, configuration SSL, mise en place de sauvegardes, monitoring des services. Pour les équipes africaines qui cherchent à monter en compétence sur l’infrastructure, la gestion d’une forge est un excellent terrain d’apprentissage en conditions réelles.

Les 3 contenders : Gitea, Forgejo, GitLab CE

Le marché des forges Git open-source n’est pas aussi fragmenté qu’il y paraît. Trois projets se distinguent nettement en 2026 par leur maturité, leur adoption et leur adéquation à différents profils d’équipes. Chacun a une identité claire et des compromis distincts.

Gitea — la légèreté du Go

Gitea est né en 2016 comme un fork de Gogs, lui-même une tentative de créer une alternative légère à GitLab. Sa particularité fondamentale est d’être écrit en Go et de se distribuer sous forme d’un binaire unique. Un seul fichier exécutable, une base de données SQLite par défaut, et vous disposez d’une forge Git fonctionnelle. Cette architecture minimaliste a des conséquences directes sur les ressources requises : Gitea fonctionne confortablement sur une machine avec 512 Mo à 1 Go de RAM pour une petite équipe, ce qui en fait l’outil de choix pour les environnements très contraints.

En 2026, Gitea a significativement enrichi ses fonctionnalités. Gitea Actions — compatible avec la syntaxe GitHub Actions — permet de définir des pipelines CI/CD en YAML avec la même logique que les workflows GitHub. Le support des packages couvre plus de 20 types de registres : npm, PyPI, Docker Container Registry, Maven, Cargo, NuGet, Helm, Composer et bien d’autres. L’interface web reste fidèle à son inspiration GitHub : sobre, fonctionnelle, facile à prendre en main pour un développeur habitué à l’écosystème Git standard. La gestion des organisations, des équipes, des permissions granulaires par dépôt, des webhooks, et des clés SSH est complète.

La limitation historique de Gitea réside dans sa gouvernance. Le projet est sous la houlette de la société Gitea Ltd, ce qui a créé des tensions dans la communauté à partir de 2022 lorsque les décisions commerciales ont commencé à peser sur la direction open-source du projet. Certains mainteneurs ont quitté le navire pour créer Forgejo — nous y reviendrons. En 2026, Gitea reste un projet open-source sous licence MIT, mais son orientation est de plus en plus influencée par les besoins d’une offre Cloud commerciale (Gitea Cloud). Pour une équipe qui cherche une solution purement communautaire, ce contexte est à prendre en compte. Source officielle : about.gitea.com.

Gitea s’installe en binaire natif, via Docker, ou via des gestionnaires de paquets sur les principales distributions Linux. La documentation officielle couvre les cas d’usage de MySQL/MariaDB et PostgreSQL pour les déploiements en production au-delà de dix utilisateurs. SQLite reste adapté jusqu’à environ dix à quinze utilisateurs selon l’intensité d’utilisation. Le passage à PostgreSQL est recommandé dès lors que la base de code grandit et que les requêtes sur l’historique Git deviennent fréquentes.

Forgejo — le fork éthique

Forgejo est né en octobre 2022, lorsqu’un groupe de mainteneurs Gitea, préoccupés par la direction prise par la gouvernance de Gitea Ltd, ont décidé de forker le projet sous un modèle de gouvernance communautaire transparent. Le nom lui-même est un jeu de mots : « forge » en espéranto. Le projet est aujourd’hui hébergé par Codeberg, une organisation allemande à but non lucratif, sous la protection d’un modèle de gouvernance ouvert qui garantit qu’aucune entité commerciale ne peut prendre le contrôle unilatéral du projet. Cette philosophie — software libre, communauté avant tout — est la raison principale pour laquelle beaucoup d’organisations choisissent Forgejo plutôt que Gitea malgré leur très grande similarité technique.

Techniquement, Forgejo a commencé comme un fork quasi-identique à Gitea, avec les mêmes fonctionnalités et la même base de code. Mais depuis début 2024, le projet a commencé à diverger de manière significative, avec des fonctionnalités propres et une cadence de release indépendante. En avril 2026, Forgejo v15.0 — marquant le 100ème release du projet — constitue une LTS (Long Term Support) supportée jusqu’au 15 juillet 2027. Cette version apporte des améliorations notables : les workflows réutilisables dans Forgejo Actions ont été significativement reworkés pour se rapprocher du comportement attendu par les utilisateurs, un nouveau processus d’enregistrement des runners Actions est disponible directement depuis l’interface web sans passer par le CLI, et les nouveaux conteneurs du registry sont auto-liés aux dépôts si possible, supprimant une étape manuelle d’administration. Source officielle : forgejo.org.

L’empreinte mémoire de Forgejo est comparable à celle de Gitea — ce qui était attendu vu l’origine commune. Un serveur Forgejo pour une équipe de 20 développeurs actifs consomme typiquement entre 300 Mo et 800 Mo de RAM au repos, selon le volume de dépôts et l’activité des pipelines. Forgejo v14.0, sorti en janvier 2026, est l’autre LTS en cours de support jusqu’en juillet 2026, pour ceux qui préfèrent une version plus conservative. La compatibilité binaire ascendante est assurée : migrer de Gitea vers Forgejo est documenté et supporté officiellement.

Pour une PME qui cherche une forge open-source de confiance, avec une communauté engagée, une gouvernance transparente et des fonctionnalités CI/CD modernes, Forgejo est le choix de référence en 2026. Il concentre l’essentiel des développements communautaires qui auraient dû aller dans Gitea mais ont été déviés par les intérêts commerciaux de Gitea Ltd.

GitLab CE — la puissance au prix du poids

GitLab Community Edition est la version open-source (licence MIT Expat) de la plateforme GitLab. C’est un tout autre monde comparé à Gitea et Forgejo — non pas parce que les fonctionnalités seraient radicalement différentes dans leur conception, mais parce que l’ambition fonctionnelle et, en conséquence, l’empreinte système sont d’une autre magnitude. GitLab CE est une plateforme de développement complète : forge Git, CI/CD (GitLab Runners), registry Docker intégré, gestion des releases, scan de sécurité SAST basique, gestion des environnements de déploiement, wiki, suivi d’issues avancé, board Kanban, roadmap de projets, intégrations Kubernetes — la liste est exhaustive.

Cette richesse fonctionnelle a un coût direct en ressources serveur. Les exigences officielles de GitLab pour une installation en production à partir de quelques utilisateurs recommandent 8 Go de RAM minimum, avec 4 vCPU. Pour une utilisation confortable avec des pipelines CI actifs et une vingtaine d’utilisateurs, 16 Go de RAM est la recommandation pratique. La documentation officielle indique que 4 Go de RAM permettent techniquement de faire tourner GitLab, mais avec un usage du swap qui rend l’expérience pénible. Pour une entreprise qui veut une forge en production fiable, il faut budgéter un VPS d’au moins 8 Go de RAM — soit un Hetzner CX32 à 8 Go pour environ 9 euros par mois. Source officielle : docs.gitlab.com/install/requirements.

L’installation de GitLab CE se fait via le package Omnibus — un paquet tout-en-un qui configure automatiquement PostgreSQL, Redis, Nginx, Puma, Sidekiq et tous les composants internes. C’est pratique pour une première installation mais cela signifie aussi que vous confiez à GitLab le contrôle de votre stack interne, ce qui peut compliquer certaines configurations avancées. Des installations Docker sont disponibles mais sont moins recommandées par l’équipe GitLab pour la production.

GitLab CE brille particulièrement dans les contextes suivants : équipes de 20 à 100 développeurs qui ont besoin de toute la chaîne DevOps dans un seul outil, structures qui utilisent déjà GitLab.com et veulent migrer en self-hosted avec une courbe d’apprentissage minimale, et projets qui nécessitent des fonctionnalités avancées de sécurité et de conformité. Pour une PME de 5 à 15 personnes avec un budget VPS serré, le surcoût en ressources de GitLab CE est difficile à justifier face à Forgejo qui offre 80 % des fonctionnalités quotidiennement utilisées pour 10 % des ressources.

Critères de choix : RAM, complexité, CI/CD, registry

Choisir entre ces trois solutions n’est pas une question de préférence esthétique — c’est une décision technique et opérationnelle qui engage votre infrastructure pour plusieurs années. Voici les critères qui doivent structurer votre analyse.

La RAM disponible sur votre VPS est le filtre le plus direct. Si vous disposez d’un VPS entre 2 et 4 Go de RAM, GitLab CE est exclu d’office — ou du moins réservé à un usage non-critique avec beaucoup de swap. Gitea et Forgejo fonctionnent très bien dans cette contrainte. Entre 4 et 8 Go, Forgejo est confortable et GitLab CE est techniquement possible mais tendu. Au-delà de 8 Go, les trois options sont viables et le choix se fait sur d’autres critères.

La complexité opérationnelle est souvent sous-estimée. Gitea et Forgejo sont des binaires Go : une seule mise à jour d’un fichier exécutable, un redémarrage, et c’est fait. La maintenance est d’une simplicité remarquable. GitLab CE, via Omnibus, implique des mises à jour qui peuvent durer 15 à 30 minutes, qui touchent une dizaine de composants internes, et qui nécessitent parfois des migrations de base de données non triviales. Pour une petite équipe sans DevOps dédié, cette complexité de maintenance est un facteur réel de risque opérationnel.

Les besoins CI/CD doivent être évalués honnêtement. Si votre pipeline se résume à « lancer des tests unitaires, builder une image Docker et la pousser sur un registre », Forgejo Actions couvre ce besoin parfaitement avec une syntaxe compatible GitHub Actions. Si vous avez besoin de pipelines multi-étages avec des environnements d’approbation, des déploiements Kubernetes natifs, des scans de sécurité SAST/DAST intégrés et des métriques de couverture de code centralisées — GitLab CI/CD est dans une catégorie à part. La complexité que vous acceptez en termes d’infrastructure est proportionnelle à la sophistication des pipelines que vous pouvez construire.

Le registry de packages est un critère croissant. Forgejo et Gitea proposent un registry de packages qui couvre la majorité des formats courants : Docker/OCI Container Registry, npm, PyPI, Maven, NuGet, Cargo. Pour une équipe qui publie des librairies internes ou distribue des artefacts en interne, ce registry évite d’installer un outil séparé comme Harbor ou Nexus. GitLab CE inclut également un Container Registry complet, mais son activation consomme des ressources supplémentaires.

La capacité de migration depuis GitHub ou GitLab.com. Les trois solutions proposent des outils de migration qui importent dépôts, issues, commentaires et pull requests depuis GitHub. Forgejo et Gitea ont amélioré leurs importeurs ces dernières versions. GitLab CE propose une migration depuis GitLab.com particulièrement propre, ce qui en fait le choix naturel pour les équipes qui migrent depuis la plateforme commerciale.

La fédération ActivityPub. C’est une fonctionnalité encore expérimentale mais notable : Forgejo travaille activement sur la fédération entre instances, ce qui permettrait à terme de soumettre des pull requests d’une instance Forgejo vers une autre sans avoir de compte sur l’instance distante. GitLab CE et Gitea n’ont pas de plans concrets dans cette direction. Pour les projets open-source distribués entre plusieurs organisations, cette vision est intéressante à long terme.

Tableau comparatif

Tutoriels du cluster

Ce pilier est le centre d’un cluster de tutoriels pratiques. Chaque satellite détaille une mise en pratique complète pas à pas. Voici les tutoriels disponibles et planifiés :

• Installer Forgejo sur Hetzner CX22 avec Docker et Caddy — déploiement complet, HTTPS automatique, configuration PostgreSQL, première organisation et premier runner Actions.
• Configurer Forgejo Actions : pipeline CI/CD Node.js et Docker build — écrire un workflow YAML complet, enregistrer un runner via l’interface web (v15), publier une image sur le Container Registry intégré.
• Migrer ses dépôts GitHub vers Forgejo — import d’issues, de pull requests, de releases et de secrets, configuration du miroir continu pour la transition progressive.

Ces trois tutoriels couvrent le parcours complet d’une PME qui part de GitHub et migre vers une forge souveraine. La séquence recommandée est : d’abord le tutoriel d’installation, puis la mise en place du CI/CD, puis la migration du code existant.

Adaptation au contexte ouest-africain

Déployer une forge Git self-hosted en Afrique de l’Ouest ne se résume pas à appliquer un tutoriel occidental. Plusieurs aspects techniques et pratiques méritent une attention spécifique pour que l’infrastructure soit réellement fiable et accessible dans ce contexte.

Le dimensionnement VPS pour une équipe de 20 développeurs avec Forgejo. La bonne nouvelle est que Forgejo est remarquablement efficace. Un Hetzner CX22 — 2 vCPU, 4 Go de RAM, 40 Go NVMe — est largement suffisant pour héberger Forgejo, sa base PostgreSQL, un ou deux runners Actions légers, et le Container Registry pour une équipe de 20 développeurs avec une activité normale. Le tout pour 3,79 euros par mois, soit environ 2 500 FCFA. Si vos pipelines CI/CD sont intensifs (builds Docker fréquents, tests parallèles), prévoyez un second VPS CX22 dédié aux runners pour ne pas saturer le serveur principal. La commande de référence pour surveiller la mémoire en production est docker stats avec --no-stream pour un snapshot instantané.

GitLab CE nécessite absolument 8 Go de RAM. Il ne s’agit pas d’une recommandation théorique : en dessous de 8 Go, les composants Sidekiq et Puma de GitLab Omnibus entrent en compétition pour la mémoire, provoquant des timeouts lors des opérations CI/CD et des réponses lentes sur l’interface web. Sur un Hetzner CX32 (8 Go RAM, 4 vCPU) à environ 9 euros par mois, GitLab CE fonctionne correctement pour une équipe de 15 à 25 utilisateurs. Pour une équipe de plus de 40 personnes avec des pipelines actifs, montez à un CX42 (16 Go) ou équivalent. Ne tentez pas GitLab CE sur un CX22 pour un usage en production — vous perdrez plus de temps en débogage de lenteurs que vous n’en gagnerez.

Le miroir GitHub pour les dépendances externes est une nécessité pratique. En auto-hébergeant votre forge, vous contrôlez le code de vos projets — mais vos pipelines CI téléchargent toujours des dépendances depuis npm, PyPI, Docker Hub ou GitHub lui-même. En cas de connectivité dégradée, ces téléchargements échouent ou ralentissent. La bonne pratique est de configurer Forgejo comme miroir de dépôts GitHub critiques : clone miroir quotidien des bibliothèques que vous utilisez fréquemment, couplé à un registry npm interne via Verdaccio ou le Package Registry de Forgejo. Cela rend vos builds résilients aux coupures d’internet ou aux pannes upstream. Forgejo supporte la création de miroirs automatiques depuis l’interface d’administration : Administration > Dépôts > Miroir, avec une fréquence de synchronisation configurable de 10 minutes à 24 heures.

L’intégration WhatsApp pour les notifications webhook change la dynamique d’équipe. Les développeurs africains communiquent massivement via WhatsApp — c’est un fait sociologique qui a des implications sur l’infrastructure dev. Plutôt que d’imposer Slack ou Mattermost à une équipe habituée à WhatsApp, il est possible de configurer des webhooks Forgejo qui publient des notifications dans un groupe WhatsApp Business dédié. Le flux est simple : Forgejo émet un webhook HTTP à chaque événement (push, pull request, review, pipeline échoué) vers un service intermédiaire — un petit script Node.js ou Python — qui formatte le message et l’envoie via l’API WhatsApp Business Cloud. Pour une équipe de 10 à 30 développeurs, ce système de notification est plus rapide à adopter que n’importe quel outil de messagerie professionnel, car il n’exige aucun changement d’habitude. Les webhooks Forgejo se configurent dans chaque dépôt sous Paramètres > Webhooks, ou au niveau de l’organisation pour une couverture globale.

La gestion de la bande passante lors des gros transferts Git. Les dépôts contenant de nombreux artefacts binaires (assets graphiques, datasets, fichiers de configuration volumeux) peuvent saturer une connexion 4G lors des clones initiaux. Deux pratiques s’imposent : configurer Git LFS (Large File Storage) sur Forgejo pour externaliser les fichiers lourds vers un stockage objet (Hetzner Object Storage est compatible S3 et s’intègre facilement), et encourager les développeurs à utiliser des clones superficiels (git clone --depth 1) pour les opérations de déploiement CI/CD. Forgejo supporte Git LFS nativement depuis la configuration initiale — une ligne dans app.ini active la fonctionnalité.

Les sauvegardes vers un stockage local africain. Hetzner Object Storage est hébergé en Europe, ce qui peut poser des questions de latence pour les restaurations fréquentes. Pour les structures dont la politique de données exige une localisation africaine, Giga Datacenter en Côte d’Ivoire, MTN Business en Côte d’Ivoire et au Sénégal, ou Orange Cloud for Business proposent des stockages objets S3-compatibles. La configuration de Forgejo pour les sauvegardes automatiques utilise la section [storage] du fichier app.ini, compatible avec n’importe quel endpoint S3.

La gestion des coupures électriques. Les coupures de courant fréquentes dans certaines capitales africaines affectent les postes de travail des développeurs mais pas le VPS hébergé en Europe. Cette asymétrie est en réalité un avantage : la forge reste disponible et les pipelines CI/CD continuent de tourner pendant les interruptions locales. Pour les équipes dont certains membres travaillent depuis des zones avec des coupures fréquentes, encouragez l’utilisation des fonctionnalités web de Forgejo — éditeur de fichiers en ligne, revue de code dans le navigateur — qui ne nécessitent pas une connexion continue une fois la page chargée.

Erreurs fréquentes

FAQ

Q : Peut-on migrer de Gitea vers Forgejo sans perdre les données ?

R : Oui, la migration est documentée et officiellement supportée par l’équipe Forgejo. Les deux projets partagent le même schéma de base de données pour les versions compatibles. La procédure consiste à arrêter Gitea, remplacer le binaire par Forgejo de la version correspondante, et démarrer. Forgejo applique automatiquement les migrations de schéma spécifiques à son projet. Il est fortement recommandé de faire une sauvegarde complète de la base de données et du répertoire de données avant toute opération. La documentation complète est disponible sur forgejo.org.

Q : Forgejo Actions est-il compatible à 100 % avec GitHub Actions ?

R : La compatibilité est élevée mais pas totale. La syntaxe YAML des workflows est identique, et les Actions du marketplace GitHub fonctionnent dans leur grande majorité. Les limitations concernent principalement certaines actions qui dépendent d’APIs ou d’environnements spécifiques à GitHub (comme les actions qui utilisent le contexte github.token de manière avancée). Pour la grande majorité des pipelines standard — tests, builds, déploiements — la compatibilité est suffisante pour migrer sans réécrire les workflows.

Q : Quelle base de données choisir pour Forgejo en production ?

R : PostgreSQL est le choix de référence pour la production. Il supporte la concurrence, les transactions ACID, et les requêtes complexes sur l’historique Git beaucoup mieux que SQLite. MySQL/MariaDB fonctionne également mais PostgreSQL est généralement préféré dans l’écosystème Go. SQLite est acceptable uniquement pour une utilisation solo ou une équipe de moins de 5 à 10 personnes avec une activité modérée. La migration de SQLite vers PostgreSQL est documentée et réalisable via les outils de dump intégrés à Forgejo.

Q : Comment estimer le stockage disque nécessaire pour une forge PME ?

R : La règle pratique est de prévoir l’espace des dépôts Git multiplie par 3 (compte tenu des objets packfiles, des LFS, des artefacts de pipeline et des logs). Pour une équipe de 20 développeurs avec 50 dépôts actifs contenant du code source standard (sans assets binaires volumineux), 40 Go sont généralement suffisants pour commencer. Activez Git LFS pour les fichiers binaires et configurez les archives de pipeline pour ne conserver que les 30 derniers jours d’artefacts. Hetzner propose des volumes additionnels à 0,059 €/Go/mois facilement attachables à un VPS existant.

Q : Est-il possible d’utiliser une forge self-hosted avec des développeurs en télétravail sur connexion mobile ?

R : Oui, c’est tout à fait faisable. Les opérations Git standard (push/pull de code source) sont peu gourmandes en bande passante. L’interface web de Forgejo est légère et fonctionne bien sur une connexion 3G/4G stable. Les points d’attention sont les clones initiaux de gros dépôts (utiliser --depth 1), les téléchargements de gros artefacts CI, et l’utilisation de l’éditeur web pour des modifications légères plutôt que de resynchroniser l’intégralité du dépôt. Depuis Forgejo v14, plusieurs parties de l’interface fonctionnent sans JavaScript, ce qui améliore la résilience sur les connexions instables.

Q : GitLab CE permet-il de remplacer complètement GitHub pour une équipe qui fait du DevOps avancé ?

R : Oui, c’est sa promesse principale. GitLab CE inclut nativement la gestion des environnements de déploiement, les métriques de couverture de code, les rapports de tests, la gestion des releases avec assets téléchargeables, les boards d’issues avancés et les roadmaps. Pour une équipe qui pratique le GitOps avec Kubernetes, GitLab CE est probablement la solution self-hosted la plus complète. La limitation principale par rapport à GitHub reste la taille de la communauté et le nombre d’intégrations tierces disponibles nativement.

Q : Peut-on héberger plusieurs organisations distinctes sur une même instance Forgejo ?

R : Oui. Forgejo supporte nativement la gestion de plusieurs organisations sur une instance unique. Chaque organisation a ses propres membres, équipes, permissions, webhooks et dépôts. C’est particulièrement utile pour une agence ou un cabinet de conseil qui veut héberger les projets de plusieurs clients sur une même infrastructure, avec une séparation logique complète entre les organisations. La séparation reste logique et non physique — tous les dépôts partagent la même base de données et le même stockage.

Pour aller plus loin

1. Formations ITSkillsCenter — Administration Linux et Infrastructure DevOps : acquérir les bases d’administration Linux, Docker et des services web nécessaires pour opérer une forge en production. Disponible sur itskillscenter.io/formations.
2. Documentation officielle Forgejo : forgejo.org/docs/latest — référence technique complète, de l’installation à la configuration avancée.
3. Documentation officielle Gitea : docs.gitea.com — guide d’installation, configuration et administration.
4. Documentation GitLab CE : docs.gitlab.com — documentation exhaustive incluant les exigences système, le guide Omnibus et la référence CI/CD.
5. Par où commencer ? Si vous partez de zéro avec une équipe de 5 à 30 développeurs, la séquence recommandée est : créer un VPS Hetzner CX22, suivre le tutoriel d’installation Forgejo avec Docker et Caddy, configurer PostgreSQL et les sauvegardes, puis migrer progressivement vos dépôts GitHub avec l’importeur intégré.

Site réalisé par [ITS] ITSkillsCenter