EBP Informatique · B2B Web & Desktop
EBP — remettre à plat un écosystème de gestion saturé de données
Éditeur de logiciels de comptabilité, gestion et finance. Un design system multi-plateforme consommé par plusieurs équipes, et une refonte d’interfaces expertes menée du cadrage au handoff.
01
Contexte & problème
EBP édite des logiciels de comptabilité, de gestion et de finance utilisés quotidiennement par des cabinets d’expertise comptable et des TPE. Ce sont des produits que l’on n’utilise pas par plaisir : on les utilise parce qu’une obligation légale l’impose, plusieurs heures par jour, souvent depuis des années.
Deux caractéristiques structurent tout le travail de conception.
- Des interfaces intrinsèquement denses. Tableaux à forte volumétrie, saisies multi-critères, états comptables. Simplifier en retirant de l’information n’est pas une option : l’information est le produit.
- Un écosystème multi-plateforme. Modules Web et Desktop, développés par plusieurs équipes, avec des cycles et des contraintes techniques différents.
Côté utilisateur, des écrans experts devenus illisibles à force d’ajouts successifs. Côté organisation, aucun langage d’interface partagé entre les équipes — donc une divergence visuelle et comportementale qui s’aggravait à chaque sprint.
Ma mission
Piloter la refonte globale de l’écosystème produit, du cadrage au handoff, et construire en parallèle le design system qui devait empêcher la divergence de recommencer.
02
Research & insights
Concevoir pour des experts impose une règle : on ne devine pas leur métier. Le protocole de recherche a donc combiné quatre sources, dont deux quantitatives.
Entretiens en profondeur de 60 minutes
Immersions contextuelles en cabinet, sur le poste réel de travail
Tris de cartes pour valider l’architecture de l’information
Recrutement : trois segments, biais exclus
Le recrutement a distingué trois populations aux besoins opposés : les cabinets d’expertise comptable (usage intensif, très haute littératie), les TPE à faible littératie comptable (usage subi, vocabulaire métier mal maîtrisé) et les utilisateurs ayant résilié — le segment le plus instructif et le plus souvent oublié. Les biais connus ont été exclus du recrutement, notamment la sur-représentation des utilisateurs avancés volontaires.
18 mois de tickets support comme signal quantitatif
L’analyse de dix-huit mois de tickets a donné ce que douze entretiens ne pouvaient pas donner : une hiérarchie des frictions par volume réel. Elle a mis en évidence des points de blocage récurrents concentrés sur un petit nombre d’écrans à forte densité — c’est là que la refonte a porté en priorité.
« Je ne veux pas que ce soit plus joli. Je veux voir mes écritures sans scroller trois fois. »
Ce que l’observation a révélé
Les immersions en cabinet ont montré des usages invisibles depuis un entretien : raccourcis clavier appris par cœur, écrans dédoublés sur deux moniteurs, feuilles de calcul intermédiaires, et surtout une intolérance totale à tout changement qui casse un automatisme de saisie. Toute refonte devait donc préserver les mécaniques d’usage expertes tout en corrigeant la lisibilité.
03
Exploration & solution
Principe directeur : densifier sans encombrer
Le travail n’a pas consisté à retirer de l’information mais à lui donner une structure : hiérarchie typographique stricte, alignements et rythme verticaux réguliers, séparation nette entre les zones de lecture et les zones de saisie, regroupement des actions par fréquence d’usage réelle plutôt que par logique de menu.
Architecture de l’information validée par tri de cartes
Les neuf sessions de tri de cartes ont permis de construire une arborescence issue du vocabulaire des utilisateurs et non de l’organisation interne des modules. Les écarts entre le tri des cabinets et celui des TPE ont été traités par une navigation stable complétée d’un accès direct, plutôt que par deux arborescences concurrentes.
Écrans denses : les partis pris
- Tableaux : en-têtes persistants, colonnes prioritaires figées, alignement numérique sur chiffres tabulaires, densité réglable plutôt qu’imposée.
- Saisies multi-critères : validation au fil de l’eau, messages d’erreur au plus près du champ, préservation stricte de l’ordre de tabulation attendu par les utilisateurs experts.
- États comptables : lecture d’abord, action ensuite — les commandes secondaires sortent du flux de lecture principal.
Une refonte visuelle plus ambitieuse avait été envisagée. Les immersions ont montré qu’elle casserait des automatismes de saisie construits sur plusieurs années. Nous avons préservé les mécaniques d’interaction et concentré l’effort sur la lisibilité et la structure : le gain d’usage était réel, le coût de réapprentissage nul.
Ateliers de restitution
Chaque phase s’est conclue par un atelier réunissant Product Owners, Product Managers et équipes de développement : présentation des résultats de recherche, arbitrages, et traduction directe en éléments de backlog.
04
UI & design system
Le design system a été conçu sous Figma pour être consommé simultanément par des modules Web et Desktop, en s’appuyant sur les standards Material Design et Ant Design — Material pour les fondations d’interaction, Ant Design pour la richesse de ses patterns de données, particulièrement adaptés aux interfaces de gestion.
Structure du système
- Design tokens alignés sur les variables front-end, pour que le vocabulaire de la maquette soit littéralement celui du code.
- Bibliothèque de composants avec états complets — repos, survol, focus, actif, désactivé, chargement, erreur, vide — parce qu’en logiciel de gestion les états secondaires représentent l’essentiel du temps d’écran.
- Patterns réutilisables pour les objets récurrents du domaine : tableau de données, formulaire de saisie multi-critères, filtre avancé, état comptable.
- Documentation tenue sous Figma et Notion : quand utiliser un composant, quand ne pas l’utiliser, cas limites, critères d’accessibilité.
Gouvernance
Un design system sans gouvernance diverge en un trimestre. J’ai mis en place des ateliers d’alignement réguliers avec les PO, PM et développeurs, des design reviews sur les nouvelles contributions, et une QA d’interface sur les builds de recette pour vérifier l’écart entre la maquette et le rendu réel avant mise en production.
Accessibilité dans les fondations
Les critères WCAG et RGAA ont été intégrés au niveau des composants : contrastes vérifiés sur tous les états, cibles de clic dimensionnées, focus visible dessiné explicitement, structures de tableaux correctes. Traiter l’accessibilité dans le système évite de la retraiter dans chaque écran.
05
Impact & apprentissages
Un design system unique consommé par plusieurs équipes
Segments utilisateurs distincts couverts, dont les utilisateurs résiliés
De tickets support analysés comme signal quantitatif
Ce que je retiens
Les utilisateurs résiliés sont le meilleur panel. Ils n’ont plus rien à ménager et décrivent précisément le moment où le produit a cessé d’être supportable. Aucun autre segment ne donne cette information.
Le support est un instrument de mesure. Dix-huit mois de tickets hiérarchisent les frictions par volume réel — une priorisation que ni l’intuition produit ni douze entretiens ne peuvent produire seuls.
En interface experte, la stabilité vaut mieux que l’élégance. Casser un automatisme de saisie coûte plus cher à l’utilisateur que ne lui rapporte une amélioration visuelle. La contrainte se déplace : il faut améliorer sans déplacer.
Ce que je ferais autrement. J’installerais la QA d’interface sur les builds de recette dès le premier composant livré, et non à mi-parcours : plusieurs écarts entre maquette et rendu ont été rattrapés plus tard qu’ils n’auraient dû l’être.