Migrer un site d’entreprise vers PHP 8 sans interruption au Québec

Pour passer un site à PHP 8 sans interruption, clonez-le en préproduction, faites-le tourner sur la version visée, corrigez toutes les erreurs et tous les avis de dépréciation, puis changez la version PHP du site en ligne durant une période creuse, avec l’ancienne version prête pour un retour arrière. Le risque n’est pas PHP 8 lui-même. C’est de mettre à jour le site en ligne en premier et d’apprendre ce qui a cassé par vos clients.

AERVIO réalise ces migrations pour des sites d’entreprises québécoises et canadiennes depuis Montréal, en semaine de 9 h à 17 h HE. Voici la séquence que nous suivons, avec les vérifications qui comptent.

Pourquoi on ne peut pas attendre

Chaque branche de PHP a une période de soutien actif, puis une période de correctifs de sécurité seulement, après laquelle elle ne reçoit plus rien. Un site sur une version en fin de vie exécute du code avec des failles connues et non corrigées, et certaines extensions et certains hébergeurs cesseront de la prendre en charge. Les dates à jour sont sur la page des versions prises en charge de php.net : vérifiez-la avant de planifier, la réponse change chaque année.

C’est aussi une question d’hébergement et de sécurité, pas seulement de développement. Les bases du durcissement : AMF, sauvegardes et alertes supposent que l’environnement d’exécution en dessous est encore maintenu.

Étape 1 : inventorier ce que vous exécutez vraiment

Avant de changer quoi que ce soit, notez :

• la version PHP actuelle (panneau d’hébergement ou page `phpinfo()` sur une URL protégée)
• le CMS et sa version : WordPress, Joomla, OpenCart, Drupal ou sur mesure
• le thème et le thème enfant, avec le nom de qui les a faits
• chaque extension, avec sa version et la date de sa dernière mise à jour
• le code maison : mu-plugins, fichiers functions, scripts cron, inclusions ponctuelles
• les extensions PHP requises (imagick, intl, mbstring, curl, zip et autres)
• le moteur de base de données et sa version
• qui a accès à l’hébergement et qui peut restaurer une sauvegarde

Si l’inventaire prend plus d’une heure, ça en dit long sur le temps depuis lequel le site n’est plus géré.

Étape 2 : sauvegarder et prouver qu’on sait restaurer

Une sauvegarde jamais restaurée est un espoir. Faites une sauvegarde complète des fichiers et de la base de données, gardez une copie hors de l’hébergeur, et restaurez-la en préproduction à titre d’essai. Cette restauration sert aussi à construire votre préproduction.

Étape 3 : monter la préproduction sur la version visée

Créez une copie avec le même contenu de base de données (anonymisez ou limitez les renseignements personnels selon vos obligations de confidentialité) et réglez sa version PHP sur la cible.

Bloquez les moteurs de recherche sur la préproduction, désactivez l’envoi de courriels et les paiements, et assurez-vous que les tâches cron et les webhooks n’appellent pas les services de production depuis la copie. Nous avons déjà vu une préproduction envoyer de vrais courriels de commande. Évitez ce scénario.

Étape 4 : trouver ce qui casse

Utilisez plusieurs signaux, pas un seul.

• Analyse statique. Les règles PHPCompatibility avec PHP_CodeSniffer signalent la syntaxe et les fonctions dont l’usage a changé d’une version à l’autre.
• Journal d’erreurs. Activez la journalisation en préproduction, parcourez chaque type de gabarit et de formulaire, puis lisez le journal.
• Avis de dépréciation. Traitez-les comme une liste de tâches, pas comme du bruit. Certains deviennent des erreurs fatales à la version suivante.
• Mises à jour des extensions et thèmes. Passez d’abord aux dernières versions compatibles. Bien des correctifs existent déjà en amont.
• Parcours manuels. Formulaires de contact, paiement, connexion, recherche, téléversements, tâches planifiées et chaque intégration.

Constats typiques :

Ne masquez pas les erreurs pour que la page s’affiche. Les erreurs réduites au silence sont celles qu’on découvre en production.

Étape 5 : trancher pour chaque composant abandonné

Pour chaque extension, thème ou script qui plante sans mise à jour, choisissez une option :

1. Remplacer par une solution maintenue
2. Appliquer un correctif documenté qu’on peut réappliquer
3. Retirer la fonction
4. Reconstruire la petite partie qui compte

Garder un composant abandonné en restant sur une vieille version de PHP est la pire des quatre options : le risque est invisible jusqu’au jour où il ne l’est plus.

Étape 6 : planifier la bascule

Choisissez une plage à faible trafic avec l’équipe disponible. Pour beaucoup de sites B2B, c’est tôt un matin de semaine ou un soir de fin de semaine. Gelez les changements de contenu et les commandes si le site vend.

Liste avant la bascule :

• Sauvegarde complète récente, restauration testée
• Accès au panneau d’hébergement confirmé
• Ancienne version PHP encore sélectionnable
• Surveillance active (vérification de disponibilité et journal d’erreurs)
• Quelqu’un prêt à tester formulaires et paiement tout de suite après
• Une personne désignée qui peut dire « on revient en arrière »

Étape 7 : basculer et vérifier

Changez la version PHP du site dans le panneau d’hébergement. La plupart des hébergeurs l’appliquent par domaine en quelques secondes.

Puis vérifiez :

• La page d’accueil et trois pages profondes se chargent
• La connexion à l’administration fonctionne
• Les formulaires arrivent à destination et, s’ils sont reliés, créent les fiches CRM
• Le paiement termine une commande test
• Les tâches planifiées s’exécutent
• Le journal d’erreurs reste propre pendant un moment
• Search Console ne montre pas de hausse d’erreurs serveur dans les jours qui suivent

Si un problème imprévu survient, revenez en arrière d’abord, diagnostiquez ensuite. C’est à ça que sert le retour arrière.

Étape 8 : laisser le site en meilleur état

Après une migration réussie :

• Consignez la version PHP, les extensions et la date dans un guide d’exploitation
• Activez les mises à jour mineures automatiques là où c’est sûr
• Inscrivez la prochaine date de fin de soutien PHP à votre calendrier
• Retirez les extensions, thèmes et anciennes copies de préproduction inutilisés
• Ajoutez une surveillance de disponibilité s’il n’y en avait pas

C’est ici qu’un cadre géré aide. Hands-off IT couvre l’exploitation, et un retainer de croissance peut comprendre des revues périodiques de l’environnement et des extensions, pour que la prochaine migration soit une routine plutôt qu’une urgence.

Quand demander de l’aide

Faites-le vous-même si le site est un CMS standard avec quelques extensions maintenues et que vous avez un environnement de préproduction. Demandez de l’aide si :

• le site repose sur du code maison que personne dans l’équipe n’a écrit
• l’hébergeur n’offre ni préproduction ni changement de PHP par site
• le paiement, les réservations ou d’autres sources de revenus dépendent de vieilles extensions
• vous êtes sur une très vieille version de PHP et qu’un saut en plusieurs étapes s’impose
• vous ne pouvez pas confirmer qui détient le compte d’hébergement

Ce que nous ne promettons pas

Nous ne promettons pas zéro problème sur un site qui n’a pas été touché depuis des années. Nous promettons un processus par étapes, un retour arrière et une liste écrite de ce qui a changé. Être sur une version PHP prise en charge ne garantit pas non plus de bons résultats de recherche : cela retire un risque de sécurité et de maintenance.

Prochaine étape

Écrivez à hello@aervio.io avec l’URL du site, le CMS et la version PHP affichée dans votre panneau d’hébergement, ou appelez le +1 438-498-3913, en semaine de 9 h à 17 h HE. Nous dirons si c’est une tâche d’une journée ou une refonte déguisée. Notre page services web explique comment nous suivons les sites après la migration.

Questions

Quelle version de PHP 8 faut-il viser?

La plus récente que votre code et vos extensions prennent en charge et qui reçoit encore des correctifs de sécurité. Consultez la page des versions prises en charge sur php.net, car les dates changent chaque année. Ne vous arrêtez pas sur une version qui va bientôt perdre son soutien.

Peut-on migrer sans aucune interruption?

Pour la plupart des sites, oui. Si vous testez sur une copie de préproduction, corrigez les erreurs là-bas et changez la version PHP dans le panneau d’hébergement pendant une période creuse, les visiteurs ne voient généralement rien. Le changement s’inverse en quelques minutes si l’ancienne version reste disponible.

Que faire si une extension ou un thème abandonné plante sous PHP 8?

Remplacez-le, dupliquez-le avec un correctif documenté, ou retirez la fonction. Rester sur une version PHP non prise en charge pour garder en vie une extension abandonnée échange un problème visible contre un problème de sécurité.