WooCommerce envisage PHP 8.1 comme minimum : ce qui est proposé
Le 8 septembre 2026, l'équipe d'ingénierie de WooCommerce a publié sur son blog développeur une proposition : relever la version minimale de PHP à 8.1, à partir de WooCommerce 11.5, alors visée pour janvier 2027. Un commentaire du 29 septembre évoque un décalage vers WooCommerce 11.6. Il s'agit d'une proposition soumise à discussion, pas d'une décision publiée : la version cible, le calendrier et même le principe peuvent encore évoluer. Aucune date de bascule ferme n'est annoncée à ce stade, et cet article n'en invente pas.
Pourquoi s'en préoccuper quand rien n'est acté ? Parce que la documentation WooCommerce indique aujourd'hui que la boutique fonctionne avec PHP 7.4 et supérieur, et recommande PHP 8.3 ou plus. L'écart entre ce minimum et cette recommandation est large, et c'est dans cet écart que vivent beaucoup de boutiques clients. La proposition a au moins un mérite : elle force la question qu'une agence devrait de toute façon se poser, à savoir quelle version de PHP tourne sur chaque boutique, et qui décide de la changer.
Ce que deviendrait une boutique restée en PHP 7.4 ou 8.0
D'après le billet, WordPress cesserait, par défaut, de proposer la mise à jour de WooCommerce aux boutiques qui ne remplissent pas la nouvelle exigence. Ces boutiques resteraient sur leur version actuelle et continueraient de recevoir les versions correctives de leur branche. Le billet précise aussi que la version de PHP ne serait pas changée à la place du propriétaire, et que les installations existantes ne seraient pas désactivées.
Le risque pour une agence n'est donc pas la panne brutale, mais le silence : une boutique qui ne reçoit plus les nouvelles versions, sans alerte, jusqu'au jour où le client réclame une fonction ou qu'une extension exige elle-même une version récente. Rien ne rougit, personne n'est prévenu. D'où l'intérêt de dresser l'état des lieux avant, plutôt que de le découvrir sous la pression d'une demande client.
Pourquoi préparer dès maintenant, même si le changement est reporté ou abandonné
- PHP 7.4 est déjà hors support — la documentation WooCommerce rappelle que PHP 7.4 a atteint sa fin de vie en novembre 2022, et PHP 8.0 a lui aussi quitté le support de sécurité. Rester dessus est un risque indépendant de WooCommerce.
- La recommandation officielle dépasse le minimum — WooCommerce recommande PHP 8.3 ou plus. Viser seulement 8.1 revient à préparer une migration de plus à court terme.
- Un échantillon n'est pas votre portefeuille — le billet situe à environ 7 % les boutiques suivies sous PHP 7.4 et à environ 2 % sous PHP 8.0, mais ce suivi est volontaire (opt-in) : c'est un ordre de grandeur, pas un recensement. Les sites repris d'un ancien prestataire sont souvent plus en retard que la moyenne.
- Les extensions décident souvent avant WooCommerce — le billet le dit lui-même : relever le minimum ne garantit pas que chaque extension, thème ou extrait de code fonctionnera. Le test sur copie reste indispensable.
- Un calendrier choisi vaut mieux qu'un calendrier subi — étaler les migrations site par site, hors période de forte vente, coûte moins cher qu'une série d'urgences.
- Le client voit l'agence, pas la plateforme — si une boutique reste figée sur sa branche, c'est vers vous qu'il se tournera. Autant l'avoir annoncé.
Premier geste : connaître la version PHP de chaque boutique
La méthode générale d'inventaire d'un parc est décrite dans l'article sur l'inventaire des versions PHP ; on ne la répète pas ici. Pour une boutique WooCommerce, trois informations suffisent d'abord : la version de PHP, la version de WooCommerce et l'état des extensions.
La source la plus fiable est la page WooCommerce > État, section « Environnement du serveur », ligne « Version de PHP » : c'est celle que la documentation WooCommerce indique pour contrôler le minimum. En SSH, wp --info affiche la version de PHP utilisée par WP-CLI, et wp eval 'echo PHP_VERSION;' celle que WordPress exécute réellement. Méfiez-vous : en ligne de commande, le binaire PHP peut différer de celui du serveur web, donc en cas d'écart, c'est la page État qui fait foi. Dans cPanel, la version est choisie par domaine, comme l'explique le guide pour changer la version PHP d'un site.
Reportez le résultat dans un tableau : boutique, version de PHP, version de WooCommerce, extensions bloquantes, statut, date prévue de bascule. Traitez d'abord les boutiques sous PHP 7.4 et 8.0, puis les autres.
Migrer une boutique vers une version PHP plus récente, sans casser le paiement
Sauvegarder et noter le point de départ
Sauvegardez les fichiers et la base de données, puis vérifiez que la sauvegarde se restaure. Notez la version de PHP actuelle du domaine : c'est votre retour arrière.
Lister les extensions et le thème
wp plugin list --fields=name,status,version,updatedonne l'inventaire. Pour chaque extension et pour le thème, relevez la compatibilité PHP déclarée par l'éditeur (champ « Requires PHP » ou notes de version). Mettez à jour d'abord ce qui peut l'être sous la version PHP actuelle.Créer une copie de test
Même version de WooCommerce, mêmes extensions, base copiée. Passez la passerelle de paiement en mode test ou bac à sable, et coupez les envois d'e-mails vers de vrais clients.
Changer la version de PHP sur la copie
Visez la version recommandée par WooCommerce si toutes les extensions la supportent, sinon la plus haute qu'elles acceptent. Sur la copie uniquement, activez
define( 'WP_DEBUG_LOG', true );pour lire les erreurs sans les afficher aux visiteurs.Rejouer le tunnel de commande
Parcourez les points de contrôle du tableau ci-dessous, du panier à la confirmation, y compris un remboursement. Corrigez ou remplacez toute extension en échec avant d'aller plus loin.
Basculer la production
Choisissez un créneau calme, prévenez le client, changez la version de PHP du domaine, videz les caches (page, objet, opcode) puis relisez WooCommerce > État pour confirmer la version effective.
Surveiller et garder le retour arrière
Les jours suivants, surveillez le journal d'erreurs, les commandes reçues, les e-mails et les actions planifiées. Gardez la version précédente sous la main tant que la boutique n'a pas traversé un cycle complet de commandes.
Les points de contrôle propres à une boutique
Faites défiler le tableau
| Point de contrôle | Ce qui peut casser | Comment le vérifier |
|---|---|---|
| Passerelles de paiement | Module incompatible avec la nouvelle version : paiement refusé ou page blanche à la validation | Commande de test en bac à sable de la passerelle, du panier à la confirmation |
| Webhooks | Notifications de paiement non reçues ou rejetées, commandes qui restent « en attente » | Journal des livraisons côté passerelle, puis statut de la commande de test |
| Tâches planifiées | Actions récurrentes en échec : relances, synchronisations, abonnements | WooCommerce > État > Actions planifiées, liste des échecs ; `wp cron event list` |
| E-mails de commande | Confirmation client ou notification boutique absente ou mal formée | Commande de test, puis réception des deux messages |
| Extensions touchant aux commandes | Fonction personnalisée qui lit ou modifie les commandes et plante | Créer, modifier, rembourser une commande de test ; relire la compatibilité déclarée de chaque extension |
| Tunnel complet | Erreur fatale sur une étape rarement testée (code promo, livraison, compte client) | Parcours complet avec code promo, deux modes de livraison et un compte neuf |
Qui porte quoi : l'agence, le client, l'hébergement
L'agence garde la relation avec le client et le calendrier : c'est elle qui annonce la fenêtre de maintenance, arbitre les extensions à remplacer et valide la reprise. L'hébergement tient l'infrastructure : versions de PHP disponibles, choix de la version site par site, comptes cPanel isolés pour qu'une bascule sur une boutique ne touche pas les autres. Sur ServOrbit, la version de PHP se choisit par domaine ; une migration assistée et l'administration peuvent s'ajouter en option, elles ne sont pas incluses d'office.
Une règle simple évite les malentendus : écrire, avant de toucher à quoi que ce soit, qui répond de quoi. Extensions payantes du client, thème sur mesure, hébergement, passerelle de paiement : chacun a un propriétaire, et la migration PHP n'efface pas ces frontières.
Ordre de passage conseillé
Rodez la procédure sur une boutique peu critique du portefeuille, puis traitez celles qui sont sous PHP 7.4 et 8.0, puis les plus actives, jamais pendant une période de forte vente. Chronométrez chaque migration : ce temps est la base d'un devis honnête pour les suivantes.
Dépannage : ce qui casse le plus souvent après le changement
Après une bascule, les mêmes symptômes reviennent d'une boutique à l'autre. Voici les cinq plus fréquents, avec leur premier geste.
Les cinq symptômes à connaître
- « Il y a eu une erreur critique sur ce site » — message de WordPress quand une extension ou le thème déclenche une erreur fatale sous la nouvelle version. Remède : remettre la version de PHP précédente dans cPanel, puis lire le journal d'erreurs de la copie pour identifier l'extension, la mettre à jour ou la remplacer.
- Commandes bloquées « en attente de paiement » — la notification de la passerelle n'arrive plus ou est rejetée. Remède : retour arrière, puis contrôle du journal des webhooks côté passerelle et de la compatibilité PHP déclarée du module.
- Écran blanc au passage en caisse — souvent une extension de paiement ou de livraison. Remède : retour arrière, puis désactivation des extensions une par une sur la copie jusqu'à trouver la fautive.
- E-mails de commande absents — le test d'envoi n'a pas été rejoué après la bascule. Remède : commande de test, lecture du journal de messagerie, vérification de l'extension d'envoi.
- Actions planifiées en échec — des tâches récurrentes qui plantaient en silence sous l'ancienne version se révèlent, ou l'inverse. Remède : ouvrir la liste des actions en échec, lire le message, mettre à jour l'extension concernée.
Et si le changement est reporté ou abandonné ?
Le plan reste utile. PHP 7.4 et 8.0 sont déjà hors support de sécurité, la recommandation officielle est plus haute que 8.1, et l'inventaire que vous venez de dresser sert aussi pour la prochaine échéance, par exemple la checklist de migration à la fin de vie d'une branche PHP ou le calendrier des fins de vie d'hébergement.
Surveillez le billet développeur de WooCommerce et sa documentation : c'est là que la décision, si elle est prise, sera publiée avec sa version et sa date. D'ici là, mieux vaut avoir une liste à jour et une procédure rodée que découvrir le sujet le jour où une boutique ne se met plus à jour.
