# Outiller un studio d’événementiel qui gère vingt sites de mariage par an

> Un site par mariage organisé, jamais réutilisé après l'événement. La duplication rapide d'un modèle s'est imposée face à la complexité inutile d'un multisite.

- Auteur : WordPress Développement
- Publié le : 2024-11-15
- Mis à jour le : 2024-11-15
- Catégorie : Outils & workflow
- URL : https://www.wpmoderne.fr/outils/studio-evenementiel-vingt-sites-mariage-par-an/

## L’essentiel

- Chaque site de mariage a une durée de vie de quelques mois seulement
- Un multisite aurait ajouté de la complexité pour un usage éphémère
- Un script d'échafaudage crée un site fonctionnel en quelques minutes

Un site créé, personnalisé pendant quelques semaines, consulté intensément le jour de l'événement, puis progressivement laissé à l'abandon une fois les remerciements envoyés aux invités. Ce cycle de vie très particulier, propre à un studio qui conçoit un site dédié pour chaque mariage qu'il organise, ne ressemble à aucun autre type de projet WordPress habituel. Avec une vingtaine de sites créés chaque année, la question de l'outillage s'est vite posée : fallait-il regrouper l'ensemble sous un réseau multisite, ou construire un outil de duplication rapide qui produit des sites totalement indépendants ?

Cet article ne traite pas de la conception graphique de ces sites, assurée par l'équipe créative du studio, mais uniquement de l'outillage technique qui permet de passer d'une commande signée à un site en ligne en quelques minutes. Le choix retenu ici a été d'écarter le multisite au profit d'un script de duplication d'un modèle de référence.

## Pourquoi le multisite ne convenait pas à ce rythme de création et d'abandon

Un réseau multisite WordPress suppose une gestion centralisée dans la durée : mises à jour groupées, base de données partagée, administration réseau commune. Or les sites de ce studio ne vivent pas dans la durée. Une fois l'événement passé, la plupart ne reçoivent plus aucune modification, certains sont conservés quelques mois par nostalgie des mariés, d'autres sont fermés rapidement à leur demande. Ajouter chacun de ces sites éphémères à un réseau multisite aurait alourdi la base de données centrale sans aucun bénéfice réel, et aurait rendu plus délicate la suppression propre d'un site en fin de vie.

> L'essentiel à retenir : Chaque site de mariage a une durée de vie de quelques mois seulement ; Un multisite aurait ajouté de la complexité pour un usage éphémère ; Un script d'échafaudage crée un site fonctionnel en quelques minutes

## Le script de duplication retenu

La solution retenue s'appuie sur un modèle de référence maintenu à jour, dupliqué à chaque nouvelle commande via un script qui automatise l'ensemble des étapes répétitives : copie des fichiers du thème, création de la base de données, import du contenu type, et remplacement des informations spécifiques au nouveau couple.

```
#!/bin/bash
set -e
NOM_SITE=$1
DOMAINE=$2

wp core download --path=/var/www/$NOM_SITE
wp config create --path=/var/www/$NOM_SITE \
  --dbname=$NOM_SITE --dbuser=studio --dbpass=$DB_PASS
wp core install --path=/var/www/$NOM_SITE \
  --url=https://$DOMAINE --title="Le mariage" \
  --admin_user=studio --admin_password=$ADMIN_PASS --admin_email=contact@studio-exemple.fr
wp theme activate modele-mariage --path=/var/www/$NOM_SITE
wp import modele-contenu-type.xml --authors=create --path=/var/www/$NOM_SITE
```

Ce script, appelé avec le nom du futur couple et le nom de domaine réservé, livre un site fonctionnel en quelques minutes, prêt à recevoir les photos et le texte personnalisés par l'équipe créative.

## Ce que ce choix a résolu concrètement

- Un incident sur un site n'a plus aucune incidence sur les autres, chacun étant totalement indépendant en base de données et en fichiers.
- La suppression d'un site en fin de vie se limite à supprimer son dossier et sa base de données, sans étape de retrait d'un réseau partagé.
- Le modèle de référence s'améliore au fil des mariages sans risquer de casser un site déjà livré à un client, puisque la duplication fige une copie indépendante au moment de la commande.

## Ce que ce choix demande en discipline

La contrepartie de cette indépendance totale, c'est l'absence de mutualisation des mises à jour de sécurité. Chaque site dupliqué doit recevoir individuellement les correctifs du cœur et des extensions, ce qui demande une surveillance régulière du parc plutôt qu'une seule opération centralisée comme le permettrait un réseau multisite. Le studio a réglé ce point avec une tâche planifiée qui vérifie hebdomadairement l'état des sites encore actifs, via une boucle sur la liste des dossiers présents.

1. Lister les sites toujours actifs (ceux dont le mariage a eu lieu il y a moins de six mois).
2. Appliquer les mises à jour de sécurité disponibles sur chacun via une commande WP-CLI groupée.
3. Archiver puis désactiver les sites plus anciens qui ne reçoivent plus de visites significatives.

> La phrase qui résume l'esprit de cet outillage, formulée par la fondatrice du studio elle-même : chaque mariage mérite un site à lui, pas une chambre dans un immeuble collectif.

## En résumé

Pour un studio qui crée des sites au cycle de vie court et indépendant, un script de duplication rapide d'un modèle de référence s'est révélé plus adapté qu'un réseau multisite pensé pour une gestion centralisée dans la durée. Le gain en simplicité de suppression et en isolation des incidents compense largement l'effort de surveillance individuelle du parc, à condition de l'automatiser dès le départ plutôt que de la considérer comme une tâche secondaire.