Une approche unique pour chaque enseigne

‍

L’ambition du projet était donc de décliner sous la forme d’une solution centrée sur le CMS Wordpress toute une série de sites web implémentant des fonctionnalités variées (content, store locator, présentation d’offres, réservation en ligne,...) dans une architecture headless évolutive et pérenne.

Le choix Wordpress s’est imposé en grande partie du fait de la disponibilité en Open Source de la solution mais aussi de la familiarité du client avec ce CMS. L’enjeu du projet résidait dans la capacité de construire, sur ce socle, un ensemble de sites par marque disposant de fonctionnalités identiques mais avec une approche UX/UI propre à chaque marque.

Il a donc fallu construire une architecture qui permette - vraiment - de découpler le comportement fonctionnel, porté par un template unique pour l’ensemble des marques, et le rendu utilisateur porté par une UI spécifique propre à l’identité de chaque enseigne.

D’habitude le template d’une solution Wordpress intègre le fonctionnel et l’UX/UI sachant que les modifications de l’Ui sont généralement faibles : modification de couleurs, quelques choix de blocs,...

Dans notre contexte, les modifications d’UI sont bien plus importantes au niveau des menus, des sliders, …

Les menus sont une source de divergence non négligeable entre les différentes marques. Les modes de présentations et d’interactions sont multiples et propres à chacune d’entre elles.

Comme on peut le voir sur les illustrations suivantes (1 et 2), une marque peut vouloir un bloc qui s’ouvre au clic sur l’entrée du header correspondante, présenter un visuel  et ouvrir les sous-menus sur un clic de l’utilisateur. Tandis qu’une seconde peut vouloir interagir au survol, sans illustration et présenté en mode “bulle”. De la même manière, la position du logo au sein du menu header est également propre à chaque marque.

‍

‍

‍

Les sliders

‍

‍

Sur ce second bloc (illustration 3 et 4) qui est un slider catégorisé, le mode de présentation des catégories, la gestion de la pagination, de la navigation et des propriétés du slider (nombre de slide visible, slide suivante prévisualisée ou non, slider automatiquement ou pas, etc..) sont également propres à chaque marque.

L’ARCHITECTURE HEADLESS

L’architecture se structure autour des composants suivants:

• Un back office Wordpress
• Un backend / frontend NextJS

Wordpress permet d’être interfacé en mode headless au moyen de ses API (Rest et GraphQL). La plupart des contributions CMS peuvent nativement être récupérées par ces APIs. Il nous a fallu néanmoins développer un plugin WP afin d’ajouter certaines informations, notamment concernant les traductions mises en place avec WPML.

‍

L'architecture headless a permis une grande flexibilité pour intégrer des sources externes. Contrairement à une approche traditionnelle WordPress qui aurait nécessité le développement de plugins pour chaque fonctionnalité spécifique (store locator, flux Instagram, sliders Flowbox, etc.), l'usage de Next.js en front-end a permis une interfaçabilité native avec divers services et API tierces.

Cette approche nous a permis de déléguer les fonctionnalités dynamiques et personnalisées à des composants front-end modernes, réactifs et optimisés pour les performances. Chaque service ou API externe est ainsi consommé de manière isolée, sans impacter directement le cœur du CMS. Cette modularité permet une meilleure évolutivité de l’ensemble de l’application.

1. Pourquoi cette approche plutôt que des plugins WordPress ?

Développer ces fonctionnalités sous forme de plugins WordPress aurait pu entraîner plusieurs défis. Premièrement, cela aurait alourdi le back-office, rendant le site potentiellement plus lent et moins sécurisé, car chaque plugin WP augmentant le nombre de dépendances et de points de vulnérabilité. En parallèle, certains services externes, comme l'API Instagram, nécessitent des mises à jour fréquentes pour maintenir leur compatibilité ; une intégration directe dans le front-end via Next.js permet donc d'assurer une gestion des dépendances plus fine et une réduction des risques liés aux versions obsolètes.

2. Performance et SEO

‍
Next.js apporte également des avantages considérables en termes de performance et de SEO. Les données dynamiques issues des APIs externes peuvent être mises en cache côté serveur (ISR - Incremental Static Regeneration) ou côté client, en fonction des besoins, permettant un rendu rapide des pages sans re chargement excessif. Les chargements asynchrones des contenus améliorent également l'expérience utilisateur, particulièrement utile pour des éléments visuels comme les flux Instagram et les sliders.

En somme, l’architecture headless nous a permis d’allier l’efficacité d’un CMS éprouvé comme WordPress avec la puissance et la modularité d’un front-end moderne.

CONTRIBUTION : UNE FLEXIBILITÉ TOTALE POUR LES ADMINISTRATEURS

Dans notre architecture headless, le rôle de WordPress est de permettre aux contributeurs de créer et de structurer le contenu grâce à des pages, des articles, et des custom post types (produits, offres, services).

Templates et blocs ACF comme éléments modulaires

Pour chaque page, un "template" est défini. Ce template regroupe un ensemble de blocs ACF (Advanced Custom Fields) disponibles pour construire la page. Ces blocs constituent les building blocks de notre application, offrant ainsi une grande modularité.

• Blocs visuels : intégralement contribuables, ils permettent de structurer des éléments visuels variés comme :some text
  • Une mise en avant d'articles (avec des champs pour le titre, sous-titre, texte, CTA, lien attaché au CTA, post associé, mode de présentation, etc.).
  • Des sliders, des titres/sous-titres avec des arrière-plans personnalisés, ou encore des bandeaux défilants.
• Blocs de sources externes : ils servent à intégrer des données provenant d’API ou d’autres services. Les contributeurs renseignent uniquement les paramètres nécessaires, par exemple la "flowkey" pour intégrer un flux d'images Flowbox.

Cette approche offre une flexibilité inégalée aux contributeurs. Ils peuvent :

• Ajouter, supprimer ou réorganiser les blocs selon leurs besoins.
• Créer des pages sur mesure, en intégrant uniquement les blocs pertinents pour leur contenu.
• Utiliser des blocs basés sur des données externes, sans qu'elles soient stockées dans WordPress (comme les flux Instagram, Flowbox, ou des données d’API spécifiques).

En résumé, les contributeurs ont une totale liberté pour créer des pages riches, personnalisées et dynamiques, tout en bénéficiant d’un système structuré et intuitif.

NEXT.JS : LA VISION UTILISATEUR

Côté Next.js, chaque requête de page est interprétée selon un processus simple et efficace :

1. Récupération des données : lors de la requête, le "template" de la page et son tableau de blocs ACF sont extraits via l'API de WordPress.
2. Mapping des blocs : chaque type de bloc ACF est mappé à un composant Server React/Next.js spécifique.
3. Rendu dynamique : un composant serveur central parcourt le tableau de blocs ACF et instancie dynamiquement les composants correspondants.

1. Gestion des blocs visuels et externes

• Pour les blocs visuels, les données contribuées sont directement utilisées pour générer le contenu, avec un rendu optimisé pour les performances et le SEO.
• Pour les blocs externes, comme Flowbox, les paramètres renseignés par le contributeur (ex. la "flowkey") sont utilisés pour effectuer des appels API. Cela permet de récupérer et d’afficher des données à jour tout en préservant la sécurité (les données sensibles restent côté serveur).

2. Avantages clés de cette approche

• Simplicité et modularité : le tableau de blocs ACF agit comme une feuille de route pour construire la page sans logique complexe.
• Performances optimisées : grâce aux composants server, les données peuvent être mises en cach, minimisant les appels externes et réduisant le temps de chargement.
• Sécurité renforcée : les appels API sont effectués côté serveur, éliminant tout risque d’exposition de clés ou d’informations sensibles au client.

Cette architecture garantit une intégration fluide entre WordPress et Next.js tout en offrant une grande flexibilité pour les contributeurs et une puissance inégalée en front-end.

SYNCHRONISATION ENTRE LES BRIQUES DE LA SOLUTION

‍

Pour garantir une performance optimale, une mise à jour fluide et une résilience face aux imprévus, l'architecture headless mise en place repose sur trois niveaux de caches.

‍

1. Cache des requêtes Next.js

Chaque requête effectuée par Next.js (vers WordPress, des APIs externes ou la base de données MongoDB) est mise en cache pour une durée spécifique définie en collaboration avec le client, via un TTL (Time-To-Live).

Fonctionnement :

• Indépendance des TTL : Chaque type de requête (contenu WP, données externes, MongoDB) possède son propre TTL.
• Utilisation des tags : Chaque requête est associée à un tag unique. Ces tags facilitent la gestion et l’invalidation ciblée des caches.
• Optimisation des performances : Une fois une requête mise en cache, elle n’est pas répétée tant que son TTL n’est pas écoulé.

2. Cache des pages Next.js

L’utilisation de l’app router de Next.js 14 permet de générer les pages de manière efficace :

• Pages générées au build : Initialement, toutes les pages sont construites lors du déploiement.
• Pages re générées dynamiquement : Lorsqu’une requête est invalidée (fin du TTL ou invalidation manuelle), les pages concernées sont régénérées.
• Servir depuis le CDN : La majorité des pages sont servies directement via le CDN, réduisant ainsi la charge serveur et améliorant les temps de réponse.

3. Cache MongoDB

Pour les données provenant d’APIs externes, nous avons mis en place un cache spécifique dans MongoDB.

• Mise à jour via des CRON : Des tâches planifiées collectent régulièrement les données externes et les synchronisent dans MongoDB.
• Accès rapide et résilience : En cas de lenteur ou d’indisponibilité d’une API externe, MongoDB garantit un accès stable et rapide à des données mises en cache.
• Indépendance utilisateur : Ces mises à jour sont totalement découplées des requêtes utilisateur.

‍

Synchronisation des caches

‍

Trois mécanismes assurent une synchronisation fluide :

1. CRON pour les données externes : Les sources comme Instagram ou Flowbox sont mises à jour indépendamment des requêtes front-end.
2. TTL pour les données WP : Les données WordPress sont automatiquement rafraîchies dès que leur TTL est atteint.
3. Cache des pages : L’invalidation d’une requête déclenche la régénération des pages associées, maintenant la synchronisation entre le contenu WordPress et le front.

Pour des besoins spécifiques (par exemple, une mise à jour sensible ou juridique), les contributeurs peuvent forcer la régénération des pages via une API d’invalidation. En indiquant les tags concernés, cette API utilise les outils natifs de Next.js pour :

• Invalider les requêtes associées.
• Déclencher la régénération immédiate des pages concernées.

‍

Les avantages clés de la gestion des caches

‍

1. Performance

‍Les utilisateurs bénéficient d’un affichage instantané, car la plupart des pages sont déjà générées et servies depuis le CDN.

2. Mise à jour automatique

‍Les contributeurs n’ont pas besoin d’intervenir pour synchroniser leurs modifications : le système de TTL assure une mise à jour fluide et continue entre WordPress, les APIs et le front-end.

3. Résilience

‍Le cache MongoDB évite les dépendances directes aux APIs externes, minimisant ainsi l’impact des lenteurs ou indisponibilités des services tiers.

4. Contrôle

‍En cas de besoin urgent, les contributeurs peuvent forcer une mise à jour immédiate, sans attendre la fin du TTL.

Cette gestion fine des caches est une pièce maîtresse de l’architecture, combinant performance, fiabilité et flexibilité pour répondre aux besoins de nos contributeurs et utilisateurs.

‍

LES MAUVAISES SURPRISES…

Limitations de WordPress

‍

L’API native de WordPress ne fournit pas toutes les données nécessaires, notamment dans un contexte multilingue avec WPML. Par exemple, il est indispensable de connaître les slugs des pages ou des custom post types dans les différentes langues pour gérer correctement le sélecteur de langue sur le front-end et respecter les exigences SEO, telles que des URL sémantiques traduites.

Pour pallier cette limitation, un plugin WordPress personnalisé a été développé. Ce plugin enrichit l’API WordPress pour exposer ces informations supplémentaires, permettant ainsi à Next.js de gérer efficacement les liens interlangues et d’améliorer la navigation multilingue.

Limites de Next.js

‍

Une autre contrainte majeure a concerné la gestion multilingue proposée nativement par Next.js, jugée trop rudimentaire et présentant des défauts importants pour le SEO. Ces limitations incluent :

• La gestion peu fluide des traductions d’URL et des liens de page.
• Des vérifications coûteuses de réécritures, mobilisant le runtime.
• La duplication de contenu avec des pages disponibles sur plusieurs URLs.
• Une baisse du score SEO global.

Pour résoudre ce problème, next-roots (une bibliothèque tierce) a été intégrée. Ce projet open source, dirigé par svobik7, permet une gestion avancée du multilingue avec Next.js. L'équipe a également contribué activement à ce projet via plusieurs PR pour lever certaines limitations, tout en remerciant chaleureusement svobik7 pour son excellent travail. Grâce à cette collaboration, next-roots nous a permis :

• De traduire chaque segment d’URL.
• De simplifier la gestion des balises SEO (hreflang, sitemap, balises canoniques).
• De gérer efficacement les breadcrumbs et sélecteurs de langue.
• De conserver un excellent score SEO

Déploiement hors de Vercel

Next.js est optimisé pour fonctionner sur Vercel, mais l'architecture a été déployée sur des serveurs d’un prestataire tiers, en utilisant pm2 pour servir l'application en mode cluster avec 8 processus Node.js. Ce mode améliore les performances en répartissant les requêtes utilisateur entre plusieurs processus.

Cependant, ce modèle a posé un problème pour l'invalidation des caches : lorsqu’un contributeur utilise l’API pour invalider un tag de cache, seul le processus qui traite la requête effectue cette opération. Les autres processus conservent leurs caches invalides.

Pour résoudre ce problème, une communication IPC (Inter-Process Communication) a été mise en place. Chaque processus informe les autres de la demande d'invalidation via un message IPC. Ainsi, tous les processus propagent l'invalidation des tags et assurent une cohérence du cache au sein du cluster.

Fonctionnalité de preview

WordPress propose aux contributeurs de prévisualiser :

1. Une nouvelle page avant publication.
2. Les modifications apportées à une page existante avant qu’elles ne soient enregistrées.

Un système a été développé pour valider le token du contributeur, garantir les droits d'accès, et récupérer via l'API WordPress les brouillons ou modifications non enregistrées. Cette fonctionnalité a nécessité un plugin WordPress supplémentaire et une logique complexe côté Next.js, mais elle offre aux contributeurs un contrôle total sur leurs contenus avant leur publication.

‍

EN CONCLUSION

Ce projet démontre les avantages d’une architecture headless, combinant la flexibilité de WordPress pour la gestion des contenus et la performance de Next.js pour un front-end moderne et réactif.

Grâce à cette approche, nous avons pu offrir une solution robuste, multilingue, multimarque, multipays et parfaitement adaptée aux besoins des contributeurs tout en garantissant une expérience utilisateur optimale.

Au-delà des aspects techniques, ce projet montre également l’importance de la collaboration dans l’écosystème open source, comme en témoigne notre contribution au projet next-roots.

N’hésitez pas à contacter nos experts pour en savoir plus sur ces questions.

‍

Découvrez le cas client Provalliance (Franck Provost, Jean Louis David, etc.), leader de la coiffure.