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 "as is". Cette approche semble 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 "as is" sont un antipattern, particulièrement pour les systèmes complexes et legacy, et comment une approche produit, centrée sur l'utilisateur et itérative, garantit le succès en transformant ces projets en opportunités d'innovation.
Les dérives des refontes "as is"
L'approche "as is" consiste à reconstruire un système existant 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, ignorant la complexité cachée sous la surface, comme un iceberg.
- La tentation du copy-paste : Les spécifications se limitent à répliquer l'existant, en suivant une méthode waterfall rigide. Les équipes tech estiment des milliers de jours-hommes en superposant les risques, sans priorisation.
- Absence de vision utilisateur : Les legacy, accumulés sur des années, intègrent des fonctionnalités inutiles ou obsolètes. Sans remise en question, on perpétue ces incohérences, en ignorant l'évolution des besoins métier.
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 "as is" pour des briques techniques ou legacy entraîne des impacts négatifs profonds, freinant l'innovation et l'efficacité :
- Dépassements massifs de budget et délais : Les estimations gonflées mènent à des projets qui s'étirent sur des années, souvent abandonnés ou incomplets, avec des coûts imprévus dus à des complexités non anticipées.
- Perte de valeur ajoutée : Le nouveau système est souvent moins performant que l'ancien, car il reproduit les mêmes dysfonctionnements sans optimisation. Les utilisateurs finaux (comme les agents de service client) restent frustrés par des interfaces austères et des workflows inefficaces.
- Démotivation des équipes : Les développeurs se sentent réduits à des exécutants, sans espace pour innover. Pour les legacy, cela perpétue une dette technique, rendant la maintenance future encore plus ardue et augmentant les risques de bugs en production.
Résultat : une organisation bloquée, avec un ROI négatif et une incapacité à s'adapter aux changements marché.
Une posture technique déplacée
Dans une refonte "as is", la technique domine, créant une posture déconnectée des réalités métier :
- Priorité à la reproduction fidèle : On valide les choix sur des critères purement tech, sans impliquer les utilisateurs, ce qui crée une dépendance à l'existant et bloque les améliorations.
- Manque de collaboration : Les équipes tech travaillent en silo, sans feedback métier, imposant une vision rigide incompatible avec l'agilité.
- Relation de dépendance : Au lieu de responsabiliser les équipes sur la valeur, on maintient un contrôle top-down, freinant la maturité et perpétuant les legacy comme fardeaux.
Cela mine l'autonomie et transforme la refonte en un exercice futile.
Alors, comment faire pour que les refontes techniques réussissent enfin ?
Pour éviter ces pièges et transformer les refontes en succès, adoptez une approche produit authentique. La clé ? Traiter la refonte comme la création d'un nouveau produit, centré sur l'utilisateur et itératif, en utilisant l'existant seulement comme source de données.
Clarifier le rôle de l'approche produit
- Elle facilite la compréhension des besoins réels, aidant l'équipe à intégrer des pratiques lean.
- Elle soutient la quête d'impact, d'autonomie et de valeur, en coachant plutôt qu'en dirigeant.
- Elle agit sur le système global, pas seulement sur les livrables techniques, en identifiant les obstacles métier.
Principes d'une approche produit réussie
- Traiter comme un nouveau produit : Oubliez le copy-paste ; utilisez l'existant pour inspirer, pas pour dicter.
- Vision et objectifs clairs : Définissez une vision centrée sur les utilisateurs (ex. : agents de service client chez Meetic). Identifiez les outcomes : résolution rapide des problèmes, optimisation des coûts, amélioration de l'expérience.
- Roadmap outcome-based : Priorisez les résultats mesurables (ex. : réduction du temps de traitement des requêtes), via des use cases et classements de besoins.
Mise en œuvre pratique
- Story mapping et backlog MVP : Cartographiez les journeys utilisateur pour simplifier les workflows. Utilisez l'event storming pour visualiser les interactions complexes et identifier les optimisations.
- Framework Scrum adapté : Itérez avec des sprints, demos et feedbacks pour valider la direction. Chez Meetic, cela a permis une beta rapide, un double RUN sans peur, et des ajustements basés sur des retours réels.
Ce modèle renforce l'alignement, booste l'autonomie et assure que les engagements sont tenus par une équipe empowerée, non par un contrôle externe.
Et maintenant ? Transformez vos refontes
Éviter les refontes "as is" est essentiel pour préserver l'esprit innovant des organisations tech. En misant sur une approche Produit, centrée sur l'utilisateur et itérative, vos équipes délivreront non seulement des systèmes modernes, mais avec un impact métier réel, transformant des legacy en atouts compétitifs.
Si vous souhaitez approfondir mon retour d'expérience : https://www.fluho.fr/blog/article/lapproche-produit-cle-du-succes-des-refontes-techniques
