Le site du musée du Louvre se rejoue tous les cinq ans. C’est un marché public, il se gagne, il se perd. Quand j’arrive, la refonte tourne depuis un an et le code est déjà propre. Je suis alternant. J’y reste cinq ans, et j’en pars lead, en relation directe avec la cliente.
Juste avant mon départ, l’agence a regagné le marché pour cinq années de plus.
Le système
Le front est headless, découplé du CMS. L’API ne renvoie pas une page, elle renvoie un arbre de composants que le front rend récursivement. Chaque gabarit est composable : les équipes éditoriales du musée assemblent leurs pages avec les composants qu’elles veulent, sans passer par un développeur.

Cette architecture existait avant moi. Ce que j’y ai apporté, c’est le contrat qui la rend tenable dans la durée.
Un même JSON Schema décrit chaque composant des deux côtés de la frontière : celui que produit le CMS en PHP, et celui que consomme la story Storybook en React. Le schéma est distribué par un submodule Git, donc versionné et partagé entre les deux dépôts. Si le back change la forme d’un composant, le front le sait, et les tests le disent.Sans ce contrat, un rendu récursif piloté par les données devient ingérable dès que l’équipe tourne. Sur cinq ans, l’équipe tourne.
- Next.js
- Drupal headless
- JSON Schema
- submodule Git
- Storybook
- SCSS
La difficulté
On pouvait mettre un dropdown dans une FAQ, un dropdown dans un drawer, un drawer dans un dropdown. C’est le back qui décidait de l’ordre et de l’imbrication, à la contribution. En dehors des composants communs comme l’image ou le texte, tous acceptaient des enfants agnostiques : ils ne savaient ni ce qu’ils contenaient, ni ce qui les contenait.

Ça change le métier. On n’assemble plus des pages, on construit un système qui doit rester juste sous n’importe quelle composition, y compris celles que personne n’a prévues. Un composant qui marche dans la maquette mais casse à trois niveaux d’imbrication est un composant faux.
L’accessibilité sous structure imprévisible
Le site est conforme au RGAA à son niveau le plus élevé, avec un audit externe conduit par Temesis. Or une imbrication arbitraire est le pire terrain pour l’accessibilité : gestion du focus, états ARIA, pièges clavier. Personne ne peut anticiper les combinaisons.
Contrat component.schema.json
{ "properties": { "type": { "enum": ["faq", "drawer", "dropdown", "bouton"] }, "children": { "type": "array", "items": { "$ref": "#" } }n'importe quel composant, à n'importe quelle profondeur} }
API
{ "type": "faq", "children": [{ "type": "drawer", "children": [{ "type": "dropdown", "children": [{ "type": "bouton" }]}]}]}
Front
Deux principes ont suffi.
Chaque composant est responsable de son propre focus et de son propre état. Il n’a jamais besoin de connaître ni ses enfants ni son parent. Une règle correcte localement reste correcte sous n’importe quelle imbrication.
Et quand une exception demande du contexte, c’est le back qui tranche. Il connaît la page, il envoie un JSON différent. Les props sont le JSON. Aucune exception n’est codée en dur dans un composant.
Des milliers de compositions sont possibles, et le front n’en connaît aucune. Il ne rend que ce qu’on lui envoie.
L’effet de bord
Une architecture conçue pour la contribution éditoriale a produit un bénéfice qu’on n’attendait pas d’elle. Comme tout se compose à partir des mêmes composants testés, il n’existe pas de page à part qui dérive. Le site est cohérent de bout en bout au pixel près, et cette cohérence est structurelle, pas disciplinaire.
L’échelle

Quatre langues : français, anglais, espagnol, mandarin. Au moins une centaine de composants, tous testés via Storybook et leur JSON Schema. Deux développeurs front pilotés sur la dernière phase. Cinq ans.
Ce que ça prouve
Ce système, je ne l’ai pas conçu. Je l’ai tenu cinq ans, amélioré sans le casser, et j’ai été l’interlocuteur du musée jusqu’au bout, d’alternant à lead.
Puis le marché a été renouvelé. Cette signature n’est pas la mienne, et c’est ce qui en fait une preuve.

