Comment moderniser un logiciel professionnel complexe sans casser la productivité de ceux qui l'utilisent tous les jours.
Refondre un logiciel métier n'a rien à voir avec la refonte d'un site vitrine. On ne touche pas à une carte de visite en ligne : on touche à l'outil de travail de gens qui passent leurs journées dedans, qui le connaissent par cœur, et dont la productivité dépend du moindre clic. Une refonte ratée ne déçoit pas, elle fait perdre du temps, de l'argent, et provoque le rejet des équipes.
J'ai mené ce type de projet pour plusieurs éditeurs de logiciel professionnel : la refonte UX/UI complète d'une application métier dense, utilisée par des experts dans un secteur exigeant. Dans cet article, je partage ma méthode, étape par étape, et les pièges qui font dérailler une refonte d'application. Pas de recette miracle : une discipline.
Avant la méthode, il faut comprendre pourquoi c'est un terrain à part. Quatre différences changent tout.
Sur un site grand public, on conçoit pour quelqu'un qui découvre. Sur un logiciel métier, on conçoit pour quelqu'un qui maîtrise déjà : souvent mieux que vous le domaine. On ne lui « explique » pas son métier : on l'aide à aller plus vite.
Sur un site, on aère, on simplifie, on enlève. Sur un logiciel métier, l'utilisateur veut souvent voir beaucoup de choses à la fois : des tableaux, des indicateurs, des données croisées. « Épurer » bêtement un outil dense, c'est le ralentir. Le vrai travail n'est pas d'enlever, c'est de hiérarchiser.
Un écran consulté cent fois par jour n'a pas les mêmes exigences qu'une page vue une fois. Le moindre frottement, multiplié par la fréquence, devient un coût énorme. Ici, l'ergonomie n'est pas du confort : c'est de la productivité directe.
Les utilisateurs ont leurs habitudes, leurs raccourcis, leurs réflexes. Une refonte, même meilleure, casse ces automatismes. La conduite du changement n'est pas une option de fin de projet : elle se pense dès le premier écran.
Une refonte de logiciel métier ne s'improvise pas. Voici le déroulé que je suis, du métier jusqu'à l'intégration.
flowchart TB
A["1. Comprendre le métier"] --> B["2. Auditer l'existant"]
B --> C["3. Architecturer l'information"]
C --> D["4. Concevoir le design system"]
D --> E["5. Maquetter & tester"]
E --> F["6. Accompagner l'intégration"]
classDef step fill:#3C5D42,stroke:#2a4030,stroke-width:2px,color:#ffffff;
class A,B,C,D,E,F step;
linkStyle default stroke:#ffffff,stroke-width:1.5px;C'est l'étape qu'on saute trop souvent et la plus déterminante. Avant la moindre maquette, je m'immerge : entretiens avec les utilisateurs, observation de leur travail réel, compréhension de leur vocabulaire et de leurs cas limites. On ne peut pas redessiner ce qu'on ne comprend pas. Un bon écran métier est d'abord une bonne compréhension du métier traduite en interface.
Le logiciel actuel, même daté, contient une intelligence accumulée. J'audite l'interface en place : ce qui marche (et qu'il faut absolument garder), ce qui coince, ce qui n'est jamais utilisé. Je cartographie les parcours réels, ceux que les gens font vraiment. Cette photo de l'existant évite de jeter ce qui avait de la valeur.
Le cœur du travail. Comment organiser des centaines de fonctions, d'écrans et de données pour que l'utilisateur s'y retrouve sans effort ? Je structure la navigation, je hiérarchise les informations par fréquence et par importance, je définis ce qui doit être visible en permanence et ce qui peut être secondaire. C'est là qu'on transforme une complexité subie en complexité maîtrisée. Concrètement, ça passe par une arborescence des écrans : la carte de tout le produit, des points d'entrée jusqu'aux écrans de détail.
Arborescence des écrans. Exemple générique d'arborescence d'un logiciel métier :
flowchart TB
A["Connexion"] --> B["Tableau de bord"]
B --> M1["Module A"]
B --> M2["Module B"]
B --> M3["Module C"]
B --> SET["Paramètres"]
M1 --> M1a["Liste"]
M1a --> M1b["Fiche détail"]
M1b --> M1c["Édition"]
M2 --> M2a["Liste"]
M2a --> M2b["Fiche détail"]
M3 --> M3a["Vue d'ensemble"]
M3a --> M3b["Rapport / export"]
classDef home fill:#3C5D42,stroke:#2a4030,stroke-width:2px,color:#ffffff;
classDef pole fill:#A2C3A8,stroke:#3C5D42,stroke-width:1.5px,color:#1f3326;
classDef page fill:#E0EBE2,stroke:#A2C3A8,stroke-width:1px,color:#2a4030;
class A,B home;
class M1,M2,M3,SET pole;
class M1a,M1b,M1c,M2a,M2b,M3a,M3b page;
linkStyle default stroke:#ffffff,stroke-width:1.5px;Un logiciel métier, c'est des dizaines d'écrans qui doivent être cohérents et le rester quand de nouvelles fonctions s'ajouteront. Je construis donc un design system : composants réutilisables (boutons, tableaux, formulaires, filtres), règles d'espacement, couleurs, états, typographie. C'est ce qui garantit qu'un écran conçu dans deux ans ressemblera à ceux d'aujourd'hui, et que les développeurs intègrent vite et juste.
Je conçois les écrans sur Figma, puis je prototype les parcours clés pour les rendre cliquables. Un écran qui paraît évident au designer peut être illisible pour l'expert métier. Mieux vaut le découvrir sur une maquette que sur le produit livré. On itère : tester, ajuster, retester.
Le design ne s'arrête pas à la maquette. Je prépare un handoff clair pour les équipes de développement (specs, composants, comportements, états), et je reste disponible pendant l'intégration pour arbitrer les cas réels. Une belle maquette mal intégrée ne vaut rien : la qualité se joue jusqu'au dernier pixel mis en production.
Tout ce travail : wireframes, design system, prototypes, handoff je le mène sur Figma. Ce n'est pas un simple détail d'outillage : c'est ce qui permet à un projet de logiciel métier de rester cohérent, testable et livrable proprement, du premier croquis jusqu'au code.
Je commence par des wireframes basse fidélité : des structures en gris, sans couleur ni détail pour valider l'organisation des écrans tant qu'elle est encore facile à changer. On discute la structure avant d'investir dans le visuel. Puis j'enrichis progressivement jusqu'à la maquette finale, fidèle au produit réel.
Sur Figma, je ne dessine pas des écrans isolés : je crée des composants réutilisables : boutons, champs, tableaux, filtres, cartes avec leurs variantes (normal, survol, désactivé, erreur, sélectionné) et de l'Auto Layout qui les fait s'adapter au contenu. Réunis dans une bibliothèque partagée, et adossés à des variables (couleurs, espacements, tokens), ils forment un design system vivant : on modifie un composant une fois, et toute la maquette se met à jour. C'est ce qui rend gérable et cohérente dans le temps une refonte de plusieurs dizaines d'écrans.
Ces variables permettent aussi de gérer des modes clair et sombre d'une simple bascule : on définit chaque couleur une fois, dans ses deux versions, et toute l'interface s'adapte. Sur un logiciel ouvert toute la journée, le mode sombre n'est pas un gadget : c'est un vrai confort visuel que les utilisateurs réclament de plus en plus.
Figma relie les écrans en un prototype navigable, sans une ligne de code. On prévisualise le produit avant qu'il existe : on le montre au client, on le fait essayer aux utilisateurs, on repère les frictions sur la maquette plutôt que sur le produit livré.
C'est là que la boucle se ferme. Avec le Dev Mode de Figma, les équipes de développement inspectent chaque écran : mesures, espacements, couleurs, typographies, valeurs exactes, extraits de code prêts à l'emploi, variables du design system. J'annote les comportements, je marque les écrans « prêts pour le dev », et je fournis tous les états : pas seulement le cas idéal, mais aussi les écrans vides, en chargement et en erreur. C'est ça, une maquette complète : un cahier des charges visuel qui ne laisse rien à l'interprétation et fait gagner un temps précieux à l'intégration.
Des plugins Figma vérifient les contrastes (norme WCAG), simulent le daltonisme et documentent l'ordre de focus clavier directement dans le fichier de conception. Concevoir accessible dès la maquette, plutôt que corriger après coup, c'est livrer un logiciel utilisable par tous et conforme aux attentes RGAA, fréquentes en B2B et dans les secteurs réglementés.
Ce sont les erreurs qui reviennent le plus souvent et qui coûtent le plus cher.
Refondre un logiciel métier, ce n'est pas « faire du beau ». C'est comprendre un métier, structurer de la complexité, concevoir un système, tester avec des utilisateurs et accompagner des développeurs. C'est un travail de product / UX designer autant que de graphiste : la rencontre entre la rigueur fonctionnelle et l'exigence visuelle.
C'est précisément ce qui me passionne dans ces projets : transformer un outil que les équipes subissaient en un outil qu'elles ont plaisir à utiliser. Quand un utilisateur expert dit « je gagne du temps », c'est la plus belle validation d'une refonte réussie.
Réussir la refonte d'un logiciel métier tient en une idée : respecter ceux qui l'utilisent. Respecter leur expertise (comprendre le métier), leur efficacité (hiérarchiser sans appauvrir), leurs habitudes (accompagner le changement) et leur temps (tester avant de livrer).
La méthode (comprendre, auditer, architecturer, systématiser, tester, accompagner) n'est pas une formalité : c'est ce qui sépare une refonte qui améliore le quotidien d'une refonte qui le complique. Dans un logiciel métier, le design ne se voit pas toujours. Mais il se ressent, chaque jour, à chaque clic.
Vous éditez ou utilisez un logiciel métier dont l'ergonomie freine vos équipes ? Contactez-moi, je vous accompagne de la compréhension du métier jusqu'à l'intégration, pour une refonte qui fait gagner du temps à ceux qui l'utilisent.
Je vous parle de design, de graphisme et je fais des zooms sur certains de mes projets clients. Un bon moyen pour vous de comprendre certains points sur l'identité visuelle, la création de site internet ou de boutique en ligne.
