Reprendre une application qui ne fonctionne plus : stabiliser d'abord, décider ensuite

Introduction

Une plateforme a rendu service pendant quelques années, puis tout s'est dégradé : des pages qui mettent plusieurs secondes à s'afficher, des fonctions qui cassent après chaque modification, un prestataire parti ou injoignable. Les utilisateurs continuent de s'en servir, faute de mieux, et chaque semaine coûte en confiance.

Tout reconstruire est parfois la bonne réponse, rarement la bonne première étape : une réécriture prend des mois, pendant lesquels l'outil existant continue de casser. Nous avons repris deux plateformes dans cette situation. L'une, AirStarter, la plateforme de Time2Start, servait plusieurs centaines de porteurs de projet d'un programme d'incubation ; l'autre, des professionnels de santé formés par La Clinique du Coureur, et leurs patients.

01Reprendre ou tout refaire : les bons signes

Une application mérite d'être reprise tant qu'elle rend encore un service réel à ses utilisateurs. Des bugs, de la lenteur ou un code daté ne suffisent pas à la condamner : ces problèmes se corrigent.

Trois questions nous aident à trancher vite :

• Vos utilisateurs s'en servent-ils encore ? Si oui, l'application porte des usages, des données et des habitudes qu'une réécriture devrait reproduire.
• Le cœur fonctionne-t-il ? Un design correct et un parcours qui tient la route valent plus qu'on ne le croit : ce sont souvent les parties les plus longues à refaire.
• Les problèmes sont-ils localisés ? Une lenteur générale ou une faille de sécurité ont souvent une cause précise, qu'un audit permet de trouver.

Une réécriture s'impose en revanche quand la technologie n'est plus maintenue et bloque toute évolution, ou quand votre métier a changé au point que l'outil ne suit plus. Même dans ce cas, nous stabilisons d'abord l'existant : il doit tenir pendant que nous construisons la suite.

02Les premiers jours : accès, sécurité, cartographie

Une reprise commence par la récupération des accès : sans eux, nous ne pouvons rien corriger ni rien garantir. Dans nos deux reprises, il a fallu les obtenir auprès d'un tiers.

Code source, hébergement, nom de domaine, base de données, comptes des services connectés : ces accès sont souvent dispersés, parfois détenus par l'ancien prestataire. Nous allons chercher l'information, expliquons la démarche à chaque interlocuteur, puis restituons ces accès à notre client. C'est un principe : vous restez propriétaire de vos données et de vos accès, y compris vis-à-vis de nous.

Vient ensuite la sécurité. Chez Time2Start, l'audit de la plateforme AirStarter a révélé une exposition de données sensibles : l'interface qui fournit les données à l'application (l'API) laissait n'importe qui récupérer des informations qui ne lui étaient pas destinées. Nous l'avons corrigée en premier, avant même la lenteur, en définissant qui peut faire quoi et ce que chaque personne connectée peut récupérer.

En parallèle, nous cartographions l'existant : quelles données, quels écrans, quels traitements, quelles dépendances. Sans documentation, il faut reconstituer ce fonctionnement à partir du code lui-même (le "reverse engineering"). C'est la seule façon de savoir ce que l'on touche.

03Stabiliser à la source, pas en surface

Stabiliser, c'est rendre l'outil fiable en traitant la cause des problèmes, pas en masquant leurs effets. Un correctif de façade fait disparaître le bug visible, mais laisse la cause en place : elle ressort ailleurs, plus tard.

Chez La Clinique du Coureur, la plateforme donnait des recommandations fausses ou ne fonctionnait plus, à la suite de modifications successives. Nous aurions pu corriger chaque écran fautif. Nous avons préféré remonter à la source : remettre en route l'environnement complet, comprendre l'algorithme de recommandation, le corriger et le mettre à jour, puis importer le catalogue du client. La plateforme est redevenue utilisable en une à deux semaines.

Ce délai dépend surtout de deux choses : la part de reverse engineering nécessaire, et le temps de trouver des solutions à la source plutôt que des rustines.

04Garder, refondre ou migrer : comment nous décidons

Nous gardons ce qui fonctionne et ne refondons que lorsque le gain justifie le coût. Cette décision se prend une fois l'outil stabilisé, sur des faits.

Dans nos deux reprises, nous avons commencé par garder le code existant :

• La Clinique du Coureur : une fois remis en état, le code fonctionnait, le design était correct et la version mobile marchait. Nous nous sommes appuyés sur l'existant et avons amélioré quelques éléments graphiques. Cela suffisait.
• Time2Start : l'application fonctionnait après la stabilisation, et aucune refonte n'était prévue. La refonte a été décidée plus de six mois plus tard, quand l'objectif est devenu d'accélérer avec une plateforme dédiée et durable, qui accompagnerait mieux les porteurs de projet.

05Migrer sans perdre une donnée

Une migration réussie se prouve : nous comptons, comparons et vérifions avant de basculer. Chez Time2Start, la refonte d'AirStarter en 2025 a fait passer l'outil de gestion des contenus de Strapi V3, une très ancienne version, à Strapi V5, avec une nouvelle base de données et un hébergement serverless (sans serveur à administrer).

Entre ces deux versions, les changements sont nombreux : les données ne se recopient pas telles quelles. Nous avons cartographié l'ancienne base, conçu les nouveaux modèles de contenu, écrit les scripts de migration, puis vérifié le résultat de trois façons :

1. 1Des scripts de vérification comparent les volumes avant et après : autant d'utilisateurs, de contenus et de progressions, et aucune perte, utilisateur par utilisateur.
2. 2Des contrôles manuels sur des comptes réels vérifient que chaque personne retrouve son parcours là où elle l'avait laissé.
3. 3Des tests couvrent les parcours clés de la nouvelle plateforme.

Résultat : 0 % de données perdues, et un chargement complet ramené de 8 secondes à 1,5 seconde.

06Deux reprises, deux issues

La même méthode a mené à deux issues différentes, parce que les besoins étaient différents.

La reprise de La Clinique du Coureur a une particularité : la plateforme avait été créée par notre startup, avant d'être rachetée par la Clinique en 2023. Nous connaissions l'outil de l'intérieur, mais d'autres l'avaient modifié entre-temps. Une leçon d'humilité : même un code que nous avons écrit devient étranger après quelques années et quelques mains.

07Ce qui est mesuré, et ce qui ne l'est pas

Chaque chiffre de cette note a sa méthode de mesure et ses limites.

• Temps de chargement (Time2Start) : mesuré avec Lighthouse, l'outil d'audit de Google, avant et après la refonte. Toutes les pages avaient des temps comparables ; le passage de 8 s à 1,5 s correspond au chargement complet.
• 0 % de données perdues (Time2Start) : vérifié par comptages avant et après, contrôles manuels et tests, au moment de la migration de 2025.
• 1 à 2 semaines (La Clinique du Coureur) : observation de notre équipe, entre le début de la reprise et le moment où la plateforme a de nouveau rendu son service. Ce n'est pas un engagement de délai : il dépend de l'état de l'existant.
• Ce que nous ne publions pas : le nombre exact d'utilisateurs et de données migrées, ni le détail des failles corrigées, pour ne donner aucune piste exploitable.
• Ce que nous ne mesurons pas : la disponibilité de la plateforme avant la reprise, faute de suivi à l'époque.