01 — Situation
Plusieurs produits.
Plusieurs héritages.
Le portefeuille regroupait des produits issus d’histoires différentes : rachats, générations techniques successives, habitudes locales et contraintes métier fortes.
Chaque produit avait une logique propre. Certaines interfaces répondaient à des usages très spécifiques, d’autres portaient encore les traces d’arbitrages anciens. Le sujet n’était donc pas de tout uniformiser, mais de rendre les parcours plus lisibles sans casser ce qui permettait aux utilisateurs de travailler.
- Produits hétérogènes
- Des interfaces, stacks et conventions qui ne racontaient pas toujours la même chose.
- Parcours longs
- Formulaires, étapes, statuts, exceptions et retours métier accumulés.
- Règles implicites
- Des décisions clés connues par les équipes, mais peu visibles dans l’interface.
- Refonte risquée
- Changer trop vite pouvait fragiliser des usages installés et coûteux à réapprendre.
02 — Cartographie
Comprendre avant
de simplifier.
Nommer la complexité utile.
Distinguer ce qui relève du métier, de l’historique produit, de la contrainte technique et de l’habitude d’interface.
J’ai commencé par reconstituer les parcours réels : étapes suivies par les utilisateurs, informations manipulées, décisions prises, dépendances entre écrans et points de friction récurrents.
Cette cartographie a permis d’éviter les raccourcis. Certaines lourdeurs étaient inutiles, d’autres protégeaient une règle métier importante. La qualité du travail venait de cette distinction.
03 — Clarification
Réorganiser l’écran.
Rendre la décision visible.
Regrouper
Rapprocher les informations qui servent à une même décision, au lieu de suivre l’ordre historique des données.
Hiérarchiser
Séparer lecture, action, statut et exception pour réduire l’effort de compréhension.
Stabiliser
Transformer les solutions récurrentes en patterns réutilisables sur plusieurs parcours.
Décision structurante
Ne pas chercher une interface plus courte à tout prix, mais une interface où l’utilisateur comprend plus vite ce qu’il doit vérifier, décider ou corriger.
04 — Arbitrage
Avancer par valeur.
Pas par grand soir.
Dans un contexte legacy, la bonne trajectoire n’est pas toujours la refonte la plus visible. C’est souvent celle qui réduit le plus de confusion avec le moins de risque.
- 01
Identifier les irritants
Repérer les écrans où l’utilisateur hésite, contourne ou sollicite l’équipe support.
- 02
Qualifier le risque
Comparer impact utilisateur, dette technique, fréquence d’usage et dépendances produit.
- 03
Choisir le bon niveau
Décider ce qui doit être corrigé localement, transformé en pattern ou remonté au Design System.
- 04
Tester la compréhension
Vérifier que la nouvelle organisation réduit réellement les hésitations, pas seulement le nombre d’éléments.
05 — Transmission
Transformer les choix
en repères d’équipe.
Les décisions importantes ont été documentées sous forme de principes simples : quand regrouper, quand séparer, comment traiter les exceptions, comment rendre un statut actionnable.
Ce travail a permis aux équipes Product et Engineering de réutiliser les arbitrages au-delà de l’écran traité, sans dépendre d’une validation permanente du design.
- Écran critiqueClarifier le parcours et les décisions attendues
- Pattern récurrentStabiliser les usages réutilisables
- PortefeuilleFaire circuler les repères entre produits
06 — Impact
Des produits plus lisibles.
Des décisions plus faciles à reprendre.
Des parcours plus faciles à comprendre, même quand le métier reste complexe.
Des priorités mieux arbitrées entre valeur immédiate, dette et trajectoire long terme.
Des évolutions mieux cadrées, avec moins d’ambiguïté sur le comportement attendu.
Des patterns qui dépassent le cas isolé et nourrissent la cohérence du portefeuille.
Ce que je retiens
Dans un produit métier, simplifier ne veut pas dire réduire. Cela veut dire rendre explicite ce qui aide l’utilisateur à décider, et retirer ce qui l’oblige à deviner.