« La plateforme d’hébergement du code source et des revues de modifications devra être installée sur une infrastructure sous la maîtrise exclusive du titulaire, à l’exclusion de tout service d’hébergement tiers. » Cette clause, extraite du cahier des charges d’un marché public remporté récemment, excluait d’office l’usage de toute plateforme de gestion de code hébergée par un tiers, aussi répandue soit-elle dans la profession.
Le pipeline d’intégration continue associé à ce marché, hébergé séparément, ne fait pas l’objet de cet article ; seule la question de l’hébergement du dépôt et des demandes de fusion elle-même y est traitée.
Pourquoi Forgejo plutôt qu’une alternative
Forgejo, dérivé communautaire d’un logiciel de forge Git plus ancien, a été retenu pour trois raisons précises. D’abord, il s’installe sur une seule machine, avec des besoins matériels modestes, ce qui correspondait au volume du projet, une équipe de six personnes travaillant sur un dépôt principal et deux dépôts satellites. Ensuite, il reproduit fidèlement les fonctionnalités attendues par l’équipe : demandes de fusion avec revue en ligne, intégration d’un système de tickets, gestion fine des droits d’accès par dépôt. Enfin, son code source reste ouvert et consultable, un argument supplémentaire dans le cadre d’un marché public soumis à des exigences de transparence.
L’installation, plus simple qu’anticipé
L’installation s’est faite via l’image de conteneur officielle du projet, déployée sur une machine virtuelle dédiée provisionnée pour ce marché, avec une base de données PostgreSQL hébergée sur la même machine compte tenu du volume limité de données à gérer.
version: "3"
services:
forgejo:
image: codeberg.org/forgejo/forgejo:7
environment:
- FORGEJO__database__DB_TYPE=postgres
- FORGEJO__database__HOST=db:5432
- FORGEJO__database__NAME=forgejo
volumes:
- ./donnees:/data
ports:
- "222:22"
- "3000:3000"
db:
image: postgres:16
environment:
- POSTGRES_DB=forgejo
volumes:
- ./postgres:/var/lib/postgresql/data
La configuration initiale, comptes utilisateurs et droits d’accès par dépôt, a pris moins d’une demi-journée, un délai jugé raisonnable au regard du gain obtenu : une plateforme entièrement sous contrôle, conforme à la clause contractuelle sans négociation possible avec le client sur ce point.
Migrer un dépôt existant sans perdre l’historique
Le dépôt principal du projet existait déjà, hébergé temporairement ailleurs pendant la phase de cadrage du marché. Sa migration vers Forgejo s’est faite par une simple opération Git, sans outil de migration spécifique : un miroir complet du dépôt d’origine, poussé intégralement vers le nouveau dépôt Forgejo, préservant l’intégralité de l’historique des commits et des branches existantes.
git clone --mirror https://ancien-depot.example/projet.git
cd projet.git
git remote set-url --push origin ssh://git@forgejo-interne.example:222/agence/projet.git
git push --mirror
Seules les demandes de fusion déjà ouvertes sur l’ancienne plateforme n’ont pas pu être transférées automatiquement, faute d’outil de migration dédié pour ce cas précis ; les deux demandes concernées, encore actives au moment de la bascule, ont simplement été recréées manuellement sur la nouvelle plateforme.
Ce que cela a changé pour l’équipe au quotidien
- Aucune dépendance à un service externe pour accéder au code ou aux revues de modifications
- Des sauvegardes intégralement maîtrisées, incluses dans le plan de sauvegarde général du marché
- Une charge de maintenance supplémentaire, limitée aux mises à jour de sécurité de Forgejo lui-même
Cette dernière charge reste modeste comparée au bénéfice obtenu : une conformité stricte à une exigence contractuelle qui n’aurait laissé aucune marge de négociation en cas de non-respect.
Notre verdict
Pour un marché public dont le cahier des charges exclut explicitement toute plateforme tierce, Forgejo constitue une réponse directe et proportionnée, sans nécessiter de développement spécifique ni de compromis fonctionnel majeur par rapport aux plateformes plus répandues habituellement utilisées par l’agence.
