Design system

Contexte

Deux produits, un seul socle à inventer

Chargemap Business et Chargemap Partners sont deux produits B2B distincts, mais leurs besoins d'interface se ressemblent beaucoup : du listing, des tableaux denses, des formulaires, des états techniques. Sans socle commun, chaque produit redéveloppait ses propres composants, du travail fait deux fois, des incohérences entre les deux, et aucune capitalisation. Il n'existait pas de design system. Je l'ai construit de zéro.

Problème

Le constat de départ était simple : deux produits aux besoins proches, c'est une opportunité de mutualisation. Plutôt que de recréer un tableau, un badge ou un champ pour chaque produit, un composant ajouté à une bibliothèque commune devient immédiatement disponible des deux côtés. Poser une fondation partagée qui réduit le travail, garantit la cohérence, et tienne dans le temps, pour les designers comme pour les développeurs.

Approche

Une bibliothèque unifiée, deux thèmes

Le cœur du système : une seule bibliothèque de composants alimente les deux produits. Un composant développé pour un besoin Partners est automatiquement utilisable sur Business, sans redéveloppement. Développé une fois, utilisé partout. Pour absorber les deux identités, le système gère deux thèmes via les modes de variables Figma : les couleurs s'adaptent à Business ou à Partners sans dupliquer un seul composant. Un système, deux marques.

Des fondations aux composants

Le système se construit en couches. À la base, les fondations : couleurs, espacements, ombres, typographie : les briques visuelles communes à tout le reste. Au-dessus, les composants qui les assemblent : boutons, champs de saisie, badges, tableaux… Chaque composant puise dans les fondations plutôt que dans des valeurs arbitraires, ce qui garantit la cohérence.

L'atomic design, sur un cas réel

Pour que le système reste lisible et composable, chaque composant suit une logique atomique. L'exemple le plus parlant, c'est notre tableau : chaque cellule contient un atome (un texte, un bouton, un badge) ; la cellule elle-même est une molécule (dimensions, styles, sous-composants) ; l'ensemble forme un organisme : le tableau, qui vient s'insérer dans des pages plus complexes. Cette décomposition n'est pas théorique : c'est ce qui permet de réutiliser les mêmes atomes partout et de faire évoluer un niveau sans casser les autres.

Des tokens sémantiques sur des primitives solides

Les couleurs, espacements et autres valeurs reposent sur des tokens sémantiques construits au-dessus des primitives Tailwind. Les composants ne référencent jamais une valeur brute mais un token porteur de sens, ce qui rend les deux thèmes possibles et le système maintenable.

AI Ready

Concevoir un système que l'IA sait lire

Plutôt que de penser le design system uniquement pour des humains, je l'ai structuré pour qu'une IA puisse implémenter un composant proprement, en respectant nos conventions. Concrètement : des conventions de nommage raccord avec le dev (kebab-case pour les layers et les composants, camelCase pour les propriétés), des variables explicites pour couleurs et espacements, et une description au niveau de chaque composant qui donne le contexte nécessaire, et qui peut être récupéré via MCP. Avec les développeurs front, on a défini des skills pour que les composants soient développés par l'IA en suivant nos conventions.

Designer, et contribuer au code

Pour aller au bout de la logique, j'ai installé en local le repo de la bibliothèque de composants. Concrètement, en tant que profil non technique, je peux désormais ouvrir des pull requests sur les composants eux-mêmes, ajuster une couleur, un espacement, ajouter une icône directement dans le code, avec l'aide de l'IA.

Le design system n'est plus seulement quelque chose que je conçois dans Figma puis que je « passe » aux devs : c'est un objet sur lequel je peux intervenir des deux côtés, en restant dans les conventions qu'on a posées.

Fiabilité & collaboration

Communiquer les évolutions

Un changelog et un versioning au langage des développeurs (major / minor / patch) permettent à chacun de voir d'un coup d'œil si un changement est un simple correctif ou une évolution structurante.

Tester les composants en isolation

Les composants vivent dans Storybook : chacun y est documenté et manipulable en isolation, indépendamment du produit dans lequel il s'insère. Les développeurs et designers disposent ainsi d'un environnement de référence pour visualiser un composant dans tous ses états avant de l'intégrer.

Éviter les divergences avec Chromatic

Chromatic ajoute la couche de test visuel : il permet de détecter toute divergence entre les versions successives du design system, et surtout entre le code et Figma (via le plugin intégré à Figma). C'est ce qui garantit que ce qui est conçu et ce qui est livré restent alignés, sans dérive silencieuse au fil des évolutions.

Impact

Un composant développé une fois est disponible sur les deux produits, sans redéveloppement. Les conventions et le contexte posés rendent le système directement exploitable par l'IA (génération de code conforme, MCP Figma), et le versioning major/minor/patch permet à chacun d'anticiper l'impact d'un changement. Le système a aussi permis à un designer, recruté récemment, d'être immédiatement productif dans nos standards. Résultat : moins de travail dupliqué, une cohérence garantie, et un système qui tient dans le temps.