Coût de reprise d'une application PHP legacy en France
En France, il n'existe pas de barème officiel pour le coût de reprise et de maintenance d'une application PHP legacy, c'est-à-dire ancienne et difficile à faire évoluer. Le repère 2026 le plus détaillé que j'ai trouvé, publié par une agence, situe l'audit entre 3 000 et 6 000 euros HT, la migration vers PHP 8.3 entre 15 000 et 35 000 euros, et la maintenance entre 800 et 2 000 euros par mois. Ce sont des estimations du marché et non mes tarifs : le seul moyen d'obtenir un prix fiable est de faire lire le code.
Je fais moi-même ce type de reprise, donc je suis intéressé par le sujet. Je préfère vous montrer ce que ces chiffres valent, et ce qu'ils ne disent pas, plutôt que d'annoncer un montant rassurant.
Coût de reprise et maintenance PHP legacy : les tarifs 2026
Ces fourchettes viennent d'un article de l'agence Kolonell daté du 7 octobre 2026. L'agence vend ces prestations et les présente comme des ordres de grandeur, et je n'ai pas trouvé d'enquête indépendante pour les confirmer. Lisez-les donc comme une première base de discussion avec votre direction, pas comme un prix de référence.
| Scénario | Estimation HT | Durée indiquée | Quand y penser |
|---|---|---|---|
| Audit de reprise | 3 000 à 6 000 € | 4 à 8 jours | Dans presque tous les cas |
| Stabilisation et correctifs de sécurité | 4 000 à 8 000 € | 2 à 4 semaines | Application appelée à disparaître sous 12 mois |
| Migration vers PHP 8.3 | 15 000 à 35 000 € | 2 à 4 mois | Règles métier saines, code récupérable |
| Migration avec cadre applicatif (Symfony, Laravel) | 35 000 à 60 000 € | 4 à 6 mois | Code sans structure, évolutions encore prévues |
| Réécriture complète | 60 000 à 120 000 € | 6 à 12 mois | Code inexploitable ou besoin très différent |
| Maintenance applicative | 800 à 2 000 € par mois | Continue | Une fois l'application stabilisée |
La colonne de droite résume ma lecture de ces scénarios et ne vient pas de la source. Retenez surtout l'ordre de ces étapes : l'audit éclaire la décision, puis la stabilisation peut faire gagner quelques mois, puis vient le vrai chantier et enfin la maintenance. Additionner toutes les lignes n'aurait aucun sens, car certains scénarios s'excluent.
Pourquoi la version de PHP pèse sur la migration
La version installée donne une première idée du retard à rattraper et du risque déjà pris. D'après le tableau officiel de PHP, PHP 5.6 est en fin de vie depuis le 31 décembre 2018, PHP 7.4 depuis le 28 novembre 2022 et PHP 8.1 depuis le 31 décembre 2025. Le site officiel précise que ces branches peuvent contenir des failles qui ne seront pas corrigées. Le support de sécurité de PHP 8.2 s'arrête le 31 décembre 2026, dans deux mois, et celui de PHP 8.3 le 31 décembre 2027.
Une ancienne version ne rend pas à elle seule le chantier cher. Ce qui fait monter la facture, c'est l'accumulation : extensions supprimées, bibliothèques abandonnées, absence de tests, serveur que personne n'ose toucher. Une petite application en PHP 7.4 avec des tests peut coûter moins cher qu'une application récente que personne ne comprend.
Ce que l'audit doit vous rendre
Un audit utile n'est pas une liste de reproches sur le code. Il doit répondre à vos questions de dirigeant : que risque-t-on aujourd'hui, que faut-il faire d'abord, et combien coûterait chaque option ? La source citée plus haut y inclut l'inventaire technique, la cartographie des fonctions et des règles métier, l'analyse de sécurité, la qualité du code et la récupération des accès.
Ce dernier point est souvent le plus urgent et le moins technique. Si votre ancien prestataire détient seul le dépôt de code, l'hébergement ou le nom de domaine, réglez ce sujet avant de parler d'évolutions. Exigez aussi un livrable que vous pourrez transmettre à un autre prestataire : vous ne devez pas être obligé de confier le chantier à celui qui a réalisé l'audit.
Quand la reprise n'est pas le bon choix
Reprendre une application n'a pas toujours de sens. Si elle couvre un besoin standard, un logiciel du marché peut coûter moins cher sur la durée, même avec ses licences. Si elle doit disparaître dans l'année, une simple stabilisation suffit peut-être. Et si le chantier demande plusieurs développeurs en parallèle avec des astreintes, une agence ou une équipe interne conviendra mieux qu'un indépendant comme moi.
À l'inverse, évitez de réécrire uniquement parce qu'un prestataire trouve le code laid. Une réécriture doit retrouver toutes les règles métier, y compris celles que personne n'a documentées, et reprendre les données existantes. C'est une source de risque que l'on sous-estime souvent, et elle se discute à partir de faits constatés dans l'audit.
Les questions à poser avant de signer
Demandez à chaque prestataire ce qu'il a repris de comparable et ce qu'il peut montrer. Demandez comment il sécurise la mise en production, quels tests il ajoute en priorité, comment il revient en arrière en cas de problème, et à qui appartiendront le code, le dépôt et les comptes. Pour la maintenance, faites préciser le nombre d'heures incluses, le délai de réponse et la prise en charge des mises à jour de sécurité. Enfin, posez une question simple : qu'est-ce qui ferait augmenter ce devis ?
Comme exemple de reprise, je peux citer Coucouroucoucou, une boutique belge sous Sylius dont environ 15 000 commandes ont été reprises avec les clients et les factures, sans coupure de vente. Ce n'est pas le même projet que le vôtre, et je vous encourage à demander à tout prestataire, moi compris, une preuve qui correspond à votre cas. Si vous voulez comparer les tarifs journaliers, lisez aussi mon article sur le TJM d'un développeur PHP freelance.
Je ne publie aucun prix : chaque application a son histoire. Pour un chiffrage, présentez votre situation sur la page contact ou consultez mon offre de développement et reprise d'application web. Je réponds sous 24 heures ouvrées, et vous parlerez directement à la personne qui lira votre code.