# Provisionner en une commande les sous-sites d’un réseau d’agences d’intérim

> Un script de provisioning garantit qu'une nouvelle agence locale démarre avec exactement la même configuration que les autres, sans copier-coller manuel.

- Auteur : Clément Hadrot
- Publié le : 2024-12-28
- Mis à jour le : 2024-12-28
- Catégorie : Outils & workflow
- URL : https://wpmoderne.dev.wordpress-developpement.fr/outils/provisionner-agences-interim-script-unique/

## L’essentiel

- Un script unique évite la dérive de configuration entre agences
- wp site create industrialise la création de sous-sites
- Les réglages métier restent dans un fichier versionné, pas dans la tête d'une personne

`wp site create --slug=agence-nantes --title="Agence Nantes"` : cette seule ligne prend moins d'une seconde à s'exécuter, mais elle ne représente qu'une fraction du travail réel. Une nouvelle agence d'intérim locale a besoin d'un formulaire de candidature, d'une liste de secteurs d'activité propre à sa région, d'un jeu de pages type et d'un compte administrateur nominatif. Sans script, chacune de ces étapes se fait à la main, et la mémoire humaine finit toujours par varier d'une ouverture à l'autre.

Ce réseau compte aujourd'hui dix-sept agences, chacune hébergée sur un sous-site d'une installation multisite. L'objectif du script de provisioning n'est pas de gérer les candidatures elles-mêmes, un module dédié s'en charge déjà, mais de garantir que le socle technique de chaque nouvelle agence soit rigoureusement identique aux seize précédentes.

## Ce que la création manuelle laissait passer

Avant l'automatisation, l'ouverture d'une agence suivait une procédure écrite dans un document partagé, relue et suivie avec plus ou moins de rigueur selon la personne qui s'en chargeait. Deux erreurs revenaient régulièrement : l'oubli de la page de mentions légales adaptée à la région, et un rôle personnalisé mal attribué à l'administrateur local, qui se retrouvait parfois avec les droits d'un simple contributeur.

Ces écarts ne se voyaient pas tout de suite. Ils remontaient des semaines plus tard, sous forme de tickets de support, quand l'agence tentait de modifier un contenu qu'elle ne pouvait pas éditer. Un script élimine ce type d'incident en figeant la procédure dans du code plutôt que dans une intention.

## La structure du script de provisioning

> L'essentiel à retenir : Un script unique évite la dérive de configuration entre agences ; wp site create industrialise la création de sous-sites ; Les réglages métier restent dans un fichier versionné, pas dans la tête d'une personne

Le script s'appuie entièrement sur `wp-cli` et s'exécute en une seule invocation, avec le nom de la ville et le code région en arguments. Il enchaîne quatre opérations : la création du site, l'activation des extensions communes, l'import du jeu de pages type, puis la création du compte administrateur local avec le rôle personnalisé `gestionnaire_agence`.

```
#!/usr/bin/env bash
set -euo pipefail

VILLE="$1"
REGION="$2"
SLUG=$(echo "$VILLE" | iconv -t ascii//TRANSLIT | tr 'A-Z ' 'a-z-')

wp site create --slug="$SLUG" --title="Agence $VILLE" \
  --email="admin@reseau-interim.example"

wp plugin activate formulaire-candidature suivi-missions --url="$SLUG"

wp import ./modeles/pages-agence.xml --authors=create --url="$SLUG"

wp user create "gestionnaire-$SLUG" "contact+$SLUG@reseau-interim.example" \
  --role=gestionnaire_agence --url="$SLUG"

wp option update reseau_region "$REGION" --url="$SLUG"
```

Le rôle `gestionnaire_agence` est déclaré une seule fois, dans un plugin d'intégration commun, via `add_role()` exécuté sur `init` si le rôle n'existe pas encore. Il reprend les capacités d'un éditeur, privé de la capacité `manage_options`, pour éviter qu'une agence locale ne modifie les réglages globaux du réseau.

## Le jeu de pages type et ses limites

Le fichier `pages-agence.xml` contient un export WXR minimal : page d'accueil, page contact, page mentions légales avec des espaces réservés à compléter. Le choix d'un export statique plutôt que d'un appel à une API interne a été délibéré, car il ne dépend d'aucun service tiers disponible au moment du provisioning. Il faut néanmoins régénérer ce fichier chaque fois que le gabarit de pages évolue, sous peine de livrer des agences avec un contenu obsolète.

Une limite persiste : le script ne vérifie pas que le nom de ville proposé ne crée pas de collision de `slug` avec une agence existante. Un contrôle préalable via `wp site list --field=slug` reste nécessaire avant de lancer la commande, ou doit être ajouté dans une prochaine itération du script.

## Ce que l'automatisation a réellement changé

Le temps d'ouverture d'une agence est passé d'environ deux heures réparties sur plusieurs jours à moins de dix minutes en une seule session. Mais le gain le plus net concerne la cohérence : les dix-sept sous-sites partagent aujourd'hui la même arborescence de pages, les mêmes rôles, et un réglage de région correctement rempli à chaque fois, ce qui simplifie considérablement les rapports consolidés au niveau du réseau.

Le script reste volontairement simple. Il ne gère ni la désactivation d'une agence fermée, ni la migration de contenu entre deux sous-sites, deux besoins réels mais plus rares, traités au cas par cas plutôt qu'automatisés dans l'immédiat.

## En résumé

Un provisioning scripté ne remplace pas une réflexion sur la structure du réseau, il la fige et la répète fidèlement. Pour un multisite qui grandit régulièrement, ce type d'outil transforme une tâche répétitive et sujette à l'erreur humaine en une opération fiable, mesurable, et rejouable à l'identique d'une ouverture à l'autre.