Du WordPress headless au thème

Un site qui montre au lieu de dire

Ce site devait répondre à quatre questions : qui, quoi, comment, ce que ça apporte. Et il devait le faire sans rien affirmer qu’il ne puisse prouver : aucun résultat, aucun client, aucun chiffre inventé. Les textes ont été écrits et sourcés avant la première ligne de code, page par page.

Je voulais deux choses. Un site qui marque, dans sa forme autant que dans ses textes : un dessin sur mesure, des animations, une mise en scène. Et un gestionnaire de contenu que je connais bien, WordPress, celui que j’utilise depuis Mondoblog, pour le faire vivre seul.

Deux outils : le site d'un côté, WordPress de l'autre

Au départ, WordPress ne semblait pas pouvoir porter seul ce dessin. La réponse a été un WordPress headless, littéralement « sans tête » : WordPress garde les textes, mais n’affiche plus rien lui-même. C’est un autre programme qui dessine le site et va chercher les textes chez lui.

Ce programme, ici, c’est Next.js, un cadre de développement qui laisse dessiner chaque écran à sa main. WordPress a été branché deux jours après le premier commit, et chaque texte du site y a été repris et comparé mot à mot.

Les deux allaient bien ensemble, et le site fonctionnait. Le dessin voulu d’un côté, l’éditeur familier de l’autre.

Capture du site

Ce qui pesait, ce n'était pas le site, c'était le chemin pour le modifier

Pour qu’une correction arrive en ligne, elle traversait toute une chaîne :

• WordPress, où l’on corrige le texte ;
• GitHub, où le code du site est rangé et versionné : chaque modification du code s’y enregistre (un commit) puis s’y envoie (un push) ;
• la construction : Next.js fabrique d’un coup toutes les pages du site, en allant chercher chaque texte dans WordPress ;
• le dépôt : les pages fabriquées sont copiées sur l’hébergement.

Un bouton dans WordPress lançait le tout, mais chaque virgule repassait par chaque étape.

Et chaque évolution du site demandait plus encore. Quelques exemples, datés dans le journal du projet :

• Un champ, quatre endroits. Pour rendre un nouveau texte modifiable, il fallait le déclarer à quatre endroits du code et de la base.
• Deux versions d’un même texte. Le 8 septembre, des textes corrigés dans le code s’affichaient encore dans leur ancienne version, celle de WordPress.
• Une case qui bloque tout. Le 9 septembre, trois publications d’affilée ont été refusées à cause d’une seule case cochée dans WordPress.

Le plus difficile, c’est toujours de choisir l’architecture.

Réduire l'architecture : un seul outil pour tout tenir

En testant, une évidence s’est imposée : WordPress pouvait tout tenir, le dessin compris. Le 6 octobre, le site a été refait en thème WordPress, c’est-à-dire l’habillage que WordPress applique lui-même à ses pages : le même dessin, les mêmes animations, les mêmes adresses, servis directement, sans GitHub, sans construction, sans dépôt à part. Ce qu’on corrige dans l’éditeur est en ligne à l’enregistrement.

Le critère était strict : rien ne devait changer pour le lecteur. Chaque page a été comparée à l’ancienne, d’abord par son code, puis écran par écran, en captures. La scène du premier écran, le défilement aimanté, les animations : tout tient dans le thème.

Puis chaque partie du site est devenue un bloc de l’éditeur, ces éléments qu’on assemble et qu’on règle à la souris, sans toucher au code. Un dossier est une page ; une section, une case ; une capture, une planche. Ce dossier-ci a été saisi ainsi, directement dans WordPress.

Capture du site

Le site a basculé à la mi-octobre, sans casser un lien : les 88 anciennes adresses renvoient vers les nouvelles en une étape.

Une architecture qui fonctionne n'est pas forcément la plus juste

La première version marchait. Mais chaque outil ajouté dans la chaîne est une étape de plus à chaque modification, et une règle de plus à retenir. Quand un seul outil peut tout tenir, le reste n’est que du processus en plus.

La seconde leçon : une architecture se juge à l’usage, sur de vrais contenus. C’est en alimentant le site, et pas en le construisant, qu’on a vu ce qu’on pouvait retirer.

Ce qui reste, c’est une expérience reproductible : un site dessiné sur mesure, porté dans WordPress sans rien perdre, et organisé en blocs que celui qui l’alimente règle lui-même.

En ligne, et alimenté depuis l'éditeur

Le site est servi par son thème WordPress. Les textes, les dossiers et les articles se modifient dans l’éditeur, et le site continue d’évoluer : le premier écran a été repris le 27 octobre, sans quitter WordPress.

Capture du site