Table des matières :
- SLA 99,9 % sur un VPS OVHcloud : le calcul est simple, le périmètre beaucoup moins
- Fonctionnalités d’un VPS OVHcloud : ce que vous achetez réellement (et ce que vous n’achetez pas)
- Limites techniques d’un VPS OVHcloud : CPU steal, I/O, réseau et “single host”
- Monter une stack PrestaShop sur VPS OVHcloud : réglages concrets (PrestaShop 8/9, PHP 8.2/8.3)
- Construire de la disponibilité au-dessus du SLA : backup, DNS, monitoring, bascule
- Sécurité et responsabilités sur VPS : IAM, durcissement et surface d’attaque réelle
- Quand un VPS OVHcloud est le bon choix, et quand il devient un piège technique
SLA 99,9 % sur un VPS OVHcloud : le calcul est simple, le périmètre beaucoup moins
Un SLA à 99,9 % signifie, mathématiquement, une indisponibilité maximale de 0,1 % sur la période de mesure. Sur un mois de 30 jours, ça représente 43 min 12 s d’indisponibilité tolérée ; sur un an (365 jours), 8 h 45 min 36 s. Si votre e-commerce a des pics (soldes, TV, influence), ces “quelques dizaines de minutes” ne sont pas une métrique anodine : un incident de 30 minutes pendant un pic peut coûter plus qu’un an de “SLA respecté” sur des périodes creuses.
Le point que beaucoup ratent : un SLA n’est pas un SLO. Le SLA est une promesse contractuelle (souvent avec des crédits), mesurée selon la définition du fournisseur. Votre SLO, lui, doit être aligné sur l’expérience utilisateur (latence, taux d’erreurs, capacité à finaliser un checkout). Autrement dit : un VPS “up” mais avec un stockage saturé et un MySQL en attente d’I/O n’est pas forcément “down” au sens du SLA, alors que votre boutique est inutilisable.
Sur un VPS OVHcloud, la disponibilité annoncée couvre généralement la plateforme VPS (hyperviseur + réseau + stockage selon périmètre), pas votre stack (Nginx/Apache, PHP-FPM, MariaDB, Redis), ni vos déploiements. Le bon réflexe est de lire le SLA comme une délimitation des responsabilités : qu’est-ce qui est mesuré, comment, et dans quels cas le crédit s’applique ? Pour éviter les mauvaises surprises, gardez une checklist simple lorsque vous évaluez un SLA “99,9 %” :
- Période de mesure : mois calendaire ? année ? fenêtre glissante ?
- Définition de l’indisponibilité : perte totale de connectivité ? seuil d’erreurs ? depuis quel point de mesure ?
- Exclusions : maintenance planifiée, incidents causés par configuration client, incidents tiers (DNS/paiement/CDN), force majeure.
- Procédure : faut-il ouvrir un ticket ? dans quel délai ? quelles preuves fournir (horodatages, logs, monitoring) ?
- Remboursement : crédits (avoir) plutôt que cash, plafonds, conditions d’éligibilité.
Si vous voulez vérifier ce que le fournisseur met concrètement derrière “VPS” (gammes, options, promesse commerciale), une page de référence utile est la page produit officielle OVHcloud VPS (à compléter ensuite par la lecture des conditions contractuelles applicables à votre offre).
Enfin, gardez une distinction opérationnelle souvent négligée : disponibilité ≠ continuité métier. Exemple réaliste (contexte France) : votre boutique est hébergée près de vos clients (latence faible vers Paris/Lyon), mais votre tunnel de paiement dépend d’un PSP externe. Le VPS peut être “OK” alors que l’utilisateur ne peut plus payer. Dans votre SLO e-commerce, la métrique la plus honnête n’est pas “VM joignable”, mais taux de checkouts réussis et temps de réponse du checkout.
Fonctionnalités d’un VPS OVHcloud : ce que vous achetez réellement (et ce que vous n’achetez pas)
Un VPS est une machine virtuelle basée sur une virtualisation de type KVM (dans la majorité des offres du marché). Concrètement, vous obtenez un couple vCPU / RAM, un disque (souvent SSD/NVMe selon gamme), une connectivité IP (IPv4 dédiée, parfois IPv6), et un accès root. L’intérêt est clair pour un stack PrestaShop : vous maîtrisez le système (Debian/Ubuntu), la version de PHP (8.2/8.3 en 2026), les modules, les limites FPM, le reverse proxy, etc.
Sur le plan “terrain”, ce que vous achetez aussi (et qu’on oublie d’écrire) :
- Liberté d’architecture : Nginx en frontal, Apache derrière, ou Nginx + PHP-FPM, séparation web/cron, ajustement fin des timeouts.
- Contrôle des versions : PHP, MariaDB, Redis, Node (assets), et possibilité de figer les versions pour éviter les surprises en mise à jour.
- Choix de localisation : OVHcloud étant un acteur européen avec des datacenters en France (par ex. Roubaix, Gravelines, Strasbourg), vous pouvez aligner proximité réseau et conformité (données hébergées en UE / en France selon besoin). Pour un site majoritairement français, cela aide souvent à maintenir une latence basse vers les zones denses (Île-de-France, Hauts-de-France, Auvergne-Rhône-Alpes), sans promettre des millisecondes “magiques”.
La fonctionnalité la plus sous-estimée, côté exploitation, c’est la capacité à standardiser : images, configuration, scripts d’init, et déploiements reproductibles. Si vous orientez votre infra vers Docker, votre VPS devient un hôte simple pour orchestrer quelques services (Nginx, PHP, MariaDB, Redis, job runner). Pour cadrer ce point, vous pouvez recouper avec l’article interne : VPS pour Docker : critères techniques et ressources recommandées.
Ce que vous n’achetez pas : du managé. Un VPS ne vous donnera pas de réplication automatique, pas de patch management, pas d’optimisation applicative, pas de supervision fine “incluse” utile pour votre stack (au mieux du ping/HTTP basic). Si vous cherchez un hébergement qui absorbe l’exploitation (patching, hardening, tuning), ce n’est pas la bonne classe de produit.
Un point concret à anticiper : sur beaucoup de VPS, l’envoi d’emails sortants (SMTP) est restreint ou surveillé (anti-spam). Même si ce n’est pas “techniquement compliqué”, c’est une source classique de tickets en production (mails transactionnels qui partent en spam, IP en mauvaise réputation, port bloqué). Pour un e-commerce, la meilleure pratique reste de déléguer l’email transactionnel à un service spécialisé (et de surveiller le taux de délivrabilité), plutôt que d’essayer de “faire SMTP” depuis le VPS.
Pour cadrer le choix d’offre, l’article interne Hébergement PrestaShop : mutualisé, VPS ou cloud managé, comment choisir est une base solide.
Limites techniques d’un VPS OVHcloud : CPU steal, I/O, réseau et “single host”
La première limite d’un VPS, quel que soit le fournisseur : vous êtes sur un hôte mutualisé. En charge, ça se traduit souvent par du CPU steal (temps CPU “volé” par l’hyperviseur quand d’autres VMs consomment), et par une variabilité de latence. Pour un PrestaShop, ce n’est pas abstrait : un pic de steal time peut faire exploser vos temps de génération PHP, et donc vos TTFB et vos Core Web Vitals. Mesurez-le : top (colonne st), mpstat -P ALL 1, et corrélez avec vos latences applicatives.
Mini-signal utile côté e-commerce : si vous observez des pics de latence sans hausse de trafic et sans hausse de vos requêtes SQL, le CPU steal (ou une contention I/O) est un suspect crédible. C’est exactement le genre de problème qui ne “viole” pas forcément un SLA, mais ruine votre conversion.
Le second point dur : le stockage. Beaucoup de boutiques tombent non pas sur le CPU, mais sur l’I/O (DB, sessions, logs, indexation, imports). Sur un VPS, les performances disque peuvent fluctuer selon la contention sur l’hôte. Avant de valider une machine pour de la prod, faites un test contrôlé : fio pour le débit et l’IOPS, et activez le slow query log côté MySQL/MariaDB. Sur PrestaShop, l’article interne PrestaShop MySQL : analyser slow query log et optimiser index vous donne une méthodo applicable immédiatement.
Pour rendre le diagnostic actionnable, voici une grille simple “symptôme → piste” (utile quand vous devez trancher vite) :
| Symptôme observé | Piste la plus probable | Où regarder en premier |
|---|---|---|
| Pages qui “moulinent” puis reviennent | I/O wait, DB lente, locks | iostat, slow query log, métriques MariaDB |
| 502/504 aléatoires en pic | PHP-FPM saturé, timeouts upstream | logs Nginx/Apache, php-fpm status, pm.max_children |
| TTFB instable sans changement de code | CPU steal / contention hôte | top st, mpstat, corrélation avec APM |
| Back-office lent, front parfois OK | DB/IO ou tâches cron lourdes | cron, SHOW PROCESSLIST, I/O |
Troisième limite : le réseau et les dépendances externes. Le SLA couvre rarement les incidents “de l’autre côté” (DNS tiers, CDN, passerelle de paiement, ERP). Un VPS avec 1 Gbps théorique ne garantit pas une latence stable vers vos APIs. Si votre checkout dépend de 3 services (paiement, anti-fraude, ERP), vous devez instrumenter les timeouts, retries, et circuit breakers (ou au minimum des timeouts courts + messages d’erreur explicites). Côté DNS, la façon dont vous gérez TTL et bascule fait une grosse différence en incident : Zone DNS OVHcloud : propagation, TTL et bonnes pratiques de configuration.
Dernier point, souvent minimisé : un VPS est un single host par défaut. Si l’hyperviseur ou le stockage attaché a un problème, votre VM est indisponible. Vous ne “scalez” pas ça avec un apt upgrade. Pour du e-commerce à enjeu, ça impose soit de l’actif/actif (deux nœuds + LB), soit au minimum un plan de restauration testé (snapshots + backups + runbook). Et, très concrètement : si votre objectif est “je veux pouvoir restaurer en 30 minutes”, alors vous devez répéter une restauration complète jusqu’à ce que 30 minutes devienne une routine, pas une hypothèse.
Monter une stack PrestaShop sur VPS OVHcloud : réglages concrets (PrestaShop 8/9, PHP 8.2/8.3)
Sur une base 2026, un choix raisonnable est Debian 12 ou Ubuntu 24.04 LTS, avec PHP 8.2 ou 8.3 selon compatibilité de votre version de PrestaShop et de vos modules. PrestaShop 9 (Symfony 6.4) a des contraintes de versions et une documentation parfois incohérente : l’article interne PrestaShop 9 : versions PHP recommandées et incohérences de documentation évite les erreurs classiques (versions “supportées” sur le papier mais instables en prod avec certains modules).
Une façon pragmatique de dimensionner (sans faire de “science exacte”) est de partir de 3 profils : boutique petite, moyenne, et “catalogue lourd”. Sans figer de chiffres universels, voici une base de discussion réaliste pour un VPS (hors pics exceptionnels, et en supposant un CDN pour les assets) :
| Profil | Indices typiques | Base VPS souvent cohérente (ordre de grandeur) |
|---|---|---|
| Petite boutique | < 5 000 produits, trafic modéré | 2–4 vCPU, 4–8 Go RAM |
| Boutique “mid” | 5 000–50 000 produits, promos régulières | 4–8 vCPU, 8–16 Go RAM |
| Catalogue lourd | > 50 000 produits, facettes + imports | 8+ vCPU, 16–32 Go RAM (souvent déjà à la limite d’un VPS) |
Ce tableau n’a qu’un but : vous pousser à valider par la mesure (APM, charge, fio, slow queries), plutôt que par l’intuition.
Côté serveur web, la réalité est simple : la plupart des gains viennent d’un PHP-FPM bien dimensionné et d’un cache applicatif cohérent. Ne configurez pas pm.max_children “au pif” : calculez-le à partir de la RAM disponible et de la consommation moyenne d’un worker (ps -ylC php-fpm --sort:rss). Ensuite, corrigez les limites d’OPcache (taille, interned strings, JIT si pertinent) et éliminez les invalidations de cache inutiles. Références internes utiles : PHP-FPM : comprendre le flux d’exécution avec Nginx et Apache et PHP OPcache : paramètres recommandés pour optimiser les performances.
Sur PrestaShop, la perf ne se gagne pas uniquement “au niveau serveur”. Vous devez traiter les causes structurelles : requêtes SQL, surcharges de hooks, facettes, surcharge de template, images. L’article PrestaShop performance : optimiser gros catalogues et Core Web Vitals et celui sur le cache PrestaShop : optimiser performance via cache Smarty, CCC et CDN sont directement actionnables.
Côté “briques”, Redis est souvent un ajout rentable pour sessions/cache : le site officiel définit Redis ainsi : « Redis is an in-memory data structure store, used as a database, cache, and message broker. » (redis.io). L’intérêt concret sur VPS : vous réduisez les accès disque (sessions), vous lissez certains pics, et vous reprenez la main sur des goulots d’étranglement “invisibles” quand tout passait en fichiers.
Construire de la disponibilité au-dessus du SLA : backup, DNS, monitoring, bascule
La règle : un SLA 99,9 % ne remplace pas un plan d’exploitation. Vous devez formaliser RPO/RTO (perte de données maximale acceptable / temps de rétablissement). Un e-commerce qui traite des commandes et des paiements ne devrait pas découvrir en incident que “snapshot ≠ backup” ou que “backup non restauré ≠ backup”. Faites une restauration complète (fichiers + base) en préprod, chronométrez, et documentez.
Pour rendre ça concret, voici un exemple de cadrage (à adapter) :
| Élément | RPO cible | RTO cible | Implication technique minimale |
|---|---|---|---|
| Base de données commandes | 5–15 min | 30–60 min | dumps fréquents + rétention + test de restore |
| Fichiers (images produits) | 1–6 h | 1–4 h | sync incrémental + stockage externe |
| Config (Nginx/PHP) | 24 h | 1 h | infra as code / backups Git + procédure |
Deux leviers pragmatiques pour dépasser le “single host” sans sur-architecturer : (1) CDN pour absorber le trafic statique et lisser les pics, (2) bascule DNS (ou LB) vers un nœud de secours. Le CDN a aussi un impact SEO/perf mesurable : en 2026, les stratégies varient fortement selon provider et fonctionnalités (cache rules, image optimization, HTTP/3). Si vous devez trancher, la comparaison interne CDN en 2026 : comparatif Bunny.net, Cloudflare, Akamai, CloudFront, Fastly vous évite de choisir “au logo”.
Sur la bascule DNS : elle n’est efficace que si vous avez (a) un TTL raisonnable défini en amont, (b) une cible de secours réellement prête (DB restaurable, fichiers synchronisés, certificats TLS, variables d’environnement), (c) un runbook (qui fait quoi, en combien de temps). En France, c’est typiquement ce qui fait la différence entre “incident maîtrisé en 40 minutes” et “nuit blanche”.
Le monitoring, enfin, doit être orienté symptôme utilisateur. Une VM “OK” n’empêche pas un PHP-FPM saturé, un MariaDB en lock, ou un disque plein. Déployez au minimum : métriques système (CPU, steal, load, I/O wait), métriques applicatives (latence, taux 5xx, queue jobs), et logs centralisés. Pour démarrer proprement : Netdata : activer et configurer les collectors pour monitoring temps réel et Prometheus : configuration des alertes, métriques et requêtes PromQL. Et pour l’alerting opérationnel côté équipe : PrestaShop : module d’alerting temps réel Slack, Discord et email.
Sécurité et responsabilités sur VPS : IAM, durcissement et surface d’attaque réelle
Sur VPS, la frontière est nette : le fournisseur gère l’infra, vous gérez l’OS et tout le runtime. Ça implique patching, pare-feu, SSH, journaux, permissions, sauvegardes, et gestion des secrets. Le facteur III de The Twelve-Factor App pose une règle simple et robuste : « Store config in the environment. » (12factor.net). Sur un VPS, ça se traduit par : pas de secrets en dur dans le code, rotation, et idéalement un coffre (même basique) plutôt qu’un .env copié dans 4 dossiers.
Pour PrestaShop, l’écosystème module/thème augmente mécaniquement la surface d’attaque (hooks, overrides, dépendances). Le durcissement n’est pas optionnel : permissions fichiers, désactivation de fonctions PHP à risque selon contexte, WAF, CSP, limitation de l’admin, rate limiting, et surtout process de mise à jour. Si vous partez d’un existant, commencez par une méthode d’audit structurée : Audit sécurité PrestaShop : méthodologie, livrables et durcissement et, en cas d’incident, un runbook de confinement : Sécurité PrestaShop : plan de réponse à incident et containment immédiat.
Ajoutez une couche “opérationnelle” souvent oubliée sur VPS :
- Comptes et accès : pas de root en SSH direct, clés SSH uniquement, 2FA sur le compte fournisseur, journalisation des accès admin.
- Exposition réseau : ports strictement nécessaires (80/443/22), filtrage par IP quand possible (admin, SSH), fail2ban si adapté.
- Hygiène applicative : suppression des modules non maintenus, rotation des clés, audit des overrides.
- Défense contre l’automatisation hostile : rate limiting sur endpoints coûteux (recherche, facettes), protection du back-office, captchas ciblés si nécessaire.
À noter : l’anti-DDoS “inclus” (souvent annoncé sur les offres VPS) n’est pas un WAF applicatif, et ne bloque pas un botnet qui fait du scraping “lent” ou qui tape des endpoints coûteux (recherche, facettes, API). Si vous avez des endpoints sensibles, mettez des limites côté reverse proxy (Nginx limit_req, limit_conn), sécurisez l’admin, et fixez les timeouts de manière agressive sur les upstreams externes.
Quand un VPS OVHcloud est le bon choix, et quand il devient un piège technique
Un VPS OVHcloud est un bon choix quand vous voulez : un environnement Linux root, une stack maîtrisée, une facture prévisible, et une charge “raisonnable” (boutique small/mid, trafic stable, pas de batch nocturne violent, pas de recherche full-text lourde). Typiquement, c’est cohérent pour une boutique PrestaShop avec Redis, une DB correctement indexée, des assets servis via CDN, et un pipeline de déploiement discipliné.
En pratique, le bon “signal” que vous êtes dans la zone de confort du VPS : vous pouvez faire une montée en charge (même artisanale) et observer que vos limites sont progressives (latence qui augmente doucement, CPU qui monte de façon corrélée), pas des murs d’instabilité (I/O qui s’écroule, steal qui grimpe, timeouts en cascade).
Ça devient un piège dès que vous vous mettez à empiler des besoins de type “dédié déguisé” : gros catalogue + imports continus + facettes agressives + recherche avancée + pics marketing, le tout sur une seule VM. À ce stade, le problème n’est pas “OVHcloud”, c’est la nature du VPS : contention I/O, CPU steal, et absence de redondance. Si vous dimensionnez pour du gros volume, regardez plutôt le dédié (meilleure stabilité CPU/IO) : Serveur dédié PrestaShop : dimensionnement matériel pour 100 000 produits et, si vous partez from scratch, Serveur dédié PrestaShop : installation et optimisation Debian pour gros catalogue.
Enfin, si votre objectif réel est la résilience (multi-AZ, auto-healing, scaling, composants managés), le VPS n’est pas “mauvais”, il est juste hors-cible : vous allez ré-implémenter à la main ce que le cloud managé fournit déjà (au prix de votre temps et de votre risque). Dans ce cas, repartez de vos contraintes (SLO, RTO, RPO, conformité, budget Ops), et comparez froidement les coûts de possession — y compris humains.
Un moyen simple de trancher sans idéologie : si votre “plan de disponibilité” tient principalement sur des interventions humaines (bascule manuelle, restauration manuelle, tuning manuel en urgence), alors vous payez votre SLA en charge mentale et risque opérationnel. L’article interne PrestaShop open source : avantages, limites et coûts de possession fournit justement un cadre pour éviter les décisions “infrastructure au rabais, exploitation au prix fort”.
