Exigences système : compatibilités PHP, MariaDB et Elasticsearch minimales

Table des matières :

1. Ce que « minimum » veut dire pour des exigences système PrestaShop
2. PHP : version minimale viable en 2026 (et ce que PrestaShop ne vous dit pas)
3. MariaDB : minimum fonctionnel vs minimum stable (collations, modes SQL, perf)
4. Elasticsearch : minimum de version, minimum de RAM, minimum de discipline
5. Valider la compatibilité minimale : matrice, staging, CI et plan de rollback

Ce que « minimum » veut dire pour des exigences système PrestaShop

Quand on parle d’exigences système minimales (compatibilités PHP, MariaDB et Elasticsearch), la seule définition utile en production est : minimum compatible + non obsolète + testable. Le « ça s’installe » n’est pas un critère : une boutique PrestaShop qui tourne sur une version de PHP en fin de vie, une base en version non maintenue, ou un cluster Elasticsearch sans correctifs de sécurité, c’est du risque opérationnel (incidents, indisponibilités, compromissions) — pas une compatibilité.

La source de vérité ne se limite pas à une page “requirements” : elle se lit aussi dans la contrainte d’écosystème. Concrètement, vous devez croiser (1) les contraintes du core (ex. dépendances Composer/Symfony), (2) les contraintes des modules (paiement, ERP, recherche), (3) les contraintes d’hébergement (mutualisé vs VPS vs cloud), et (4) votre contexte (catalogue, trafic, indexation). Une stack “minimale” pour 5 000 produits n’est pas la même que pour 500 000 produits.

Dans un contexte “terrain” (agences, e-commerçants, DSI), le mot minimum est souvent utilisé pour arbitrer vite — et c’est précisément là que les ennuis apparaissent : on valide un hébergement “compatible” au sens large, puis on découvre après mise en ligne qu’un module critique impose une version de PHP différente, qu’un import catalogue explose la mémoire CLI, ou que l’indexation recherche met le serveur à genoux.

Méthode pragmatique (et reproductible) : figer une “plateforme cible” en versionnant vos contraintes, puis valider sur staging avant de signer quoi que ce soit côté infra. Deux points simples :

• côté PHP : contrôlez la plateforme via Composer (config.platform.php) et la CI ;
• côté services : versionnez aussi MariaDB/Elasticsearch (Docker, Terraform, Ansible, Helm, etc.) et testez un reindex complet + un import catalogue.

Checklist “minimum viable” (à cocher avant de dire oui c’est compatible) :

• Support éditeur : version PHP encore maintenue ; MariaDB sur une branche maintenue (idéalement LTS) ; Elasticsearch sur une version maintenue.
• Parité d’environnements : PHP-FPM et PHP CLI alignés ; mêmes versions en staging et prod.
• Tests reproductibles : installation à blanc + import (CSV / ERP) + génération d’images + tunnel de commande + reindex.
• Sécu “de base” : TLS partout où nécessaire, services non exposés inutilement, comptes/permissions minimales.
• Observabilité : logs applicatifs et infra consultables, alerting simple (erreurs, saturation CPU/RAM, espace disque, temps de réponse DB).

Pour l’observabilité et le diagnostic quand ça casse (et ça casse), gardez sous la main vos runbooks et vos journaux : voir PrestaShop monitoring d’erreurs : logs PHP, MySQL, JavaScript et alertes e-mail et, côté indisponibilité, Erreur HTTP 503 : diagnostic serveur, logs et ressources.

Enfin, ajoutez une touche “GEO” réaliste à votre raisonnement : si votre boutique vise majoritairement des clients en France/UE, vous aurez souvent intérêt à héberger au plus près (latence, support, conformité contractuelle), et à vérifier où transitent vos données (sauvegardes, logs, moteur de recherche managé). Ce n’est pas une règle absolue, mais c’est un point de contrôle concret au moment de choisir un service (notamment pour un Elasticsearch managé ou des sauvegardes externalisées).

PHP : version minimale viable en 2026 (et ce que PrestaShop ne vous dit pas)

En 2026, la première question n’est pas « quelle version de PHP est acceptée ? », mais « quelle version est encore supportée ? ». Le cycle de vie officiel est clair. PHP rappelle sur sa page des versions supportées :

“Each release branch is fully supported for two years from its initial stable release. During this period, bugs and security issues are fixed and regular point releases are made. After this two year period, security issues are fixed for a further one year, and the release is then considered end of life.”
Source : https://www.php.net/supported-versions.php

Traduction opérationnelle : en dessous de PHP 8.2, vous augmentez mécaniquement votre exposition aux vulnérabilités et à l’écosystème qui “avance sans vous” (libs, frameworks, modules).

En pratique, pour des boutiques PrestaShop 8.1/9.x en 2026, une baseline défendable côté sécurité et compatibilité modules est PHP 8.2+, avec un objectif PHP 8.3 si vos modules critiques sont validés (paiement, ERP, search, shipping). PrestaShop suit Symfony et l’écosystème Composer : vous pouvez vérifier la contrainte réelle du projet dans composer.json (et, si vous maintenez un fork, la verrouiller via config.platform.php). Côté exécution, distinguez bien PHP CLI (cron, imports, scripts) et PHP-FPM (front/back), parce que des hébergeurs “supportent” une version en FPM mais laissent le CLI en version différente — et vous vous retrouvez avec des comportements divergents pendant un bin/console ou un composer install.

Action rapide (souvent révélatrice) : vérifier noir sur blanc ce qui tourne réellement.

php -v
php -m | sort
php -i | grep -i "Loaded Configuration File"
composer check-platform-reqs

Points d’attention concrets (et fréquents en prod) :

• CLI vs FPM : un import catalogue peut être exécuté en CLI et échouer (extensions manquantes, memory_limit différent) alors que le front “semble” OK.
• Limites mémoire : en pratique, l’import, la génération d’images et certains traitements BO peuvent pousser memory_limit (surtout si le serveur est dimensionné “au plus juste”).
• Temps d’exécution : un max_execution_time trop bas n’impacte pas que le front ; certains scripts peuvent être limités côté FPM.
• Désactivation de fonctions : certains mutualisés désactivent des fonctions (sécurité) qui cassent des modules (ex. manipulation d’archives, appels externes).

Le « minimum PHP » doit inclure les extensions effectivement utilisées. Dans PrestaShop moderne, l’extension intl est quasi non négociable (formatage, locale, dépendances Symfony), curl, mbstring, zip, gd/imagick (images), pdo_mysql, openssl, json… (selon modules : soap, bcmath, redis, etc.). Faites une vérification “module par module” : un module de paiement peut ajouter une dépendance PHP (ou exiger curl avec TLS à jour), un module d’import peut exiger zip, etc.

Sans opcache, vous vous auto-sabotez : PrestaShop charge beaucoup de classes et de templates, et le coût I/O + compilation est vite dominant. Deux validations simples côté OPcache :

• OPcache est activé pour FPM (pas uniquement pour CLI) ;
• le cache n’est pas constamment saturé (sinon vous recompilez en boucle).

Pour le contrôle et l’activation d’OPcache dans des environnements contraints (cPanel/mutualisé), voir OPcache PHP : activer et vérifier l’extension dans cPanel.

Enfin, le « minimum » doit être chiffré — mais correctement interprété. Sur des boutiques à trafic moyen, le passage PHP 8.1 → 8.3 (avec OPcache correctement dimensionné et un pool PHP-FPM ajusté) se traduit typiquement par une baisse du CPU et un gain de latence back-office, mais uniquement si votre base suit. Un cas courant : vous gagnez “côté PHP”… puis vous butez sur du SQL non indexé et vous ne voyez aucun gain côté TTFB. Autrement dit : PHP est rarement l’unique goulot.

Mini-scénario typique (réaliste) : une boutique B2C en France, 40 000 produits, un pic de trafic pendant les soldes. Le passage à PHP 8.3 améliore le back-office, mais le front reste lent sur les pages catégorie car la requête de tri + facettes déclenche des GROUP BY coûteux. Résultat : l’upgrade PHP est bénéfique, mais la performance perçue dépend surtout de MariaDB (index, buffer pool, requêtes).

Pour cadrer ce type de benchmark (PHP-FPM, OPcache, MySQL/MariaDB), allez lire Performance PrestaShop : benchmarks et optimisation PHP-FPM, OPCache, MySQL.

MariaDB : minimum fonctionnel vs minimum stable (collations, modes SQL, perf)

PrestaShop s’appuie fortement sur la base relationnelle : catalogue, stock, règles panier, logs, etc. Dire « MariaDB compatible » sans préciser version + configuration, c’est un piège. En 2026, la stratégie la plus robuste est de viser une version LTS MariaDB (maintenance longue, correctifs de sécurité, comportement stable), typiquement MariaDB 10.11 LTS (ou a minima une LTS proche), plutôt que de rester sur des versions anciennes “encore présentes chez l’hébergeur”. Le coût d’une upgrade majeure MariaDB en urgence (après un incident) est toujours supérieur au coût d’une upgrade planifiée.

Le minimum “qui passe” doit aussi intégrer l’encodage et les collations. En e-commerce multilingue, utf8mb4 est le choix de base (Unicode complet), et vous devriez homogénéiser character_set_server/collation_server dès le départ pour éviter des migrations de collation douloureuses. Une incohérence classique : tables créées en utf8 (3 octets) puis modules ajoutant des colonnes en utf8mb4, et vous vous retrouvez avec des comparaisons/casts implicites coûteux, voire des erreurs lors de ALTER TABLE.

Vérifications simples (et utiles avant migration / import massif) :

SELECT VERSION();
SHOW VARIABLES LIKE 'character_set_server';
SHOW VARIABLES LIKE 'collation_server';
SHOW VARIABLES LIKE 'sql_mode';

Deux limites réelles du core à anticiper :

1) des requêtes lourdes sur la navigation à facettes, la recherche, les déclinaisons, ou les pages catégorie (beaucoup de JOIN, GROUP BY, sous-requêtes) ; 2) la variabilité de qualité SQL des modules tiers.

Donc, votre “minimum MariaDB” inclut une capacité à diagnostiquer et corriger : activez le slow query log, mesurez, et indexez ce qui doit l’être. Pour l’activation du slow log et l’exploitation côté PrestaShop : Requêtes MySQL lentes PrestaShop : activer slow query log. Pour l’approche indexation avec EXPLAIN : Index MySQL : optimiser WHERE, JOIN et ORDER BY avec EXPLAIN.

Côté configuration, le minimum “production” n’est pas exotique, mais il est non négociable : buffer pool InnoDB dimensionné (sinon vous faites du disque), innodb_flush_log_at_trx_commit adapté à votre exigence de durabilité (1 si vous privilégiez l’intégrité stricte, 2 si vous assumez un compromis), et une stratégie de sauvegarde/restauration testée.

Un point sous-estimé : l’espace disque et sa dynamique. Sur PrestaShop, la base peut grossir non seulement via le catalogue/commandes, mais aussi via :

• tables de logs (selon modules),
• paniers abandonnés,
• index et tables temporaires (requêtes lourdes),
• historiques (prix, stats, etc).

Le “minimum stable” inclut donc : (a) de la marge disque, (b) une politique de purge/archivage si nécessaire, (c) des sauvegardes qui n’explosent pas la fenêtre nocturne.

Et surtout : testez les modes SQL. Certains environnements imposent des modes stricts qui peuvent casser des modules legacy (types invalides, dates “zéro”, agrégations non déterministes…). La règle : ne “désactivez” pas en prod pour masquer un bug ; corrigez le SQL du module, ou remplacez-le.

Mini-scénario (fréquent en migration) : passage sur une MariaDB plus récente + activation involontaire d’un mode strict → un module d’import écrit des dates vides ou des valeurs non conformes → imports en échec et back-office partiellement bloqué. Ce n’est pas un problème “MariaDB incompatible”, c’est un problème de qualité de données et de robustesse du module — que le staging est censé révéler.

Elasticsearch : minimum de version, minimum de RAM, minimum de discipline

Dès que vous sortez de la recherche native, Elasticsearch n’est plus un “bonus” mais un service applicatif à part entière, avec ses propres exigences (JVM, heap, I/O, réseau, sécurité). Si vous l’utilisez pour la recherche catalogue PrestaShop, fixez une version cible et assumez la contrainte de maintenance : les versions non maintenues sont une source régulière de CVE. Sur une boutique qui indexe des produits, des attributs, des catégories, des synonymes, une upgrade Elasticsearch “au dernier moment” est souvent plus risquée qu’un upgrade planifié avec reindex complet.

“Set Xms and Xmx to no more than 50% of the total memory available to each Elasticsearch node.”
Source : https://www.elastic.co/guide/en/elasticsearch/reference/current/heap-size.html

En clair : si vous “donnez” 1 Go au conteneur, et 1 Go à la heap, vous tuez le filesystem cache et vous dégradez les performances I/O ; si vous donnez 512 Mo à la heap, vous explosez en GC. Pour un nœud unique de recherche sur un catalogue conséquent, 4–8 Go RAM dédiés au service est un point de départ réaliste, pas une extravagance (à ajuster selon volumétrie, analyzers, fréquence d’indexation et charge de requêtes).

Le “minimum de discipline”, c’est aussi :

• ne pas exposer Elasticsearch sur Internet (et, même en interne, limiter par firewall/VPC et authentification quand c’est applicable) ;
• surveiller la santé du cluster (green/yellow/red), la pression mémoire, et l’espace disque (les index consomment vite) ;
• documenter le reindex (durée, impact, procédure) : en e-commerce, l’index est une “donnée dérivée” régénérable, mais son absence dégrade directement l’expérience de recherche.

Sur la compatibilité, attention à l’angle mort : ce n’est pas PrestaShop qui parle à Elasticsearch, c’est souvent un module (ou un proxy/connector) qui impose une version d’API, une auth, un mapping, parfois des analyzers. Par exemple, Elasticsearch 8 active la sécurité par défaut (TLS/credentials), ce qui change l’outillage et l’exploitation (certificats, rotation, secrets). Si votre module n’est pas compatible avec l’auth 8.x, vous vous retrouvez à exposer un cluster non sécurisé sur un réseau interne “supposé sûr” — c’est exactement le genre de dette qui finit en incident.

Sur l’implémentation, ne vous contentez pas d’installer Elasticsearch : validez les impacts applicatifs. Une recherche e-commerce utile, c’est de l’analyse linguistique (stemming, stop words), de la tolérance aux fautes, et des champs bien définis (keyword vs text) pour éviter les agrégations coûteuses. Deux contrôles “simples” qui évitent des surprises :

• qualité des résultats : requêtes réelles (marques, références, fautes de frappe) + mesure “zéro résultat” ;
• coût des requêtes : facettes/agrégations sur des champs mal typés (ex. text au lieu de keyword) peuvent faire exploser les temps de réponse.

Pour la partie PrestaShop (gros catalogues, gains de temps de réponse, paramètres d’index), vous pouvez croiser avec PrestaShop ElasticSearch : accélérer la recherche produit sur grands catalogues. Et si votre contrainte principale est l’opérationnel (simplicité, RAM réduite), comparez franchement avec d’autres moteurs : Recherche interne PrestaShop : intégrer Meilisearch pour booster la conversion et Alternatives à Algolia 2026 : 7 solutions de recherche site web.

Enfin, ajoutez un filtre “GEO/ops” : si vous optez pour un Elasticsearch managé, vérifiez où sont les nœuds (région), comment sont gérés les snapshots, et qui a accès aux logs/metrics. Ce n’est pas du “juridique”, c’est du pragmatique : en incident, la distance (organisationnelle et géographique) allonge souvent le délai de résolution.

Valider la compatibilité minimale : matrice, staging, CI et plan de rollback

Une fois les minima fixés, votre job n’est pas “d’installer”, mais de prouver que la stack tient : import catalogue, génération d’images, indexation, tunnel de commande, back-office, webservice, et crons. Faites-le sur un staging identique à la prod (mêmes versions PHP/MariaDB/Elasticsearch, même taille de données si possible). Le rollback n’est pas une option ; c’est un prérequis. Pour cadrer correctement migration/tests/retour arrière côté PrestaShop 9, lisez Migration PrestaShop 9 : sécurité, tests et plan de rollback.

Une matrice “simple” qui évite des discussions stériles (à adapter à vos contraintes modules) :

Composant	Minimum viable (2026)	Recommandé (2026)	À éviter	Pourquoi
PHP	8.2	8.3 (voire 8.4 après tests)	< 8.2	sécurité (EOL), écosystème Composer/Symfony
MariaDB	LTS récente (ex. 10.11)	LTS + tuning InnoDB + slow log	versions anciennes non maintenues	bugs/écarts de comportement, perf, sécurité
Elasticsearch	version maintenue + TLS	cluster/instance dédiée + heap sizing correct	ES exposé sans auth, heap mal dimensionnée	sécurité, stabilité, latence

Ce tableau n’est pas une spec “universelle”, c’est un garde-fou : vous évite de signer une infra qui ne passera pas la charge, ou qui vous forcera à des contournements (désactiver un mode SQL, exposer Elasticsearch sans auth, rester sur PHP EOL).

Pour rendre la validation concrète (et pas juste “ça démarre”), vous pouvez définir un jeu de tests minimal à exécuter à chaque changement de version :

Parcours / job	Objectif	Signal d’alerte typique
composer install + composer check-platform-reqs	dépendances cohérentes	extensions manquantes / PHP CLI non aligné
Import d’un échantillon + import “taille prod”	valider mémoire/temps	timeouts, erreurs encodage, données invalides
Génération d’images (batch)	valider GD/Imagick + perf I/O	saturation CPU, erreurs Imagick, disque plein
Reindex recherche (complet)	valider ES + mapping	heap/GC, erreurs analyzers, index rouge
Tunnel commande (paiement, email)	valider modules critiques	échec PSP, erreurs TLS, latence

Pour industrialiser la validation, mettez la compatibilité dans la CI : exécution de tests (même basiques), installation des dépendances, et vérification de plateforme. Une approche efficace consiste à reproduire le runtime via conteneurs en local/staging (DDEV, Docker), puis à verrouiller les versions. Sur l’exécution Composer dans conteneur, voir DDEV Composer : exécuter et configurer Composer dans les conteneurs. Vous évitez ainsi le syndrome : “ça marche sur mon poste / chez l’hébergeur ça casse”.

Le rollback, lui, doit être écrit comme une procédure “bête et méchante”. Exemple de points non négociables :

• snapshot/backup avant upgrade (base + fichiers + configs) ;
• preuve que la restauration fonctionne (test trimestriel ou avant migration majeure) ;
• scénario de retour arrière (versions, étapes, responsable, fenêtre d’intervention).

Dernier point : mesurez avant d’optimiser. Si vous fixez Elasticsearch “par défaut” mais que votre vrai bottleneck est MariaDB (indexes, buffer pool), vous ajoutez un service sans ROI. Inversement, si votre recherche interne génère beaucoup de “zéro résultat” et une latence élevée, un moteur externe peut être un vrai gain… mais uniquement si vous suivez les métriques (CTR de recherche, taux de conversion post-recherche, temps d’indexation). Pour cadrer la mesure côté recherche : Recherche interne PrestaShop : mesurer CTR, zéro résultat et conversion.

Et si vous devez sécuriser et fiabiliser vos appels API (ERP, PIM, OMS) dans cette stack, gardez aussi un œil sur Webservice PrestaShop : activer l’API et créer une clé d’accès. En pratique, beaucoup de “problèmes de compatibilité” se révèlent être des problèmes de timeouts, de versions TLS, ou de jobs cron qui tournent avec un PHP CLI différent : là encore, staging + logs + procédures font la différence.