Entré chez Mazarine en alternance en 2020, j’ai d’abord contribué au frontend de Louvre.fr. Mon rôle s’est élargi jusqu’au pilotage technique du site sur mes deux dernières années, avant mon départ en 2025.
Cadrer les évolutions avec le musée
Avec mon interlocutrice au musée, le Product Owner et les designers, je précisais les besoins, discutais les choix d’interface et proposais des solutions adaptées au temps disponible. J’estimais et répartissais ensuite le travail, relisais le code et participais à la recette technique, puis aux vérifications après déploiement.
Les parcours accessibles par QR code en sont un exemple : depuis une œuvre dans le musée, le visiteur rejoint un parcours sur le site. J’ai participé au cadrage du besoin et de l’expérience utilisateur, estimé le travail et dirigé l’implémentation frontend et backend en définissant le contrat d’API.
Sur la dernière phase, je dirigeais deux développeurs frontend et coordonnais le travail avec le lead backend. Je contribuais aussi ponctuellement à Drupal et aux revues de code backend.
Des pages assemblées par le musée
La refonte avait commencé avant mon arrivée. Elle reposait sur une architecture headless : le CMS Drupal gérait les contenus, tandis que le frontend React les affichait. L’API transmettait un arbre de composants que le frontend parcourait pour construire la page.
Les équipes éditoriales pouvaient ainsi assembler leurs pages à partir des composants disponibles. J’ai fait évoluer cette architecture et ses outils, notamment en structurant les contrats partagés entre Drupal et React.
Un contrat JSON Schema décrivait les données attendues pour chaque composant. Le même schéma servait côté Drupal et dans les exemples et tests Storybook côté React. Les schémas vivaient dans le dépôt backend, intégré comme sous-module Git au dépôt frontend : les deux équipes travaillaient à partir d’une version commune du contrat.Ce contrat rendait les échanges front/back explicites, y compris pour les développeurs qui rejoignaient le projet.
J’ai créé un générateur Hygen pour produire les squelettes frontend et backend et leur schéma. Les revues de code vérifiaient ensuite le respect du contrat, les conventions et la réutilisation des composants. J’ai repris cet outil sur Orient Express.
Maîtriser les composants imbriqués
Un menu déroulant pouvait apparaître dans une FAQ ou un panneau latéral, lui-même placé dans un autre composant. L’ordre et l’imbrication étaient configurés dans le CMS. À l’exception des éléments simples comme le texte ou l’image, les composants pouvaient accueillir des enfants sans dépendre d’un assemblage précis.
Cette souplesse exigeait de vérifier les composants au-delà de la maquette initiale. Un comportement correct dans une page simple pouvait poser problème après plusieurs niveaux d’imbrication, notamment pour la navigation au clavier.
L’accessibilité à chaque niveau
Le travail d’accessibilité s’appuyait sur un audit externe conduit par Temesis. Nous traitions notamment la gestion du focus, les états ARIA et les situations où la navigation au clavier pouvait se bloquer.
Contrat component.schema.json
{ "properties": { "type": { "enum": ["faq", "drawer", "dropdown", "bouton"] }, "children": { "type": "array", "items": { "$ref": "#" } }un composant peut contenir d’autres composants} }
API
{ "type": "faq", "children": [{ "type": "drawer", "children": [{ "type": "dropdown", "children": [{ "type": "bouton" }]}]}]}
Front
Chaque composant gérait son focus et ses états. Nous vérifiions son comportement isolément, puis dans une page complète. Les contrôles étaient principalement manuels : clavier, lecteur d’écran ponctuel, agrandissement du texte et espacements.
Quand un comportement dépendait du contexte de la page, le backend transmettait les données correspondantes. Le frontend conservait ainsi des composants réutilisables, sans multiplier les variantes propres à chaque page.
Réutiliser les composants dans la durée
Les mêmes composants servaient à construire des pages très différentes. Une correction de style ou d’accessibilité pouvait donc bénéficier à l’ensemble de leurs usages.
Certains nouveaux gabarits pouvaient être assemblés sans développement frontend supplémentaire. Lors des estimations Scrum, leur part frontend pouvait alors être chiffrée à zéro. La configuration et la validation restaient nécessaires.
Une base commune à quatre langues
Pendant ma mission, le site couvrait le français, l’anglais, l’espagnol et le mandarin, avec une centaine de composants au moins. Storybook et les contrats JSON Schema servaient de base à leur vérification.
Ce que je retiens
Cette mission m’a fait passer du développement frontend au pilotage technique d’un site dans la durée. Je reliais les besoins du musée aux choix de composants, aux contrats d’API et au travail des développeurs.
Le système partagé permettait à l’équipe de faire évoluer le site tout en réutilisant les composants existants. Cette expérience m’a aussi appris à mesurer le coût de la composition, un point que j’ai pris en compte sur Orient Express.
