Les 2 différences entre multisite et usine à sites

Ces dernières années, nous assistons à une multiplication de nouvelles technologies, solutions, tendances et concepts innovants. De quoi s’y perdre et confondre deux concepts importants dans le périmètre du digital : le multisite et l'usine à sites (aussi appelé webfactory).

Nous vous expliquons ici les différences entre ces 2 concepts.

Qu’est ce qu’un multisite ?

Un multisite est une fonction standard proposée par un système de gestion de contenus qui vous permet de générer plusieurs sites sur la base d’un même socle technologique et d’une seule instance.

Un multisite permet ainsi les fonctions suivantes, dépendant de la solution CMS/CMF :

• Un socle technologique complètement partagé entre les sites (Codebase du CMS),
• Le partage de modules et fonctionnalités entre plusieurs sites, selon les capacités du CMS/CMF, 
• Des thèmes graphiques pouvant être différents selon le sites,
• Des contenus pouvant être partagés entre sites, selon la capacité de gestion des permissions de la solution,
• Le partage de l'intégration avec tous vos systèmes tiers que vous avez souhaité connecter à votre socle (PIM, DAM, Marketing Automation/CRM, etc.).

Nous pourrions résumer un multisite avec le schéma suivant qui représente un seul socle technique capable de créer plusieurs sites ayant potentiellement des fonctionnalités différentes :

Légende :
Sites internet : A,B,C
Fonctionnalités partagées : F1, F2, etc.
CMF : Drupal (recommandé), Wordpress, Jahia, etc.
Applications tierces : DAM, PIM, CRM, APP, LDAP
Middleware : Solr, Mysql, etc.
Cloud : Azur, AWS, OVH, etc.

Vous n’avez alors plus besoin d’autre chose : votre usine à sites peut se résumer à un simple multisite. Les 2 concepts ne sont donc pas antinomiques, une usine à sites peut tout simplement contenir un multisite en y ajoutant des capacités complémentaires.

Actency propose une solution d’usine à sites basée sur la solution Drupal, découvrez-la : Drupal Factory

Les 2 différences qui impliquent de parler d'une usine à sites plutôt que de multisite

Plusieurs instances

• Tout d’abord, on parle d’usine à sites quand on ne peut pas se contenter d’un seul système technique (un seul codebase) et qu’il est nécessaire de créer plusieurs “instances”
   

  C’est par exemple le cas pour une entreprise internationale qui voudrait déployer des sites extranet partout dans le monde : il ne sera probablement plus possible d’utiliser la même instance de code source pour générer tous les sites.

  Pourquoi plusieurs instances ?

  Pour un extranet par exemple, il ne sera pas possible de se reposer sur le CDN pour gérer la vitesse de chargement des pages. Si l’extranet est hébergé dans un datacenter en Europe pour des équipes basées en Australie, le temps de réponse sera extrêmement long, rendant votre application inexploitable ou entraînant un manque d’adhésion. Dans tous les cas, il faudra à un moment changer pour utiliser un datacenter proche de l’Australie. Il sera alors nécessaire de créer une nouvelle “instance” pour ce code source. Il existe de nombreux autres cas où cela s’explique, notamment pour la sécurité ou la politique locale.

  Voici un schéma qui représente ce que vous allez devoir mettre en œuvre dans le cas d’une multitude d'instances, justifiant ainsi l'appellation “usine à sites” : la création de plusieurs instances, dont chacune contient potentiellement des fonctionnalités différentes (tout comme un multisite).

  Ce schéma part du principe que nous utilisons un même cloud + middleware, c’est un choix arbitraire de représentation. Dans la réalité, des clouds différents par instance pourront être utilisés. Un cloud propose différents datacenters, et l’exploitation de différents datacenters du même cloud justifie déjà la création de plusieurs instances.

  Ainsi, dans le cas d’instances multiples, vous devez ajouter des méthodes et des processus pour déployer et maintenir automatiquement toutes vos instances afin de ne conserver qu’un seul et même socle technologique. C’est à partir de cette étape que vous pouvez parler d’usine à sites.

  Dans ce cas de figure, il est fréquent de retrouver une architecture sous la forme de plusieurs multisites (une par instance) au sein de votre usine à sites.

  

Des processus d’industrialisation

• Ensuite, on parle d’usine à sites lorsqu’il est nécessaire de mettre en œuvre des processus d’industrialisation de la production digitale : intégration, tests de déploiement automatisés.
   

  Les concepts de CI/CD et de CIT ont le vent en poupe car les écosystèmes digitaux stratégiques sont devenus si complexes qu’une simple gestion humaine ne permet plus d’assurer la qualité et la pérennité des applications ou des sites internet stratégiques.

  Pourquoi il n'est pas possible d'utiliser la même instance de code pour générer tous les sites ?

  Il n’est humainement plus possible de demander à une équipe de testeurs ou de développeurs de tester une application à chaque modification ou évolution. Un développeur ne peut pas prévoir l’intégralité des impacts que les modifications pourraient avoir sur l’ensemble de l’écosystème. De la même manière, un déploiement en production peut s’avérer être une démarche extrêmement complexe, entraînant des centaines d’opérations manuelles critiques.

  Pour quel résultat ?

  Des régressions incontrôlées en production, une baisse de la satisfaction des utilisateurs et des contrats de maintenance qui ne font que de traiter des anomalies et des urgences. Quand le turn-over naturel a fait son œuvre sur l’équipe technique, vous perdez le contrôle avec l’illusion qu’une documentation technique suffira à la garder. Dans la réalité, les applications sont devenues trop complexes à gérer, il faut donc changer de méthode et miser sur des CI/CD.

  La mise en œuvre de ces processus automatisant une partie de la chaîne de production afin de ne plus compter sur l’Humain dans certains cas revient donc à industrialiser votre processus de développement, de test et de déploiement. Votre processus de production est alors pensé… comme une usine.

Dès lors, un multisite ne s’applique que dans des projets très simples, et encore...

Quand on parle de multisite, on parle de projets très simples, ne nécessitant qu’une seule instance et aucun processus d'industrialisation de la production digitale, ce qui est de plus en plus rare actuellement.

Cela implique que le projet multisite est de nature :

• “temporaire” : par exemple un site événementiel avec une couverture internationale nécessitant un multisite par essence temporaire.
• extrêmement simple sur le plan fonctionnel : par exemple des sites éditoriaux très basiques regroupant page d’accueil + pages de contenu statique uniquement et quelques fonctions standards proposées par un socle commun (formulaire, recherche, etc.)

Par définition, il ne nécessite donc que très peu de maintenance (une simple préventive suffirait).

En général ces projets se composent quasiment exclusivement de modules standards et n'impliquent pas d’intégration avec des systèmes tiers.

Il faut donc savoir provoquer la bascule d’un modèle multisite en usine à sites

Un projet peut donc commencer simplement par une version multisite basique, sans enjeux techniques forts et évoluer au point où le changement vers un modèle “usine à sites” devient stratégique.

Nous isolons 2 cas typiques :

• Votre projet évolue dans sa complexité : l’ajout d’un espace Extranet ou de multiples intégrations avec des systèmes tiers par exemple.
• Le contexte dans lequel se trouve le site vous oblige à le mettre en œuvre une infrastructure multi-instance : par exemple vous devez déployer en Chine (vous obligeant à utiliser plusieurs clouds différents), ou bien une contrainte de sécurité de votre IT qui souhaite plusieurs instances pour compartimenter les risques de faille de sécurité, etc.

Dans ces cas, il vous faut alors lancer un projet de mise à niveau vers un modèle usine à sites en ajoutant des processus d’industrialisation CI/CD/CIT ou modifier votre architecture pour être compatible avec une infrastructure composée de plusieurs instances.

Pour conclure, il est préférable d’envisager un projet d’usine à sites plutôt qu’un projet multisite.

Le modèle multisite simple n’est pas recommandé pour des applications stratégiques et la tendance actuelle est plutôt de privilégier l’approche usine à sites, quel que soit le projet qui aurait une intention simplement multisite. Dans vos architectures, prévoyez toujours au minimum de pouvoir basculer dans un modèle usine à sites.

Aujourd'hui l’ultra spécialisation des solutions techniques, le respect de normes et d’usages de plus en plus complexes, le tout associé une quantité grandissante d'applications tierces à intégrer font qu’un projet multisite est rarement simple et de facto une orientation usine à sites est à privilégier.

Une architecture compatible et un minimum de processus de tests automatisés à appliquer au commencement du projet sécuriseront les équipes techniques et le projet sur le long terme.