Refonte d’une application métier : méthode, étapes et pièges à éviter

Votre application métier a dix ans, plusieurs couches de fonctionnalités ajoutées au fil des demandes, et vos équipes ont appris à vivre avec ses défauts. La refonte devient inévitable. Mais une refonte mal menée peut faire pire que l’existant : perte de repères, baisse de productivité pendant des mois, rejet par les utilisateurs. Voici la méthode que nous appliquons chez Wolfox.

Refonte UX, refonte technique : de quoi parle-t-on ?

On confond souvent les deux. La refonte technique change la technologie : nouveau framework, nouvelle architecture, migration vers le cloud. La refonte UX change la manière dont l’outil est utilisé : organisation des écrans, parcours, vocabulaire, composants.

Les deux sont souvent menées ensemble, et c’est une bonne nouvelle : une refonte technique est le meilleur moment pour corriger l’expérience. À condition que l’UX ne soit pas réduite à « refaire les maquettes à l’identique avec un design plus moderne ».

Les signaux qu’il est temps de refondre

• Les utilisateurs contournent l’outil avec des fichiers Excel ou des notes à côté.
• La formation d’un nouvel arrivant prend des semaines.
• Chaque nouvelle fonctionnalité alourdit des écrans déjà saturés.
• Plusieurs applications historiques font des choses proches, sans logique commune.
• Le support reçoit toujours les mêmes questions.
• L’outil n’est pas accessible, ce qui exclut une partie de vos collaborateurs et peut vous exposer juridiquement.

Étape 1 : comprendre le travail réel

Une refonte commence sur le terrain, pas dans Figma. Nous menons des entretiens et, surtout, des observations au poste de travail : c’est là qu’on découvre les raccourcis, les doubles saisies et les fichiers parallèles que personne ne mentionne en réunion.

En parallèle, nous analysons l’existant : statistiques d’usage si elles existent, demandes au support, inventaire des écrans et des fonctionnalités. Cet audit UX permet de distinguer ce qui est vraiment utilisé de ce qui ne l’est plus.

Étape 2 : cartographier les processus et prioriser

Nous cartographions ensuite les processus métier avec les équipes : acteurs, étapes, décisions, états d’un dossier, exceptions. Cette carte sert à décider ce que la refonte doit traiter en priorité. Deux critères simples :

• la fréquence : les tâches répétées des dizaines de fois par jour ;
• le coût d’une erreur : les actions où une confusion a des conséquences lourdes.

Tout ne doit pas être refait. Certaines fonctionnalités peuvent être supprimées, d’autres simplement déplacées.

Étape 3 : repenser l’architecture de l’information

C’est souvent le chantier le plus structurant : organiser les menus et les écrans selon la logique du métier, et non selon celle de la base de données ou des modules historiques. Le vocabulaire compte autant que la structure : les libellés doivent reprendre les mots des utilisateurs.

Chez Ampersand, par exemple, la refonte du CRM interne a consisté à fusionner deux outils historiques en une seule interface, avec un travail de fond sur la structure, les parcours et la donnée.

Étape 4 : prototyper et tester avec les utilisateurs

Nous concevons ensuite les écrans clés sous forme de prototypes cliquables, testés avec de vrais utilisateurs sur des scénarios réalistes, y compris les erreurs et les cas particuliers. Les tests mélangent profils experts et nouveaux arrivants : les premiers détectent ce qui les ralentit, les seconds ce qui n’est pas compréhensible.

Étape 5 : construire un design system

Une application métier repose sur des composants très répétitifs : tableaux, filtres, formulaires, statuts, notifications. Les formaliser dans un design system garantit la cohérence entre les écrans, accélère le développement et permet de traiter l’accessibilité une fois pour toutes, au niveau de chaque composant.

Étape 6 : déployer par lots et accompagner le changement

Un « big bang » est rarement la bonne option pour un outil utilisé tous les jours. Nous recommandons une refonte par lots : on commence par les parcours les plus fréquents ou les plus pénibles, on mesure, on ajuste, puis on continue. Cela permet aux équipes de s’approprier progressivement le nouvel outil.

L’accompagnement compte autant que le design : associer des utilisateurs relais dès le début, expliquer ce qui change et pourquoi, prévoir un canal pour remonter les problèmes.

Les pièges à éviter

• Reproduire l’existant à l’identique avec une nouvelle charte : vous gardez tous les défauts.
• Concevoir sans les utilisateurs, à partir des seuls besoins exprimés par la direction ou la DSI.
• Tout refaire d’un coup, au risque de bloquer les équipes pendant la transition.
• Oublier les cas particuliers : ce sont souvent eux qui font perdre le plus de temps.
• Négliger l’accessibilité : le RGAA s’applique aussi aux intranets et progiciels des organismes publics et des grandes entreprises.

Travailler avec votre DSI, votre ESN ou votre éditeur

Une refonte d’application métier implique toujours plusieurs acteurs. Nous intervenons en complément de vos équipes techniques ou de vos prestataires : pour l’intranet du Département de la Seine-Maritime, nous avons travaillé avec l’ESN chargée du développement. Le design system et les prototypes deviennent alors le langage commun entre métier, design et développement.

Combien de temps et quel budget ?

Cela dépend du nombre d’écrans, des profils d’utilisateurs et de l’état de l’existant. Une refonte par lots permet d’étaler l’investissement et de mesurer les gains à chaque étape. Le plus sûr est de commencer par un audit UX : il donne une vision claire des priorités et permet de chiffrer la suite.

Vous préparez la refonte d’un outil interne ? Découvrez notre accompagnement des applications métier ou contactez-nous pour en parler.