Performances en berne, dette technique ingérable, incapacité à faire évoluer l’application, volonté de pivoter…
Dans tout projet web ou mobile, la refonte technique est parfois une étape incontournable pour repartir sur des bases saines. On ne parle pas ici de la refonte d’un petit site internet, qui peut aller relativement vite. Mais plutôt de la refonte d’une plateforme web complexe, d’un logiciel, d’un outil métier.
Cette étape de refonte fait peur, et souvent on la repousse sans cesse car les défis sont nombreux :
- Comment maîtriser les coûts et les délais ?
- Comment être sûr de faire les bons choix techniques ?
- Comment libérer du temps à son équipe technique sans négliger l’exploitation ?
- Comment être certain qu’on ne se lance pas dans un projet de 2 ans, sans visibilité sur son impact réel ?
Chez theTribe, nous sommes contactés quasi quotidiennement par des entreprises qui souhaitent opérer une refonte, et nous avons mené des dizaines de projets de ce type. Nous en avons tiré quelques apprentissages.
Sommaire :
- Les 8 warning qui montrent que vous avez besoin d’une refonte 🚨
- Un MVP qui a atteint ses limites 🚧
- Une concurrence menaçante ⚔️
- Le problème du support du mobile 📱
- Manque de productivité des équipes opérationnelles 📈
- Une dette technique insurmontable 🌋
- Un changement de stratégie 🔀
- Un produit qui n’a pas su évoluer de façon cohérente 🚫
- Des tickets de support qui s’accumulent 🎫
- Les risques d’une refonte ratée 🆘
- Comment réussir à coup sûr votre refonte ? 🏆
Pourquoi une refonte ? 🛠️
On ne lance pas un projet de refonte par plaisir, mais par nécessité.
Quand la décision est prise, on est souvent face à un mur : les équipes techniques n’arrivent plus à faire évoluer l’application, les utilisateurs lorgnent du côté des concurrents, les performances techniques se dégradent et on passe son temps à éteindre des incendies.
Aveu d’échec pour certains, bourbier pour d’autres, il ne s’agit pourtant pas de savoir si la refonte est nécessaire, mais plutôt d’identifier la fenêtre de tir la plus propice pour la réaliser, et de choisir une méthodologie pour en faire une réussite tout en minimisant les risques.
Refonte partielle ? Refonte totale ? Refonte d’architecture, d’infrastructure, refonte graphique et ergonomique ? Front ou back ? Faut-il tout arrêter pendant X mois le temps que la refonte soit réalisée, ou faire vivre deux projets en parallèle ?
La première chose à faire, c’est d’établir un diagnostic, au lieu de se lancer tête baissée et de tout casser. Quel est le problème principal ? Comment se lancer tout en maintenant l’existant ? Quelles sont les ressources disponibles en interne, et où aller chercher du renfort ? Que doit-on prioriser ?
Plus que le “pourquoi”, c’est donc le “comment” qui va importer le plus pour la réussite de votre projet de refonte.
Mais il existe quand même quelques critères qui rendent le projet de refonte particulièrement urgent, particulièrement stratégique.
On a identifié 8 warnings, des problématiques qui, quand on les rencontre au sein d’une entreprise, montrent qu’une refonte va être nécessaire.
Les 8 warning qui montrent que vous avez besoin d’une refonte 🚨
1. Un MVP qui a atteint ses limites 🚧
Vous avez réalisé un MVP avec une solution nocode / low code, la traction est validée et vous envisagez de faire une levée de fonds, ou vous venez de le faire.
Vous commencez à facturer quelques clients, mais cela vous génère beaucoup de travail manuel. Les frais d’abonnement aux outils que vous utilisez commencent à exploser (autour de 1000€/mois). Vous commencez à être limité par les capacités de votre solution… Il est temps de passer à la vitesse supérieure !
2. Une concurrence menaçante ⚔️
Votre application, votre produit n’est plus au niveau par rapport à ceux de vos concurrents. Une nouvelle concurrence émerge, avec des solutions moins abouties que la vôtre mais plus innovantes, avec une interface séduisante et un discours marketing rodé.
Vos prospects / clients vous parlent sans cesse des fonctionnalités disponibles ailleurs.
Ils valorisent néanmoins votre excellent service client, qui permet de compenser ces manques.
3. Le problème du support du mobile📱
Votre site n’est pas responsive alors que plus de 30% de votre trafic a lieu sur mobile. Il y a un gros décalage entre votre taux de conversion sur desktop et mobile. Vos équipes techniques réussissent bien à faire quelques améliorations, mais ce n’est pas suffisant.
4. Manque de productivité des équipes opérationnelles 📈
Votre business grossit vite. Malheureusement, tous les 6 mois, vous êtes obligé de recruter de nouvelles fonctions support pour administrer les ventes, et refaire “à la main” ou sur excel un certain nombre d’actions répétitives qui ne sont pas réalisées ou mal réalisées sur votre plateforme.
5. Une dette technique insurmontable 🌋
Vous avez un produit qui a été construit couche par couche, par des équipes successives. Il y a de nombreux bugs, sur le backoffice comme sur l’interface clients. Vos équipes techniques disent qu’il est compliqué à maintenir, vous observez au quotidien des problèmes de performances. Vous êtes victime d’un fléau, qu’on appelle la dette technique.
6. Un changement de stratégie 🔀
Votre entreprise a pivoté, et votre produit ne correspond plus à 100% à votre stratégie ; vous ne voulez pas tout jeter à la poubelle mais vous avez besoin de faire évoluer votre produit rapidement.
7. Un produit qui n’a pas su évoluer de façon cohérente 🚫
Une partie de votre plateforme a souffert par rapport à une autre (exemple : le backoffice par rapport au front, l’appli mobile par rapport à l’appli web…). Les utilisateurs se plaignent, il faudrait tout revoir mais votre équipe est déjà mobilisée sur d’autres chantiers.
8. Des tickets de support qui s’accumulent 🎫
Le nombre de tickets de support augmente de manière exponentielle, malgré l’excellent travail de l’équipe de développement. Vous commencez à avoir quelques départs dans votre équipe technique, et vous sentez la lassitude de vos équipes produit, qui ont des difficultés à lancer de nouvelles fonctionnalités.
Vous le voyez, il peut donc y avoir une grande variété de signes avant-coureur, signes qu’une refonte va être nécessaire.
Mais nous pouvons néanmoins les regrouper en 3 grandes catégories :
- La dette technique devient trop forte pour être absorbée. Les équipes techniques passent une majorité de leur temps à de la correction de bugs plutôt que sur de l’enrichissement fonctionnel.
- Le nombre de tâches à faible valeur ajoutée se démultiplie, au niveau des fonctions support, mais aussi au niveau de l’exploitation. La marge opérationnelle est sous tension.
- De plus en plus de clients se détournent de votre offre au profit de celles de concurrents.
Si vous vous retrouvez dans cette situation… Alors oui, la question de la refonte mérite d’être posée. Mais avant de vous lancer, vous devez identifier les risques, les pièges dans lesquels vous ne devez pas tomber.
Les risques d’une refonte ratée 🆘
Vous avez décidé de lancer un projet de refonte : il en va de la survie de votre entreprise et de votre capacité à rester attractif, à la fois pour vos clients mais aussi pour vos collaborateurs !
Réussir ce projet de refonte est donc un enjeu crucial. Sans vouloir vous faire peur, faire de mauvais choix peut avoir un impact durable sur votre performance économique.
C’est pour cela qu’il est important, dès le départ, d’identifier les risques que vous courez si vous prenez de mauvaises décisions.
Voici les principaux pièges dans lesquels tombent les candidats malheureux à la refonte :
- Risques 1 : Perdre du temps
- Risque 2 : Devoir tout recommencer
- Risque 3 : Mettre le business en pause
- Risque 4 : Sous-estimer la migration des données
👉 Perdre du temps
C’est le plus grand risque.
Retarder la prise de décision, ne pas allouer suffisamment de moyens dès le départ, ne pas prendre en compte la problématique dans son ensemble… Comme tout projet interne, un projet de refonte a une dynamique propre. Elle soulève des espoirs, fédère autour d’un projet qui a du sens pour tous et ouvre des perspectives d’amélioration du travail au quotidien. Elle crée également des attentes côté clients, qui ont le sentiment d’avoir été entendus par vos équipes.
Malgré tout, au bout de quelques semaines, quelques mois, les équipes se lassent, les clients sont déçus, les délais annoncés se prolongent… et vos concurrents ont continué à prendre de l’avance sur vous.
C’est pourquoi vous ne devez pas tergiverser : si vous avez décidé de lancer une refonte, il faut commencer maintenant.
| Le tip theTribe Faites une refonte par brique pour accélérer le go to market. Commencez par une brique stratégique et visible sur laquelle vous pouvez vite apporter de la satisfaction aux utilisateurs ! |
👉 Devoir tout recommencer
La refonte de refonte, vous connaissez ? Un grand classique !
On commence à réécrire tout son produit, et 6 mois ou 1 ans plus tard, on recommence : parce qu’on n’avait pas bien compris les enjeux, parce qu’on avait choisi les mauvaises technos… Ou pire encore, le développeur qui s’était engagé sur la refonte a travaillé 6 mois dans son coin, et vous annonce du jour au lendemain qu’il quitte l’entreprise.
C’est pourquoi la méthodologie est importante. Prendre un peu de temps au démarrage pour bien étudier la situation et analyser les risques, cela peut vous faire gagner un temps fou par la suite.
C’est aussi pour cette raison qu’il faut s’assurer d’avoir le bon panel de compétences en charge du projet. Non, ne confiez pas la refonte de votre produit à un développeur seul, mais mobilisez une équipe aguerrie ! D’autres l’ont fait… et se sont cassé les dents.
| Le tip theTribe Appuyez-vous sur les forces déjà présentes dans l’entreprise. La personne qui souffre le plus de l’existant est probablement la mieux placée pour prendre en main le projet ! |
👉 Mettre le business en pause
Pendant que vous travaillez sur la refonte de votre produit, le business continue !
Vos utilisateurs ont des besoins, il y a des bugs en production à corriger, des nouveaux clients qui signent, des concurrents qui arrivent sur le marché…
Vous ne pouvez pas vous permettre de tout mettre en pause le temps de sortir la v2 de votre produit.
Cela signifie deux choses :
- Aucune personne clé ne doit être mobilisée à 100% sur cette refonte, en particulier le CEO, qui doit se concentrer à 100% sur le développement de l’entreprise.
- Il va falloir faire coexister votre plateforme actuelle et la nouvelle version pendant un certain temps : cela s’organise, il y a des bonnes pratiques à respecter, mais cela ne s’improvise pas !
Vous l’aurez compris : la refonte de votre produit est quelque chose que vous ne pouvez pas rater.
C’est pour cela que l’on vous conseille de bien vous entourer ! D’ailleurs, n’ayez pas peur de vous faire aider. Technique du figuier étrangleur, refonte complète à périmètre iso, place de l’utilisateur dans la refonte UX, KPI suivi pour s’assurer de la réussite de la refonte… Nombreux sont les sujets que vous ne maîtrisez peut-être pas à 100% en interne, et pour lesquels une expertise externe serait précieuse.
| Le tip theTribe Séparer vos équipes : une équipe sera en charge de la maintenance du code legacy (l’historique), et une dexième en charge de la refonte. L’équipe refonte doit être autonome sur son périmètre pour ne pas être dépendante de facteurs exogènes ! |
👉 Sous-estimer la migration des données
Votre entreprise existe depuis plusieurs années, et vous avez collecté un grand nombre de données d’utilisation de votre produit.
Si votre produit est un site grand public, vous avez un positionnement SEO solide, une base d’utilisateurs qui s’attend à retrouver son historique d’utilisation de votre outil dans son interface personnel.
Si votre produit est un une application B2B ou un outil interne, les données qu’elles contient sont sans doute d’une importance stratégique pour les utilisateurs.
Il est hors de question de risquer une perte de données clients, commerciales, financières à cause d’une refonte.
De plus, votre équipe Marketing et l’équipe Produit s’appuient régulièrement sur des statistiques d’utilisation pour appuyer leurs décisions stratégiques.
SEO, données utilisateurs sont des actifs forts de l’entreprise, attention à ne pas repartir d’une feuille blanche à l’issue de votre refonte.
La stratégie data sera donc un point de vigilance particulier dans le cadre de cette refonte. En l’absence de CPO, le rôle du CEO est de bien s’assurer qu’il y aura le moins de perte d’information possible entre l’ancienne plate-forme et la nouvelle.
| Le tip theTribe Penser à créer dès le début une passerelle entre l’ancienne plateforme et la nouvelle. Ce hub sera l’endroit unique de communication entre l’ancien et le nouveau produit pour permettre aux 2 produits de cohabiter. Le jour où la refonte sera terminée, le hub pourra être supprimé. |
Comment réussir à coup sûr votre refonte ? 🏆
Du développement en interne à la sous-traitance auprès d’une équipe dédiée, il existe mille et une manières de réussir une refonte mais pas de recette miracle pour maîtriser à la fois, les coûts, la qualité et les délais.
Chez theTribe, nous mettons à votre disposition un cadre de réalisation qui vous permettra de minimiser les risques pour vous et pour votre business.
Nous espérons que cet article vous aura aidé à comprendre les risques et les enjeux d’une refonte produit, mais également qu’il vous aura donné quelques conseils pratiques pour initier le chantier.
