Réécriture iso-fonctionnelle ou refonte : comment trancher

C'est l'arbitrage le plus structurant d'un projet de migration, et le plus mal posé. « On refait pareil » rassure les utilisateurs mais fige vingt ans d'habitudes, y compris les mauvaises. « On en profite pour tout repenser » séduit la direction mais transforme une migration maîtrisable en projet de transformation à l'issue incertaine. Voici comment nous posons la décision.

Les deux approches en une phrase

L'iso-fonctionnel réécrit le même logiciel sur une technologie moderne : mêmes écrans ou presque, mêmes règles, mêmes habitudes, seul le socle change. La refonte reconçoit le produit à partir des besoins actuels : les processus sont revisités, l'interface repensée, certaines fonctions disparaissent et d'autres naissent. Entre les deux, tout un dégradé existe, et c'est précisément là que se trouve la bonne réponse.

Ce que coûte vraiment l'iso-fonctionnel

L'iso-fonctionnel paraît plus simple : pas de spécifications à réinventer, l'existant fait foi. En réalité, il oblige à reproduire des comportements que personne ne sait plus justifier, à documenter des cas particuliers dont l'utilité a disparu, et à reconstruire des écrans que la technologie cible ferait mieux autrement. Reproduire fidèlement une bizarrerie coûte souvent plus cher que la remplacer par le comportement standard. L'iso strict a un domaine de pertinence : les modules réglementaires ou d'interface avec des tiers, où le comportement est un contrat.

Une situation type

Un exemple revient souvent : un écran de saisie de commande comporte quinze champs optionnels, dont trois seulement sont encore utilisés. Personne ne se souvient pourquoi les douze autres existent, mais reproduire l'écran à l'identique oblige à tous les recoder, tester et documenter. Une fois la question posée aux utilisateurs actuels, il apparaît souvent que ces champs correspondaient à un processus abandonné depuis longtemps. Les supprimer coûte moins cher que les reproduire, et simplifie l'écran pour tout le monde.

Le piège de la refonte opportuniste

Le piège inverse est plus coûteux encore : profiter de la migration pour rouvrir tous les sujets métier. Le périmètre gonfle, les ateliers s'enchaînent, les utilisateurs attendent un outil qui n'arrive pas, et le risque technique de la migration se double d'un risque produit. Règle simple : une migration réussie change le socle OU le métier de façon significative, jamais les deux au maximum en même temps. Les évolutions métier lourdes se planifient sur la cible, une fois la migration digérée.

Ce que nous vérifions à ce stade

• Le périmètre annoncé au démarrage correspond-il encore au périmètre discuté en atelier deux mois plus tard ?
• Chaque évolution proposée a-t-elle un usage identifié, ou repose-t-elle sur une préférence individuelle ?
• Le calendrier de la migration reste-t-il tenable si cette évolution est intégrée maintenant plutôt que sur la cible ?
• Le module concerné est-il sur le chemin critique de la migration, ou peut-il attendre sans risque ?

Grille de décision en 5 questions

• Ce module a-t-il un comportement contractuel (réglementaire, interface tierce) ? Oui : iso-fonctionnel strict.
• Les utilisateurs se plaignent-ils du processus actuel ? Oui : la refonte de ce module a une valeur mesurable.
• La règle métier est-elle comprise et documentée ? Non : la documenter d'abord, décider ensuite.
• Le module est-il utilisé fréquemment ? Rarement utilisé : iso minimal, voire abandon si l'usage a disparu.
• L'écart entre l'existant et le standard de la cible est-il faible ? Oui : adopter le standard coûte moins que reproduire l'écart.

L'approche mixte, souvent la bonne

Dans les faits, presque tous nos dossiers atterrissent sur un mixte assumé : iso-fonctionnel sur le cœur transactionnel qui fonctionne bien, refonte ciblée sur les deux ou trois processus douloureux identifiés avec les utilisateurs, et abandon explicite des fonctions mortes révélées par l'audit. Ce tri se fait module par module, pendant la phase de trajectoire, avec un critère constant : chaque écart à l'iso doit se justifier par une valeur métier nommée, chaque reproduction à l'identique par un usage réel.

Erreurs fréquentes

• Décider du niveau d'iso ou de refonte module par module sans grille de critères écrite, au fil de l'eau.
• Laisser la décision reposer sur une seule personne, sans validation croisée entre technique et métier.
• Rouvrir un arbitrage déjà tranché parce qu'un nouvel interlocuteur rejoint le projet en cours de route.
• Confondre une préférence de confort et un problème métier démontré, au moment de justifier un écart à l'iso.

FAQ