Un seul modèle de pipeline partagé par toute une agence : la gouvernance

developer.wordpress.org ne documente aucune recommandation officielle sur la structuration d’une chaîne d’intégration continue pour un parc de projets WordPress — cette décision reste entièrement du ressort de chaque équipe, ce qui explique pourquoi tant d’agences finissent avec autant de variantes de pipeline que de projets gérés.

Un modèle de pipeline unique, référencé par l’ensemble des projets d’une agence plutôt que copié et adapté indépendamment dans chacun, élimine cette dérive à la racine. Mais cette centralisation introduit un risque symétrique : une modification malencontreuse du modèle central peut affecter simultanément tous les projets qui en dépendent, ce qui impose une gouvernance explicite plutôt qu’une modification informelle au fil de l’eau.

Le principe du modèle référencé

GitHub Actions permet à un fichier de configuration de réutiliser un flux de travail défini dans un dépôt distinct, via la syntaxe uses: pointant vers ce dépôt et une référence de version :

jobs:
  deploiement:
    uses: mon-agence/pipelines-partages/.github/workflows/deploiement-wordpress.yml@v3
    with:
      environnement: production
    secrets: inherit

Chaque projet référence ainsi une version précise du modèle partagé, plutôt que d’en dupliquer le contenu. Une modification du modèle central, une fois publiée sous une nouvelle version, ne s’applique aux projets existants que lorsqu’ils choisissent explicitement de migrer vers cette nouvelle référence.

Ce que la gouvernance doit trancher

La centralisation du modèle pose une question de gouvernance qu’un modèle dupliqué par projet ne pose jamais aussi frontalement : qui a le droit de proposer une modification, qui la valide, et selon quel processus une nouvelle version est publiée et adoptée.

Qui propose

N’importe quel membre de l’équipe technique peut proposer une modification via une requête de fusion classique sur le dépôt du modèle partagé, au même titre que pour n’importe quel autre dépôt de code.

Qui valide

La validation d’une modification du modèle partagé est réservée à un petit groupe de personnes désignées, distinct de l’ensemble de l’équipe technique, précisément parce que l’impact d’une erreur ici touche plusieurs projets simultanément plutôt qu’un seul.

Comment une version se propage

Toute publication d’une nouvelle version majeure du modèle s’accompagne d’un journal des modifications explicite et d’une période de transition pendant laquelle l’ancienne version reste disponible et fonctionnelle, le temps que chaque projet migre à son propre rythme plutôt que d’être forcé à une adoption immédiate.

Un exemple d’incident évité par cette gouvernance

Une modification proposée pour ajouter une étape de scan de sécurité au modèle partagé aurait, dans sa première version soumise, bloqué le déploiement de tout projet dont une dépendance présentait une vulnérabilité de gravité moyenne, sans période de transition. La revue par le groupe de validation a identifié ce risque avant publication et a imposé un seuil de blocage limité aux vulnérabilités critiques dans un premier temps, avec un assouplissement progressif annoncé à l’avance plutôt qu’un changement de comportement brutal pour l’ensemble des projets du parc.

Versionner le modèle comme n’importe quelle bibliothèque

Le dépôt du modèle partagé applique un versionnage sémantique classique : une version mineure ajoute une fonctionnalité sans casser la compatibilité des projets existants, une version majeure peut introduire un changement de comportement nécessitant une adaptation explicite du fichier de configuration de chaque projet migrant. Cette discipline, habituelle pour une bibliothèque de code, s’applique tout aussi bien à un modèle de pipeline partagé.

• Version mineure : nouvelle option facultative, rétrocompatible par défaut
• Version majeure : changement de comportement par défaut, nécessitant une migration volontaire
• Journal des modifications tenu à jour pour chaque publication

Ce que cette gouvernance ne résout pas seule

Un modèle bien gouverné réduit le risque d’une modification malencontreuse, mais ne dispense pas de tester chaque nouvelle version sur un projet représentatif avant sa publication définitive comme version stable. La gouvernance encadre le processus humain de décision ; elle ne remplace pas une validation technique effective du comportement du modèle lui-même.

En résumé

Centraliser le modèle de pipeline d’une agence dans un unique dépôt référencé par l’ensemble des projets élimine la dérive habituelle d’une configuration copiée et adaptée projet par projet, à condition d’accompagner cette centralisation d’une gouvernance claire sur qui décide, qui valide et comment chaque version se propage. Sans cette gouvernance, le gain de cohérence se paierait au prix d’un risque d’incident généralisé à la moindre modification imprudente.