Comparer deux outils d’intégration continue n’a de sens que si l’un des deux ne nécessite aucune migration du code source. C’est précisément la situation d’une agence dont les dépôts vivent sur Bitbucket depuis des années, avec un historique de tickets Jira lié à chaque branche, une équipe habituée à l’interface, et des dizaines de dépôts de thèmes et d’extensions WordPress. La question n’est pas « quel est le meilleur outil d’intégration continue dans l’absolu », mais « le gain apporté par GitHub Actions justifie-t-il la migration complète du code, des identifiants et des habitudes d’une équipe entière ». Cet article ne traite pas de la mécanique de cette migration elle-même, seulement de l’arbitrage qui précède la décision.
Les deux outils permettent d’automatiser les mêmes tâches typiques d’un projet WordPress : lancer une suite de tests PHPUnit, vérifier le code avec PHPCS, construire les assets d’un thème à blocs, puis déployer sur un serveur de recette ou de production. La différence se joue ailleurs, dans l’écosystème, la maturité de certaines fonctionnalités, et le coût réel de rester où l’on est.
Ce que Bitbucket Pipelines fait déjà bien
Bitbucket Pipelines s’intègre nativement avec le reste de la suite Atlassian, ce qui compte pour une agence qui utilise Jira au quotidien pour son suivi de tickets. La configuration se fait dans un fichier bitbucket-pipelines.yml à la racine du dépôt, avec une syntaxe proche de celle d’autres outils basés sur des conteneurs Docker :
image: php:8.2
pipelines:
default:
- step:
name: Tests PHPUnit
caches:
- composer
script:
- composer install --no-interaction
- vendor/bin/phpunit
Pour une agence de taille modeste, avec un nombre de dépôts limité, cette simplicité constitue un vrai atout : peu de concepts à apprendre, une interface qui reste dans le même produit que la gestion de projet, et un quota de minutes de build gratuit suffisant tant que le nombre de projets actifs reste raisonnable.
Ce que GitHub Actions apporte de plus à grande échelle
La force de GitHub Actions tient dans son marché d’actions réutilisables, publiées par la communauté ou par les projets eux-mêmes, et dans la possibilité de créer des workflows réutilisables partagés entre plusieurs dépôts d’une même organisation. Pour une agence qui gère plusieurs dizaines de projets WordPress avec des étapes très similaires d’un dépôt à l’autre (installation des dépendances, tests, construction des assets, déploiement), cette réutilisation change la maintenance :
jobs:
tests:
uses: mon-agence/workflows-partages/.github/workflows/tests-wordpress.yml@main
with:
version-php: '8.2'
Un seul fichier de workflow central, versionné dans un dépôt dédié, peut alors être appelé depuis chaque projet, ce qui évite de dupliquer la même logique de test dans vingt fichiers différents et de devoir les mettre à jour un par un en cas de changement.
Comparatif direct
| Critère | Bitbucket Pipelines | GitHub Actions |
|---|---|---|
| Intégration avec un suivi de tickets Atlassian | Native | Nécessite une extension tierce |
| Workflows réutilisables entre dépôts | Limité | Natif et mature |
| Marché d’actions communautaires | Réduit | Très large |
| Simplicité pour une petite équipe | Élevée | Correcte, courbe d’apprentissage un peu plus longue |
| Coût de migration si déjà en place | Nul | Migration complète du code et des secrets |
Le vrai coût caché : la migration elle-même
Le comparatif technique penche souvent en faveur de GitHub Actions dès que le nombre de projets dépasse une dizaine. Mais il ignore un facteur décisif pour une agence déjà installée sur Bitbucket : migrer signifie déplacer l’historique complet de chaque dépôt, reconfigurer les clés de déploiement et les secrets d’environnement pour chacun, former l’équipe à une interface différente, et probablement faire cohabiter les deux systèmes pendant une période de transition qui n’est jamais aussi courte qu’annoncée au départ.
- Évaluer le nombre de projets qui bénéficieraient réellement d’un workflow réutilisable, pas seulement en théorie.
- Chiffrer le temps de reconfiguration des secrets et des clés SSH de déploiement pour chaque dépôt migré.
- Considérer une migration progressive, projet par projet, plutôt qu’un basculement complet à une date fixe.
- Ne migrer les projets les plus anciens et les moins actifs qu’en dernier, voire pas du tout.
Le conseil que nous donnons systématiquement dans ce genre d’arbitrage : ne jamais migrer un outil d’intégration continue pour des raisons de préférence esthétique, seulement quand le coût de la stagnation dépasse clairement celui du changement.
Notre verdict
Pour une agence déjà installée sur Bitbucket, avec un parc de projets WordPress raisonnable et un usage quotidien de Jira, rester sur Bitbucket Pipelines reste un choix défendable tant que la duplication de configuration entre dépôts ne devient pas ingérable. La bascule vers GitHub Actions se justifie surtout à partir d’un volume de projets suffisant pour que la réutilisation de workflows communs compense largement le coût, réel et souvent sous-estimé, d’une migration complète.
