Architecture multi-tenant et headless CMS : quelle stack employer ?

La création et la maintenance de plusieurs sites reposant sur une architecture multi-tenant (multi-locataire) soulèvent de nombreuses questions. Les choix technologiques vont être déterminants pour la sécurité, la maintenance, la scalabilité et les performances des sites.

Dans le cadre d’un appel d’offres auquel nous avons récemment répondu, nous avons pu explorer une approche efficace pour la mise en place d’un CMS prenant en charge la multi-location. Voici les choix technologiques que nous avons faits, et les problématiques auxquelles ils ont permis de répondre.

Qu’est-ce qu’un CMS multi-tenant ?

Un CMS multi-tenant est un système de gestion de contenu doté d’un référentiel unique, duquel dépendent plusieurs sites locataires. Dans notre cas, ils partagent la même architecture, la même expérience utilisateur (UX) et la même interface utilisateur (UI).

Néanmoins, les données de chaque site sont isolées de manière à ne pas interférer avec les autres locataires. Les accès au back office vont être propres à chaque site satellite, avec la possibilité d’échanger ou de partager du contenu entre eux.

Concernant les rôles et permissions des utilisateurs, une telle architecture conduit à des problématiques de cloisonnement des données. Chaque utilisateur doit être en capacité de créer ou de modifier du contenu sur un site spécifique, et ce en fonction du niveau de permission dont il dispose.

Le constat : WordPress, une réponse dépassée aux sites multi-locataires

Pour répondre à ce besoin, de nombreux prestataires web proposent aujourd’hui encore une intégration WordPress ou autre CMS appartenant à “l’ancien monde” 🦖 (Drupal, Joomla). Ces solutions supposément tout-en-un sont généralement adaptées dans la douleur pour répondre à un besoin précis.

Dans le cas d’une architecture multi-tenant, WordPress est plus dans une logique de duplication de sites que de centralisation. Ce qui amène à des sites très lourds, avec une maintenance laborieuse, mais également risquée faute à de nombreuses failles de sécurité causées par leur système de plugin.

CMS multi-tenant : notre choix technologique

Partant de ce constat, nous avons opté pour une approche favorisant une seule code base commune à tous les sites, gérant aussi bien le front que le back-office.

Voici la stack retenue (entièrement open source) pour en arriver là :

• Payload pour le CMS : Ce CMS headless est parfaitement adapté à la centralisation des contenus, la gestion des droits sur-mesure, avec une prise en charge native du multi-site (multi-tenant) et multi-domaine.
• PostGreSQL pour la base de données : le CMS est couplé avec une base de données de type PostGreSQL, pour le stockage des contenus, un standard de marché de haute qualité pouvant être hébergé par le plus grand nombre d’hébergeurs et plateformes.
• NextJS pour le front : Les sites sont développés avec NextJS, sur la base du Framework React. Pour optimiser les rendus, nous nous appuyons sur le standard TailwindCSS ainsi que la librairie de composants shadn/ui.

Sites multi-tenant avec Payload CMS : mise en pratique

L’architecture multi-tenant autorise une entière modularité par l’indépendance de chacune des parties.

Chaque site possède un identifiant utilisé pour cloisonner les données en base de données (une donnée peut être associée à N sites). Cela nous permet de cloisonner la création/édition de données dans le back office, mais également de générer tous les sites en se basant sur quelques variables d’environnement, dont l’identifiant du site.

Avec des services d’hébergement type Vercel, Amplify ou Netlify, nous obtenons une architecture permettant de déployer très facilement 50 sites conjointement, et ce avec une seule codebase. Dès qu’une modification est effectuée dans la code base, tous les sites sont déployés en simultané avec la mise à jour de la correction / l’évolution.

Le tout en gérant l’appartenance de chaque donnée, comme par exemple un article, une offre d’emploi ou un widget : chaque site est autonome pour aller chercher des données en fonction des valeurs d’environnement. La flexibilité de Payload offre en back office des interfaces sur mesure, simplifiant l’échange ou le partage des données entre site : pour ce faire, il suffit d’ajouter l’identifiant du site à laquelle appartient une donnée en base de données.

Cela garantit une évolutivité et une robustesse très fortes et simplifie la maintenabilité de tous les sites. En effet, d’autres composants peuvent être plus tard créés et déployés simultanément sur les sites souhaités.

Enfin, le headless CMS de Payload est construit avec Next, le front peut être couplé dans la même code base. Payload délivre des outils permettant de requêter la base de données, en fonction du schéma que l’on aura typé. Comme la partie CMS et site front se trouvent dans la même code base, on peut utiliser cet outil directement dans les serveurs actions ou dans les serveurs components et utiliser pleinement tous les avantages qu'offrent NextJS App Router et React 19.

Ainsi, tout est parfaitement séparé, les bundles Javascript envoyés au client sont très légers, ils favorisent la performance et le référencement des sites.

CMS multi-tenant : les avantages

Pour conclure, voici les avantages d’un CMS multi-locataire :

• Un référentiel unique 🎯Le CMS multi-tenant réduit les coûts liés à l’hébergement, la maintenance et la sécurité. Vous conservez en outre une image de marque et une expérience utilisateur similaire sur l’ensemble des sites. Vous pouvez garantir la cohérence sur tous les canaux, tout en répondant aux besoins individuels.
• Une maintenance facilitée 🛠️ L’ajout, la mise à jour ou la correction de fonctionnalités sont centralisés au lieu d’être effectués individuellement, site après site.
• Une meilleure évolutivité 🚀 Une architecture multi-tenant peut accueillir de nouveaux sites et utilisateurs sans que cela n’affecte les performances au niveau global.
• Une collaboration plus aisée 👩‍💻 Les équipes opérant au sein d’une même organisation peuvent plus facilement collaborer. Les contenus créés pour un site A peuvent ensuite être partagés à un site B, sans créer de doublons.