# PHP 8.4 sur un hébergement WooCommerce : ce qui casse vraiment en production

> Trois catégories de messages reviennent systématiquement lors d'une montée vers PHP 8.4 sur des boutiques WooCommerce en production. Voici lesquelles, avec les extensions les plus souvent concernées.

- Auteur : Clément Hadrot
- Publié le : 2025-05-05
- Mis à jour le : 2025-05-05
- Catégorie : E-commerce
- URL : https://wpmoderne.dev.wordpress-developpement.fr/ecommerce/php84-hebergement-woocommerce-casse-production/

## L’essentiel

- Les typages implicitement nullables sont la cause la plus fréquente
- Les extensions de tarification personnalisées sont les plus exposées
- Un audit en amont évite un rollback en urgence

Trois catégories de messages suffisent à expliquer la quasi-totalité des incidents remontés après une montée vers PHP 8.4 sur des boutiques WooCommerce en production : les typages implicitement nullables, les fonctions internes appelées avec des arguments désormais incompatibles, et les extensions tierces qui n'ont simplement jamais été testées sur cette version.

PHP 8.4, sorti en novembre 2024, introduit des changements de langage significatifs (property hooks, visibilité asymétrique) qui n'ont, en pratique, presque aucun impact sur du code WooCommerce classique. Le vrai risque se situe ailleurs : dans les dépréciations renforcées qui deviennent visibles, parfois pour la première fois, sur du code écrit il y a plusieurs années.

## Catégorie 1 — Les paramètres implicitement nullables

PHP 8.4 marque comme dépréciée la déclaration implicite d'un paramètre nullable, c'est-à-dire une signature de fonction où une valeur par défaut `null` est fournie sans que le type soit explicitement marqué `?type`. Ce motif est extrêmement répandu dans les extensions WooCommerce écrites avant l'adoption généralisée des types stricts :

```
// Déclenche une dépréciation en PHP 8.4
function calculer_remise( WC_Product $produit, $regle = null ) { /* ... */ }

// Correction
function calculer_remise( WC_Product $produit, ?array $regle = null ) { /* ... */ }
```

Cette catégorie représente à elle seule la majorité des messages observés sur les extensions de tarification dynamique et les surcharges de méthodes de passerelle de paiement.

## Catégorie 2 — Fonctions internes et arguments non typés strictement

Certaines fonctions PHP internes utilisées couramment dans les templates WooCommerce (fonctions de manipulation de chaînes, de tableaux) deviennent plus strictes sur le typage de leurs arguments. Un appel avec une valeur `null` non explicitement gérée en amont — fréquent sur des champs personnalisés optionnels — remonte désormais un avertissement au lieu de passer silencieusement.

> L'essentiel à retenir : Les typages implicitement nullables sont la cause la plus fréquente ; Les extensions de tarification personnalisées sont les plus exposées ; Un audit en amont évite un rollback en urgence

## Catégorie 3 — Extensions jamais testées au-delà de PHP 8.1 ou 8.2

La dernière catégorie n'est pas un problème de langage mais de maintenance : certaines extensions premium, notamment des connecteurs de paiement ou de logistique moins actifs, n'annoncent une compatibilité testée qu'avec PHP 8.1 ou 8.2. Elles fonctionnent souvent malgré tout sur 8.4, mais sans garantie, et sans que l'éditeur ait vérifié l'absence d'appels à des fonctionnalités supprimées.

- Vérifiez la compatibilité annoncée dans la documentation de chaque extension active avant la montée de version.
- Sur un environnement de recette, activez `WP_DEBUG_LOG` et parcourez le tunnel d'achat complet, pas seulement la page d'accueil.
- Testez spécifiquement les extensions de paiement et de tarification, les plus exposées aux deux premières catégories.

## Méthode d'audit avant bascule en production

La démarche qui a le mieux fonctionné sur les projets suivis consiste à cloner l'environnement de production sur un conteneur PHP 8.4, exécuter un parcours d'achat complet (ajout au panier, application d'un coupon, passage en caisse, paiement en mode test), puis grep systématiquement les journaux à la recherche de `Deprecated` et `Warning` avant de considérer la montée comme validée.

> Sur nos projets, aucune montée de version PHP majeure ne part en production sans un parcours d'achat complet exécuté sur l'environnement cible, journaux à l'appui.

## Et si l'hébergeur impose la version avant que tout soit corrigé ?

Certains hébergeurs mutualisés forcent une migration groupée de leurs clients vers PHP 8.4 à une date fixe. Si le temps manque pour corriger chaque extension, une solution transitoire consiste à activer `error_reporting` avec un masque excluant temporairement `E_DEPRECATED` côté serveur — jamais côté code applicatif — le temps de traiter les corrections dans l'ordre de priorité, sans bloquer la boutique.

## En résumé

Une montée vers PHP 8.4 sur une boutique WooCommerce en production casse rarement le cœur du logiciel : elle révèle des habitudes de code datées, concentrées sur les typages nullables implicites et les extensions non maintenues. Un audit ciblé sur ces trois catégories, mené sur un environnement de recette avant bascule, évite l'essentiel des incidents.