# Un pipeline unique pour déployer extensions et thèmes blocs d’agence

> Deux pipelines distincts géraient jusqu'ici la publication des extensions et des thèmes blocs de l'agence. Voici pourquoi et comment ils ont fusionné.

- Auteur : Clément Hadrot
- Publié le : 2026-01-10
- Mis à jour le : 2026-01-10
- Catégorie : Outils & workflow
- URL : https://wpmoderne.dev.wordpress-developpement.fr/outils/pipeline-unique-deployer-extensions-themes-blocs-agence/

## L’essentiel

- Extensions et thèmes blocs partagent l'essentiel de leur chaîne de build
- Deux pipelines distincts doublaient la maintenance pour un bénéfice réel limité
- La distinction ne subsiste qu'au niveau du packaging final

Pourquoi deux pipelines de déploiement séparés pour des livrables qui partagent presque tout, du linting PHP à la compilation des assets JavaScript ? C'est la question posée en revoyant l'outillage de publication de l'agence, où les extensions maison et les thèmes blocs développés pour plusieurs clients suivaient jusqu'ici deux chaînes d'intégration continue distinctes, maintenues par deux configurations différentes malgré des étapes quasi identiques.

Ce texte détaille pourquoi cette séparation historique ne se justifiait plus, comment le pipeline unifié a été construit, et ce qui reste malgré tout spécifique à chaque type de livrable une fois la fusion réalisée.

## Pourquoi deux pipelines existaient à l'origine

La séparation initiale remontait à une époque où les extensions de l'agence étaient publiées uniquement sur un dépôt Packagist privé, tandis que les thèmes blocs, plus récents dans la pratique de l'équipe, étaient distribués directement aux clients sous forme d'archive zip. Ces deux modes de distribution avaient justifié, à l'époque, deux configurations de pipeline distinctes, chacune adaptée à sa cible finale.

Avec le temps, les étapes intermédiaires — installation des dépendances Composer, compilation des assets via un bundler JavaScript, exécution des tests PHPUnit, vérification du style de code — sont devenues quasiment identiques d'un pipeline à l'autre, sans que personne n'ait pris le temps de les rapprocher.

## Ce que le pipeline unifié a conservé et ce qu'il a changé

> L'essentiel à retenir : Extensions et thèmes blocs partagent l'essentiel de leur chaîne de build ; Deux pipelines distincts doublaient la maintenance pour un bénéfice réel limité ; La distinction ne subsiste qu'au niveau du packaging final

```
jobs:
  build:
    steps:
      - uses: actions/checkout@v4
      - name: Installer les dépendances
        run: composer install --no-dev && npm ci
      - name: Compiler les assets
        run: npm run build
      - name: Exécuter les tests
        run: composer run test
      - name: Packager selon le type de livrable
        run: |
          if [ "$LIVRABLE_TYPE" = "extension" ]; then
            ./scripts/package-extension.sh
          else
            ./scripts/package-theme-bloc.sh
          fi
```

Le pipeline unifié conserve une étape commune pour l'ensemble des tâches de build et de test, puis ne diverge qu'à la toute dernière étape : le packaging final, différent selon qu'il s'agit d'une extension destinée à Packagist ou d'un thème bloc destiné à une archive zip livrée au client. Cette divergence, désormais limitée à un script de quelques lignes plutôt qu'à une configuration de pipeline entière, s'est révélée largement suffisante pour couvrir la différence réelle entre les deux types de livrables.

## Ce que cette fusion a réellement changé au quotidien

Avant la fusion, toute évolution de la chaîne de build — passage à une nouvelle version de l'outil de compilation JavaScript, ajout d'une étape d'analyse statique du code — devait être répliquée manuellement dans les deux configurations, avec un risque réel d'oubli sur l'une des deux. Sur les six derniers mois avant la fusion, deux incidents distincts sont nés précisément de ce type d'oubli : une étape de sécurité ajoutée sur le pipeline des extensions, jamais répliquée sur celui des thèmes blocs.

- Une seule configuration à faire évoluer désormais, quel que soit le type de livrable concerné
- Un temps de maintenance du pipeline réduit d'après nos estimations à environ un tiers de ce qu'il représentait auparavant
- Un risque d'incohérence entre les deux chaînes définitivement écarté

## La limite de cette unification

Le pipeline unifié fonctionne parce que les deux types de livrables partagent un socle technique réellement commun. Il ne se généraliserait pas nécessairement à des livrables plus hétérogènes, comme un projet Bedrock complet à côté d'une simple extension WordPress, dont les étapes de build divergent bien plus profondément dès la phase d'installation des dépendances.

> Fusionner deux pipelines n'a de sens que si leur différence se limite réellement à la dernière étape, jamais par principe d'économie seule.

## En résumé

Deux pipelines distincts pour des livrables partageant l'essentiel de leur chaîne de build ne représentaient rien d'autre qu'une charge de maintenance dupliquée sans bénéfice réel. La fusion, limitée à isoler la seule étape de packaging qui diffère véritablement entre extensions et thèmes blocs, a simplifié l'outillage sans rien retirer de la spécificité propre à chaque type de livrable.