Industrialisez votre écosystème web avec une usine à sites Drupal 11. Découvrez les meilleures architectures et conseils d'experts Smile pour votre projet.
Une "usine à sites" (ou "site factory") Drupal vise à industrialiser la création, la maintenance et le déploiement de multiples sites web sur une base technique commune. Les objectifs sont la gouvernance (cohérence), la rapidité de déploiement et l'efficacité de la maintenance (sécurité).
Avec Drupal 11, qui repose entièrement sur Composer, les versions les plus modernes de PHP et une gestion de la configuration avancée, les "anciennes" méthodes ont été affinées.
Voici les différentes solutions et approches pour construire une usine à sites avec Drupal 11.
L'architecture multisite native : l'approche historique pour les flottes homogènes
C'est l'approche historique de Drupal, toujours présente dans le Core.
Concept : une seule base de code Drupal (un seul composer.json, un seul dossier core, modules, themes) sert un nombre illimité de sites.
Fonctionnement technique :
- Le dossier sites/ contient un sous-dossier par site (ex: sites/site1.com, sites/site2.fr).
- Le fichier sites/sites.php fait le lien (mapping) entre un nom de domaine (URL) et le dossier du site correspondant.
- Chaque site a sa propre base de données et son propre dossier files.
- Tous les sites partagent exactement le même code (versions de modules identiques). Il est toutefois possible de surcharger chaque site avec des éléments de code spécifiques à une instance précise.
Avantages :
- Centralisation maximale : une seule mise à jour de sécurité (un composer update) actualise tous les sites d'un coup.
- Très rapide pour "cloner" un nouveau site basique.
Inconvénients (importants) :
- Monolithe fragile : une mise à jour ratée (ex. : un bug dans un module) casse tous les sites simultanément.
- Manque de flexibilité : impossible d'avoir des versions de modules différentes. Si "Site A" a besoin du module X v1.0 et "Site B" du module X v2.0, c'est impossible.
- La gestion de la configuration (voir point 4) devient complexe pour gérer les variations entre sites.
L'approche "distribution" (profil d'installation)
C'est l'approche "moderne" la plus robuste, alignée avec la philosophie Composer.
Concept : vous ne gérez pas une base de code unique, mais un "modèle" de site. Chaque site est un projet indépendant, mais tous sont issus de ce modèle.
Fonctionnement technique :
- Vous créez un profil d'installation (une "distribution") Drupal.
- Ce profil contient le thème, les modules par défaut et, surtout, la configuration par défaut (exportée dans config/sync).
- Créer un nouveau site se fait via une commande : composer create-project mon-entreprise/usine-a-sites nouveau-site.
- Chaque site est alors un projet Drupal 11 complet et indépendant (son propre composer.json, son propre dépôt Git, etc.).
- Ce fonctionnement est encore enrichi avec le système de Recipes qui permet de déployer toute la puissance d’un profil d’installation même sur des sites déjà en cours d’exploitation.
Avantages :
- Isolation parfaite : chaque site est autonome. Un site qui plante n'affecte aucun autre.
- Flexibilité : un site peut décider de ne pas faire une mise à jour, ou d'ajouter un module spécifique qui n'est pas dans le tronc commun, sans affecter l'usine.
- Maintenance : les mises à jour du "tronc commun" sont poussées dans le profil. Les sites n'ont qu'à faire un composer update mon-entreprise/usine-a-sites pour récupérer les nouveautés.
Inconvénients :
- Maintenance décentralisée : actualiser 100 sites signifie exécuter la mise à jour 100 fois (mais facilement scriptable via une CI/CD).
Approche "Monorepo" (gestion par “composer”)
C'est un hybride puissant, souvent utilisé par les agences et les plateformes PaaS.
Concept : un seul dépôt Git (Monorepo) contient le code commun, mais utilise des mécanismes Composer avancés pour gérer les variations.
Fonctionnement technique :
- Il existe un composer.json à la racine qui définit le Core de Drupal 11.
- Chaque site (ou "famille" de sites) peut avoir son propre composer.json additionnel, ou le dépôt utilise des scripts pour construire des "artefacts" de déploiement différents.
Avantages :
- Équilibre entre centralisation du code (un seul Git) et flexibilité de déploiement.
- Parfaitement adapté aux pipelines de CI/CD (GitLab CI, GitHub Actions).
Inconvénients :
- Complexité technique : demande une excellente maîtrise de Composer et des outils de déploiement.
Module indispensable : "Config Split"
Quelle que soit l'approche choisie (surtout 1 et 3), un module est vital : Config Split.
Dans une usine à sites, 90% de la configuration est identique (types de contenu, champs). Mais, il y a des variations :
- Le "Site A" (e-commerce) a le module commerce activé.
- Le "Site B" (blog) ne l'a pas.
- Le "Site C" (intranet) a un module ldap activé.
Config Split permet de définir des ensembles de configuration "conditionnels". Il "splite" (sépare) la configuration originelle des configurations optionnelles.
Vous avez une base config/sync, puis :
- config/split/ecommerce (contient la config du module Commerce)
- config/split/intranet (contient la config LDAP)
En fonction du site, vous activez le "split" correspondant. C'est l'outil N°1 de la gouvernance dans une usine à sites.
Plateformes PaaS "clés en main"
Enfin, il y a la solution d'externaliser la complexité de l'infrastructure.
Concept : vous utilisez un service spécialisé qui a déjà construit toute l'infrastructure (serveurs, Git, déploiement) optimisée pour le multisite Drupal.
Exemple : Acquia Site Factory : la solution historique et la plus intégrée. C'est une interface "low-code" pour cloner des sites établis sur des "profils" que vous définissez. Elle gère les mises à jour en masse.
Avantages :
- Abstrait la complexité : vous vous concentrez sur Drupal, pas sur les serveurs ou les pipelines.
- Rapidité de déploiement et haute disponibilité garanties.
- Puissantes fonctionnalités de réplication de sites, codes, bases de données
Inconvénients :
- Coût : ces services PaaS sont logiquement plus chers qu'un hébergement classique.
- Verrouillage fournisseur (vendor lock-in) : vous êtes lié à la technologie de la plateforme même si celle-ci reste établie sur un standard du marché.
Synthèse des approches
Approche | Centralisation | Isolation des sites | Complexité de MAJ | Idéal pour... |
1. Multisite Natif | Maximale (code unique) | Faible (MAJ groupée) | Simple (1 MAJ) | Petites flottes, sites très similaires. |
2. Distribution | Faible (modèle) | Total (projets séparés) | Complexe (N MAJ) | Grandes flottes, besoin de flexibilité. |
3. Monorepo (Composer) | Élevée (Git unique) | Élevée (builds séparés) | Moyenne (CI/CD) | Équipes techniques matures (agences). |
4. PaaS (Acquia) | Maximale (Interface) | Totale (gérée) | Simple (interface) | Entreprises voulant externaliser l'infra. |
Recommandation pour Drupal 11 : Pour une usine à sites souveraine et robuste, l'approche nᵒ 2 (Distribution / Profil d'installation), combinée au module Config Split et automatisée par une CI/CD, est la "best practice" moderne.
Conclusion
Rationaliser et industrialiser sa plateforme web devient un impondérable du marketing digital. Vous devenez plus autonome et pouvez générer vos propres sites (lancement de produits, événementiel, nouvelle campagne…) dans une logique de time to market. Les équipes Smile Drupal analysent avec vous vos besoins stratégiques pour mettre en place la meilleure architecture d’usine à sites pour optimiser vos coûts et dynamiser votre communication et vos opérations marketing.
