Combien coûte la refonte d’un logiciel métier ?

Une PME peut figurer parmi vos candidats : les PME représentent 51.3 % des titulaires du corpus de refonte, selon les données essentielles de la commande publique du 13 janvier 2021 au 28 juillet 2026, consultées le premier octobre 2026.

Cette présence justifie de consulter des structures de tailles différentes. Elle ne démontre ni un prix inférieur ni une meilleure aptitude à reprendre votre application. Pour apprécier une proposition, demandez surtout qui examinera le code, qui arbitrera les choix techniques et qui accompagnera vos utilisateurs pendant la bascule. Une équipe adaptée doit couvrir ces responsabilités et expliquer comment elle les assume lorsque les travaux avancent simultanément.

Le budget dépend aussi de ce que vous fournissez au candidat. Des accès disponibles, une documentation exploitable et des interlocuteurs métier mobilisés permettent de préciser les travaux. À l’inverse, un prestataire qui découvre les règles de gestion après signature devra faire traiter ces découvertes dans le cadre contractuel convenu. Comparez donc les hypothèses des offres avant leurs montants.

Exemple hypothétique : votre application reste utilisable, mais son interface gêne le traitement des dossiers. Une proposition conserve les traitements existants ; une autre remplace également le stockage et les échanges avec les outils voisins. La taille des entreprises consultées n’explique pas cet écart de périmètre. Faites préciser ce que chaque proposition conserve, transforme et vérifie.

Pour préparer votre sélection parmi les prestataires de reprise de logiciel, demandez une présentation de l’équipe affectée et de son organisation. Exigez également une explication des dépendances envers vos propres collaborateurs : leur disponibilité fait partie des conditions concrètes de réussite et doit apparaître dans le calendrier proposé.

La baisse des annonces ne démontre pas une baisse des prix : les annonces publiques de codeur.com relevées le 14 octobre 2026 recensent 75 annonces de logiciel ancien ou fichier à remplacer sur les six derniers mois, contre 144 sur les six précédents.

Ce relevé décrit une demande publiée sur une plateforme. Il ne renseigne pas les montants finalement signés, la disponibilité des prestataires ni la complexité des applications concernées. Vous pouvez vous en servir pour comprendre le contexte des petites reprises, mais pas pour imposer une remise à une équipe qui doit sécuriser une migration complète.

La catégorie rassemble des besoins de remplacement dont l’étendue doit être examinée. Remplacer un fichier utilisé pour une tâche précise ne mobilise pas nécessairement le même travail que transformer une application partagée avec des droits d’accès, des historiques et des interfaces. L’intitulé « refonte » recouvre ces différences sans les résoudre.

Exemple hypothétique : vous souhaitez remplacer un fichier de suivi devenu difficile à maintenir. Si les utilisateurs attendent simplement de retrouver les opérations actuelles, le cadrage peut rester ciblé. S’ils demandent également des validations, une gestion des accès et des échanges automatisés, votre besoin change. Présentez ces attentes séparément pour que le devis montre leur incidence.

• Décrivez le problème qui déclenche le remplacement.
• Distinguez les usages indispensables des améliorations souhaitées.
• Demandez comment seront récupérés et contrôlés les historiques.

La négociation devient utile lorsque vous pouvez retirer, différer ou simplifier un livrable identifié. Une baisse générale de la demande ne dit pas quel travail supprimer dans votre projet. Le cahier des charges doit rendre ces arbitrages possibles avant de demander un engagement ferme sur le prix.

Le recul des demandes ne fixe pas le prix de votre reprise : les annonces publiques de codeur.com relevées le 14 octobre 2026 comptent 597 annonces de reprise de code, application existante ou maintenance sur les six derniers mois, contre 1038 sur les six précédents.

Ce second ensemble porte sur des interventions plus larges que le seul remplacement d’un logiciel ancien. Une correction, la reprise d’un développement interrompu et la maintenance d’une application existante peuvent y apparaître. Leur présence dans une même catégorie ne permet pas de les considérer comme des refontes comparables.

Pour votre budget, la distinction utile porte sur le résultat attendu. Une petite reprise cherche à rétablir un fonctionnement ou à modifier une zone délimitée. Une modernisation transforme une partie du socle ou de l’usage en conservant des éléments existants. Une réécriture reconstruit les fonctions retenues et exige de démontrer que les règles métier nécessaires ont été préservées.

Exemple hypothétique : un export ne fonctionne plus dans votre application. Le réparer peut suffire si le reste répond aux besoins et reste maintenable. Si cet export révèle des données incohérentes et des traitements devenus incompréhensibles, demandez un diagnostic avant de décider du chantier. Le problème visible ne décrit pas toujours le travail nécessaire.

Faites chiffrer séparément la stabilisation urgente et la transformation envisagée. Vous pourrez ainsi décider si la correction conserve son utilité pendant la modernisation ou si elle serait rapidement abandonnée. Cette séparation aide également à vérifier que le devis ne vous fait pas payer une reconstruction complète pour résoudre un défaut localisé.

Le comparatif réécrire ou moderniser un logiciel peut structurer cette décision. Demandez au candidat de justifier sa trajectoire par les éléments observés dans votre application, avec les limites du diagnostic et les vérifications encore nécessaires.

Votre budget doit couvrir les engagements qui suivent la livraison : la durée médiane atteint 36 mois dans le corpus de refonte des données essentielles de la commande publique du 13 janvier 2021 au 28 juillet 2026, consultées le premier octobre 2026.

Cette durée décrit les contrats observés. Elle ne donne ni le temps de développement de votre logiciel ni une période de maintenance automatiquement incluse. Avant de comparer des prix, faites préciser les prestations couvertes pendant l’exécution : conception, réalisation, migration, accompagnement, corrections ou évolutions. Un montant global perd son sens si ces engagements restent implicites.

La mise en service ouvre aussi des besoins d’exploitation. L’application doit être hébergée, surveillée, sauvegardée et maintenue dans un état compatible avec ses dépendances. Votre organisation doit savoir qui reçoit les signalements, qui qualifie une anomalie et qui autorise une intervention. Faites apparaître ces responsabilités dans le contrat, même lorsque vous conservez certaines tâches en interne.

Exemple hypothétique : votre équipe accepte les fonctions livrées, puis demande une nouvelle règle de validation après utilisation réelle. Le contrat doit permettre de distinguer cette évolution d’une erreur de réalisation. Sans définition partagée, chaque demande devient une discussion sur ce qui était compris dans le prix.

• Identifiez les prestations récurrentes et leurs conditions de révision.
• Définissez le traitement des corrections après réception.
• Précisez les modalités de transfert vers un autre intervenant.

Votre budget de refonte et votre budget de TMA doivent pouvoir se lire ensemble. Demandez une présentation qui distingue les travaux de transformation des engagements de fonctionnement. Vous pourrez alors comparer les offres sur une durée contractuelle identique, sans convertir la médiane observée en tarif annuel.

Les montants publics correspondent à des périmètres de transformation variés : la médiane atteint 122 400 € dans le corpus des données essentielles de la commande publique du 13 janvier 2021 au 28 juillet 2026, consultées le premier octobre 2026.

Ce repère aide à situer une opération structurée, mais il ne remplace pas l’examen des prestations. Le corpus comprend notamment une mission d’assistance à maîtrise d’ouvrage et une modernisation de plateforme. Ces objets ne décrivent pas les mêmes livrables, même s’ils participent à la transformation d’un système existant.

Ces exemples expliquent pourquoi un intitulé proche du vôtre ne suffit pas à valider votre enveloppe. Une mission peut financer la préparation des décisions, une autre leur mise en œuvre. Dans votre consultation, indiquez si vous attendez un diagnostic, une définition de cible, une réalisation ou un accompagnement jusqu’à la bascule.

Demandez ensuite les exclusions : reprise documentaire, nettoyage des données, raccordement aux outils voisins et formation doivent être explicitement traités. Le montant devient comparable lorsque vous savez quelles obligations il achète et quels travaux restent à votre charge.

Les budgets d’annonce indiquent des intentions de dépense : dans les annonces publiques de codeur.com relevées le 14 octobre 2026, 159 annonces de logiciel ancien ou fichier à remplacer affichent « Moins de 500 € ».

Ce montant annoncé ne prouve pas qu’une migration complète a été réalisée dans cette enveloppe. Il peut correspondre à un besoin limité, à une demande encore imprécise ou à un budget que le porteur de projet devra revoir après consultation. Le relevé ne permet pas de choisir entre ces interprétations pour chaque annonce.

Vous devez donc rapprocher votre demande des travaux décrits, pas seulement de la catégorie budgétaire. Une application métier contient souvent des règles qui ne figurent dans aucun document. Leur identification demande des échanges avec les utilisateurs et une lecture du fonctionnement existant. Si vous les omettez dans votre demande, les propositions pourront sembler accessibles tout en laissant la reprise fonctionnelle ouverte.

Exemple hypothétique : vous demandez de « refaire le logiciel à l’identique ». Cette formule laisse pourtant plusieurs questions sans réponse. Faut-il conserver un calcul historique devenu contestable ? Reprendre les dossiers clôturés ? Reproduire un export rarement utilisé ? Chaque réponse modifie les livrables et les contrôles attendus.

Préparez une enveloppe de décision avec un périmètre indispensable clairement décrit. Demandez les améliorations facultatives séparément, sans les retirer silencieusement de la proposition principale. Vous pourrez alors différer certaines fonctions en sachant ce que vous perdez ou reportez.

La lecture des prix du logiciel sur mesure complète cette démarche lorsque votre refonte revient à reconstruire une grande partie de l’application. Votre critère reste le contenu acheté : le budget affiché par un autre demandeur ne constitue pas un engagement de réalisation pour votre propre système.

Vous devez clarifier les travaux dont le contenu reste incertain avant d’accepter un forfait : 22.7 % des marchés du corpus sont des accords-cadres, selon les données essentielles de la commande publique du 13 janvier 2021 au 28 juillet 2026, consultées le premier octobre 2026.

Cette part rappelle que les montants observés ne relèvent pas tous d’une commande de réalisation entièrement figée. Elle ne permet pas de déduire une formule de facturation universelle. Pour votre projet, choisissez le mode d’engagement à partir de ce qui peut être décrit, vérifié et accepté avant les travaux.

Un forfait demande un périmètre suffisamment explicite. Précisez les fonctions, les données reprises, les interfaces concernées et les conditions de réception. Faites également décrire les hypothèses : accès au code, disponibilité des environnements, qualité des données et participation de vos équipes. Une hypothèse déterminante doit entraîner une décision prévue si elle se révèle fausse.

Le temps passé convient à une investigation dont les découvertes orientent la suite, à condition d’organiser le pilotage. Demandez les travaux prévus, les résultats attendus du diagnostic et les éléments qui vous permettront de décider de poursuivre. Une intervention ouverte sans livrables intermédiaires ne vous donne pas de maîtrise sur le budget.

Exemple hypothétique : le candidat doit examiner un module dont personne ne connaît les dépendances. Vous pouvez commander cette investigation avec un résultat attendu : une cartographie exploitable, les risques identifiés et une proposition de travaux. Le développement pourra ensuite faire l’objet d’un engagement adapté au périmètre éclairci.

Dans un appel d’offres de refonte, demandez que les candidats expliquent leur traitement des découvertes. Vous comparerez ainsi leur manière de décider et de chiffrer les écarts, au lieu de découvrir cette méthode pendant l’exécution.

Vous faites entrer la migration et la recette dans le prix convenu en les décrivant comme des livrables : la moitié centrale des montants va de 53 000 à 257 500 € dans les données essentielles de la commande publique du 13 janvier 2021 au 28 juillet 2026, consultées le premier octobre 2026.

Cette dispersion ne mesure pas le coût particulier de la recette. Elle renforce l’intérêt de vérifier ce que chaque offre inclut. Des écrans développés ne prouvent pas que vos données ont été correctement reprises ni que vos opérations métier aboutissent au résultat attendu. Le devis doit décrire les contrôles et les responsabilités associés à ces résultats.

1. Retenez des situations de travail représentatives avec les utilisateurs concernés.
2. Définissez le résultat attendu et les données nécessaires pour chaque situation.
3. Faites tester la reprise sur un environnement prévu à cet effet.
4. Consignez les écarts, leur traitement et les conditions d’acceptation.
5. Validez la préparation de la bascule et du retour arrière.

Exemple hypothétique : votre logiciel suit des dossiers avec un historique de décisions. Une recette limitée à l’ouverture des écrans laisserait de côté la chronologie, les droits de consultation et les liens entre les pièces. Demandez de vérifier un parcours complet à partir de données choisies et protégées pour cet usage.

Précisez qui prépare ces données, qui constate les anomalies et qui décide de leur caractère bloquant. Faites aussi définir le traitement d’une anomalie déjà présente dans l’ancien logiciel : sa reproduction et sa correction ne constituent pas nécessairement le même engagement.

Enfin, demandez les éléments remis après les essais : résultats, réserves, procédures de migration et consignes d’exploitation. Ces livrables vous permettent de réceptionner la transformation avec une preuve de fonctionnement et de préparer la maintenance sur une base documentée.

Les lignes qui décrivent les livrables, les exclusions et les conditions de réception permettent de décider : la médiane des offres reçues est de 3 dans les données essentielles de la commande publique du 13 janvier 2021 au 28 juillet 2026, consultées le premier octobre 2026.

Disposer de propositions concurrentes ne suffit pas si elles répondent à des demandes différentes. Organisez votre lecture autour des travaux indispensables : diagnostic de l’existant, conception de la cible, développement, reprise des données, interfaces, recette et bascule. Pour chaque poste, vérifiez ce qui sera remis et comment vous pourrez constater que le travail est terminé.

Examinez ensuite les conditions financières. Le devis doit expliquer les déclencheurs de facturation, le traitement des demandes nouvelles et les conséquences d’un retard dans la fourniture de vos accès ou de vos décisions. Demandez également ce qui reste dû si vous arrêtez le chantier après une étape contractuellement prévue.

Exemple hypothétique : une offre paraît moins chère parce qu’elle vous laisse préparer les données et organiser les essais. Une autre confie ces tâches au prestataire. Pour arbitrer, vérifiez si votre équipe possède la disponibilité et les moyens nécessaires. Une tâche déplacée vers votre organisation reste une charge à assumer, même lorsqu’elle disparaît du devis.

Contrôlez enfin la remise du code, de la documentation et des accès nécessaires à l’exploitation. Les droits d’utilisation, les composants soumis à licence et les conditions de transfert doivent être compréhensibles avant la commande. Ces éléments déterminent votre capacité à faire vivre le logiciel après sa transformation.

Votre décision peut alors relier le prix à un résultat exploitable : ce que vous recevez, les vérifications prévues, votre contribution et les obligations qui continuent après réception. Demandez une clarification écrite sur chaque écart matériel avant de retenir une proposition.