Il y a quelques années, la plupart des appels d'offres demandaient une usine à sites en Drupal. Si la demande est moins fréquente, cela reste une typologie d'appel d'offres que nous rencontrons fréquemment.

Nous allons détailler les possibilités offertes par notre CMS favori, mais avant ça, je vais vous mettre dans la confidence du secret le mieux gardé dans la communauté Drupal :

Il y a autant d'usines à sites différentes que de clients !

Maintenant qu'on a écarté ça, voyons les options qui s'offrent à nous. Je ne vais pas revenir sur le détail technique des différentes options qui sont déjà amplement couvertes dans ce toujours très valable article ([EN]) ou dans la présentation du même auteur ([EN]) sur le sujet. Nous allons essayer de vous présenter les options de façon très concrètes et de vous indiquer la solution que nous préconisons.

C'est quoi, pour vous, un "site" ?

D'abord, ce que vous appelez "site" peut très bien correspondre techniquement à une sous-partie d'un site. Parfois, vous voulez signifier un changement de charte graphique ou d'ergonomie, parfois une séparation des utilisateurs qui administrent les parties du site, parfois cela constitue vraiment un "site" différent (souvent lié à un nom de domaine différent, notamment).

Selon la définition que vous avez d'un site, une usine à sites peut ne pas vous correspondre, ou alors s'implémentera de manière très différente. Il nous faut donc vous aider à expliciter vos besoins avec des questions très précises.

Quel est votre besoin ?

Pour s'assurer de l'adéquation de la solution technique avec les besoins du client, il est nécessaire de le comprendre, et pour cela, vous devez poser ces quelques questions face à chaque projet d'usines à site Drupal :

• De combien de sites avez-vous besoin ?
• Y a-t-il partage de contenus entre les sites ?
• Avez-vous besoin d'une administration centralisée ?
• Y a-t-il partage d'utilisateurs entre les sites, et devez-vous être automatiquement connectés sur l'ensemble des sites ?

De combien de sites avez-vous besoin ?

Familièrement appelée la règle "2 n'est pas une usine".

Si vous n'avez pas besoin d'un nombre conséquent de sites, inutile de considérer une usine, vous pouvez simplement dupliquer votre site principal et supprimer tout le contenu.

Parfois, le nombre de sites est trop restreint pour justifier une usine à site. Ou alors les différences entre les sites sont telles qu'il n'y a pas moyen de mutualiser les fonctionnalités sur une même base de code. Il vaut mieux dans ce cas simplement coder certaines fonctions sous forme de modules réutilisables, qui seront installés sur plusieurs sites différents, sans usine donc. Parfois c'est uniquement le thème graphique qu'il faut partager.

Si vous souhaitez tout de même utiliser une "usine à sites", les autres questions peuvent vous permettre de mieux déterminer l'option technique à retenir.

Partage de contenu

Votre usine à sites peut générer ou héberger des sites complètement différents, mais il est possible que vous souhaitiez des sites partageant tout ou partie de leur contenu. C'est le cas par exemple de sites nationaux qui ont des déclinaisons régionales, ou de sites en marque blanche où seule l'intégration graphique change, mais le contenu est identique.

Dans ce cas, la solution historique et standard de la communauté Drupal s'appelle Domain Access, permettant de gérer dans une seule interface plusieurs sites différents, avec un contenu pratiquement identique (mais permettant une personnalisation de chaque site).

Dans le cas où on ne vise qu’un partage de contenu partiel, Domain Access risquant alors de représenter une surcouche pouvant poser des problèmes, il est possible d’utiliser Entity Share, un module utilisé notamment par plusieurs sociétés françaises. Il devient alors possible de "s’abonner" à certains contenus issus d’un site jouant le rôle de serveur central, et de récupérer alors automatiquement ce contenu sur des sites jouant le rôle de clients locaux.

Avez-vous besoin d'une administration centralisée ?

Ici, l'administration dépend de la solution technique retenue. Par exemple, avec Domain Access, il est possible de créer du contenu pour n'importe quel site depuis le site principal.

Partage d'utilisateurs

Ici, il n'est pas nécessaire d'utiliser une usine à sites. De nombreuses solutions sont possibles : Domain Access, dont nous avons parlé ci-dessus. Mais aussi tout simplement une intégration à un système de SSO : Bakery, qui fonctionne nativement avec des sites Drupal qui sont des sous-sites du même nom de domaine ; CAS, trés utilisé dans les universités françaises.

Vous pouvez aussi simplement vous connecter à un annuaire LDAP (avec le module du même nom) ou même combiner ces solutions (authentification via CAS et droits d'accès gérés depuis un LDAP, par exemple, que nous avons mis en place récemment).

Partage de "structure"

Ce besoin est à étudier au cas par cas. Mais bien souvent, il est possible de coder les types de contenu ou autre dans des modules réutilisables partagés par différents sites.

Le cœur et rien que le cœur

Le cœur de Drupal fournit nativement une solution "multi-site". Le code étant alors entièrement partagé, la montée de version du cœur doit se faire sur l'ensemble des sites en même temps.

Cela signifie que tous les sites de l’usine seront mis en maintenance au même moment et pour la même durée.

Si le développement de l'usine à sites est simplifiée (on réalise en fait un seul développement), la phase de maintenance peut être rendue plus complexe car on doit alors synchroniser les traitements sur l'ensemble des sites.

Si cela semble une opération aisée d’un point de vue administration système, c’est souvent au niveau organisationnel que cela peut poser problème, dans la mesure où l’ensemble des équipes doivent se synchroniser pour appliquer leurs mises à jour, ce qui est rarement possible dans les grandes organisations. C'est ce qui nous conduit la plupart du temps à écarter cette solution.

C'est cependant une fonctionnalité régulièrement utilisée.

Si il a d'ailleurs un instant été question de faire disparaître cette fonctionnalité en Drupal 9, il semble que de trop nombreuses personnes l'utilisent aujourd'hui, même si elle n'est pas forcément compatible avec les workflows de déploiement modernes, notamment l'utilisation de Composer. Il est donc désormais question d'améliorer cette fonctionnalité. À suivre donc !

En résumé, pour le moment, d'après nous : n'utilisez pas le multisite Drupal si vous n'êtes pas sûr de vous !

Les autres solutions de la communauté Drupal

Les distributions

Pour chaque client, aujourd'hui, nous créons une « distribution » (un Drupal packagé avec des modules de la communauté et une pré-configuration). Le client est alors libre d’installer autant de sites qu’il le veut à partir de cette distribution (même si le plus souvent il n'en installe qu'un seul).

C'est la solution que nous utilisons principalement sur nos projets. Dans l'optique d'utiliser une base de site de façon répétée pour créer des sites totalement indépendants, c'est la solution que nous recommandons. Vous conservez alors la mutualisation des développements permettant de réduire le coût de développement du projet, mais vos sites sont ensuite libres d'évoluer complètement indépendamment.

Utilisez plutôt une distribution que vous installez pour chaque nouveau site !

Ægir

Ægir est l'approche "système" de l'usine à sites Drupal : l'objectif est ici de contrôler complètement votre plateforme afin de pouvoir à tout moment générer un nouveau site en remplissant un seul formulaire.

Cette approche est notamment utilisée par des universités, ou des freelances voulant déployer rapidement des sites pour leurs clients, et peut d'ailleurs être combinée avec les distributions, en permettant pour chaque nouveau site de choisir la distribution à déployer.

Une solution toute récente, Micro Site

Depuis peu existe également Micro site, que nous n'avons pas encore testé. Composée d'une suite de module comme Domain Access, ce module semble répondre aux mêmes besoins.

C'est d'ailleurs la solution qui semble fonctionnellement la plus proche de la solution que nous avons développé pour certains clients :

µCMS, une usine à sites Drupal pré-paramétrée

Les modules que nous avons évoqués précédemment sont tous des solutions standards dans la communauté Drupal. Comme la plupart des modules Drupal, il est nécessaire de les paramétrer pour arriver à un résultat adapté à vos besoins.

Les usines à sites étant souvent des projets d'envergure, le moindre temps gagné durant la phase de développement est utile, et nous pensions nécessaire de disposer d'une solution pré-paramétrée répondant à des besoins que nous retrouvions régulièrement chez nos clients.

Nous avons alors développé sur une base Drupal 7, en y associant le framework Symfony, pour ajouter une couche métier spécifique à ce secteur fonctionnel, un produit destiné aux développeurs d'usines à sites : µCMS.

Les principales fonctionnalités de ce produit sont :

• un workflow de création de sites permettant aux utilisateurs de créer à la volée de nouveaux sites puis les mettre en ligne, et ceci en minimisant l'intervention des administrateurs

• un backoffice dédié de gestion de contenus, ajoutant quelques fonctionnalités par rapport au backoffice standard Drupal comme les recherches de contenu par facette
• des droits fins site par site, pour coller aux équipes éditoriales du client
• un mécanisme de partage et surcharge de contenus entre sites

Il est naturellement impossible de prévoir à l'avance les types de contenus dont vous aurez besoin, mais il est possible de les définir comme dans tout site Drupal. Nous avons même ajouté une fonctionnalité de définition des types de contenu à partir de fichier de configuration au format YAML, qu'il est possible de modifier et resynchroniser en cas d'évolution de ces types de contenu (ajout de champs par exemple).

Une gestion multisite avec partage de contenu

L'une des plus grandes problématiques des usines à site est de permettre le partage de contenus entre site. Nous utilisons le mécanisme de droit Node Access de Drupal pour cloisonner les contenus et faire en sorte qu'ils ne soient visibles que sur un ou plusieurs sites mais pas tous. Le contenu peut être créé localement (uniquement visible pour le site courant) ou globalement, auquel cas il pourra ensuite être utilisé sur d'autres sites. Un contenu donné pourra même être modifié uniquement pour le site courant (sans modifier le contenu dans sa version d'origine qui reste visible des autres sites), c'est une surcharge ou spécialisation de ce contenu.

Un des cas d'usage consiste à permettre au client de créer un nouveau site en prenant un site existant comme modèle. Les contenus de ce site source seront alors automatiquement visible du nouveau site (partage des droits)

Une gestion des médias facile d'utilisation

La gestion des médias a traditionnellement été un point faible de Drupal. Notre usine à site vient en standard avec des types de contenu pour les médias traditionnels. Il est possible de les ajouter à un panier latéral, pour ensuite les déposer sur les champs de type média associés aux types de contenu. 

Une gestion SEO automatique

Les contenus bénéficient d'URL propres en standard, et basé sur l'arborescence du menu de navigation.

Si ce mécanisme, appelé "slug", est certes plus contraignant qu'un Drupal standard, c'est de toute façon la configuration que nous appliquons sur l'ensemble de nos sites Drupal, et c'est ce qui est repris par la plupart des CMS récents : Wagtail, Kirby, Grav. Dans la mesure où c'est la configuration qui a le plus de sens, nous l'appliquons immédiatement pour que vous n'ayez plus à y penser.

Il est cependant bien sûr possible d'avoir pour la même page des URLs différentes selon le site, par exemple.

Il est également possible d'ajouter des redirections (au sens HTTP 301) associées à un contenu, ce qui est très utile en cas de migration à partir d'un site existant afin de ne pas casser les URLs précédemment indexées ou dans les signets des utilisateurs. Pour cela il suffit d'aller dans les propriétés SEO d'un contenu et ajouter une ou plusieurs nouvelle(s) URL(s). L'avantage de gérer cela dans Drupal est de ne pas dégrader les performances du routage amont (serveur web) par des règles potentiellement complexes dans le cas de grosses volumétries de contenu.

Une interface d'administration simple

Les usines à sites sont souvent destinées à des clients qui en ont un usage intensif et qui passent une bonne partie de leur temps à créer des pages. L'interface de contribution doit donc être intuitive. Nous avons donc porté une attention spécifique à cette partie avec un backoffice propre à cette usine, et qui se substitue au backoffice généraliste d'origine de Drupal. Il est ainsi facile de distinguer les contenus globaux des contenus locaux, et de filtrer les contenus par type.

Une usine globalement extensible

Le fait de charger un coeur Symfony nous permet d'externaliser des développements complexes ou métier en dehors de Drupal, pour retrouver la simplicité et la testabilité liée à ce framework. Il est aussi possible d'étendre la gestion des sites au cas par cas. Par exemple, chez un de nos clients, les sites gérés par l'usine étaient parfois des sites marque blanche, avec une grande partie de contenu partagé (mais donc personnalisable tout de même, comme dit plus haut) avec un jeu de couleur paramétrable, site par site.

Ce n'est finalement que Drupal

Cette usine à site est construite sur ce que le cœur de Drupal propose, à chaque client son usine, à chaque déploiement l'intégration des modules qui conviennent. Vous souhaitez utiliser une autre solution de média ? Il suffit d'installer le module qui correspond. Vous avez besoin de formulaires ? Webform s'intégrera naturellement dans les sites et les formulaires pourront être partagés !

Malgré une interface d'administration revue et simplifiée, la communauté de Drupal reste à l'honneur, et les possibilités offertes par le grand choix de modules reste d'actualité.

Tout dépend de vos besoins !

Si votre besoin est relativement courant : une génération de sites similaires partageant éventuellement du contenu, alors, testez µCMS ou Domain Access, et économisez du temps dans la mise en place de votre projet.

Si vos sites sont par contre pour la plupart assez différents, nous recommandons l'utilisation de modules communs (pour économiser du temps de développement) paramétrés par des profils d'installation différents, dans une approche "distribution".

Nous disposons d'ailleurs pour ces projets d'une distribution interne "Simply Drupal", accélérant grandement le démarrage de nos projets Drupal 8 aujourd'hui.

Si vous pensez que votre besoin n'est pas couvert, sachez qu'il est probablement possible de tout de même réaliser votre usine à sites avec Drupal, et vous pouvez également nous contacter pour ça !