Comment estimer le budget d'une refonte d'application legacy

Comment estimer le budget refonte application legacy quand personne ne connaît vraiment toutes ses dépendances ? La bonne estimation est une fourchette construite après audit, pas un prix fixe calculé au nombre d'écrans. Une application ancienne concentre du code, des données, des règles métier implicites, des intégrations oubliées et des habitudes utilisateurs. Le budget doit donc couvrir autant la compréhension du système que sa reconstruction.

Sur les projets que je vois passer, la précision du chiffrage dépend moins de la taille du cahier des charges que de la qualité de l'audit initial. Un devis sérieux ne donne pas un chiffre unique trop tôt. Il expose une fourchette, les hypothèses qui la soutiennent et les risques susceptibles de la déplacer.

Ces fourchettes ne sont pas des tarifs universels. Elles servent de point de départ pour poser le vrai calcul.

Commencer par choisir le bon niveau de refonte

Le mot « refonte » mélange souvent quatre projets très différents. Or, le choix de la stratégie peut multiplier le budget par cinq.

Microsoft distingue notamment le rehosting, le replatforming, le refactoring et le rebuilding dans son guide des stratégies de modernisation. Déplacer l'application vers une infrastructure plus récente sans toucher au cœur du code n'a rien à voir avec une reconstruction complète.

Replatformer, refactorer ou reconstruire ?

Le replatforming conserve l'essentiel du code et change surtout l'environnement d'exécution, la base de données ou le système de déploiement. C'est l'option la moins chère, mais elle laisse une partie de la dette technique en place.

Le refactoring modifie les zones fragiles sans changer le comportement visible. Il convient lorsque les règles métier restent valables et que l'architecture peut encore évoluer progressivement.

La reconstruction repart sur une nouvelle base. Elle devient logique quand la technologie n'est plus maintenue, que chaque évolution casse une autre fonction, ou que le produit doit changer profondément. Elle coûte plus cher au départ, mais peut être moins risquée qu'un refactoring sans fin.

Avant de chiffrer, écrivez donc une phrase de décision : « Nous conservons le métier et les données, mais remplaçons l'interface, l'API et le déploiement » est beaucoup plus utile que « nous modernisons l'application ».

Fixer les résultats attendus avant la stack

Une refonte ne devrait pas être justifiée par « le code est vieux ». Elle doit répondre à des résultats mesurables : réduire le temps de mise en production, supprimer une technologie en fin de support, diviser les incidents, améliorer les performances ou rendre possible une nouvelle offre.

Cette étape évite de reconstruire des fonctions inutilisées. Elle permet aussi d'arbitrer. Si l'objectif prioritaire est de fiabiliser les mises en production, une nouvelle interface complète peut attendre. Si le problème est l'impossibilité de recruter sur la stack, la migration technique devient prioritaire.

Auditer l'existant avant d'annoncer un prix

Un audit de refonte n'est pas une formalité commerciale. C'est une phase de production à part entière. Microsoft recommande de commencer par un inventaire des applications, des données et de l'infrastructure afin d'évaluer les coûts et de construire un plan de modernisation cohérent dans son guide d'évaluation.

Pour une application métier moyenne, je prévois généralement 5 à 15 jours d'audit. Une plateforme critique, connectée à plusieurs systèmes, peut demander 20 à 30 jours.

Les six éléments à inventorier

L'audit doit produire au minimum :

1. une carte des modules et des parcours critiques ;
2. une liste des dépendances internes et externes ;
3. un inventaire des bases, volumes et règles de conservation ;
4. une mesure de la couverture de tests et des zones non testables ;
5. une cartographie de l'infrastructure, des déploiements et des accès ;
6. une liste des risques de sécurité, de conformité et de continuité.

Il faut aussi interroger les personnes qui utilisent ou maintiennent l'application. Une règle métier absente du code peut vivre dans un export Excel, une procédure manuelle ou la mémoire d'un salarié. Si elle est découverte au milieu du développement, elle devient un dépassement de budget.

Transformer les inconnues en hypothèses chiffrées

Chaque inconnue importante doit apparaître dans l'estimation. Par exemple : « la migration suppose que 95 % des enregistrements respectent le schéma actuel » ou « l'API du prestataire reste compatible pendant six mois ».

Une hypothèse vérifiable peut être testée pendant un court prototype. Une inconnue non traitée devient une marge de sécurité. C'est la différence entre un budget pilotable et un chiffre rassurant mais fragile.

Pour les applications dont la documentation est pauvre, je recommande un premier lot fermé : audit, cartographie, preuve de migration sur un échantillon de données et proposition d'architecture. Le budget global est recalculé seulement après ce lot.

Calculer la charge par poste, pas par écran

Compter les écrans sous-estime presque toujours une refonte. Deux pages visuellement simples peuvent cacher une gestion complexe des droits, des traitements asynchrones et quatre intégrations.

Le calcul le plus lisible est :

Budget = (jours de cadrage + UX + développement + données + tests + infrastructure + bascule) × TJM + coûts externes + réserve de risque

Pour comprendre le coût du mode de collaboration, notre comparatif forfait ou régie pour un projet de développement détaille les effets des avenants et du risque intégré au prix.

Ventiler les jours de travail

Voici un exemple pour une application métier de taille intermédiaire, avec une interface web, une API, une base de données et trois intégrations externes.

À 180 €/jour, cette estimation représente 19 620 à 40 860 € avant les licences, l'hébergement et la réserve. Avec 20 % de risque, l'enveloppe devient 23 544 à 49 032 €.

Ce tableau oblige à discuter des vrais postes. Si un devis ne réserve presque rien aux tests, aux données ou à la bascule, ces tâches n'ont pas disparu. Elles seront improvisées ou facturées plus tard.

Ajouter les coûts que le devis oublie

Le budget projet ne se limite pas aux jours du prestataire. Ajoutez :

1. le temps des experts métier et du responsable produit ;
2. les licences temporaires et définitives ;
3. le double hébergement pendant la transition ;
4. les audits de sécurité ou de conformité ;
5. la formation et la documentation ;
6. la maintenance corrective après la mise en ligne ;
7. le coût d'une interruption de service ;
8. le maintien de l'ancien système jusqu'à validation.

La migration des données mérite une ligne propre. Elle comprend le nettoyage, les scripts de transformation, les répétitions à blanc, les contrôles d'intégrité et parfois une période de synchronisation entre les deux systèmes.

Appliquer une réserve de risque explicite

Une réserve n'est pas un montant caché destiné au prestataire. C'est une enveloppe contrôlée, débloquée seulement lorsqu'un risque identifié se produit.

Choisir le bon pourcentage

Une réserve de 10 à 15 % peut suffire si le code est documenté, les tests fiables, les dépendances connues et les experts métier disponibles.

Prévoyez 20 à 25 % si certaines parties du système restent opaques, si les données sont irrégulières ou si plusieurs fournisseurs externes sont impliqués.

Montez à 30 à 40 % pour une application critique sans tests, maintenue par une personne, construite sur une technologie obsolète et impossible à reproduire localement. Dans ce dernier cas, mieux vaut souvent financer un audit plus poussé que gonfler aveuglément la réserve.

Chiffrer trois scénarios

Je présente toujours trois scénarios :

1. Optimiste : les hypothèses sont confirmées, aucune dépendance majeure ne bloque.
2. Probable : quelques anomalies apparaissent, sans remettre l'architecture en cause.
3. Dégradé : une migration, une intégration ou une règle métier impose une reprise importante.

Le budget de décision doit être le scénario probable. Le scénario dégradé sert à vérifier que l'entreprise pourrait terminer le projet sans l'abandonner à 80 %.

Découper la refonte pour maîtriser la dépense

Une refonte complète en un seul tunnel concentre le risque. Un découpage progressif permet de valider l'architecture, les données et la capacité de livraison avant d'engager toute l'enveloppe.

Les quatre lots que je recommande

Le premier lot couvre l'audit et le prototype technique. Le deuxième reconstruit un parcours métier vertical, de l'interface à la base de données. Le troisième migre les fonctions restantes par priorité. Le quatrième prépare la bascule, le retour arrière et la fermeture de l'ancien système.

Chaque lot doit avoir des critères d'acceptation observables. Le parcours vertical, par exemple, n'est pas « terminé » quand les écrans existent. Il doit fonctionner avec des données réalistes, des droits corrects, des logs, des tests et un déploiement reproductible.

Ce fonctionnement rejoint la logique décrite dans notre méthode pour piloter un développeur en régie à distance : backlog priorisé, points courts et validation fréquente des livrables.

Suivre le budget chaque semaine

Le tableau de bord peut rester simple :

1. jours consommés par poste ;
2. reste à faire réestimé ;
3. risques ouverts et réserve consommée ;
4. décisions métier en attente ;
5. périmètre ajouté, supprimé ou reporté.

La métrique importante n'est pas le pourcentage de tâches fermées. C'est le coût estimé à terminaison. Une équipe peut avoir consommé 50 % du budget et terminé 70 % des tickets tout en restant en retard si les 30 % restants concentrent la migration et les cas complexes.

Le budget réaliste d'une refonte legacy

Pour une application interne limitée, correctement documentée et sans forte contrainte de disponibilité, une enveloppe de 10 000 à 20 000 € peut suffire.

Pour une application métier intermédiaire avec une base historique et plusieurs intégrations, la zone réaliste se situe plutôt entre 25 000 et 50 000 €.

Pour une plateforme critique, multi-rôles, avec migration complexe et continuité de service, il faut souvent prévoir 60 000 à 100 000 € ou plus.

Ces montants sont cohérents avec notre analyse plus large du coût de développement d'une application, mais une refonte ajoute deux postes absents d'un projet neuf : la compréhension de l'existant et la transition sans perte de service.

Mon verdict : ne demandez pas « combien coûte la refonte ? » avant d'avoir payé pour réduire les inconnues. Demandez d'abord combien coûte l'audit qui permettra de choisir la stratégie, de ventiler les jours et de tester la migration. Un budget crédible n'est pas celui qui affiche le montant le plus précis. C'est celui qui montre clairement ce qui pourrait le faire changer.

« Sur une application legacy, l'audit n'est pas un coût avant le projet. C'est la première étape du projet. »

Vincent Roye