OVHcloud .ovhconfig : changer version PHP, moteur et mode d’exécution

Table des matières :

1. .ovhconfig sur OVHcloud : ce que ce fichier pilote réellement (et ce qu’il ne pilote pas)
2. Changer la version PHP avec app.engine.version : stratégie réaliste pour PrestaShop (1.7/8/9)
3. Moteur (app.engine), environnement et WAF (http.firewall) : réglages qui ont des effets de bord
4. Mode d’exécution (app.engine.mode) : CGI vs PHP-FPM, performances et compatibilité PrestaShop
5. Procédure de changement .ovhconfig sans downtime « surprise » (et avec rollback en 2 minutes)
6. Dépannage : 500 après changement, pages blanches, 403, et décalage PHP CLI/Web

.ovhconfig sur OVHcloud : ce que ce fichier pilote réellement (et ce qu’il ne pilote pas)

Sur l’hébergement mutualisé OVHcloud (Web Hosting, et une partie des anciennes offres « Cloud Web »), .ovhconfig est le point d’entrée le plus simple pour déclarer l’environnement d’exécution : moteur applicatif, version de PHP, et (selon l’offre) mode d’exécution. Ce fichier est lu par l’infrastructure OVHcloud au moment de servir le vhost ; il ne s’agit pas d’un « réglage PHP » au sens php.ini, mais d’une sélection de runtime côté plateforme.

Concrètement, les clés qui vous intéressent pour un stack PrestaShop sont généralement : app.engine (moteur), app.engine.version (version), app.engine.mode (mode), environment (prod/dev côté plateforme) et parfois http.firewall (WAF OVHcloud). L’analyse est stricte : une faute de frappe ou une valeur non supportée peut provoquer un HTTP 500 immédiat (le vhost ne démarre pas sur le bon runtime). Autre piège classique : confondre « version PHP web » (pilotée par .ovhconfig) et version PHP CLI (celle que vous obtenez en SSH), qui peut être différente.

Ce que .ovhconfig ne pilote généralement pas (et qui surprend souvent après une migration ou un changement d’offre) :

• les directives fines type memory_limit, max_execution_time, post_max_size, upload_max_filesize (ce sont des réglages PHP, pas du runtime) ;
• la configuration Apache/Nginx (headers, compression, HTTP/2/3, etc.) ;
• la configuration de pools PHP-FPM (nombre de workers, pm.max_children, etc.) : sur mutualisé, vous choisissez un mode, pas la taille du pool ;
• la version de MySQL/MariaDB, ni les paramètres serveur SQL ;
• la version de PHP utilisée par les tâches cron/CLI (qui dépend de l’environnement SSH, si disponible, et des binaires exposés).

À vérifier aussi : selon les configurations, .ovhconfig s’applique à l’arborescence du dossier où il est placé. En pratique, évitez d’avoir plusieurs .ovhconfig « oubliés » à différents niveaux (ex. un dans www/ et un autre dans www/preprod/) sans intention claire : c’est typiquement ce qui crée des incohérences entre front-office, back-office et scripts annexes.

Dernier point : .ovhconfig est un mécanisme spécifique à l’hébergement mutualisé. Sur un VPS ou un dédié, vous ne « changez pas PHP » avec .ovhconfig, vous gérez des paquets/containers et la config de votre serveur (Apache/Nginx + PHP-FPM, etc.). Si vous êtes en train de vous demander si le mutualisé est encore adapté à votre volumétrie, gardez sous la main : Hébergement PrestaShop : mutualisé, VPS ou cloud managé, comment choisir et, côté OVH, VPS OVHcloud : fonctionnalités, SLA 99,9 % et limites techniques.

Enfin, petit rappel « contexte France/UE » sans marketing : OVHcloud est un acteur historiquement français (siège à Roubaix) et opère plusieurs datacenters en France et en Europe. Sur mutualisé, vous ne choisissez pas toujours finement la localisation ; si vous avez une exigence RGPD, latence ou résidence des données, appuyez-vous sur les informations affichées dans le Manager et sur vos mesures (latence, disponibilité), plutôt que sur des suppositions.

Changer la version PHP avec app.engine.version : stratégie réaliste pour PrestaShop (1.7/8/9)

Pour PrestaShop, « changer la version PHP » n’est pas un détail : c’est un changement d’ABI applicative (extensions, compatibilité modules, warnings devenant fatals, compat Symfony/Doctrine, etc.). En 2026, les boutiques qui traînent encore sur PHP 7.4 ou 8.0 le font souvent par héritage, mais c’est rarement défendable côté sécurité et maintenance. Pour PrestaShop 9 en particulier, la compatibilité PHP est un sujet mouvant et la documentation n’est pas toujours cohérente : voir PrestaShop 9 : versions PHP recommandées et incohérences de documentation.

La stratégie la plus « réaliste » (et la moins risquée) n’est pas de choisir la version PHP « la plus récente possible » par principe, mais de :

• partir de votre socle (version PrestaShop exacte + thème + modules critiques : paiement, search, marketplace, ERP, transporteurs) ;
• identifier une version cible qui est à la fois supportée par PrestaShop et par vos modules ;
• valider sur préproduction (ou clone) avec un jeu de tests minimal (checkout, BO, génération de PDF, imports/exports, cron).

Le minimum opérationnel sur OVHcloud mutualisé : éditer .ovhconfig au niveau du répertoire racine servi par votre domaine (souvent www/, parfois une racine différente selon le Manager). Exemple de base, typiquement adapté à une base PrestaShop 8.x/9.x si votre offre propose PHP 8.2 :

app.engine=php
app.engine.version=8.2
app.engine.mode=phpfpm
environment=production
http.firewall=security

Quelques points à ne pas rater : (1) gardez un rollback (ex. dupliquez en .ovhconfig.bak avant modification), (2) évitez tout « mélange » avec d’anciennes méthodes OVH (SetEnv PHP_VER dans .htaccess sur des vieilles offres), (3) laissez passer quelques minutes pour propagation interne, puis validez via un phpinfo() temporaire (à supprimer ensuite), et surtout via le back-office PrestaShop (pages modules, checkout, génération de PDF).

Pour valider sans exposer un phpinfo(), une alternative très simple est un fichier temporaire qui n’affiche que la version :

<?php
header('Content-Type: text/plain; charset=utf-8');
echo 'PHP web = ' . PHP_VERSION . PHP_EOL;

Déposez-le, appelez-le une fois, supprimez-le. Ça limite l’exposition d’informations sensibles (extensions, chemins, variables d’environnement), ce qui est particulièrement important sur un e-commerce.

Si vous maintenez des modules custom ou un checkout complexe, ne faites pas ça à l’aveugle : faites tourner une batterie de tests et au minimum un smoke test automatisé. Même sur mutualisé, vous pouvez reproduire en local via Docker avant de toucher la prod ; côté tests de module, la logique est la même que dans ps_onepagecheckout : exécuter les tests PHPUnit avec Docker et PrestaShop.

Checklist « compatibilité PHP » utile avant bascule (rapide, mais efficace) :

• vérifier que vos extensions requises sont bien là côté web (au minimum intl, pdo_mysql, gd/imagick selon stack, zip) ;
• scanner vos logs après navigation : un passage à une version supérieure fait souvent remonter des warnings/dépréciations qui, combinés à certains réglages, peuvent devenir bloquants ;
• vérifier les tâches non interactives : crons (indexation, relances panier, exports), webhooks, webservices (ERP/marketplace).

Moteur (app.engine), environnement et WAF (http.firewall) : réglages qui ont des effets de bord

Sur .ovhconfig, app.engine sert à choisir la « famille » de runtime gérée par la plateforme (PHP, parfois Node/Python selon offres). Pour PrestaShop, c’est trivial : app.engine=php. Là où ça devient moins trivial, c’est quand on a un front proxy (CDN), une appli annexe (webhooks), ou un sous-dossier pour de la préprod : l’infrastructure OVHcloud va associer votre vhost à un runtime et des règles ; si vous essayez d’« empiler » des comportements (ex. PHP pour / et autre chose pour /api), vous allez vous heurter aux limites structurelles du mutualisé.

La clé environment est souvent laissée à production (et c’est très bien). Sur un stack Symfony, l’idée est claire : la prod ne doit pas tourner avec du debug. Symfony le dit explicitement : « Debug mode should never be enabled in production. » (documentation Symfony, environnements : https://symfony.com/doc/current/configuration/environments.html). Dans PrestaShop, l’équivalent opérationnel reste defines.inc.php / _PS_MODE_DEV_ et la gestion fine des logs ; ne comptez pas sur environment=development pour « résoudre » une page blanche proprement.

Un bon réflexe (surtout quand vous changez PHP) : séparer diagnostic plateforme et diagnostic applicatif.

• Si vous avez un 500 « immédiat » dès la première requête, avant même un début de rendu HTML, suspectez d’abord un problème de runtime (app.engine.version non supportée, app.engine.mode indisponible, fichier mal parsé).
• Si vous avez des erreurs uniquement sur certaines routes (ex. paiement, upload image, BO modules), suspectez plutôt un module, un override, un problème de permissions, ou… le WAF.

Enfin, http.firewall (quand disponible) pilote le WAF OVHcloud (souvent security vs none). Sur un e-commerce, désactiver le WAF peut faire disparaître des faux positifs, mais c’est aussi enlever une couche de filtrage. Le piège récurrent : une règle WAF qui déclenche sur des payloads de checkout, d’upload d’images, ou certains endpoints de modules, et vous récupérez des 403 qui ressemblent à des problèmes de droits.

Avant de toucher à ce réglage, gardez une approche « triage » :

• est-ce que le 403 est reproductible sur un endpoint précis (ex. /module/... ou /admin...) ?
• voyez-vous une trace côté PrestaShop (log applicatif) ? Si non, ça pointe plutôt vers la couche HTTP/WAF.
• le problème survient-il uniquement avec certains contenus (longue chaîne, caractères spéciaux, JSON, base64) ?

Avant de désactiver le firewall « au hasard », lisez une méthodo de tri : Diagnostiquer une erreur 403 Forbidden : causes et dépannage étape par étape. Si vous devez réellement maîtriser les règles de filtrage, le mutualisé n’est pas l’endroit : migrez vers une infra où vous contrôlez WAF/CDN et logs (et où vous pouvez corréler précisément une requête à une règle).

Mode d’exécution (app.engine.mode) : CGI vs PHP-FPM, performances et compatibilité PrestaShop

Quand OVHcloud le propose, app.engine.mode fait une différence concrète : php (souvent CGI/FastCGI « simple » côté plateforme) versus phpfpm (Process Manager). Du côté PHP, le principe est documenté : « PHP-FPM (FastCGI Process Manager) is an alternative PHP FastCGI implementation with some additional features useful for sites of any size, especially busier sites. » (PHP manual : https://www.php.net/manual/en/install.fpm.php). Sur un mutualisé, vous ne gérez pas les pools FPM vous-même, mais vous bénéficiez généralement d’une exécution plus stable sous charge.

Sur PrestaShop, le gain est rarement « magique », mais il est souvent visible sur deux axes :

• régularité (moins de variations fortes de TTFB quand plusieurs requêtes arrivent en rafale) ;
• résilience quand vous avez beaucoup de hooks/modules, ou des pages lourdes (catégories filtrées, facettes, recherche, BO).

Pour objectiver (sans outils lourds), mesurez avant/après avec une méthode simple et répétable :

• vider les caches applicatifs si votre procédure le prévoit (et refaire un « warm-up » en visitant les pages clés),
• effectuer 10 à 20 requêtes sur 2–3 URLs représentatives (home, catégorie, produit, panier),
• comparer la médiane du TTFB plutôt que le « meilleur score » (les extrêmes trompent vite).

Un tableau de lecture rapide (utile quand vous décidez si vous activez phpfpm ou si vous restez en mode par défaut) :

Point de comparaison	CGI / app.engine.mode=php	PHP-FPM / app.engine.mode=phpfpm
Stabilité sous charge	plus variable selon plateformes	souvent plus régulière
Latence à froid	peut être plus pénalisante	souvent mieux amortie
Compatibilité	parfois « ça marche partout » sur vieilles offres	peut être indisponible selon offre / gamme
Dépannage	erreurs parfois plus opaques	logs/diagnostic parfois plus lisibles côté runtime

Justement, OPcache : ne le laissez pas hors-sujet. PHP est explicite : « OPcache improves PHP performance by storing precompiled script bytecode in shared memory » (PHP manual : https://www.php.net/manual/en/book.opcache.php). Sur mutualisé, vous n’aurez pas la main sur tous les paramètres, mais vous devez connaître les symptômes d’un OPcache trop petit (invalidations fréquentes, latence erratique après déploiement) et les réglages côté serveur quand vous sortez du mutualisé.

Symptômes concrets souvent observés après un déploiement sur un shop PrestaShop :

• comportement « aléatoire » pendant 5 à 15 minutes (certaines pages OK, d’autres non),
• erreurs qui disparaissent après purge cache, puis reviennent au prochain déploiement,
• différences entre front et BO si des fichiers sont chargés différemment.

Pour aller plus loin : PHP OPcache : paramètres recommandés pour optimiser les performances et, si vous êtes en VPS/dédié, PHP-FPM : comprendre le flux d’exécution avec Nginx et Apache.

Procédure de changement .ovhconfig sans downtime « surprise » (et avec rollback en 2 minutes)

Pré-requis non négociables : une sauvegarde fichier + base, et un moyen de revenir en arrière sans dépendre du Manager OVHcloud. Dans un monde propre, .ovhconfig est versionné (Git) et déployé comme le reste ; dans un monde mutualisé « FTP only », au minimum gardez un .ovhconfig.bak et ayez un accès FTP/SSH prêt à restaurer. Si vous prévoyez aussi une mise à jour PrestaShop, alignez-vous sur une discipline de déploiement : Mise à jour PrestaShop : checklist sauvegarde, pré-production et tests.

La méthode pratique qui évite 80 % des incidents : créer une préproduction sur sous-domaine (ou au moins sur un sous-répertoire isolé avec son propre .ovhconfig si votre offre le supporte), dupliquer base + médias, puis changer PHP/mode sur la préprod d’abord. Vous validez le tunnel critique (front, recherche, panier, paiement, BO, génération facture PDF, webservice), vous checkez les erreurs PHP (log serveur + var/logs ou var/log/ selon version PrestaShop), puis vous appliquez en prod. Si vous avez des modules maison, faites un run des scénarios de non-régression (imports, exports, cron, webhooks) avant la bascule.

Procédure « safe » très concrète (adaptée aux contraintes mutualisées) :

1. Dupliquer le fichier en place : .ovhconfig → .ovhconfig.bak.
2. Modifier une seule chose à la fois (ex. d’abord app.engine.version, puis app.engine.mode).
   Cela rend le diagnostic trivial si ça casse.
3. Attendre la propagation (quelques minutes) et tester :

• la page d’accueil,
• une page produit,
• le panier,
• une tentative de commande jusqu’à l’étape paiement (en mode test si possible),
• le BO (connexion + page modules).

1. Si KO : rollback immédiat en remettant .ovhconfig.bak comme .ovhconfig.

Deux détails « bêtes mais fréquents » qui font perdre du temps :

• encodage : éditez en UTF-8 sans BOM, et évitez les caractères invisibles ;
• permissions et nom exact : le fichier doit s’appeler exactement .ovhconfig (pas .ovhconfig.txt), et être accessible à l’utilisateur web.

Enfin, surveillez : un changement de runtime peut décaler les temps de réponse et donc impacter vos métriques SEO/perf (TTFB, stabilité). Côté e-commerce, ça se traduit vite en Core Web Vitals et taux de conversion — particulièrement en périodes de pics (soldes, Black Friday, campagnes TV/radio, opérations locales). Branchez au minimum un monitoring d’erreurs et une vue sur la charge, même basique ; pour des approches plus sérieuses : Netdata : activer et configurer les collectors pour monitoring temps réel et SEO PrestaShop : checklist technique 2025 pour indexation et performance.

Dépannage : 500 après changement, pages blanches, 403, et décalage PHP CLI/Web

Le cas le plus brutal : HTTP 500 immédiatement après édition de .ovhconfig. Dans 90 % des cas, c’est (a) une valeur non supportée par l’offre (version ou phpfpm indisponible), (b) une faute de syntaxe (espaces, clé incorrecte), ou (c) un fichier encodé bizarrement (BOM). Revenir à l’état précédent via FTP est le premier réflexe. Ensuite seulement, vous cherchez l’explication : logs d’hébergement OVHcloud (répertoire logs/ si présent, ou via le Manager), puis validation en rebasculant une seule variable à la fois (d’abord la version PHP, ensuite le mode).

Une grille de diagnostic rapide (pratique quand vous devez agir vite, sans « tout casser ») :

Symptôme	Cause probable	Action la plus efficace
500 immédiat, toutes les URLs	valeur app.engine.version/mode non supportée, faute de frappe	rollback .ovhconfig, puis retest variable par variable
500 uniquement sur certaines pages (ex. BO modules)	module/override incompatible avec PHP	activer debug temporaire, identifier le module, mettre à jour/patcher
page blanche sans 500 apparent	fatal error masqué, affichage erreurs désactivé	activer mode debug temporaire, consulter logs, corriger puis désactiver debug
403 après changement	WAF (http.firewall) ou règles HTTP	vérifier logs + règles, appliquer une méthodo 403
CLI affiche PHP 8.x, mais le site est en 7.x (ou inverse)	décalage CLI/Web normal	vérifier PHP côté web via fichier temporaire, ne pas conclure depuis php -v

Les « pages blanches » (front ou back-office) après upgrade PHP sont souvent des fatal errors masqués : incompatibilité d’un module, appel à une fonction dépréciée devenue erreur, ou autoload cassé. Sur PrestaShop, vous pouvez activer temporairement le mode debug (selon version) pour afficher l’exception, mais ne vous contentez pas de « ça marche en dev » : la correction doit être commitée (update module, patch, suppression override incompatible). Si vous suspectez un problème de cache Symfony/Smarty, purgez proprement (var/cache/* selon version) et redéclenchez un warm-up via une requête contrôlée.

Enfin, ne confondez pas 403 et erreurs PHP. Sur OVHcloud mutualisé, un 403 après changement .ovhconfig est souvent corrélé à http.firewall (WAF) ou à un changement de comportement serveur (rewrite, PATH_INFO). Avant de désactiver le firewall « pour voir », faites une analyse structurée : Erreur 403 Forbidden : causes et dépannage étape par étape.

Et si votre motivation initiale était la sécurité (corriger une CVE PHP, sortir d’une version en fin de support, ou durcir la conf), rappelez-vous qu’un runtime à jour ne remplace pas un durcissement applicatif et serveur : Symfony : sécuriser un serveur PHP avec hardening et gestion CVE. Sur un mutualisé, cela se traduit surtout par : mises à jour régulières de PrestaShop et des modules, réduction de la surface d’attaque (désinstaller ce qui ne sert pas), contrôle des droits fichiers, et surveillance des logs/alertes — parce que .ovhconfig ne corrigera pas un module vulnérable ni un back-office exposé.