GitLab ou GitHub : lequel choisir pour notre petite équipe ?

La semaine où vous recrutez un sixième développeur, le groupe privé de premier niveau qui contient votre code sur GitLab.com Free dépasse cinq utilisateurs. D'après la documentation de GitLab sur la limite d'utilisateurs gratuits, le groupe passe alors en lecture seule. Sur GitHub Free pour les organisations, la nouvelle recrue arrive sans difficulté, puisque les collaborateurs sont illimités, mais vous vous heurterez à une autre limite la première fois que vous voudrez verrouiller main. Les dépôts privés de GitHub Free ne peuvent utiliser ni les branches protégées ni les propriétaires de code.

Les offres payantes à comparer ensuite sont GitHub Team, affichée à 4 $ par utilisateur et par mois — for the first 12 months, — et GitLab Premium, à 29 $ par utilisateur et par mois, facturés annuellement. Il existe aussi une option sans aucuns frais de licence : GitLab Community Edition. CE tourne sur des serveurs que vous contrôlez, l'un pour GitLab et l'autre pour le runner qui exécute vos jobs de CI, et le tableau ci-dessous lui consacre une colonne.

Comparatif des offres pour un dépôt privé

Chaque ligne ci-dessous part du principe d'un dépôt d'équipe privé. Les informations sur les offres proviennent de la page de tarifs ou de la documentation de chaque éditeur.

Offres et prix tels qu'affichés sur github.com/pricing et about.gitlab.com/pricing le 28 septembre 2026, et inchangés lors de notre nouvelle lecture des deux pages le 21 octobre. La page de GitHub n'indique pas le prix de Team après les 12 premiers mois. La ligne sur le stockage ne compare pas des choses équivalentes : le quota de GitHub couvre les packages et les artefacts Actions, celui de GitLab le stockage du dépôt Git et de LFS dans chaque projet.

Si votre équipe veut qu'une personne valide chaque déploiement avant qu'il n'atteigne la production, lisez la ligne sur les déploiements avant celle sur le prix. Sur GitHub Free, Pro et Team, les relecteurs obligatoires pour les environnements de déploiement ne fonctionnent que sur les dépôts publics, ce qui place ce contrôle un niveau au-dessus de la revue obligatoire avant fusion pour quiconque a du code privé. GitLab met les deux dans Premium, où les environnements protégés définissent qui peut déployer et qui doit approuver. Si votre code est public, la plupart de ces écarts disparaissent sur GitHub : les branches protégées et les relecteurs de déploiement fonctionnent tous deux sur les dépôts publics sans offre payante.

Quelle option convient à votre équipe

À notre avis, GitHub est le plus difficile à quitter quand vos pipelines reposent sur Actions, car migrer implique d'adapter à GitLab CI les workflows du Marketplace que vous réutilisez.

Ce que GitLab CE omet, et ce qu'il conserve

Dans CE, l'un de vos responsables peut fusionner une merge request que personne n'a relue, et GitLab ne l'en empêchera pas. Dans l'offre gratuite, qui correspond aux fonctionnalités de CE, les approbations « sont facultatives et n'empêchent pas la fusion sans approbation ». Tout ce qui figure dans la liste What needs Premium ci-dessous porte le badge Premium dans la documentation de GitLab.

Qu'une revue ait lieu avant reste à la discrétion de vos Maintainers. Si un contrat client ou un audit de conformité exige qu'aucune modification ne soit livrée sans une seconde approbation, CE ne peut pas l'imposer, alors que les règles d'approbation de Premium le peuvent.

Vous n'aurez pas à migrer pour en bénéficier. La documentation de GitLab sur la conversion vous fait installer le paquet Enterprise Edition (EE) par-dessus CE, puis ajouter une licence. Tant que vous ne l'avez pas ajoutée, EE propose gratuitement les mêmes fonctionnalités Free. Les fonctionnalités de Premium s'activent quand vous activez une licence payante.

Ce qu'implique l'auto-hébergement

Un administrateur CE sur le GitLab Forum, qui gère une instance d'environ 40 utilisateurs inscrits, dont cinq actifs environ, s'occupe de la routine chaque lundi :

Votre plan doit aller un peu plus loin :

• Appliquer les mises à jour de GitLab selon un calendrier que vous respectez, à une heure creuse. Après un démarrage à froid, notre instance de test a mis environ 2 minutes avant que sa page de connexion réponde
• Sauvegarder ailleurs que sur le serveur, et restaurer une copie de temps en temps pour vérifier que cela fonctionne. La sauvegarde de GitLab exclut gitlab.rb et gitlab-secrets.json, et sa documentation sur les sauvegardes indique de copier ces deux fichiers vous-même
• Mettre également à jour GitLab Runner sur son propre serveur
• Désigner une deuxième personne capable de tout faire en l'absence de la première

Voici ce que coûte une année de sièges au prix affiché, avant de compter quoi que ce soit pour les serveurs :

Soit 29 $ et 4 $ par utilisateur et par mois, multipliés par 12. Notre guide sur les coûts par utilisateur de GitLab et GitHub comparés à un serveur GitLab CE chiffre la facture complète, serveurs compris. Au salaire médian américain de 2025 pour les développeurs de logiciels, analystes QA et testeurs, soit 64,44 $ de l'heure selon le Bureau of Labor Statistics, 10 sièges Premium coûtent à peu près autant que 54 heures de travail d'un développeur par an, et 10 sièges GitHub Team environ 7 heures.

Pour mettre ces heures en balance avec les frais par siège de votre équipe, prenez une année de sièges Premium, soustrayez le coût des deux serveurs et divisez par votre propre coût horaire. Vous obtenez le nombre d'heures de maintenance par an que vous pourriez y consacrer avant que CE ne coûte plus cher que Premium. Ce calcul ne porte que sur le coût, car CE n'impose pas les approbations comme le fait Premium. Si GitHub Team est votre autre option, faites le même calcul avec son prix de 4 $ par siège. À ce prix, les frais par siège mettent beaucoup plus de temps à atteindre le coût de deux serveurs et de leur maintenance.

Sur le VPS GitLab de DreamHost, DreamHost assure le support du matériel, du réseau et de la connectivité 24 h/24 et 7 j/7, et la page produit précise que vous gérez vous-même les mises à jour logicielles et la configuration. Les sauvegardes sont aussi à votre charge, comme l'indique la liste ci-dessus.

La taille de serveur nécessaire pour GitLab

La page des exigences de GitLab fixe 8 vCPU et 16 Go de mémoire comme référence pour une installation sur un seul nœud. Les offres VPS GitLab de DreamHost comprennent Stack 16 (4 vCPU, 16 Go) et Stack 32 (8 vCPU, 32 Go). Stack 32 est la première offre qui atteint cette référence. Stack 16 a bien les 16 Go, mais la moitié des 8 vCPU : elle reste donc en dessous de la référence, et les offres plus petites encore plus loin. Le guide de GitLab pour les environnements à mémoire limitée descend bien plus bas, pour cinq développeurs maximum. Aucune des deux pages ne mentionne une équipe de 10 ou 20 personnes.

Ces chiffres concernent GitLab lui-même. Les jobs de CI doivent tourner ailleurs : la page d'installation du runner de GitLab indique d'installer GitLab Runner sur une machine distincte de celle qui héberge votre instance GitLab. GitLab ne publie pas de taille pour cette machine. Sa page sur les exigences du runner précise que cela dépend du CPU et de la mémoire utilisés par vos jobs, du nombre de jobs exécutés en même temps et du nombre de personnes qui travaillent en parallèle. Notre propre estimation le place sur Stack 8, qui offre 2 vCPU et 8 Go, comme le runner hébergé par défaut de GitLab.com.

Pages des exigences de GitLab consultées le 28 septembre 2026, et pages sur le runner le 20 octobre 2026. Les caractéristiques des Stack proviennent de la page VPS GitLab de DreamHost.

La documentation de GitLab n'indique pas à partir de quand 4 vCPU deviennent insuffisants pour une équipe de votre taille, et nous ne l'avons pas mesuré non plus : le test ci-dessous fait donc tourner GitLab sur Stack 16 et l'observe pendant l'exécution des pipelines. Si des jobs se mettent en file d'attente pendant le test, vérifiez le réglage de concurrence du runner et l'utilisation du CPU sur les deux serveurs avant d'incriminer une offre. Un serveur GitLab dont le CPU frôle la saturation pendant les pipelines est le signe que vous avez trouvé la limite, et Stack 32 atteint les deux valeurs de référence de la page des exigences. L'espace disque augmente avec vos dépôts, vos images de conteneurs et vos artefacts de CI : vérifiez l'espace utilisé à la fin de l'essai et faites une projection.

Ce que GitLab CE a consommé sur notre VM de test

Les pages de dimensionnement de GitLab donnent une référence pour un usage réel et un plancher pour la mémoire limitée, mais aucune mesure de ce qu'une installation vide consomme réellement. Nous avons donc lancé l'image officielle GitLab CE 19.5.0 sur une VM de test de 2 vCPU et 8 Go, à peu près la taille du serveur runner ci-dessus, et relevé sa mémoire 10 minutes après sa stabilisation. Nous avons ensuite exécuté trois pipelines d'un petit projet Node.js, avec GitLab Runner sur la même VM.

Dans les chiffres de CPU, 100 % correspond à un vCPU : le job et GitLab ont donc eu besoin ensemble de plus que les deux vCPU de la VM. Ces exécutions n'impliquaient aucun utilisateur et un seul petit projet : elles ne permettent pas d'en déduire une taille d'équipe. Elles situent néanmoins la mémoire de GitLab au repos à environ 4 285 Mio avec les réglages par défaut et environ 2 657 Mio avec les réglages pour mémoire limitée, soit environ un quart des 16 Go de Stack 16 ou moins, ce qui fait des 4 vCPU le chiffre à surveiller. Pendant l'essai, surveillez donc le CPU des deux serveurs pendant l'exécution de vos propres pipelines.

Comment tester CE le temps d'un sprint

Créez un miroir de votre code sur le serveur de test et laissez l'original là où il est : si le test ne donne rien, vous n'aurez rien à rapatrier.

1. Copiez un vrai dépôt

   Choisissez un dépôt avec un pipeline fonctionnel et son véritable historique, pour que le test reflète la taille réelle de votre code et vos vrais temps de build. L'outil d'importation GitHub de GitLab transfère le dépôt, les tickets et les pull requests.

2. Définissez la règle de fusion

   Protégez main en réglant Allowed to merge sur Maintainers et Allowed to push and merge sur No one. Voyez ensuite si vos responsables techniques s'accommodent d'approbations que GitLab n'imposera pas.

3. Faites tourner la CI pendant une semaine normale

   Enregistrez un runner sur un second serveur, un Stack 8, et lancez vos pipelines habituels. S'il s'agit de workflows GitHub Actions, réécrivez-les d'abord pour GitLab CI et comptez ces heures dans le test. Notez combien de temps les jobs attendent pendant que des personnes utilisent l'application web.

4. Testez une restauration et une mise à jour

   Restaurez une sauvegarde, ainsi que vos copies de gitlab.rb et gitlab-secrets.json, sur un serveur de rechange jetable, puis appliquez une mise à jour de GitLab. Notez la durée de chaque opération et tout ce que vous avez dû corriger à la main. Nous n'avons pas chronométré de mise à jour sur notre VM de test : c'est donc de cette étape que viendra votre estimation du temps de maintenance.

Avant le début du sprint, fixez par écrit votre seuil de réussite : combien de temps un build peut attendre, et combien d'heures de maintenance par mois vous jugez acceptables.

Comment nous avons testé GitLab CE

Les chiffres GitLab de cette page ont été mesurés par DreamHost sur une VM de test (arm64), et non sur un serveur DreamHost, le 20 octobre 2026. Il s'agit du même test que celui de notre guide sur les coûts par utilisateur de GitLab et de GitHub, qui détaille toute la configuration et les mesures au repos. Nos offres utilisent des processeurs x86 AMD EPYC : attendez-vous donc à de légères différences sur un vrai serveur. En bref : l'image officielle de CE 19.5.0 sur une machine à 2 vCPU avec 8 Go de mémoire (7 922 Mio selon Linux), une fois avec les paramètres par défaut et une fois avec les paramètres pour mémoire limitée de GitLab. Pour les pipelines, GitLab Runner tournait sur la même machine et a exécuté trois fois les jobs de test et de build du projet open source Express, pendant que nous relevions la mémoire et le CPU toutes les 3 secondes.

Ce que nous n'avons pas testé : la charge d'une vraie équipe, un dépôt volumineux, plusieurs pipelines simultanés, un runner sur un second serveur, les 4 vCPU du Stack 16 ou les 8 du Stack 32, et l'interruption de service liée à une mise à jour. Chaque configuration n'a été testée qu'une seule fois. Les caractéristiques et les prix des offres proviennent des pages de GitHub et de GitLab, aux dates indiquées dans les sources.

FAQ GitLab ou GitHub