La refonte technique est un passage obligé pour 100% des entreprises (qui veulent continuer à faire du business). Et pourtant, faute de savoir par quel bout commencer, l’erreur n°1 est de repousser la refonte jusqu’à ce qu’elle devienne inévitable. Avec une situation explosive.
Il y a 1001 manières de s’y prendre pour gérer son projet de refonte. La règle principale à respecter : ne pas laisser les équipes tech seules face à la dette.
J’aimerais dans cet article vous partager mes dix années d’expérience en gestion produit, en tant que CPO.
Et répondre à la question clé : comment aborder votre refonte de manière stratégique ?
Les points clés de mon approche :
Commençons par les pièges à éviter, avant d'aborder une stratégie qui équilibre dette et innovation.
Lorsqu'il s'agit de réussir une refonte, certaines erreurs peuvent coûter cher et retarder significativement votre projet. En tout et pour tout, j’ai eu l’occasion d’intervenir / piloter plus de 8 refontes techniques, en startup ou dans de plus grosses structures.
Voici les pièges les plus courants à éviter pour assurer une transition en douceur et maximiser les bénéfices de votre refonte :
La plupart des refontes sont lancées suite à un blocage technique (obsolescence, latence, scalabilité), avec des objectifs purement technologiques. Alors que comme toute évolution logicielle, une refonte doit servir les besoins de vos utilisateurs.
Une refonte qui va durer des mois ou des années peut devenir un véritable levier stratégique pour l’entreprise :
En alignant objectifs stratégiques et contraintes technologiques, cette modernisation du logiciel peut accélérer la croissance, ouvrir de nouveaux marchés, améliorer l’expérience client et optimiser les opérations internes.
En début de refonte, tout le monde semble aligné sur le fait que gérer la dette est une priorité. Mais plus la refonte avance, plus les urgences clients et marché deviennent pressantes.
Si les objectifs de refonte n’étaient pas partagés, la situation devient de plus en plus tendue.
Assurez-vous dès le départ que toutes les parties prenantes, des développeurs aux dirigeants, sont alignées sur les objectifs et les attentes du projet. Et communiquez de manière régulière sur la valeur apportée (de manière itérative) par la refonte.
La première cause des refontes qui échouent c'est le manque d'investissement dans la planification.
Une refonte technique est généralement un projet au long court, qui ne s’improvise pas. Elle nécessite une feuille de route détaillée, incluant des étapes claires, des délais réalistes et une allocation précise des ressources.
Sans une planification rigoureuse, les projets dérivent, les coûts explosent, et les délais s'allongent. Sans compter la démotivation des équipes et potentiellement le turn-over.
Lorsqu’il y a plus de trois squads de développement, les refontes techniques sont généralement pilotées par un chef de projet dédié.
Pour se faire la main en début de refonte et créer un nouveau produit simplifié, il est tentant de commencer par des quick wins et de reporter la migration des clients stratégiques.
Mais ce choix met en péril toute la roadmap :
Attendre la fin de la migration revient à créer une bombe à retardement. Autant que possible, intégrez les clients et sujets stratégiques dès le début du projet, pour vous offrir le luxe du temps : le temps de migrer et d'itérer sur les fonctionnalités clés.
💡 Astuce terrain : un de mes clients a créé un 'Copil de refonte' avec ses clients historiques, pour s'assurer de leur soutien tout au long du projet.
Au vu de l’investissement nécessaire pour faire une refonte, il peut être tentant de repartir de zéro et de lancer un projet d’envergure finalisé et livré pour une date précise, culminant par un grand lancement. Mais cette approche "big bang" est la plus risquée :
Pensez à la refonte (ratée) de l’application SNCF Connect, déboulonnée dans la presse.
Autant que possible, adoptez plutôt une approche itérative ou a minima une longue phase de beta. Déployez les changements par phases pour tester les modifications sur un échantillon restreint d'utilisateurs et ajuster la stratégie de refonte au plus tôt.
Votre refonte est un levier d’engagement marketing, avec de la communication en continu sur les nouveautés.
💡 Astuce terrain : ne pas confondre legacy (la dette) et héritage (l'historique à conserver).
Le lancement d'un projet de modernisation du logiciel crée rapidement deux trajectoires au sein de l'entreprise :
Le choix d'isoler des équipes dédiées à la maintenant de l'existant, ou de créer des équipes mixtes maintenance/modernisation sur des pans fonctionnels a un impact majeur sur la dynamique des équipes.
Pour ne pas désengager une partie des équipes et capitaliser sur la connaissance de l'existant, un plan de rétention des collaborateurs avec une montée en compétences sur des nouvelles technologies et pratiques est à mettre en place dans les deux cas.
Pour consolider les équipes investissez dans :
C’est cet investissement dans la culture, en parallèle de l’investissement technologique, qui évitera de reproduire les erreurs qui ont conduit à la refonte. Afin que le produit livré en fin de refonte n’ait pas besoin... d'être refondu à son tour.
La dette technique est l'accumulation de compromis et de raccourcis pris au fil du temps pour des raisons de rapidité ou de coût.
La plupart du temps, la dette a été créée de manière itérative, à force de patchs, et n’est pas documentée. Cette connaissance informelle crée un risque important de régression lors de la refonte, notamment si l’équipe a peu d’ancienneté sur le produit par exemple lors du départ d’un fondateur.
Identifiez et adressez la dette existante dès le départ, puis investissez le temps nécessaire pour comprendre la “root cause” et la raison primaire qui a causé l’apparition de patchs et de dette technique. Ceci afin d’éviter que les mêmes problèmes ne resurgissent dans le nouveau système.
💡 Astuce : pensez à multiplier le temps estimé de refonte des briques logicielles impactées par le poids de la dette technique.
Voyons maintenant comment maximiser l’impact d’une refonte, et gérer ce bon équilibre. Autrement dit : comment transformer un projet de refonte technique en une réussite business.
La réussite d'une refonte technique repose avant tout sur la valeur ajoutée du nouveau produit, à la fois aux utilisateurs et au marché.
Une refonte technique qui ne fait qu’améliorer la qualité du code, en reprenant de manière “ISO” l’existant, engendre plus de risques que de bénéfices : le temps de la refonte, le marché a évolué et le nouveau code qui vient d’être créé est potentiellement déjà obsolète.
Ma conviction : surtout lorsqu’il s’agit d’une refonte conséquente, apporter de la valeur doit rester le fil conducteur de votre démarche 🙌
La dette technique est un concept clé dans toute refonte technique. Elle représente l'accumulation de décisions techniques rapides ou de compromis qui peuvent ralentir votre développement à long terme.
Autrement dit, c’est un sujet prioritaire à aborder dans tout projet de refonte 😁
Après des années sans gérer la dette technique, la tentation est grande de se concentrer uniquement sur sa résorption.
Le risque : après quelque mois à plein régime sur la dette, les demandes clients et marché vont devenir de plus en plus pressantes. Dans le pire des cas, le comité de direction demandera une “pause” de la refonte technique.
Imaginez plutôt votre parcours de refonte avec une jauge de points de vie, comme dans un jeu vidéo. Lorsqu’on se concentre sur la dette, la jauge de désirabilité (et donc viabilité) du produit diminue à mesure que le marché évolue. Lorsqu’on ajoute des innovations, elle se remplit.
L’objectif d’une stratégie produit, dans le cadre d’une refonte technologique, est de gérer cette jauge de manière équilibrée :
Un bon product manager jongle entre ces deux besoins critiques pour la pérennité de son produit.
L'innovation est nécessaire pour rester compétitif, mais négliger la dette technique finira par freiner cette même innovation.
Pour prioriser la refonte technique, il est utile de la visualiser à l'aide d'une matrice qui évalue la valeur qui peut être ajoutée par rapport à la dette accumulée :
Ces opportunités vont vous permettre de réduire efficacement la dette technique, tout en apportant dès le début de la refonte de la valeur ajoutée client ou marché. Ce n’est pas forcément le plus simple à faire, mais c’est ce qui aura le plus d’impact bénéfique sur votre entreprise. Pensez-y : même si la refonte est mise en pause, un vous aurez un début de base solide sur lequel construire.
Remplacer ou supprimer des fonctionnalités prend du temps, et nécessite beaucoup d’accompagnement des clients existants. Mais retarder cette échéance augmente le coût de la maintenance de ces fonctionnalités, et peut allonger considérablement la refonte.
La procrastination est votre pire ennemi pour ce type d’opportunité : intégrez-les au fur et à mesure de la refonte, pour décommissionner en douceur les modules ou prendre le temps de trouver le bon partenaire vers lequel rediriger les clients existants.
Développez et communiquez sur votre stratégie de refonte, et son impact non seulement sur la dette technique mais aussi sur la valeur apportée aux utilisateurs et au marché. La communication interne sera la clé d’une refonte soutenue et portée en interne hors des équipes techniques.
Ce projet de refonte doit avoir son propre product marketing, et être perçu comme un projet hautement stratégique puisqu’il touche au cœur de valeur de votre entreprise : son produit.
Vous connaissez désormais les pièges à éviter pour votre prochaine refonte technique.
Cependant, chaque refonte technique est unique, selon votre produit et votre contexte d’entreprise.
Prêt à transformer votre produit ? Contactez-moi pour discuter de votre projet de refonte technique !