Le client veut inverser deux blocs sur ses pages produits. Le visuel avant le texte, partout. C'est le genre de demande qu'on chiffre en fin de réunion, entre deux sujets, parce que sur un site normal c'est une modification d'affichage et c'est fini.
Sauf que la seule réponse honnête, ici, c'est : "sur combien de pages ?"
Et cette question surprend tout le monde, à commencer par celui qui la pose. Parce qu'elle ne devrait pas exister. Une mise en page, c'est censé être un gabarit, un endroit unique qu'on modifie une fois.
Layout Builder n'est pas en cause. C'est un bon module, il fait ce qu'on lui demande, et il a rendu possible des choses qui demandaient trois modules contrib et un thème sur mesure il y a dix ans. Le sujet est ailleurs : c'est une case cochée deux ans plus tôt, par quelqu'un qui répondait à une demande parfaitement légitime, et ce que cette case a déplacé.
Deux Layout Builder, et un seul se maintient bien
Il faut commencer par là, parce que tout le reste en découle.
Le layout par défaut, celui qu'on configure dans l'écran "Gérer l'affichage" d'un type de contenu, est de la configuration. Il s'exporte, il se versionne, il se déploie comme le reste. Une modification s'applique à tous les contenus du type d'un coup. C'est sain, c'est prévisible, et ça se maintient très bien.
Les overrides, c'est l'option "autoriser chaque contenu à personnaliser sa mise en page". Dès qu'un contributeur touche à l'agencement d'une page, l'arrangement de cette page-là part vivre dans le contenu, dans un champ porté par l'entité, nommé layout_builder__layout.
Ça ressemble à un détail d'implémentation. C'est une bascule d'architecture.
La configuration décrit un modèle. Le contenu décrit un cas. En déplaçant la mise en page vers le contenu, on transforme une décision unique en des centaines de décisions indépendantes, chacune modifiable par quelqu'un d'autre, et aucune visible depuis un seul endroit.
Tout ce qui suit est une conséquence de cette phrase.
Ce qu'on ne peut plus faire globalement
C'est le coût numéro un, et sur les projets qu'on m'apporte, c'est celui qui n'a jamais été chiffré au moment du choix. Ce qui se comprend : il ne se manifeste pas avant deux ans.
Modifier un composant ne se propage plus. Les pages qui ont personnalisé leur agencement gardent le leur, et elles ont raison : c'est exactement ce qu'on leur a demandé de faire. Le changement global devient une reprise page par page.
Pour une agence, la traduction est brutale. "Changer un composant" cesse d'être une tâche unitaire chiffrable. Le devis dépend du nombre de pages personnalisées, ce nombre n'est écrit nulle part, et la première étape du chiffrage consiste à aller le compter. Ce qui veut dire qu'on ne peut plus répondre en réunion.
Et le comptage lui-même se paie : il faut interroger la base sur le contenu du champ de layout, distinguer les pages réellement personnalisées de celles qui ont juste ouvert l'éditeur, et croiser avec ce qu'on veut modifier.
Sur un site de trente pages, c'est une matinée. Sur un site de deux mille, c'est un sujet en soi.
Le déploiement qui ne voit pas la moitié du site
Voilà le coût le plus contre-intuitif, et il frappe en priorité les équipes qui travaillent proprement.
Une chaîne de déploiement sérieuse repose sur l'export et l'import de configuration. On modifie en local, on exporte, on versionne, on importe en production. Ce mécanisme ne voit pas les overrides : ils sont du contenu, dans la base, avec les noeuds.
Conséquence opérationnelle immédiate : la préproduction et la production divergent structurellement, et elles divergent toutes seules, sans que personne ne fasse d'erreur. "Je reproduis le problème en local" cesse d'être une opération de code pour devenir une opération de synchronisation de base de données. Sur un site avec des données personnelles, ça veut aussi dire une procédure d'anonymisation à chaque fois.
Le signe que le problème n'est pas dans ma tête : à peu près tous les modules qui tentent de déplacer du contenu entre environnements ont une issue ouverte sur ce point précis. Quand plusieurs équipes indépendantes écrivent un contournement pour la même chose, ce n'est plus un cas particulier.
C'est aussi le genre de découverte qu'on fait en reprenant un projet développé par une autre équipe : la chaîne de déploiement a l'air impeccable, et il manque la moitié de ce qui s'affiche.
Le module qu'on ne peut plus enlever
Un jour, l'équipe décide de sortir de Layout Builder. Nouveau thème, refonte du modèle de contenu, ou simplement le constat que ça coûte plus que ça ne rapporte.
Drupal refuse. Et il le dit comme ça :
The Layout Section field type is used in the following field: node.layout_builder__layout
You must revert all customized layouts of this display before you can disable this option.
La case est grisée. Pour la décocher, il faut annuler la personnalisation de toutes les pages concernées, une par une. Au moment où j'écris ces lignes, il n'existe pas de mécanisme intégré pour le faire en masse : une issue du coeur propose un bouton d'annulation groupée, elle est ouverte depuis des années et toujours pas livrée.
Sur un site à quelques dizaines de pages, c'est une matinée pénible. Au-delà, c'est un chantier, ou un script écrit pour l'occasion, avec la prudence qui va avec puisqu'on supprime définitivement du travail éditorial.
Il y a un enseignement général là-dedans, et il dépasse largement Layout Builder : le coût de sortie fait partie du coût de la décision. On compare les modules sur ce qu'ils permettent de faire. On les compare rarement sur ce qu'ils coûtent à quitter, et c'est pourtant le seul chiffre qu'on est certain de payer un jour.
Les petits frottements qui s'additionnent
Ceux-là ne décident de rien tout seuls. Ils s'accumulent, et ils expliquent pourquoi la TMA d'un site sous Layout Builder coûte plus cher que sa jumelle sans.
Les blocs custom deviennent des dépendances dures. Un layout enregistre l'identifiant du plugin de bloc qu'il place. Renommez ce bloc, retirez-le, et vous laissez des références orphelines dans des pages que vous découvrirez en production, souvent des mois plus tard, souvent par un utilisateur. La règle de méthode qui en découle est simple : la suppression d'un bloc placé dans des layouts n'est jamais une suppression. C'est une migration.
Les modifications de mise en page en attente. La mise en page est versionnée avec le contenu, ce qui est logique et souhaitable. Le frottement connu est plus étroit et il vaut la peine d'être dit précisément : une session d'édition de layout laissée en cours peut réapparaître après un retour à une révision antérieure, avec un message de modifications non enregistrées qui n'a plus de sens pour l'éditeur. C'est une issue ouverte du coeur, correctif proposé, pas encore livré à ce jour. Rien de dramatique, mais c'est le genre de bizarrerie qui génère un ticket de support et vingt minutes d'explication.
Les droits. Qui a le droit de personnaliser, et sur quels types de contenu ? La question a l'air administrative, elle est architecturale : chaque personne autorisée est une source supplémentaire de divergence entre les pages. Un site où trois personnes peuvent personnaliser et un site où trente le peuvent n'ont pas le même coût de maintenance, à fonctionnalités identiques. Et c'est un symptôme qu'on retrouve derrière beaucoup de pannes Drupal : le module n'a pas lâché, c'est l'usage qu'on en a fait pendant des années qui a dérivé.
Où Layout Builder est franchement le bon choix
Je serais malhonnête de m'arrêter là. Layout Builder résout un vrai problème, et il le résout bien dans trois situations.
Une poignée de pages éditoriales tenues par une équipe qui en a réellement besoin : accueil, landing de campagne, page institutionnelle qui change deux fois par an. Le reste du site n'y touche pas, le nombre de pages personnalisées reste connu, et tous les coûts décrits plus haut restent gérables parce qu'ils portent sur dix pages.
Les layouts par défaut seuls, sans jamais ouvrir les overrides. On garde toute la souplesse de composition, on garde la mise en page dans la configuration, on garde le déploiement propre. C'est de loin le mode le plus économique, et à mon sens le plus sous-utilisé : sur les sites que je reprends, les overrides sont le plus souvent activés par réflexe, parce que la case est là, sans que le besoin correspondant ait jamais été formulé.
Les overrides ouverts sur un seul type de contenu, choisi, identifié, et dont on sait qu'il restera peu peuplé. C'est le compromis raisonnable quand le besoin de liberté est réel mais circonscrit.
Le message n'est donc pas "fuyez Layout Builder". Il est : ouvrez les overrides en sachant ce que vous signez, et écrivez-le quelque part, parce que celui qui reprendra le site plus tard ne saura pas que c'était une décision.
Et les alternatives, alors ?
La question tombe toujours à ce moment-là, autant y répondre.
Les paragraphes ont un coût différent, pas moindre. Prolifération d'entités, aucune réutilisation d'un composant entre deux pages, édition lourde dès que l'imbrication grimpe. Ils ont en revanche un avantage réel sur le sujet qui nous occupe : ce sont des entités de contenu classiques, que les outils de déploiement de contenu savent manipuler.
Un jeu de composants figés en champs est moins souple et nettement moins cher à tenir. Il faut le proposer sérieusement quand on écoute le besoin réel et qu'on entend "trois gabarits de page". Ça m'est arrivé plusieurs fois, et le client était soulagé qu'on lui propose plus simple.
Le compromis qui marche le plus souvent dans les projets que j'accompagne : des layouts par défaut soignés, plus un seul type de contenu ouvert aux overrides pour les pages de campagne. On récupère l'essentiel du bénéfice pour une petite fraction du coût.
Si c'est déjà en place : trois lignes à mettre au contrat
Quand on hérite d'un site où les overrides sont ouverts depuis longtemps, il est trop tard pour la décision. Il n'est pas trop tard pour le contrat de maintenance.
Le recensement. Combien de contenus ont une mise en page personnalisée, et sur quels types. Tant que ce nombre est inconnu, aucun devis d'évolution d'affichage n'est fiable, et c'est vous qui absorberez l'écart.
La règle sur les blocs. Aucun bloc placé dans des layouts n'est supprimé ni renommé sans recherche préalable de ses usages. Ça tient en une ligne dans le processus de revue de code.
La ligne dans le devis. "Modifier un composant" ne se chiffre plus comme une tâche unitaire. Dites-le au client au moment de la signature du contrat, quand c'est une information technique. Après, c'est une excuse.
Ce qui coûte cher, c'est de quitter
Layout Builder ne coûte pas cher à installer. Il coûte cher à quitter.
C'est le genre de décision qu'on prend en dix secondes dans un écran de configuration, parce que la case est là, qu'elle a l'air anodine, et que le client a demandé "de la souplesse". Puis on la paie pendant trois ans, en petites monnaies, sur chaque évolution d'affichage.
C'est exactement pour ça qu'elle mérite dix minutes de discussion avant. Dix minutes avec le client, pour lui demander combien de pages il compte réellement personnaliser. Dans les projets que j'accompagne, la réponse est presque toujours très en dessous de ce que la case laisse faire.