Design System Figma Multi-marques BNP Paribas · Arval

Design System Arval — Construire la cohérence à l'échelle de 4 pays et 5 équipes

Création from scratch du design system Arval : fondations visuelles, bibliothèque de composants versionnée, gouvernance et communauté de pratique. Un système conçu pour être adopté — pas seulement livré.

Client Arval — filiale BNP Paribas

Core team 2 designers · 1 PO · 3 dev front-end

Outil Figma — UI kit versionné

Périmètre 4 pays · 5 équipes · marques blanches

01 — Contexte

Une organisation multi-pays, multi-équipes, sans langage visuel commun

Arval opère dans plus de 30 pays avec des équipes produit distribuées. Sans référentiel design partagé, chaque équipe concevait et développait ses interfaces de façon indépendante — générant des incohérences visuelles, des composants redéveloppés en doublon et des délais de livraison allongés.

Le défi était triple : créer un système suffisamment structuré pour garantir la cohérence entre 5 équipes et 4 pays, suffisamment flexible pour supporter des marques blanches, et suffisamment bien documenté pour être adopté sans dépendance permanente à la core team.

Les trois objectifs

1. Cohérence — garantir que toutes les interfaces produites par les équipes Arval parlent le même langage visuel, quel que soit le pays ou le produit.

2. Adoption — promouvoir l'utilisation active du design system, pas seulement sa mise à disposition. Objectif : que les équipes choisissent de l'utiliser parce qu'il leur fait gagner du temps.

3. Communauté — établir une communauté de pratique engagée autour du système, pour assurer sa pérennité et son évolution dans le temps.

02 — Mon rôle

Co-créateur du système, référent design de la core team

Au sein d'une core team de 6 personnes (2 designers, 1 PO, 3 développeurs front-end), j'ai co-piloté la conception et la mise à disposition du design system Arval dans Figma — des fondations jusqu'à la gouvernance.

Fondations & tokens

Définition et structuration des 483 variables (couleurs, typographie, espacement, ombres, border-radius) — nommées et organisées pour être directement consommables par les développeurs front-end.

Bibliothèque Figma versionnée

Construction des 31 composants avec variants, états interactifs et auto-layout. Versionnement du UI kit pour permettre aux équipes de monter en version sans casser leurs fichiers existants.

Marques blanches

Architecture du système pour supporter plusieurs marques blanches — theming par tokens, composants agnostiques de la marque, documentation des règles de customisation.

Gouvernance & communauté

Mise en place du processus de contribution, des règles de versioning et d'une communauté de pratique engagée — pour que le système vive au-delà de la core team initiale.

03 — Processus

Construire pour être adopté, pas seulement livré

Le processus a été conçu pour embarquer les équipes dès le début — l'adoption ne commence pas à la livraison, elle se construit pendant la conception.

Audit & inventaire — recenser l'existant

Recensement des patterns visuels existants dans les interfaces des 5 équipes. Identification des composants communs, des incohérences majeures et des besoins spécifiques par pays. Cet audit a servi de base pour prioriser les premiers composants à créer.

Fondations — poser les 483 variables

Définition des design tokens en collaboration étroite avec les 3 développeurs front-end — nommage, structure, organisation par catégorie et par marque. Les tokens ont été conçus dès le départ pour supporter le theming multi-marques, avec une couche de variables sémantiques au-dessus des variables primitives.

Composants — 31 briques, zéro compromis

Construction itérative de la bibliothèque dans Figma — des atomes (boutons, champs, icônes) aux organismes (formulaires, tableaux, navigation). Chaque composant validé conjointement avec les développeurs avant publication, pour garantir la parité design/code et éviter les surprises en implémentation.

Versionnement — un UI kit qui évolue sans casser

Mise en place d'un système de versionnement sémantique du UI kit Figma (major / minor / patch), avec changelog documenté à chaque release. Les équipes peuvent choisir de monter en version ou de rester sur une version stable selon leurs contraintes projet.

Communauté — l'adoption comme produit

Création d'une communauté de pratique réunissant designers et développeurs des 5 équipes. Sessions de onboarding, office hours réguliers, canal dédié pour les questions et contributions. L'objectif : que chaque équipe se sente propriétaire du système, pas seulement utilisatrice.

Image — bibliothèque de composants Figma

04 — Résultats

Un système vivant, adopté et en croissance

Les chiffres parlent d'eux-mêmes — et le plus significatif est le dernier : 3 300 inserts par semaine, c'est la preuve que le système est utilisé au quotidien, pas seulement mis à disposition.

483 var.

Variables de design tokens structurées et documentées

31 comp.

Composants Figma avec variants et états interactifs

+3,3k/sem.

Inserts hebdomadaires — indicateur d'adoption active

5 teams

Équipes produit embarquées dans le système

4 pays

Déploiement international du design system

15 marques

Architecture multi-marques blanches supportée nativement

Adoption mesurée — les +3 300 inserts hebdomadaires dans Figma confirment que les équipes utilisent activement le UI kit, sans y être contraintes.

Architecture multi-marques — le système supporte nativement plusieurs marques blanches via le theming par tokens, sans dupliquer les composants.

Communauté active — une communauté de pratique engagée réunit designers et développeurs des 5 équipes autour du système, garantissant son évolution continue.

Parité design/code — les tokens et composants ont été co-construits avec les développeurs front-end, réduisant les écarts entre maquette et implémentation finale.

Pérennité garantie — le versionnement sémantique et les règles de gouvernance permettent au système de continuer à évoluer sans dépendre de la core team initiale.