Prestashop hosting OVH : guide complet pour e-commerçants

Je gère des boutiques PrestaShop sur des VPS OVH depuis plusieurs années. Pas en tant qu'hébergeur, mais en tant que développeur qui livre des sites e-commerce à des dirigeants de PME — et qui doit s'assurer que ces sites tiennent la charge, restent rapides, et ne tombent pas un vendredi soir. Ce que je partage ici n'est pas une fiche produit OVH. C'est un retour d'expérience terrain : les configurations qui fonctionnent réellement en production, les erreurs que j'ai commises (et corrigées), et les choix techniques qui font la différence entre un site PrestaShop lent et une boutique qui répond en moins d'une seconde. Si vous êtes dirigeant d'une PME e-commerce et que vous cherchez un hébergement PrestaShop OVH fiable, ce guide est écrit pour vous.

Pourquoi OVH pour héberger PrestaShop (et pas Shopify, pas mutualisé)

Cet article fait partie de notre dossier PrestaShop Headless › performance.

La question revient à chaque projet client : pourquoi ne pas prendre un Shopify et en finir ? La réponse tient en trois mots : souveraineté, performance, contrôle. Shopify est une solution américaine, hébergée aux États-Unis, soumise au Cloud Act. Pour une PME française qui traite des données clients européennes, c'est un risque juridique réel depuis l'entrée en vigueur du RGPD.

OVH, c'est l'inverse. Des datacenters à Roubaix, Gravelines, Strasbourg. Des données qui restent en France. Et surtout, un VPS sur lequel vous avez le contrôle total. Pas de limite sur le nombre de produits, pas de commission sur les ventes, pas de surcoût quand votre catalogue dépasse 500 références.

Le mutualisé OVH (offres Web Cloud) peut convenir pour un blog ou un site vitrine. Mais pour PrestaShop en production avec 1 000+ produits, des modules métier et du trafic B2B régulier, c'est insuffisant. Vous partagez les ressources CPU et RAM avec des dizaines d'autres sites. Un pic de trafic chez votre voisin de serveur ralentit votre boutique. J'ai vu des temps de réponse passer de 800 ms à 4 secondes sur un mutualisé un vendredi après-midi — pile au moment où les acheteurs B2B passent leurs commandes de fin de semaine.

Le prestashop hosting OVH sur VPS résout ce problème. Vos ressources sont dédiées. Vous contrôlez PHP, MariaDB, le cache. Vous décidez quand mettre à jour, quoi installer, comment configurer.

VPS vs mutualisé vs dédié : quel hébergement pour quel chiffre d'affaires

J'utilise une grille simple pour orienter mes clients :

La majorité de mes clients PME se situent dans la tranche VPS. Un VPS OVH à 25 €/mois avec 4 vCPU et 8 Go de RAM fait tourner PrestaShop 8 avec 3 000 produits sans broncher. C'est le meilleur rapport qualité/prix du marché pour un hébergeur PrestaShop OVH.

Le dédié se justifie quand vous avez du trafic soutenu (plus de 10 000 visiteurs/jour), un catalogue très lourd avec des déclinaisons complexes, ou des besoins de calcul spécifiques (génération de PDF, IA embarquée). Avant d'y passer, optimisez votre VPS — dans 80 % des cas, le problème n'est pas le matériel mais la configuration.

La configuration OVH qui fonctionne en production

Voici la configuration VPS que je déploie systématiquement pour mes clients PrestaShop :

• VPS OVH Essential : 4 vCPU, 8 Go RAM, 160 Go NVMe SSD
• OS : Ubuntu 22.04 LTS (stabilité, support long terme)
• PHP : 8.1 avec OPcache activé (128 Mo de mémoire partagée)
• MariaDB : 10.11 (innodb_buffer_pool_size = 2 Go minimum)
• Nginx : reverse proxy avec cache statique et compression gzip/brotli
• Redis : 7.x pour les sessions et le cache objet PrestaShop

Le point crucial : innodb_buffer_pool_size. C'est le paramètre qui a le plus d'impact sur la performance de PrestaShop. Je le règle à 25-30 % de la RAM totale du VPS. Sur 8 Go, je mets 2 Go. La différence est immédiate sur les pages catégories et les recherches produit.

Côté PHP, j'active systématiquement opcache.revalidate_freq=60 en production. PrestaShop charge des centaines de fichiers PHP par requête — sans OPcache, chaque visite recompile tout. C'est la première cause d'un site PrestaShop lent que je rencontre chez les nouveaux clients.

Docker + Nginx + MariaDB : la stack que j'utilise

J'ai standardisé ma stack de déploiement autour de Docker. Chaque client obtient un environnement isolé avec sa propre configuration :

# docker-compose.yml simplifiéservices:  prestashop:    image: prestashop/prestashop:8.1    volumes:      - ./modules:/var/www/html/modules      - ./themes:/var/www/html/themes    environment:      - DB_SERVER=mariadb      - DB_NAME=prestashop  mariadb:    image: mariadb:10.11    volumes:      - db_data:/var/lib/mysql    command: --innodb-buffer-pool-size=2G  nginx:    image: nginx:alpine    ports:      - "443:443"    volumes:      - ./nginx/conf.d:/etc/nginx/conf.d  redis:    image: redis:7-alpine

L'avantage de cette approche : reproductibilité. Quand je provisionne un nouveau VPS pour un client, le déploiement prend 25 minutes, configuration comprise. Le même environnement tourne en développement, en préprod et en production. Plus de "ça marche sur ma machine".

Nginx sert de reverse proxy devant PrestaShop. Il gère le SSL (Let's Encrypt via Certbot), la compression, et le cache des fichiers statiques. PrestaShop ne voit jamais le trafic HTTPS directement — c'est plus sûr et plus rapide. Pour un setup headless avec un front Nuxt 3 séparé, Nginx route le trafic entre le front et l'API PrestaShop sur le même VPS.

Les 5 erreurs qui rendent votre PrestaShop lent sur OVH

1. OPcache désactivé ou mal configuré. Vérifiez avec phpinfo(). Si opcache.enable est à 0, chaque requête recompile PHP. Sur un catalogue de 2 000 produits, ça peut tripler le temps de réponse.
2. innodb_buffer_pool_size trop petit. La valeur par défaut de MariaDB est 128 Mo. Pour PrestaShop, c'est dérisoire. Montez à 2 Go minimum sur un VPS 8 Go. Vous verrez la différence sur la première requête catalogue.
3. Pas de cache objet (Redis). PrestaShop utilise le cache fichier par défaut. Sur un VPS avec SSD NVMe, c'est correct. Mais Redis en mémoire réduit encore le temps de réponse de 30 à 50 % sur les pages catégories.
4. Modules mal codés qui font des requêtes SQL en boucle. J'ai vu un module de filtres produits qui exécutait 200+ requêtes par page catégorie. Le serveur n'y est pour rien — c'est le code. Activez le Profiler PrestaShop (_PS_DEBUG_PROFILING_) pour identifier les coupables.
5. Images non optimisées. PrestaShop régénère les miniatures à la volée si elles n'existent pas. Un catalogue de 3 000 produits avec 5 photos chacun, ça fait 15 000 images. Si les miniatures ne sont pas pré-générées, chaque visite déclenche un redimensionnement. Lancez la régénération depuis le back-office après chaque import.

Sécuriser votre VPS (SSH, firewall, certificats)

Un VPS exposé sur Internet sans sécurisation, c'est une cible. Voici le minimum que j'applique sur chaque hébergement PrestaShop OVH que je configure :

• SSH par clé uniquement : désactiver l'authentification par mot de passe (PasswordAuthentication no dans /etc/ssh/sshd_config)
• Port SSH non standard : changer le port 22 par un port aléatoire (ex : 2222). Ça élimine 90 % des scans automatiques
• Firewall UFW : n'ouvrir que les ports 80, 443 et votre port SSH. Tout le reste est fermé
• Fail2ban : bannir les IP après 3 tentatives de connexion échouées
• Let's Encrypt : certificat SSL gratuit, renouvelé automatiquement via Certbot
• Mises à jour automatiques : unattended-upgrades pour les patchs de sécurité Ubuntu

Côté PrestaShop : renommez le dossier /admin par un nom aléatoire, désactivez l'affichage des erreurs PHP en production, et vérifiez que le fichier .htaccess (ou la config Nginx équivalente) bloque l'accès aux dossiers sensibles (/var, /config, /vendor).

Monitoring et alertes : ne plus découvrir les pannes par vos clients

Le pire scénario : un client vous appelle pour dire que sa boutique est en panne depuis deux heures. Vous n'aviez rien vu. C'est la réalité de la plupart des hébergements PrestaShop sans monitoring.

Ce que je mets en place systématiquement :

• Healthcheck HTTP : un script qui vérifie toutes les 5 minutes que la page d'accueil répond en HTTP 200 avec un temps de réponse < 2 secondes
• Monitoring disque : alerte à 80 % d'utilisation. Les logs PrestaShop et les backups peuvent remplir un disque en quelques semaines si personne ne regarde
• Monitoring RAM : alerte si la consommation dépasse 85 %. MariaDB est gourmand — un innodb_buffer_pool_size trop élevé peut saturer la mémoire
• Logs centralisés : les erreurs PHP, les erreurs Nginx et les slow queries MariaDB dans un même endroit, consultables sans SSH

Pour l'analytics, j'utilise Matomo en self-hosted plutôt que Google Analytics — souveraineté des données oblige. Matomo tourne sur le même VPS sans impact notable sur les performances.

Migrer vers OVH sans downtime

La migration est le moment le plus stressant pour un dirigeant e-commerce. Chaque minute de downtime, ce sont des commandes perdues. Voici la méthode que j'applique :

1. Préparer le VPS cible : installer toute la stack (Docker, Nginx, MariaDB, Redis, PHP) et configurer l'environnement complet
2. Copier les fichiers : rsync des fichiers PrestaShop (modules, thèmes, images) vers le nouveau serveur
3. Exporter la base de données : mysqldump complet, puis import sur le nouveau MariaDB
4. Tester sur IP : accéder au nouveau serveur directement par son IP pour vérifier que tout fonctionne
5. Basculer le DNS : modifier les enregistrements A et AAAA pour pointer vers le nouveau VPS
6. Synchroniser les dernières commandes : pendant la propagation DNS, synchroniser les commandes passées sur l'ancien serveur

Le temps de propagation DNS est le seul moment d'incertitude. Pour le réduire, je baisse le TTL des enregistrements à 300 secondes (5 minutes) 48 heures avant la migration. Le jour J, la bascule est quasi instantanée.

Vous gérez une boutique PrestaShop et vous cherchez un hébergement fiable, souverain et performant sur OVH ? Je configure et maintiens des VPS e-commerce pour des PME françaises. Prenez rendez-vous pour un audit gratuit de votre hébergement actuel.