PHP 5.6 : c’est la version encore exécutée par l’ancien hébergement au moment de la reprise de ce dossier, un hébergement mutualisé souscrit en 2010 et jamais remis en question depuis. Dix ans plus tard, la base de données MySQL elle-même tournait dans une version dont plus personne ne connaissait le numéro exact avant d’aller vérifier.
La reprise d’un site ancien pose une question qui précède toute autre décision technique : où va-t-il désormais être hébergé ? Se contenter de migrer l’existant à l’identique reviendrait à reconduire les mêmes limites. Changer d’hébergement sans méthode conduit à des surprises au moment de la bascule. Voici la démarche suivie sur ce dossier, sous forme de liste de vérification.
Faire l’inventaire avant de choisir quoi que ce soit
Avant de comparer des offres d’hébergement, il faut savoir précisément ce que l’ancien environnement fait tourner. Cet inventaire, souvent négligé, évite de découvrir après coup qu’une fonctionnalité dépendait d’une extension serveur non standard.
- Version de PHP réellement utilisée, et extensions activées (
phpinfo()ouwp-clile confirment) - Version de MySQL ou MariaDB, et taille réelle de la base de données
- Présence de règles particulières dans le
.htaccessou la configuration Apache - Tâches cron externes éventuellement configurées chez l’ancien hébergeur
Définir des critères de choix propres à une reprise
Le choix d’un hébergement pour un site neuf et celui pour une reprise ne répondent pas aux mêmes critères. Sur un projet neuf, on optimise directement pour la cible finale. Sur une reprise, il faut aussi un environnement capable d’accueillir temporairement l’existant, le temps d’un audit et d’une remise à niveau progressive.
Les critères retenus
- Prise en charge de plusieurs versions de PHP simultanément, pour tester la compatibilité sans tout casser d’un coup
- Accès SSH complet, indispensable pour utiliser WP-CLI lors de l’audit
- Sauvegardes automatiques incluses, en plus d’une sauvegarde manuelle avant toute opération
- Un environnement de recette séparé, ou au minimum un sous-domaine dédié aux tests
Pourquoi un hébergement mutualisé bas de gamme ne convient plus
L’ancien hébergement, une offre mutualisée d’entrée de gamme figée sur PHP 5.6 et sans accès SSH, ne permettait tout simplement pas de mener un audit sérieux. Impossible d’exécuter WP-CLI, impossible de tester une montée de version PHP sans affecter directement la production, impossible même de consulter les journaux d’erreurs au-delà d’une interface web limitée.
Le nouvel hébergement retenu propose un accès SSH complet, la possibilité de basculer entre PHP 7.3 et PHP 7.4 par simple sélection dans le tableau de bord, et un environnement de préproduction inclus dans l’offre. Le coût mensuel est supérieur à l’ancien contrat, mais reste raisonnable au regard du temps gagné sur l’audit.
Sur une reprise, l’hébergement n’est pas un détail logistique à régler après coup : c’est l’outil qui permet ou empêche de faire l’audit correctement. Choisir un environnement trop rigide avant même d’avoir compris ce que contient le site revient à se priver de sa propre marge de manœuvre.
La phase de transition, pas à pas
La bascule ne s’est pas faite en un seul mouvement. Le site a d’abord été dupliqué tel quel sur le nouvel hébergement, en conservant PHP 5.6 pour vérifier que la migration pure ne cassait rien. Une fois cette étape validée, la version de PHP a été relevée progressivement, avec vérification des journaux d’erreurs à chaque palier :
- Migration à l’identique sur le nouvel hébergement, PHP inchangé
- Passage à PHP 7.2, avec correction des avertissements de dépréciation identifiés
- Passage à PHP 7.4, la version stable la plus récente à cette date
- Bascule DNS finale une fois les tests de non-régression validés
Checklist à conserver pour la prochaine reprise
Ce dossier a permis de figer une liste de vérification réutilisable pour toute future reprise de site ancien : inventaire technique complet avant de choisir un hébergeur, hébergement transitoire suffisamment souple pour tester plusieurs versions de PHP, sauvegarde systématique avant chaque palier de montée de version, et validation fonctionnelle avant toute bascule DNS définitive. Cette rigueur, appliquée en amont, évite très largement les mauvaises surprises qui surviennent d’ordinaire au pire moment.
