Le 30 novembre 2020, PHP 7.2 perd définitivement tout support de sécurité officiel. Passé cette date, plus aucune faille découverte sur cette version ne sera corrigée, ce qui expose tout site encore hébergé dessus à un risque croissant à mesure que le temps passe. Pour une association qui gère elle-même son site WordPress, sans équipe technique dédiée, cette migration demande une méthode simple et sans improvisation.
L’enjeu n’est pas seulement la date limite : c’est la compatibilité du site avec la version cible, PHP 7.4, qui doit être vérifiée avant la bascule, faute de quoi le site associatif peut se retrouver en page blanche le jour même du changement de version chez l’hébergeur mutualisé.
Étape 1 : recenser ce qui tourne sur le site
Avant toute chose, il faut établir la liste complète des extensions actives et du thème utilisé. Sur un mutualisé sans accès WP-CLI, cette liste se récupère simplement dans le back-office, sous Extensions, en notant le nom et la version de chacune. Si un accès SSH est disponible, la commande suivante accélère la tâche :
wp plugin list --status=active --fields=name,version
wp theme list --status=active --fields=name,version
Cette liste sert de base pour l’étape suivante : vérifier, extension par extension, la compatibilité annoncée avec PHP 7.4 sur la page du plugin sur WordPress.org ou dans son changelog.
Étape 2 : identifier les extensions à risque
Certaines extensions anciennes, peu maintenues ou abandonnées, utilisent des fonctions PHP dépréciées entre la version 7.2 et la 7.4, notamment autour du typage des arguments de fonction et de certaines fonctions de tableau. Un signe qui doit alerter : une extension dont la dernière mise à jour date de plus de deux ans n’a probablement jamais été testée sur PHP 7.4 par son auteur.
- Vérifier la mention « Testé jusqu’à la version » sur la fiche WordPress.org de chaque extension
- Repérer les extensions sans mise à jour depuis plus de 18 mois, candidates au remplacement
- Noter les extensions de paiement ou d’adhésion en ligne, souvent les plus sensibles à une casse silencieuse
Étape 3 : activer WP_DEBUG sur une copie de test
La méthode la plus fiable pour une association sans compétence technique poussée reste de demander à l’hébergeur mutualisé un environnement de test, souvent proposé sous forme de sous-domaine ou de compte secondaire, avec PHP 7.4 déjà activé. Une copie complète du site (fichiers et base de données) y est déployée, puis testée avec le débogage activé le temps du test uniquement, jamais en production :
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
Le fichier wp-content/debug.log généré permet ensuite de repérer les avertissements et erreurs fatales liés à la nouvelle version de PHP, sans les afficher aux visiteurs du site de test.
Étape 4 : parcourir les parcours critiques
Une fois le site de test en ligne sous PHP 7.4, il faut parcourir manuellement les fonctionnalités essentielles à l’association : formulaire d’adhésion, page de don en ligne si elle existe, espace membre, envoi d’e-mails automatiques. Ces parcours sont souvent ceux qui utilisent le plus d’extensions tierces, donc les plus exposés à une incompatibilité.
Un conseil qui évite bien des déconvenues : tester le formulaire de don en ligne en conditions réelles, avec une transaction de test à faible montant, avant toute bascule en production. C’est souvent le parcours le plus critique et le moins visité lors des tests rapides.
Étape 5 : planifier la bascule
Une fois les tests concluants, la bascule elle-même se fait généralement depuis le panneau de contrôle de l’hébergeur mutualisé (cPanel ou équivalent), en changeant la version PHP sélectionnée pour le compte. Il est recommandé de planifier cette opération en dehors des heures de forte fréquentation du site, et de garder sous la main les identifiants de l’environnement de test au cas où un retour arrière serait nécessaire dans les minutes qui suivent.
Après bascule, un contrôle rapide du site en production, avec les mêmes parcours testés en amont, confirme que tout fonctionne comme prévu avant de considérer la migration terminée.
En résumé
Migrer un site associatif de PHP 7.2 vers PHP 7.4 avant la fin du support de sécurité ne demande pas de compétence de développeur, mais une méthode rigoureuse : recenser les extensions actives, vérifier leur compatibilité annoncée, tester sur une copie du site avant toute bascule en production, et parcourir les fonctionnalités critiques comme les dons en ligne. Cette approche, réplicable pour chaque montée de version future, évite qu’une association découvre une page blanche le jour où l’hébergeur retire définitivement l’ancienne version de PHP.
