PHP 5.6 en 2026, ce n’est pas un débat de puristes. C’est un risque opérationnel. Le jour où ton hébergeur retire l’ancienne image, où la VM ne boot plus, où OpenSSL/TLS te casse un truc, ou juste où tu dois ajouter une dépendance et que plus rien ne compile… tu ne « maintiens » plus. Tu subis.
Ce guide, c’est un plan de sortie. Pas une refonte héroïque. Pas « on réécrit tout en Symfony/Laravel ». Un chemin praticable pour reprendre le contrôle, sécuriser le minimum vital, remettre des tests, puis upgrader par paliers jusqu’à une version PHP supportée.
PHP 5.6 en 2026 : le vrai problème, c’est l’arrêt du monde autour
Oui, ton code PHP 5.6 peut encore « tourner ». Mais tout le reste se dégrade autour : OS, librairies système, extensions PECL, images Docker, outils de build, certificats, CI, et même les compétences dans l’équipe. PHP 5.6 est en fin de vie depuis longtemps, donc pas de correctifs de sécurité. Et surtout, tu es dépendant de gens qui n’ont plus aucune raison de continuer à maintenir un environnement qui te convient.
Le scénario classique, c’est le faux sentiment de stabilité. Ça ne bouge pas, donc on repousse. Jusqu’au jour où une contrainte externe te tombe dessus : migration d’infra, nouveau serveur, changement d’hébergeur, mise à jour forcée d’un reverse proxy, ou incident sécurité qui te pousse à couper des accès. À ce moment-là, « on verra plus tard » devient « on fait comment ce soir ? ».
Sponsorisé par Le Scribouillard
Besoin de contenu optimisé SEO ?
Utilisez la meilleure plateforme française de création de contenu assistée par IA ! Et générez des articles pour moins de 1€ !
Cartographier le legacy : ce que tu dois savoir avant de toucher à PHP
Avant d’ouvrir un IDE et de commencer à remplacer des fonctions, il faut comprendre ce que tu as réellement dans les mains. Un PHP 5.6 en Apache mod_php n’a pas les mêmes contraintes qu’un PHP-FPM, et un site avec trois scripts et une base MySQL n’a pas les mêmes pièges qu’un monolithe qui fait aussi du cron, de l’import CSV et des appels SOAP vers un SI externe.
Concrètement, je veux savoir : comment l’app est servie (Apache/Nginx, mod_php/PHP-FPM), quelles extensions sont indispensables (gd, intl, mcrypt, imap, etc.), où est la base et comment on s’y connecte, comment sont gérés les uploads, qui écrit sur le disque, quels jobs tournent en arrière-plan, et quelles intégrations sortantes existent (paiement, SMTP, API partenaires). Ce dernier point est souvent le piège numéro 1 : tu changes une petite chose, et tu te retrouves à casser un flux externe dont personne ne se souvenait.
Deux signaux doivent immédiatement t’alerter : du code qui dépend d’extensions historiques (mcrypt, mysql_*, vieux drivers) et du code qui écrit partout sur le filesystem. Le premier te bloque à l’upgrade. Le second te complique l’isolation et la sécurisation.
Survivre avant de migrer : isoler PHP 5.6 pour arrêter l’hémorragie
Si tu es déjà en mode « hébergeur coupe tout », ta priorité n’est pas de passer en PHP 8.3 dans la nuit. Ta priorité, c’est de stabiliser l’existant dans une boîte contrôlée. L’approche la plus réaliste, c’est souvent de figer l’environnement dans une VM ou un conteneur, puis de mettre un reverse proxy moderne devant.
J’aime bien le combo « vieux runtime derrière, façade propre devant » : Nginx récent (TLS, headers, rate limiting) qui proxy vers ton PHP 5.6 isolé. Ça te permet de gérer correctement HTTPS, HSTS, les ciphers, les logs, et de réduire l’exposition, sans dépendre des limites d’un stack antique.
Ensuite, tu réduis le rayon d’explosion. Si ton app n’a pas besoin de sortir sur Internet sauf vers deux APIs, tu limites l’egress. Si elle n’a pas besoin d’écrire dans dix répertoires, tu verrouilles en lecture seule et tu laisses une seule zone writable (et tu sais exactement laquelle). Si elle accepte des uploads, tu les sors du serveur ou tu les mets sous contrôle, parce que « upload + vieux PHP + vieux serveur » c’est une recette classique pour se faire ouvrir.
À ce stade, le but n’est pas de rendre le legacy « safe ». C’est impossible à promettre avec un runtime EOL. Le but, c’est de rendre l’incident moins probable, et surtout moins cher quand il arrive.
Sécurité minimale : ce que je fais systématiquement sur un PHP EOL
Je vais être direct : PHP 5.6 ne recevra pas de patch. Donc la stratégie, c’est « réduire l’attaque », pas « corriger ». Tu commences par les basiques qui changent vraiment le risque : supprimer tout accès admin exposé inutilement, mettre un filtrage IP si c’est cohérent, forcer une authentification forte là où c’est possible, et surtout couper tout ce qui ressemble à un panneau d’admin oublié, un phpinfo() qui traîne, ou un dossier de dump accessible.
Côté serveur, tu veux des headers propres, des logs exploitables, un WAF si tu as un trafic exposé, et un monitoring qui te remonte les erreurs PHP et les pics suspects. Et oui, tu vérifies les sauvegardes. Pas « elles existent ». Tu testes une restauration. Parce que le jour où tu touches au runtime, le vrai filet, c’est le restore.
Avant l’upgrade : remettre des tests, même si tu n’en as jamais eu
Le piège, c’est de croire que « rajouter des tests » veut dire écrire 300 PHPUnit sur une base de code de 2014. Non. Pour une migration PHP, ton meilleur ROI, c’est une couche de tests grossiers mais fiables, qui te dit juste si l’app respire encore.
Je commence souvent par des smoke tests HTTP qui tapent les pages critiques (login, formulaire principal, checkout s’il y en a un, back-office minimal). Tu veux attraper l’erreur fatale et la page blanche. Ensuite, j’aime bien l’approche « golden pages » : tu captures quelques réponses HTML sur une base de données de staging, tu les compares après migration, et tu acceptes que ce soit imparfait. L’objectif n’est pas d’avoir un diff parfait. L’objectif est d’attraper le gros bug qui sinon passerait en prod.
Quand c’est une app plus interactive, un mini-playwright ou un script Selenium te sauve la vie. Pas pour « tout couvrir ». Pour rejouer 3 parcours critiques en automatique, à chaque tentative d’upgrade. Le but est simple : réduire le nombre de retours arrière et te donner le droit d’avancer.
La stratégie qui marche : upgrader par paliers (5.6 → 7.4 → 8.2/8.3)
Passer de 5.6 à 8.3 d’un coup, ça ressemble à une bonne idée… jusqu’au moment où tu te prends 40 incompatibilités en même temps, sans savoir ce qui est lié à quoi. Dans la vraie vie, le chemin le moins douloureux, c’est souvent de viser d’abord PHP 7.4, puis seulement ensuite PHP 8.2/8.3. PHP 7.4 n’est plus supporté non plus, donc ce n’est pas une destination, mais c’est un palier utile pour « traduire » un vieux code vers le monde moderne.
Le premier mur classique, c’est la base de données. Si ton code utilise mysql_*, c’est mort en PHP 7. Tu dois migrer vers mysqli ou PDO. Et tant qu’à faire, tu en profites pour nettoyer les requêtes construites à la main avec concaténation, parce que c’est rarement joli et souvent dangereux. J’ai vu des migrations où le passage à PDO a sorti des failles SQL qui dormaient depuis des années, simplement parce qu’on a enfin regardé les requêtes en face.
Le deuxième mur, ce sont les extensions disparues ou « bizarres ». mcrypt est l’exemple emblématique. Si ton app chiffre des choses avec mcrypt, ne te raconte pas d’histoire : tu vas devoir décider ce qui doit rester chiffré, comment migrer le stockage, et comment gérer la compat. C’est typiquement le genre de truc à encapsuler derrière une interface, pour pouvoir changer l’implémentation sans retoucher tout le code.
Le troisième mur, c’est le comportement. PHP 7 et 8 ont durci pas mal de choses. Des warnings deviennent des erreurs, des notices se transforment en comportements différents, et surtout tu vas croiser des fatal errors là où PHP 5.6 « laissait passer ». Ça fait mal, mais c’est aussi une bonne nouvelle : ton app devient plus déterministe, et tu arrêtes de cacher des bugs.
Mon conseil terrain : traite d’abord ce qui empêche l’exécution (fatal errors, extensions, autoload). Ensuite seulement, tu t’occupes des warnings et des edge cases. Si tu fais l’inverse, tu vas passer deux jours à polir un truc qui ne démarre même pas.
Composer, dépendances, autoload : l’autre migration qui te tombe dessus
Sur du PHP 5.6, tu tombes souvent sur un mélange un peu toxique : pas de composer, ou composer très ancien, ou des vendors copiés à la main sur le serveur. Et quand composer est là, tu as parfois des dépendances qui n’existent plus, ou des contraintes de version qui te bloquent.
Le move pratique, c’est de remettre de l’ordre côté build. Tu veux pouvoir installer les dépendances en CI, reproduire un build, et éviter le « ça marche sur le serveur parce qu’il y a un fichier vendor d’il y a 6 ans ». Et tu veux pouvoir annoncer clairement « notre prod tourne sur PHP X » sans que l’environnement réel te contredise.
Si tu as une app avec beaucoup de dépendances, utilise une contrainte de plateforme pour simuler la version PHP cible au moment où tu fais évoluer les packages. Ça évite de tirer des libs modernes qui ne tourneront jamais sur ton palier actuel.
{
"config": {
"platform": {
"php": "7.4.33"
}
}
}
Ce n’est pas magique, et ça n’empêche pas les problèmes, mais ça rend le chantier plus pilotable. Et ça te force à expliciter une cible.
Les incompatibilités que tu vas croiser (et qui font perdre un temps fou)
Tu vas rencontrer des vieux classiques. Le mysql_* on en a parlé. Les patterns preg_replace avec le modificateur /e aussi, ça revient souvent dans des vieux templatings maison ou des helpers « malins ». La gestion de JSON peut te surprendre si tu avais des encodages bancals ou des chaînes pas vraiment en UTF-8. Et tu as aussi des trucs très bêtes, du genre des noms de fonctions ou de classes qui deviennent des mots réservés, ou des warnings qui étaient ignorés et qui te cassent un flux parce que tu renvoyais du HTML avant un header.
Le plus insidieux, c’est quand « ça marche » mais plus pareil. Une migration PHP qui ne casse rien visiblement peut quand même modifier des conversions de types, des comparaisons, ou des arrondis. D’où l’intérêt des golden pages et des parcours automatisés, même imparfaits.
Si tu as un gros codebase, n’hésite pas à t’appuyer sur des outils de compatibilité (PHP_CodeSniffer avec PHPCompatibility, Rector, PHPStan/Psalm). Pas pour remplacer ton cerveau. Pour éviter de jouer à la chasse au bug à l’aveugle.
Le plan “budget/dev” : ce que tu corriges, ce que tu retires, ce que tu encapsules
Le problème des migrations legacy, ce n’est pas seulement technique. C’est le périmètre. Si tu essaies de profiter du chantier pour « nettoyer tout le code », tu vas exploser ton budget et ta motivation. À l’inverse, si tu refuses de toucher à quoi que ce soit, tu risques de rester bloqué sur des briques qui ne passeront jamais en PHP moderne.
Je découpe généralement en trois catégories. D’abord, ce qui est non négociable parce que ça bloque l’exécution (db driver, extensions, autoload, erreurs fatales). Ensuite, ce qui peut être retiré parce que ça ne sert plus ou que personne n’ose l’assumer (un export legacy, un module admin fantôme, un vieux connecteur). Enfin, ce qui doit être encapsulé parce que c’est risqué ou central (crypto, paiement, intégrations externes). L’encapsulation te permet d’avancer sans tout comprendre dès le jour 1, et ça te donne un point d’entrée propre pour corriger plus tard.
Et surtout, tu arbitres avec une règle simple : ton but est d’arriver sur une version PHP supportée avec une app qui redémarre et qui se monitore. Pas d’atteindre la perfection.
Mon avis (tranché) : la “réécriture panique” coûte plus cher que la migration par étapes
Je comprends la tentation du grand reset. Mais la réécriture panique arrive au pire moment, avec le pire niveau de stress, et elle casse presque toujours des comportements métier que personne n’avait documentés. Une migration par paliers n’est pas sexy. Elle est ennuyeuse. Et c’est exactement ce que tu veux.
Le meilleur indicateur que tu es sur la bonne voie, c’est quand le sujet « PHP 5.6 » cesse d’être une urgence émotionnelle et devient un chantier piloté, avec un environnement reproductible, des tests minimaux, des logs, et une roadmap technique compréhensible par l’équipe.
Conclusion : vise une sortie “ennuyeuse”, puis une vraie modernisation
Sortir de PHP 5.6, ce n’est pas « moderniser » ton produit. C’est arrêter de jouer avec une dette qui peut te tomber dessus n’importe quand. Une fois que tu es en PHP 8.2/8.3 (ou au moins sur une version supportée), là tu peux commencer à faire les bons chantiers : typage progressif, refacto des zones chaudes, upgrade framework, nettoyage des dépendances, et amélioration perf.
Mais d’abord, tu t’extrais. Proprement. Sans big bang. Et avec un filet.
