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 première erreur est de sous-estimer l'importance de 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é.
La refonte doit servir les besoins de vos utilisateurs.
Trop souvent, l’impact des modifications technologiques sur l’usage de la solution est négligé. Les décisions techniques sont prises en vase clos, sans consultation des utilisateurs finaux.
Ce qui peut conduire à des solutions qui ne répondent pas aux attentes des clients, peu évolutives, ou pire à des régressions d’usage. Comme pour toute itération produit, pensez à impliquer vos utilisateurs dès le début de la refonte, et sollicitez leur feedback tout au long du processus.
Lorsque plusieurs choix techniques sont possibles, mettez à plat les impacts fonctionnels de la décision à prendre.
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.
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 dans le temps, plus les urgences clients et marché deviennent pressantes.
Et 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.
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.
Une refonte technique est l'occasion rêvée de revoir les pratiques de développement et de product management. Alors qu’il est tentant de foncer une fois le socle redéfini et enrichi de quelques outils, 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.
Pour garantir un produit stable et finalisé, il est tentant de reporter la migration des clients stratégiques. Mais ce choix met en péril toute la roadmap : les gros clients sont les plus exigeants et dépendent souvent de fonctionnalités spécifiques.
Attendre la fin de la migration revient à créer une bombe à retardement. Chaque adaptation non anticipée pour ces clients, non négociable, va retarder la refonte d'autant.
Autant que possible, intégrez ces clients dès le début du projet pour leur offrir le temps de migrer avec l'accompagnement adéquat.
💡 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.
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.
💡 Astuce terrain : commencer par une brique qui apporte beaucoup de valeur, pour s'offrir de la marge d'itération sur un sujet prioritaire.
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 😁
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 !