Cinquante minutes de build gratuites par mois : c’est le quota du plan gratuit de Bitbucket Pipelines en 2026, à comparer aux quatre cents minutes offertes par GitLab CI sur son offre gratuite. Pour un développeur qui travaille seul sur trois ou quatre projets WordPress en parallèle, cet écart pèse vite sur le choix d’outil, bien avant toute question de fonctionnalités avancées.
Choisir son premier outil d’intégration continue en solo n’a rien d’anodin : la configuration prise au départ conditionne des mois d’habitudes. Ce comparatif se limite volontairement à ce qui compte pour un freelance sans équipe DevOps derrière lui : la lisibilité du fichier de configuration, le coût réel des minutes de build, et la façon dont chaque plateforme gère nativement les dépendances Composer d’un thème ou d’une extension WordPress.
La configuration YAML, deux philosophies différentes
Bitbucket Pipelines se configure dans un fichier bitbucket-pipelines.yml à la racine du dépôt, avec une structure assez rigide : un pipeline par défaut, des pipelines déclenchés par branche, et des étapes (step) qui s’enchaînent séquentiellement à l’intérieur d’un même pipeline. GitLab CI utilise un fichier .gitlab-ci.yml plus modulaire, organisé en stages et en jobs, avec la possibilité d’inclure d’autres fichiers YAML via include, ce qui devient utile dès qu’on gère plusieurs projets WordPress avec une base commune.
Sur un pipeline simple à deux étapes (installer les dépendances, lancer les tests), la différence est négligeable. Elle se creuse dès qu’on ajoute une étape de déploiement conditionnelle selon la branche : GitLab CI exprime nativement les règles avec rules et des variables comme CI_COMMIT_BRANCH, quand Bitbucket demande de dupliquer une partie de la configuration entre le pipeline par défaut et les pipelines par branche.
Le coût réel des minutes sur un projet WordPress
Un job WordPress typique — installation de Composer, exécution de PHPUnit ou PHP_CodeSniffer, éventuellement un build front avec npm — tourne entre trois et six minutes selon la taille du thème. Avec le quota Bitbucket de 50 minutes gratuites, cela représente moins de dix exécutions par mois, largement insuffisant dès qu’on pousse plusieurs commits par jour sur un projet actif. Les quatre cents minutes de GitLab CI absorbent beaucoup plus confortablement ce rythme, même en cumulant deux ou trois projets clients.
| Critère | Bitbucket Pipelines | GitLab CI |
|---|---|---|
| Minutes gratuites par mois | 50 | 400 |
| Fichier de configuration | bitbucket-pipelines.yml | .gitlab-ci.yml |
| Cache Composer natif | Oui, via caches: composer | Oui, via la clé cache et un chemin explicite |
| Règles conditionnelles par branche | Duplication partielle du YAML | Mot-clé rules intégré |
| Inclusion de fichiers YAML partagés | Limitée | include natif |
Composer, un support natif comparable
Les deux plateformes proposent un cache dédié pour Composer, ce qui évite de retélécharger les dépendances PHP à chaque exécution. Sur Bitbucket, il suffit de déclarer composer dans la section caches du pipeline pour bénéficier du cache par défaut de la plateforme. Sur GitLab CI, la déclaration est un peu plus explicite : il faut préciser le chemin du dossier vendor et une clé de cache basée sur le hash de composer.lock.
# .gitlab-ci.yml
cache:
key:
files:
- composer.lock
paths:
- vendor/
test:
stage: test
image: php:8.3-cli
script:
- composer install --no-progress
- vendor/bin/phpunit
Dans les deux cas, l’image Docker de base doit être choisie avec soin : une image PHP officielle légère évite d’installer manuellement les extensions courantes (mysqli, gd, zip) à chaque exécution, ce qui rallongerait le temps de build et grignoterait le quota de minutes gratuites.
Ce que ce comparatif ne couvre pas
Les runners auto-hébergés changent complètement l’équation du coût : en installant un runner GitLab CI sur son propre VPS, les minutes gratuites deviennent illimitées, ce qui rend la comparaison de quotas caduque. Ce choix suppose cependant de maintenir soi-même une machine, ce qui sort du cadre d’un comparatif pensé pour un développeur qui commence tout juste à automatiser ses déploiements et cherche la solution la plus simple à faire fonctionner en une soirée.
Notre verdict
Pour un solo qui débute avec l’intégration continue sur des projets WordPress, GitLab CI l’emporte sur deux points concrets : le quota gratuit plus généreux et la syntaxe rules qui simplifie les pipelines conditionnels par branche, un besoin qui arrive vite dès qu’on distingue une branche de recette et une branche de production. Bitbucket Pipelines reste pertinent si le dépôt est déjà hébergé sur Bitbucket pour d’autres raisons, mais il n’y a pas de raison de migrer un dépôt existant uniquement pour ce critère.
