Le piège du comparatif de fonctionnalités
Cherchez « GitLab vs Gitea » et vous tomberez sur des tableaux à quarante lignes où chaque produit coche à peu près les mêmes cases. Gestion des dépôts, oui. Interface web, oui. Revue de code, oui. Intégration continue, oui. Registre de paquets, oui. Authentification centralisée, oui.
Ces tableaux sont exacts, et parfaitement inutiles.
Parce qu’ils comparent ce qu’un produit sait faire le jour où vous l’installez, alors que le vrai sujet est ailleurs : ce qu’il va vous coûter tous les mois pendant trois ans.
Et pour un administrateur système, il y a une raison supplémentaire de raisonner ainsi. Ce que vous vous apprêtez à installer n’est pas un outil de confort posé dans un coin. À la fin de cette formation, votre forge distribuera des scripts à vos postes, alimentera vos serveurs en images de conteneurs, et servira peut-être de source de configuration à vos outils de déploiement. C’est un service de production. Le jour où elle tombe, ce n’est pas « on ne peut plus consulter le code » : ce sont vos GPO, vos déploiements et vos images qui sont impactés.
Une forge simple que vous maîtrisez vaut mieux qu’une forge riche que vous subissez.
Mon expérience : j’ai commencé par GitLab
Je peux difficilement mieux illustrer ce propos qu’en racontant ma propre erreur.
Ma première forge a été GitLab. Et je l’ai choisie exactement comme je viens de vous déconseiller de le faire : j’ai lu les comparatifs, GitLab cochait le plus de cases, donc GitLab. C’était la plus complète, c’était donc forcément la meilleure. Le raisonnement paraissait imparable.
Pendant un temps, tout allait bien. GitLab répondait à tous mes besoins — c’est une plateforme sérieuse, et ce n’est pas une critique du produit. Le problème n’était pas ce qu’elle savait faire, mais ce qu’elle me demandait en retour.
La complexité, d’abord. Chaque fois que je voulais activer une fonction — le registre d’images, les pages statiques — je me retrouvais dans une configuration nettement plus lourde que ce que le besoin justifiait. Beaucoup d’options, beaucoup de paramètres, et le sentiment permanent de n’exploiter qu’une petite partie de ce que je maintenais.
La consommation de ressources, ensuite. Une VM entière, correctement dimensionnée, pour un usage qui restait celui d’une infrastructure de taille modeste.
Les mises à jour, surtout. Un rythme soutenu, et à plusieurs reprises des changements qui ont cassé mes chaînes d’intégration continue existantes. Il fallait reprendre des définitions de pipelines qui fonctionnaient très bien la veille. À cela s’ajoutaient des correctifs de sécurité fréquents, qu’il fallait appliquer sans traîner.