Construire une plateforme publique cohérente avec Drupal et le Design System de l'État

Construire une plateforme publique cohérente avec Drupal et le Design System de l'État Contexte du projet

La mission s'inscrivait dans le cadre de la refonte du portail ParcoursSup, la plateforme nationale française dédiée à l'orientation et à l'admission dans l'enseignement supérieur.

Contrairement à de nombreux projets web classiques, l'objectif n'était pas uniquement de produire de nouvelles pages ou de moderniser une interface existante.

Le défi consistait à construire une plateforme publique capable de rester cohérente malgré la diversité des contenus, des parcours utilisateurs et des besoins métier.

Le projet reposait sur Drupal 10 et s'appuyait sur le Design System de l'État français (DSFR), qui imposait un cadre précis en matière d'interface, de composants et d'accessibilité.

Dans ce contexte, le rôle du développement ne se limitait pas à l'intégration visuelle.

Il fallait transformer les règles du Design System en composants Drupal réutilisables, maintenables et compatibles avec les besoins éditoriaux du portail.

Pourquoi les plateformes publiques sont différentes

Une plateforme institutionnelle n'est pas un simple site vitrine.

Elle doit répondre simultanément à plusieurs exigences :

cohérence graphique ; accessibilité ; maintenabilité ; évolutivité ; qualité éditoriale ; conformité aux standards publics.

Ces contraintes deviennent encore plus visibles lorsqu'un Design System officiel est imposé.

Le Design System ne définit pas uniquement l'apparence des écrans.

Il influence également :

la structure des composants ; l'organisation du contenu ; les comportements utilisateurs ; les règles de navigation ; les choix d'implémentation.

Le développement doit alors servir d'interface entre les exigences fonctionnelles et les contraintes du système de design.

Les contraintes du Design System de l'État

L'une des particularités du projet était l'utilisation du DSFR.

Ce système fournit un ensemble cohérent de :

composants ; règles de mise en page ; conventions visuelles ; comportements d'interface ; exigences d'accessibilité.

Mais intégrer un Design System dans Drupal ne consiste pas à copier du HTML.

La difficulté est de permettre aux équipes éditoriales de continuer à produire du contenu tout en garantissant le respect des standards définis.

Chaque composant doit donc être pensé à plusieurs niveaux :

structure Drupal ; configuration éditoriale ; template Twig ; comportement JavaScript ; intégration DSFR.

Cette logique a fortement influencé l'architecture du projet.

Une architecture orientée composants

Une part importante du travail concernait l'implémentation et la personnalisation de composants Drupal.

Les paragraphes ont joué un rôle central.

Ils permettaient de construire des pages complexes à partir d'éléments réutilisables tout en conservant une certaine autonomie éditoriale.

Cette approche présente plusieurs avantages :

réutilisation ; cohérence ; évolutivité ; réduction de la duplication.

Le même principe a été appliqué à d'autres éléments du portail, notamment :

les menus ; les méga-menus ; certains composants éditoriaux spécifiques.

L'objectif était de construire un système de composants plutôt qu'une collection de pages indépendantes.

Les formulaires comme objets métier

Le projet comportait également plusieurs formulaires avancés développés avec Webform.

Un formulaire public n'est jamais un simple ensemble de champs.

Il constitue souvent un point de contact important entre l'utilisateur et l'organisation.

Les enjeux concernaient notamment :

l'expérience utilisateur ; la qualité des données ; la validation ; l'accessibilité ; la maintenabilité.

L'utilisation de Webform permettait de bénéficier d'un socle robuste tout en ajoutant les personnalisations nécessaires.

Cette approche évitait de développer des formulaires entièrement sur mesure lorsque cela n'était pas nécessaire.

Pourquoi créer un module basé sur la State API

L'une des réalisations les plus intéressantes concernait la création d'un module Drupal personnalisé reposant sur la State API.

Le besoin était relativement simple :

centraliser plusieurs informations globales utilisées à travers le site.

Par exemple :

réseaux sociaux ; informations de contact ; éléments du footer ; contenus système ; paramètres globaux.

Plusieurs approches étaient possibles.

Ces informations auraient pu être stockées directement dans la configuration ou du contenu classique.

Le choix de la State API répondait à un besoin précis : disposer d'un mécanisme léger pour gérer certaines données globales utilisées par l'ensemble de la plateforme.

Cette décision illustre un principe fréquent dans les projets Drupal :

le choix d'une solution ne dépend pas uniquement de ce qui est techniquement possible, mais de ce qui est le plus adapté au rôle métier de la donnée.

Difficultés rencontrées

La principale difficulté concernait l'équilibre entre flexibilité et cohérence.

Les équipes éditoriales ont besoin d'autonomie.

Le Design System impose des règles.

Drupal offre de nombreuses possibilités de personnalisation.

L'enjeu était donc de construire un cadre suffisamment souple pour les contributeurs sans compromettre l'homogénéité de la plateforme.

Une autre difficulté concernait la multiplication des composants.

Sans discipline architecturale, un système de composants peut rapidement devenir difficile à maintenir.

Chaque nouveau composant doit être justifié, documenté et réutilisable.

Enfin, l'accessibilité représentait une contrainte permanente.

Dans un contexte public, elle ne peut pas être traitée comme une amélioration facultative.

Elle fait partie intégrante du produit.

Résultats obtenus

La plateforme dispose désormais :

d'une architecture de composants cohérente ; d'une meilleure réutilisation des éléments d'interface ; d'une intégration conforme au DSFR ; d'un système de formulaires maintenable ; d'une gestion centralisée de plusieurs contenus globaux ; d'une base solide pour les évolutions futures.

Plus important encore, le projet démontre qu'un Design System peut devenir un véritable levier d'industrialisation lorsqu'il est correctement intégré à l'architecture du CMS.

Enseignements Product Engineering

Cette expérience montre qu'un Design System ne concerne pas uniquement les designers.

Lorsqu'il est appliqué à grande échelle, il devient un sujet d'architecture.

Les choix réalisés dans Drupal influencent directement la capacité du système à rester cohérent dans le temps.

Elle rappelle également que les plateformes publiques sont souvent des systèmes de contenu avant d'être des applications.

Le rôle du Product Engineering consiste alors à transformer des règles de design, d'accessibilité et de gouvernance en composants réutilisables, compréhensibles et maintenables.

C'est probablement la principale leçon de cette mission : la cohérence d'une plateforme publique ne repose pas uniquement sur son apparence, mais sur la manière dont ses composants sont conçus et gouvernés.