Deux mois avec Gitea : ma forge Git locale est devenue un outil du quotidien

Le 18 juin dernier, j'ai installé Gitea dans mon cluster Kubernetes local.

Deux mois plus tard, mon instance héberge 47 dépôts.

Pourtant, au départ, je ne cherchais ni à remplacer GitHub, ni même particulièrement à installer Gitea.

Tout est parti de Subversion.

Tout est parti d'une GED sous Subversion

Je travaillais sur une GED (gestion électronique de documents) dont les documents étaient versionnés avec Subversion.

Comme je manipule aujourd'hui essentiellement Git, je me suis d'abord rappelé qu'il existait des passerelles entre Git et SVN.

Mais cette réflexion en a rapidement entraîné une autre.

J'ai mon propre serveur Subversion.

Existe-t-il aujourd'hui une plateforme équivalente autour de Git que je pourrais également héberger sur ma propre infrastructure ?

J'ai regardé plusieurs alternatives auto-hébergeables avant de m'arrêter sur Gitea.

Retrouver chez moi un écosystème proche de GitHub

Je ne cherchais pas simplement un serveur capable d'héberger des dépôts Git.

GitHub m'a habitué à disposer de tout un environnement autour du dépôt : organisations, gestion des projets, automatisation, interface Web, API, outils en ligne de commande...

Parmi les solutions que j'ai étudiées, Gitea m'est apparu comme l'écosystème le plus proche de cette expérience tout en restant suffisamment simple pour être hébergé sur mon infrastructure.

Il restait alors à l'intégrer.

Une installation Kubernetes réalisée avec mon agent IA

Je disposais déjà d'une infrastructure locale et d'un cluster Kubernetes.

Lors de mes échanges de brainstorming avec mon agent IA, j'ai donc naturellement proposé de réutiliser cette infrastructure plutôt que de créer un environnement spécifique pour Gitea.

Je lui ai fourni la configuration d'accès à mon cluster Kubernetes et lui ai demandé de préparer le déploiement.

L'agent a généré une première base de manifests Kubernetes.

J'ai ensuite complété et adapté cette base aux contraintes de mon infrastructure, notamment concernant les volumes persistants et la configuration de l'Ingress.

Progressivement, le déploiement s'est structuré autour de plusieurs composants : application Gitea, PostgreSQL, stockage persistant, accès SSH, Ingress, TLS et secrets.

Ce fonctionnement illustre assez bien la manière dont j'utilise aujourd'hui mes agents IA.

Je définis l'architecture, les contraintes et la direction. L'agent peut ensuite agir directement sur l'environnement pour mettre en œuvre une première solution, que j'adapte ou complète lorsque les spécificités de mon infrastructure l'exigent.

Cette délégation ne s'arrête pas à la conception : elle se retrouve plus loin, quand l'agent agit directement sur la plateforme via sa CLI.

Héberger Git était une première étape

Une fois Gitea opérationnel, une autre question s'est rapidement posée.

Si mes dépôts sont hébergés localement, pourquoi ne pas également y exécuter mes builds ?

J'ai donc ajouté un runner Gitea à mon cluster Kubernetes afin d'exécuter des builds.

Mon premier véritable projet de test a été volontairement simple : un dashboard Svelte de suivi du budget du foyer, lui-même destiné à être auto-hébergé.

Le dépôt disposait désormais de son workflow dans .gitea/workflows, exécuté par mon runner.

Tout n'a évidemment pas fonctionné du premier coup. Les premières exécutions ont alterné succès et échecs, le temps de stabiliser la chaîne.

Mais l'objectif était atteint.

Gitea n'était déjà plus seulement un endroit où stocker mes sources.

Il commençait à devenir une véritable plateforme de développement.

Je n'ai pas migré mes dépôts GitHub

La suite aurait pu consister à transférer progressivement mes dépôts GitHub vers ma nouvelle plateforme.

Ce n'est pas ce que j'ai fait.

GitHub continue de répondre à certains de mes besoins et je n'avais aucune raison particulière de le supprimer de mon environnement.

J'avais en revanche un autre problème.

De nombreux projets existaient uniquement dans des dépôts Git locaux, parfois sauvegardés sur des supports amovibles, mais sans aucun remote.

Et tous ces dépôts ne contiennent pas nécessairement des applications.

Certains correspondent à des projets Python, Rust, JavaScript ou Shell. D'autres contiennent essentiellement du Markdown, des fichiers texte, de la documentation ou mes dossiers d'orchestration utilisés avec mes agents IA.

Ces projets n'avaient pas forcément vocation à être publiés ou hébergés sur GitHub.

Gitea leur a donné une place.

Git ne versionne pas seulement mon code

C'est probablement l'un des enseignements inattendus de cette expérimentation.

Avec l'importance croissante des agents IA dans mon environnement de travail, mes fichiers Markdown, mes instructions, mes configurations et mes éléments d'orchestration deviennent eux aussi des éléments importants de mes projets.

Ils évoluent.

Ils doivent pouvoir être historisés.

Et je veux pouvoir revenir en arrière lorsque cela devient nécessaire.

Git répond parfaitement à ce besoin, même lorsqu'il n'y a pratiquement aucune ligne de code dans le dépôt.

Disposer de ma propre forge m'incite donc davantage à versionner ces éléments plutôt que de les laisser dispersés dans différents répertoires.

tea : donner accès à Gitea à mes agents IA

Mes agents devaient aussi pouvoir agir directement sur cette plateforme au quotidien.

Une plateforme locale ne doit pas devenir un environnement isolé de mes outils de travail.

Avec GitHub, j'utilise notamment son CLI gh.

Gitea possède son équivalent : tea.

Cela s'intègre particulièrement bien à ma manière de travailler avec Claude Code ou Codex.

Pour ce type d'agent CLI, je ne considère pas qu'un serveur MCP soit systématiquement nécessaire.

L'agent dispose déjà d'un shell. Lorsqu'une application propose une CLI suffisamment complète, cette CLI peut directement constituer son interface avec le service.

Avec GitHub, l'agent peut utiliser gh.

Avec Gitea, il peut utiliser tea.

Je peux ainsi lui demander de créer un dépôt, voire une organisation, puis de travailler avec cette forge sans avoir à ajouter une couche MCP uniquement pour cela.

Le besoin n'est pas d'utiliser MCP.

Le besoin est de fournir à l'agent une interface adaptée pour agir sur son environnement.

47 dépôts deux mois plus tard

Deux mois après son installation, mon instance Gitea héberge 47 dépôts répartis entre plusieurs projets et organisations.

Mais le chiffre est finalement secondaire.

Le principal changement est beaucoup plus simple :

je travaille plus sereinement avec mes projets Git du quotidien.

Les dépôts qui restaient auparavant uniquement sur mes machines ou sur des supports amovibles disposent maintenant d'un remote centralisé.

Je peux les retrouver et les organiser au même endroit.

Mes agents peuvent également interagir avec eux.

Et lorsque cela se justifie, je dispose de ma propre chaîne de build.

Gitea n'a pas remplacé GitHub

Cette expérimentation ne m'a finalement pas conduit à abandonner GitHub.

Elle m'a plutôt fait prendre conscience que j'avais laissé un espace vide dans mon organisation.

D'un côté, mes projets destinés à GitHub.

De l'autre, quantité de dépôts Git locaux qui n'avaient aucune raison particulière d'y être hébergés.

Gitea occupe désormais cet espace.

Et il y a quelques années, j'aurais probablement hésité davantage avant d'ajouter une nouvelle plateforme à administrer moi-même.

C'est peut-être là que l'arrivée des agents IA autonomes change progressivement l'équation du self-hosting.

Installer une solution reste une chose. La comprendre, l'intégrer, la maintenir et interagir quotidiennement avec elle en est une autre.

Lorsque mon agent peut directement agir sur Kubernetes, Git ou Gitea — via tea ou les autres CLI auxquels je lui donne accès — il ne se limite plus à m'assister ponctuellement.

Dans cette expérience, il a participé directement à l'exploitation de l'infrastructure.

Cela ne supprime ni la responsabilité, ni la nécessité de comprendre l'infrastructure que j'administre. Mais cela réduit sensiblement la friction liée à son exploitation quotidienne.

Gitea n'est donc pas devenu mon remplaçant de GitHub.

Il est devenu ma plateforme Git locale.