Le problème : le PHP legacy est une panne au ralenti
Une application PHP legacy porte généralement trois risques à la fois : elle tourne sur une version de PHP qui ne reçoit plus de correctifs de sécurité, elle dialogue avec la base de données via des extensions que le PHP moderne a supprimées, et elle vit sur un unique serveur vieillissant que personne n'ose redémarrer. Chaque mois qui passe la rend plus exposée et plus difficile à déplacer, car la mémoire institutionnelle de son fonctionnement s'estompe tandis que la surface d'attaque grandit. L'instinct de la laisser tranquille est compréhensible et c'est exactement ce qui la rend dangereuse — plus elle attend, plus la migration forcée finale devient massive. Ce scénario existe pour rendre le déplacement délibéré et réversible plutôt qu'une urgence.
Comment cdn.com.tr résout ce problème : runtime moderne, données managées, bouclier edge
PHP Platform donne à l'application un runtime PHP 8 supporté avec un vrai gestionnaire de fichiers et une sélection de version, si bien que vous n'êtes plus figé sur ce qui était installé sur l'ancienne machine. La base de données managée retire les données de ce serveur fragile et les place sur un service MySQL maintenu, avec des identifiants injectés dans le runtime plutôt que collés dans des fichiers de configuration. Devant les deux, la couche edge termine le TLS avec Auto SSL et filtre le trafic avec le WAF, si bien que même un code antérieur aux pratiques de sécurité modernes n'est pas directement exposé à internet. Vous modernisez le runtime et la couche de données tout en enveloppant l'ensemble d'une protection que l'application d'origine n'a jamais eue.
Compatibilité PHP 8 : le travail qui conditionne réellement le déplacement
La migration réussit ou échoue sur la compatibilité du code, c'est donc là que va le véritable effort. Les applications legacy utilisent couramment les fonctions supprimées mysql_*, s'appuient sur des fonctions supprimées ou modifiées en PHP 7 et 8, supposent un jonglage de types laxiste que PHP 8 a resserré, ou dépendent d'extensions qui ne sont plus fournies par défaut. Faire tourner l'application sur une copie en staging du nouveau runtime révèle ces problèmes sous forme d'erreurs concrètes plutôt que de surprises en production. Vous les corrigez méthodiquement — remplacez mysql_* par mysqli ou PDO, remplacez les fonctions supprimées, traitez les avertissements — et retestez jusqu'à ce que les parcours critiques soient propres. Ce n'est qu'alors que la mise en ligne devient une étape de routine plutôt qu'un saut dans le vide.
Migrer la base de données sans corrompre vos données
Déplacer les données est l'endroit où des dégâts silencieux surviennent si vous vous précipitez. Le piège le plus courant est l'encodage des caractères : de nombreuses bases legacy sont en latin1 ou dans un mélange, et les importer dans une cible utf8mb4 sans précaution transforme les caractères turcs et autre texte non-ASCII en charabia difficile à corriger ensuite. La voie sûre consiste à importer dans MySQL managé, à faire correspondre explicitement le jeu de caractères et la collation source, et à vérifier un échantillon d'enregistrements réels — en particulier tout ce qui contient du texte accentué ou non latin — avant de faire confiance au résultat. Vous validez le cycle complet de lecture/écriture en staging afin qu'au moment de la bascule la base de données soit une copie fiable connue, pas une copie sur laquelle on espère.
Staging et rollback : ne jamais jouer avec le trafic réel
La discipline qui rend une migration legacy sûre est que la production continue de tourner intacte jusqu'à ce que le nouvel environnement ait fait ses preuves. Vous construisez et testez tout en staging, et vous gardez l'ancien hôte vivant et opérationnel jusqu'après la bascule. Abaisser le TTL DNS à l'avance signifie que le passage vers l'edge — et le retour en arrière, si nécessaire — prend des minutes plutôt que des heures. Si quelque chose casse sous un trafic réel que le staging n'avait pas révélé, vous revenez au DNS de l'ancien hôte, corrigez le problème en staging, et réessayez. Comme rien de l'ancien environnement n'a été détruit pendant le déplacement, le rollback est une vraie option, pas un bluff.
Optionnel : standardiser les déploiements futurs avec GitHub
Une fois l'application sur la plateforme, vous pouvez connecter son dépôt via GitHub Deploy afin que les futurs changements passent par un pipeline reproductible — installation Composer, build et étapes de migration définis une fois et exécutés de la même façon à chaque fois. Cela transforme la migration ponctuelle en un flux de déploiement continu et contrôlé, ce qui est souvent le moment où une application longtemps négligée obtient enfin un processus de release maintenable. C'est optionnel, mais c'est ce qui fait qu'une migration de sauvetage devient une vraie modernisation plutôt qu'un simple changement d'adresse.
Comment le mettre en place, étape par étape
Faire l'inventaire de l'application et choisir un runtime cible
Répertoriez la version de PHP, les extensions, les tâches cron et les chemins de fichiers dont dépend l'application, puis créez une application PHP Platform ciblant un runtime PHP 8 supporté. Notez tout ce qui utilise des fonctions supprimées ou de vieilles extensions MySQL afin de connaître à l'avance les changements de code à venir avant de toucher la production.
Monter une copie en staging
Déployez le code sur la plateforme comme environnement de staging et importez une copie de la base de données, afin de pouvoir exercer l'application sur le nouveau runtime sans aucun trafic réel. Poussez le code via GitHub Deploy ou le gestionnaire de fichiers, et gardez cet environnement jusqu'à ce que la migration soit validée.
Migrer la base de données vers MySQL managé
Créez une base de données managée, importez votre dump, et vérifiez que le jeu de caractères et la collation correspondent à l'original (les applications legacy sont souvent en latin1 ou dans un encodage mixte). Faites pointer l'application vers la base managée en utilisant les identifiants fournis par la plateforme plutôt que de les coder en dur, et vérifiez les lectures et écritures en staging.
Corriger la compatibilité et retester en staging
Traitez les problèmes PHP 8 révélés en staging — fonctions dépréciées, mysql_* vers mysqli/PDO, gestion des types plus stricte — jusqu'à ce que l'application tourne proprement. Testez les parcours critiques (connexion, formulaires, admin, paiements) de bout en bout sur l'URL de staging avant d'envisager la mise en ligne.
Attacher le domaine, Auto SSL et WAF
Amenez le domaine sur le compte CDN, laissez Auto SSL préparer le certificat, et activez le WAF afin que le vieux code soit protégé dès qu'il fait face à internet public. Gardez l'origine joignable uniquement via l'edge afin que le serveur applicatif ne soit jamais exposé directement.
Basculer le DNS avec un rollback prêt
Basculez le DNS vers l'edge pendant une fenêtre calme avec un TTL bas défini à l'avance, afin de pouvoir revenir en arrière rapidement en cas de problème. Gardez l'ancien hôte actif et intact jusqu'à ce que le nouvel environnement ait fait ses preuves sous un trafic réel, puis mettez-le hors service.
Exemples de scénarios
Un forum de longue date en PHP fin de vie est déplacé vers PHP 8 et MySQL managé, avec les sections d'archives à forte lecture mises en cache à l'edge et le WAF atténuant les abus de bots.
Un CMS PHP sur mesure est porté tel quel sur le runtime moderne après correction de la compatibilité, offrant des années de fonctionnement sûr sans réécriture complète.
Un outil métier PHP tournant sur une seule machine vieillissante est migré vers un runtime et une base de données managés, éliminant le point de défaillance unique qui rendait tout le monde nerveux.
Questions fréquentes
Mon application utilise les vieilles fonctions mysql_*. Fonctionnera-t-elle sur PHP 8 ?
Pas telle quelle — ces fonctions ont été supprimées il y a des années. La migration comprend leur remplacement par mysqli ou PDO, exactement le genre de problème que le staging révèle sous forme d'erreurs claires afin que vous le corrigiez avant la mise en ligne plutôt que de le découvrir en production.
Comment éviter de corrompre les caractères turcs pendant le déplacement de la base ?
Faites correspondre explicitement le jeu de caractères et la collation source lors de l'import dans MySQL managé, et vérifiez en staging des échantillons d'enregistrements contenant du texte accentué ou non latin. Les décalages d'encodage sont l'échec silencieux le plus courant des migrations legacy, vous le validez donc avant la bascule, pas après.
Puis-je tout tester avant de toucher le site en production ?
Oui, c'est le cœur de l'approche. Vous faites tourner une copie complète en staging sur le nouveau runtime avec une copie de la base de données, vous validez les parcours critiques, et ce n'est qu'ensuite que vous basculez le DNS. La production continue de tourner sur l'ancien hôte pendant tout ce temps.
Que se passe-t-il si quelque chose casse juste après la bascule ?
Vous revenez au DNS de l'ancien hôte, qui est toujours actif et intact, puis vous corrigez le problème en staging et réessayez. Définir un TTL DNS bas avant la bascule ramène ce rollback à quelques minutes.
Dois-je mettre à niveau tout mon code d'un coup ?
Il vous faut suffisamment de travail de compatibilité pour que l'application tourne proprement sur le runtime PHP 8 cible, mais vous n'avez pas à réécrire l'application. De nombreuses applications legacy migrent avec un ensemble ciblé de corrections ; un refactoring plus large peut avoir lieu plus tard une fois l'application en sécurité sur la plateforme.
Mon vieux code est-il en sécurité une fois de nouveau exposé à internet ?
Le WAF edge et Auto SSL se placent devant l'application, filtrant le trafic d'attaque courant et imposant HTTPS avant que les requêtes n'atteignent l'origine. Combiné au fait de ne rendre le serveur applicatif joignable que via l'edge, cela offre au code legacy une protection qu'il n'a jamais eue sur son ancien hôte.