Exigences système : prérequis mod_rewrite, bcmath et GeoIP nouveau format

Table des matières :

1. Ce que couvrent vraiment ces « exigences système » côté PrestaShop (et ce que le cœur ne dit pas)
2. mod_rewrite : ce que PrestaShop attend sur Apache 2.4 (et comment le prouver)
3. Quand vous n’avez pas Apache : Nginx, reverse proxy, LiteSpeed… et la fausse exigence « mod_rewrite »
4. bcmath : l’extension PHP qui casse des paiements (et pourquoi le core la sous-estime)
5. GeoIP « nouveau format » : passer proprement à MaxMind GeoLite2 (.mmdb) sans casser la géolocalisation
6. Check-list de validation en staging : tests reproductibles, rollback, et monitoring des régressions
7. Points de durcissement : éviter que ces prérequis deviennent des incidents sécurité ou perf

Ce que couvrent vraiment ces « exigences système » côté PrestaShop (et ce que le cœur ne dit pas)

Sur PrestaShop 8.1.x et PrestaShop 9.x (contexte 2026), les contrôles d’installation et certaines pages du back-office se résument à trois items : réécriture d’URL (souvent présentée comme modrewrite), l’extension PHP bcmath, et la base GeoIP « nouveau format ». Le point important : ces exigences ne sont pas homogènes. modrewrite n’a de sens que sur Apache, bcmath dépend du SAPI (CLI vs FPM), et GeoIP implique une chaîne « base de données + mises à jour + conformité » que PrestaShop traite de manière minimaliste.

Le cœur vérifie surtout des symptômes : URLs « propres » (Friendly URLs) et génération de routes, disponibilité de certaines fonctions PHP, et présence d’un fichier GeoIP attendu. Ces contrôles peuvent passer en local et échouer en prod si vous n’exécutez pas le même binaire PHP (ex. php CLI ≠ PHP-FPM), ou si un reverse proxy masque des erreurs de réécriture. Avant de « corriger » à l’aveugle, alignez d’abord vos versions et votre stack (Apache/Nginx, PHP-FPM/LiteSpeed, conteneurs). Pour la matrice PHP/DB côté PrestaShop, gardez un lien direct avec l’article interne : Exigences système : compatibilités PHP, MariaDB et Elasticsearch minimales.

Pour cadrer rapidement ce que l’alerte signifie réellement, voici une lecture « utile en exploitation » :

Alerte affichée	Ce que PrestaShop cherche à obtenir	Ce qui casse en vrai (le plus fréquent)	Preuve à produire
mod_rewrite	Un mécanisme de réécriture vers index.php + lecture des règles	.htaccess ignoré (AllowOverride None), chemin de base en sous-répertoire, proxy qui réécrit mal	curl -I sur une URL produit + logs webserver
bcmath	Fonctions bc*() disponibles dans le runtime web	Extension installée sur une autre version PHP, FPM sans module, image Docker différente	phpinfo() (SAPI FPM) ou test applicatif
GeoIP nouveau format	Base .mmdb lisible et à jour	fichier absent, permissions, base obsolète, IP client non propagée	test lecture mmdb + contrôle de date/poids

Enfin, ces prérequis ont des impacts concrets : une réécriture bancale = pages du front en 404, duplication SEO, redirections incohérentes (à relier à votre stratégie de mapping, cf. Migration PrestaShop WooCommerce : redirections 301 et cartographie d’URL SEO); bcmath manquant = erreurs fatales sur certains paiements/exports; GeoIP cassé = géolocalisation inutilisable, et potentiellement règles de pays erronées (taxes, livraisons, blocage). Le reste de l’article se concentre sur des checks reproductibles et des corrections durables — typiquement ce qu’on veut quand on opère une boutique en production (souvent derrière CDN/WAF, et parfois avec un hébergement mutualisé où la visibilité infra est limitée).

mod_rewrite : ce que PrestaShop attend sur Apache 2.4 (et comment le prouver)

Sur Apache 2.4, PrestaShop s’appuie historiquement sur un front controller (index.php) et sur un fichier .htaccess généré/maintenu par le BO (SEO & URL). Le module mod_rewrite permet d’intercepter une URL « propre » (/categorie/produit.html) et de la router vers index.php avec des paramètres, sans exposer index.php dans l’URL. Sans ça, votre boutique peut fonctionner « en mode dégradé » uniquement si vous désactivez les URLs simplifiées, avec un coût SEO et UX évident.

Vérification côté serveur (Apache) :

apachectl -M | grep -E 'rewrite|headers|expires'
# ou sur certaines distros
httpd -M | grep rewrite

Vous cherchez rewrite_module (shared) (ou static). Si absent : activez-le et redémarrez.

• Debian/Ubuntu :

sudo a2enmod rewrite
sudo systemctl reload apache2

• RHEL/Alma/Rocky : c’est généralement un package + configuration, puis systemctl reload httpd.

Le piège récurrent n’est pas mod_rewrite… mais AllowOverride. PrestaShop dépend de .htaccess, donc si votre vhost a AllowOverride None, le .htaccess est ignoré même si mod_rewrite est actif. Exemple minimal recommandé (à adapter) :

<Directory /var/www/prestashop>
    AllowOverride All
    Require all granted
</Directory>

Deux cas concrets reviennent souvent :

• Boutique dans un sous-répertoire (ex. https://exemple.tld/boutique/) : si la RewriteBase régénérée ne correspond pas, vous obtenez des 404 « propres ». Dans ce scénario, faites une régénération .htaccess depuis le BO après avoir stabilisé la configuration vhost, puis validez au curl.
• Option MultiViews (content negotiation) activée dans Apache : elle peut « voler » des URLs en essayant de deviner un fichier proche, et provoquer des comportements incohérents. Si vous voyez des résultats différents selon extensions et casses, c’est une piste à auditer.

Si vous êtes en hébergement mutualisé, c’est typiquement le point où l’éditeur du vhost (votre hébergeur) doit intervenir. Côté diagnostic, arrêtez de regarder uniquement le BO : testez une URL « propre » qui doit matcher une règle .htaccess (produit/catégorie), et consultez les logs Apache (access + error) lors d’une 404.

Mini-protocole de preuve (rapide et actionnable) :

# 1) une URL "friendly" doit répondre en 200 ou 301, pas en 404
curl -I https://votredomaine.tld/nom-produit.html

# 2) la home doit rester OK
curl -I https://votredomaine.tld/

Si vous obtenez une 404 sur l’URL friendly mais pas sur la home, vous avez presque toujours un problème de réécriture (ou .htaccess ignoré).

Doc de référence Apache (utile pour trancher les débats internes et partager un lien neutre) : Documentation mod_rewrite (Apache 2.4).

Quand vous n’avez pas Apache : Nginx, reverse proxy, LiteSpeed… et la fausse exigence « mod_rewrite »

Sur Nginx, mod_rewrite n’existe pas. Pourtant, beaucoup d’installateurs/OPS voient encore l’alerte « mod_rewrite manquant » et tentent de la « résoudre »… alors que la boutique tourne derrière Nginx en frontal et PHP-FPM en backend. Ici, l’objectif n’est pas d’activer un module inexistant : il faut reproduire la logique front controller et s’assurer que les routes Friendly URL retombent vers index.php.

Config Nginx type (à adapter à votre doc d’hébergement, et à tester en staging). Les points clés : try_files vers /index.php, prise en charge des fichiers statiques, et propagation de PATH_INFO si nécessaire.

location / {
    try_files $uri $uri/ /index.php?$args;
}

location ~ \.php$ {
    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    fastcgi_pass unix:/run/php/php8.2-fpm.sock;
}

Deux points qui évitent des « faux problèmes de rewrite » en environnement réel (CDN / reverse proxy / WAF) :

• IP client et schéma (HTTP/HTTPS) : si le proxy n’envoie pas correctement X-Forwarded-For et X-Forwarded-Proto, PrestaShop peut générer des redirections ou des liens en HTTP, ou enregistrer une mauvaise IP (impact GeoIP, antifraude, logs). Ce n’est pas du rewrite, mais le symptôme ressemble à des redirections incohérentes.
• Normalisation d’URL : certains WAF/CDN réécrivent les chemins (double slash, encodage, paramètres), ce qui casse des URLs à facettes ou des paramètres de tri/pagination. Si l’incident ne se reproduit pas en accès direct au serveur, suspectez la couche proxy avant Nginx.

Dans ce cas, le symptôme ressemble à un problème de rewrite, mais la cause est ailleurs. Pour les environnements avec WAF, la réduction des faux positifs sur le checkout vous évite de diagnostiquer le mauvais composant : WAF PrestaShop : réduire les faux positifs et sécuriser le checkout.

Dernier point : LiteSpeed/OpenLiteSpeed implémentent une compatibilité .htaccess très proche d’Apache. L’alerte « mod_rewrite » est alors souvent un faux négatif lié au SAPI ou à un check trop strict. Si vous êtes sur LiteSpeed, validez surtout le résultat fonctionnel (URLs propres + redirections attendues), et surveillez les métriques serveur/queue si la couche web devient un bottleneck : Performances PHP LiteSpeed : cache opcode, LSAPI et suivi WaitQ.

bcmath : l’extension PHP qui casse des paiements (et pourquoi le core la sous-estime)

bcmath (BCMath) fournit des opérations arithmétiques en précision arbitraire sur des nombres représentés sous forme de chaînes. Dans un contexte e-commerce, elle devient utile dès que vous manipulez des montants avec plus de 2 décimales, des taux, des conversions, des calculs d’échéancier, ou des identifiants/numéros très longs. Le cœur de PrestaShop ne dépend pas systématiquement de bcmath pour afficher un prix, mais des modules (paiement, ERP, reporting, antifraude) s’appuient dessus, parfois indirectement via une lib.

Pourquoi ce n’est pas un détail : si un module retombe sur des floats, vous pouvez obtenir des effets de bord bien connus (addition/arrondi non exact). Exemple classique (illustratif) :

• 0.1 + 0.2 n’est pas exactement égal à 0.3 en flottant binaire ;
• sur un panier avec remises cumulées, conversions et frais, des écarts « d’un centime » peuvent apparaître et déclencher des refus de paiement, des écritures comptables incohérentes ou des erreurs de rapprochement.

Référence fonctionnelle (documentation PHP, extension BCMath) : Documentation BCMath (PHP).

En pratique, quand bcmath manque, vous avez trois profils d’incident :

1) erreur fatale au runtime (lib qui appelle bcadd, bccomp, etc.) ;
2) calculs silencieusement faux si le module retombe sur des floats (problèmes d’arrondi, cumul d’erreurs) ;
3) incompatibilité au moment d’un composer install si votre projet impose l’extension via ext-bcmath.

Validation correcte = vérifier le bon binaire. Beaucoup d’équipes testent php -m | grep bcmath (CLI) alors que la prod utilise PHP-FPM (web). Faites les deux :

php -m | grep -i bcmath
php-fpm8.2 -m 2>/dev/null | grep -i bcmath || true

Deux compléments utiles quand vous suspectez un serveur multi-PHP (Plesk/cPanel, pools multiples, conteneurs) :

# Où pointe le CLI ?
which php
php -v
php --ini | sed -n '1,6p'

Côté web, le plus propre est de vérifier via un phpinfo() temporaire en IP whitelisting, ou via une commande interne (Symfony console/CLI) exécutée dans le même conteneur/pool PHP que le front.

Installation (exemples) :

• Debian/Ubuntu (PHP 8.2) :

sudo apt-get update
sudo apt-get install -y php8.2-bcmath
sudo systemctl reload php8.2-fpm

• RHEL/Alma/Rocky (Remi, à adapter) : package php-bcmath, puis reload du service FPM.

Le risque ici n’est pas « installer un paquet » : c’est d’installer l’extension pour une version PHP qui n’est pas celle utilisée par PrestaShop. Sur des serveurs multi-PHP, vous pouvez avoir php8.1-bcmath installé alors que le vhost tourne en 8.2. Même logique en conteneurs : votre Dockerfile peut installer l’extension, mais votre image runtime peut être une autre. Si vous avez déjà des outils d’observabilité, corrélez l’activation avec vos erreurs fatales et vos pics : Superviser les erreurs PrestaShop : logs PHP, MySQL, JavaScript et alertes e-mail.

GeoIP « nouveau format » : passer proprement à MaxMind GeoLite2 (.mmdb) sans casser la géolocalisation

Quand PrestaShop parle de GeoIP « nouveau format », l’idée derrière est simple : arrêter d’utiliser les bases historiques au format .dat (GeoIP Legacy) et s’appuyer sur les bases MaxMind modernes GeoLite2 (format .mmdb). La distribution des bases gratuites implique désormais un compte et une clé de licence pour automatiser les téléchargements. Si vous migrez une boutique ancienne, vous tombez souvent sur un répertoire GeoIP vide, un fichier obsolète, ou des permissions qui empêchent l’écriture côté back-office.

Documentation technique du format MaxMind DB (utile si vous devez justifier le choix ou auditer un parseur) : MaxMind DB format.
Accès officiel GeoLite2 + contraintes de compte/licence : GeoLite2 – MaxMind (dev).

Concrètement, PrestaShop attend un fichier GeoLite2-Country.mmdb (ou équivalent selon versions) dans un chemin précis, et une option de géolocalisation activée dans le BO. Si le fichier est absent/corrompu, vous aurez une géolocalisation muette (tout le monde « inconnu »), ce qui peut casser :

• la restriction de pays (ex. B2B, zones réglementées) ;
• l’affichage automatique de langue/devise ;
• certaines règles fiscales ou transport.

Procédure fiable en prod : ne dépendez pas du « bouton télécharger » du BO si votre serveur est verrouillé (pas de sortie Internet, TLS inspecté, etc.). Préférez un job d’update contrôlé (cron) qui dépose le .mmdb dans un répertoire persistant, avec des permissions correctes pour l’utilisateur PHP (www-data, apache, etc.).

Astuce pragmatique (évite les suppositions de chemin) : sur une instance, repérez ce que PrestaShop lit réellement.

# retrouver les bases mmdb présentes
find . -maxdepth 4 -type f -name "*.mmdb" -ls

# retrouver des références possibles dans le code/config
grep -R --line-number "GeoLite2" . | head
grep -R --line-number "\.mmdb" . | head

Points d’attention techniques :

• Chemins et persistance : sur Docker/Kubernetes, montez un volume pour le fichier .mmdb, sinon vous le perdez à chaque redeploy.
• Permissions : si PrestaShop doit lire uniquement, privilégiez 0644 et propriétaire root, groupe du serveur web. Si le BO écrit, vous ouvrez une surface d’attaque inutile.
• Mise à jour : mettez une rotation (mensuelle au minimum) et un contrôle d’intégrité (taille minimale, hash, date de build). Sans ça, vous finissez avec une base périmée et des décisions pays fausses.

Et côté conformité (utile en France/UE où les audits reviennent vite) : GeoIP n’est pas magique, et n’est pas « anonyme ». Une adresse IP est généralement traitée comme donnée personnelle selon le contexte ; en UE, le sujet est solidement discuté en jurisprudence (par exemple l’arrêt Breyer de la CJUE, 2016, sur les IP dynamiques). Si vous exploitez la géolocalisation pour bloquer/segmenter, documentez-le (registre), limitez la conservation des logs, et évitez d’exfiltrer l’IP vers un tiers non nécessaire. Sur des architectures renforcées (WAF, reverse proxy), assurez-vous aussi que l’IP client réelle est correctement propagée (X-Forwarded-For) avant d’accuser GeoIP de se tromper.

Check-list de validation en staging : tests reproductibles, rollback, et monitoring des régressions

Valider ces trois prérequis « une fois » n’a aucun intérêt si vous ne les verrouillez pas dans vos déploiements. Faites-le en staging, sur une infra la plus proche possible de la prod (mêmes versions Apache/Nginx, même PHP, mêmes modules), puis automatisez des checks après chaque release. Si vous avez une démarche de migration ou de montée majeure (ex. PrestaShop 9), gardez un plan de rollback et des tests ciblés : Migration PrestaShop 9 : sécurité, tests et plan de rollback.

Pour mod_rewrite / URL rewriting, ne vous contentez pas d’un check de module. Testez des URLs réelles :

• une page produit (route canonique)
• une catégorie
• une URL avec paramètres (tri, pagination)
• une redirection 301 attendue (ancienne URL → nouvelle)

Le but : détecter tôt les boucles 301/302, les 404 sur routes Symfony/legacy, et les incohérences de canonicals. La génération d’URL côté PrestaShop est plus subtile qu’un .htaccess : si vous mélangez routes Symfony et legacy, documentez vos points de sortie : Comprendre la génération d’URL : Link, routes Symfony et legacylink.

Pour bcmath, ajoutez un check applicatif : exécuter un petit script PHP dans le même runtime que la boutique, par exemple :

<?php
if (!extension_loaded('bcmath')) {
  fwrite(STDERR, "bcmath manquant\n");
  exit(1);
}
if (bccomp('0.3', '0.30', 2) !== 0) {
  fwrite(STDERR, "bcmath comportement inattendu\n");
  exit(2);
}
echo "OK\n";

Ce test est trivial, mais il évite le « ça marche en CLI » alors que le pool FPM web n’a pas l’extension.

Pour GeoIP, ajoutez un test d’existence + fraîcheur : date de modification du .mmdb et taille minimale, puis un test fonctionnel via une IP de référence (VPN/CI) et une lecture GeoIP locale (pas un call réseau). Si vous ne pouvez pas tester la précision, testez au moins que la chaîne « lecture du fichier mmdb → pays » ne crash pas. Et surveillez en prod : remontée d’erreurs PHP liées à GeoIP, taux d’utilisateurs « pays inconnu », et effets collatéraux sur taxes/livraison.

Rollback (simple mais souvent oublié) : conservez une copie du .htaccess précédent et du .mmdb précédent (datés) avant une mise à jour SEO/infra. En cas d’incident, vous restaurez l’état N-1 immédiatement, puis vous analysez au calme.

Enfin, ne négligez pas l’effet SEO : un rewrite mal configuré se paye en indexation et en duplication, surtout lors d’une refonte/migration. Si vous êtes en phase d’optimisation, croisez ces prérequis avec vos audits SEO et votre check qualité : Audit SEO technique : contrôle qualité avant publication des pages web et SEO PrestaShop : optimiser fiches produits, schema.org et images WebP.

Points de durcissement : éviter que ces prérequis deviennent des incidents sécurité ou perf

Activer la réécriture et multiplier les règles .htaccess peut devenir un problème de sécurité si vous laissez le serveur interpréter des directives dangereuses ou si vous exposez des chemins sensibles. Le .htaccess PrestaShop est utile, mais pas une politique de sécurité. Dans les environnements Apache, validez les headers et les règles de blocage (fichiers .env, dumps, /var/), et versionnez vos changements pour éviter les dérives. Pour une base, alignez-vous sur des pratiques de durcissement cohérentes : Sécurité PrestaShop : mises à jour, SSL et durcissement .htaccess.

Côté performance, mod_rewrite et .htaccess ont un coût (par requête, Apache doit reparser des directives). Sur des boutiques à trafic élevé, vous gagnez à déplacer des règles au niveau vhost (pas .htaccess) quand c’est possible, ou à passer à une conf Nginx dédiée. Mais c’est un arbitrage : PrestaShop régénère .htaccess via le BO, donc si vous « sortez » des règles critiques du fichier, documentez-le, sinon une future bascule SEO les écrase.

Autre point souvent sous-estimé : les règles de rewrite et de redirection ont un impact direct sur les caches (CDN, Varnish). Une boucle 301/302, ou un Vary mal maîtrisé, peut faire exploser le taux de MISS et dégrader tout le site. Si vous êtes en mode runbook « soldes », ce genre de détail finit en incident évitable : PrestaShop soldes : optimiser caches, CDN et Varnish pour trafic élevé.

Pour bcmath et GeoIP, le risque principal est l’écart entre environnements : staging ok, prod KO, parce que le provisioning n’est pas idempotent. Si vous êtes déjà en CI/CD, formalisez les prérequis système (packages, extensions, fichiers .mmdb) dans l’image, l’Ansible, ou les manifests. L’objectif n’est pas « que ça marche » : c’est reproductible et vérifiable. Sur le long terme, c’est la même logique que pour la dette technique : mesure, profiling, et refactoring des points durs — même côté infra : Dette technique Symfony : profiling Blackfire et refactoring mesurable.