Mis à jour le 1er novembre 2026. Article réécrit : prérequis officiels de WordPress et PrestaShop comparés, valeurs par défaut d’OPcache et d’InnoDB, calendrier des versions de PHP, choix d’hébergement et rôle réel de l’IA. Il regroupe désormais nos articles sur l’IA et les serveurs web pour PrestaShop et WordPress, l’architecture serveur WordPress et PrestaShop, l’« hébergement IA » et les serveurs qui s’optimisent seuls.
WordPress et PrestaShop reposent sur la même pile : un serveur web, PHP, une base MySQL ou MariaDB, des caches. Ils ne la sollicitent pas de la même façon. Un blog sert surtout des pages identiques à des visiteurs anonymes ; une boutique traite des paniers, des sessions et des prix qui ne se mettent pas en cache. La performance serveur d’un CMS se joue donc sur quelques réglages précis, avant toute promesse d’automatisation.
Cet article traite les leviers communs et le rôle réel de l’IA. Le diagnostic d’une boutique saturée est détaillé dans notre guide du serveur PrestaShop surchargé, la supervision et l’auto-scaling dans notre guide de monitoring serveur.
Deux CMS, deux profils de charge
| Élément | WordPress | PrestaShop 9 |
|---|---|---|
| PHP recommandé | 8.3 ou plus récent | 8.1 à 8.5 pour la 9.1, 8.5 recommandé |
| Base de données recommandée | MariaDB 10.11+ ou MySQL 8.0+ | MySQL 5.7+ ou MariaDB 10.2+, version récente conseillée |
| Mémoire PHP | Selon extensions | memory_limit de 512 Mo minimum recommandé |
| Cache objet | Fichier object-cache.php (Redis, Memcached) | Natif : Memcached, APC, Xcache ; Redis par module |
| Cache de pages | Efficace pour les visiteurs anonymes | Limité aux pages sans panier ni connexion |
| Tâches planifiées | WP-Cron, déclenché par les visites | Tâches cron des modules |
Depuis WordPress 6.1, l’outil Santé du site signale en production l’absence de cache objet persistant quand il serait utile. Côté PrestaShop 9.2, le code ne propose nativement que Memcached, APC et Xcache. Pour les tâches planifiées, WordPress exécute WP-Cron lors des chargements de pages. La documentation recommande de le désactiver par define( 'DISABLE_WP_CRON', true ); dans wp-config.php, puis de confier wp-cron.php au planificateur du système.
OPcache : vérifier plutôt que copier
OPcache garde le code PHP compilé en mémoire partagée. Une fois l’extension chargée, il est actif par défaut, mais ses réglages par défaut sont modestes : 128 Mo de mémoire, 10 000 scripts au maximum, vérification des fichiers modifiés toutes les 2 secondes. Depuis PHP 8.4, le JIT est désactivé par défaut. Un PrestaShop avec ses dépendances, ou un WordPress chargé d’extensions, peut dépasser la limite de scripts.
opcache.enable=1
opcache.memory_consumption=256
opcache.max_accelerated_files=20000
opcache.validate_timestamps=0Avec validate_timestamps=0, PHP ignore les fichiers modifiés jusqu’au rechargement de PHP-FPM. Intégrez ce rechargement à chaque mise à jour du cœur, d’un thème ou d’un module, sinon le site exécute l’ancien code. Vérifiez le taux de remplissage avec opcache_get_status() dans une page réservée à l’administrateur : la configuration en ligne de commande peut différer de celle de PHP-FPM.
PHP : version et réglages par site
| Branche PHP | Support actif jusqu’au | Sécurité jusqu’au |
|---|---|---|
| 8.2 | 31 décembre 2024 | 31 décembre 2026 |
| 8.3 | 31 décembre 2025 | 31 décembre 2027 |
| 8.4 | 31 décembre 2026 | 31 décembre 2028 |
| 8.5 | 31 décembre 2027 | 31 décembre 2029 |
Un site en PHP 8.2 doit migrer avant la fin de 2026. Les failles critiques corrigées le 21 octobre 2026 rappellent qu’une version à jour fait partie de la performance : un serveur compromis consomme des ressources à votre insu. Voir notre article sur la faille PHP2Shell.
Sur un hébergement où PHP tourne en FastCGI ou PHP-FPM, php_value dans .htaccess provoque souvent une erreur 500. Utilisez un fichier .user.ini, lu uniquement par les SAPI CGI et FastCGI et relu toutes les 300 secondes par défaut :
memory_limit = 512M
max_execution_time = 60Seules les directives modifiables par répertoire y sont prises en compte. Les réglages du pool PHP-FPM restent hors de portée sur un mutualisé.
La base de données : buffer pool et requêtes
Avec InnoDB, les données et index les plus lus restent dans le buffer pool. Sa taille par défaut est de 128 Mo, souvent trop peu pour une boutique, et MySQL permet de la modifier à chaud par SET GLOBAL.
SHOW VARIABLES LIKE 'innodb_buffer_pool_size';
SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_read%';Innodb_buffer_pool_read_requests compte les lectures logiques, Innodb_buffer_pool_reads celles qui ont dû aller sur le disque. Ces compteurs cumulent depuis le démarrage : comparez leur progression pendant une période chargée. Si les lectures disque montent vite, le buffer pool est trop petit. Ne lui donnez pas toute la mémoire : PHP-FPM et le système en ont besoin. Le journal des requêtes lentes et EXPLAIN sont décrits dans notre guide PrestaShop surchargé.
Mémoire, processeur et disque
free -h
vmstat 1 5
iostat -dx 1 5
sudo dmesg | grep -i "out of memory"La colonne available de free estime la mémoire disponible sans swap. dmesg révèle si le noyau a tué un processus ; si c’est mysqld, le site tombe. Dans vmstat, wa mesure l’attente disque, si et so les échanges avec le swap. Pour iostat (paquet sysstat), ne concluez pas sur %util seul : un SSD traite plusieurs requêtes en parallèle et peut afficher une valeur haute en répondant bien. await est plus parlant.
Cache de pages et page de connexion
Le cache de pages (Nginx FastCGI, Varnish, CDN ou extension) soulage PHP sur les contenus publics. Pour WordPress, contournez-le dès que le cookie wordpress_logged_in_ ou un cookie comment_author_ est présent, ainsi que pour wp-admin. Pour PrestaShop, la présence du cookie PrestaShop- impose le contournement. Un cache mal réglé peut montrer à un visiteur les données d’un autre : c’est un incident de sécurité.
La page wp-login.php attire les tentatives de connexion automatisées, qui occupent PHP. Une limite de débit par adresse IP les contient :
# Bloc http
limit_req_zone $binary_remote_addr zone=wplogin:10m rate=5r/m;
# Bloc server
location = /wp-login.php {
limit_req zone=wplogin burst=3 nodelay;
limit_req_status 429;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_pass unix:/run/php/php8.4-fpm.sock;
}5r/m autorise en moyenne une requête toutes les 12 secondes par adresse. Sans limit_req_status, Nginx répond 503. Ce bloc remplace le gestionnaire PHP pour cette URL : sans les lignes fastcgi_*, le fichier serait servi en texte brut. Adaptez le socket. Pour les autres protections, voir notre guide de défense d’un serveur web.
Choisir un hébergement à la mesure du site
- Mutualisé : suffisant pour un site vitrine ou un blog. Vous ne contrôlez ni le pool PHP-FPM ni l’installation d’un cache objet.
- VPS : premier palier pour une boutique en croissance, à condition d’assurer mises à jour et supervision.
- Dédié ou cloud : justifié par un trafic élevé ou des pics forts. Un cloud sans règles de mise à l’échelle peut coûter plus cher qu’un dédié bien dimensionné.
Séparez les rôles avant d’ajouter des ressources : serveur web et PHP, base de données, traitements asynchrones. Une requête de visiteur ne doit jamais attendre la réponse d’un modèle d’IA.
« Hébergement IA » ne correspond à aucune norme. Le terme recouvre surtout la supervision, la mise à l’échelle et le filtrage du trafic. Comparez plutôt les ressources garanties, les versions de PHP maintenues, le cache proposé, les sauvegardes et leur restauration, le support et le tarif de renouvellement. Notre comparatif des hébergeurs web 2026 applique ces critères.
Ce que l’IA automatise réellement
| Fonction | Ce qui existe | Ce qui reste humain |
|---|---|---|
| Détection d’anomalies | Modèles appris sur l’historique des métriques | Décider si l’écart est un incident |
| Synthèse de journaux | Regroupement d’erreurs, hypothèses classées | Vérifier avec EXPLAIN, un profileur, un test |
| Mise à l’échelle | Règles et seuils appliqués par la plateforme | Choisir la métrique, les seuils, le plafond |
| Filtrage du trafic | Scores de risque des pare-feu applicatifs | Liste blanche, déblocage, contrôle des faux positifs |
| Optimisation autonome | Promesses commerciales rarement documentées | Toute modification de base ou de configuration |
Netdata en donne un exemple documenté. Sa détection d’anomalies est active par défaut quand le stockage est en mode dbengine. Elle s’entraîne sur six heures de données, réentraîne toutes les trois heures et conserve 18 modèles par métrique, soit environ 54 heures. Elle signale un écart à l’habitude, pas une panne à venir : une campagne ou une mise à jour inédite produisent des alertes sans incident.
Un modèle de langage peut résumer un journal et proposer des causes. Limitez l’extrait à la période du problème, retirez adresses IP et identifiants, puis vérifiez chaque hypothèse. Il peut affirmer une cause fausse avec assurance, et un index ajouté sans test ralentit les écritures. Un modèle exécuté sur le serveur de production consomme les ressources que vous cherchez à libérer. Voir notre guide d’analyse des logs Nginx.
Mesurer avant et après
Chaque changement se juge sur les mêmes pages, avant et après. Côté serveur, suivez le TTFB et la file d’attente PHP-FPM. Côté visiteur, les Core Web Vitals ont pour seuils 2,5 secondes pour le LCP, 200 millisecondes pour l’INP et 0,1 pour le CLS ; l’INP a remplacé le FID le 12 mars 2024. Voir nos Core Web Vitals pour WordPress, pour PrestaShop, et le diagnostic d’un site lent.
Questions fréquentes
Un cache suffit-il à compenser un serveur sous-dimensionné ?
Non. Il réduit le travail de PHP et de MySQL, mais ne règle ni une mémoire insuffisante ni un disque saturé. Sur une boutique, le panier et la commande échappent au cache de pages.
Un hébergement présenté comme « IA » rend-il un site plus rapide ?
Pas automatiquement. Si la lenteur vient du thème, des extensions ou des requêtes, changer d’offre ne suffit pas. Mesurez le TTFB et les Core Web Vitals sur les mêmes pages, pendant la période d’essai.
L’IA peut-elle modifier seule la configuration de production ?
Certains outils le proposent. La pratique prudente reste la suggestion : l’outil propose, vous testez en préproduction, puis vous appliquez avec un retour arrière prévu.
Faut-il héberger un modèle d’IA sur le même serveur que le CMS ?
En général, non. Un modèle local consomme mémoire et processeur en continu. Placez-le sur une machine dédiée, ou appelez une API depuis une file d’attente.
Sources
- WordPress, Requirements : https://wordpress.org/about/requirements/
- WordPress, New cache Site Health checks in WordPress 6.1 : https://make.wordpress.org/core/2022/10/06/new-cache-site-health-checks-in-wordpress-6-1/
- WordPress, Hooking WP-Cron Into the System Task Scheduler : https://developer.wordpress.org/plugins/cron/hooking-wp-cron-into-the-system-task-scheduler/
- WordPress, Cookies : https://developer.wordpress.org/advanced-administration/wordpress/cookies/
- PrestaShop, System requirements (PrestaShop 9) : https://devdocs.prestashop-project.org/9/basics/installation/system-requirements/
- Code de PrestaShop 9.2.0, lu localement :
classes/cache/,CachingType.php,classes/Cookie.php. - PHP, OPcache runtime configuration : https://www.php.net/manual/en/opcache.configuration.php
- PHP, Supported versions : https://www.php.net/supported-versions.php
- PHP, .user.ini files : https://www.php.net/manual/en/configuration.file.per-user.php
- MySQL 8.4, Configuring InnoDB Buffer Pool Size : https://dev.mysql.com/doc/refman/8.4/en/innodb-buffer-pool-resize.html
- nginx, ngx_http_limit_req_module : https://nginx.org/en/docs/http/ngx_http_limit_req_module.html
- Netdata, ML Configuration : https://learn.netdata.cloud/docs/netdata-ai/anomaly-detection/ml-configuration
- Google, Web Vitals et INP becomes a Core Web Vital : https://web.dev/articles/vitals, https://web.dev/blog/inp-cwv-march-12
