PrestaShop 9 : versions PHP recommandées et incohérences de documentation

Table des matières :

« Version PHP recommandée » : compatibilité technique vs support opérationnel
D’où viennent les incohérences de documentation autour de PrestaShop 9 et PHP
Comment déterminer la plage PHP réellement supportée (méthode reproductible)
Recommandations 2026 : PHP 8.3 comme base, PHP 8.4 sous conditions, éviter les branches en fin de vie
Réduire l’écart doc ↔ réalité : verrouillage, CI, et gouvernance des versions PHP
Checklist courte (mais utile) avant de figer la version PHP d’une boutique PrestaShop 9

PrestaShop 9 met tout le monde face à un problème classique : la documentation parle de « versions PHP recommandées », le code impose des contraintes différentes, et l’écosystème (modules/thèmes/hébergement) ajoute sa propre réalité. À la fin, ce n’est pas « quelle version PHP passe », mais « quelle version PHP est soutenue, maintenable et sécurisée en 2026 ».

Dans cet article, on remet de l’ordre entre trois notions souvent mélangées :

Compatibilité technique (ça s’installe et ça ne crash pas immédiatement)
Support opérationnel (ça se maintient, ça se diagnostique vite, ça se met à jour sans douleur)
Support sécurité upstream (PHP reçoit encore des correctifs)

L’objectif : vous donner une méthode reproductible pour décider quoi déployer (PrestaShop 9 + PHP) sans dépendre d’un tableau de doc potentiellement obsolète.

« Version PHP recommandée » : compatibilité technique vs support opérationnel

Dans un projet e-commerce, « compatible » et « recommandé » ne recouvrent pas la même chose.

Compatible signifie généralement : l’installateur ne bloque pas, les dépendances Composer se résolvent, le front et le back se chargent, et les scénarios de base (indexation, panier, paiement) ne cassent pas immédiatement.
Recommandé devrait signifier : version encore supportée par PHP, testée par l’éditeur et/ou par la CI du projet, cohérente avec les dépendances (Symfony/Doctrine/Twig), et sur laquelle on sait diagnostiquer vite (logs, outils, profils de perf).

En 2026, la variable la plus ignorée dans les docs PrestaShop est l’EOL PHP. PHP publie un calendrier de support très strict. Le site officiel rappelle :

“Every PHP 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.”
— PHP.net, Supported Versions https://www.php.net/supported-versions.php

Traduction opérationnelle : une version peut être « compatible » avec PrestaShop 9 tout en étant inacceptable en production si elle ne reçoit plus de correctifs sécurité. Et l’impact n’est pas théorique : une boutique est une surface d’attaque permanente (formulaires, upload d’images, back-office, intégrations paiement/transport, endpoints modules, etc.).

Enfin, PrestaShop 9 n’est pas un binaire isolé : c’est un agrégat Symfony + dépendances Composer + extensions PHP. Si PrestaShop 9.x s’appuie sur Symfony 6.4 LTS (cas courant sur les stacks 2024–2026), alors le plancher PHP est dicté par Symfony :

“Symfony 6.4 requires PHP 8.1.0 or higher.”
— Symfony Docs https://symfony.com/doc/6.4/setup.html#technical-requirements

Mais ça ne dit toujours pas quelle version choisir en 2026 : entre 8.3 et 8.4, le critère déterminant n’est pas seulement la perf, c’est le support upstream + la compatibilité module/thème + la capacité de debug.

Point important (souvent oublié) : « recommandé » doit aussi intégrer votre capacité d’exploitation. Si votre hébergeur/infogérance ne sait pas vous fournir rapidement :

des pools PHP-FPM isolés,
des métriques (latence, erreurs 5xx, saturation),
un accès logs exploitable, alors la meilleure version PHP sur le papier peut devenir la pire en pratique.

D’où viennent les incohérences de documentation autour de PrestaShop 9 et PHP

La première source d’incohérence, c’est la multiplication des documents : page « exigences système », README GitHub, notes de version, pages communautaires, et parfois même des articles qui reprennent des tableaux copiés-collés d’une version antérieure. Ces contenus ne vivent pas au même rythme que le code. Le résultat typique : une page annonce « PHP 8.1+ » parce que c’était vrai au moment de la rédaction, puis elle n’est pas mise à jour quand PHP 8.1 passe EOL.

La seconde source, plus technique : le code dit parfois autre chose que la doc. Exemples fréquents :

L’installateur valide une version PHP minimale « large » (pour ne pas bloquer des hébergements), mais Composer refuse ensuite (contrainte require.php plus stricte).
À l’inverse, Composer « accepte », mais à l’exécution vous prenez des erreurs liées à des extensions manquantes (intl, gd, zip…) ou à des comportements modifiés (dépréciations devenues plus visibles).

La règle d’or : en cas de conflit, le code exécutable et les contraintes Composer priment. Concrètement, si composer.json indique une contrainte, c’est cette contrainte qui vous protège des combos non testés.

Troisième cause : l’écosystème module/thème. Une boutique « PrestaShop 9 + 30 modules + thème custom » n’a pas la même surface de risque qu’un core nu. Beaucoup de modules historiques ont encore des patterns problématiques vis-à-vis des versions PHP récentes :

Déprecations (ex. code “bruyant” qui pollue les logs et masque les vraies erreurs)
Accès à des entrées non filtrées (superglobales) ou hypothèses sur l’encodage
Dépendances figées (vendor embarqué) qui introduisent une incompatibilité indirecte
Usage d’extensions ou de fonctions dont le comportement évolue (formatage des dates, conversions numériques, etc.)

Le cœur PrestaShop peut être « OK » sur une version récente, mais un module de paiement peut casser en silence, ce qui rend la « recommandation » très contextuelle. Pour une approche migration orientée risques (tests, rollback, compat modules), gardez une checklist dédiée comme base de travail :

Mini-scénario réaliste (souvent rencontré en France/UE) : une boutique migre vers PrestaShop 9, met PHP à jour « parce que recommandé », puis découvre en production qu’un module (paiement, connecteur ERP, transport) déclenche une erreur uniquement sur le tunnel de commande, donc invisible sur un simple test “homepage + BO”. D’où l’intérêt d’un protocole de tests reproductible (voir section méthode).

Comment déterminer la plage PHP réellement supportée (méthode reproductible)

Commencez par arrêter de « deviner » : lisez les contraintes de plateforme. Dans le dépôt PrestaShop 9.x, la vérité se trouve dans :

composer.json (champ require.php)
et, en pratique, dans composer.lock (versions réellement retenues)

Si vous packez ou déployez via CI/CD, ne vous contentez pas de « composer install passe » : exécutez une validation de plateforme sur l’environnement cible.

Commande utile (côté projet, après installation des dépendances) :

composer check-platform-reqs

“The check-platform-reqs command checks that your PHP and extensions versions match the platform requirements of the installed packages.”
— Composer CLI docs https://getcomposer.org/doc/03-cli.md#check-platform-reqs

En clair : si votre PHP-FPM n’a pas intl, si zip manque, si gd n’est pas compilé avec les bons backends, ou si la version PHP ne matche pas, vous le saurez avant de découvrir un 500 au checkout.

1) Clarifier ce que vous validez : version PHP et extensions

Les incohérences de documentation portent souvent autant sur les extensions que sur la version PHP. Une manière pratique de structurer le sujet est de séparer :

extensions “socle” (nécessaires au fonctionnement général)
extensions “fonctionnelles” (selon usages : images, i18n, chiffrement, perf)
extensions “infrastructure” (cache, observabilité)

Exemple de checklist rapide (à adapter à votre stack) :

Catégorie	Extensions PHP typiques à vérifier	Pourquoi ça casse en vrai
Socle	`curl`, `mbstring`, `json`, `openssl`, `pdo_mysql`	appels API, encodage, TLS, DB
Fonctionnel	`intl`, `gd`, `zip`, `sodium`, `bcmath`	i18n, images, archives, crypto, calculs (selon modules)
Perf	`opcache`	latence et charge CPU (FPM)

Pour une base méthodique côté prérequis serveur (y compris mod_rewrite, bcmath, GeoIP selon cas), vous pouvez vous appuyer sur :

2) Vérifier le “runtime”, pas seulement l’installation

Ensuite, validez par tests et scénarios. En staging, faites au minimum :

installation (ou upgrade) + back-office accessible
régénération des thumbnails (stress test images)
indexation (si activée) et navigation catégories/produits
création de compte + connexion
tunnel complet (panier → livraison → paiement → confirmation)
BO : création/modif produit, consultation commande, génération facture

Instrumentez dès le début :

logs PHP-FPM (error + slow si activé)
logs applicatifs PrestaShop
logs MySQL/MariaDB (erreurs + lenteurs)
console JS (erreurs de scripts modules)

L’objectif n’est pas de « tester tout », mais de capturer vite les incompatibilités runtime (déprecations, fatals, warnings convertis en exceptions). Pour structurer cette partie (collecte, centralisation, alertes), voir :

Monitoring d’erreurs : logs PHP/MySQL/JS et alertes e-mail

3) Matrice simple “versions PHP” (utile même sans tests automatisés)

Même sans grosse CI, vous pouvez faire une matrice très simple sur staging :

PHP 8.3.x (cible “confort”)
PHP 8.4.x (cible “future-proof”)
(éventuellement) PHP 8.2.x uniquement pour mesurer l’écart si vous êtes coincé par un module

À chaque run, vous comparez :

le nombre d’erreurs fatales,
les warnings/déprecations réellement déclenchés sur les parcours métier,
le temps de réponse (p95) sur les pages clés,
et l’impact sur CPU/RAM (PHP-FPM + MySQL).

Ce comparatif vaut plus qu’une “table compat” copiée-collée.

Recommandations 2026 : PHP 8.3 comme base, PHP 8.4 sous conditions, éviter les branches en fin de vie

Le cœur du problème en 2026 : ce n’est pas seulement “PrestaShop 9 supporte quoi”, c’est “qu’est-ce qui reste sécurisé sur la durée de vie de votre boutique”.

D’après le calendrier officiel PHP (https://www.php.net/supported-versions.php), les branches ont une fenêtre de support limitée et, en 2026 :

PHP 8.2 est déjà sur une fin de vie opérationnelle (support terminé selon le calendrier upstream). Autrement dit : même si “ça marche”, c’est un choix qui vous met en rattrapage permanent.
PHP 8.3 reste une base très répandue et généralement stable côté écosystème, mais son horizon de support est plus court que 8.4 : si vous le choisissez, faites-le avec un plan de montée de version.
PHP 8.4 offre en général un meilleur horizon de support upstream, ce qui est un avantage concret pour un e-commerce (patchs sécurité disponibles plus longtemps).

Pourquoi, malgré tout, PHP 8.3 reste souvent la “base” en 2026 ? Parce que beaucoup d’environnements et d’outils (images Docker, recettes d’hébergement, modules anciens mais encore utilisés) ont eu le temps de s’aligner sur 8.3. La recommandation pragmatique devient donc :

Par défaut : viser PHP 8.3.x si vous devez minimiser le risque de compatibilité immédiate (modules legacy).
Dès que possible : préparer/valider PHP 8.4.x pour augmenter l’horizon de support et éviter un “prochain chantier PHP” trop proche.

PHP 8.4 est techniquement très intéressant, mais la question n’est pas « est-ce que PHP 8.4 est rapide » ; c’est « est-ce que votre stack PrestaShop 9 + modules est propre ». Les écarts de comportement (déprecations plus strictes, changements mineurs dans certaines fonctions, bibliothèques tierces pas encore alignées) créent des coûts cachés : temps de debug, patchs temporaires, forks de modules.

Un bon compromis “pro” (surtout en contexte UE où l’indisponibilité du checkout coûte vite cher) est de procéder en deux temps :

Stabiliser en 8.3 (si nécessaire) pour sécuriser la migration PrestaShop 9
Basculer en 8.4 une fois les modules critiques validés (paiement, transport, ERP, marketplace)

Côté performance, les gains observables ne viennent pas « magiquement » du numéro de version : ils viennent d’une configuration correcte de PHP-FPM/OPcache (mémoire, opcache.max_accelerated_files, opcache.validate_timestamps, warmup), et d’une réduction des I/O et des locks (sessions, filesystem, cache).

Pour des repères concrets (OPcache, pools FPM, mesure et bench), vous pouvez partir de :

Réduire l’écart doc ↔ réalité : verrouillage, CI, et gouvernance des versions PHP

Pour que « version PHP recommandée » ait un sens, vous devez figer une cible et la rendre vérifiable. Concrètement : documentez dans votre repo (README technique) :

une version PHP cible (ex. 8.3.x ou 8.4.x selon votre stratégie)
une version minimale tolérée (si vous devez supporter plusieurs environnements)
une version maximale validée (utile quand une version vient de sortir et que vous ne l’avez pas qualifiée)

Ne laissez pas cette information flotter dans un wiki externe : l’objectif est que n’importe quel dev/DevOps puisse lire la cible et la reproduire.

Ensuite, rendez la cible exécutable dans la CI. Une matrice GitHub Actions (ou autre) qui exécute au moins :

composer check-platform-reqs
une compilation/clear cache Symfony (bin/console selon l’outillage PrestaShop)
des smoke tests (HTTP 200 sur pages clés, connexion BO si possible)

… sur plusieurs versions PHP (8.3/8.4) vous évite une grande partie des surprises. Si vous travaillez déjà sur la provenance/sécurité des builds (SBOM, validation), ce sujet est naturellement adjacent :

Dernier point : ne faites pas confiance à une doc non sourcée. Vérifiez toujours que vous êtes sur les dépôts officiels (éviter les forks “quasi officiels” qui modifient des contraintes), et basez-vous sur des artefacts vérifiables : tags Git, composer.json, pipeline CI, changelog. Pour une méthode de vérification GitHub (dépôts officiels, hygiène anti-forks) :

Dépôts officiels PrestaShop : vérification GitHub et sécurité anti-forks

Checklist courte (mais utile) avant de figer la version PHP d’une boutique PrestaShop 9

Choisir une version PHP « recommandée » sans matérialiser les contraintes est une perte de temps. Commencez par lister :

version PrestaShop 9.x exacte (tag)
liste des modules actifs (et surtout : modules critiques business)
thème (marketplace vs custom)
particularités infra (reverse proxy, cache, multi-front, cron, workers)
contraintes d’exploitation (fenêtre de maintenance, rollback, monitoring, astreinte)

Si vous êtes derrière un reverse proxy type HAProxy, documentez aussi la terminaison TLS et les headers, car les erreurs « PHP » sont parfois des erreurs d’entête ou de timeouts masquées :

HAProxy : terminaison TLS, rate limiting et supervision Prometheus

Sur staging, exécutez :

php -v et php -m (inventaire versions + extensions)
composer check-platform-reqs
un cycle complet « cache clear + compilation container + pages clés »
un tunnel de commande complet + back-office (création produit, commande, facture)

Puis comparez les logs et les dépréciations entre 8.3 et 8.4. Ce diff a une valeur bien supérieure à un tableau de compatibilité figé dans une page qui n’a pas été mise à jour depuis 6 mois.

Enfin, si vous devez trancher rapidement pour la prod en 2026 :

8.3.x reste un choix très pragmatique si vous devez limiter le risque de régression immédiate (écosystème modules).
8.4.x est un très bon choix si vous avez une discipline de tests et un inventaire module/thème maîtrisé (et un meilleur horizon de support).
Évitez les branches en fin de vie : même si l’installation “passe”, le coût sécurité/maintenance explose vite.

Pour le reste (qualité de code, durcissement, typage, dépendances), ne perdez pas de temps : appliquez des standards propres côté PHP, sinon la “compatibilité” se paiera en debug. Base de travail :

Bonnes pratiques PHP : sécurité, typage et qualité de code