Drupal headless, partiellement découplé ou monolithique : choisir

« On devrait passer en headless ? » est la question d’architecture qu’on me pose le plus — et celle à laquelle on répond le plus souvent par idéologie plutôt que par arbitrages. Je travaille actuellement sur un back-office Drupal 10 qui alimente un front Symfony via API chez France Télévisions, j’ai livré des monolithes Twig classiques pendant une décennie, et ce site-ci est un front statique sans aucun CMS. Voici la grille que j’utilise vraiment.

Les trois options (et demie)

1. Drupal monolithique. Drupal rend tout : templates Twig, render cache, BigPipe. Un déploiement, un seul modèle mental. Les éditeurs ont l’édition contextuelle, les outils de mise en page et l’aperçu instantané gratuitement.

2. Full headless. Drupal devient une API de contenu (JSON:API, GraphQL ou endpoints sur mesure) et une application séparée — Next, Nuxt, Astro, ou dans notre cas Symfony — possède le front. Deux bases de code, deux déploiements, un contrat entre les deux.

3. Partiellement découplé (découplage progressif). Drupal rend toujours les pages, mais des zones interactives précises sont confiées à des composants JavaScript — un module de réservation, une recherche instantanée, une visualisation de données. Vous gardez la machinerie éditoriale et saupoudrez l’interactivité là où elle rapporte.

3½. Pas de tête du tout. Pour un contenu qui change quelques fois par mois, un générateur de site statique consommant du markdown ou l’API d’un CMS headless au build (ce que fait tak.tn) bat un CMS qui tourne en production.

Ce que le full headless coûte vraiment

Les bénéfices sont réels : les équipes front livrent dans leur propre stack, l’API force une modélisation de contenu propre, et une seule source de vérité peut servir plusieurs consommateurs (web, applis, écrans). Mais la facture arrive vite :

• Vous reconstruisez ce que Drupal vous donnait gratuitement. Aperçu, mise en page par page, menus, fils d’Ariane, redirections, metatags, changement de langue — chacun devient une discussion de conception d’API et du code front.
• L’aperçu éditorial est le gouffre classique. « Je peux voir la page avant de publier ? » est une exigence d’une ligne et une implémentation de plusieurs semaines à cheval sur deux systèmes.
• Deux pipelines, deux surfaces d’astreinte. L’invalidation de cache à travers la frontière de l’API est l’endroit où les bugs vont se cacher.
• Le SEO ne va bien que si le front rend côté serveur. Du React rendu côté client qui consomme JSON:API, c’est la recette pour transformer un site parfaitement indexable en pari sur la file de rendu de Google.

Rien de tout ça n’est une raison de ne pas le faire. Ce sont des raisons de ne pas le faire par défaut.

Les questions qui tranchent vraiment

1. Qui consomme le contenu ? Un seul site web → monolithe ou découplage partiel. Site + appli mobile + TV connectée → la couche API mérite son coût. (Un diffuseur audiovisuel est le cas d’école — c’est pour ça que l’architecture FTV a du sens.)
2. À quel point le produit est-il éditorial ? Si les éditeurs composent des pages d’atterrissage, réordonnent des blocs et attendent un aperçu WYSIWYG, le headless va vous combattre. Si le contenu est fait d’enregistrements structurés (programmes, produits, articles) rendus dans des gabarits fixes, un contrat d’API est naturel.
3. Quelle équipe avez-vous ? Le headless exige deux équipes compétentes et quelqu’un qui possède le contrat entre elles. Une équipe de trois personnes qui maintient les deux côtés d’une stack découplée va moins vite, pas plus vite.
4. Où vit l’interactivité ? Si ce sont trois widgets sur un site par ailleurs éditorial, le découplage progressif vous donne 90 % du bénéfice pour 10 % du coût.

Mes réglages par défaut

• Site éditorial, un seul canal web → Drupal monolithique, Twig moderne, cache agressif. L’ennuyeux gagne.
• Site éditorial avec des îlots de comportement applicatif → découplage partiel : Drupal continue de rendre, on monte des composants là où il faut.
• Plateforme de contenu multicanale avec un front possédé par une autre équipe → full headless, avec rendu côté serveur et aperçu éditorial budgétés dès le premier jour, pas découverts au sprint 9.
• Sites personnels et vitrines → statique, aucun CMS en production.

L’architecture est un moyen. Le test est toujours le même : les éditeurs publieront-ils plus vite, et les utilisateurs recevront-ils leurs pages plus vite ? Si un schéma d’architecture ne peut pas répondre aux deux sans rougir, c’est de la mode, pas de l’architecture.

Vous pesez cette décision pour votre propre plateforme ? Je fais des audits d’architecture — y compris un verdict honnête « restez monolithique » quand c’est la bonne réponse.