Aller au contenu
Axel Besson
ENMe contacter

Réconcilier le site et l'app d'une banque

Pour un même objet, le site web Crédit Agricole et l'application Ma banque avaient chacun leur composant. L'objectif : trouver le bon compromis pour n'en garder qu'un, utilisé sur les deux. Mission pour Crédit Agricole Technologies et Services, avec Synanto.

Un exemple, pas leur produit. Mission confidentielle, visuels reconstitués.

Exemple : une carte de compte, de deux composants à un seulAvant : deux composantsSite webCompte courantActif•••• €VirementPaiementRelevéBadge rectangulaire, actions en texte pleinApp Ma banqueCompte courant•••• €Vir.PmtRel.Pas de badge, actions abrégées sur fond grisAprès : un composant communCarte de compte, 1 composantSite webCompte courantActif•••• €VirementPaiementRelevéApp Ma banqueCompte courantActif•••• €VirementPaiementRelevéAxelDeux composants pour un même objet : chaque écart se payait deux fois.AxelAprès l'atelier : un seul composant, sur le site comme dans l'app.

Le problème

Sur le site comme dans l'app, on retrouvait les mêmes objets métier. Mais chaque équipe faisait évoluer son propre composant, avec ses styles, ses comportements et son nommage. Chaque écart se payait deux fois, en conception puis en intégration.

Mes décisions

Exemple : l'audit des écarts sur une carte de compte
ÉlémentSite webApp Ma banqueComposant commun
Statut du compteBadge rectangulaire
Écart
Pas de badge
Écart
Badge pilule, token color-status
ActionsTexte plein, en ligne
Écart
Abrégées, fond gris sans contour
Écart
Bordées, token action-label
StructureLibellé, montant, badge, actionsLibellé, montant, actionsLibellé, montant, badge, actions

Comparer les deux composants, écart par écart

L'audit a mis côte à côte le composant du site et celui de l'app. Chaque écart est documenté et classé par priorité, pour que les deux équipes partent du même constat avant de chercher une solution.

Trouver le compromis en atelier, avec les deux équipes

J'animais des ateliers réunissant le web et l'app autour d'un composant : présentation de l'audit, idéation et benchmark, puis création collective en direct sur Figma. Sur les composants complexes, on itérait jusqu'à un accord, et chaque décision était documentée.

Schéma : le déroulé d'un atelier
Présentation de l'audittout le monde part du même constatIdéation et benchmarkchaque équipe pose ses contraintesCréation collectiveen direct sur FigmaDécision documentéepour que chacun s'y réfère
Exemple : le composant commun, spécifiésite webCompte courantActif•••• €VirementPaiementRelevéappCompte courantActif•••• €VirementPaiementRelevéBadge : pilule, token color-statusActions : bordées, token action-labelNe change que le contexte autour : fond de page, grille

Un seul composant, adapté à chaque écran

Le composant sorti de l'atelier s'utilise tel quel sur le site comme dans l'app : même structure, mêmes tokens, même badge. Ce qui s'adapte à l'écran se règle autour du composant, jamais dedans. Les deux équipes piochent dans la même source.

Résultat

Ce que ça a changé

Un composant là où il y en avait deux.

Le même sur le site et dans l'app : seul le contexte autour change. Des composants Figma documentés, livrés aux équipes front-end.

  • 2 surfaces auditées
  • Composants documentés
  • Un composant pour le web et l'app
Avec le recul

Ce que je referais autrement

J'aurais associé les développeurs dès l'audit, et pas seulement aux ateliers : ils voient des écarts que Figma ne montre pas.

Cas suivantJuridispoRendre un avocat facile à trouver et à réserver2 parcours13 écransAudit puis refonteLire l'étude de cas
Contact

Mon profil vous intéresse ?

Télécharger le CVLinkedIn (nouvel onglet)

Ou ouvrir ma messagerie avec l'adresse déjà remplie.

Mentions légalesConfidentialité