Séparer le fond de la forme
Dans un CMS classique, le back-office et le site public sont un seul et même logiciel : changer l'apparence oblige à travailler dans les gabarits de l'outil, et refondre le site implique souvent de refaire l'administration avec. Une architecture headless coupe ce lien. Le back-office ne fait plus qu'une chose : stocker le contenu et l'exposer via une API. L'affichage devient un projet à part, libre de sa technologie.
Pour les équipes contenu, rien ne change dans le quotidien : elles écrivent au même endroit. Ce qui change, c'est le nombre de destinations que ce même contenu peut alimenter.
Ce que ça débloque
Le premier gain est la diffusion multi-canal. Une fiche produit rédigée une fois nourrit le site, l'application mobile, une borne en magasin et le catalogue envoyé à un partenaire. Pas de recopie, pas de version divergente.
Le deuxième est le rythme. On peut refondre entièrement l'interface publique sans toucher au back-office ni migrer le contenu, ce qui rend les refontes moins lourdes et donc plus fréquentes. Le troisième est la performance : le front n'est plus contraint par les choix techniques du CMS et peut s'appuyer sur les frameworks modernes, ce qui se voit directement sur les temps de chargement et le référencement.
Quand ça ne vaut pas le détour
Le headless ajoute une pièce à l'architecture : deux applications à déployer et à surveiller au lieu d'une. Pour un site vitrine de dix pages, mis à jour trois fois par an et sans autre canal, le jeu n'en vaut pas la chandelle. La bascule devient intéressante dès qu'il y a plusieurs points de diffusion, un volume de contenu réel, des équipes distinctes sur le contenu et sur le produit, ou une exigence de performance forte.
C'est l'architecture que nous retenons le plus souvent sur nos projets de développement web sur mesure, et notamment sur les sites à fort volume de contenu. Elle s'accompagne d'une réflexion sur la scalabilité du front, qui devient le point d'entrée du trafic.
