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

Construire une plateforme publique ne consiste pas seulement à publier des pages.

Dans un environnement institutionnel, chaque évolution doit respecter un cadre : cohérence visuelle, accessibilité, gouvernance éditoriale, continuité de service et maintenabilité.

La refonte du portail Parcoursup s'inscrivait dans cette logique.

Drupal était le socle technique. Le Design System de l'État français donnait le cadre d'interface. Mais le vrai sujet était ailleurs : comment transformer ces contraintes en une plateforme durable, cohérente et capable d'évoluer ?

Une plateforme publique durable ne repose pas uniquement sur son apparence. Elle repose sur la manière dont ses composants, ses contenus et ses règles sont conçus pour rester cohérents dans le temps.

Contexte

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

Le projet devait répondre à des contraintes fortes :

• un cadre visuel institutionnel défini par le Design System de l'État ;
• des exigences d'accessibilité élevées ;
• une forte diversité de contenus et de parcours ;
• une gouvernance éditoriale à maintenir dans le temps ;
• une plateforme utilisée à grande échelle ;
• une base technique appelée à évoluer.

L'objectif n'était donc pas seulement de moderniser une interface.

Il fallait construire une architecture capable de faire cohabiter besoins métier, règles publiques, autonomie éditoriale et cohérence globale.

Les exigences d'une plateforme publique

Une plateforme publique est différente d'un site classique.

Elle doit être lisible, accessible, stable et compréhensible par des publics très variés.

Elle doit aussi permettre à plusieurs équipes de publier ou faire évoluer des contenus sans dégrader l'expérience globale.

Cela crée plusieurs exigences simultanées :

• cohérence graphique ;
• accessibilité ;
• clarté des parcours ;
• qualité éditoriale ;
• réutilisabilité ;
• maintenabilité ;
• capacité à évoluer sans rupture.

Ces exigences ne peuvent pas être traitées séparément.

Une décision de composant influence la publication. Une décision éditoriale influence l'interface. Une contrainte d'accessibilité influence la structure technique. C'est précisément là que le sujet devient Product Engineering.

Le rôle du Design System

Le Design System de l'État ne définit pas seulement une apparence.

À cette échelle, il devient un cadre de conception.

Il impose des règles sur :

• la structure des composants ;
• les comportements d'interface ;
• les conventions visuelles ;
• la lisibilité ;
• les états interactifs ;
• l'accessibilité ;
• la cohérence entre pages.

L'enjeu n'était donc pas de copier des fragments HTML dans Drupal.

Il fallait traduire le Design System en composants éditoriaux réutilisables, compréhensibles par les équipes et compatibles avec les besoins réels du portail.

Cette traduction est une décision d'architecture.

Les contraintes d'architecture

Le risque principal, dans ce type de projet, est de construire une collection de pages ou de composants spécifiques.

Cela peut fonctionner à court terme, mais la plateforme devient rapidement difficile à maintenir.

Chaque exception crée un coût futur :

• divergence visuelle ;
• duplication de structure ;
• comportements incohérents ;
• difficulté à corriger globalement ;
• risque d'écart avec le Design System ;
• complexité pour les équipes éditoriales.

L'architecture devait donc éviter deux excès.

D'un côté, elle ne devait pas enfermer les contributeurs dans un système trop rigide. De l'autre, elle ne devait pas laisser chaque page devenir un cas particulier.

Le bon équilibre consistait à créer un cadre de composants suffisamment structuré pour garantir la cohérence, mais suffisamment souple pour couvrir les besoins métier.

Les décisions de Product Engineering

Plusieurs décisions ont structuré le projet.

Construire un système de composants

Les composants Drupal devaient correspondre à des usages réels du portail.

L'objectif n'était pas de multiplier les variantes. Il était de créer des blocs réutilisables, alignés avec le Design System, capables de composer des pages différentes sans perdre la cohérence d'ensemble.

Cette logique permet de passer d'une production page par page à une production par système.

Encadrer l'autonomie éditoriale

Les équipes éditoriales ont besoin d'autonomie.

Mais cette autonomie doit s'exercer dans un cadre. Sans règles, la cohérence visuelle et l'accessibilité se dégradent progressivement.

Le travail consistait donc à donner des possibilités de composition sans transformer chaque choix éditorial en risque de divergence.

Centraliser les contenus globaux

Certains contenus ou paramètres sont utilisés sur l'ensemble du portail : footer, informations de contact, réseaux sociaux, pages système, éléments transverses.

Les centraliser évite les duplications, facilite les mises à jour et réduit les incohérences.

Ce type de décision paraît simple, mais il a un impact direct sur la maintenabilité.

Préserver l'accessibilité comme contrainte produit

Dans un contexte public, l'accessibilité n'est pas une amélioration facultative.

Elle fait partie du produit.

Les composants doivent donc être conçus pour respecter les règles attendues dès leur conception, et pas corrigés tardivement après intégration.

Drupal comme moyen, pas comme sujet

Drupal a été utile parce qu'il permettait de structurer le contenu, de construire des composants éditoriaux et d'organiser la gouvernance du portail.

Mais le sujet principal n'était pas Drupal.

Le sujet principal était la capacité à traduire des contraintes institutionnelles en architecture maintenable.

Les Paragraphs, les menus, les méga-menus, les formulaires ou les contenus globaux n'ont de valeur que s'ils servent un objectif produit :

• rendre la publication plus fiable ;
• éviter la duplication ;
• préserver la cohérence ;
• faciliter les évolutions ;
• soutenir l'accessibilité ;
• réduire le coût de maintenance.

La technologie devient alors un support de gouvernance, pas une finalité.

Les formulaires et points de contact

Les formulaires publics ne sont jamais de simples assemblages de champs.

Ils constituent des points de contact entre une institution et ses usagers.

Ils doivent donc être pensés avec plusieurs contraintes :

• compréhension ;
• accessibilité ;
• validation ;
• qualité des données ;
• maintenabilité ;
• cohérence avec le reste du portail.

Le choix n'était pas de développer du spécifique partout.

L'enjeu était d'utiliser les bons socles, puis de personnaliser uniquement ce qui était nécessaire pour répondre aux besoins métier.

Construire une plateforme durable

La durabilité d'une plateforme publique dépend de sa capacité à évoluer sans se fragmenter.

Cela demande une discipline d'architecture :

• limiter les composants redondants ;
• documenter les usages attendus ;
• centraliser ce qui doit l'être ;
• garder des règles de composition claires ;
• vérifier l'accessibilité en continu ;
• distinguer besoin métier réel et exception ponctuelle.

Une plateforme durable n'est pas celle qui prévoit tous les cas dès le départ.

C'est celle qui offre un cadre robuste pour absorber les évolutions futures sans perdre sa cohérence.

Les difficultés rencontrées

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

Les métiers ont besoin de couvrir des cas variés. Le Design System impose des règles. Drupal offre de nombreuses possibilités de configuration. Sans arbitrage, ces trois dimensions peuvent tirer le système dans des directions différentes.

Une autre difficulté concernait la multiplication des composants.

Chaque nouveau composant doit être justifié. S'il ne correspond pas à un usage durable, il augmente la charge de maintenance sans créer suffisamment de valeur.

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

Elle oblige à penser les composants comme des objets complets : structure, contenu, comportement, état, navigation et usage réel.

Ce que je ferais différemment aujourd'hui

Avec le recul, je renforcerais encore plus tôt certains éléments de gouvernance.

Par exemple :

• cartographier les familles de composants dès les premières phases ;
• documenter les règles d'usage éditorial ;
• définir plus clairement les critères de création d'un nouveau composant ;
• formaliser les cas où une exception est acceptable ;
• relier systématiquement chaque composant à une contrainte d'accessibilité et de maintenance.

Ces ajustements n'auraient pas changé l'orientation du projet.

Ils auraient surtout permis de rendre certains arbitrages plus explicites et plus faciles à partager dans le temps.

Les enseignements Product Engineering

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

Lorsqu'il est appliqué à l'échelle d'une plateforme publique, il devient un sujet d'architecture, de gouvernance et de maintenance.

La valeur ne vient pas seulement de la conformité visuelle.

Elle vient de la capacité à transformer des règles de design, d'accessibilité et de contenu en composants réutilisables, compréhensibles et durables.

Dans ce contexte, le Product Engineering consiste à faire tenir ensemble :

• les besoins métier ;
• le cadre institutionnel ;
• l'expérience utilisateur ;
• l'accessibilité ;
• l'architecture de contenu ;
• la maintenabilité ;
• l'évolutivité de la plateforme.

Ce que je retiens aujourd'hui

Le principal enseignement de cette mission est qu'une plateforme publique durable se construit par contraintes.

Ces contraintes ne sont pas des freins lorsqu'elles sont bien intégrées. Elles deviennent un cadre qui aide à produire de la cohérence, de la qualité et de la maintenabilité.

Drupal et le Design System de l'État ont fourni les moyens.

Le vrai sujet était la conception d'une plateforme publique capable de rester cohérente dans un environnement fortement normé.