Sur un mutualisé, votre voisin de serveur subit un pic WooCommerce — et votre blog ralentit parce que mod_php multiplie les process Apache gonflés de PHP en mémoire. Sur un VPS bien administré, chaque site a son pool FPM sous utilisateur Unix distinct : fuite ou saturation d'un client n'écrase pas les autres.
mod_php intègre PHP dans le processus Apache. PHP-FPM exécute PHP dans des workers séparés, Apache ou Nginx passant les requêtes via FastCGI. Pour plusieurs sites, la question n'est pas religieuse : quelle isolation mémoire et sécurité entre tenants ?
mod_php vs PHP-FPM
| Aspect | mod_php | PHP-FPM |
|---|---|---|
| Modèle processus | Apache + PHP couplés | Pools PHP indépendants |
| Mémoire sous charge | Explose (workers × PHP) | pm.max_children par pool |
| Isolation multi-site | Faible | Forte (user + pool) |
| Serveur web | Apache surtout | Nginx ou Apache |
| Réglage | Limité | pm, slowlog, status page |
| Hébergement mutualisé | Historique | Standard VPS/dédié |
Héberger dix WordPress en mod_php sur un VPS, c'est empiler dix bombes mémoire avec un seul détonateur.
mod_php : quand il reste visible
Mutualisé legacy. Vous n'avez pas le choix — l'hébergeur gère.
Application monolithique unique, trafic faible. Acceptable avec OPcache et marge RAM large.
Contrainte plugin rare exigeant mod_php — de plus en plus exceptionnel.
Migration recommandée dès accès root et second site.
PHP-FPM : bonnes pratiques multi-sites
Un utilisateur Unix par client (site_a, site_b). Un pool par site dans /etc/php/8.x/fpm/pool.d/. pm.on-demand ou dynamic selon trafic ; éviter static surdimensionné. open_basedir limité au docroot. Slowlog activé. Socket Unix ou TCP localhost — jamais FPM exposé sur Internet.
Stack courante : Nginx → socket Unix FPM → PHP 8.x plus OPcache plus Redis object cache WordPress. Apache équivalent : désactiver mod_php, activer proxy_fcgi vers pools.
Performance et sécurité
OPcache obligatoire dans les deux modes. Version PHP homogène par pool. CVE PHP : patch OS ; FPM permet reload sans couper Apache ou Nginx entier. Compromission site A en mod_php partagé → lecture fichiers site B possible ; utilisateur FPM séparé limite le rayon d'impact.
Le sommet : l'isolation n'est pas une option multi-tenant
Décider et avancer sans angle mort
Un site sur VPS personnel : PHP-FPM par habitude plus marge de réglage. Agence multi-clients : pool plus utilisateur obligatoires, audit annuel des slowlogs. Mutualisé : migrer clients sensibles vers VPS FPM ou offre managée. Mesurez la RAM par pool via pm.status_path avant la prochaine période de pic. Voir Apache ou Nginx WordPress et l'annuaire hébergeurs VPS.
Questions fréquentes
mod_php est-il obsolète ?
Déconseillé multi-sites et sous charge. PHP-FPM recommandé avec Nginx et Apache event MPM depuis des années.
Un site unique a-t-il besoin de PHP-FPM ?
Pas strictement ; meilleur contrôle mémoire sur VPS moderne. OPcache plus pools séparés restent le défaut sensé.
Comment isoler deux clients ?
Pool FPM dédié plus utilisateur Unix plus open_basedir plus vhost séparé — jamais mod_php partagé.
PHP-FPM avec Apache ?
Oui via proxy_fcgi — Apache sert HTTP, FPM exécute PHP sans mod_php embarqué.
Combien de sites PHP tournent sur votre serveur ? Si la réponse est supérieure à un et que vous êtes encore en mod_php, la migration FPM n'est pas un luxe — c'est assurance voisinage.