Module 7 · 7.2

Français

Nederlands English Deutsch Français Español

Ce qu’une boutique exige de son hébergement

Module 7: Visibilité et hébergement · Temps de lecture : 10 minutes

Objectif pédagogique : À l’issue de cette leçon, vous saurez évaluer si une offre d’hébergement convient à une boutique WooCommerce, vérifier et ajuster les principaux paramètres PHP, et reconnaître le moment où votre offre devient trop petite.

Notions clés : recommandations serveur, version de PHP, limite de mémoire WordPress (WP_MEMORY_LIMIT), memory_limit, max_execution_time, max_input_vars, upload_max_filesize, base de données, cache d’objets, CPU, processus, 503, Resource Limit Is Reached, WooCommerce > État, évoluer

Une boutique est plus lourde qu’un site ordinaire

Un site WordPress ordinaire doté d’un cache de pages sert la plupart des visiteurs à partir de HTML enregistré. Une boutique ne peut le faire qu’à moitié (leçon 6.4) : le panier, la validation de commande et Mon compte sont générés à nouveau pour chaque visiteur, et dès qu’une personne ajoute un article à son panier, elle reçoit une session et le cache ne s’applique souvent plus pour elle. De plus :

chaque commande écrit dans la base de données (commande, lignes, adresses, stock, notes) ;
le prestataire de paiement signale via un webhook que le paiement a été effectué, et cette requête doit recevoir une réponse rapide ;
WooCommerce dispose d’actions planifiées qui s’exécutent en arrière-plan (leçon 7.3) ;
l’administration (commandes, rapports, modification des produits) est plus lourde que pour un blog.

Une boutique qui fonctionne parfaitement sur une petite offre avec dix commandes par jour peut se bloquer pendant des soldes avec des centaines de visiteurs simultanés. C’est pourquoi il est utile de savoir ce dont votre offre est capable.

Ce que WooCommerce recommande

WooCommerce publie des paramètres serveur recommandés (état en novembre 2026, pour la version 10.8 et ultérieures) :

Élément	Recommandation
WordPress	6.9 ou supérieur
PHP	8.3 ou supérieur (testé jusqu’à 8.4 inclus)
Base de données	MySQL 8.0 ou supérieur, ou MariaDB 10.6 ou supérieur
Limite de mémoire WordPress	256 Mo ou plus
HTTPS	obligatoire

Ce sont des recommandations, pas un minimum : l’extension elle-même demande PHP 7.4 pour s’installer. Mais une boutique sur une ancienne version de PHP est plus lente et ne reçoit plus de mises à jour de sécurité. La manière de passer en toute sécurité à une version plus récente de PHP est décrite dans la formation WordPress, leçon 8.4 ; la procédure est la même pour une boutique, mais vous testez avec un soin particulier la validation de commande et le paiement en préproduction (staging).

Où voir ce dont vous disposez actuellement ? Dans WooCommerce > État (État du système). Vous y trouvez, sous Environnement WordPress, notamment la limite de mémoire WordPress, et sous Environnement serveur la Version de PHP, les limites PHP et la version de la base de données. En cas de problème, un développeur ou le support d’une extension demande souvent ce rapport ; le bouton permettant d’obtenir le rapport système ("Get system report") vous permet de le copier.

Les paramètres PHP qui comptent

Quatre paramètres reviennent le plus souvent avec une boutique :

memory_limit (et WP_MEMORY_LIMIT) : la quantité de mémoire vive qu’une seule requête PHP peut utiliser. Une valeur trop faible provoque une page blanche ou le message "Allowed memory size exhausted", souvent lors de rapports, d’importations ou de la modification d’un grand produit variable. WooCommerce recommande une limite de mémoire WordPress de 256 Mo. WordPress utilise la valeur définie dans wp-config.php (WP_MEMORY_LIMIT), mais jamais plus que ce que PHP autorise lui-même.
max_execution_time : la durée maximale d’une requête. Une importation CSV ou l’exportation de mille commandes peut prendre plus de temps que la valeur par défaut. Mieux vaut importer en plusieurs parties plus petites que fixer une limite très élevée.
max_input_vars : le nombre de champs qu’un formulaire peut envoyer. Pour un produit variable comportant de nombreuses variations, ou pour un grand menu, l’administration envoie des centaines de champs. Si la limite est trop basse, les derniers champs sont ignorés sans avertissement : vous cliquez sur Mettre à jour, aucune erreur ne s’affiche, mais une partie de vos variations n’a pas été enregistrée. Si vous le constatez, augmentez la valeur (par exemple à 3000 ou 5000) ou créez moins de variations (leçon 3.2).
upload_max_filesize et post_max_size : la taille maximale d’un fichier envoyé. Important pour les photos de produits et pour les produits téléchargeables (leçon 3.3).

Chez la plupart des hébergeurs, vous modifiez ces valeurs dans le panneau de gestion. Chez WebOké, cela se fait dans DirectAdmin, dans les paramètres PHP de votre offre (voir KB 212 et KB 200) ; chez d’autres prestataires, le fonctionnement est similaire, parfois via un fichier .user.ini ou un écran php.ini. Modifiez une seule valeur à la fois et vérifiez dans WooCommerce > État qu’elle a bien été prise en compte.

Quand l’offre devient trop petite

Sur un hébergement mutualisé, chaque offre a ses limites : la quantité de CPU, de mémoire et le nombre de processus simultanés. Chez WebOké et d’autres hébergeurs utilisant CloudLinux, vous les voyez dans DirectAdmin, dans l’utilisation de votre offre. Si votre boutique les dépasse, les visiteurs reçoivent une erreur 503 ou un message comme "Resource Limit Is Reached". Pour une boutique, c’est particulièrement gênant : un client qui s’apprête à payer, ou un webhook du prestataire de paiement qui ne reçoit pas de réponse, si bien qu’une commande payée reste en "Attente paiement".

Avant de passer à une offre supérieure, identifiez d’abord ce qui provoque la charge. Les causes les plus fréquentes pour une boutique :

un cache de pages absent ou mal configuré (leçon 6.4) ;
des robots qui parcourent les filtres, les résultats de recherche ou les liens ?add-to-cart= ;
WP-Cron à chaque visite et une file d’attente d’actions planifiées saturée (leçon 7.3) ;
des extensions lourdes ou un thème qui effectue de nombreuses requêtes en base de données sur chaque page ;
l’absence de cache d’objets (Redis) avec de nombreux clients connectés (leçon 6.4).

Pour trouver la cause, vous disposez de l’aperçu d’utilisation de votre offre, des journaux et, chez certains hébergeurs, d’un outil comme PHP X-Ray qui montre page par page quelle fonction est lente (KB 227).

Si la boutique est bien configurée et que vous atteignez malgré tout les limites, il est alors justifié d’évoluer : une offre plus grande, ou un serveur dédié (VPS) sur lequel vous décidez vous-même du nombre de processus PHP autorisés. Cette étape demande aussi davantage de gestion. Ne la planifiez pas au milieu de votre semaine la plus chargée ; testez d’abord sur le nouvel emplacement (leçon 7.3).

Ce qu’il faut encore pour une boutique

Au-delà de PHP, une boutique demande à son hébergement :

HTTPS avec renouvellement automatique du certificat (formation WordPress, leçon 3.1) ;
des sauvegardes suffisamment fréquentes pour vos commandes, avec un test de restauration (leçon 6.2) ;
un vrai cron pour les tâches planifiées (leçon 7.3) ;
une messagerie fiable ou une connexion à un service d’envoi d’e-mails (leçon 6.1) ;
une possibilité de staging (préproduction) (leçon 7.3) ;
une base de données suffisamment grande : les commandes et les actions planifiées augmentent chaque jour.

Chez Theehuis Example, la boutique a démarré sur une offre d’hébergement ordinaire. Après une newsletter proposant une réduction, le trafic reçu en une heure a dépassé celui d’une semaine normale, et des paiements sont restés bloqués. Dans l’aperçu d’utilisation, le nombre maximal de processus était constamment atteint. La cause : le cache de pages avait été désactivé après une mise à jour du thème. Une fois le cache réactivé, l’opération suivante s’est déroulée sans erreur 503.

Résumé

Une boutique est plus lourde qu’un site ordinaire : pages dynamiques, écritures en base de données, webhooks et actions planifiées.
WooCommerce recommande PHP 8.3+, MySQL 8.0+ ou MariaDB 10.6+, une limite de mémoire de 256 Mo et HTTPS ; vous voyez vos valeurs dans WooCommerce > État.
Surveillez memory_limit, max_execution_time, max_input_vars (perte silencieuse de données avec de nombreuses variations) et les limites d’envoi de fichiers.
Une erreur 503 ou Resource Limit Is Reached signifie que les limites de votre offre sont atteintes ; cherchez d’abord la cause, puis évoluez.

Quiz

Exercice

Exercice A7.2 : Votre version de PHP convient-elle à WooCommerce ? Ouvrez WooCommerce > État et notez la Version de PHP (Environnement serveur) et la limite de mémoire WordPress en Mo (Environnement WordPress). Saisissez l’adresse de votre boutique et ces deux valeurs. Le programme recherche la branche de votre version de PHP dans le tableau de php.net (quelles versions reçoivent encore des mises à jour) et vérifie si la page d’accueil affiche un en-tête X-Powered-By avec une version de PHP. Vert si votre branche est encore activement prise en charge et au moins égale à 8.3, et si la limite de mémoire est d’au moins 256. Orange si votre branche ne reçoit plus que des mises à jour de sécurité, si elle est inférieure à 8.3 tout en étant encore prise en charge, si la limite de mémoire se situe entre 128 et 255, ou si votre site affiche la version de PHP dans un en-tête. Rouge si votre branche ne reçoit plus de mises à jour ou est inconnue, si la limite de mémoire est inférieure à 128, ou si l’en-tête affiche une autre branche que celle que vous avez saisie ("plusieurs versions de PHP sont-elles installées ?").

Question pour vous-même (non corrigée) : qu’indique WooCommerce > État pour max_input_vars et pour la taille maximale d’envoi de fichiers ? Est-ce suffisant pour votre plus grand produit et votre plus gros téléchargement ?

Pour aller plus loin

Ces articles décrivent les étapes dans les panneaux de WebOké ; dans d’autres panneaux, le fonctionnement est similaire.

Cookies sur WebOké

Paramètres des cookies

Nécessaires

Marketing