Refactorisation ou réécriture PHP: le guide de décision
À ce stade, l’organisation ne subit plus simplement une dette technique; elle subit une dette de décision. Les équipes hésitent, les budgets se dispersent et le produit perd du terrain au moment même où le time-to-market devrait s’accélérer.
Une application PHP ancienne n’est pas, par nature, une application condamnée. De même, un monolithe n’est pas nécessairement un passif à démolir. La vraie question n’est donc pas: « le code est-il moderne? » Elle est plus exigeante: l’actif logiciel permet-il encore de servir la stratégie produit, de protéger les données, de retenir les talents et de livrer à un rythme compatible avec le marché?
Pour un CTO, un fondateur ou une direction générale, la décision engage bien davantage qu’un budget de développement. Elle engage le TCO de la plateforme, la continuité opérationnelle, la fiabilité des revenus numériques et la capacité de l’entreprise à recruter des développeurs qui accepteront de faire évoluer le système dans la durée.
Réécrire sans audit n’est pas une stratégie de modernisation: c’est un pari coûteux sur une connaissance incomplète du produit.
1. Le risque: l’audit technique doit précéder toute décision
La première erreur consiste à répondre à une impression par une décision d’architecture. « Le code est illisible », « nous sommes bloqués sur une vieille version de PHP », « personne ne veut intervenir dans ce dépôt »: ces signaux sont sérieux, mais ils ne suffisent pas à conclure qu’une réécriture est nécessaire.
Une refactorisation, au sens strict, transforme la structure interne du logiciel sans modifier son comportement observable. Elle rend le système plus lisible, plus testable et moins coûteux à faire évoluer, tout en préservant les règles métier qui produisent déjà de la valeur. Une réécriture complète, à l’inverse, reconstruit tout ou partie du système et implique fréquemment de redéfinir des interfaces, des processus ou des comportements fonctionnels. Confondre les deux revient à brouiller le pilotage du risque.
L’audit technique d’un code legacy PHP doit donc établir une photographie opérationnelle, non un inventaire esthétique. La direction doit pouvoir répondre à cinq questions simples, mais rarement simples à instruire:
- Quelles fonctions génèrent directement du chiffre d’affaires, protègent une obligation réglementaire ou soutiennent une opération critique?
- Quels comportements sont documentés par des tests fiables, et lesquels reposent sur la mémoire de quelques collaborateurs?
- Quelles dépendances Composer sont vulnérables, abandonnées ou incompatibles avec les versions maintenues de PHP?
- Où se concentrent les incidents de production, les lenteurs et les zones de modification les plus coûteuses?
- L’équipe actuelle possède-t-elle la connaissance métier, la disponibilité et la stabilité nécessaires pour mener une transformation sans interrompre la feuille de route produit?
Cette dernière question est souvent sous-estimée. Une application peut être techniquement modernisable, mais ne pas l’être dans les conditions organisationnelles du moment. Si les développeurs les plus expérimentés quittent l’entreprise, si le product ownership est flou ou si le backlog est déjà saturé d’engagements commerciaux, la méthode choisie doit intégrer cette réalité. La dette technique et la dette de gouvernance se renforcent mutuellement.
Un audit utile ne se contente pas d’annoncer que le code est complexe. Il relie cette complexité à ses conséquences: temps moyen pour livrer une évolution, fréquence des régressions, dépendance à certains profils, coût de maintenance PHP, exposition aux vulnérabilités et difficulté de recrutement. C’est à cette condition que la discussion devient une décision d’investissement plutôt qu’un affrontement entre préférence technique et contrainte financière.
2. L’investissement: mesurer la dette plutôt que la commenter
La dette technique est souvent décrite dans un vocabulaire moral: « mauvais code », « bricolage », « erreurs historiques ». Cette approche est improductive. Le code existant est généralement le résultat de décisions prises sous des contraintes de marché, de financement ou de calendrier. Le sujet, pour un dirigeant, n’est pas de juger le passé; il est de chiffrer le coût futur de son maintien.
L’analyse statique apporte ici une première couche de visibilité. PHPStan propose onze niveaux d’analyse, du niveau 0 au niveau 10. L’intérêt n’est pas de basculer brutalement au niveau maximal et de créer plusieurs milliers d’alertes impossibles à traiter. Une adoption progressive, éventuellement fondée sur une ligne de base, permet de distinguer le passif connu des nouveaux défauts introduits au fil des livraisons.
Le même raisonnement vaut pour les tests. La couverture ne doit jamais être réduite à un pourcentage rassurant dans un tableau de bord. PHPUnit permet d’observer la couverture des lignes, des branches, des chemins, des fonctions, des méthodes et des classes. Ces indicateurs n’ont de valeur que rapprochés de la criticité métier et de la complexité du code. L’indice CRAP, par exemple, met en relation complexité cyclomatique et couverture: il signale les zones où un changement sera particulièrement risqué, soit parce qu’elles sont très complexes, soit parce qu’elles sont insuffisamment protégées.
Le comité de pilotage doit chercher des preuves, non des slogans. Un module de facturation avec une couverture limitée, des règles accumulées depuis plusieurs années et une forte densité d’incidents ne se traite pas comme une page de contenu éditorial. À l’inverse, un composant ancien mais stable, correctement testé et peu modifié peut parfaitement rester en place pendant que l’entreprise investit ailleurs.
| Élément observé | Ce qu’il révèle | Conséquence stratégique |
|---|---|---|
| Tests de non-régression fiables sur les parcours critiques | Le comportement actuel peut être préservé et vérifié | La refactorisation incrémentale devient crédible |
| Dépendances abandonnées ou vulnérables | Risque de sécurité et de blocage lors des montées de version | Prioriser l’assainissement du socle et la substitution ciblée |
| Alertes d’analyse statique concentrées dans quelques modules | Dette localisée, souvent traitable par lots | Éviter la réécriture globale et cibler les zones à fort ROI |
| Règles métier implicites, peu documentées | Risque élevé de perte fonctionnelle lors d’une reconstruction | Consolider la connaissance avant toute réécriture |
| Incidents récurrents sur des flux essentiels | Le système compromet directement l’exploitation | Arbitrage accéléré, avec plan de continuité explicite |
| Architecture incapable de répondre aux besoins produits futurs | Limite structurelle, non seulement qualité de code | Évaluer une reconstruction partielle ou complète |
La qualité de l’audit tient également à ce qu’il exclut. L’absence d’alertes Composer ne prouve pas l’absence de risque. L’absence d’erreurs PHPStan ne démontre pas l’absence de défaut métier. Une couverture importante ne garantit pas que les bons scénarios sont testés. La direction technique doit résister à la tentation du feu vert automatique: les outils objectivent une partie du risque, ils ne remplacent ni l’analyse métier ni l’expérience de production.
La dette technique devient pilotable lorsqu’elle est reliée à un coût de livraison, un risque opérationnel ou une opportunité produit perdue.
3. La contrainte de calendrier: PHP et Symfony imposent une trajectoire
La stratégie de modernisation d’une application ne peut ignorer le cycle de vie des technologies qui la composent. Pour PHP, le modèle est clair: chaque branche bénéficie de deux années de support complet, suivies de deux années durant lesquelles seuls les correctifs de sécurité critiques sont fournis. Au-delà de quatre ans, la branche arrive en fin de vie.
Cette mécanique change la nature du risque. Une application sur une branche non maintenue ne devient pas subitement inutilisable; elle devient progressivement plus difficile à sécuriser, à héberger, à intégrer et à faire évoluer. Elle augmente aussi le coût de recrutement, car les développeurs expérimentés souhaitent légitimement travailler dans un environnement où leurs compétences restent valorisables.
À la date de référence du 17 juillet 2026, PHP 8.2 reçoit encore des correctifs de sécurité jusqu’au 31 décembre 2026, sans bénéficier du support actif. PHP 8.3 reste couvert sur le plan de la sécurité jusqu’au 31 décembre 2027. PHP 8.4 demeure en support actif jusqu’au 31 décembre 2026, puis en support de sécurité jusqu’au 31 décembre 2028. PHP 8.5, quant à lui, bénéficie du support actif jusqu’au 31 décembre 2027 et de correctifs de sécurité jusqu’au 31 décembre 2029.
Ces dates sont un instrument de planification, pas un ordre de migration aveugle. Une montée de version PHP, y compris entre versions mineures, peut comporter des incompatibilités ascendantes. La mise à niveau doit donc être testée avant tout déploiement en production. Une direction qui reporte systématiquement cette étape finit par transformer une migration maîtrisable en programme d’urgence.
Avec Symfony, le principe est analogue, mais la cadence doit être intégrée au portefeuille de projets. Le framework publie en principe une version majeure tous les deux ans, en novembre des années impaires, et une version mineure environ tous les six mois. Les versions LTS bénéficient de trois ans de corrections de bugs et de quatre ans de correctifs de sécurité. Pour effectuer une montée majeure, il convient d’abord d’atteindre la dernière version mineure de la branche actuelle, de supprimer les dépréciations, puis de réaliser la migration majeure.
Cette discipline peut paraître lente. Elle est en réalité beaucoup moins coûteuse qu’une accumulation de sauts technologiques. Une organisation qui traite les dépréciations au fil de l’eau conserve des options. Celle qui les ignore pendant quatre ou cinq ans se retrouve fréquemment devant une alternative artificielle: soit geler le produit, soit tout reconstruire.
4. La modernisation incrémentale: préserver la valeur tout en réduisant le risque
Dans une majorité de projets PHP encore actifs, la modernisation incrémentale est la trajectoire la plus rationnelle. Non parce qu’elle serait confortable, mais parce qu’elle limite l’exposition simultanée aux risques techniques, métiers et commerciaux.
Elle consiste à traiter le système par zones de valeur et par interfaces, plutôt que comme un bloc uniforme. Le principe est de conserver le comportement utile, d’encadrer ce comportement par des tests, puis de faire évoluer l’implémentation par petites étapes. L’application continue ainsi de servir les utilisateurs pendant que sa structure interne gagne en cohérence.
Une stratégie modernisation application sérieuse peut suivre cet ordre:
1. Stabiliser l’observable. Identifier les parcours critiques — paiement, commande, droits d’accès, export, calcul de prix, synchronisation — et documenter leur comportement par des tests de caractérisation. Il ne s’agit pas encore de corriger ou d’embellir; il s’agit de savoir ce que le système fait réellement.
2. Sécuriser le socle d’exécution. Traiter les dépendances vulnérables ou abandonnées, rétablir une chaîne d’intégration fiable, produire des environnements reproductibles et planifier la compatibilité PHP. Sans cette base, chaque évolution fonctionnelle porte une prime de risque disproportionnée.
3. Isoler les frontières. Extraire progressivement les accès aux services externes, à la base de données, aux systèmes de paiement ou aux fournisseurs de données. Les frontières bien définies réduisent l’effet de propagation d’un changement et rendent les remplacements ultérieurs possibles.
4. Réduire la complexité là où elle coûte. Les modules fréquemment modifiés et riches en conditions implicites sont les premiers candidats. Le gain ne vient pas d’une perfection abstraite, mais de la baisse mesurable du temps nécessaire pour faire évoluer le backlog sans régression.
5. Faire progresser les exigences de qualité. Augmenter par paliers le niveau d’analyse statique, refuser les nouvelles dépréciations et suivre les défauts introduits. La ligne de base protège la trajectoire: le passif est traité selon une priorité économique, tandis que l’avenir ne recrée pas le même problème.
Cette méthode exige une gouvernance ferme. Le backlog technique ne doit pas être une annexe que l’on sacrifie à chaque arbitrage commercial. Il doit être relié à des résultats attendus: diminuer les incidents, raccourcir le délai de livraison, réduire le risque de sécurité, libérer de la capacité produit ou améliorer la rétention des ingénieurs.
La refactorisation ne produit pas toujours une démonstration spectaculaire. Elle crée cependant une forme de capital: une plateforme capable d’absorber les prochaines décisions de l’entreprise. C’est précisément ce qui en fait un investissement, et non une dépense de confort.
5. Quand la réécriture complète devient une option rationnelle
Il existe néanmoins des situations dans lesquelles la réécriture devient légitime. Elle ne doit pas être choisie parce que le code est ancien, ni parce qu’un nouveau responsable technique souhaite imprimer sa marque. Elle devient rationnelle lorsque l’architecture, le modèle de données ou les dépendances empêchent structurellement l’entreprise d’atteindre ses objectifs.
Le cas le plus sérieux apparaît lorsque le comportement à préserver est lui-même devenu incompatible avec la stratégie. Une application construite pour un seul canal de vente, une seule devise ou un fonctionnement entièrement manuel peut ne plus supporter l’internationalisation, l’automatisation ou les exigences de conformité qui structurent désormais le marché. Dans ce cas, préserver à tout prix le comportement existant revient à conserver le problème.
La réécriture peut également se justifier lorsque plusieurs conditions se cumulent:
- les règles métier sont contradictoires, non maîtrisées et impossibles à isoler sans toucher l’ensemble du système;
- le modèle de données empêche les évolutions indispensables ou compromet la fiabilité des informations;
- les dépendances stratégiques ne disposent plus d’une trajectoire de mise à niveau réaliste;
- l’observabilité est insuffisante au point que les incidents ne peuvent ni être expliqués ni prévenus;
- le coût cumulé des contournements dépasse manifestement l’investissement requis pour une nouvelle fondation;
- l’entreprise peut dégager une équipe stable, un product ownership clair et un financement qui ne met pas en péril la feuille de route courante.
Même dans ce cas, « tout réécrire » ne signifie pas nécessairement couper l’ancien système un matin donné. Une réécriture responsable est progressive dans son déploiement, même lorsqu’elle est radicale dans son architecture. Elle prévoit la coexistence temporaire, la migration des données, les mécanismes de retour arrière, la validation des écarts fonctionnels et la reprise des intégrations tierces.
Le principal risque d’une réécriture est la redécouverte tardive du métier. Les applications anciennes recèlent souvent des règles qui n’existent ni dans les spécifications ni dans les présentations de direction: exceptions de facturation, règles commerciales locales, historiques clients, compromis opérationnels accumulés. Ces règles ne sont pas nobles, mais elles sont fréquemment indispensables. Les ignorer transforme un programme de modernisation en interruption de service différée.
Une décision de portefeuille, non un verdict sur le passé
Le choix stratégique CTO PHP ne se résume pas à opposer le courage de reconstruire à la prudence de conserver. La bonne décision consiste à répartir l’investissement selon le risque et la valeur: refactoriser ce qui fonctionne encore et mérite d’être préservé; remplacer ce qui bloque explicitement l’ambition produit; sécuriser sans délai ce qui expose l’entreprise; accepter, enfin, que certains composants soient retirés plutôt que modernisés.
Une réécriture complète est une décision exceptionnelle, car elle mobilise du capital, du temps de management et une capacité de concentration considérable. Une refactorisation incrémentale est souvent la meilleure voie, à condition qu’elle ne serve pas de prétexte à différer les problèmes structurels.
En définitive, l’entreprise ne choisit pas entre deux techniques. Elle choisit le niveau de risque qu’elle accepte de porter pour continuer à livrer, recruter et croître. La recommandation est donc nette: financez d’abord un audit technique relié aux enjeux métier, transformez ensuite par séquences mesurables, et ne validez une réécriture que lorsque la conservation du système coûte davantage à l’avenir que sa reconstruction maîtrisée.
