Les 7 secrets d'une refonte produit réussie

Vous éditez un produit et vous avez pris la décision d’entamer une refonte ? Nous avons, pour vous, compilé une liste de points d’attention. Nous avons établi cette liste sur la base de nos expériences de refonte, vous êtes prêt à connaître les secrets d’une refonte réussie ? Let’s go !

1/ Remettre en question le fonctionnel

Vous avez pris la décision de refondre votre produit, alors autant y aller à fond !
On ne le dira jamais assez, la phrase la plus dangereuse en informatique, et sans doute en général, est la suivante “on a toujours fait comme ça”.
Adopter cette philosophie impose d’emblée des limitations profondes, finalement cela revient à faire du neuf avec du vieux.
Profitez, au contraire, de l’occasion qui vous est offerte de tout remettre à plat pour challenger le fonctionnel de votre produit. Votre expérience, celle de vos utilisateurs ainsi que de votre équipe est une mine d’or sur laquelle il faut capitaliser pour trouver des axes d’amélioration.
Il se peut que les usages aient changé car introduits par un concurrent ou par l’évolution des technologies. Il serait dommage de louper l’occasion de se mettre à jour.
Osez challenger le fonctionnel de votre produit sans pour autant vous imposer de tout changer, tout dépend des objectifs que vous avez définis. Le sujet sera traité dans le prochain chapitre.

2/ Définir les objectifs de la refonte

Refondre son produit, c’est bien, mais il est nécessaire de définir les objectifs attendus de cette refonte.
Pourquoi avez-vous pris cette décision ?
Vous souhaitez apporter des évolutions trop structurantes pour les ajouter à votre produit actuel ?
Les technologies utilisées sont obsolètes et ne présentent pas de possibilité de mise a jour ?
L’architecture ne permet pas ou plus de faire évoluer le produit ou présentent des problèmes conceptuels impliquant lenteur ou bugs à répétition ?
Il y a forcément une raison principale appuyée de corollaires vous incitant à amorcer cette étape notable de la vie de votre produit.
Ces objectifs clairements définis permettent à votre équipe de cibler précisément les points critiques à aborder lors de la conception de la nouvelle version.
Un projet de refonte nécessite lui aussi de passer par une phase de conception et de spécification (ou d’écriture de stories). Spécifier le projet en se contentant d’écrire “reprendre l’existant mais en mieux” n’est évidemment pas suffisant.
Définissez des objectifs clairs, mettez l’accent sur ce qu’il faut améliorer ou changer et construisez votre nouveau produit autour de ces axes.

3/ Tester ses idées

Une refonte est toujours une étape majeure et impactante dans la vie d’un produit et d’une entreprise lorsqu’elle est construite autour de ce produit.
C’est pourquoi il peut être de bon ton de tester les nouveautés que vous voulez mettre en place à l’aide d’un POC.
Vous limiterez l’effet tunnel et vous capterez des retours utilisateurs plus tôt. C’est une bonne occasion d’engager vos ambassdeurs ou vos key users qui seront vos premiers sponsors si la refonte s’annoncent prometteuse. Se sentant privilégiés ils ne pourront s’empêcher d’en parler autour d’eux et de faire du teasing auprès du reste de votre communauté et de vos prospects.
Cette phase progressive est celle qui a été adoptée par SAP lors de leur refonte consistant à migrer leur client lourd sur des technologies web on cloud.
N’attendez pas que la refonte soit totalement terminée pour sortir la nouvelle version, d’autant plus si votre legacy comporte de nombreuses fonctionnalités.

4/ Challenger la stack technique en place

Au même titre qu'il est important de remettre profondément en question le fonctionnel de l'application, il est tout aussi important remettre en questions la stack technique en place.

Dans quels cas remettre en question la stack technique ?

Si les technologies actuellement utilisées sont obsolètes ou tendent à la devenir, il est opportun de profiter de la refonte pour en changer au profit de technologies plus modernes.
Vous pouvez également profiter des compétences de nouveaux arrivants pour orienter le choix des technos utilisées pour la refonte.
Si la technique est la principale raison de la refonte, alors vous devez considérer la changement de technologie au delà du simple changement d'architecture.

Attention toutefois à ne pas partir sur les derniers langages ou framework à la mode pour le simple plaisir. Bien que potentiellement pertinent, vous risquez de perdre en qualité à cause du manque de compétence de vos équipes en la matière.
Rien de pire que de tout changer pour faire moins bien, non ?

5/ Phaser le projet

Refondre un logiciel ou une application revient à créer un nouveau projet avec la particularité qu'il existe une première version servant de modèle.
Il est donc totalement acceptable d'aborder ce projet de refonte comme un projet de création, en executant plusieurs phases successives.
L'avantage principal de cette approche est qu'elle simplifie la conduite du changement, dont nous parlerons dans le prochain chapitre, elle permet également d'adapter la suite du projet tenant compte des retours des utilisateurs.
La complexité de cette méthode est qu'il est nécessaire de maintenir plusieurs produits en même temps, la question de la synchronisation des données se pose également.
Comme évoqué dans les chapitres précédents, l'approche progressive est celle adoptée par SAP lors de la refonte de leur client lourd.
Dans un premier temps, seules quelques fonctionnalités ont été développées sur la version on-cloud. La politique tarifaire était adaptée, les clients utilisants la version "legacy" n'ont pas été migrés et les données sont restées cloisonnées. Petit à petit, d'autres fonctionnalités ont été ajoutées à la version cloud tenant compte des besoins des utilisateurs, de l'appétence de ces derniers pour la version web et des possibilités techniques.
Cet exemple est quelque peu hors concours de part l'épaisseur fonctionnelle du logiciel, pour autant il image plutôt bien le propos couvert dans ce chapitre.

6/ Investir dans la conduite du changement

Pour refondre un produit, il faut avoir un produit et par extension des clients ou des utilisateurs. La nature de la refonte, l'ancienneté du produit et l'utilisation qui en est faite sont autant d'habitudes prises pas les utilisateurs. Habitudes qu'il va falloir changer et parfois tordre !
On note ici LA principale raison de résiliation ou de désinscription post refonte. En effet l'être humain n'aime pas trop changer ses habitudes, il y est naturellement réfractaire, c'est un fait à anticiper lors de la migration de la précédente version vers la nouvelle.
La conduite du changement ou accompagnement au changement est trop souvent délaissée sous prétexte que "puisque c'est mieux tout le monde va l'adopter !"
Or les utilisateurs de longue date préfèrent continuer à utiliser un logiciel ou une application comportant quelques bugs ou avec des temps de traitement un peu longs, plutôt que devoir réapprendre à utiliser l'outil, surtout s'il s'agit de son outil de travail. Il entrera alors dans une phase de rejet ou le moindre petite obstacle ou la moindre petite difficulté sera exacerbée et tous les prétextes seront bons à vous jeter la phrase fatidique "c'était mieux avant !"
Pour accepter le changement, il doit être progressif. Habituer petit à petit vos utilisateurs historiques aux nouveautés, offrez leur la possibilité de beta tester ou montrez leur certaines fonctionnalités en avant première.
Mieux, impliquez les dans la refonte en leur demandant leur avis, il leur sera alors impossible de critiquer un outil pour lequel ils ont pris part à la conception. Il y a de forte chance qu'ils en deviennent les premiers sponsors !
Le phasing évoqué dans le chapitre précédent est une possibilité permettant une adoption progressive.
Une autre solution consiste à faire des webinars de démonstration chaque fois qu'une étape majeure du développement est passée, une sorte d'avant première permettant de valoriser les utilisateurs tout en leur offrant une mise en bouche.
La conduite du changement est une étape clef qu'il ne faut pas oublier. Gardez les précieux utilisateurs que vous avez eu peine à gagner par le passé.

7/ Anticiper la migration de données

La migration des données est une étape capitale de la refonte. C'est la dernière étape permettant de mettre un terme à l'ancienne version du produit et de valider la mise en service de la nouvelle.
Les données de vos utilisateurs ne doivent en aucun cas être perdues, il convient de les migrer.
Simple sur le principe, c'est une étape très périlleuse techniquement donc il faut maîtrisr le timing à la perfection.
Rien ne doit être laissé au hasard :

Un plan précis doit être établi en avance de phase et les scénarii doivent être anticipés.
Bien entendu une migration "blanche" doit être effectuée en amont pour valider la procédure.
Cette étape peut être ignorée si le fait de perdre les données présentes sur la première version est assumé et partagé avec les utilisateurs.
La complexité de cette étape dépend de plusieurs facteurs :

Bien que potentiellement complexe, si elle est préparée convenablement, la migration de données ne pose pas de problème.


La refonte d'une application ou d'un logiciel est un exercice particulier qu'il convient d'appréhender de manière particulière sans se brider pour autant.
Vous avez participé à la refonte d'un produit ? Vous souhaitez compléter cet article ou débattre ? Réagissez en commentaire.

top