Skip to content

7 erreurs à éviter pour réussir sa refonte logicielle SaaS B2B

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 ?

Réussir sa refonte technique en équilibrant gestion de la dette et innovation

Les points clés de mon approche :

  • bien flécher les investissements pour optimiser les coûts et les délais
  • utiliser votre refonte technologique comme un vecteur de valeur ajoutée (pour vos utilisateurs ET vos équipes).
  • et surtout, aligner les objectifs technologiques avec vos ambitions business

Commençons par les pièges à éviter, avant d'aborder une stratégie qui équilibre dette et innovation.

Les erreurs à éviter absolument dans une refonte technologique

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 :

🚩 1. Négliger la planification de la 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é.

🚩 2. Ignorer les utilisateurs finaux

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.

🚩 3. Ne pas adresser la dette technique par la racine

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.

🚩 4. Reléguer au second plan la communication de la refonte

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.

🚩 5. Prévoir le lancement en grande pompe d'un nouveau produit

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 :

  • produit incomplet si tout n’est pas finalisé à temps
  • multiples régressions quand les patchs (non documentés) ne sont pas repris
  • répétition des erreurs passées puisqu’il n’y a pas de feedback utilisateur continu
  • frustration des utilisateurs face au changement brutal

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.

🚩 6. Investir dans le run mais pas dans la formation des équipes

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 :

  • Une formation poussée aux nouvelles technologies utilisées (ou l’appui d’un expert)
  • La mise en place de nouvelles méthodologies (par exemple agile ou Lean)
  • L'amélioration des processus de développement (CI/CD, tests automatisés, etc.)
  • La mise en place de rituels favorisant le partage des connaissances au sein de l'équipe
  • L'adoption de meilleures pratiques de product management (discovery/delivery)

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.

🚩 7. Migrer les gros clients en dernier

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.

🚩 8. Déséquilibrer la balance dette technique / innovation

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 :

  • En consacrant une majeure partie des ressources à la réduction de la dette
  • Tout en ordonnant la roadmap pour permettre le développement d'innovations et de nouvelles fonctionnalités sur du code “sain”.

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 clé des refontes réussies : concilier dette et innovation

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 🙌

Comprendre et prioriser la dette technique

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 😁

Pourquoi la dette technique est-elle problématique ?

  • Une performance dégradée : Une accumulation de dette technique peut ralentir les performances de votre application, rendant les mises à jour plus difficiles et risquées.
  • Augmentation des coûts : Plus la dette technique est élevée, plus les nouveaux développements sont complexes. Les correctifs et améliorations nécessitent plus de temps et de ressources.
  • Des bugs et anomalies de plus en plus fréquentes : Ignorer la dette technique augmente le risque de régressions et d’anomalies, difficiles à détecter. Ce qui affecte directement la satisfaction des utilisateurs.
  • Des risques de sécurité : Si les technologies deviennent obsolètes, le produit devient plus vulnérable et ne bénéficie plus des dernières normes de sécurité. Ce risque a un impact direct sur la réputation de votre entreprise en cas de faille.

La matrice de la dette technique

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 :

Matrice de priorisation dette-valeur pour une refonte technique stratégique

  1. Haute valeur, haute dette : Ces éléments doivent être abordés en premier lors d'une refonte, même s'ils sont les plus complexes à traiter. Ils sont critiques pour la performance à long terme de votre produit et apportent de la valeur dès le début de la refonte.
  2. Haute valeur, faible dette : Ce sont vos "quick wins". Ils offrent des améliorations faciles et rapides sans ajout significatif de dette technique. C’est votre backlog d’opportunités bonus, à utiliser lorsque votre jauge de points de vie est trop basse.
  3. Pas de valeur, pas de dette : Ces éléments peuvent souvent être remplacés ou supprimés sans impact significatif sur la rétention. Ils sont détectables en analysant l’usage de votre produit, et supprimer ou remplacer ces éléments via des partenariats allégera rapidement la dette produit tout en raccourcissant la refonte.
  4. Faible valeur, haute dette : Priorisez ces éléments pour une révision ou une suppression, car ils n'apportent pas beaucoup de bénéfices, mais augmentent considérablement la complexité.

Mes conseils pour une stratégie de refonte impactante

⭐️ Commencer par les opportunités qui ont le plus haut ratio “grosse valeur / grosse dette”

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.

⭐️ Attaquer le sujet du décommissionnement assez tôt dans la refonte

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.

⭐️ Piloter la refonte avec une stratégie orientée valeur

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.

Pour aller plus loin

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 !

Stratégie de refonte

Après 10+ refontes de plateformes et marketplaces SaaS B2B, j’ai créé ma recette signature. En moins de deux mois, alignez votre roadmap business avec vos contraintes tech.👩‍🍳

Discutons de votre refonte ➜

Claire Van de Voorde CPO freelance