Boutique WooCommerce : préparer l’exigence PHP prévue en 2027

Le 29 septembre 2026, WooCommerce a annoncé que la version 11.6, prévue pour février 2027, exigera PHP 8.1 ou plus. L’annonce prévoit un avertissement en 11.3 pour PHP 7.4 et 8.0, puis 11.5 comme dernière version compatible avec ces branches. Le calendrier de l’éditeur donne du temps pour préparer le changement. Il ne transforme pas une ancienne version PHP en choix durable.

PHP exécute une partie du logiciel de la boutique sur l’hébergement. Le navigateur du client reçoit le résultat de ce travail : fiches, panier ou messages. Lorsque la version PHP change, certains composants peuvent rencontrer des incompatibilités, même si la page d’accueil continue à fonctionner. La préparation porte donc sur la boutique et ses dépendances, pas seulement sur un réglage de serveur.

Le seuil de compatibilité ne décrit pas le support de sécurité

Le minimum annoncé indique ce que WooCommerce 11.6 acceptera. Le support PHP indique si sa branche reçoit encore des corrections du projet PHP. Ces deux critères doivent être rapprochés : PHP 8.1 satisfait le futur minimum, mais son support de sécurité a pris fin le 31 décembre 2025 selon la liste officielle des branches abandonnées.

WooCommerce recommande PHP 8.3 ou plus lorsque les composants du site le permettent. La page des versions PHP maintenues permet de vérifier le calendrier de la branche envisagée. Choisissez avec l’hébergeur une version compatible et maintenue, en tenant compte du temps pendant lequel vous souhaitez l’utiliser. Une préversion disponible pour les essais n’a pas le même statut qu’une version stable.

Le schéma conserve le calendrier annoncé pour WooCommerce. Il montre une exigence minimale et une recommandation ; il ne constitue pas un classement des versions PHP par sécurité ni une preuve que votre boutique a été testée. Cette distinction évite de prendre la marche « PHP 8.1 » comme une destination suffisante pour plusieurs années.

Faire apparaître le composant qui peut bloquer

Demandez la version effectivement utilisée par le site. Celle proposée dans le catalogue de l’hébergeur peut être différente. Relevez ensuite les extensions, le thème et les fonctions particulières : paiement, livraison, documents, abonnements ou synchronisation avec une autre application. Pour chacune, identifiez le fournisseur et la compatibilité annoncée avec la version cible.

Dans un scénario hypothétique, les pages de vente et le paiement passent les essais, mais une génération de document ne fonctionne plus. Cette tâche n’avait pas été incluse dans la première revue. L’entreprise doit alors corriger ou remplacer le composant concerné avant de généraliser. Le cas illustre l’intérêt d’un inventaire fondé sur le travail réel ; il ne décrit pas un résultat constaté par Gaia.

• Avant l’essai : conservez un état de départ et identifiez la personne capable de modifier puis restaurer l’environnement.
• Sur la copie : vérifiez les calculs, les options, le paiement de test, les confirmations et la gestion des commandes.
• Après un cycle représentatif : examinez les tâches différées, les documents et les échanges avec les outils externes.

Une tâche différée se déclenche après la visite : envoi programmé, synchronisation ou autre opération récurrente. Une courte navigation ne prouve pas qu’elle fonctionne. Faites définir une durée d’observation compatible avec les tâches de votre boutique et examinez les erreurs avec son responsable. Les données de test doivent rester séparées des clients et des transactions réels.

Préparer le passage sans effacer l’activité récente

Choisissez un créneau avec l’équipe et confirmez la sauvegarde ainsi que le scénario de retour. Revenir à l’ancienne version PHP et restaurer des données sont deux opérations différentes. Si une restauration devient nécessaire, elle doit prendre en compte les commandes reçues après la copie. Le plan doit préciser qui rapproche ces transactions et comment éviter un double traitement.

Après le changement, relevez la version active et répétez les contrôles essentiels. Gardez les anomalies ouvertes avec un responsable et une prochaine vérification. Reporter temporairement une évolution peut être nécessaire pour résoudre une dépendance ; l’annonce WooCommerce ne présente pas ce report comme une stratégie de maintien indéfini des anciennes branches.