WordPress headless avec Silex : un front statique rapide, un back-office que vos clients connaissent déjà

Si vous construisez des sites pour des clients, vous connaissez cette tension. Les clients adorent WordPress parce qu'ils peuvent se connecter et modifier eux-mêmes leurs contenus. Mais livrer un front WordPress moderne pour de vrais clients — un front qui reste rapide, sûr et maintenable — c'est un vrai travail, souvent ingrat. Beaucoup d'agences et de freelances se sont battus avec des page builders et des thèmes lourds, avant de revenir en silence à un WordPress monolithique qu'ils doivent maintenant materner.

Le WordPress headless est la sortie de cette tension, et Silex le rend accessible. L'idée est simple : WordPress continue de faire ce qu'il fait de mieux, servir de back-office de contenu, et Silex conçoit le front visuellement puis le publie comme un site statique tout simple. Votre client continue d'éditer dans l'admin WordPress qu'il connaît déjà ; le site public, lui, n'est plus que du HTML et du CSS rapides et standards, régénérés depuis WordPress à chaque changement de contenu. Cet article explique comment ça marche, quand c'est le bon choix, et — tout aussi important — quand ça ne l'est pas.

Un mot sur l'origine de tout ça. Le workflow décrit ci-dessous a été montré en direct, de bout en bout, sur deux lives de Silex Labs, avec à chaque fois un professionnel de WordPress dans la pièce pour poser les questions qui fâchent : Emmanuel Mutel, designer et intégrateur web freelance, et Hugo Blanchard de l'agence WordPress Digital Korner (et de son studio de plugins WP Connect), à Nantes. Merci à eux deux pour ce regard honnête et concret. Nous avons conservé leur cadrage et revérifié les faits techniques durables (WPGraphQL, la situation ACF/SCF, le build Eleventy) auprès de sources à jour.

D'abord, rendons à WordPress ce qui lui appartient : c'est un excellent CMS

Soyons clairs d'emblée, car ceci n'est pas un article « quittez WordPress ». WordPress est l'un des grands projets du logiciel libre. Il fait tourner une part énorme du web, son expérience d'édition est familière à des millions de personnes, et son écosystème d'extensions est immense. Quand un client non technique s'assoit pour écrire un article, ajouter un membre à l'équipe ou changer une image de bandeau, WordPress est un endroit vraiment agréable pour le faire.

Ce qui vieillit mal, ce n'est pas WordPress le CMS. C'est le couplage traditionnel de ce CMS avec le front public : du PHP exécuté à chaque requête, une base de données exposée sur internet, un thème empilé sur un page builder, et une charge de maintenance qui ne s'arrête jamais. Le headless garde la bonne partie — le back-office — et remplace la partie fragile — le front d'exécution. Vous ne combattez pas WordPress. Vous le laissez faire l'unique tâche pour laquelle il est le meilleur.

Ce que « WordPress headless » veut vraiment dire

Sur un site WordPress classique, un seul serveur fait tout : il stocke vos contenus, génère les pages en PHP et les sert aux visiteurs. « Headless » (sans tête) veut dire qu'on débranche la tête — le front — du corps — le CMS. WordPress devient un back-office de contenu pur, accessible via une API, et c'est autre chose qui construit les pages que vos visiteurs voient réellement.

Avec Silex, cet « autre chose », c'est un éditeur visuel plus un build statique :

1. WordPress détient le contenu. Articles, pages et champs personnalisés vivent dans WordPress exactement comme votre client s'y attend.
2. WordPress expose ce contenu via une API grâce à l'extension WPGraphQL, qui ajoute un point d'accès GraphQL à n'importe quel site WordPress. Silex se contente de le lire — aucune écriture, aucune mutation —, ce qui vous permet de verrouiller le reste.
3. Silex conçoit le front face à ce contenu réel, visuellement, dans le navigateur.
4. Le site est publié sous forme de fichiers statiques générés par Eleventy au moment du build. Pas de PHP, pas de base de données sur le serveur public. Juste du HTML, du CSS et des ressources.

Le site publié n'est pas « connecté » à WordPress au runtime. Le contenu est récupéré une fois, au moment du build, puis figé dans des fichiers. Comme l'équipe l'a résumé en direct : une fois le build terminé, vous pouvez éteindre complètement le serveur WordPress, le site en ligne continue de tourner, puisque ce ne sont que des fichiers sur un hébergement.

Pourquoi découpler le front, au fond

Séparer le CMS du front vous apporte quatre choses concrètes.

La vitesse. Un site statique est à peu près ce qui se fait de plus rapide sur le web. Il n'y a pas de PHP à exécuter ni de base à interroger quand un visiteur arrive : les pages sont servies comme de simples fichiers, idéalement depuis un CDN. En production, l'équipe Silex rapporte des scores Lighthouse/PageSpeed supérieurs à 90 sur mobile et proches de 100 sur ordinateur pour ces sites. Les images en font partie : le build Eleventy peut les redimensionner et les convertir automatiquement en formats modernes WebP ou AVIF, si bien qu'un client peut téléverser un gros JPEG sans y penser et obtenir malgré tout un <source> optimisé dans le HTML final.

La sécurité et une maintenance minimale. C'est le point sur lequel un professionnel WordPress présent au live a été le plus cash. Un WordPress non mis à jour est une cible : sautez les mises à jour pendant quelques mois et vous pouvez vous attendre à vous faire pirater. Un site statique n'a quasiment aucune surface d'attaque, parce qu'il n'y a rien de dynamique qui tourne sur le serveur public. Et dans un montage headless, vous pouvez verrouiller l'admin WordPress à fond, la restreindre à certaines adresses IP, ou la garder entièrement hors de l'internet public, en n'exposant qu'une route GraphQL en lecture. Le contenu ressort vers le build ; rien ne rentre en sens inverse.

La sobriété. Rien qui s'exécute sur le serveur à chaque requête, cela signifie moins de calcul, des pages plus légères et une empreinte plus faible. Un HTML statique propre et taillé à la main s'en sort bien sur des outils comme Website Carbon, et il vous donne une base solide et standard pour construire des pages accessibles, au lieu des empilements profonds de <div> imbriqués que génèrent souvent les thèmes lourds et les page builders.

Pas de lock-in. Un site Silex, c'est du HTML et du CSS standards que vous hébergez où vous voulez : GitLab Pages gratuitement, un hébergement FTP, votre propre serveur, n'importe quel CDN. Aucun runtime propriétaire en dessous, aucune plateforme qui prend le site en ligne en otage. Si un jour vous quittez Silex, vous gardez des fichiers standards et vous gardez votre contenu dans WordPress. La portabilité est l'état par défaut, pas un bouton « exporter » assorti d'astérisques.

Comment ça marche, étape par étape

Voici le pipeline réel que les lives ont démontré, d'un projet vierge à un site éditable par le client.

1. Transformer WordPress en source headless

Installez l'extension WPGraphQL sur le site WordPress. C'est la seule pièce indispensable : elle vous donne une unique URL GraphQL que Silex comprend. Silex n'a besoin que d'un accès en lecture à cette route — pas d'accès en écriture, pas de mutations —, vous pouvez donc garder le reste de WordPress verrouillé.

2. Modéliser le contenu avec des champs personnalisés

Les articles WordPress bruts arrivent avec beaucoup de balisage dont vous ne voulez pas dans une page mise en forme. L'approche propre consiste à définir vos propres champs : le client remplit un titre, une image, une date, une courte description, et chacun de ces champs correspond à un élément précis et stylé de votre design.

C'est ce que fait un framework de champs personnalisés, et ici nous en recommandons un entièrement libre : Pods. Pods est un logiciel libre (GPL), porté par la communauté, offre tous les types de champs gratuitement, et intègre le support WPGraphQL directement dans son cœur depuis la version 2.9 : vos champs apparaissent dans l'API en cochant une case. Il garde toute la stack libre, de bout en bout.

L'option la plus connue est Advanced Custom Fields (ACF), maintenue par WP Engine. Il vaut la peine de connaître la situation actuelle : en octobre 2024, pendant le conflit WP Engine / WordPress.org, l'équipe de WordPress.org a forké ACF en Secure Custom Fields (SCF), désormais la version fournie par l'annuaire de WordPress.org. N'importe laquelle convient à un workflow headless avec Silex : vous ne faites que définir des groupes de champs, et Silex les lit de la même façon. Si vous partez de zéro, c'est Pods que nous choisirions.

3. Concevoir le front dans Silex, face au contenu réel

Dans Silex, vous construisez la page visuellement : conteneurs, calques, classes CSS que vous créez et réutilisez, points de rupture responsive. Deux habitudes comptent ici, et toutes deux sont revenues comme pièges de débutant en direct : créez de vraies classes plutôt que de styler l'identifiant d'un élément, et pensez la structure de vos classes avant de commencer à décorer les blocs.

Ensuite, vous liez le contenu. Sélectionnez un élément de texte et, dans ses réglages, vous pouvez lui assigner une valeur venant de WordPress : un titre d'article, un champ personnalisé, un extrait. Pour une liste d'articles, vous définissez une boucle : un seul design qui génère une page par article, chacune avec sa propre URL, exactement comme une page de collection. En coulisses, Silex transforme cela en boucle de gabarit dans le build statique, mais vous la créez avec des clics, pas du code.

4. Gérer le SEO et les slugs sans extension

Comme vous maîtrisez les gabarits, vous n'avez pas besoin d'une extension SEO WordPress sur le front. Les slugs et permaliens des pages viennent directement des données WordPress (pagination.items), et le titre SEO, la description et l'image de partage social sont juste des champs que vous mappez dans les réglages de page de Silex. Le schéma le plus simple recommandé par l'équipe : ajoutez de simples champs texte dans Pods (ou ACF/SCF) pour « titre SEO » et « description SEO », plus une valeur de repli valable pour tout le site quand un client en laisse un vide. Si votre client tient à Yoast, vous pouvez toujours récupérer ses valeurs, mais deux champs personnalisés font souvent une extension de moins et suffisent parfaitement.

5. Publier, et laisser le client relancer le build tout seul

Publier lance un build (sur GitLab CI, avec Eleventy) qui récupère tout depuis WordPress et écrit le site statique. Le point important pour l'autonomie du client : installez une extension de déploiement sur WordPress, ou câblez un jeton de déclenchement (trigger token) GitLab — une URL à appeler, éventuellement en POST —, et le client peut lancer un nouveau build depuis l'intérieur de WordPress. Il n'ouvre jamais Silex. Il modifie son contenu, clique sur un bouton, et son site en ligne se met à jour.

La vraie valeur : vous livrez, votre client reste autonome

C'est tout l'intérêt de l'approche, alors autant le dire clairement. Le WordPress headless avec Silex, ce n'est pas migrer un site WordPress existant vers du statique, et ce n'est pas remplacer WordPress. C'est un modèle de livraison pour freelances et agences :

• Vous concevez et construisez le front dans Silex, livrez un site statique rapide, propre et portable, et remettez un back-office WordPress configuré avec les bons champs et modules.
• Votre client édite son contenu dans l'admin WordPress qu'il connaît déjà : il ajoute des articles, remplace des images, remplit des sections et publie, sans toucher au design ni au code, et sans dépendre de vous pour le moindre changement de texte.

Comme l'a résumé Hugo Blanchard (Digital Korner) : Silex peut être quasiment invisible pour le client. Il n'a pas besoin de savoir que ça existe. Il vit dans WordPress ; le site statique rapide se débrouille tout seul.

Quand le headless n'est pas le bon choix

Le headless est un vrai compromis, pas un gain gratuit. Soyez honnête avec vous-même et avec votre client sur les cas où il vaut mieux s'en passer :

• Les petits sites à faible trafic où la performance et la sécurité sont déjà correctes. Si un simple site WordPress fait le travail, ajouter un pipeline de build, c'est de la complexité dont vous n'avez pas besoin.
• Les clients qui veulent tout dans un seul outil. Le headless, c'est deux pièces en mouvement : WordPress plus le montage Silex/build. Certains clients (et certains budgets) sont mieux servis en restant monolithiques.
• Les sites qui reposent sur des extensions WordPress dynamiques côté front. Tout ce qui doit exécuter du PHP à chaque requête pour le visiteur — recherche en direct, personnalisation dynamique sur la page, certains parcours d'abonnement ou d'e-commerce — ne se traduit pas proprement en front statique. Si l'interactivité est au cœur du site, le headless vous mettra des bâtons dans les roues.
• Les équipes sans appétit pour une étape de build. Dès que vous dépassez le simple site statique, vous prenez en charge GitLab, un pipeline et l'habitude de rebuilder à la publication. Ça vaut le coup pour du travail professionnel ; c'est disproportionné pour une plaquette d'une page.

Si l'un de ces cas décrit votre projet, un build WordPress classique est la recommandation honnête.

Côte à côte

À qui ça s'adresse

Tournez-vous vers le WordPress headless avec Silex si vous êtes freelance ou agence et livrez des sites à des clients qui veulent gérer leur propre contenu, si la performance et la sécurité comptent pour le projet, et si vous préférez remettre des fichiers standards hébergeables partout plutôt que d'attacher le site en ligne à une plateforme. C'est un choix particulièrement adapté aux studios qui font du travail professionnel récurrent, où un front rapide et peu coûteux à maintenir et un client autonome valent l'un comme l'autre de l'argent bien réel.

Restez sur un build WordPress classique si le site est petit, si le client veut un outil unique, ou si le front dépend réellement d'extensions WordPress dynamiques. Le bon outil pour le bon usage.

À voir en action

Tout le workflow ci-dessus a été construit en direct, avec nos deux invités. Regardez les épisodes :

Silex aime les développeurs WordPress, avec Emmanuel Mutel.

Spécial WordPress, avec Hugo Blanchard (Digital Korner).

Un mot pour finir, côté libre

Le résumé honnête est celui-ci : WordPress est un excellent CMS, et il est à son meilleur quand il fait le travail de contenu sans qu'on lui demande d'être en plus un front fragile, exposé et coûteux à maintenir. Silex est un facilitateur — une façon visuelle et intégrée de construire ce front statique et de le déployer gratuitement sur GitLab Pages ou ailleurs —, si bien que vous gardez le confort d'édition de WordPress sans son fardeau d'exécution.

Et Silex est un logiciel libre, pas juste « open source » au sens marketing. Il est sous licence AGPL et porté par l'association à but non lucratif Silex Labs. Ça compte, pour un outil sur lequel vous bâtissez une activité auprès de clients : aucune entreprise ne peut en douce le fermer, le racheter ou verrouiller la fonctionnalité dont vous aurez besoin l'an prochain. Vous gardez le code source, vous gardez le site, vous gardez la main. « Open source » est l'expression que les gens cherchent ; la liberté est la raison pour laquelle il est construit ainsi.

Si ça correspond à votre façon de travailler, essayez l'éditeur, lisez la documentation et venez poser vos questions dans la communauté. Et si un simple build WordPress est la bonne réponse pour votre projet, c'est aussi un bon résultat. L'objectif est de choisir en connaissance de cause.