Dans les organisations tech, les refontes de systèmes legacy ou de briques techniques obsolètes sont souvent abordées comme une simple reproduction à l’identique, dite iso-fonctionnelle.
Cette approche peut sembler sécurisante, mais elle cache des pièges majeurs qui mènent à des échecs coûteux et à une perte de valeur.
Basé sur l’expérience de la refonte du backoffice de Meetic (backoffice de plus de 20 ans), cet article explore pourquoi les refontes iso-fonctionnelles sont un antipattern, en particulier pour les systèmes complexes et legacy, et comment une approche produit, centrée sur l’utilisateur et itérative, transforme ces projets en opportunités d’innovation.
Les dérives des refontes iso-fonctionnelles
L’approche iso-fonctionnelle consiste à reconstruire un système existant à l’identique, sans remise en question, en se basant sur un audit purement technique. Voici les principales dérives qui en découlent :
- L’audit technique comme point de départ : on se concentre sur les problèmes techniques (langages obsolètes, serveurs vétustes, code inextricable), sans analyser les besoins réels des utilisateurs. Cela mène à une reproduction fidèle mais aveugle, ignorant les usages prioritaires et les frictions réelles.
- La tentation du copy-paste : les spécifications se limitent à répliquer l’existant, souvent via une approche waterfall rigide. Les risques sont superposés sans priorisation, gonflant artificiellement les charges et coûts.
- Absence de vision utilisateur : les systèmes legacy, construits par accumulation, regorgent de fonctionnalités historiques désormais inutiles. Les dupliquer, c’est perpétuer des incohérences et complexités, au lieu d’en profiter pour rationaliser et simplifier.
Ces dérives transforment un projet nécessaire en un gouffre temporel et financier, où la technique prime sur la valeur.
Conséquences sur l’organisation et les équipes
Adopter une refonte iso-fonctionnelle entraîne des impacts négatifs lourds, bien au-delà du simple aspect technique :
- Dépassements massifs de budget et délais : les équipes planifient souvent des projets de plusieurs années, mais la complexité cachée engendre retards, abandons ou livraisons partielles.
- Perte de valeur ajoutée : le nouveau système est parfois moins efficace que l’ancien, car il hérite des mêmes workflows lourds. Les utilisateurs finaux restent frustrés, faute de réelle amélioration de leur quotidien.
- Démotivation des équipes tech : réduits à des “copieurs”, les développeurs perdent sens et motivation. La dette technique est reproduite, la maintenance reste un calvaire, et le risque d’incidents en production augmente.
- Dette organisationnelle : les processus restent figés, car la refonte échoue à remettre en cause les habitudes obsolètes. Le changement devient repoussé plutôt qu’embrassé.
Résultat : une organisation verrouillée, incapable de générer un ROI positif, et de s’adapter rapidement aux évolutions du marché.
Une posture technique déplacée
Dans une refonte iso-fonctionnelle, la technique dicte la marche à suivre. Cette posture est déconnectée des réalités métier :
- Priorité à la reproduction fidèle : les critères de succès sont techniques, pas métier. On reste prisonnier de l’existant.
- Manque de collaboration : en travaillant en silo, l’équipe tech évacue la voix des utilisateurs métier, ce qui renforce les écarts de compréhension.
- Relation de dépendance et contrôle top-down : au lieu d’autonomiser les équipes produit/tech par une approche responsable, on maintient une logique de commande-exécution.
La refonte devient alors un rituel stérile, et non un levier d’évolution.
Comment réussir une refonte technique ?
Pour transformer les refontes en succès, il faut rompre avec le réflexe iso-fonctionnel et adopter une approche produit authentique.
L’idée centrale est de traiter la refonte comme un nouveau produit, et non comme un exercice de duplication.
Clarifier le rôle de l’approche produit
- Compréhension des besoins réels utilisateurs avant de coder.
- Orientation vers l’impact business et opérationnel, et non seulement vers la dette technique.
- Travail sur le système global (organisation, workflows, gouvernance).
Principes d’une approche produit réussie
- Traiter comme un nouveau produit : l’existant devient une source d’inspiration, pas une liste de specs figées.
- Définir une vision claire et mesurable : alignée sur la satisfaction utilisateur et les outcomes (ex. réduire le temps de traitement, améliorer la qualité des données, fluidifier les opérations).
- Construire une roadmap par résultats (outcome-based) : prioriser en fonction d’impacts concrets sur les usages, pas en backlog figé.
Mise en œuvre pratique
- Story mapping et backlog MVP : simplifier en priorisant les parcours les plus critiques. Utiliser des ateliers collaboratifs (event storming, design thinking) pour construire collectivement.
- Cadre agile adapté (Scrum ou Kanban hybride) : cadencer les développements en sprints, valider via des démos régulières.
- Double Run pragmatique : cohabitation de l’ancien et du nouveau jusqu’à stabilisation, en minimisant les risques de bascule.
Ce modèle renforce l’alignement stratégique, stimule la motivation des équipes et sécurise la réussite de la refonte.
Et maintenant ?
Les refontes iso-fonctionnelles sont un piège à éviter absolument.
Elles semblent plus simples, mais elles enferment l’organisation dans le passé, démotivent les équipes et aboutissent à des projets coûteux sans impact réel.
À l’inverse, une approche Produit centrée sur l’utilisateur, incrémentale et orientée business transforme une contrainte comme la reconstruction d’un legacy en avantage compétitif.
👉 Vos refontes ne doivent pas être des copies, mais des opportunités de repenser vos systèmes à la lumière de vos enjeux réels.
