Un développeur pousse du code — un conteneur démarre pour exécuter des tests. Si vous utilisez GitHub, ce runner exécute une série d'actions JavaScript ou Docker récupérées sur une marketplace publique. Si vous utilisez GitLab, un unique binaire écrit en Go exécute un fichier YAML hautement structuré à l'aide de mots-clés natifs.
Bien que votre équipe ait probablement déjà choisi sa plateforme d'hébergement Git, les couches CI de GitHub et GitLab reposent sur des philosophies architecturales fondamentalement différentes. Choisir comment exécuter vos builds, gérer vos runners et sécuriser vos secrets nécessite d'examiner de près ces moteurs sous-jacents.
Les différences architecturales fondamentales
GitHub Actions et GitLab CI abordent l'exécution des pipelines depuis les deux extrémités opposées du spectre de la modularité.
GitHub Actions est hautement composable. Il s'appuie sur un modèle d'exécution étape par étape où chaque étape peut exécuter des actions créées par la communauté. Ces actions sont essentiellement des dépôts de code packagés écrits en JavaScript ou encapsulés dans des conteneurs Docker. Cela rend la plateforme extrêmement extensible — mais cela introduit des dépendances externes dans votre processus de build.
GitLab CI repose sur une configuration YAML centralisée et hautement structurée. Au lieu de récupérer des tâches tierces sur une marketplace, vous définissez des jobs et les orchestrez à l'aide de mots-clés intégrés puissants tels que rules, needs et stages. Cette conception privilégie la prévisibilité et le contrôle — en conservant l'intégralité de la définition de votre pipeline dans les limites de votre propre dépôt.
Gestion des runners et auto-hébergement
L'exécution de builds sur une infrastructure hébergée devient rapidement coûteuse. Pour les charges de travail importantes, les équipes gèrent souvent leurs propres agents de build.
GitHub utilise une application de runner auto-hébergée écrite en .NET Core. Bien qu'elle prenne en charge les principaux systèmes d'exploitation, l'orchestration de flottes importantes de ces runners nécessite souvent des outils tiers. Par exemple, pour mettre à l'échelle automatiquement les runners GitHub sur Kubernetes, de nombreuses équipes de plateforme s'appuient sur le contrôleur open-source Actions Runner Controller (ARC).
GitLab Runner est un binaire unique écrit en Go. Il dispose d'un modèle d'exécuteur intégré et mature. Prêt à l'emploi, GitLab Runner prend en charge nativement plusieurs exécuteurs, notamment :
- Kubernetes (création d'un nouveau pod pour chaque job)
- Docker (exécution des jobs dans des conteneurs isolés)
- VirtualBox ou Parallels (pour des environnements de machines virtuelles propres)
- Shell (pour une exécution directe sur l'hôte)
Pour les infrastructures d'entreprise complexes, la configuration d'autoscaling native de GitLab est généralement plus facile à mettre en place et à maintenir, sans dépendre de contrôleurs open-source externes.
Syntaxe des pipelines et complexité de la configuration
Les deux plateformes utilisent YAML, mais elles gèrent les flux de travail complexes différemment.
GitHub Actions utilise des workflows réutilisables et des actions composites pour réduire la duplication. Une action composite vous permet de regrouper plusieurs étapes en une seule étape réutilisable — tandis que les workflows réutilisables vous permettent de partager des modèles de pipeline entiers entre différents dépôts.
GitLab CI utilise un modèle d'héritage basé sur extends et includes. Cela permet aux équipes de plateforme d'écrire un modèle de pipeline maître et de l'inclure dans des centaines de projets. Les développeurs peuvent ensuite surcharger des paramètres spécifiques selon leurs besoins.
Exemple pratique : builds matriciels
Prenons un scénario dans lequel vous devez exécuter des tests d'intégration sur plusieurs versions de Node.js et plusieurs moteurs de base de données.
Dans GitHub Actions, vous définissez une stratégie matricielle directement dans la configuration du job :
jobs:
test:
runs-on: ubuntu-latest
strategy:
matrix:
node-version: [16, 18, 20]
database: [postgres, mysql]
steps:
- uses: actions/checkout@v4
- name: Use Node.js
uses: actions/setup-node@v4
with:
node-version: ${{ matrix.node-version }}
- run: npm ci
- run: npm test
Dans GitLab CI, vous obtenez ce résultat en utilisant le mot-clé parallel:matrix :
test:
image: node:$NODE_VERSION
services:
- name: $DATABASE_IMAGE
parallel:
matrix:
- NODE_VERSION: ["16", "18", "20"]
DATABASE_IMAGE: ["postgres:15", "mysql:8"]
script:
- npm ci
- npm test
Les deux approches mènent au même résultat : l'exécution de 6 jobs de test en parallèle. Cependant, GitHub Actions s'appuie sur une action de la marketplace (actions/setup-node) pour configurer l'environnement — tandis que GitLab CI s'attend à ce que vous définissiez directement l'image Docker de base.
Écosystème, marketplace et extensibilité
Le choix ici dépend de votre préférence entre une plateforme managée par un fournisseur unique ou un écosystème porté par la communauté.
La marketplace de GitHub contient des milliers d'actions pré-construites. Si vous devez envoyer une notification Slack, téléverser un artefact sur AWS ou exécuter un scan de sécurité, une action prête à l'emploi existe probablement déjà. Cela accélère la création initiale du pipeline. Cependant, dépendre d'actions communautaires signifie que vous devez faire confiance aux mainteneurs amont — ou figer chaque action sur un SHA de commit spécifique pour éviter les attaques sur la chaîne d'approvisionnement.
GitLab CI évite le modèle de marketplace. À la place, GitLab intègre les fonctionnalités courantes directement dans sa plateforme. L'analyse de sécurité, la gestion du registre de conteneurs et le suivi des releases sont des fonctionnalités natives. Cela réduit votre dépendance vis-à-vis de code tiers — mais cela signifie que vous devez écrire des étapes personnalisées en shell ou en conteneur si GitLab ne prend pas en charge nativement un outil spécifique.
Si votre équipe souhaite évaluer comment ces écosystèmes s'intègrent dans une chaîne d'outils plus large, les lecteurs peuvent explorer d'autres options sur StackMatch.
Sécurité et gestion des secrets
Les deux plateformes prennent en charge les identifiants fédérés OpenID Connect (OIDC) modernes. Cela permet à vos pipelines de s'authentifier auprès de fournisseurs cloud comme AWS, GCP ou Azure sans stocker de clés d'accès à longue durée de vie dans votre configuration CI.
GitHub sécurise les environnements en vous permettant de restreindre les secrets à des branches ou des environnements de déploiement spécifiques. Vous pouvez également exiger une approbation manuelle avant l'exécution d'un job de déploiement.
GitLab propose des protections similaires par environnement, mais ajoute une intégration native plus étroite avec HashiCorp Vault. Il fournit également une détection intégrée des secrets dans le cadre de sa plateforme de base — analysant votre code à la recherche de clés API commises par erreur avant même la fin du build.
Faire le bon choix : quand utiliser quoi
Le choix de votre moteur de CI doit correspondre au style opérationnel de votre équipe :
- Choisissez GitHub Actions si votre équipe privilégie la rapidité, s'appuie fortement sur des outils open-source publics et préfère utiliser des composants pré-construits plutôt que d'écrire des scripts personnalisés. C'est le choix naturel pour les projets qui bénéficient d'un vaste écosystème communautaire.
- Choisissez GitLab CI si vous gérez des pipelines multi-projets complexes, si vous exploitez votre propre infrastructure de runners sur Kubernetes et si vous préférez une plateforme unique et unifiée où l'analyse de sécurité et les registres de conteneurs sont gérés par un seul fournisseur.
FAQ
Puis-je utiliser GitLab CI avec un dépôt GitHub ?
Oui. GitLab prend en charge la CI/CD pour les dépôts externes. Cela vous permet d'exécuter des pipelines GitLab CI sur du code hébergé dans GitHub, bien que cela nécessite une configuration supplémentaire par rapport à l'utilisation native de GitHub Actions.
Quelle plateforme offre la meilleure mise en cache pour les dépendances de build ?
Les deux plateformes proposent des mécanismes de mise en cache robustes. La configuration des clés de cache de GitLab CI est généralement plus flexible pour les stratégies multi-branches complexes — tandis que GitHub Actions s'appuie fortement sur des actions de mise en cache gérées par la communauté.
Comment se comparent les modèles de tarification pour les minutes de CI ?
Les deux plateformes proposent des offres gratuites incluant des minutes de runner hébergé. GitLab facture en fonction de l'utilisation des ressources de calcul sur l'ensemble de ses forfaits — tandis que les tarifs de GitHub Actions varient selon la visibilité du dépôt et le système d'exploitation du runner.