Reprendre un MVP existant sans tout réécrire

Le problème

Le produit existe. Il a été développé par un prestataire, il tourne en démo, les premières personnes l’ont vu et ont dit que l’idée tenait. Et puis le fondateur se retrouve avec une question qu’il n’avait pas prévue : comment reprendre un MVP développé par un autre prestataire sans tout réécrire ? Le budget du premier MVP est déjà engagé, le calendrier de lancement aussi, et le nouveau prestataire consulté répond souvent la même chose : « on repart de zéro, ce sera plus propre ».

Le truc, c’est que cette réponse arrive parfois avant même que le code ait été lu. Une réécriture complète, c’est long, c’est cher, et ça jette des mois de travail qui fonctionnent déjà en grande partie.

L’approche

Une plateforme de mise en relation entre des centres de formation, CFA, organismes, écoles, et des jurys professionnels qualifiés pour leurs certifications. Les centres y trouvent rapidement des jurys disponibles, les jurys y gagnent la visibilité qui leur manquait, et tout le parcours est couvert, des profils au paiement. Elle est en production aujourd’hui, avec près de 500 jurys inscrits (chiffre 2026). C’est la reprise que j’ai menée pour SimplyJury à partir d’avril 2026, sur un MVP livré par un autre prestataire, trop avancé pour repartir de zéro.

L’audit, pour décider avant de coder

Avant d’ajouter quoi que ce soit, j’ai réalisé un audit technique de l’existant, offert. Ce qui compte, c’est ce qu’il a permis de décider : quel périmètre était sain et pouvait être gardé tel quel, quel périmètre demandait des correctifs, et dans quel ordre les livrer. Le résultat tient dans un backlog de mise en production, découpé en sprints, chacun tracé par sa plage de commits et son statut. Le premier a été livré dès la fin avril 2026.

Correctifs ciblés, recette, mise en ligne

Chaque sprint a été livré, puis validé par une recette manuelle avant de passer au suivant, avec une checklist de bout en bout écrite pour le lancement. La mise en production elle-même a suivi un runbook, lot par lot, avec des contrôles SQL avant et après chaque étape ; l’état de prod y est mesuré au 27 août 2026. Un exemple de correctif représentatif : la fiabilisation des emails transactionnels, avec un expéditeur décidé à un seul endroit du code et un domaine dédié imposé par une garde à l’exécution.

Des lots chiffrés, isolés, réversibles

Après la mise en ligne, chaque évolution est arrivée par lot : un périmètre clair, un prix connu avant de s’engager, et des options explicitement séparées que le client peut retirer sans incidence sur le reste. Les alertes jury, le dépôt de session côté centre avec son tableau de bord, la connexion à double vérification par code, les statistiques d’administration, la fiabilisation des emails par type de compte : chacun de ces lots a été livré indépendamment, avec sa propre recette.

Un partenariat qui continue

Le vrai sujet n’a jamais été une livraison unique. Le dépôt montre un rythme mensuel de livraisons depuis avril 2026, avec un pic en août, le mois de la mise en production, et le fondateur commite aussi dans le dépôt. Le suivi post-lancement a son propre backlog, alimenté par ce que le terrain remonte, et c’est ce backlog qui décide des lots suivants.

Stack et choix techniques

Sur une reprise de MVP, je ne change pas la stack pour le plaisir : je garde ce qui tient et je fais évoluer ce qui doit l’être. Ici, la base est Next.js 15 sur Vercel, région cdg1 à Paris, avec Supabase pour la base de données et l’authentification, Stripe pour le paiement et Resend pour les emails. TypeScript en mode strict sur l’ensemble du dépôt.

Le choix structurant a été de ramener l’accès aux données sur Drizzle, table par table, à mesure que les lots le demandaient : tableaux de bord du centre, sessions et leurs notes, statistiques du jury, export RGPD. Chaque requête est ainsi écrite, typée et relue dans le dépôt. Le schéma compte 28 tables et 50 migrations SQL versionnées ; un workflow GitHub dédié les applique, et le script vercel-build les exécute en production avant chaque next build, ce qui évite qu’une version déployée tourne sur un schéma en retard.

Les droits d’accès aux données sont portés par PostgreSQL, avec 86 politiques RLS déclarées dans les migrations. Le webhook Stripe tourne avec maxDuration à 30 secondes, et la connexion est vérifiée par code OTP avec plafonnement des tentatives.

Résultat

Le chiffre qui compte pour une place de marché, c’est le vivier : sans jurys disponibles, aucun centre de formation n’a de raison de revenir. Ce résultat appartient au client, c’est son marché, son réseau, son travail commercial. Ma part, c’est que la plateforme n’ait jamais été le facteur limitant, qu’elle tienne quand l’audience arrive et qu’elle évolue au rythme de ce que le terrain remonte.

Questions fréquentes

Comment reprendre un MVP développé par un autre prestataire sans tout réécrire ?

En lisant le code avant de décider. L’audit sépare ce qui est sain de ce qui doit être corrigé, et produit un backlog ordonné plutôt qu’un devis de refonte. Ensuite, les correctifs se livrent par sprints, chacun validé par une recette avant le suivant, jusqu’à la mise en ligne.

Faut-il tout réécrire un MVP existant ou le corriger ?

Mon point de vue : la réécriture se justifie quand l’audit la démontre, pas avant. Une réécriture est plus longue et plus chère qu’annoncé, et elle réintroduit des bugs que la version existante avait déjà réglés. Corriger, ça veut dire garder ce qui fonctionne et faire évoluer, morceau par morceau, ce qui doit l’être.

Comment se passe un audit technique avant de reprendre un projet ?

Il me faut l’accès au dépôt, à l’hébergement et à la base de données. Je lis le code, le schéma, les déploiements, et j’en tire un document que le client garde : ce qui peut être mis en ligne tel quel, ce qui doit être corrigé avant, et l’ordre proposé. Ce document devient le backlog des premiers sprints.

Qu’est-ce que la TMA, et en quoi ça diffère d’un développement classique ?

La tierce maintenance applicative, c’est la suite après la mise en ligne : corriger ce qui casse, faire évoluer ce que le terrain demande, tenir les dépendances à jour. La différence avec un développement classique, c’est un rythme, pas une livraison.

Si tu portes un MVP que tu n’as pas développé toi-même et que tu hésites entre le lancer et tout refaire, mieux vaut bien choisir ses prestataires dès le départ — mais quand ce n’est plus possible, la reprise de MVP commence par cet audit. Pour la suite, une fois le produit en ligne, c’est le partenariat technique en lots réguliers qui prend le relais.