Pendant environ six semaines, ce site a fonctionné en WordPress headless, une architecture souvent présentée comme le meilleur des deux mondes. Elle a tenu ses promesses techniques. Son coût était ailleurs : dans tout ce qu'il fallait faire pour qu'une simple correction arrive en ligne.
De quoi parle-t-on ?
WordPress est le CMS le plus répandu : on y écrit ses textes, on y range ses images, et il fabrique lui-même les pages du site. Un WordPress dit « headless », littéralement sans tête, garde la première moitié du travail et abandonne la seconde. Il conserve les textes, mais n’affiche plus rien. Un autre programme se charge de dessiner le site et vient chercher les textes chez lui.
Pour be-hem.com, ce choix avait une raison précise. Je voulais un site dessiné sur mesure, avec des animations et une mise en scène qu’un thème WordPress ne semblait pas pouvoir porter, et je voulais en même temps continuer à écrire dans WordPress, un outil familier que j’utilise depuis mes premières heures de blog en 2011. Le programme d’affichage a été construit avec Next.js, un outil de développement qui laisse dessiner chaque écran librement. Sur le papier, l’équilibre était parfait : la liberté du design d’un côté, le confort de l’éditeur de l’autre.
Une correction, quatre étapes
Le coût s’est révélé à l’usage. Pour qu’un mot corrigé dans WordPress apparaisse sur le site, il traversait une chaîne de quatre étapes : la correction dans WordPress, l’enregistrement du code sur GitHub, la fabrication de toutes les pages du site d’un seul coup, puis leur copie sur l’hébergement. Un bouton lançait l’ensemble, mais chaque virgule repassait par chaque étape, et chacune pouvait échouer.
À cela s’ajoutait une règle contraignante : pour qu’un nouveau texte soit modifiable depuis WordPress, il fallait le déclarer à quatre endroits différents, dans le code et dans la base. Oublier l’un d’eux ne provoquait aucune erreur visible, puisque le texte s’affichait grâce à une valeur de secours. Il devenait simplement impossible à modifier, sans que rien ne le signale.
Ce que le journal du projet a retenu
Le journal du projet garde la trace des incidents de ces semaines. Aucun n’était grave, mais tous avaient la même origine. Des textes corrigés dans le code continuaient de s’afficher dans leur ancienne version, parce que celle de WordPress avait priorité. Trois publications d’affilée ont été refusées à cause d’une seule case cochée dans WordPress. J’ai fini par découvrir que la liste des articles du blog pouvait se vider entièrement si une seule des requêtes envoyées au serveur était refusée. Puis, l’import d’une ancienne archive a fait apparaître soixante et onze pages vides, en double des vraies. Finalement, les essais menés en local affichaient une vieille version, conservée en mémoire.
À chaque fois, le problème tenait au fait que deux outils devaient rester d’accord en permanence, et qu’une chaîne de quatre étapes offre autant d’occasions de se désynchroniser. On ne passait pas son temps à améliorer le site, on le passait à surveiller la chaîne.
Revenir à un seul outil
En testant, une évidence s’est imposée : WordPress pouvait finalement porter seul le design voulu. À la mi-octobre, le site est revenu à un thème WordPress, avec plus ou moins le même design, des animations quasi similaires et les mêmes adresses. Désormais, ce qui est corrigé dans l’éditeur est en ligne dès l’enregistrement. Le récit complet de cette bascule fait l’objet d’un dossier dans la rubrique Projets.
Le headless n’est pas un mauvais choix pour autant. Il a du sens pour une équipe qui dispose d’un développeur à demeure, pour plusieurs sites qui puisent dans les mêmes contenus, ou pour des besoins que WordPress ne sait vraiment pas servir. Pour un site tenu par une seule personne, en revanche, chaque étape ajoutée est une étape de plus à surveiller, seul.
Avant de choisir une architecture découplée, une question suffit souvent à trancher : qui corrigera une faute de frappe, et combien d’étapes le sépareront du lecteur ? Si la réponse est « moi, seul, et quatre », l’outil principal sait sans doute déjà faire ce qu’on s’apprête à chercher ailleurs.
Une architecture se choisit sur ce qu’elle permet. Elle se garde sur ce qu’elle coûte.