(Étude de cas)

Crédit Agricole

Harmoniser les composants d'interface d'un grand groupe bancaire, du web à l'application mobile Ma banque.

Rôle : UX Designer · Design System Contexte : Mission Synanto pour Crédit Agricole Technologies et Services Secteur : Banque
Design SystemUI DesignBanque
Avant l'atelier
Site web CA
Compte courantActif
•••• €
VirementPaiementRelevé

Badge rectangulaire, actions en texte plein

App Ma banque
Compte courant
•••• €
Vir.PmtRel.

Pas de badge, actions abrégées

Après
Web = App
Compte courantActif
•••• €
VirementPaiementRelevé

Badge pilule sur token, actions bordées, structure inchangée

Confidentialité : aucun écran du produit ne peut être publié. Les illustrations de cette page reconstituent, sur une charte neutre, les composants et les décisions de design réellement livrés.

(Contexte)

Mission menée pour Crédit Agricole Technologies et Services (CATS), l'entité technologique du groupe. Intégré aux équipes produit et front-end, j'ai pris en charge la cohérence des composants d'interface, du web au mobile.

Le site web CA et l'application Ma banque faisaient évoluer leurs composants en parallèle : mêmes objets métier, styles et nommages divergents. Chaque écart se paie deux fois, en conception puis en intégration.

ClientCrédit Agricole Technologies et Services (CATS)
ContexteMission Synanto · 4 mois
Périmètre2 surfaces produit · site web CA et app Ma banque
ÉquipeÉquipes produit et front-end
Mon rôleUX Designer · Design System
(Problématique)

Comment garantir des interfaces cohérentes, du web au mobile, dans un groupe où chaque équipe fait évoluer ses composants de son côté ?

(Objectifs)
01

Auditer la cohérence

Identifier les écarts entre les composants UI web et mobile, et les points de divergence entre équipes.

02

Harmoniser

Livrer des composants Figma alignés et documentés, prêts pour les équipes front-end.

03

Outiller les équipes

Fluidifier la collaboration design/développement et diffuser une culture design system.

(Parcours & écrans)

Deux surfaces, un seul composant

Le parti pris : ne pas livrer deux variantes d'un même objet. Chaque composant divergent a été ramené à une définition unique : mêmes tokens, mêmes états, même nommage, utilisable telle quelle sur le web comme sur l'app. Ce qui s'adapte au contexte se règle autour du composant, jamais dedans.

La source partagée : tokens et composants

Tokens et styles
Couleur primaire
Couleur encre
Fond neutre
Bold / Titre
Regular / Corps
Composants partagés
Primaire
Secondaire
Champ de saisie
En coursValideEn attente

Ce que j'ai fait chez Crédit Agricole Technologies et Services

1
Audit des composants

Cartographie des écarts entre composants web et mobiles : styles, comportements, nommage. Identification des divergences entre équipes.

2
Harmonisation

Conception de composants Figma cohérents et documentés, alignés entre le site web et l'app Ma banque, prêts à être intégrés sans friction par les développeurs.

3
Collaboration design/dev

Ateliers avec les équipes produit et front-end pour ancrer les composants dans les pratiques et fluidifier le passage du design au code.


Résultat : la même base, deux produits cohérents

Site web CA
ComptesÉpargneCrédit
Compte courant
Solde disponibleActif
Livret A
Taux 3%En cours
Simuler un prêt
App Ma banque
Bonjour Axel
Connecté
Compte courant
**** euros
ComptesÉpargneCrédit
Rechercher une opération

De l'atelier au composant final

Une fois les écarts identifiés, j'animais des ateliers réunissant les deux équipes (web et app) autour d'un même composant. L'objectif : trouver une solution qui satisfait les deux surfaces sans compromis. Voici un exemple concret : la carte de compte, revisitée pour fonctionner aussi bien en desktop qu'en mobile.

Avant l'atelier : deux composants qui divergent

Version web
Compte courant
**** euros
Actif
Virement
Paiement
Relevé
Écart identifié
Badge rectangulaire · Actions en ligne
Version app
Compte courant
**** euros
Virement
Paiement
Relevé
Écart identifié
Badge inexistant · Actions en icônes

L'atelier : de l'audit à la solution

1
Présentation de l'audit
Je presente les écarts identifiés lors de l'audit aux deux équipes (web et app). Objectif : aligner tout le monde sur le constat avant de chercher des solutions. Les divergences sont documentées et classées par priorité.
2
Idéation et benchmark
On s'appuie sur des références externes (design systems reconnus, patterns similaires dans d'autres produits) pour explorer les pistes. Chaque équipe propose ses contraintes et ses attentes. Cette phase permet de sortir du cadre du produit existant pour penser la solution de façon plus ouverte.
3
Création collective
On conçoit ensemble le composant, en direct, sur Figma. Je pilote la session mais chaque équipe contribue aux décisions. L'objectif est de sortir avec un composant que tout le monde valide, web comme app. Selon la complexité, cette phase peut se dérouler sur plusieurs ateliers avant qu'on tombe d'accord.
Un processus itératif. Sur des composants complexes, on ne sort pas toujours avec un consensus après un seul atelier. On itère, on revalide, et on documente chaque décision pour que les équipes puissent s'y référer.

Le composant sorti de l'atelier : identique web et app

Le résultat de l'atelier : un seul et même composant, utilisé tel quel sur le web comme sur l'app. Pas d'adaptation, pas de fork. La même structure, les mêmes tokens, le même badge. Ce qui change, c'est uniquement le contexte dans lequel il s'insère (fond de page, grille), pas le composant lui-même.
Carte de compte · composant DS · Web = App
STRUCTURE
Label · Montant · Badge · Actions
BADGE
Pilule · token color-status
ACTIONS
Texte · token action-label
● WEB   =   APP ●
Compte courant
**** euros
Actif↑ BADGE PILULE
Virement
Paiement
Relevé
↑ ACTIONS BORDEES · TOKEN ACTION-LABEL
Badge : rectangulaire → pilule avec token color-status
Actions : fond gris sans contour → bordure token action-label
Structure : inchangée, compatible web et app
Un seul composant dans le design system. Les deux équipes piochent dans la même source. L'adaptation au contexte (fond de page, grille mise en page) est gérée en dehors du composant, pas à l'intérieur.
(Solution)

La solution

Un ensemble de composants harmonisés, documentés et alignés entre design et développement, qui réduit les écarts entre le web et le mobile.

(Impact)

Deux surfaces auditées, des composants Figma documentés livrés aux équipes front-end, et un composant unique là où il y en avait deux. Pas de fork, pas d’adaptation.

(Projet suivant)
AMAC