Pourquoi j'ai construit FerrisGit, et l'éditeur de pipeline qui arrive

Avec ArtiFerris, mes artefacts npm et Docker avaient trouvé un registre léger et auto-hébergé. Il manquait l'autre moitié de la chaîne : le code, les merge requests et l'intégration continue. Mes dépôts vivaient sur GitHub, et le GitLab que j'avais tenté d'auto-héberger demandait bien plus de ressources que mon usage ne le justifiait. FerrisGit est né de là.

Pourquoi

D'abord la souveraineté. GitHub appartient à Microsoft et, comme GitLab.com, il est soumis au droit américain où que soient stockées les données : depuis le CLOUD Act de 2018, un fournisseur américain doit remettre aux autorités les données en sa possession, sous sa garde ou sous son contrôle, qu'elles se trouvent aux États-Unis ou ailleurs. Ce n'est pas théorique : en 2019, GitHub a bloqué les dépôts privés des développeurs d'Iran, de Syrie, de Crimée, de Cuba et de Corée du Nord pour appliquer les sanctions américaines. En 2025, l'administration Trump a sanctionné des magistrats de la Cour pénale internationale, qui a fini par quitter Microsoft après que la messagerie de son procureur aurait été coupée, ce que Microsoft dément. Je ne veux pas que l'accès à mon code dépende des décisions d'un gouvernement d'extrême droite et du clown orange de la Maison Blanche.

Ensuite la sobriété. GitLab fixe 8 vCPU et 16 Go de mémoire comme base pour un seul nœud. FerrisGit tient en un binaire Rust de 25 Mo qui sert l'interface, l'API et Git ; mesurée à vide et au repos, une instance occupe environ 70 Mio, PostgreSQL compris. Une instance vide ne dit rien d'une équipe au travail, et GitLab fait beaucoup plus, mais l'ordre de grandeur est là. L'écart n'a d'intérêt écologique que s'il permet une machine plus petite ou partagée.

Enfin, la cohérence et l'envie d'apprendre. FerrisGit construit, ArtiFerris stocke et analyse : les deux forment une même chaîne. Et construire une forge, c'est comprendre de l'intérieur Git en HTTP, un moteur de CI ou l'exécution de jobs dans Kubernetes, tout en essayant des idées que les forges existantes ne m'offraient pas.

Ce que FerrisGit fait aujourd'hui

À la version 0.1.4 : dépôts en HTTP, groupes imbriqués, rôles, merge requests avec relecture en ligne, tickets et kanban, wikis, releases, webhooks, et des pipelines exécutées sur des runners Docker ou dans des Pods Kubernetes. La double authentification est obligatoire pour tous. Il manque encore l'accès SSH, les branches protégées, et l'interface n'existe qu'en français.

Vos données restent les vôtres

Sur une instance que vous hébergez, je n'ai accès à rien : FerrisGit n'envoie aucune télémétrie, et ses seules requêtes sortantes sont les webhooks et les e-mails que vous configurez. Sur l'instance que j'héberge, app.ferrisgit.pro, un administrateur ne peut pas lire les dépôts privés, ni par l'API ni par Git, et un test le vérifie. Les mots de passe et jetons sont hachés, les secrets chiffrés en AES-256-GCM.

Cette garantie est celle de l'application : le contenu des dépôts n'est pas chiffré sur le disque, et un accès direct à la machine permettrait de le lire, comme sur toute forge hébergée par un tiers. La seule certitude reste d'héberger soi-même.

L'éditeur de pipeline, sans YAML

C'est la fonctionnalité en cours de développement. Aujourd'hui, décrire une pipeline, c'est écrire du YAML : une syntaxe de plus pour qui veut seulement que ses tests tournent ou que son application se déploie.

L'éditeur la construit à la souris : les étapes sont des colonnes, les jobs des cartes que l'on glisse de l'une à l'autre, et un clic ouvre les réglages d'un job. Des modèles (Rust, Node ou Angular, Go, image Docker) et un catalogue de tuiles prêtes à l'emploi évitent de partir d'une page blanche. Les tuiles de déploiement (image Docker, SSH, Kubernetes avec kubectl ou Helm) écrivent les commandes à partir de quelques réponses, contrôlées pour qu'aucune ne puisse injecter autre chose. L'éditeur signale aussi les secrets manquants, et une variable qui ressemble à un mot de passe.

Un éditeur visuel finit souvent par enfermer dans un format que l'on ne peut plus modifier à la main. Ici, .ferrisgit-ci.yml reste la seule source de vérité : les cartes et le YAML sont deux vues du même fichier, lu et vérifié par l'analyseur du serveur, si bien que ce qui s'affiche est ce qui s'exécuterait. Une modification ne touche jamais directement la branche par défaut : elle part sur une branche, avec une merge request. La contrepartie : repasser par les cartes réécrit le fichier et efface les commentaires, ce que l'éditeur signale avant.

Et ensuite

La feuille de route mène de la forge à l'analyse de code : branches protégées et interface en cinq langues en 0.2, puis détection de secrets, audit des dépendances, quality gates, qualité du code et sécurité, et un lien de plus en plus étroit avec ArtiFerris. Rien de tout cela n'existe encore.

Le code est sur github.com/Masmarino/FerrisGit, sous licence Apache 2.0, et les issues sont ouvertes.