Moderniser une plateforme PHP legacy vers PHP 8 : refonte complète ou Strangler Fig ?

Pourquoi commencer par les risques et l’inventaire

Les branches PHP 5 et PHP 7, y compris PHP 7.4, ne reçoivent plus de correctifs de sécurité du projet PHP. Une application peut continuer de fonctionner, mais une vulnérabilité découverte dans le moteur ou dans une dépendance abandonnée peut devenir difficile à corriger. L’hébergement, le système d’exploitation, la base de données et les extensions natives ont eux aussi leurs propres cycles de support.

Avant de choisir une cible, recensez les versions PHP et extensions réellement exécutées, les bibliothèques Composer, les services externes, les tâches planifiées, les files de traitement et les environnements. Vérifiez les incompatibilités de langage et d’API, les bibliothèques sans version compatible et les contraintes de l’hébergeur. Un saut de version peut aussi changer des comportements implicites : avertissements, conversions de types ou gestion des erreurs.

Cartographiez aussi les utilisateurs, les processus critiques, les périodes sensibles, les propriétaires métier et les personnes capables de maintenir chaque composant. Le développement PHP sur mesure commence par cette connaissance : une dépendance humaine ou une règle non documentée peut être aussi déterminante qu’une dépendance technique.

Si les dépendances sont compatibles ou remplaçables, que le code est testable et que l’architecture répond encore au métier, une mise à niveau en place peut être la voie la plus directe. Si ces conditions ne tiennent pas, il faut comparer une refonte complète avec une migration par domaines, sans présumer que l’une sera toujours moins coûteuse.

Refonte complète ou Strangler Fig : des risques différents

Une refonte reconstruit le périmètre avant une bascule généralement concentrée. Avec Strangler Fig, une façade dirige certaines demandes vers les nouveaux composants et laisse les autres à l’ancien système ; la couverture évolue par étapes. Les deux approches peuvent coexister dans un même programme, selon les domaines.

Une façade ne simplifie pas automatiquement un monolithe très imbriqué. Si chaque opération écrit dans les mêmes tables et dépend des mêmes transactions, la séparation peut exiger des adaptations importantes avant la première livraison. À l’inverse, une refonte sans connaissance des règles métier risque de reproduire trop tard les exceptions essentielles.

Cinq étapes pour une migration progressive maîtrisée

1. Cartographier les flux et choisir une première frontière

Reliez les parcours utilisateurs aux écrans, traitements, tables, tâches planifiées et intégrations qui les soutiennent. Identifiez les données sensibles, les pics d’activité, les règles connues uniquement des équipes et les dépendances entre domaines. Choisissez une première fonction suffisamment isolable pour valider la méthode, avec un responsable métier, des critères d’acceptation et une stratégie de retrait de l’ancien code.

2. Installer une façade et organiser le routage

Une façade ou un proxy dirige les requêtes vers le legacy ou vers le nouveau service selon une règle explicite : chemin, fonction ou cohorte contrôlée. Prévoyez ses limites de capacité, sa surveillance, ses règles de sécurité et son propre mode de défaillance ; elle ne doit pas devenir un point aveugle. Documentez qui décide des changements de routage et comment les annuler.

La compatibilité des sessions et de l’authentification est centrale : cookies, domaine, durée, stockage et droits doivent être compatibles ou reliés par un mécanisme d’authentification conçu pour les deux systèmes. Testez la connexion, la déconnexion et le passage d’un parcours à l’autre, sans partager aveuglément des secrets ou des formats de session incompatibles.

3. Capturer les comportements avec des tests de caractérisation

Avant de modifier une fonction, enregistrez ce que le système actuel produit pour des entrées représentatives, puis confrontez ces résultats aux attentes des responsables métier. Ces tests décrivent l’existant, y compris ses anomalies : une différence détectée n’est pas automatiquement un défaut du nouveau système ni une règle à conserver.

Pour la facturation québécoise, vérifiez notamment la TPS et la TVQ, les exemptions applicables, les remises, les avoirs et les arrondis par ligne ou sur le total selon les règles retenues. Comparez les résultats sur des cas limites et des données dépersonnalisées ; faites valider les écarts par les personnes compétentes avant de changer le calcul.

4. Migrer les données et les intégrations

Pour chaque donnée et chaque étape, désignez une source de vérité et le système autorisé à écrire. Définissez la reprise initiale, la synchronisation, les contrôles de rapprochement, les conflits et le transfert de propriété. Évitez les doubles écritures non coordonnées : elles peuvent créer des divergences difficiles à détecter ou à réparer.

Pour les paiements, courriels, API et traitements asynchrones, prévoyez des opérations idempotentes ou des clés d’idempotence lorsque c’est possible, des limites de temps (timeouts), des reprises contrôlées et des mécanismes de détection des doublons. Testez les erreurs partielles et les contrats avec les partenaires ; une nouvelle requête après un délai dépassé ne signifie pas forcément que l’opération initiale a échoué.

5. Basculer, observer et retirer

Définissez avant chaque bascule une fenêtre adaptée, des responsables, des seuils d’alerte et des critères d’arrêt. Observez les erreurs, la latence, les files, les résultats métier et les écarts de données ; prévoyez une procédure de communication et de reprise. Augmentez progressivement le trafic lorsque les observations le justifient, puis retirez le code, les accès et la façade devenus inutiles après validation.

Revenir au routage précédent ne suffit pas toujours : si le nouveau système a modifié des données ou déclenché des effets externes, le rollback peut exiger une réconciliation, des opérations compensatoires ou une restauration avec reprise des changements. Préparez et exercez ces scénarios avant la bascule, sans supposer qu’un retour arrière complet sera toujours possible.

Une grille de décision et de budget sans prix fictifs

Pour chaque domaine, confrontez la capacité à isoler les fonctions, la connaissance des règles, l’état des dépendances, les contraintes de données, la tolérance aux interruptions et les compétences disponibles. Une mise à niveau en place mérite d’être évaluée si le socle reste viable ; une refonte si le périmètre est borné et le modèle doit changer ; une approche progressive si les frontières et la coexistence sont gérables.

Établissez des hypothèses explicites et réévaluez-les après les premières découvertes. Le budget doit couvrir l’exploitation pendant la transition et la sortie du legacy, pas seulement la création du nouveau code. Aucun calendrier fiable ne se déduit du seul numéro de version PHP.

PHP 8, Laravel et Symfony : choisir des versions soutenues

Pour une nouvelle cible, PHP 8.4 et PHP 8.5 méritent d’être évalués selon la compatibilité des dépendances et de l’hébergement. Le calendrier officiel prévoit la fin du support de sécurité de PHP 8.3 au 31 décembre 2027, de PHP 8.4 au 31 décembre 2028 et de PHP 8.5 au 31 décembre 2029. Ces dates ne signifient pas que toutes les versions 8.x bénéficient d’un support identique : vérifiez aussi les phases de support actif et de sécurité au moment du choix.

Laravel 13 exige au minimum PHP 8.3 ; Symfony 7.4 exige PHP 8.2 et Symfony 8.0 PHP 8.4. Un minimum ne garantit pas la compatibilité de toutes les dépendances ni la même durée de support. Vérifiez séparément les versions PHP prises en charge, les dates de correctifs du framework et celles des bibliothèques utilisées.

Une migration vers Laravel peut convenir à une équipe qui recherche un ensemble de conventions et de composants intégrés. Une architecture Symfony pour applications critiques peut convenir à un contexte qui privilégie ses composants et une structuration adaptée aux contraintes du système. Le choix dépend de l’équipe, des besoins et de la maintenance future, pas d’une supériorité universelle.

Mesurer la performance au-delà du changement de version

Un moteur plus récent ne corrige pas à lui seul une application lente. Mesurez les parcours critiques avant et après migration : temps de réponse, requêtes et charge de la base, consommation de ressources et délais des traitements asynchrones. Repérez les requêtes N+1, examinez les index et chargez les relations nécessaires plutôt que de multiplier les accès à la base.

Le cache peut réduire du travail répété, mais exige des règles d’expiration et d’invalidation adaptées aux données. Les files peuvent déplacer des tâches hors du parcours utilisateur ; elles demandent aussi surveillance, reprise après erreur et contrôle des doublons. Validez ces choix sous une charge représentative au lieu de présumer un gain.

Loi 25 et données de santé : intégrer les obligations au projet

Selon les données traitées, le lieu d’activité et les circonstances, la Loi 25 au Québec et d’autres règles de protection des renseignements personnels peuvent s’appliquer. La migration est l’occasion d’examiner les finalités, les accès, la conservation, la journalisation, les transferts et la réponse aux incidents. Limitez les données utilisées pour les tests et protégez les sauvegardes comme les environnements temporaires.

Si la plateforme traite des renseignements de santé, des obligations et des exigences contractuelles supplémentaires peuvent s’appliquer selon le contexte. Associez les responsables de la sécurité et de la protection des renseignements personnels aux décisions, et obtenez un avis juridique adapté. Une version récente de PHP ou un framework ne garantit pas à elle seule la conformité.

Questions fréquentes sur la migration PHP

Commencer par un audit, pas par une technologie

Une migration réussie commence par une décision éclairée sur les risques, les règles métier et la capacité de l’organisation à soutenir la transition. Avant de choisir une refonte ou Strangler Fig, faites réaliser un audit de votre plateforme PHP pour cartographier les dépendances, comparer les trajectoires et préparer les premières décisions avec vos équipes.