MUH
Le hub headless qui normalise vos contenus CMS en APIs propres, consommables par n'importe quel front.
MUH (Middleware Unifié Headless) découple définitivement le front-end du CMS : WordPress Bedrock côté éditorial, un middleware NestJS au centre, un ou plusieurs fronts Next.js en sortie. Chaque couche évolue indépendamment des autres - changer de CMS n'oblige pas à réécrire le front, et inversement.
Découplage
Le front ne parle jamais directement au CMS. MUH expose des APIs REST/GraphQL normalisées et stables, quelle que soit la version de WordPress ou la configuration des plugins. Le CMS devient un détail d'implémentation.
Qualité intégrée
SEO et GEO (optimisation pour les IA génératives), accessibilité RGAA, cache Cloudflare avec invalidation ciblée par URL, auth OAuth2/Keycloak - la qualité est câblée dans le socle, pas ajoutée au cas par cas.
Réversibilité
Les packages @muh/* (adapters, forms, fixtures, CLI) sont versionnés sémantiquement et publiés dans le registry GitLab privé. Remplacer WordPress par un autre CMS demain ne casse aucun code front.
Architecture du hub headless
MUH s'articule autour de trois couches :
WordPress Bedrock (CMS) - WordPress géré avec Bedrock (structure Composer, .env, mu-plugins). Les éditeurs créent et organisent les contenus via une interface familière. Le CMS est déployé sur Kubernetes BSO en conteneur stateless, avec stockage S3/MinIO pour les médias et Redis pour le cache objet.
Middleware NestJS - Le cœur de MUH. Il interroge WordPress via l'API REST ou GraphQL, normalise et enrichit les données (résolution des ACF, traductions Polylang, formats multilingues), puis les expose en APIs propres et documentées. C'est ici que vivent les règles métier transversales : gestion du cache, revalidation Next.js, formulaires de contact sécurisés, intégration Meilisearch.
Front Next.js (et apps) - Le ou les fronts consomment uniquement l'API MUH. Ils peuvent être remplacés, dupliqués ou étendus sans toucher au CMS ni au middleware. Un même middleware peut alimenter un site web, une app mobile et un outil interne simultanément.
Ce que ça change pour la DSI
- APIs REST/GraphQL normalisées : contrat stable entre le front et le CMS, versionné et documenté - indépendant des mises à jour WordPress.
- Auth OAuth2/Keycloak : authentification centralisée, les tokens sont validés par le middleware - le CMS WordPress n'est jamais exposé directement sur le réseau public.
- Cache Cloudflare + invalidation ciblée : les pages sont servies depuis le cache edge en quelques millisecondes. À chaque publication, seules les URLs concernées sont purgées - pas d'invalidation globale qui efface tout.
- Packages
@muh/*versionnés : adapters, forms, fixtures, CLI - chaque composant réutilisable est publié dans le registry GitLab privé avec un changelog sémantique. - Observabilité : Loki/Grafana sur le cluster BSO, logs structurés, alertes sur les 5xx et les erreurs de revalidation.
- Stateless et scalable : les pods WordPress et NestJS sont stateless (médias sur S3, sessions sur Redis). L'autoscaling horizontal est possible sans configuration particulière.