Qu’on soit dans une start-up, une scale-up ou un grand groupe, il y a de fortes chances qu’on soit un jour confronté à un projet de refonte. Les technologies changent, les besoins évoluent et pour couronner le tout, le turn-over des équipes de développeurs entraîne le moment fatidique, celui où ça ne peut plus durer.
La petite goutte de sueur apparaît alors quand il faut convaincre les différents responsables et le business de tout arrêter pour se concentrer sur une refonte nécessaire. On ne va pas se mentir, faire une refonte ne fait pas partie des moments les plus agréables. En plus du projet, il faudra la frustration liée à l'impression de stagnation de la part des utilisateurs et des parties prenantes en interne en attente d’évolutions.
Pourtant c’est une très bonne opportunité pour repartir sur des fondations solides, à condition de gérer au mieux cette période de transition qui va bien au-delà du simple développement.
Cet article a pour objectif de partager 6 erreurs déjà vécues et à ne pas reproduire.
#1 Faire la refonte pour de mauvaises raisons
“Reculer pour mieux sauter” comme dit le proverbe. Toute refonte doit permettre d’envisager un futur plus radieux, aussi bien techniquement que fonctionnellement. Il faut donc identifier les difficultés actuelles, ce en quoi cette refonte va aider à les surmonter et si le retour sur investissement est positif. Cette refonte doit aussi être évaluée au regard de la stratégie de l’entreprise. Veut-on avoir une stratégie court-termiste car les attentes actuelles sont trop fortes ? C’est un choix qui peut être fait ponctuellement.
Une maintenabilité complexe (vélocité faible), des régressions en pagaille à chaque évolution ou des problèmes à recruter des développeurs à cause d’une stack technique obsolète sont autant de bonnes raisons pour mener à bien un projet de ce type.
A contrario, voici une liste non exhaustive de mauvaises raisons :
- si le produit n’évolue pas (ou peu)
- faire plaisir au nouveau CTO qui veut imposer sa patte
- une équipe de développeurs qui veut tester la dernière techno à la mode
#2 Avoir un sponsorship faible
Lors de la refonte, l’équipe va susciter une attente importante de la part du business qui peut se transformer en réelle frustration. Le marché ne vous attend pas, les besoins utilisateurs sont grandissants et votre produit, lui, stagne. Sans un sponsorship qui fait autorité pour calmer ces ardeurs, vous allez gaspiller de l’énergie alors que vous avez besoin de focus pour mener à bien ce projet.
Ce sponsorship doit s’accompagner d’un message fort : aucune évolution sur l’existant, exception faite de contraintes légales fortes. Même minimes, accepter de prendre des évolutions est une perte de focus pour l’équipe, entraînant un ralentissement de la refonte et un périmètre à migrer plus important. De plus, cela envoie un mauvais message sur l’importance de cette refonte qui peut apparaitre non fondamentale avec un produit actuel qui vit bien. Double échec.
#3 Précipiter le démarrage du développement
On connait tous l’histoire du lièvre et de la tortue. Pour une refonte, c’est pareil. Avant de commencer, il faut s’assurer d’avoir les bons acteurs pour gérer ce projet, surtout côté Tech.
Des développeurs seniors, ayant une appétence pour les problématiques d’architecture sont des profils qu’il faut en priorité. Les fondations qui seront encore là pour plusieurs années sont en train d’être dessinées, il faut des personnes ayant de l’expérience pour éviter de futurs écueils.
Il faudra prendre aussi le temps nécessaire pour construire cette nouvelle architecture et faire les bons choix de techno. Cela peut paraître frustrant mais ce choix est stratégique. Des PoC (Proof of Concept) peuvent être lancées pour lever les potentiels doutes sur une partie de la nouvelle architecture.
Une entreprise qui avait fait le choix d’une technologie émergente pour la refonte de son application mobile s’est retrouvée à :
- sortir une première version non stable au bout d’un an
- devoir mener une nouvelle refonte, vers une autre technologie au bout de quelques mois
Un POC et/ou le choix d’une technologie établie aurait évité d’avoir deux ans sans réelles améliorations UX pour cette application. La clé de réussite de cette deuxième refonte a été de prendre le temps de valider tous les choix d’architecture.
#4 Considérer que ce n’est qu’un sujet Tech
Cela te paraît peut-être évident, et pourtant ce doit être l’erreur la plus classique ! Il faut impliquer le Produit dans ce projet : pas comme un simple chef de projet mais comme un vrai Product Manager.
C’est le moment de tout refaire, donc c’est aussi une bonne occasion de simplifier le Produit et d’améliorer l’expérience proposée. Pour cela, il faut :
- Commencer par la data disponible : quelles sont les fonctionnalités les plus utilisées, comment le sont-elles, quelles parties du parcours doivent être simplifiées…
- Se concentrer ensuite sur des insights qualitatifs : interviews utilisateurs, sessions recording…
- Accepter de revoir l’expérience existante si le besoin s’en fait ressentir.
La refonte peut aussi être un bon moment pour instaurer de nouvelles manières de faire du Discovery et incorporer des outils pour collecter plus d’insights Produit.
Sur le choix de l’architecture et des technos, c’est à l’équipe Tech de décider mais c’est aussi au Produit de les challenger (notamment si on décide d’aller sur une techno jeune). Le Produit est aussi présent pour alimenter en insights d’utilisation, en donnant ces ambitions en termes de volumétrie de données, de pics d’utilisation et/ou de niveau de performance attendu.
Au-delà de cet aspect “Cadrage”, il est important que le Produit soit impliqué tout au long du développement. Spécifier, tester, piloter font partie des tâches qui lui reviennent, comme pour un nouveau produit.
#5 Sous-estimer l’impact organisationnel et humain
Un élément sous-estimé mais qui doit pourtant faire partie de la réflexion, c’est l’impact organisationnel et humain.
La nouvelle architecture peut être un enabler pour revoir le découpage des équipes et passer à une organisation en Feature Team par exemple. C’est aussi le moment de challenger la manière dont vous travailliez. Il y a quelques années, c’était aussi un moment charnière où on pouvait tester le passage à l’agilité.
Au niveau humain, comment gérer les développeurs en place ? Certains sont là depuis des années, peut-être ont-ils fait partie de ceux qui ont fait des choix technologiques qui nous ont amené à cette situation. Parmi eux, certains vont mal prendre la remise en question et peut-être vaut-il mieux pour tout le monde qu’ils s’en aillent. D’autres vont vouloir faire partie de cette nouvelle histoire à construire, et il faut les inclure aux différentes discussions, les former aux nouvelles technos utilisées. Les laisser partir serait une erreur car ils connaissent l’organisation et le fonctionnel. En tout cas, c’est un grand mercato qui s’annonce.
Et les parties prenantes dans tout ça ? Le Customer Success et le Marketing doivent être impliqués dans la démarche. La refonte va leur faire naître un sentiment de frustration. Pour le mitiger, il va falloir leur montrer la lumière au bout du tunnel, avec un produit futur offrant une meilleure expérience et une plus rapide évolutivité. Tout au long du projet, il faut leur donner de la visibilité de manière très transparente mais aussi faire appel à leurs expertises si vous voulez réadapter l’expérience en cours de route.
#6 Faire une sortie “big bang”
Décommissionner l’ancien produit d’un coup, et encore pire sans jamais avoir mis la nouvelle version dans la main des utilisateurs est la pire des décisions à prendre. Les utilisateurs et les parties prenantes n’ont pas vu de nouveauté depuis un certain temps, alors autant ne pas les décevoir.
Pour cela, plusieurs stratégies :
- Avoir des parcours hybrides entre le nouveau Produit et l’existant. Par exemple, sur un projet de refonte d’un site de location de véhicules, la homepage a été migrée en premier. Puis la page de réservation de véhicules, etc. Il faut faire attention à ce que les données soient bien cohérentes, ce qui peut s’avérer être un challenge.
- Rediriger une partie du trafic (système de Canary Release) sur le nouveau produit et augmenter ensuite cette part si le produit est reçu favorablement par les utilisateurs, et ne montre pas de signes de défaillance.
- Dans un contexte international, il est possible de lancer le nouveau produit uniquement sur un pays au début. On recommande alors de prendre un petit pays en termes de business pour limiter les potentiels impacts négatifs.
- Découper la migration par persona. Certaines migrations vont traiter d’abord le parcours d’un persona précis. Puis, une fois que la migration sera un succès, on passera à un autre persona, et ainsi de suite.
Ces stratégies peuvent être cumulatives, l’objectif étant de découper finement pour avoir des feedbacks rapides en termes de performances et usages.
Ceci n’exclut pas non plus le fait d’avoir recours à des tests d’utilisabilité où de vrais utilisateurs pourront manipuler le nouveau produit en avant première pour donner leur feedback, et vous laisser la possibilité d’itérer pour le meilleur.
Tout ça n’a qu’un seul objectif : éviter un bad buzz !
