# Bitbucket Pipelines contre GitLab CI : lequel pour un solo sur WordPress

> 50 minutes de build gratuites par mois ne suffisent jamais : comparatif concret entre Bitbucket Pipelines et GitLab CI pour un développeur WordPress freelance.

- Auteur : Clément Hadrot
- Publié le : 2026-04-28
- Mis à jour le : 2026-04-28
- Catégorie : Outils & workflow
- URL : https://wpmoderne.dev.wordpress-developpement.fr/outils/bitbucket-pipelines-gitlab-ci-solo-wordpress/

## L’essentiel

- Quota de minutes gratuites très différent selon la plateforme
- Support natif de Composer quasi identique sur les deux
- Le YAML de GitLab CI plus lisible sur un pipeline à plusieurs étapes

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.

> L'essentiel à retenir : Quota de minutes gratuites très différent selon la plateforme ; Support natif de Composer quasi identique sur les deux ; Le YAML de GitLab CI plus lisible sur un pipeline à plusieurs étapes

| 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.