PrestaShop 9 : guide en 7 étapes pour créer une boutique

Table des matières :

Étape 1 — Cadrer la stack et l’architecture avant d’installer quoi que ce soit
Étape 2 — Verrouiller les prérequis système (PHP, extensions, DB) et éviter les pièges de doc
Étape 3 — Installer PrestaShop 9 proprement (sources, intégrité, CLI) et figer la reproductibilité
Étape 4 — Configurer le fonctionnel sans casser la cohérence technique (taxes, paiement, checkout)
Étape 5 — Choisir/adapter thème et modules pour PrestaShop 9 (Twig, services, compatibilité)
Étape 6 — Durcir sécurité et exploitation (TLS, headers, WAF, droits, sauvegardes)
Étape 7 — Préparer la mise en production (cache, CDN, monitoring, SEO) et valider avec des tests reproductibles

PrestaShop 9 n’est pas juste « une nouvelle version » : c’est un socle Symfony plus assumé (services, contrôleurs, Twig côté BO/FO selon contextes), une surface d’API d’administration en pleine évolution, et des attentes plus strictes sur la stack (PHP, cache, headers, observabilité). Créer une boutique en 2026 sans cadrage technique revient à empiler des modules jusqu’à ce que ça casse.

L’objectif de ce guide n’est pas de “faire tourner” PrestaShop, mais de mettre en ligne une boutique vendable, maintenable et observable. En France/UE, ça implique aussi de penser très tôt aux contraintes réelles : TVA multi-zones, conformité promotions (directive Omnibus), paiements soumis à l’authentification forte (DSP2/SCA), et exigences de protection des données (RGPD).

Étape 1 — Cadrer la stack et l’architecture avant d’installer quoi que ce soit

Commencez par figer les choix d’architecture, parce qu’ils déterminent vos perfs, votre sécurité et votre coût de run. À minima : PHP-FPM + OPcache, une base MySQL/MariaDB correctement configurée, et un reverse proxy (Nginx/Apache devant, voire HAProxy si vous avez plusieurs backends). Si vous visez un trafic sérieux ou des pics (soldes, campagnes), vous devez penser cache multi-niveaux (HTTP cache, object cache, CDN) dès le jour 1 ; rattraper ça après coup est plus cher et casse souvent la compatibilité des modules.

Sur l’hébergement, évitez le « mutualisé au hasard » si vous voulez maîtriser les paramètres PHP, les timeouts, la file d’attente (FPM) et les limites fichiers. Référez-vous aux comparatifs et patterns d’archi du site : Hébergement e-commerce : mutualisé, VPS, cloud ou SaaS comparés et, si vous allez vers du dédié, Serveurs dédiés infogérés e-commerce : NVMe, Redis, Varnish et haute disponibilité. En pratique : NVMe + MariaDB tuning + Redis + un CDN donnent plus de ROI qu’un CPU “énorme” sur une stack mal cachée.

Pour rendre le choix moins “émotionnel”, voici une grille rapide (à adapter à votre contexte : nombre de produits, pics, intégrations, budget run) :

Option	Quand c’est OK	Risques fréquents en PrestaShop 9
Mutualisé	POC / très petit catalogue / peu de modules	Timeouts, restrictions PHP, I/O lente, cache limité, debug difficile
VPS	Boutique “standard” + montée en charge progressive	Mauvaise config DB/FPM si non infogéré, monitoring absent
Dédié	Gros catalogue, trafic stable, besoin I/O et DB solides	Mauvais partitionnement, backups/DR négligés, patching non cadré
Cloud (instances + services)	Variabilité forte, HA, composants managés (DB, CDN)	Coût si mal gouverné, complexité réseau/observabilité

Enfin, tranchez tôt la question « monolithe PrestaShop » vs « services autour » (ERP, PIM, recherche, OMS). PrestaShop 9 peut rester un monolithe efficace, mais dès que vous externalisez la recherche ou le stock, vous entrez dans une architecture hybride qui nécessite des contrats d’API, de la supervision et une stratégie de retry. Pour ce cadrage, un rappel utile : Architecture backend : monolithe moderne ou microservices, critères décisionnels.

Astuce “terrain” : si vous avez un seul point de friction à anticiper, c’est la chaîne catalogue → stock → prix → checkout. Une boutique “simple” peut se contenter de PrestaShop + paiement + transport. Une boutique avec ERP/PIM/OMS doit formaliser dès le début : latence acceptable, source de vérité du stock, règles de prix, et comportement en panne (ex. que fait-on si l’ERP est indisponible ?).

Étape 2 — Verrouiller les prérequis système (PHP, extensions, DB) et éviter les pièges de doc

PrestaShop 9 est sensible aux versions PHP (et la documentation n’est pas toujours cohérente). Avant même de préparer un vhost, validez une version PHP supportée et stable pour votre parc de modules. Le site a déjà documenté les incohérences et les choix raisonnables : PrestaShop 9 : versions PHP recommandées et incohérences de documentation. Concrètement, fixez une version unique pour dev/staging/prod, sinon vous allez “déboguer” des différences d’extensions, de JIT/OPcache et de comportements typés.

Côté OS et extensions, vérifiez explicitement modrewrite (ou l’équivalent Nginx), bcmath, intl, gd/imagemagick, zip, curl, et la partie GeoIP si vous l’utilisez. Pour une checklist orientée exigences réelles (pas juste « Apache + MySQL »), appuyez-vous sur : Exigences système : prérequis mod_rewrite, bcmath et GeoIP nouveau format et Exigences système : compatibilités PHP, MariaDB et Elasticsearch minimales.

Pour éviter les “ça marche chez moi”, formalisez un mini-contrat d’environnement :

PHP : version, memory_limit, max_execution_time, upload_max_filesize, post_max_size, OPcache activé.
Système : timezone, NTP (horloge), limites fichiers (ulimit), taille /tmp, rotation logs.
Réseau : DNS sortant (webhooks), SMTP/transactionnel (emails), ports autorisés.
Préprod : même version PHP + mêmes extensions + même schéma DB que prod (sinon tests non représentatifs).

Sur la base, ne partez pas avec une config par défaut. Mettez au moins : un innodb_buffer_pool_size dimensionné (souvent 50–70% RAM dédiée DB si serveur DB isolé), tmp_table_size/max_heap_table_size cohérents, et activez le slow query log pour objectiver. Même en “petite” boutique, PrestaShop génère vite des requêtes coûteuses via modules. Guide opérationnel : Requêtes MySQL lentes PrestaShop : activer slow query log et, pour aller plus loin, Développeur MySQL : optimiser requêtes, schémas et performances en production.

Point souvent sous-estimé : encodage et collations. En e-commerce (noms produits, attributs, avis), partez sur utf8mb4 côté DB si possible, et assurez-vous que les imports (ERP/PIM) respectent le même encodage. Un mélange de collations peut provoquer des comparaisons lentes, des erreurs d’index, ou des résultats incohérents en recherche/tri.

Étape 3 — Installer PrestaShop 9 proprement (sources, intégrité, CLI) et figer la reproductibilité

Téléchargez le code depuis une source vérifiable. En 2026, le risque de forks “pollués” et de packages re-packagés est réel. Si vous passez par GitHub, appliquez une hygiène minimale : vérifier le dépôt officiel, contrôler les tags, et éviter les zips “mirrors”. Référence directe : PrestaShop GitHub : dépôts officiels, vérification et sécurité anti-forks.

Pour l’installation, privilégiez une approche reproductible (Composer + lockfile + CI) plutôt qu’un upload FTP artisanal. Même si vous commencez petit, vous vous remercierez au premier hotfix. Exemple (schématique) de séquence côté serveur :

# 1) Récupération
git clone https://github.com/PrestaShop/PrestaShop.git prestashop9
cd prestashop9

git checkout <tag-stable>

# 2) Dépendances
composer install --no-dev --prefer-dist --optimize-autoloader

# 3) Droits (à adapter à votre modèle d’exécution)
chown -R www-data:www-data var/ img/ modules/ themes/

Bon réflexe : considérez votre dépôt comme un artefact de build, pas un “dossier vivant” modifié en prod. En pratique :

vous versionnez le code + le composer.lock,
vous injectez les variables d’environnement (DB, secrets) au déploiement,
vous interdisez les modifications manuelles en prod (sinon rollback et audit deviennent impossibles).

L’installation en CLI est utile en CI/CD ou quand vous voulez automatiser un staging. Les chemins et options peuvent changer selon distributions, donc vérifiez la version exacte de PrestaShop 9 que vous déployez. Pour savoir ce qui est pilotable en CLI (cache, debug, tâches), gardez sous la main : Commandes CLI PrestaShop : liste, catégories et options d’aide. Point critique : une boutique “installée” n’est pas une boutique “prête prod” tant que vous n’avez pas verrouillé APP_ENV, les permissions, et la rotation des logs.

Checklist courte “post-install” (souvent oubliée) :

Renommer/sécuriser l’accès admin (URL, IP allowlist si possible) et supprimer/neutraliser tout reliquat d’installation.
Vérifier que le debug est désactivé en prod et que les erreurs ne fuient pas côté front.
Mettre en place les cronjobs (tâches planifiées) via un mécanisme robuste (cron système) et non via un simple ping public non protégé.

Étape 4 — Configurer le fonctionnel sans casser la cohérence technique (taxes, paiement, checkout)

La création d’une boutique PrestaShop 9 “qui vend” passe par des réglages fonctionnels, mais ils ont des impacts techniques : taxes et zones influent sur le calcul panier, règles de prix et performances ; transporteurs et délais conditionnent les pages checkout ; et les modules de paiement posent des contraintes de sécurité (webhooks, IPN, signatures). Traitez ces réglages comme des contrats : quelles devises, quels pays, quels modes de livraison, quelles règles de TVA, et surtout quelles exceptions.

Mini-scénario fréquent (FR/UE) : vous vendez en France et en Belgique, avec livraison en point relais. Si vous ajoutez ensuite un flux B2B (TVA intracommunautaire), vous introduisez des règles de taxe différentes selon :

le type de client (particulier vs pro),
la validité du numéro de TVA,
le pays de livraison/facturation,
les frais de port (soumis à TVA selon règles applicables).

Sans cadrage, ces règles finissent “codées” dans des modules promos, et le panier devient fragile. La solution n’est pas forcément de complexifier : c’est de documenter les cas et de les tester (voir plus bas).

Sur le checkout, évitez les empilements. Chaque “optimisation” (one-page checkout, express checkout, wallet, BNPL) augmente les cas d’erreur : adresses, pays, TVA, règles panier, modules tiers, WAF. Un article utile pour cadrer les compromis UX/tech : Passage en caisse PrestaShop : checkout en une page et express checkout. Si vous ajoutez un paiement en plusieurs fois, testez impérativement en sandbox, tracez les callbacks, et vérifiez l’impact PCI : Paiement en plusieurs fois PrestaShop : tests sandbox, TAEG et conformité PCI-DSS.

Une méthode simple pour valider sans y passer des semaines : définir un plan de test “checkout” en 12 cas max, mais représentatifs. Exemple de matrice de base :

Pays : FR + 1 pays UE
Livraison : domicile + point relais
TVA : particulier + pro (si B2B)
Paiement : CB (avec 3DS2/SCA) + un moyen alternatif
Promos : une règle panier simple + un code promo
Edge cases : stock limite (1 unité), adresse incomplète, email déjà existant

Deux rappels factuels côté conformité : (1) sur les prix, la directive Omnibus impose un affichage cohérent du prix antérieur en cas de promotion — si vous faites du pricing dynamique, vous devez stocker et restituer correctement. Référence : Directive Omnibus PrestaShop : afficher le prix antérieur conforme. (2) sur les paiements carte : le PCI DSS (standard maintenu par le PCI Security Standards Council) définit des exigences de sécurité pour les organisations qui traitent, stockent ou transmettent des données de carte. Plus votre intégration est “redirigée + tokenisée” (sans manipulation de données sensibles côté boutique), plus vous réduisez votre surface de conformité. Référence : PCI Security Standards Council.

Étape 5 — Choisir/adapter thème et modules pour PrestaShop 9 (Twig, services, compatibilité)

PrestaShop 9 pousse plus loin les patterns Symfony : services, contrôleurs modernisés, et une intégration Twig qui impacte thèmes et overrides. Si vous “portez” un thème PrestaShop 8 ou un legacy 1.7, ne vous contentez pas de faire passer la page d’accueil : validez l’ensemble des gabarits critiques (produit, catégorie, recherche, panier, checkout, compte). Les points de friction typiques : surcharge de controllers, hooks manquants, et dépendances front non maîtrisées.

Pour une approche structurée, travaillez avec une checklist de compatibilité thème/module et des tests de non-régression. Le site documente précisément les changements à anticiper : PrestaShop 9 : adapter modules et thèmes aux contrôleurs services et Twig et, avant d’installer 30 modules “indispensables”, lisez : Compatibilité modules PrestaShop 9 : checklist avant migration sécurisée. Même en création from scratch, cette checklist évite de figer un socle sur des modules qui n’existent pas vraiment en PS9.

Critères concrets de sélection (souvent plus utiles que “nombre d’étoiles”) :

Fréquence de mise à jour et compatibilité explicitement annoncée avec PrestaShop 9.
Capacité du module à se désinstaller proprement (tables, overrides, hooks).
Possibilité de configurer un mode “dégradé” (si l’API du fournisseur est HS, le checkout doit-il tomber ?).
Impact performance : pages touchées, requêtes ajoutées, appels externes au rendu.

Enfin, attachez une discipline de performance au front. L’enjeu n’est pas “un score Lighthouse parfait” mais des métriques réelles stables : TTFB, LCP, CLS, cache hit ratio. Google définit les Core Web Vitals comme des métriques orientées expérience utilisateur (chargement, interactivité, stabilité visuelle). Référence : Core Web Vitals & Page Experience. Dans PrestaShop, ça se traduit souvent par : images en WebP/AVIF, lazy-loading maîtrisé, CSS critique (sans casser le rendu), et réduction des JS bloquants. Pour l’implémentation SEO “propre” côté produit (schema.org, images), vous avez une base : SEO PrestaShop : optimiser fiches produits, schema.org et images WebP.

Étape 6 — Durcir sécurité et exploitation (TLS, headers, WAF, droits, sauvegardes)

PrestaShop 9 en production doit être traité comme une appli web exposée, pas comme un CMS “installé et oublié”. Première couche : TLS partout, redirection HTTP→HTTPS, et en-têtes de sécurité adaptés (HSTS, CSP, X-Frame-Options, etc.). Si vous ne pilotez pas les headers, vous laissez des vecteurs simples (clickjacking, XSS via intégrations). Un guide pratico-pratique côté PHP est ici : HTTP Security Headers en PHP : guide CSP, HSTS, X-Frame-Options.

Deuxième couche : durcissement applicatif + WAF pragmatique. Oui, un WAF peut casser un checkout (faux positifs), et c’est exactement pour ça qu’il faut le calibrer plutôt que le désactiver. Le site traite ce sujet sans langue de bois : WAF PrestaShop : réduire les faux positifs et sécuriser le checkout et, côté règles serveur/htaccess et mise à jour, Sécurité PrestaShop : mises à jour, SSL et durcissement .htaccess. À ce stade, votre objectif est de réduire la surface d’attaque sans dégrader le taux de conversion.

Troisième couche : exploitation et gouvernance technique. Mettez en place des sauvegardes chiffrées, testez les restores, et limitez les privilèges (DB user non-admin, clés API à périmètre réduit). OWASP maintient notamment le projet OWASP Top 10, utilisé comme référence de sensibilisation aux risques applicatifs. Référence : OWASP Top 10. Traduction opérationnelle : si vous n’avez pas une cartographie claire (endpoints, modules, clés, accès), vous ne pouvez pas sécuriser correctement. Pour le runbook (backup, rotation logs, patch management), voir : Maintenance PrestaShop : managed services, sécurité serveur, sauvegardes chiffrées.

Checklist “sécurité exploitable” (orientée e-commerce) :

Comptes admin : principe du moindre privilège + revue périodique des accès.
Back-office : restriction IP/VPN si possible + journalisation des connexions.
Fichiers : droits minimaux, pas d’écriture globale, pas d’upload exécutables.
Intégrations : secrets stockés hors dépôt, rotation possible, scope minimal.
Sauvegardes : au moins base + médias, versionnées, test de restauration planifié.

Étape 7 — Préparer la mise en production (cache, CDN, monitoring, SEO) et valider avec des tests reproductibles

La mise en prod d’une boutique PrestaShop 9 se joue sur trois axes : performance, observabilité, et SEO “anti-régression”. Côté performance, activez OPcache, dimensionnez PHP-FPM (pm.max_children cohérent avec CPU/RAM), et choisissez une stratégie cache. Redis pour le cache applicatif est souvent un gain net si correctement instrumenté : Redis PrestaShop : configurer le cache sur VPS ou serveur dédié et, si vous êtes sur LiteSpeed/cPanel, les points OPcache ne sont pas optionnels : OPcache PHP : activer et vérifier l’extension dans cPanel. Pour les forts volumes, ajoutez du cache HTTP (Varnish) et validez l’entête X-Cache : PrestaShop Docker : configurer Varnish VCL et valider le cache X-Cache.

Côté CDN, ne le branchez pas “pour le score”, branchez-le pour réduire la latence et stabiliser le TTFB perçu sur les assets statiques, et surtout pour absorber les pics. En 2026, les différences de modèles (cache rules, shield, HTTP/3, WAF intégré) comptent : CDN en 2026 : comparatif Bunny.net, Cloudflare, Akamai, CloudFront, Fastly. Si vous devez frontaler plusieurs nodes, HAProxy reste un outil robuste, mais exige un vrai travail TLS et rate limiting : HAProxy reverse proxy : terminaison TLS, rate limiting et supervision Prometheus.

Côté QA et monitoring, vous avez besoin de preuves, pas d’impressions. Activez une collecte structurée des erreurs PHP/JS/MySQL et mettez des alertes “actionnables” : PrestaShop monitoring d’erreurs : logs PHP, MySQL, JavaScript et alertes e-mail ; si vous optimisez, mesurez avec profiling : PrestaShop debug profiling : activer et analyser performances SQL et Audit performance PrestaShop : méthode en 6 étapes reproductibles.

Pour rendre les validations reproductibles, définissez un “go/no-go” simple avant ouverture au public :

Tests fonctionnels : créer un compte, ajouter au panier, appliquer promo, payer, recevoir email, générer facture, annuler/rembourser (si applicable).
Tests techniques : cache activé, pages clés sans erreurs 500, temps de réponse stable, logs propres, tâches cron OK.
Tests d’intégrations : webhooks paiement, flux ERP/PIM (si présents), transporteurs (étiquette, tracking), SMTP.
Rollback : procédure claire (restaurer DB + médias, revenir au tag précédent) et fenêtre de bascule maîtrisée.

Enfin, verrouillez la partie SEO technique avant indexation : contrôle des balises, canonicals, robots, pagination, et tests de pages clés ; base de méthode : Audit SEO technique : contrôle qualité avant publication des pages web. En pratique, deux pièges classiques à éviter :

indexer la préprod (ou des URLs de test) par erreur ;
publier un thème “joli” mais avec des templates produit/catégorie qui dégradent la crawlabilité (pagination, filtres à facettes, canonicals incohérents).