Passer de Joomla à une architecture découplée

L'architecture découplée consiste à séparer l'endroit où le contenu est saisi de l'endroit où il est affiché : d'un côté un système de gestion de contenu exposant une interface de programmation, de l'autre un site construit indépendamment qui consomme ces données. C'est une trajectoire sérieuse, régulièrement proposée en sortie de Joomla, et elle mérite d'être présentée avec ses contreparties plutôt qu'avec ses arguments de vente.

Découplé veut dire deux logiciels au lieu d'un

C'est la conséquence la plus structurante, et elle mérite d'être posée avant tout le reste. Avec Joomla, un seul produit gère la saisie, le rendu, les menus, les formulaires, la recherche et les URLs. En découplé, ces responsabilités se répartissent entre deux systèmes qu'il faut faire tenir ensemble, versionner ensemble et déployer ensemble. Vous ne migrez pas un site, vous fabriquez une application. Le coût de possession n'est pas celui d'une migration, c'est celui d'un développement à maintenir.

Ce que les rédacteurs perdent

• L'aperçu fidèle avant publication, qui doit être reconstruit explicitement et ne l'est pas toujours.
• La composition libre des pages : ce qui se faisait en glissant des modules dans des positions devient une fonctionnalité à développer.
• L'autonomie sur la navigation, les menus et les nouveaux gabarits, qui repassent souvent côté technique.
• La mise en ligne immédiate d'un changement de structure, quand un déploiement est nécessaire pour toute évolution d'affichage.
• La simplicité du dépannage : un affichage cassé peut désormais venir du contenu, de l'interface de programmation ou du site, et il faut savoir lequel.

Ces pertes ne sont pas rédhibitoires, elles sont budgétables. Ce qui pose problème, c'est de les découvrir après la mise en ligne, quand l'équipe éditoriale constate qu'elle ne peut plus faire seule ce qu'elle faisait la veille.

Quand le découplé se justifie

• Le même contenu alimente plusieurs canaux : site public, application mobile, bornes, partenaires, et il doit être saisi une seule fois.
• Le trafic ou les contraintes de performance dépassent ce qu'un rendu serveur classique tient confortablement.
• Une équipe technique existe déjà et maintient d'autres applications : le socle ne sera pas orphelin.
• Une refonte complète était de toute façon décidée et financée, indépendamment de la question Joomla.
• Le site comporte des fonctions interactives que le rendu de page classique sert mal.

Quand il devient un piège

Le cas le plus défavorable est celui d'une organisation dont le problème initial était de ne plus trouver personne pour maintenir Joomla. Le découplé multiplie alors la difficulté : il faut désormais des compétences sur le système de contenu, sur le site consommateur et sur la chaîne de déploiement. Le second cas défavorable est budgétaire : le découplé se finance comme une refonte, avec ses phases de conception et de développement, et le présenter comme une migration mène à un projet sous-financé qui s'arrête à mi-parcours. Le troisième est éditorial : une équipe habituée à publier seule et qui se retrouve dépendante d'un développeur pour chaque évolution finira par contourner l'outil.

Questions fréquentes