Comment proposer à deux types d'utilisateurs aux besoins distincts — site builder et éditeur — des outils adaptés à leur niveau, sans sacrifier la cohérence du design ni la liberté éditoriale.
Contexte du projet
Le projet consiste en la création du site institutionnel de Conserto, société de conseil et d'expertise IT, pour remplacer son site WordPress existant. Le périmètre fonctionnel attendu au démarrage couvre trois axes : la présentation de la société et de ses valeurs, l'exposition de ses services, et la publication de contenus chauds.
Le projet est mené seul, en deux mois, dans un environnement de développement local ddev. L'absence d'équipe impose une rigueur architecturale particulière : chaque choix technique doit être documentable, maintenable et transmissible sans friction.
Objectif central
Au-delà du livrable fonctionnel, l'ambition du projet est de valider une approche architecturale déjà présentée lors du Drupal BarCamp de Perpignan : construire un système de pages modulables reposant sur des design patterns, accessible à deux types de profils distincts avec des interfaces et des niveaux de complexité adaptés à chacun.
Pourquoi ce choix de stack ?
Drupal 11 est retenu pour sa maturité sur la gestion des types de contenu et ses capacités d'affichage configurable. Le module ui_patterns, combiné à ui_suite, permet de connecter un design system à la couche de rendu Drupal sans duplication de logique. Les Single Directory Components (SDC) apportent une encapsulation propre des composants Twig. Paragraphs sert de brique de composition pour la couche éditoriale. Bootstrap fournit le référentiel visuel, issu d'une maquette Figma conçue pour le design system dès le départ.
Aucune intégration automatisée n'est mise en place entre Figma et le code — la maquette sert de référence visuelle et de documentation de design, pas de source de vérité synchronisée.
Architecture Drupal 11 : deux couches sur un socle design system commun
Le projet repose sur une séparation nette entre la configuration du système — réservée au site builder — et la composition des pages — accessible à l'éditeur. Cette séparation n'est pas seulement organisationnelle : elle est inscrite dans l'architecture technique elle-même.
Le socle : design system et composants SDC
Le point de départ est une maquette Figma conçue en amont selon une logique de design system : les éléments visuels y sont pensés comme des composants réutilisables, organisés par niveaux de granularité. Cette maquette ne pilote pas le code de manière automatisée, mais elle sert de référence stable tout au long du développement.
Côté code, les composants sont implémentés sous forme de Single Directory Components (SDC) avec des templates Twig. Chaque composant regroupe dans un même répertoire son template, sa feuille de style, et sa définition de schéma.
La couche site builder
Le module ui_patterns permet de mapper les composants SDC sur les modes d'affichage des types de contenu Drupal. Le site builder configure depuis le back-office comment chaque type de contenu doit être rendu selon son contexte. Ce travail est réalisé une fois, en amont. Les rendus sont ensuite figés.
La couche éditeur
Des méta-composants construits via Paragraphs agrègent plusieurs composants SDC dans une configuration préétablie et n'exposent à l'éditeur qu'un sous-ensemble d'options ciblées. Un mapping est fait entre des composants SDC et un Paragraph pour fournir une interface de configuration à ce méta-composant.
L'interface d'édition front
L'éditeur compose ses pages directement depuis l'interface front du site. Il voit le rendu réel de sa page au fur et à mesure qu'il assemble ses méta-composants, ce qui supprime l'écart entre saisie et résultat visuel.
Le site builder Drupal : configurer les rendus avec ui_patterns
Le site builder est le premier maillon de la chaîne. Son travail est invisible pour l'utilisateur final, mais il conditionne la cohérence de tout ce que l'éditeur peut produire ensuite.
Le persona site builder
Dans ce projet, le site builder est un profil technique — développeur ou intégrateur — capable de naviguer dans l'administration Drupal et de comprendre la relation entre types de contenu, champs et modes d'affichage. Il n'édite pas de contenu : il configure le système qui permettra à d'autres d'en créer.
Son objectif est de poser des rails. Une fois son travail terminé, les éditeurs disposent d'un environnement balisé où les dérives visuelles sont structurellement impossibles.
Le workflow de configuration
Ce que ui_patterns apporte concrètement
Le module ui_patterns est le pivot de la couche site builder. Il introduit une abstraction entre les composants visuels et la couche de données Drupal. Modifier l'apparence d'un composant ne nécessite pas de toucher à la configuration des modes d'affichage, et inversement.
La frontière avec la couche éditeur
Le site builder définit quels composants existent, comment ils se comportent et dans quel contexte ils apparaissent. L'éditeur compose des pages, mais ne peut pas modifier le comportement des composants qu'il utilise. Cette frontière est ce qui rend le système scalable.
L'éditeur Drupal : composer des pages avec des méta-composants Paragraphs
La couche éditeur est le point de contact entre le système et les personnes qui publient du contenu au quotidien. L'enjeu est double : leur donner suffisamment de liberté pour produire des pages variées, sans leur imposer une complexité qui ralentirait leur travail.
Le persona éditeur
L'éditeur sur ce projet est un profil webmaster — à l'aise avec les outils numériques, habitué à gérer du contenu en ligne, mais non développeur. Son périmètre est la composition de pages : assembler des blocs, renseigner des champs, choisir parmi des options présentées clairement.
Sur ce projet, les utilisateurs finaux étaient déjà familiers de la technologie Drupal. Cela a facilité la prise en main, mais l'architecture a été pensée pour ne pas en dépendre.
-
Ajouter, modifier des sections et des composants avec rendu -
Modal de section avec choix de colonnage -
Configuration de l'affichage d'une section -
Choix d'un composant à ajouter parmi une liste -
Configuration de la donnée et des paramètres du composant -
Rendu de la configuration de deux composants en 2 colonnes
Le principe des méta-composants
Le méta-composant est la brique centrale de la couche éditeur. Il s'agit d'un type Paragraph qui agrège un ou plusieurs composants SDC dans une configuration préétablie, et qui expose à l'éditeur uniquement les options pertinentes pour son usage. Le mapping entre les props du composant SDC et les champs du Paragraph est géré via ui_patterns.
La règle de conception : plusieurs petits plutôt qu'un grand
Le choix structurant de la couche éditeur est de multiplier les méta-composants ciblés plutôt que de proposer un composant unique et flexible.
Exemples de méta-composants
-
3 composants exemples: Callout et cards -
Exemple de variations d'affichage d'un composant média avec ses différentes options -
Exemple de composant d'affichage texte et média avec différentes options de configurations
Bilan technique : ui_patterns, SDC et Paragraphs à l'épreuve du projet
Deux mois de développement solo permettent de dresser un bilan honnête : les choix architecturaux ont globalement tenu leurs promesses, mais certaines frictions techniques ont nécessité des arbitrages que tout projet similaire devrait anticiper.
- Cohérence visuelle garantie par la séparation des responsabilités
- Prise en main éditeur sans formation
- Composants SDC maintenables et découplés
- Chaîne Figma → SDC → ui_patterns homogène
- Interface site builder alourdie par le volume de champs exposés
- Risque de sur-personnalisation des composants
- Courbe d'apprentissage sur le mapping SDC ↔ Paragraph
Ce qui a bien fonctionné
La séparation entre couche site builder et couche éditeur a tenu sur toute la durée du projet. Le fait de l'avoir inscrite dans l'architecture dès le départ a évité les dérives.
La chaîne Figma → SDC → ui_patterns s'est révélée cohérente. Partir d'un design system pensé en amont a évité les allers-retours habituels entre intégration et design.
Les frictions rencontrées
Le principal point de résistance technique a concerné ui_patterns. Le module introduit une couche d'abstraction puissante, mais dont la configuration devient rapidement complexe lorsque le nombre de composants et de modes d'affichage augmente. Il faut alors bien s'assurer de rester dans l'objectif de proposer des composants utilisables, et qui ne contiennent pas trop de personnalisation, ce qui les rend complexes à maintenir.
Des problématiques de performances ont également été identifiées, liées au volume de champs disponibles qui alourdissent l'interface pour le site builder. Ces problèmes sont restés contenus dans le périmètre de ce projet, mais ils constituent un signal à prendre en compte pour des projets architecturés différemment.
Enfin, le mapping entre composants SDC et Paragraphs représente une courbe d'apprentissage non négligeable pour tout développeur qui intégrerait le projet après coup.
Ce qui serait fait différemment
La première chose à mettre en place dès le départ serait un outil de documentation des composants — Storybook ou équivalent — pour centraliser les décisions de mapping et rendre le système transmissible sans effort d'explication.
Une réflexion plus précoce sur la stratégie de cache Drupal permettrait également d'anticiper les enjeux de performance. Enfin, documenter formellement la frontière site builder / éditeur renforcerait la durabilité de l'approche au-delà du projet initial.
Ce que ce projet apprend sur la conception de sites Drupal modulables
Au-delà des choix techniques, ce projet valide une façon de penser l'architecture d'un site CMS : non pas comme une liste de fonctionnalités à assembler, mais comme un système conçu pour deux personas distincts, avec des niveaux d'abstraction adaptés à chacun.
Ce que ce projet ouvre comme perspectives
L'approche validée ici est reproductible. Elle peut être documentée sous forme de kit de démarrage pour des projets futurs de même nature, à condition d'y adjoindre dès le départ la documentation des composants qui manquait ici.
La question qui reste ouverte est celle de la scalabilité : jusqu'où cette approche tient-elle sur un site avec un catalogue de composants large, une équipe de plusieurs éditeurs, et des besoins évolutifs ?
Un système, deux regards : ce que la séparation des personas change à l'architecture
Ce REX ne porte pas sur un site. Il porte sur une façon de concevoir un système éditorial : en partant des personnes qui vont l'utiliser, en leur donnant des outils calibrés à leurs besoins, et en inscrivant cette distinction dans l'architecture elle-même.
Ce que le projet démontre
Le site conserto.pro est le support de validation d'une approche qui dépasse le projet lui-même. En deux mois, seul, il a été possible de livrer un site institutionnel complet, cohérent visuellement, et dont l'interface d'édition est suffisamment intuitive pour être prise en main sans formation.
La chaîne Figma → SDC → ui_patterns → Paragraphs a tenu sur toute la durée du projet. Chaque maillon a joué son rôle sans empiéter sur les autres.
Ce que cela signifie pour un projet similaire
Si vous envisagez un site institutionnel sur Drupal avec des besoins d'autonomie éditoriale, les choix faits ici sont reproductibles. Ce qui demande le plus d'investissement n'est pas technique : c'est la phase de conception des méta-composants, qui exige de bien comprendre les besoins des éditeurs avant d'écrire la première ligne de configuration.
Ce projet a été mené seul, en deux mois, sans outil de documentation des composants et sans intégration automatisée avec Figma. Ces deux manques sont identifiés. Les combler dès le départ sur un projet d'équipe ou à longue durée de vie est la condition pour que l'approche reste transmissible et maintenable dans le temps.
Étude de cas réalisée par l'architecte technique du projet. Site disponible à l'adresse conserto.pro.