Reprise, refonte progressive ou refonte complète : le tableau comparatif
Reprendre un logiciel, c'est garder son code et le remettre en état avant de le faire évoluer. Le refaire, c'est écrire un nouveau logiciel qui remplacera l'ancien, soit d'un bloc, soit par morceaux. Ces trois chemins n'ont ni le même risque ni le même calendrier.
| Critère | Reprise de l'existant | Refonte progressive | Refonte complète |
|---|---|---|---|
| Point de départ | Le code actuel, sécurisé et documenté | Le code actuel, remplacé module par module | Une page blanche, avec l'ancien logiciel comme référence |
| Premières améliorations visibles | Rapides : corrections et petites évolutions | Au premier module remplacé | À la mise en service du nouveau logiciel |
| Investissement de départ | Le plus faible | Étalé dans le temps | Le plus élevé, concentré |
| Dette technique | Réduite peu à peu, jamais effacée | Supprimée module après module | Remise à zéro |
| Interruption pour les utilisateurs | Aucune | Changements limités à un module à la fois | Une bascule globale à préparer |
| Données | Conservées en place | Partagées ou synchronisées pendant la transition | Migrées en une fois, après des répétitions |
| Risque principal | Découvrir tard une fragilité profonde | Faire cohabiter deux systèmes trop longtemps | Oublier des règles que seul l'ancien logiciel appliquait |
Les six critères qui font pencher la balance
| Critère | Signal en faveur de la reprise | Signal en faveur de la refonte |
|---|---|---|
| Qualité du code | Structure lisible, nommage clair, quelques tests | Fichiers de milliers de lignes, copier-coller partout, aucune correction sans effet de bord |
| Technologies | Langage et bibliothèques qui reçoivent encore des correctifs | Environnement abandonné par son éditeur ou par sa communauté |
| Documentation | Installation et déploiement reproductibles | Personne ne sait reconstruire la version en production |
| Données | Modèle cohérent avec le métier actuel | Modèle qui oblige à détourner des champs pour suivre l'activité |
| Budget | Trésorerie limitée, besoin d'étaler l'effort | Coût de maintenance annuel qui ne cesse de monter |
| Urgence | Un incident ou une obligation à traiter tout de suite | Un logiciel qui tient encore, laissant le temps de construire |
Un seul signal rouge ne suffit pas à justifier une refonte : un code médiocre écrit dans une technologie vivante se reprend souvent très bien. C'est la combinaison de plusieurs signaux qui fait basculer la décision. La notion de dette technique aide à mesurer ce que coûte chaque année le statu quo.
Ce que l'audit préalable doit établir
L'audit répond à des questions fermées, auxquelles on doit pouvoir répondre par oui ou par non avec une preuve.
- Avez-vous tous les accès ? Hébergement, base de données, dépôt de code, nom de domaine, comptes des stores, services tiers : qui en est titulaire ?
- Le code récupéré produit-il exactement la version en production ? Si personne ne sait la reconstruire, chaque correction devient un pari.
- Les dépendances sont-elles à jour et maintenues ? La CNIL consacre une fiche de son guide RGPD pour l'équipe de développement à la maîtrise des bibliothèques et des SDK, et une autre à la qualité du code et à sa documentation : ce sont précisément les points que l'audit vérifie.
- Des tests protègent-ils les parcours critiques ? Facturation, calculs de prix, droits d'accès.
- Le modèle de données colle-t-il au métier d'aujourd'hui ? Ou des champs détournés trahissent-ils des contournements anciens ?
- Quelles failles évidentes existent ? Mots de passe écrits en clair dans le code, comptes administrateurs oubliés, données exposées.
Le contenu et le coût d'un tel examen sont détaillés dans la page combien coûte un audit de code. Quand le prestataire d'origine a disparu, commencez par la page reprendre un logiciel abandonné, qui traite des accès à récupérer en priorité.
Pourquoi une technologie en fin de vie change la décision
Une technologie en fin de vie ne reçoit plus de correctifs de sécurité. Or l'ANSSI, dans ses dix règles d'or de la sécurité numérique, demande d'appliquer les mises à jour dès qu'elles sont proposées : sur un environnement abandonné, il n'y a plus rien à appliquer. Le RGPD, de son côté, impose à l'article 32 des mesures garantissant la confidentialité, l'intégrité et la disponibilité des données, et une évaluation régulière de leur efficacité. Un logiciel bâti sur des composants figés rend ces obligations de plus en plus difficiles à tenir.
Le second effet est humain. Une technologie de niche ou vieillissante attire peu de développeurs : chaque intervention coûte plus cher, et le jour où la seule personne qui la maîtrise s'en va, le logiciel devient intouchable. Dans ce cas, la reprise n'achète que du temps, et ce temps doit servir à préparer la suite.
La refonte progressive : remplacer sans arrêter l'activité
La refonte progressive construit le nouveau logiciel à côté de l'ancien et transfère les usages par étapes. Le principe tient en quatre gestes :
- découper l'existant en blocs fonctionnels (planning, interventions, facturation, rapports) ;
- construire le premier bloc dans la nouvelle application, branché sur des données communes ou synchronisées ;
- basculer les utilisateurs de ce bloc, en gardant l'ancien écran accessible en consultation ;
- recommencer avec le bloc suivant, puis éteindre l'ancien logiciel quand plus personne ne s'en sert.
Le projet Cap Vert applique cette prudence aux données. YMHB Web y a remplacé un outil hérité d'un prestataire précédent par un tableau de bord web et une application mobile iOS et Android pour les équipes de nettoyage. Près de 10 000 enregistrements (environ 1 200 clients, 1 380 chantiers, 4 000 interventions, 3 000 rapports) sont passés de l'ancienne base MongoDB vers PostgreSQL, synchronisés pendant toute la transition et contrôlés champ par champ, sans perte. La génération d'un rapport PDF est passée d'environ 2,6 secondes à moins d'une seconde, et les équipes ont basculé sur les nouvelles applications en août 2026.
Notre verdict selon votre situation
| Votre situation | Recommandation |
|---|---|
| Code récent, technologies courantes, prestataire parti | Reprise : sécuriser, documenter, ajouter des tests, puis reprendre les évolutions |
| Une partie saine, une partie fragile | Refonte progressive, en commençant par le module qui casse le plus |
| Technologie abandonnée, données saines | Refonte progressive ou complète, avec reprise intégrale des données |
| Projet jamais terminé, aucune version utilisable | Refonte complète, en se servant de l'existant comme cahier des charges |
| Incident ou obligation à traiter cette semaine | Reprise ciblée d'abord, décision de fond ensuite |
| Logiciel stable, peu modifié, qui fait le travail | Ni l'un ni l'autre : une maintenance sérieuse suffit |
Quand aucune des deux options ne convient
- Un logiciel du marché fait désormais le travail : migrer les données vers cet outil coûte souvent moins cher que reprendre ou refaire un code spécifique.
- Le logiciel n'a presque plus d'utilisateurs : archiver les données et l'arrêter proprement est parfois la décision la plus saine.
- Le problème vient du processus : réécrire un outil qui reproduit une organisation confuse ne la rend pas plus claire. On clarifie d'abord qui fait quoi.
- Le différend avec l'ancien prestataire est juridique : si le code est retenu en contrepartie d'une facture contestée, le sujet relève d'un avocat avant d'être technique.
Ce que YMHB Web livre à l'issue de l'audit
YMHB Web conclut l'audit par une recommandation écrite et argumentée : reprise, refonte progressive ou refonte complète. En cas de reprise, le travail commence par la sécurisation, la documentation et des tests sur les parcours critiques, comme le décrit l'offre de reprise d'un logiciel existant. En cas de refonte, la préférence va au remplacement progressif et à une migration des données vérifiée avant chaque bascule. Dans les deux cas, le code et les accès sont remis au nom du client, et le code lui appartient au paiement intégral. Les facteurs qui font varier le budget sont présentés dans la page combien coûte la refonte d'un logiciel.
Questions fréquentes
Une refonte coûte-t-elle toujours plus cher qu'une reprise ?
Une refonte coûte plus cher au départ qu'une reprise, mais pas forcément sur la durée de vie du logiciel. Quand le code est fragile ou repose sur une technologie qui ne reçoit plus de correctifs, chaque évolution d'un logiciel repris coûte davantage année après année. La comparaison doit porter sur plusieurs années : investissement initial, maintenance annuelle et coût des incidents dans les deux scénarios.
Qu'est-ce qu'une refonte progressive d'un logiciel ?
Une refonte progressive consiste à remplacer un logiciel module par module, en construisant le nouveau à côté de l'ancien. Les deux partagent ou synchronisent leurs données pendant la transition, les utilisateurs basculent bloc par bloc, et l'ancien logiciel reste consultable jusqu'à son arrêt. Cette approche évite une bascule unique risquée et permet de corriger la trajectoire après chaque étape.
Les données sont-elles perdues lors d'une refonte ?
Les données ne sont pas perdues lors d'une refonte bien menée : elles sont migrées de l'ancienne base vers la nouvelle, après des répétitions et des contrôles. Une bonne pratique consiste à vérifier les enregistrements champ par champ, à synchroniser les deux bases pendant la transition et à ne jamais supprimer l'ancienne avant que le nouveau logiciel ait fait ses preuves auprès des utilisateurs.
Faut-il refaire son logiciel quand on change de prestataire ?
Changer de prestataire ne justifie pas à lui seul de refaire un logiciel. Un nouveau prestataire peut préférer réécrire ce qu'il ne connaît pas, mais la décision doit reposer sur un audit écrit : accès, qualité du code, technologies, données et documentation. Si le code se relit et que ses technologies sont maintenues, la reprise est généralement la voie la plus économique et la moins risquée.
Que faire si le code récupéré ne correspond pas à la version en production ?
Si le code récupéré ne correspond pas à la version en production, il faut d'abord sauvegarder la production telle qu'elle tourne, puis mesurer l'écart : fonctions absentes, fichiers modifiés directement sur le serveur, configuration manquante. Selon l'ampleur de l'écart, on reconstitue le code à partir de la production ou l'on s'oriente vers une refonte, en se servant de l'application existante comme référence fonctionnelle.
À lire aussi
Sources
- CNIL, La CNIL publie une nouvelle version de son guide RGPD pour l'équipe de développement (13 décembre 2021 : fiches code source, bibliothèques et SDK, qualité du code et documentation)
- ANSSI, Les 10 règles d'or de la sécurité numérique
- CNIL, texte du RGPD, chapitre IV (article 32, sécurité du traitement)