Approche headless
Découplage total du front-end et du CMS pour une livraison omnicanale, des performances edge et une réversibilité totale.
Le headless sépare définitivement le CMS éditorial du front-end : les éditeurs contribuent dans l'outil qu'ils maîtrisent, les développeurs déploient un front Next.js optimisé, et les deux couches évoluent sans se bloquer. Pas de monolithe, pas de risque de régression cross-layer.
Indépendance des couches
Changer de CMS n'oblige pas à réécrire le front. Changer de front n'impacte pas le CMS. Les mises à jour WordPress, les montées de version de Next.js et les évolutions métier se font en parallèle, chacune dans son périmètre.
Performance et omnicanalité
Le rendu est statique ou edge-cached : les pages se servent en quelques millisecondes depuis Cloudflare, sans solliciter le serveur. Le même middleware peut alimenter un site web, une app mobile et un outil interne simultanément.
Réversibilité garantie
L'API exposée par le middleware est stable et versionnée. Remplacer WordPress par un autre CMS demain, ou migrer le front vers un autre framework, ne casse aucune intégration : le contrat d'API tient.
Architecture du hub headless MUH
Notre socle headless repose sur MUH (Middleware Unifié Headless), développé en interne en NestJS. Il s'interpose entre le CMS (WordPress Bedrock) et les fronts consommateurs (Next.js, apps mobiles, outils internes).
Trois couches distinctes :
- CMS éditorial (WordPress Bedrock) - Les éditeurs travaillent dans une interface connue. WordPress est déployé en conteneur stateless sur Kubernetes BSO, avec stockage S3/MinIO pour les médias et Redis pour le cache objet.
- Middleware NestJS (MUH) - Interroge WordPress via REST ou GraphQL, normalise les données (ACF, Polylang, multilingue), applique les règles métier transversales et expose des APIs propres et documentées. C'est ici que vivent la gestion du cache, la revalidation Next.js, les formulaires sécurisés et l'intégration Meilisearch.
- Front Next.js - Consomme exclusivement l'API MUH. Rendu hybride (SSG pour les pages stables, ISR pour les contenus mis à jour fréquemment, SSR pour les pages personnalisées). Aucun appel direct au CMS.
Ce que ça change pour la DSI
- APIs REST/GraphQL versionnées : contrat stable et documenté entre le front et le CMS, indépendant des mises à jour WordPress ou des changements de plugins.
- Sécurité périmétrique : WordPress n'est jamais exposé directement sur le réseau public. Seule l'API MUH est accessible, avec authentification OAuth2/Keycloak pour les zones protégées.
- Cache edge Cloudflare : les pages sont servies depuis le cache en quelques millisecondes. À chaque publication éditoriale, seules les URLs concernées sont purgées (invalidation ciblée, pas de wipe global).
- Autoscaling stateless : les pods WordPress et NestJS sont stateless (médias sur S3, sessions sur Redis). L'autoscaling horizontal ne requiert aucune configuration particulière.
- Observabilité : logs structurés, alertes sur les 5xx et les erreurs de revalidation, dashboards Loki/Grafana sur BSO.
- Packages
@muh/*versionnés : adapters, forms, fixtures et CLI sont publiés dans le registry GitLab privé avec un changelog sémantique. Chaque composant réutilisable est upgradeable indépendamment.
Mesure et pilotage
- Temps de réponse page (TTI, LCP) mesurés en continu via Cloudflare Analytics et Lighthouse CI.
- Taux de cache hit Cloudflare (objectif : > 85 % sur les pages publiques).
- Erreurs de revalidation et 5xx middleware monitorés et alertes en temps réel.