Refactoriser vs réécrire : choisir le chemin le plus rapide vers la production

Ce que vous décidez vraiment (et ce que « rapide » signifie)

Le choix entre refactoriser et réécrire ne porte pas tant sur ce qui est « plus correct » que sur la voie qui vous permet d'atteindre une version stable en production avec le moins de risques et de mauvaises surprises.

Refactoriser signifie conserver l'application existante, mais améliorer sa structure. Vous modifiez l'architecture pour que le code soit plus compréhensible, plus sûr à modifier et moins susceptible de casser. Les fonctionnalités restent majoritairement identiques, mais l'intérieur devient plus propre.

Réécrire signifie repartir d'une base de code neuve. Vous recréez l'application depuis zéro, en vous basant souvent sur la version précédente comme référence. Cela peut sembler plus rapide parce que vous arrêtez de lutter contre d'anciens problèmes, mais vous perdez aussi beaucoup des apprentissages sur les cas limites.

Le véritable objectif n'est pas d'avoir du code parfait. C'est une mise en production qui fonctionne pour de vrais utilisateurs : des connexions qui ne cassent pas, des paiements qui ne débitent pas deux fois, des données qui ne disparaissent pas et des mises à jour qui n'entraînent pas de nouveaux bugs.

Quand on parle de « plus rapide », on entend généralement l'une de ces choses :

• Temps calendaire court (quand vous pouvez livrer quelque chose d'utilisable)
• Rapide avec peu de risques (probabilité de livrer sans incident en production)
• Rapide sur le long terme (combien de retravail vous évitez après le lancement)

Le piège est d'optimiser uniquement pour le premier. Livrer en 10 jours n'aide pas si vous passez ensuite 6 semaines à corriger des pannes, colmater des failles de sécurité et reconstruire des fonctionnalités mises de côté.

Un exemple courant : un prototype généré par l'IA semble fini, mais cache des problèmes comme des secrets exposés, une gestion des données désordonnée ou une authentification fragile. Un refactor rapide peut corriger les problèmes évidents et obtenir une démo, mais si la base est instable, on finit par « refactoriser pour toujours ». Des équipes comme FixMyMess observent souvent cela avec des applis générées via Lovable, Bolt, v0, Cursor ou Replit.

« Rapide maintenant » devient « lent plus tard » quand vous :

• Continuez d'ajouter des fonctionnalités dans un code que vous n'osez pas modifier
• Sautez les tests, si bien que chaque changement casse quelque chose d'inattendu
• Conservez des patterns dangereux en production (requêtes non sécurisées ou clés exposées)
• Dépendrez d'une seule personne qui comprend le désordre

Une bonne décision fait fonctionner rapidité et stabilité ensemble : livrer tôt, mais pas d'une manière qui crée un second projet plus long juste après le lancement.

Signes de santé du code qui favorisent le refactor

Le refactor est généralement la voie la plus rapide quand le code a déjà une colonne vertébrale fiable. Dans le dilemme refactor vs réécrire, recherchez une base de code qui a du sens même si elle est désordonnée.

La « forme » du code est claire

Un bon candidat au refactor présente une structure visible : les dossiers correspondent aux fonctionnalités, les fichiers ont une responsabilité principale, et l'application suit un schéma cohérent (même si ce n'est pas votre pattern favori). Vous pouvez tracer une action utilisateur de l'interface au back-end et à la base sans vous perdre.

Vous verrez aussi des frontières qui tiennent : un module d'auth clairement défini, une zone de paiements séparée, ou une couche de données distincte. Cela rend possible d'améliorer une partie sans tout casser.

Les points douloureux sont réparables, pas fondamentaux

Le refactor brille quand les problèmes sont locaux et répétables. Signes typiques : logique dupliquée, fichiers trop longs, gestion d'erreurs manquante, et problèmes de configuration du type « ça marche sur ma machine ». Ces soucis sont embêtants, mais n'indiquent pas que tout le système est confus.

Cherchez des bugs qui se concentrent autour de fonctionnalités précises plutôt que partout. Si la connexion est cassée mais que le reste de l'app se comporte, c'est un signal pour refactoriser. Si chaque changement provoque des échecs aléatoires sur des écrans sans lien, vous êtes plus près d'une réécriture.

Voici des indicateurs faciles à repérer favorables au refactor :

• Une ou deux « zones chaudes » causent la plupart des problèmes (par exemple l'auth ou un modèle de données)
• Les noms sont globalement lisibles et le flux est traçable avec des logs basiques
• Les mêmes corrections reviennent (validation manquante, réponses API incohérentes)
• Les dépendances sont raisonnables et assez à jour pour être patchées
• Les problèmes de performance se rattachent à des requêtes ou endpoints spécifiques

Les problèmes d'échelle et de rapidité peuvent aussi être de bons candidats au refactor si vous pouvez les améliorer par étapes : ajouter du cache sur un endpoint, corriger une requête SQL lente, ou déplacer un travail lourd en tâche d'arrière-plan.

Exemple : un fondateur apporte une appli générée par l'IA où l'onboarding fonctionne, mais les pages de facturation sont chaotiques et des secrets sont exposés dans le repo. Une équipe comme FixMyMess refactoriserait typiquement : contenir les parties risquées, renforcer la sécurité, nettoyer le flux de facturation, et conserver ce qui marche déjà.

Signes qui rendent la réécriture plus sûre

Parfois la voie la plus rapide est d'arrêter de colmater et de repartir à zéro. Dans le choix refactor vs réécrire, « plus sûr » signifie généralement que vous pouvez prévoir l'impact de chaque changement et livrer sans une longue traîne de surprises.

Bloqueurs difficiles à démêler

Une réécriture est souvent plus sûre quand le code n'a pas de frontières claires. On le voit quand une modification casse trois zones sans lien, ou quand on ne peut pas expliquer le flux des données sans tout lire.

Signes courants de « bloqueurs » :

• Dépendances serrées et emmêlées où chaque fichier importe tous les autres
• Effets de bord partout (état global, jobs en arrière-plan cachés, configuration magique)
• Pas de source unique de vérité pour les données (stores concurrents, logique dupliquée)
• Des « fixes » qui exigent de toucher des dizaines de fichiers pour une petite fonctionnalité
• Un setup de build ou de déploiement qui ne marche que sur une seule machine

Si vous ne pouvez pas isoler un point de départ sûr, le refactor devient une recherche lente de mines.

Échecs répétés et signaux de sécurité

Si la même catégorie de bug revient, cela pointe souvent vers un mauvais design, pas un patch manquant. Répétitions typiques : authentification qui casse après des petits changements UI, bugs d'état qui n'apparaissent qu'après quelques clics, intégrations fragiles s'appuyant sur des comportements non documentés.

Les problèmes de sécurité peuvent aussi forcer une réécriture. Secrets exposés dans le repo, requêtes base de données non sécurisées, permissions excessives ou vérifications d'auth copiées-collées ne sont pas des problèmes « plus tard ». Ils changent la donne car vous ne pouvez pas prouver la sûreté du système sans remplacer les parties risquées.

Un exemple rapide : un prototype marche en démo, mais des utilisateurs sont déconnectés aléatoirement, le webhook de paiement échoue sur les retries, et on trouve des clés API côté client. Vous pouvez passer des semaines à chasser les symptômes, ou reconstruire les flux principaux avec des frontières claires et des valeurs par défaut plus sûres.

Enfin, si vos besoins ont tellement changé que la conception d'origine ne convient plus (par exemple conçu pour un utilisateur unique mais besoin actuel d'équipes, de rôles et de logs d'audit), réécrire peut être plus rapide que forcer une ancienne architecture à s'adapter.

C'est le genre de situation que FixMyMess rencontre souvent dans des bases de code générées par l'IA : l'app « marche en grande partie », mais la fondation rend chaque correctif risqué. Une réécriture propre du cœur peut être la route la plus rapide vers la production quand la structure actuelle n'est pas fiable.

Couverture de tests : le facteur qui change la donne

Refactoriser sans tests, c'est changer des pièces les yeux bandés. Ça peut marcher quand vous testez une fois, mais le changement suivant peut casser quelque chose que vous n'avez pas vu.

Les tests sont le filet de sécurité qui vous dit « l'app fait toujours ce dont les utilisateurs ont besoin ». Avec ce filet, le refactor est généralement plus rapide et plus sûr qu'une réécriture, car vous pouvez améliorer le système existant par petites étapes et attraper les erreurs tôt.

Pourquoi une faible couverture rend la réécriture tentante

Quand il y a peu ou pas de tests, chaque changement devient une vérification manuelle. Ça se transforme vite en longs cycles de « je corrige une chose, j'en casse une autre ». Dans ce cas, les équipes penchent souvent pour la réécriture car repartir à zéro paraît plus propre.

Mais une faible couverture n'implique pas automatiquement une réécriture. Souvent, le mouvement le plus rapide est le « refactor test-first » : ajoutez un petit ensemble de tests autour des comportements les plus importants, puis refactorisez derrière ce bouclier. Une réécriture sans tests peut aussi échouer, car vous n'avez pas non plus de moyen rapide de prouver que la nouvelle version respecte les anciens besoins.

Les manières les plus rapides d'ajouter de la confiance (sans tout couvrir)

Vous n'avez pas besoin d'une couverture parfaite pour réduire le risque. Il faut des tests là où les échecs font mal.

Commencez par quelques vérifications légères :

• Tests de fumée : l'app se charge‑t‑elle, permet-elle de se connecter et d'atteindre l'écran principal ?
• Tests du chemin critique : les 3–5 actions qui font ou sauvent de l'argent (inscription, paiement, création de commande, envoi de message)
• Tests de régression pour bugs : un test pour chaque bug douloureux que vous avez corrigé afin qu'il reste corrigé
• Tests d'auth et de permissions : le lieu le plus simple pour les surprises et les problèmes de sécurité

Ajoutez ensuite de la profondeur seulement là où cela rapporte.

Unit vs end-to-end en termes simples : les tests unitaires vérifient de petites pièces (une fonction ou un module) et sont rapides. Les tests end-to-end simulent un utilisateur réel et détectent les problèmes d'intégration, mais sont plus lents et parfois fragiles.

Règle pratique : quelques tests end-to-end pour couvrir le chemin critique, et des tests unitaires pour verrouiller la logique délicate.

Si vous avez hérité d'un prototype généré par l'IA (depuis Lovable, Bolt, v0, Cursor ou Replit), il est courant d'avoir presque zéro test. Dans ce cas, une évaluation rapide de la santé du code plus un petit jeu de tests du chemin critique indiquent souvent si refactoriser ou réécrire est l'option la plus sûre, sans tâtonner.

Délais et risques : comment estimer sans conjectures

Quand on débat refactor vs réécrire, on discute souvent de la vitesse. La vraie question est : à quelle vitesse pouvez-vous livrer une première version fiable en production sans parier l'entreprise sur une supposition ?

Une façon simple d'estimer est de transformer le projet en une liste de « ce qui doit fonctionner le jour J ». Faites un inventaire, puis ajoutez des marges pour ce que vous ne pouvez pas encore voir.

Une méthode d'estimation simple

Notez chaque fonctionnalité et intégration indispensable, puis marquez-les comme connus, flous ou inconnus.

• Fonctionnalités : connexion, onboarding, workflows principaux, admin, facturation
• Intégrations : paiements, email/SMS, analytics, SSO, webhooks
• Inconnues : exigences floues, docs manquantes, données incohérentes, setups « ça marche sur ma machine »
• Réducteurs de risque : tests existants, environnement de staging, capacité à lancer l'app localement
• Contraintes fortes : date de lancement, besoins de conformité, revue d'app store, délais partenaires

Donnez ensuite à chaque élément une fourchette de temps (pas un seul nombre). Par exemple : « Stripe checkout 0,5 à 2 jours » si vous maîtrisez le basique mais pas les cas limites.

Le risque du refactor se manifeste souvent par des régressions cachées. Vous changez une petite chose et une fonctionnalité distante casse parce que le code est emmêlé. Le risque de la réécriture est différent : vous reconstruisez vite, puis découvrez que vous avez oublié une portée importante comme la migration des comptes, les rôles ou une intégration délicate.

La partie la plus difficile est les « inconnues inconnues » — des problèmes que vous ne savez même pas lister. Prévoyez-les volontairement. Règle pratique : ajoutez une marge de contingence de 20 % si le système est familier et stable, 40 % s'il est désordonné ou mal compris, et 60 % si c'est un prototype IA avec peu de documentation.

Stratégie de date limite qui vous garde honnête

Séparez « MVP mise en production » de « embellir après ». Le MVP doit contenir seulement ce dont vous avez besoin pour accepter de vrais utilisateurs (bases de sécurité, logs, backups, et un canal de support). Les améliorations comme l'architecture parfaite, des dashboards supplémentaires et les fonctionnalités agréables vont en phase 2.

Exemple : si votre app gère déjà l'auth et les paiements mais que le code est difficile à modifier, un refactor ciblé avec de bons tests de fumée peut atteindre le MVP plus vite. Si l'auth est cassée, des secrets sont exposés et le modèle de données change tout le temps, une réécriture avec un périmètre MVP serré est souvent un calendrier plus sûr. Des équipes comme FixMyMess commencent souvent par cartographier ces risques lors d'un audit rapide pour que l'estimation soit basée sur le code réel, pas sur l'espoir.

Étape par étape : un workflow pratique pour décider

Quand vous hésitez entre refactoriser et réécrire, vous avez besoin d'une méthode reproductible qui ne repose pas sur l'instinct. Ce workflow garde le focus sur le comportement en production, le risque et le temps.

Commencez par écrire ce que l'app doit faire en production. Restez concret et orienté utilisateur : s'inscrire et se connecter, réinitialisation de mot de passe, checkout, emails, actions admin, et intégrations qui ne doivent pas casser. Si ce n'est pas sur la liste, cela ne pilote pas la décision.

Parcourez ensuite le code et mappez les plus gros échecs à leur emplacement. Choisissez les cinq problèmes qui bloquent la mise en production (pas les irritations). Pour chacun, notez le fichier ou module, la fréquence d'apparition et ce qui se produit quand il échoue (perte de données, risque de sécurité, ou simple mauvais UX).

Utilisez une fiche d'évaluation simple pour éviter les débats stériles. Notez ces trois domaines de 1 à 5 : clarté du code (peut-on suivre le flux), couverture des tests (les chemins critiques sont-ils protégés), et bases de sécurité (secrets, auth, validation). Des scores bas ne signifient pas automatiquement réécrire, mais ils changent la donne.

Séquence pratique :

1. Définir les comportements indispensables et le seuil minimum de performance et de sécurité.
2. Lister les cinq principaux bloqueurs de mise en production et pointer les endroits exacts dans le code.
3. Noter de 1 à 5 la santé du code, les tests et la sécurité, et écrire une phrase expliquant chaque note.
4. Choisir une voie : refactoriser si la plupart des bloqueurs sont locaux et compréhensibles, réécrire si les échecs sont systémiques, ou opter pour un hybride en reconstruisant une tranche bout en bout.
5. Fixer une date de checkpoint avec des critères pass/échec (par ex. : login OK, paiements réussis, pas de secrets exposés, tests de fumée verts) avant de s'engager pleinement.

Exemple rapide : une startup a une UI fonctionnelle, mais la connexion échoue aléatoirement, les emails sont peu fiables et les secrets sont codés en dur. Si les échecs se situent principalement dans un module d'auth et un helper email désordonné, un refactor ciblé plus des corrections de sécurité peut livrer plus vite. Si l'auth est imbriquée dans toute la base sans tests et des modèles de données incohérents, un plan hybride (réécrire d'abord l'auth et le flux utilisateur) est souvent plus sûr.

Si vous avez hérité d'un prototype IA, c'est précisément le type de tri que FixMyMess fait lors d'un audit gratuit : identifier les bloqueurs, noter le risque et recommander la voie la plus rapide qui tient en production.

Scénarios exemples à mapper sur votre projet

Les projets réels ressemblent rarement à des cas théoriques propres. Utilisez les scénarios ci‑dessous pour repérer le modèle qui correspond à votre cas, puis ajustez selon votre délai et votre tolérance au risque.

Scénario A : Prototype IA qui marche en démo mais échoue en production (auth cassée, secrets exposés, architecture emmêlée). Décision : Refactoriser et réparer d'abord, car la voie la plus rapide est souvent de corriger les parties dangereuses et fragiles sans jeter l'UI et les flux qui fonctionnent.

Un cas courant est une app construite dans Lovable/Bolt/v0/Cursor/Replit qui « marche en grande partie » jusqu'à l'arrivée des vrais utilisateurs. Si l'auth est instable, les variables d'environnement sont codées en dur et le code est dans un seul gros fichier, la réécriture peut sembler tentante — mais elle retarde souvent car il faut réapprendre les mêmes exigences. Le gain rapide consiste à verrouiller les secrets, réparer l'auth, démêler les pires modules et ajouter des tests basiques autour de la connexion et des actions principales. (C'est le type de travail de sauvetage pour lequel FixMyMess a été créé.)

Scénario B : App mature avec un cœur stable, mais le travail de fonctionnalités devient de plus en plus lent. Décision : Refactor ciblé, car le produit est éprouvé et la douleur vient surtout de la maintenabilité, pas de la justesse du code.

Ici l'app fonctionne, les clients en dépendent, et le problème majeur est « chaque changement casse quelque chose ». Concentrez-vous sur les hotspots : un module lent, une chaîne de dépendances désordonnée, une zone avec des bugs répétés. Refactorisez par petites tranches et mesurez le progrès par « temps pour livrer une petite fonctionnalité », pas par la quantité de code touchée.

Scénario C : Pivot produit qui change le modèle de données et les workflows (nouvelle tarification, nouvelles entités, nouveaux droits). Décision : Réécriture sélective, car forcer une nouvelle réalité dans un vieux modèle de données crée des cas limites sans fin.

Conservez ce qui fonctionne encore (design system, intégration du provider d'auth, reporting) et réécrivez les parties qui incarnent l'ancienne logique métier (schéma de données, workflows principaux). Ça évite de tout réécrire tout en supprimant la plus grande source de bugs futurs.

Scénario D : Pas de tests, beaucoup de cas limites, et un délai serré. Décision : Approche hybride, car refactor vs réécrire importe moins que réduire le risque vite.

Gelez le périmètre, ajoutez une fine « ceinture de sécurité » de tests autour des 3 parcours utilisateur les plus critiques, puis corrigez les échecs les plus dangereux. Si une section est trop risquée à toucher, réécrivez cette pièce derrière un feature flag ou un endpoint parallèle, puis basculez-la quand elle passe les nouveaux tests.

Erreurs communes qui font perdre des semaines

Le plus grand gaspillage de temps dans ce choix est de croire qu'on peut faire de gros changements en toute sécurité sans savoir ce qui peut casser. Si vous ne pouvez pas dire rapidement si signup, login, checkout et emails fonctionnent après un changement, chaque étape devient un test manuel long.

Erreur 1 : Refactoriser sans tests et prétendre que c'est « sûr »

Le refactor peut être plus rapide, mais seulement si vous avez un filet de sécurité basique. Sans tests (ou au moins un petit ensemble de vérifications répétables), vous faites deux fois le même travail : améliorer le code, puis chasser les bugs introduits par le refactor.

Correction simple : avant de toucher à l'architecture, écrivez quelques vérifications à haute valeur pour les flux qui rendent l'app réelle. Pensez « un nouvel utilisateur peut‑il s'inscrire, payer et recevoir une confirmation ».

Erreur 2 : Réécrire alors que les exigences bougent encore

Les réécritures attirent les changements d'idée. Quand la direction produit évolue tous les quelques jours, la réécriture ne « finit » jamais. Vous continuez à reconstruire la fondation pendant que le plan change.

Si vous devez réécrire, figez les indispensables pour la première livraison et repoussez les améliorations à la seconde passe. Même une définition succincte de done peut économiser des semaines.

Voici des domaines d'intégration que les équipes oublient souvent de compter dans les estimations :

• Paiements (webhooks, retries, cas limites comme les remboursements)
• Emails/SMS (deliverability, templates, désabonnement)
• Analytics (événements, identité utilisateur, confidentialité)
• Permissions/roles (admin vs user, accès aux données)
• APIs tierces (limites de taux, gestion d'erreurs)

Erreur 3 : Laisser la sécurité et la fiabilité pour la fin

Les problèmes de sécurité ne sont pas une tâche « plus tard ». Secrets exposés, auth faible et risques d'injection peuvent forcer des retouches tardives car ils touchent aux flux centraux. Il en va de même pour la fiabilité : pas de limites de débit, pas de validation d'entrée ou jobs fragiles.

Exemple : une équipe livre un tableau de bord réécrit, puis découvre que leur webhook de paiement peut être usurpé. Ils doivent alors refaire l'auth, auditer les données et patcher la production en urgence.

Erreur 4 : Polir le style du code alors que la production est cassée

Ça fait du bien de renommer des fichiers et ranger des dossiers. Mais si l'app ne se déploie pas proprement, plante sur de vraies données ou a une auth cassée, le nettoyage stylistique devient une distraction.

Si vous avez hérité d'un code généré par l'IA, les équipes se coincent souvent dans cette boucle. Des plateformes comme FixMyMess privilégient d'abord le diagnostic (qu'est‑ce qui est réellement cassé), puis des réparations ciblées pour atteindre la production sans transformer le projet en un chantier d'améliorations sans fin.

Checklist rapide avant de vous engager

Avant de choisir refactoriser ou réécrire, faites un contrôle de réalité rapide. Il s'agit moins d'opinions que de savoir si le code actuel peut être modifié en toute sécurité sans surprises.

Cinq questions qui révèlent le vrai risque

Commencez par ces vérifications et notez oui ou non. Si vous ne pouvez pas répondre, considérez‑le comme un « non » jusqu'à preuve du contraire.

• Quelqu'un peut‑il expliquer le chemin principal des données depuis l'action utilisateur jusqu'à la base, sans improviser ?
• Avez‑vous des tests automatisés pour les trois actions les plus importantes (par ex. : inscription, connexion, et checkout ou création de projet) ?
• Y a‑t‑il quelque chose d'évidemment dangereux maintenant (clés API codées en dur, routes admin ouvertes, auth faible, requêtes SQL dangereuses) ?
• Combien de services externes doivent fonctionner le jour J (paiements, email, analytics, stockage de fichiers) ?
• Un nouveau développeur peut‑il ouvrir le repo et comprendre la structure en 1–2 heures ?

Si vous avez répondu « non » à un item, vous pouvez encore refactoriser, mais votre estimation doit inclure du temps pour réduire ce risque (ajouter des tests, cartographier les flux, corriger la sécurité). Si vous avez répondu « non » à trois items ou plus, une réécriture devient souvent la voie la plus rapide parce que vous payez une « taxe de découverte » à chaque changement.

Interpréter rapidement vos réponses

Imaginez un scénario simple : un fondateur a un prototype construit par un outil IA, la connexion marche localement mais échoue en production. S'il n'y a pas de tests, un flux de données flou et des secrets exposés, chaque correctif peut casser autre chose. Dans ces cas, les équipes passent souvent des jours à chasser les symptômes.

C'est là qu'un petit audit de code aide. Chez FixMyMess, nous voyons le même pattern dans les apps générées par l'IA : logique d'auth collée, secrets commis dans le repo, intégrations qui se comportent différemment en production. Quand tout cela arrive ensemble, le choix « rapide » le plus sûr est celui qui réduit d'abord les inconnues, même si sur le papier il paraît plus gros.

Prenez votre décision seulement après pouvoir expliquer : ce qui doit marcher le jour J, ce qui peut attendre, et ce que vous pouvez vérifier avec des tests.

Étapes suivantes : décider et aller en production

Choisissez la plus petite livraison que vous pouvez mettre en production, puis définissez le « done » en termes clairs. Pas « le code est plus propre » ni « l'architecture est moderne », mais des résultats comme : les utilisateurs peuvent s'inscrire, payer et accomplir l'action principale sans erreur. Un objectif plus petit facilite le choix entre refactoriser et réécrire parce que vous pouvez juger quelle voie atteint la ligne d'arrivée avec moins de risques.

Écrivez votre définition de « done » comme une petite checklist que vous pouvez tester en une seule session :

• Le flux utilisateur principal fonctionne de bout en bout (chemin « happy path »)
• Connexion, paiements et emails se comportent correctement
• Aucun secret exposé et les vérifications de sécurité de base sont passées
• L'app se déploie de manière fiable dans votre environnement réel

Si votre app a été générée par un outil IA et qu'elle échoue en production, commencez par un diagnostic avant de vous engager sur une voie. Les prototypes IA semblent souvent complets mais cachent des problèmes comme une authentification cassée, une logique emmêlée et des requêtes base de données non sûres. Les corriger à l'aveugle peut se transformer en semaines de devinettes.

Option pratique : obtenir un audit expert d'abord. FixMyMess (fixmymess.ai) propose un audit gratuit du code pour identifier ce qui est cassé, risqué et ce qui peut être sauvé. Beaucoup de remédiations se bouclent en 48–72 heures une fois les problèmes clarifiés. Et si le prototype est fortement endommagé, une reconstruction propre peut être plus rapide que de colmater autour d'un code fragile, parfois aussi rapide que 24 heures pour un périmètre ciblé.

Voici une manière simple d'avancer aujourd'hui : imaginez que vous avez besoin d'un onboarding fonctionnel d'ici vendredi. Si le code actuel a déjà les écrans, le routage et le modèle de données, refactoriser plus des corrections ciblées peut vous y amener. Si les actions de base plantent, que l'état est incohérent et que vous ne pouvez pas savoir ce que chaque changement va casser, réécrire la plus petite tranche livrable est souvent plus sûr.

Si vous voulez une recommandation claire, partagez votre délai, ce que « done » signifie et ce qui échoue actuellement. Vous obtiendrez une réponse directe : refactoriser, réécrire ou un plan hybride pour vous mener en production rapidement.