Prix de la refonte d'un logiciel métier : les postes de coût et comment les maîtriser

Le prix de la refonte d'un logiciel métier ne se donne pas au téléphone : il dépend surtout des règles métier à retrouver, du volume et de l'état des données à reprendre, des outils reliés au logiciel et de la durée pendant laquelle l'ancien et le nouveau doivent cohabiter. Le nombre d'écrans pèse beaucoup moins qu'on ne le croit. Une refonte bien préparée se chiffre par module, avec un prix ferme pour chacun, plutôt qu'en un montant global.

Cet article détaille ce que vous payez réellement dans une refonte, poste par poste, ce qui fait monter ou baisser la facture, et comment lire un devis. Il complète notre article sur le prix d'une application métier sur mesure, qui traite d'un projet neuf.

Un repère de marché, et ses limites

Peu de sources indépendantes publient des budgets réels. La plateforme d'avis B2B Clutch compile ceux que déclarent les clients dans ses avis vérifiés. Sa page de tarifs du développement logiciel, mise à jour le 21 septembre 2026, indique :

Ce repère vaut ce qu'il vaut. Les chiffres sont mondiaux, ils mêlent des pays aux coûts très différents, et ils couvrent tous les types de projets, pas spécifiquement les refontes. La moyenne est tirée vers le haut par les gros projets : la tranche la plus fréquente décrit mieux un projet courant. Enfin, rien n'y couvre la vie du logiciel après la mise en production.

Méfiez-vous des fourchettes précises publiées sans source : elles reflètent les tarifs d'un prestataire, pas ceux du marché, et ne disent rien de votre logiciel.

Ce qu'une refonte coûte de plus qu'un projet neuf

Une refonte n'est pas un projet neuf avec un modèle à recopier. Elle ajoute des postes qu'un projet partant de zéro n'a pas, et ce sont eux qui font déraper les budgets.

Deux de ces postes sont presque toujours sous-estimés. La reprise des données, d'abord : un export ne suffit pas, il faut décider avec le métier ce qui fait foi, ce qui s'abandonne et ce qui se corrige. Nous lui consacrons un article, la reprise de données lors d'une migration de logiciel. La cohabitation, ensuite : tant que l'ancien logiciel tourne, il faut le maintenir, le sauvegarder et le raccorder au nouveau.

Ce qui fait monter ou baisser la facture

Les facteurs qui font monter le prix

• Des règles métier non documentées : tarifs par client, remises en cascade, calculs d'échéances. Chacune doit être retrouvée, comprise, testée.
• Des intégrations nombreuses : comptabilité, ERP, banque, site, outils des clients ou des fournisseurs. Chaque échange se reconstruit et se teste.
• Des données abondantes et sales : plusieurs bases, des doublons, des formats changeants au fil des versions.
• Un code inaccessible ou illisible : sans code source, ou dans un langage que peu de développeurs pratiquent, l'analyse se fait par l'usage, ce qui demande plus de temps avec les utilisateurs.
• Des contraintes réglementaires : données de santé, facturation électronique, traçabilité.
• Une bascule d'un bloc imposée : quand l'ancien logiciel ne peut pas cohabiter, toute la recette se concentre à la fin, avec plus de marge de sécurité.

Les leviers qui le font baisser

• Retirer avant de refaire. Dans un logiciel ancien, une partie des écrans et des options ne sert plus. Les identifier avant le chiffrage est le levier le plus puissant.
• Remplacer le standard par un produit. Comptabilité, paie, messagerie : un logiciel du marché fait souvent aussi bien. On ne reconstruit que ce qui vous est propre.
• Valider sur prototype avant de développer. Un écran corrigé sur un prototype coûte quelques minutes ; le même écran corrigé après développement coûte des jours.
• Découper en modules. Chaque module se chiffre, se livre et se paie séparément, et chacun sert dès sa mise en production.
• Garder la base existante pendant la transition, quand elle est saine : le nouveau logiciel la lit, et la reprise se fait par étapes.

La méthode qui permet ce découpage est détaillée dans la refonte d'une application métier, tout réécrire ou moderniser par étapes.

Forfait, régie ou abonnement : trois façons de payer une refonte

La régie paraît souple, mais une refonte est l'exemple même du projet qui découvre des surprises en route : chacune se paie alors au temps passé. Le forfait n'a de sens que sur un périmètre décrit, d'où l'intérêt d'un découpage en modules et d'un prototype validé. Les deux logiques sont comparées en détail dans forfait ou régie pour un logiciel métier.

L'abonnement répond à une autre question : comment éviter de refaire la même refonte dans dix ans. En payant chaque mois le logiciel, sa maintenance et ses évolutions, vous lissez la dépense et le prestataire a intérêt à garder le code sain. Le choix est discuté dans application à l'abonnement ou au forfait.

Le coût de ne rien faire

Le prix d'une refonte se compare à celui du statu quo, qui n'est jamais nul. Il ne figure sur aucune facture, mais il se chiffre :

• le temps perdu en contournements, ressaisies et exports manuels, multiplié par le nombre de personnes et de semaines ;
• le risque de panne sans personne pour réparer, et ce qu'une journée d'arrêt coûterait à l'activité ;
• la sécurité : un logiciel et un système qui ne reçoivent plus de mises à jour laissent ouvertes des failles connues ;
• les opportunités manquées : un portail client, une application terrain, une obligation légale que l'ancien outil ne sait pas suivre ;
• la dépendance à une seule personne qui connaît encore le logiciel.

Notre article sur la dette technique expliquée aux dirigeants aide à mettre ces coûts en regard d'un devis.

Comment lire un devis de refonte

Un devis de refonte se lit d'abord par ce qu'il contient, ensuite par son montant. Vérifiez qu'il répond à ces questions :

• L'analyse de l'existant est-elle prévue et chiffrée, ou supposée faite par vous ?
• Le découpage est-il par module, avec un prix et une date pour chacun ?
• La reprise des données est-elle un poste à part, avec des migrations de test ?
• Que devient l'ancien logiciel pendant la transition : qui le maintient, qui le raccorde, quand est-il éteint ?
• Qui valide les règles métier, et combien de temps cela demande à votre équipe ?
• La recette est-elle décrite, avec des comparaisons entre ancien et nouveau logiciel ?
• La maintenance après mise en production est-elle chiffrée ?
• Que récupérez-vous en fin de contrat : code, données, documentation, avec des droits définis au cas par cas dans le contrat ?

Un devis très inférieur aux autres oublie souvent la reprise des données ou la cohabitation, qui reviennent ensuite en avenants. Notre méthode pour comparer des devis de développement s'applique entièrement à une refonte.

Les erreurs qui font exploser le budget

• Chiffrer avant d'avoir trié : on paie la reconstruction de fonctions mortes.
• Ajouter toutes les améliorations en cours de route : chaque souhait accepté sans arbitrage allonge le projet.
• Sous-estimer le temps de l'équipe interne : un référent métier doit répondre aux questions et valider les résultats.
• Oublier l'extinction : deux logiciels maintenus en parallèle, c'est deux factures.
• Choisir le devis le plus bas sans comparer les périmètres : le moins cher sur le papier est souvent le plus incomplet.

Comment obtenir un chiffre fiable

1. Faites l'inventaire : les écrans réellement utilisés, par qui, à quelle fréquence, et les outils reliés.
2. Triez : ce qu'on retire, ce qu'on remplace par un produit, ce qu'on reconstruit.
3. Validez le premier module sur un prototype, avec ses utilisateurs.
4. Demandez un prix ferme par module, plutôt qu'un montant global.
5. Prévoyez la vie d'après : maintenance, hébergement, évolutions.

Pour la méthode d'estimation elle-même, voyez notre article estimer un projet logiciel.

Notre approche

Chez LPR Studio, le premier pas ne coûte rien : un prototype visuel gratuit du premier module, présenté en visio sous 5 jours ouvrés. C'est ce prototype qui permet ensuite un prix ferme, module par module, au forfait ou en abonnement, sans jamais facturer au temps passé. Le principe est expliqué dans voir son logiciel avant de le payer.