Migration PHP Legacy — Moderniser votre Application PHP 5/7 sans Arrêter la Production

#L'état du PHP legacy en 2026 — Risques techniques et de recrutement

L'argument « ça tourne, on ne touche pas » tient de moins en moins face aux réalités de 2026. Les applications PHP legacy accumulées depuis les années 2000 et 2010 présentent un profil de risques techniques, sécuritaires et organisationnels qui finit toujours par déboucher sur une crise — qu'il vaut mieux anticiper qu'encaisser en urgence.

#Le profil type d'une application PHP legacy en 2026

Une application PHP legacy classique, c'est généralement un MVC artisanal sans framework (chaque développeur a implémenté sa propre version du pattern), des fonctions globales en cascade (spaghetti de 3 000 lignes dans un fichier functions.php), des requêtes SQL écrites à la main sans ORM ni prepared statements (vecteur SQL injection encore très courant dans ces codebases), aucune couverture de tests unitaires, aucun typage strict (pas de type hints, pas de déclaration declare(strict_types=1)), aucune conformité PSR (PSR-4 autoloading, PSR-7 HTTP messages, PSR-12 coding standard), un déploiement via FTP ou SFTP sans pipeline CI/CD, et des dépendances gérées soit manuellement par copier-coller de librairies dans un dossier lib/, soit via un composer.json dont la dernière mise à jour date de 2019. Le schéma de base de données reflète souvent les mêmes années de dette : tables sans clés étrangères, index manquants sur les colonnes de jointure, procédures stockées en français avec commentaires en verlan, colonnes varchar(255) pour tout type de donnée.

#Les risques de sécurité qui s'accumulent sans patch

PHP 5.6 a atteint sa fin de support officiel en décembre 2018. PHP 7.4 en décembre 2022. PHP 8.0 en novembre 2023. Depuis ces dates, les CVE (Common Vulnerabilities and Exposures) s'accumulent sans patch officiel de l'équipe PHP core. En 2025-2026, plusieurs CVE critiques (CVSS score ≥ 9.0) concernant des versions de PHP en fin de vie ont été publiées sans correctif disponible pour ces versions. Les codebases PHP legacy présentent par ailleurs des vulnérabilités applicatives classiques : injections SQL sur les requêtes construites par concaténation de chaînes, XSS (Cross-Site Scripting) sur les sorties non échappées avec htmlspecialchars(), inclusion de fichiers dynamiques via include($_GET['page']) (Remote File Inclusion), désérialisation non sécurisée d'objets PHP. PHPStan en mode strict et Psalm détectent systématiquement plusieurs dizaines à centaines de ces patterns sur un codebase legacy de taille moyenne.

Les dépendances Composer (quand elles existent) posent un problème symétrique : un composer.json d'une application PHP 7 typique embarque des librairies dont certaines n'ont pas reçu de mise à jour de sécurité depuis 3 à 5 ans. La commande composer audit sur ces projets retourne souvent 15 à 40 advisory de sécurité actives. Voir glossaire dette technique pour une définition complète des concepts.

#Le problème de recrutement PHP legacy en 2026

Trouver un développeur PHP 5 opérationnel en France en 2026 relève du parcours du combattant. La génération qui a écrit ces applications est aujourd'hui reconvertie vers des stacks modernes (Symfony 6/7, Laravel 10, Node.js, Next.js) ou en position managériale. Les jeunes développeurs sortis des formations depuis 2020 n'ont jamais écrit une ligne de PHP sans Composer ni namespace PSR-4. Le marché s'est ajusté en conséquence : les rares profils capables de maintenir du PHP 5 legacy pratiquent des tarifs journaliers 40 à 60 % supérieurs à la moyenne du marché PHP moderne, avec des disponibilités très limitées. Une ETI qui perd son développeur PHP legacy historique se retrouve souvent face à une crise opérationnelle immédiate — le code tourne mais personne ne sait plus le modifier. C'est l'un des arguments opérationnels les plus forts pour planifier la migration maintenant, avant la crise, plutôt qu'en urgence après.

#3 voies de modernisation PHP — Quelle approche pour votre projet

Il n'existe pas de réponse universelle à la question « que faire de notre PHP legacy ». Le choix entre les trois voies dépend de l'état réel du codebase (mesuré par l'audit dette technique), des compétences disponibles en interne, des contraintes de production et du budget alloué. Nehos qualifie ces trois dimensions lors de l'audit initial avant toute recommandation.

#1. Migration en place PHP 8.3 + Symfony 7 — La voie du refactoring progressif

C'est la voie la plus rapide et la moins risquée pour les codebases dont la logique métier est cohérente et structurée, même si le code est "sale". Le principe : on améliore le codebase existant par couches successives sans le réécrire. Étape 1 — montée de version PHP : PHP 5.6 → 7.4 (compatible mode), puis 7.4 → 8.0, puis 8.0 → 8.3. Chaque version intermédiaire requiert de corriger les dépréciations signalées par php -l et PHPStan niveau 0. Durée typique : 3 à 6 semaines par saut de version majeure selon la taille du codebase. Étape 2 — introduction Composer et PSR-4 : si le projet n'utilise pas Composer, on introduit l'autoloading PSR-4, on migrate les inclusions manuelles vers des namespaces, on retire les require/include à la main. Étape 3 — introduction des composants Symfony : Symfony Routing remplace le routeur artisanal, Symfony DI Container remplace le registre global ou le singleton, Doctrine ORM remplace les requêtes SQL à la main, Symfony Console pour les scripts de batch. On n'installe pas Symfony full-stack d'un coup — on installe chaque composant là où il apporte le plus de valeur immédiate. Étape 4 — typage strict et PHPStan niveau 8 : ajout progressif de type hints sur les fonctions et méthodes, declare(strict_types=1) fichier par fichier, montée du niveau PHPStan de 0 à 8 sur 3 à 6 mois. Étape 5 — Docker et CI/CD : conteneurisation de l'application (PHP-FPM + Nginx + Postgres/MySQL), pipeline GitHub Actions ou GitLab CI avec lint + tests + build + déploiement automatisé. Timeline globale pour un codebase 50-200 KLOC : 3 à 8 mois. Budget indicatif : 212 k€ HT selon taille et niveau de dette initiale. Voir glossaire refactoring code.

#2. Strangler Fig + API-first — Migration vers Next.js + Symfony API Platform

Le pattern Strangler Fig (Martin Fowler, 2004) est la voie privilégiée pour les équipes qui souhaitent moderniser l'expérience front-end (React, performance, composants modernes) sans réécrire la logique métier PHP en une fois. Principe : on encapsule progressivement le monolithe PHP legacy derrière une API REST ou GraphQL, on reconstruit le front-end en Next.js App Router qui consomme cette API, et on migre les features une par une de l'ancien rendu PHP (templates Smarty, Twig ou PHP pur) vers le nouveau front Next.js. L'ancienne application continue de tourner en parallèle pendant toute la migration — un reverse proxy (Nginx ou Traefik) route le trafic vers l'ancienne ou la nouvelle version selon la feature activée via feature flag. Étape 1 — identifier les domaines bornés (bounded domains) : authentification, facturation, reporting, API publique, espace client. Chaque domaine est une unité de migration indépendante. Étape 2 — wrapping API : pour chaque domaine, on crée des controllers Symfony API Platform ou des routes Symfony pures qui exposent la logique métier existante en REST/JSON — sans la réécrire, juste l'encapsuler. Étape 3 — reconstruction du front en Next.js App Router : React Server Components pour les pages SEO-critiques (SSR/SSG), Client Components pour les parties interactives, Tailwind CSS + shadcn/ui pour l'UI, SWR ou React Query pour le data fetching. Étape 4 — décommissionnement progressif : une fois un domaine 100 % migrée côté Next.js et API, le code PHP correspondant est retiré du monolithe. On continue jusqu'à l'extinction complète du front legacy. Timeline : 6 à 18 mois selon la taille du codebase et le nombre de domaines. Budget indicatif : à partir de 19 k€ HT. Cf service migration Symfony → Next.js.

#3. Réécriture complète — Quand et comment (et quand surtout pas)

La réécriture complète est recommandée dans un seul cas de figure : le codebase est irrémédiablement dégradé — plus de 70 % de code mort non appelé, zéro couverture de tests (impossible de caractériser le comportement actuel), PHP 4 sans aucun framework ni structure, et la logique métier est parfaitement documentée et stable (pas de régression fonctionnelle possible pendant la réécriture). Même dans ce cas, la réécriture complète reste la voie la plus risquée. Le syndrome du second système (Fred Brooks, "The Mythical Man-Month") frappe systématiquement : la nouvelle version prend invariablement 3 fois plus de temps qu'estimé, parce qu'on découvre en cours de route des comportements implicites du legacy qu'aucune spécification ne documentait. Nehos recommande la réécriture complète à moins de 20 % de ses projets PHP legacy. Quand elle est justifiée, la stack cible est Next.js App Router (front) + Symfony 7 API Platform (back) + Postgres 16, déployée sur OVHcloud avec pipeline GitLab CI complet. Tests : PHPUnit dès la première ligne de code, objectif 80 % coverage avant mise en production, Playwright pour les tests E2E.

#Pattern Strangler Fig — Migration sans downtime

Le Strangler Fig Application est un pattern d'architecture décrit par Martin Fowler en 2004, dont le nom est emprunté au figuier étrangleur tropical : un arbre qui pousse autour d'un autre arbre, l'enveloppant progressivement, jusqu'à le remplacer entièrement quand l'arbre hôte meurt et se décompose. L'analogie avec la migration logicielle est saisissante — et c'est exactement pour cela que ce pattern est devenu la référence du secteur pour les migrations d'applications legacy en production.

Pourquoi ce pattern est supérieur au big bang pour les applications PHP legacy en production. La migration big bang (tout réécrire, tout basculer en une nuit) est techniquement attrayante sur le papier. En pratique, elle concentre tous les risques sur une fenêtre de bascule unique : si la nouvelle version présente un comportement inattendu sur un cas limite non couvert par les tests, on revient en arrière au milieu de la nuit et toute la migration est à recommencer. Sur des applications PHP legacy avec 0 % de couverture de tests, la probabilité de comportements inattendus à la bascule est quasi-certaine. Le Strangler Fig dilue ce risque dans le temps : chaque migration de domaine est une bascule partielle, testée en production avec un sous-ensemble de trafic, réversible indépendamment des autres domaines.

Comment Nehos applique le Strangler Fig à un projet PHP legacy concret. (1) Cartographie des domaines lors de l'audit : on identifie les périmètres fonctionnels autonomes du monolithe (authentification et sessions, catalogue produit, panier et commandes, reporting et BI, API publique partenaires, espace administration). Chaque domaine est évalué selon trois critères : complexité d'extraction (couplage avec le reste du monolithe), valeur business (ROI de la migration de ce domaine en particulier), et risque (dépendances critiques, volume de transactions). (2) On définit un ordre de migration par domaine : on commence toujours par le domaine le moins couplé et le plus autonome — typiquement le reporting ou l'espace administration — pour acquérir de la confiance et des pratiques sur un périmètre à faible risque avant de migrer les domaines critiques (panier, paiement, authentification). (3) Pour chaque domaine, on implémente la nouvelle version derrière un feature flag (variable d'environnement ou flag Unleash/LaunchDarkly). Le reverse proxy route 5 % du trafic vers la nouvelle version, on surveille les métriques (taux d'erreur, latence p95, comportements fonctionnels), on monte progressivement à 25 %, 50 %, 100 %. (4) Une fois la nouvelle version du domaine à 100 % du trafic et stable depuis 2 à 4 semaines, le code PHP correspondant est retiré du monolithe et la dette technique associée est définitivement éteinte. On passe au domaine suivant.

#Audit dette technique PHP — Ce que Nehos évalue en 5-10 jours

L'audit dette technique est la condition préalable à toute recommandation de voie de migration. Sans audit, toute estimation de coût ou de durée est une projection dans le vide. Nehos structure cet audit autour de 8 axes d'évaluation.

Métriques qualité du code. Complexité cyclomatique (McCabe) mesurée par PHPMD (PHP Mess Detector) : une complexité cyclomatique moyenne supérieure à 20 par méthode signale un codebase difficile à tester et à modifier sans régression. NCLOC (Non-Comment Lines of Code) total et par module — indicateur de taille brute. Taux de code dupliqué via PHP_CodeSniffer et PHPCPD (Copy-Paste Detector) : un taux de duplication supérieur à 15 % signale un problème structurel de réutilisation.

Couverture de tests. Le point le plus critique pour évaluer le risque de la migration. Un codebase à 0 % de couverture PHPUnit est migrable, mais nécessite d'établir une couverture de "characterization tests" (tests de caractérisation au sens de Michael Feathers dans "Working Effectively with Legacy Code") avant tout refactoring. Ces tests ne vérifient pas que le code est correct — ils documentent ce que le code fait réellement, pour détecter les régressions involontaires pendant le refactoring.

Conformité PSR et standards. PSR-4 autoloading (namespaces ou includes manuels ?), PSR-12 coding standard (indentation, nommage, structure des fichiers), conformité aux standards Symfony sur les parties qui utilisent Symfony, utilisation correcte de Composer (lockfile présent et committé, pas de dépendances installées hors Composer).

Sécurité — scan PHPStan security + Psalm. PHPStan avec l'extension security (phpstan-security-checker) et Psalm détectent les patterns dangereux : concaténation SQL sans prepared statements, sorties non échappées, inclusions de fichiers dynamiques, désérialisation non sécurisée. composer audit liste les advisory de sécurité actives sur les dépendances. Le résultat est classé par criticité (CVSS score) et urgence de correction.

Qualité du schéma de base de données. Index manquants sur les colonnes de jointure et de filtrage (EXPLAIN ANALYZE sur les 20 requêtes les plus fréquentes), absence de clés étrangères (intégrité référentielle gérée uniquement applicativement — source de données orphelines), procédures stockées complexes difficiles à migrer, types de colonnes inadaptés (dates stockées en varchar, montants en float).

Maturité du pipeline de déploiement. Déploiement via FTP ou SFTP (score 0/10), script de déploiement manuel SSH (2/10), capistrano/deployer sans tests automatisés (4/10), pipeline CI/CD avec tests mais sans conteneurisation (6/10), pipeline complet GitLab CI / GitHub Actions avec tests + Docker + déploiement automatisé (10/10). La maturité du pipeline conditionne directement la capacité à livrer en continu pendant la migration.

Audit des dépendances Composer. Âge moyen des dépendances (une dépendance non mise à jour depuis plus de 3 ans est un signal), nombre d'advisory de sécurité actives (composer audit), compatibilité avec PHP 8.3 (certaines librairies legacy ne sont pas compatibles et nécessitent remplacement).

L'output de l'audit est un document de 20 à 40 pages avec : score de dette technique global (1 à 10), cartographie des domaines fonctionnels, recommandation de voie de migration étayée, plan de migration détaillé par phases avec estimation de charge et de budget, et liste priorisée des quick wins sécurité à traiter en priorité absolue indépendamment du plan de migration. Voir service Audit Dette Technique Nehos.

#Stack cible — PHP 8.3 + Symfony 7 ou Next.js + API Platform

Le choix de la stack cible n'est pas une question de mode technologique — c'est une décision structurée par le contexte du client.

Quand choisir PHP 8.3 + Symfony 7. Cette voie est recommandée quand l'équipe interne est PHP-native et souhaite upgrader progressivement sans reconversion technologique majeure, quand la logique métier en PHP est sophistiquée et bien structurée (même si le code est "sale" en surface), quand des développeurs PHP Symfony sont disponibles en interne ou sur le marché, et quand le time-to-market d'une migration incrémentale est préféré à une refonte complète. Symfony 7 (PHP 8.2+ requis) apporte : composants matures et stables (Routing, DI, ORM Doctrine 3, Console, Messenger pour les queues, Scheduler pour les tâches récurrentes), écosystème de bundles large (API Platform 3, EasyAdmin 4, KnpPaginator, etc.), compatibilité native avec Docker, performance PHPStan niveau 9, types stricts complets. La migration PHP vers Symfony suit un chemin balisé avec des outils spécialisés : Rector PHP pour les migrations automatisées de syntaxe (PHP 7.x → 8.x, Symfony 3 → 7), PHP-CS-Fixer pour la normalisation du code style.

Quand choisir Next.js 15 + Symfony API Platform. Cette voie est recommandée quand le front-end doit être reconstruit de toute façon (UX obsolète, performance mobile insuffisante, nécessité de composants React modernes), quand l'équipe souhaite ajouter des fonctionnalités IA (agents LangChain, RAG, génération de contenu) qui s'intègrent nativement dans l'écosystème JavaScript/TypeScript, quand la performance front-end est critique (ISR/SSG Next.js pour les pages catalogue ou SEO), et quand le front-end et le back-end peuvent évoluer indépendamment (équipes séparées, cadences de déploiement différentes). Symfony API Platform 3 reste la couche API recommandée pour les équipes PHP : API REST + GraphQL auto-générés depuis les entités Doctrine, filtrages et pagination natifs, support OpenAPI 3.1, authentification JWT via LexikJWTAuthenticationBundle. Voir glossaire TypeScript et glossaire Next.js.

#Cas particulier — Applications PHP gérant des données sensibles (RGPD, HDS)

Les applications PHP legacy hébergeant des données sensibles requièrent une attention spécifique pendant la migration — et constituent souvent une opportunité de remédier aux problèmes de conformité accumulés dans le legacy.

Données de santé (HDS). Si l'application PHP legacy traite des données de santé au sens de l'article 9 du RGPD (dossiers patients, résultats d'analyses, prescriptions, données de bien-être salarié), l'hébergement sur une infrastructure certifiée HDS est obligatoire (décret n° 2018-137). La migration est l'opportunité de basculer vers OVHcloud HDS (certifié ISO 27001 + HDS) avec Postgres 16 chiffré (pgcrypto) et audit trail immutable (pgaudit). Les applications PHP legacy hébergées chez un hébergeur mutualisé non HDS (OVH Mutualisé, Infomaniak partagé, etc.) sont en infraction caractérisée — la migration régularise cette situation.

Données financières (PCI-DSS). Si l'application PHP legacy gère des paiements par carte bancaire, le scope PCI-DSS s'applique. Les codebases PHP legacy qui stockaient les numéros de carte en clair (une pratique hélas encore découverte lors des audits) ou qui utilisaient des librairies de paiement non maintenues (PHP 5 + ancienne version d'Ogone/Mollie/PayPlug SDK) sont en zone de risque maximale. La migration est l'occasion de sortir définitivement du scope PCI-DSS par tokenisation (déléguer le stockage des données carte à Stripe, Adyen ou Mollie — l'application ne voit jamais les données carte en clair).

Données RH et salariés (RGPD article 6 + 9). Les ERP ou SIRH internes PHP legacy accumulent souvent des données RH mal cloisonnées, sans politique de rétention implémentée, sans logs d'accès. La migration est l'opportunité d'implémenter la minimisation des données (supprimer les champs non nécessaires), les politiques de rétention automatisées (Postgres scheduled jobs de purge), et les logs d'accès (pgaudit) exigés en cas d'audit CNIL.

#Couverture de tests — De 0 % à 80 % sans ralentir la production

L'absence de couverture de tests est la caractéristique la plus commune des codebases PHP legacy — et la première chose à adresser avant tout refactoring sérieux. Nehos applique une stratégie en trois temps inspirée de Michael Feathers ("Working Effectively with Legacy Code", 2004) et de la pyramide de tests.

Étape 1 — Tests de caractérisation (smoke tests). Avant de toucher une ligne de code legacy, on installe PHPUnit et on écrit des tests qui documentent le comportement actuel du système — pas ce que le code devrait faire, mais ce qu'il fait réellement. Ces tests sont des filets de sécurité : ils détectent les régressions involontaires introduites par le refactoring. Une règle empirique : 20 % du code cause 80 % des bugs en production. On identifie ce 20 % via les logs d'erreur existants et les retours utilisateurs, et on écrit les tests de caractérisation en priorité sur ces chemins critiques.

Étape 2 — Tests unitaires et d'intégration sur le code refactoré. À mesure que le refactoring progresse (extraction de classes, injection de dépendances, migration vers Symfony DI), on ajoute des tests unitaires PHPUnit sur les classes extraites. Les tests d'intégration Symfony utilisent le KernelBrowser (pour les requêtes HTTP complètes) et les Symfony WebTestCase. Objectif : 60-80 % de couverture sur le nouveau code produit pendant la migration, 20-40 % sur le code legacy conservé (coverage progressif).

Étape 3 — Tests E2E Playwright et BDD Behat. Les tests end-to-end Playwright couvrent les parcours utilisateurs critiques (authentification, paiement, génération de documents) et constituent le dernier filet de sécurité avant bascule de trafic dans le cadre du pattern Strangler Fig. Behat (BDD) est utilisé quand les équipes métier participent à la définition des critères d'acceptation — les scénarios Gherkin sont lisibles par les non-développeurs et documentent les règles métier de façon pérenne.

Mutation testing avec Infection PHP. Une fois la couverture à 60 %+, Infection PHP (mutation testing framework) vérifie la qualité réelle des tests : il introduit des mutations dans le code source (inverte des conditions, supprime des retours, modifie des opérateurs) et vérifie que les tests existants les détectent. Un score de mutation supérieur à 80 % signifie que les tests testent réellement le comportement du code, pas juste qu'ils s'exécutent sans erreur.

#Méthodologie de déploiement — Audit, plan, migration progressive

La migration PHP legacy suit chez Nehos une méthodologie en quatre phases reproductibles, indépendamment de la voie choisie (migration en place, Strangler Fig ou réécriture).

Phase 1 — Audit dette technique (5 à 10 jours, à partir de 1 618 € HT). Analyse complète du codebase selon les 8 axes décrits ci-dessus. Output : rapport d'audit, recommandation de voie de migration, plan de migration détaillé phase par phase, estimation de charge et de budget. Sans cet audit, toute estimation de coût est une fiction.

Phase 2 — Plan de migration et setup de l'environnement (2 à 4 semaines). Mise en place de l'environnement cible : Docker Compose (développement), pipeline GitLab CI ou GitHub Actions (CI/CD), environnement de staging iso-production. Introduction de PHPStan niveau 0 et PHPUnit dans le projet existant — l'objectif est de passer à 0 erreur PHPStan niveau 0 avant de commencer le refactoring, pour avoir une baseline propre. Définition de la première itération de migration (premier domaine ou première couche selon la voie choisie).

Phase 3 — Migration progressive par itérations de 2 à 4 semaines. Chaque itération délivre un périmètre fonctionnel migré, testé (PHPUnit + Playwright), et mis en production en parallèle de l'ancienne version (feature flag). Les réunions de pilotage bimensuelles avec le DSI ou CTO client présentent : code migré ce sprint, couverture de tests ajoutée, dette technique réduite (métriques PHPStan, PHPMD, coverage), plan du sprint suivant. La livraison continue feature-by-feature permet au client de voir la progression concrète à chaque sprint et de reprioriser si le contexte business évolue.

Phase 4 — Stabilisation, décommissionnement du legacy, MCO. Une fois 100 % du trafic routé vers la nouvelle version sur tous les domaines, le code legacy est archivé (tag Git) puis retiré du pipeline. Documentation technique mise à jour (ADR — Architecture Decision Records, README, diagrammes de séquence). Formation de l'équipe interne sur la nouvelle stack (Symfony 7 ou Next.js + API Platform selon la voie). Forfait MCO mensuel optionnel (à partir de 1 746 € HT/mois) pour les clients sans équipe technique interne suffisante.

#ROI mesurable — Cas éditeur SaaS PHP 5 → Symfony 7

Cas client référence : éditeur SaaS B2B français, logiciel de gestion commerciale pour PME, 85 000 lignes de code PHP 5.6, aucun framework, Composer absent, zéro couverture PHPUnit, déploiement via FTP. Contexte : l'éditeur avait perdu son seul développeur senior PHP capable de maintenir le codebase, et faisait face à des bugs critiques de plus en plus fréquents en production (3 à 5 incidents majeurs par mois). Ses clients SaaS commençaient à le questionner sur la feuille de route technologique — le legacy PHP 5.6 devenait un frein commercial fort.

Mission Nehos sur 18 mois : audit dette technique initial (complexité cyclomatique moyenne 34, 0 % couverture, 22 advisory de sécurité Composer actives, 8 CVE PHP 5.6 sans patch), migration progressive Strangler Fig vers Symfony 7 + API Platform + Next.js (front reconstruit), couverture de tests montée de 0 % à 74 % PHPUnit + 18 parcours E2E Playwright, pipeline GitLab CI complet. 0 downtime sur toute la durée de la migration (feature flags + exécution parallèle).

Résultats mesurés à 18 mois de migration : 3× moins de bugs en production (de 3-5 incidents majeurs/mois à moins de 1 incident/mois en moyenne), coût de maintenance réduit de 45 % (une demi-journée de développeur par semaine vs 2 jours avant migration), time-to-market des nouvelles features divisé par 2.4 (de 3-4 semaines à 8-12 jours en moyenne grâce à l'architecture modulaire Symfony + CI/CD), recrutement facilité (3 candidats Symfony qualifiés reçus en 2 semaines pour un poste, contre 0 candidat PHP 5 en 3 mois lors de la dernière tentative), score NPS clients SaaS +18 points après lancement de la nouvelle interface Next.js. Investissement total : 435 k€ HT. ROI estimé par le client sur 3 ans : 4,2×.

#Tarification — 212 k€ HT

La tarification d'une mission de migration PHP legacy dépend directement de trois variables : la taille du codebase (KLOC — milliers de lignes de code non-commentées), la profondeur de la dette technique (score d'audit), et la voie de migration choisie. Toute estimation de budget sans audit préalable est indicative et peut varier significativement à la hausse.

Fourchette 212 k€ HT — Petits codebases, migration en place. Codebases 15-40 KLOC, PHP 7.x → PHP 8.3 + Symfony composants, introduction Composer + PSR-4, couverture PHPUnit de 0 % à 50 %, Docker + pipeline CI/CD basique. Durée : 3 à 5 mois. Profil client typique : ETI avec application interne ancienne, SaaS B2B PME mono-tenant.

Fourchette à partir de 19 k€ HT — Codebases moyens, migration en place complète ou Strangler Fig partiel. Codebases 40-100 KLOC, PHP 5/7 → PHP 8.3 + Symfony 7 complet (Routing, DI, Doctrine ORM, Messenger, API Platform partiel), couverture PHPUnit 60 %+, Playwright E2E sur les parcours critiques, Docker multi-stage + pipeline GitLab CI complet. Durée : 5 à 9 mois. Profil client typique : éditeur SaaS B2B mono-produit, ETI avec ERP PHP interne structurant.

Fourchette 712 k€ HT — Grands codebases, Strangler Fig complet ou réécriture. Codebases 100-300 KLOC, migration Strangler Fig complète vers Next.js + Symfony API Platform, ou réécriture complète sur stack cible avec couverture de tests 80 %+, pipeline DevSecOps (SAST, DAST, dependency scanning), formation équipe interne. Durée : 9 à 18 mois. Profil client typique : éditeur SaaS B2B multi-tenant, ETI avec application critique multi-modules.

L'audit dette technique initial (à partir de 1 618 € HT) est toujours facturé séparément en phase 1 — son résultat peut ajuster significativement l'estimation de budget de la migration. Pour un codebase dans le bas de la fourchette en termes de dette, l'audit amène souvent à réduire l'estimation. Pour un codebase fortement dégradé, il peut l'augmenter. Dans tous les cas, l'audit est la seule façon d'avoir une estimation fiable. Réservez un RDV de 30 minutes pour qualifier votre codebase PHP et obtenir une première estimation indicative : [Calendly audit PHP legacy](https://calendly.com/raphael-poirier_/decouverte15min-nehos-groupe