Redesign du back office ACS

Aperçu

Depuis janvier 2025, je pilote le design produit du back office ACS, un produit multi-banques et l'interface opérationnelle de l'Access Control Server (ACS) Worldline : la solution d'authentification certifiée que les banques émettrices utilisent pour piloter le 3-D Secure, réduire la fraude et vérifier le porteur de carte lors des paiements en ligne, via plusieurs méthodes d'authentification. C'est l'infrastructure derrière les pages d'authentification visibles parfois au checkout. Quand j'ai rejoint le projet, le back office avait grandi sans design system, sans Figma, et avec une UI qui ne suivait plus les usages experts, longs formulaires de recherche, tableaux denses, navigation qui ralentissait les tâches critiques.

10+

Banques émettrices en boucle UX

14

Sessions UX client

9

Participants tests internes

5

Versions UI kit livrées

Problème

Les experts des banques émettrices clientes, Crédit Agricole Payment Services, Crédit Mutuel Arkea, et d'autres, s'appuient sur ce back office au quotidien pour configurer, superviser et faire tourner une plateforme d'authentification qui, côté porteur de carte, se matérialise au moment du paiement en ligne. En B2B, l'accès direct à ces profils reste limité pour mener de la recherche en continu.

Au fil du temps, chaque banque avait aussi façonné le produit selon ses propres besoins : fonctionnalités spécifiques, parcours sur mesure, demandes ponctuelles. Ce qui devait être une plateforme unique était devenu un patchwork de variations par client, difficile à maintenir, à utiliser de façon homogène et à faire évoluer. L'UI legacy amplifiait cette fragmentation : pas de composants partagés, des patterns incohérents, et des écarts d'accessibilité par rapport aux attentes WCAG et RGAA.

La refonte devait converger ces trajectoires divergentes vers une expérience commune, cohérente, normalisée, tout en préservant ce qui est réellement spécifique à chaque client, et poser les bases de discovery et de design que le produit n'avait jamais eues.

Mon rôle

• Lead Product Designer sur le back office ACS, direction UX et standards visuels
• Encadrement de deux alternants design sur la recherche, les itérations UI kit et le prototypage
• Animation de user clubs et de sessions UX client (~tous les six semaines) avec 10+ banques émettrices en boucle pour aligner la roadmap sur les besoins réels des experts
• Contribution au design system émergent, en parallèle de versions UI kit utilisables immédiatement par la squad
• Collaboration avec l'ingénierie sur la faisabilité, confronter le design aux contraintes techniques avant le build
• Revue UI et tests UX sur ce qui est livré ; cadrage de l'instrumentation analytics et exploitation des données pour éclairer les décisions produit

Approche

Un produit, plusieurs banques. L'objectif n'est pas de multiplier les variantes. Via les sessions UX banque par banque et une synthèse interne, nous fusionnons ce qui compte chez chaque client en une expérience partagée : navigation cohérente, patterns réutilisables et normes, accessibilité incluse, sur lesquelles chaque émetteur peut s'appuyer.

Discovery sans accès direct. Nous combinons deux sessions de tests internes (neuf collègues rejouant des scénarios experts) et 14 sessions UX client à ce jour, environ une tous les six semaines, banque par banque. On y présente le travail en cours, on collecte du feedback et on priorise les fonctionnalités à la fois critiques pour chaque banque et généralisables pour toutes.

Repartir de zéro. Sans système existant, j'ai livré cinq versions d'UI kit avec mes alternants, quatre avant le déploiement du design system, autour de la couleur, du contraste et de patterns accessibles (WCAG / RGAA), appliqués aux zones à forte friction, notamment les longs formulaires de recherche et les parcours cœur du back office. Figma Make a accéléré le prototypage avancé : en quelques jours, on explore ce qui prenait des semaines de design classique.

Valider avant de généraliser. Nous animons un user club annuel pour stress-tester les paris majeurs. Plusieurs directions ont été validées, dont une navigation latérale (en remplacement du menu haut) et un historique de recherche pour la consultation de transactions. D'autres, comme la magic search, ont été abandonnées avant le build. En parallèle, nous déployons le back office redesigné (nouveaux patterns UX, pas encore une release design system complète) et mettons en place Matomo pour capturer les premiers signaux quantitatifs : ce qui est utilisé, où les experts peinent, et si les changements tiennent en production.

Mon plus grand défi : la recherche de transactions

L'une des zones les plus frictionnelles du back office, c'est le formulaire de recherche de transactions : une page unique saturée de critères, des dizaines de champs que les experts doivent parcourir, remplir et maintenir. Sur le papier, simplifier cet écran semblait une évidence.

L'hypothèse : la « magic search »

Mon idée : un constructeur de recherche dynamique centré sur un seul champ, une barre de magic search. L'expert choisit un critère, saisit sa valeur, en ajoute un autre, et compose sa requête pas à pas. Moins de bruit visuel, un parcours plus guidé, et (je le pensais) des recherches plus rapides une fois le pattern acquis. (Le besoin d'historique de recherche s'est avéré réel, mais comme fonctionnalité à part, pas à l'intérieur de ce builder.)

Nous l'avons prototypé rapidement dans Figma, en s'appuyant fortement sur Figma Make pour obtenir une version interactive avancée sans attendre l'ingénierie. L'objectif : tester le concept en interne avant de lancer le build.

Ce que les tests internes ont changé

Quand des collègues ont rejoué des scénarios experts sur le prototype, le constat s'est inversé. Construire une recherche prenait plus de temps, pas moins. Le pattern obligeait à composer un formulaire from scratch alors que le vrai besoin, c'était d'enchaîner plusieurs recherches, lancer une requête, ajuster un critère, changer de type de transaction, relancer. Il fallait des champs visibles et persistants, modifiables en un clic, pas un builder qui cachait la complexité derrière un seul input.

On a identifié l'écart avant l'implémentation. La magic search a été abandonnée ; l'apprentissage est resté, et l'historique de recherche a été validé comme réponse distincte pour enchaîner et réutiliser des requêtes.

Pourquoi c'est important

C'est un exemple concret de notre façon de travailler quand l'accès direct aux experts bancaires est limité : prototypage génératif rapide (Figma Make) pour explorer des idées ambitieuses, tests internes pour les confronter aux vrais usages, et capacité à tuer un concept qui paraît élégant mais échoue en pratique, tout en livrant ce que les tests confirment. Toutes les pistes ne partent pas en production ; celles qui partent sont plus solides.

Résultat

Par rapport à un produit parti de zéro côté design, et d'un paysage de customisations par banque, le back office shippe aujourd'hui vers une expérience commune et cohérente : UI plus claire, bases d'accessibilité plus solides, et une boucle de discovery qui garde la roadmap ancrée dans le réel. Six paris UX majeurs validés à ce jour (navigation latérale, historique de recherche, et autres refontes) ; la magic search illustre ce qu'on a su stopper tôt. La release en cours embarque la nouvelle navigation et des patterns UX partagés ; nous continuons de stress-tester les parcours avec les clients et en interne, pendant que le design system mûrit. Le projet est en cours, et chaque user club et chaque session banque aide à distinguer ce qui doit devenir standard de ce qui doit rester spécifique.