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
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.
