# Refonte d’un outil métier : retouche, remplacement ou transition progressive ? > Votre outil interne a dix ans, un seul sachant et aucune liaison. Trois façons de le refondre, les critères pour choisir, et le rôle du pilote côté client. Publié le 6 novembre 2025 · Valentin Souvay, fondateur et consultant en transformation numérique (Onilys) Source : https://onilys.fr/blog/refonte-outil-metier-retouche-remplacement-transition-progressive/ Un outil développé il y a dix ans, connu d’une seule personne, lent et isolé : faut-il le retoucher, le remplacer, ou le remplacer morceau par morceau ? Les critères qui font la différence, et ce qu’il faut préserver pour les utilisateurs. ## En bref - Trois voies : refaire l’interface, tout remplacer d’un coup, ou remplacer module par module. - Quatre critères pour choisir : criticité, dette (règles enfouies dans le code), compétences disponibles, capacité des équipes à absorber le changement. - Un diagnostic de quelques semaines produit la carte sur laquelle se décide la voie. - Préserver les gestes des utilisateurs, et confier le pilotage à quelqu’un d’indépendant du développeur. « Il faut tout refaire, ou on peut sauver ce qu’on a ? » C’est une question qu’on nous pose souvent à propos d’un outil interne. Elle arrive presque toujours avec la même description. Un logiciel développé il y a une dizaine d’années, par un prestataire qui a disparu ou par un salarié encore là, mais seul à savoir comment il fonctionne. Il est lent le lundi matin et relié à rien : les commandes qu’il contient sont ressaisies dans la comptabilité, les plannings qu’il produit sont recopiés dans un tableur. Et pourtant, tout le monde s’en sert, parce qu’il fait exactement ce que fait l’entreprise. Ce peut être l’outil qui gère les affaires d’un fabricant de structures métalliques, de la consultation jusqu’à la pose. Ou celui qui suit les engins d’un service matériel, leurs contrôles réglementaires et leurs affectations par chantier. La réponse honnête est : cela dépend. Mais cela dépend de choses précises, qu’on peut regarder. ## Trois façons de s’y prendre, et ce qu’elles coûtent vraiment La retouche d’interface est la voie la plus tentante. On garde le moteur, on refait les écrans. En quelques semaines, l’outil a l’air neuf, il fonctionne sur tablette, les boutons sont lisibles. Le coût est faible et le risque aussi. Mais les problèmes de fond restent intacts : la base de données mal structurée, les règles de calcul enfouies dans un code que personne ne sait lire, l’absence de liaison avec les autres outils. On a repeint une maison dont la charpente travaille. Cela se justifie quand le fond est sain et que seul l’écran a vieilli, ou comme première étape avant une refonte plus lourde, à condition de le dire. Le remplacement complet est la voie propre. On repart d’une page blanche, on décrit le métier tel qu’il est aujourd’hui, on construit ou on choisit un outil neuf, et un jour donné, on bascule. Tout est cohérent, documenté, relié dès le départ. Le coût est élevé, la durée se compte en mois, parfois en année, et le risque est concentré sur un seul moment : la bascule. Ce jour-là, on découvre les cas que personne n’avait décrits. Les régressions, c’est-à-dire ce que l’ancien outil faisait et que le nouveau ne fait plus, apparaissent dans les semaines qui suivent, quand les équipes ont perdu leurs habitudes et pas encore pris les nouvelles. La transition progressive est la voie du milieu, et celle que nous recommandons le plus souvent. On découpe l’outil en modules : la gestion des affaires, le planning, la facturation, les contrôles. On en reconstruit un, on le relie à l’ancien outil, on le met en service. Pendant un temps, les deux coexistent : on saisit les affaires dans le nouveau module et on consulte encore le planning dans l’ancien. Puis on passe au module suivant. C’est moins élégant, cela demande des passerelles temporaires, et la cohabitation doit rester courte pour ne pas devenir permanente. Mais chaque étape est petite, chaque bascule réversible, et les équipes absorbent le changement par morceaux. ## Quatre critères pour trancher Ce qui décide entre les trois voies, ce sont quatre questions, à poser dans cet ordre. - **La criticité.** Que se passe-t-il si l’outil s’arrête une journée ? Si la réponse est « les chantiers continuent, on rattrape le lendemain », vous avez de la marge pour une transition progressive. Si la réponse est « on ne sait plus quel camion part où », la retouche en attendant mieux est exclue, et la transition devra commencer par le module le plus critique, avec un plan de repli. - **La dette.** Combien de règles métier sont enfouies dans le code sans être écrites ailleurs ? Un outil dont les règles sont connues et documentées se remplace proprement. Un outil dont les règles ne sont connues que de lui-même se remplace par morceaux, parce que chaque module reconstruit est l’occasion de les redécouvrir une à une. - **Les compétences disponibles.** Le sachant est-il encore là, et pour combien de temps ? S’il part dans un an, la transition progressive doit démarrer maintenant, avec lui. S’il est déjà parti, le remplacement complet est parfois la seule voie, parce que personne ne peut plus relier quoi que ce soit à l’ancien outil. - **La capacité des équipes à absorber le changement.** Une entreprise en pleine saison, ou qui vient de changer d’ERP, n’absorbera pas une bascule complète. Une transition par modules, calée sur les creux d’activité, passe mieux. C’est le critère qu’on oublie le plus, et celui qui fait échouer le plus de projets. ## Le diagnostic d’abord, et les repères des utilisateurs ensuite Avant de choisir, il faut regarder. Un diagnostic de deux à trois semaines suffit en général : lire le code quand c’est possible, inventorier les écrans et les règles, interroger les utilisateurs sur ce qu’ils font vraiment avec l’outil, et surtout sur ce qu’ils font à côté. Il produit une carte : les modules, leurs liaisons, leur criticité, les règles reconstituées. C’est sur cette carte que se décide la voie, pas sur une impression de lenteur. Il y a une chose que le diagnostic doit aussi relever, et que les projets de refonte sacrifient trop vite : les repères des utilisateurs. Un conducteur de travaux qui saisit ses heures depuis dix ans dans le même écran a des gestes. Il sait que le code chantier se tape en premier, que la liste des engins est triée dans tel ordre. Ces gestes ne sont pas de la résistance au changement, ce sont du temps gagné. Un nouvel outil qui les casse tous d’un coup sera contourné, même s’il est meilleur. Préserver le vocabulaire, l’ordre des champs, les raccourcis qui comptent, quitte à moderniser tout le reste, est ce qui fait qu’une refonte est adoptée en une semaine plutôt que subie pendant six mois. Pour [la refonte de l’expérience utilisateur d’un outil métier du Défenseur des droits](https://onilys.fr/cas-clients/defenseur-des-droits-outil-support/), la nouvelle expérience a été construite avec les utilisateurs, en ateliers, puis testée avec eux, et une première version a été livrée en un mois. Partir de leurs gestes plutôt que d’une maquette idéale permet d’aller vite sans les perdre. ## Un pilote côté client, qui n’est pas le développeur Un montage revient souvent : le prestataire qui développe le nouvel outil est aussi celui qui définit ce qu’il doit faire, décide des priorités et valide son propre travail. Ce n’est pas de la mauvaise foi, c’est qu’il n’y a personne en face. Le dirigeant n’a pas le temps, le sachant est juge et partie, les utilisateurs sont consultés à la fin. Une refonte a besoin d’un pilote côté client. Quelqu’un qui tient la liste des règles métier et vérifie qu’elles sont toutes reprises. Qui arbitre entre ce que les utilisateurs demandent et ce que le projet peut porter. Qui organise les tests avec les équipes avant chaque bascule, a le droit de dire non à une mise en service, et veille à ce que la cohabitation des deux outils ne s’éternise pas. Ce rôle demande du temps, de la méthode, et une indépendance vis-à-vis de ceux qui développent. Dans une PME, ce rôle existe rarement en interne, et c’est souvent celui que nous tenons : le diagnostic, le choix de la voie, puis le pilotage jusqu’à la mise en production, au forfait, sans outil à vendre et sans développement à défendre. Le prestataire reste libre de construire, le client reste maître de ce qu’il obtient. C’est le sens de notre expertise [cadrer et piloter un projet numérique](https://onilys.fr/expertises/cadrer-et-piloter/). Si votre outil a dix ans et un seul sachant, commencez par la carte, pas par le devis. Et si vous voulez d’abord mesurer ce que cet outil vous coûte en ressaisies, notre [workshop d’automatisation](https://onilys.fr/workshop-automatisation/), une demi-journée sur un seul processus avec les personnes qui le font, est une bonne façon d’ouvrir le sujet.