Quand j’ai rejoint Maisons du Monde, les équipes produits, design et tech travaillaient déjà avec rigueur sur plusieurs fronts en parallèle : évolution des parcours e-commerce, refonte du site, déploiement de nouvelles fonctionnalités… Mais comme dans beaucoup d’entreprises en croissance, les composants d’interface étaient développés au fil des besoins, sans encore de système centralisé ni de référentiel commun.
Il ne s’agissait donc pas de repartir de zéro, mais plutôt de rassembler, organiser et aligner les efforts déjà en cours. Ma mission a été de poser les fondations d’un Design System global pour accompagner cette dynamique de structuration, tout en facilitant la collaboration entre designers, développeurs, PO et autres parties prenantes.
Cela a impliqué la création d’une bibliothèque de composants partagés, bien sûr, mais aussi la mise en place d’un langage commun, d’une documentation détaillée, et surtout d’un cadre organisationnel pérenne, autrement dit : du Design Ops.
Le Design System : une collaboration essentielle entre designers et développeurs
1. Poser les bases : construire un langage commun
Avant de démarrer la production du Design System en tant que tel, nous avons pris le temps de poser des fondations solides. La première étape a été de clarifier un langage partagé entre les équipes design et développement.
En effet, comme souvent dans les organisations matures, chaque équipe avait déjà ses conventions, ses habitudes de nommage et ses façons de structurer l’interface. Mais ces logiques internes n’étaient pas toujours alignées entre métiers, ce qui pouvait parfois créer des incompréhensions ou des doublons.
Nous avons donc organisé plusieurs échanges et ateliers pour :
- Identifier les divergences de vocabulaire ou d’interprétation,
- Définir ensemble une terminologie cohérente et transversale,
- Poser les bases d’une grille de lecture commune pour tous les composants.
Ce travail nous a permis de formaliser un glossaire vivant, intégré à la documentation, qui a facilité les échanges dès les premières étapes de conception.
2. Poursuivre les fondations : Penser une structure cohérente pour une intégration fluide
Prenons un exemple visuel simple : le jeu Tetris. À première vue, tout semble évident. Mais imaginez maintenant que chaque pièce soit légèrement différente selon qu’elle provienne de l’univers du design ou du développement. Résultat : difficile de remplir correctement le gabarit.
Dans notre cas, le rectangle gris en pointillés représente une structure cible — un gabarit commun que nous devons tous viser. Les blocs de Tetris, eux, symbolisent les composants UI, dessinés dans Figma d’un côté, codés en Vue de l’autre. S’ils ne sont pas construits avec les mêmes règles, les mêmes proportions ou les mêmes comportements attendus, l’intégration devient vite un casse-tête.
Ce désalignement, souvent invisible au départ, peut générer des écarts significatifs : des boutons qui ne réagissent pas comme prévu, des espacements incohérents, ou des logiques de hiérarchie visuelle qui se perdent. Pour l’éviter, nous avons posé dès le début des fondations communes, avec une modélisation symétrique pensée à la fois pour le design et pour le code.
L’objectif était clair : réduire les écarts d’interprétation et faciliter l’intégration, en partant d’une base partagée, lisible et scalable pour tous.
Le Design System : une arborescence fonctionnelle et une sémantique précise
Le Design System chez Maisons du Monde comprend actuellement 44 composants. Ils constituent la colonne vertébrale du design, intégrant à la fois la charte graphique de la marque, appelée Tokens, et sont utilisés par les 150 composants Front sur nos différentes applications e-commerce, appshop et mobile.
Avant : Une classification atomique côté développeurs, aucune arborescence côté designers
Tiré du livre « Atomic Design » de Brad Frost
La première version de notre Design System était basée sur un modèle atomique, classant les éléments en Atomes, Molécules et Organismes. Cependant, cette approche ne fonctionnait pas. Les développeurs ne pensent pas en termes de taille de composants, mais plutôt en termes de fonction, ce qui les obligeait à rechercher chaque composant dans un classement contre-intuitif.
C’est pour cela qu’on a décidé de tout changer…
Après : Une classification fonctionnelle et un nommage standardisé
Nous avons collaboré entre designers et développeurs pour définir une arborescence commune répondant aux besoins des deux métiers. Nous avons opté pour une classification par fonction, regroupant les composants par catégorie autour d’un même usage. Le nommage des composants correspond à l’usage intuitif qu’on en fait. Par exemple, un Carousel se trouve désormais dans la navigation et non plus dans les organismes.
Ce travail est actuellement représenté en miroir du côté des développeurs sur une plateforme accessible appelée Histoire.
Une sémantique en trois parties pour les composants Front
Concernant les 150 composants Front, intégrés dans toutes les applications de Maisons du Monde, nous avons mis en place une construction sémantique en trois parties : le domaine, la fonction et l’aspect UI. Pour chacune de ces parties, nous avons rédigé une liste aidant à définir chaque élément, assurant ainsi une nomenclature cohérente pour les nouveaux composants apparaissant sur nos plateformes.
1. Une sémantique en 3 parties
Ce socle commun nous a ensuite permis de construire une nomenclature robuste pour nommer chaque composant. L’objectif : que son nom soit à la fois explicite, stable et utile pour toutes les équipes, du design à l’intégration.
Nous avons adopté une logique en trois segments :
→ Domaine (où le composant se situe dans l’écosystème)
→ Fonction (à quoi il sert)
→ Aspect UI (comment il se présente)
Par exemple : shipping + option + list désignera une liste de différentes option après le panier pour choisir son mode de livraison.
Pour cela, nous avons établi des listes de termes validés pour chaque segment, à partir des usages déjà existants sur les plateformes. Cette grille permet à chacun de nommer un composant de manière autonome et cohérente, tout en facilitant sa réutilisation ou son intégration dans d’autres projets.
C’est une base essentielle du Design System, car un bon système passe d’abord par une nomenclature compréhensible par tous.
2. Des composants Front alignés
Une fois les règles de nommage posées, nous avons structuré la bibliothèque de composants Front de manière à la rendre claire, transverse et accessible pour tous les profils : développeurs, designers, PO, etc.
Côté design, les composants sont organisés avec un niveau de granularité fin sur Figma. Côté développement, ils sont intégrés dans une bibliothèque Vue, exposée dans un premier temps sur Storybook, puis migrée progressivement vers Histoire, plus adaptée à notre stack.
Un principe central guide cette organisation : un composant peut être utilisé à plusieurs endroits sur le site, mais il reste rangé dans le domaine de sa fonction d’origine. Cela évite les redondances, encourage la réutilisation, et favorise une architecture évolutive à long terme.
Nous avons également veillé à ce que cette bibliothèque soit ouverte à la consultation par tous chez Maisons du Monde : pas seulement les développeurs ou les designers, mais aussi les PO ou les responsables QA. L’objectif était d’avoir un véritable référentiel partagé, qui aligne les intentions de design et les implémentations réelles.
Design System & Front : un référentiel unique Figma (UI) / Histoire (Dev)
Une fois les langages alignés et la structure synchronisée, on pourrait croire le travail terminé… mais ce n’est que le sommet de l’iceberg. Voici ce qu’il reste à explorer en profondeur.
1. Une documentation pour concrétiser la co-construction
La documentation est bien plus qu’un simple livrable : c’est le socle de communication interdisciplinaire qui rend possible l’alignement entre UX, UI, PO et développeurs. Chaque composant du Design System est accompagné de sa documentation, rédigée par mes soins, et pensée pour répondre à la fois aux besoins d’usage métier et aux impératifs techniques.
Prenons le ButtonDS comme exemple. Sa documentation s’appuie sur :
- un tableau de modélisation exhaustif, listant toutes les combinaisons de props et leurs contextes d’usage
- une overview claire avec les dimensions, contraintes, éléments obligatoires, et lien vers un prototype Figma fonctionnel
- une présentation de ses props détaillées (nom, type, valeur par défaut, rôle), facilitant leur implémentation directe en Vue.js
- une description des états dynamiques : survol (
hover), clic (active), désactivation (disabled), sélection via clavier (focus-visible)… - une section sur les comportements spécifiques, par exemple :
- gestion des marges dans une stack horizontale de boutons
- adaptabilité dans un formulaire vs dans un panel latéral
- largeur flexible ou fixe selon le contexte
En plus de ces éléments techniques, chaque documentation comporte :
- des exemples concrets d’implémentation (avec aperçu Figma + lien direct vers les maquettes UI)
- une cartographie de ses usages dans l’interface, même si non exhaustive dans certains cas comme pour le bouton
- des guidelines UI, qui listent les “à faire” / “à éviter” (ex. : ne jamais utiliser un Primary dans une modale secondaire, éviter deux reversed dans la même section…)
Cette documentation n’est pas figée : elle est vivante, collaborative, et maintenue en miroir entre Figma et Histoire. Elle facilite :
- l’intégration sans friction côté développement
- l’appropriation du composant par les nouveaux designers
- la validation des comportements en phase de QA ou de review produit
En somme, c’est cette rigueur documentaire qui transforme le Design System en outil transversal réellement opérationnel, et non en simple vitrine de composants.
2. Des propriétés identiques pour tous
Comme évoqué précédemment, les props (propriétés) permettent aux développeurs d’appeler une version bien précise d’un composant. Prenons notre ButtonDS : les props sont pensées en collaboration entre designers et développeurs dès la phase de conception, afin de garantir une parfaite correspondance entre Figma et le rendu final dans le code.
Parmi les props les plus courantes, on retrouve par exemple size, avec des valeurs comme small, medium ou large. Cela permet d’adapter dynamiquement les dimensions du bouton selon son contexte d’utilisation. On a également la prop variant (ex. : standard ou arrow) et surtout le level, qui joue un rôle crucial dans la hiérarchisation des actions.
Contrairement à ce que son nom pourrait laisser penser, le level ne désigne pas une couleur, mais un niveau d’importance fonctionnelle :
- Primary : action principale de la page (ex. : “Ajouter au panier”)
- Secondary : action secondaire (ex. : “Ajouter aux favoris”)
- Reversed : pour les cas d’usage inversés, comme une superposition sur image ou en dark mode
Toutes ces variations sont également sensibles aux états dynamiques classiques du web : hover, focus, active, ou encore disabled, sans oublier les cas d’accessibilité comme la navigation au clavier (:focus-visible).
Chaque état, chaque prop, chaque comportement a été rigoureusement documenté dans Figma et reproduit à l’identique sur Histoire. Cette parité garantit une synchronisation totale entre ce que voient les designers et ce que livrent les développeurs.
Ce travail d’alignement passe par une co-décision systématique : nous définissons ensemble les noms, les valeurs et les comportements attendus de chaque prop, afin d’éviter toute ambiguïté en phase de développement. C’est ce qui permet aujourd’hui d’avoir des composants cohérents et facilement maintenables.
3. Une source de vérité unique soutenue par une organisation transverse
L’objectif ultime d’un Design System bien conçu est d’offrir une source de vérité unique et accessible à tous, quel que soit son rôle dans l’équipe. Pour cela, nous avons structuré une organisation rigoureuse autour de deux référentiels synchronisés : Figma pour les designers, et Histoire pour les développeurs.
Sur Histoire, chaque composant est rendu interactif grâce à une zone de test appelée “Playground”. Les équipes peuvent y manipuler les props (variant, level, size…) et visualiser instantanément les effets, ce qui permet :
- aux développeurs de valider l’implémentation
- aux designers d’ajuster des détails en direct
- aux testeurs de vérifier des cas d’usage spécifiques
Du côté de Figma, la même logique s’applique : toutes les variantes du composant sont modélisées à plat, avec les différents états, et directement reliées à la documentation technique. L’intégration est facilitée grâce à des naming conventions strictes, à une classification par domaine/fonction/UI, et à des tokens unifiés (couleurs, radius, typo…).
Mais ce miroir ne fonctionne que si l’organisation suit. Pour cela, nous avons :
- défini des rituels de Design System Review (toutes les semaines avec développeurs) et de Design System Board (toutes les semaines avec les designers)
- créé une documentation miroir entre Figma et Histoire, mise à jour systématiquement lors de l’évolution d’un composant
- instauré une logique de “single source of truth” : un composant n’est considéré comme terminé que s’il est à jour dans les deux référentiels
- formalisé un workflow de contribution où chaque nouvelle évolution est validée, testée, documentée et diffusée de manière transverse
Ce système permet aujourd’hui à toutes les équipes (produit, design, tech, QA) de s’appuyer sur des composants cohérents, validés et alignés, sans dépendre d’un référent unique. C’est cette organisation qui garantit la pérennité, la scalabilité et la maintenabilité du Design System sur le long terme.
Un grand merci à :
Chloé Vérité, UI Designer, pour l’animation des prototypes
Astrid Crépin, Lead Designer, pour la réalisation des composants Front de la homepage
Pierre Nowak, mon binôme en tant que Design System Engineer
Benjamin Hénique, Architecte Solution, et Jean-Charles Fauchet, Tech Lead, pour leur soutien et leurs solutions pendant nos Design System Reviews
Et bien sûr, Sophie Gauthié, Head of Product Design, pour sa confiance pendant ces deux années et nos échanges précieux autour du Design Ops.