# Un pipeline de déploiement unique pour un parc de 40 sites WordPress hétérogènes

> Concevoir un système paramétrable qui gère des configurations différentes sans dupliquer un pipeline par client.

- Auteur : Clément Hadrot
- Publié le : 2026-02-26
- Mis à jour le : 2026-02-26
- Catégorie : Outils & workflow
- URL : https://wpmoderne.dev.wordpress-developpement.fr/outils/pipeline-deploiement-unique-parc-heterogene/

## L’essentiel

- Un fichier de configuration par site remplace un pipeline dupliqué
- Le pipeline commun lit ce fichier pour adapter son comportement
- Les cas vraiment particuliers passent par une étape optionnelle isolée

Avant la refonte décrite ici, chaque nouveau client de l'agence recevait son propre fichier de workflow GitHub Actions, copié depuis le client précédent puis ajusté à la main : nom du serveur, méthode de déploiement, présence ou non d'un build front, etc. Après trois ans, l'agence gérait quarante variantes légèrement différentes du même pipeline, chacune ayant dérivé indépendamment au fil des correctifs appliqués ponctuellement. Corriger un bug de déploiement demandait, dans le pire des cas, de le corriger quarante fois.

Ce texte ne revient pas sur le déploiement blue-green en tant que technique, déjà détaillé séparément. Il décrit l'architecture retenue pour unifier ces quarante pipelines en un seul, paramétré, sans perdre la capacité à gérer les spécificités de chaque client.

## Identifier ce qui varie réellement d'un site à l'autre

Un audit des quarante workflows existants a permis de classer les variations en quatre catégories : la méthode de transport du code (rsync, SFTP, ou déploiement via image Docker), la présence ou non d'un build front nécessitant Node, l'hébergeur cible avec ses particularités de connexion, et une poignée de cas vraiment singuliers, comme un client avec une étape de purge de cache CDN spécifique à son fournisseur.

## Un fichier de configuration par site

Chaque dépôt de site reçoit désormais un fichier `deploiement.yaml` à sa racine, qui décrit ses propres particularités sans jamais toucher au pipeline lui-même :

> L'essentiel à retenir : Un fichier de configuration par site remplace un pipeline dupliqué ; Le pipeline commun lit ce fichier pour adapter son comportement ; Les cas vraiment particuliers passent par une étape optionnelle isolée

```
# deploiement.yaml
site:
  nom: boutique-nord
  methode_transport: rsync
  hote: boutique-nord.example.com
  utilisateur_ssh: deploiement
  chemin_distant: /var/www/boutique-nord

build:
  front_active: true
  gestionnaire: npm
  commande: "npm ci && npm run build"

etapes_supplementaires:
  - purge_cache_cloudflare

apres_deploiement:
  wp_cli:
    - "cache flush"
    - "rewrite flush"
```

## Le pipeline commun qui lit cette configuration

Un unique fichier `.github/workflows/deploiement.yml`, versionné dans un dépôt central puis référencé comme workflow réutilisable par chaque dépôt client, lit ce fichier de configuration et adapte son comportement en conséquence :

```
jobs:
  deployer:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Lire la configuration du site
        id: config
        run: |
          echo "methode=$(yq '.site.methode_transport' deploiement.yaml)" >> "$GITHUB_OUTPUT"
          echo "front_active=$(yq '.build.front_active' deploiement.yaml)" >> "$GITHUB_OUTPUT"
          echo "hote=$(yq '.site.hote' deploiement.yaml)" >> "$GITHUB_OUTPUT"

      - name: Construire le front si nécessaire
        if: steps.config.outputs.front_active == 'true'
        run: |
          COMMANDE=$(yq '.build.commande' deploiement.yaml)
          eval "$COMMANDE"

      - name: Déployer via rsync
        if: steps.config.outputs.methode == 'rsync'
        run: |
          rsync -avz --delete ./ deploiement@${{ steps.config.outputs.hote }}:$(yq '.site.chemin_distant' deploiement.yaml)

      - name: Déployer via SFTP
        if: steps.config.outputs.methode == 'sftp'
        run: |
          lftp -c "open -u deploiement, sftp://${{ steps.config.outputs.hote }}; mirror -R ./ ."

      - name: Exécuter les commandes WP-CLI post-déploiement
        run: |
          yq '.apres_deploiement.wp_cli[]' deploiement.yaml | while read -r commande; do
            ssh deploiement@${{ steps.config.outputs.hote }} "wp $commande --allow-root"
          done
```

### Gérer les étapes vraiment particulières

Pour le client dont le CDN nécessite une purge spécifique, l'étape `etapes_supplementaires` déclenche un script dédié, isolé dans un dossier `etapes-optionnelles/` du dépôt central, plutôt que d'introduire une branche conditionnelle spécifique dans le pipeline principal :

```
- name: Exécuter les étapes supplémentaires
        run: |
          yq '.etapes_supplementaires[]' deploiement.yaml | while read -r etape; do
            bash "etapes-optionnelles/${etape}.sh"
          done
```

## Ce que cette refonte a changé

| Avant | Après |
| --- | --- |
| 40 fichiers de workflow distincts | 1 fichier de workflow réutilisable |
| Correctif appliqué site par site | Correctif appliqué une fois, propagé à tous |
| Nouveau client : copier-coller et adapter | Nouveau client : remplir un fichier YAML |
| Dérive silencieuse entre pipelines | Comportement identique garanti par construction |

## La limite de cette approche

Cette unification demande une discipline de conception stricte : chaque nouveau besoin client doit d'abord être analysé pour déterminer s'il s'agit d'une variation légitime à paramétrer proprement, ou d'un cas si singulier qu'il justifie de rester une étape optionnelle isolée plutôt que d'ajouter une nouvelle branche conditionnelle générale dans le pipeline commun. Céder à la facilité d'ajouter une condition `if` supplémentaire à chaque demande finirait par reconstituer, à terme, la même complexité dispersée que celle qu'on cherchait à éliminer.

> Un pipeline commun qui accumule les cas particuliers non maîtrisés finit toujours par redevenir quarante pipelines déguisés en un seul.

## En résumé

Le passage à un pipeline unique paramétrable a réduit drastiquement le coût de maintenance du parc de déploiements de l'agence, au prix d'un effort de conception initial pour bien distinguer ce qui relève d'un paramètre légitime de ce qui relève d'une véritable exception. Le fichier de configuration par site, simple et lisible même par un développeur qui découvre le projet, s'est révélé être le bon niveau d'abstraction pour ce parc particulier.