Étude de cas · Design System
Design System
BYmyCAR · 12 marques fédérées.
BYmyCAR, acteur majeur de la distribution automobile en France, opérait avec plus de 12 marques sur autant d'interfaces visuellement incohérentes. L'objectif : fédérer l'ensemble sous un langage design commun, documenté et maintenable.
−30%
Temps dev Front-End
+150
Composants Figma
+12
Marques fédérées
01
Constat : Une expérience utilisateur fragmentée et non accessible
Un écosystème visuel fragmenté
L'audit initial a révélé un écosystème digital profondément hétérogène. Sur l'ensemble des marques du groupe, chaque interface avait évolué de façon autonome, générant une fragmentation visuelle et éditoriale sévère. Autant de bibliothèques que de marques.
Des lacunes d'accessibilité critiques
Le constat en matière d'accessibilité était tout aussi sévère. De nombreux composants ne respectaient pas les ratios de contraste WCAG AA, et des textes d'interface — labels, mentions légales, indicateurs de statut — étaient rendus à des tailles inférieures à 12 px.
Point de départ de l'audit : Plus de 340 composants uniques recensés sur Figma, dont 60 % de doublons non harmonisés. Aucun token de design, aucune règle d'accessibilité documentée.
Branding fragmenté
Couleurs hors charte, styles médias disparates et tonalité éditoriale instable — sans ligne directrice unifiée.
Branding fragmenté
Couleurs hors charte, styles médias disparates et tonalité éditoriale instable — sans ligne directrice unifiée.
Accessibilité critique
Ratios de contraste insuffisants et textes inférieurs à 12 px rendant l'interface illisible pour les utilisateurs à vision réduite.
Prolifération des composants
Multiplication non contrôlée des variantes de cards : aucun standard, chaque équipe produisant ses propres déclinaisons.
02
Les Fondations : Un langage commun entre Design et Code
L'intégralité de la documentation a été réalisée directement sur Figma. Ce choix n'était pas arbitraire : l'outil était déjà adopté par toutes les équipes — designers, Product Managers et développeurs front-end — éliminant ainsi toute friction d'onboarding.
L'architecture des Design Tokens
La première étape a été de poser un système de tokens robuste pour garantir la scalabilité. Chaque token suit une nomenclature stricte à cinq niveaux, lisible à la fois par un designer et un développeur.
Les Primitives — Core Foundations
Avant de concevoir le moindre composant, quatre chantiers de fondation ont été menés en parallèle. Ces primitives constituent la couche la plus stable du système : elles ne changent jamais sans décision explicite, et tout le reste en découle.
Description
Deux couches distinctes : les primitives (brand-500, neutral-100) sont les valeurs brutes, jamais utilisées directement dans les composants. Les sémantiques (color-background-button-primary-enabled) portent une intention claire et sont les seuls tokens référencés dans le code. Chaque palette couvre 11 steps, complétée par des rôles pour les états : info, success, warning, danger.
Création des Composants : Rigueur, Accessibilité et Comportements
Les primitives posées, chaque composant a été conçu selon une philosophie accessibility-first — les problèmes critiques identifiés à l'audit (contrastes insuffisants, tailles typographiques non conformes, absence d'états focus) ont été traités à la racine, pas en post-production.
Composants — Exemples
Système de boutons à 4 variantes (primary, secondary, ghost, destructive) et 3 tailles. Chaque combinaison état × variante est documentée — aucun comportement implicite. Le contraste WCAG AA est vérifié programmatiquement sur chaque token de couleur.
Refonte complète des liens : états hover, visited et focus visibles et distincts. Couleur conforme WCAG AA, soulignement explicite pour ne pas reposer uniquement sur la couleur. Chaque variante — lien inline, lien standalone, lien avec icône — est documentée avec ses règles d'usage.
Refonte complète des inputs : labels toujours visibles (plus de placeholder seul), messages d'erreur positionnés sous le champ avec icône, hint text optionnel. Touch target minimal de 44px respecté sur mobile. Variantes avec prefix, suffix et caractère restant.
Composant central du catalogue — la card véhicule existait en 6 déclinaisons non cohérentes selon les marques. Le nouveau composant unifié gère les états loading (skeleton), favori, badge promo et l'affichage conditionnel des informations selon le contexte (liste, grille, suggestion).
Adaptation du design system pour chacune des marques
Chaque composant est conçu pour absorber l'identité visuelle de chaque marque du groupe — couleurs, typographie, rayons — sans altérer sa structure ni sa logique d'accessibilité. Un seul système, autant de déclinaisons que de marques.
03
Avant / Après : L'impact direct sur l'interface
Au-delà des chiffres, le Design System a produit un impact visuel immédiat et mesurable. La page produit véhicule — surface transactionnelle centrale du groupe, déclinée sur toutes les marques — illustre concrètement ce que signifie passer d'une interface héritée à un produit accessible, cohérent et scalable. Chaque correction répond à un problème fonctionnel documenté à l'audit — aucune retouche cosmétique.
- Cards véhicules hétérogènes — 6 déclinaisons non cohérentes selon les marques
- Typographie et espacements non tokenisés — chaque équipe ses propres valeurs
- Absence de hiérarchie visuelle — composants sans niveaux d'importance définis
- Card véhicule unifiée — un seul composant partagé sur toutes les marques du groupe
- Tokens typographiques et d'espacement appliqués — cohérence garantie par le système
- Hiérarchie visuelle structurée via les primitives — titre, prix et CTA stratifiés
04
Tout documenter sur Figma
Toute la documentation du Design System a été réalisée directement dans Figma. Le choix était évident : l'outil était déjà utilisé au quotidien par toutes les équipes — designers, développeurs et Product Managers — sans aucune friction d'adoption. Chaque composant est documenté avec ses variantes, ses états, ses tokens associés et ses règles d'usage, au même endroit que le fichier de design.
05
Rétrospective
Défis rencontrés
- Convaincre les équipes de la valeur long terme du Design System face aux urgences du quotidien.
- Gérer la dette technique héritée des 12 marques existantes sans stopper la production.
- Maintenir la cohérence entre Figma et le code au fil des itérations.
- Former des designers juniors à l'utilisation rigoureuse des tokens et variants.
- Arbitrer entre standardisation et besoins spécifiques de certaines marques.
Ce que j'en ai retiré
- Un Design System n'est pas un projet, c'est un produit : il a besoin d'une roadmap et d'un ownership.
- Les design reviews régulières avec les développeurs sont aussi importantes que la qualité des composants eux-mêmes.
- La documentation doit être pensée pour les développeurs dès la conception du composant.
- Prochain chantier : déployer des tests utilisateurs pour mesurer l'impact du Design System sur les parcours de conversion.
- Explorer les Design Tokens W3C pour améliorer l'interopérabilité Figma ↔ code.
Étude de cas suivante
Aven — Marketplace Automobile IA
Concevoir une marketplace B2B2C from scratch : data viz, IA et 20M€ levés.
Voir l'étude de cas Aven