Votre application vieillit, chaque évolution coûte plus cher que la précédente, et un développeur vous a dit : « Le plus simple, ce serait de tout refaire. » Avant de signer, sachez que refaire son application de zéro est rarement le plus simple, et presque jamais le plus rapide. Dans la plupart des cas, reprendre l'existant et le moderniser par étapes coûte moins cher et fait courir moins de risques.
Il existe pourtant de vrais cas où repartir d'une page blanche se justifie. Toute la question est de les reconnaître sur des faits, et non sur l'impression qu'un code est « sale ». Depuis l'arrivée d'outils comme Claude Code ou Cursor, la tentation de tout régénérer est encore plus forte : raison de plus pour savoir ce que vous jetez.
Voici comment raisonner, en tant que dirigeant, pour trancher entre réécriture et reprise.
Refaire son application de zéro : pourquoi l'idée séduit
La réécriture a tout pour plaire. Le code actuel est difficile à lire, personne ne sait vraiment comment il fonctionne et chaque modification provoque des effets de bord. Un développeur qui arrive sur un projet préfère presque toujours écrire son propre code plutôt que comprendre celui d'un autre : c'est plus agréable, et on a l'impression d'avancer vite.
Côté dirigeant, la promesse séduit aussi : repartir sur des bases saines, avec une technologie récente. « Cette fois, on fera les choses bien. » Et depuis que l'IA générative sait produire une application en quelques jours, l'argument du coût semble balayé.
Le problème, c'est que ce raisonnement compare une application réelle, avec tous ses défauts visibles, à une application imaginaire qui n'en a encore aucun.
Ce qu'une réécriture fait perdre, et qu'on ne voit pas
En 2000, Joel Spolsky publiait un texte resté célèbre, Things You Should Never Do, Part I. Il y qualifie la décision de Netscape de réécrire son navigateur de zéro de « pire erreur stratégique » qu'un éditeur de logiciel puisse commettre. Son argument central tient toujours : les lignes de code qui paraissent bizarres sont souvent des corrections de bugs. Chacune correspond à un cas réel qu'un utilisateur a rencontré un jour.
Concrètement, quand vous jetez une application qui tourne depuis des années, vous jetez aussi :
- les règles métier implicites : ce calcul de remise particulier pour un client historique, cette exception sur les jours fériés, ce format d'export qu'un partenaire exige ;
- les cas limites déjà rencontrés et corrigés, que personne n'a documentés ;
- les données et leur historique, qu'il faudra migrer vers une nouvelle structure, avec toutes les incohérences accumulées ;
- du temps : pendant la réécriture, l'application actuelle doit continuer de tourner, et souvent d'évoluer. Vous payez deux applications à la fois.
Spolsky ajoutait qu'une réécriture offre plusieurs années d'avance à vos concurrents, le temps de retrouver le niveau fonctionnel de départ. L'IA accélère l'écriture du code. Elle n'accélère pas la redécouverte de tout ce que l'ancienne application faisait sans que personne le sache. C'est même là que le code généré par IA est le plus fragile : il couvre bien le scénario décrit, moins bien les cas auxquels personne n'a pensé.
Les cas où repartir de zéro se justifie vraiment
Repartir de zéro n'est pas toujours une erreur. C'est justifié quand plusieurs de ces conditions sont réunies :
- L'application est petite, et ses règles métier tiennent sur quelques pages que vous pouvez écrire vous-même.
- La technologie n'a plus d'avenir : langage ou framework abandonné, plus de mises à jour de sécurité, plus de développeurs disponibles. Attention, une version ancienne d'un framework toujours maintenu n'entre pas dans ce cas : une application Laravel 8, on la met à jour, on ne la réécrit pas.
- Le besoin a changé de nature : l'outil interne doit devenir un produit vendu à des clients, avec des exigences de sécurité et de gestion multi-utilisateurs jamais prévues au départ.
- Le prototype n'a jamais été pensé pour durer : typiquement, une application générée en quelques jours pour valider une idée, sans base de données structurée ni contrôle d'accès sérieux.
Sur ce dernier point, les applications construites avec Lovable ou Bolt s'examinent au cas par cas. Certaines se reprennent très bien. D'autres gagnent à être reconstruites sur une base saine, en récupérant l'interface et les données. Nous détaillons ce diagnostic dans Application Lovable : quand passer la main à un développeur, et comment préparer la reprise.
À l'inverse, « le code est mal écrit » ou « je ne connais pas cette technologie » ne suffisent pas. Ce sont des raisons pour lesquelles un développeur préfère réécrire, pas des raisons pour lesquelles votre entreprise doit payer une réécriture.
La voie du milieu : remplacer l'application morceau par morceau
Entre « tout garder tel quel » et « tout jeter », il existe une approche éprouvée. Martin Fowler l'a baptisée Strangler Fig Application, d'après le figuier étrangleur, qui pousse autour d'un arbre hôte et finit par le remplacer. Le principe : construire le nouveau à côté de l'ancien, puis y déplacer les fonctionnalités une par une. Fowler en résume l'intérêt : chaque morceau étant petit, chaque mise en service fait courir peu de risque.
Dans une PME, cela donne par exemple :
- Stabiliser l'existant : sauvegardes vérifiées, mises à jour de sécurité, surveillance, déploiement reproductible.
- Isoler la partie la plus douloureuse, celle qui bloque les évolutions ou concentre les bugs, et la refaire proprement, avec des tests.
- Mettre ce morceau en production seul, vérifier qu'il fonctionne, puis passer au suivant.
- Retirer l'ancien code au fur et à mesure qu'il ne sert plus.
L'avantage pour vous : l'application continue de rendre service pendant toute l'opération. Chaque étape peut être arrêtée ou réorientée, et vous voyez des résultats dès les premières semaines, au lieu d'attendre une bascule finale qui ne cesse d'être repoussée.
Pour une application Laravel, la première étape est souvent une montée de version. Laravel annonce une politique de support claire : 18 mois de corrections de bugs et 2 ans de correctifs de sécurité pour chaque version majeure (documentation Laravel, politique de support). Une application qui n'est plus couverte appelle une mise à niveau, pas forcément une réécriture.
Comment décider sur des faits plutôt qu'au ressenti
Avant de choisir, demandez un état des lieux court, fondé sur des critères vérifiables. Les questions à poser :
- Le code est-il récupérable et déployable ? Avez-vous le dépôt complet et les accès à l'hébergement ? Peut-on remettre l'application en ligne à l'identique ?
- Quelle part de l'application pose problème ? Souvent, l'essentiel des difficultés se concentre dans un ou deux modules.
- La technologie est-elle encore maintenue, et existe-t-il un chemin de mise à jour ?
- Les données sont-elles saines et documentées ?
- Quelles évolutions voulez-vous dans les douze prochains mois ? C'est ce besoin, et non l'état du code, qui doit guider la décision.
Si vous reprenez une application Laravel laissée par un ancien prestataire, la marche à suivre est détaillée dans Reprise d'une application Laravel : par où commencer quand le prestataire est parti. Pour une application construite avec l'IA, l'équivalent est un audit ciblé : voir ce que l'audit doit couvrir et comment s'y préparer.
Méfiez-vous d'un devis de réécriture qui arrive sans cet état des lieux. Un prestataire qui n'a pas lu votre code ne peut pas savoir ce qu'il vous propose de jeter.
Questions fréquentes
L'IA ne rend-elle pas la réécriture beaucoup moins chère ?
Elle accélère l'écriture du code. Elle n'accélère ni la redécouverte des règles métier cachées dans l'ancienne application, ni la migration des données, ni les tests avec vos utilisateurs. Ce sont ces postes qui font déraper les réécritures.
Combien de temps prend une modernisation progressive ?
Cela dépend entièrement de la taille de l'application et de vos priorités. Tout l'intérêt de l'approche progressive, c'est justement de pouvoir s'arrêter dès que le résultat vous suffit.
Et si mon prestataire actuel insiste pour tout refaire ?
Demandez-lui de lister ce que fait l'application actuelle, règle par règle, et d'expliquer comment chacune sera reproduite. S'il ne peut pas répondre, la réécriture n'est pas prête à démarrer.
Reprendre une application existante et la faire évoluer sans tout casser, c'est le cœur de l'offre Pilote : Devnco développe par étapes, avec des livraisons régulières. Si vous hésitez entre reprise et réécriture, parlons-en : une heure passée ensemble sur l'existant suffit souvent à y voir plus clair.