PHP sur un serveur : exécution, serveur local, versions et limites

PHP est un langage open source exécuté côté serveur : entre le client et le serveur, le serveur web passe chaque fichier PHP à l'interpréteur, qui renvoie des pages web en code HTML. PHP et serveurs vont ensemble, sur un serveur local comme chez un hébergeur : installation, options et exemple PHP.

Comment PHP fonctionne-t-il avec un serveur web ?

PHP fonctionne côté serveur : le navigateur ne voit jamais le code PHP, il ne reçoit que le résultat. L'échange entre le client et le serveur suit toujours le même trajet. Le navigateur demande une adresse, le serveur web repère que le fichier visé porte l'extension .php, il le transmet à l'interpréteur, qui exécute les instructions, interroge au besoin des bases de données SQL, puis produit du code HTML. Le serveur renvoie ce HTML au navigateur, qui l'affiche comme n'importe quelle page statique.

Cette séparation explique deux réalités souvent mal comprises. Un fichier PHP ouvert directement dans le navigateur, par un double clic, affiche son code source ou une page blanche : sans serveur, personne ne l'exécute. Et une page PHP ne peut pas être publiée sur un hébergement « statique » qui ne sert que des fichiers HTML, CSS et images. Il faut un serveur capable de lancer l'interpréteur, en local pendant le développement, puis sur l'hébergement une fois le site en ligne.

Le plus petit exemple PHP tient en quelques lignes. Placé dans un fichier index.php, il mélange du code HTML et une instruction echo :

<!DOCTYPE html>
<html>
<head><title>Test PHP</title></head>
<body>
<p><?php echo "Hello world, nous sommes le " . date('d/m/Y'); ?></p>
</body>
</html>

Le navigateur reçoit la phrase avec la date du jour déjà calculée : le php echo a disparu, remplacé par son résultat. Ce même fichier index.php fonctionne sans modification sur un serveur local, sur un serveur Apache, sur Nginx ou sur un hébergement mutualisé, à condition que la version de PHP installée connaisse les fonctions utilisées, d'où l'intérêt de tester la compatibilité du site avec PHP 7 et 8 avant toute mise en ligne. Un script PHP plus ambitieux, avec une classe et ses méthodes (class Panier { public function total() { ... } }), suit exactement le même chemin : seul le volume de travail confié à l'interpréteur augmente.

Apache, Nginx, PHP-FPM : qui exécute vraiment le script PHP ?

Le serveur web et l'interpréteur PHP sont deux logiciels distincts, et la façon dont ils se parlent change le comportement du site. Historiquement, Apache chargeait PHP comme un module interne, mod_php : chaque processus Apache embarquait l'interpréteur. Cette option reste simple à installer et alimente encore beaucoup de piles Apache, MySQL, PHP (le fameux LAMP sous Linux), mais elle impose le mode prefork d'Apache et consomme de la mémoire même pour servir une simple image.

La solution courante aujourd'hui s'appelle PHP-FPM (FastCGI Process Manager), intégré au cœur de PHP depuis la version 5.3.3. PHP tourne alors en service séparé, avec son propre groupe de processus, et le serveur web lui transmet les requêtes par le protocole FastCGI, sur un socket Unix ou un port local (127.0.0.1:9000 dans la configuration fournie par défaut). Nginx ne sait pas exécuter PHP lui-même : il passe obligatoirement par PHP-FPM, avec une directive fastcgi_pass. Apache peut faire de même grâce à mod_proxy_fcgi.

Le mode PHP-FPM explique une particularité des hébergements : plusieurs versions de PHP peuvent cohabiter sur un même serveur, chacune avec son groupe de processus, et le panneau de contrôle attribue l'une ou l'autre à chaque domaine. C'est aussi pour cela qu'un fichier php.ini modifié ne prend effet qu'au redémarrage du service PHP-FPM concerné, et non du serveur web.

Comment démarrer un serveur PHP local en une ligne ?

Démarrer un serveur PHP local ne demande aucun logiciel supplémentaire : depuis PHP 5.4.0, l'interpréteur contient un serveur web interne. Dans un terminal, placé dans le dossier du projet, une seule commande suffit :

php -S localhost:8000

Le site devient accessible à l'adresse http://localhost:8000 dans le navigateur du même ordinateur. Si l'adresse demandée ne désigne aucun fichier précis, le serveur renvoie le fichier index.php ou index.html du dossier, comme le ferait Apache. Chaque requête s'affiche dans le terminal avec son code de réponse, ce qui remplace un journal d'accès pendant les tests.

Les options utiles du serveur interne

Trois options couvrent l'essentiel des besoins. L'option -t désigne un autre dossier racine, par exemple php -S localhost:8000 -t public/ pour un projet dont les pages publiques vivent dans un sous-dossier. Un fichier routeur, passé en dernier argument (php -S localhost:8000 routeur.php), reçoit toutes les requêtes et imite les règles de réécriture d'un .htaccess. L'option -c charge un fichier php.ini particulier, pratique pour reproduire la configuration de l'hébergement.

Ce que le serveur interne ne fait pas

La documentation de php.net est explicite : ce serveur web sert à faciliter le développement, il n'est pas un serveur complet et ne doit pas être utilisé sur un réseau public. Par défaut, il traite une requête à la fois ; la variable d'environnement PHP_CLI_SERVER_WORKERS, ajoutée en PHP 7.4 à titre expérimental et absente sous Windows, permet d'en lancer plusieurs. Il ne lit pas les fichiers .htaccess et ne gère ni HTTPS ni compression. Pour tester un site WordPress ou un formulaire simple, ces limites gênent rarement ; pour mesurer des performances, elles faussent tout.

Quels serveurs utiliser pour PHP sur un ordinateur personnel ?

Les meilleurs serveurs pour PHP en local sont ceux qui reproduisent l'hébergement de destination, plus que ceux qui offrent le plus d'options. Quatre familles d'outils open source dominent, chacune avec son terrain de prédilection :

XAMPP

Distribué par Apache Friends pour Windows, Linux et macOS, il installe en un seul paquet Apache, MariaDB, PHP et Perl, avec phpMyAdmin pour la gestion de base de données. Un bon point de départ pour une pile Apache MySQL PHP classique.

WampServer

Réservé à Windows, il ajoute une icône qui bascule d'une version de PHP à l'autre en deux clics, utile pour tester un site avant une migration. Son forum francophone reste une ressource active.

MAMP et Laragon

MAMP vise surtout macOS, Laragon surtout Windows ; tous deux démarrent Apache ou Nginx avec PHP et MySQL, et créent des adresses locales lisibles pour chaque projet.

Docker

Les images officielles « php » existent en variantes Apache, FPM et CLI. Un fichier de configuration décrit le serveur web, la version de PHP et la base : c'est l'option la plus fidèle à la production, au prix d'un apprentissage plus long.

Pour une page de test ou un script isolé, le serveur web interne de PHP suffit et s'installe avec PHP lui-même. Dès que le site dépend de règles .htaccess, de plusieurs domaines ou d'une base de données, une pile complète évite les mauvaises surprises au moment de la mise en ligne.

Serveur web local et hébergement : les écarts qui cassent un site

Un site qui marche sur un serveur local et échoue une fois en ligne souffre presque toujours d'un écart de configuration, pas d'un bogue du code PHP. Avant de transférer les fichiers, cinq points se comparent entre le poste de développement et le serveur de l'hébergeur :

• La version de PHP : un code écrit pour PHP 8.4 peut utiliser des fonctions absentes de la 8.2 installée chez l'hébergeur, et l'inverse vaut pour les fonctions retirées.
• Les extensions chargées : intl, gd, imagick ou sodium sont souvent actives en local et parfois absentes en ligne ; un appel de phpinfo() de chaque côté dresse la liste.
• La casse des noms de fichier : Windows et macOS confondent Image.jpg et image.jpg, un serveur Linux non.
• Les règles de réécriture : le serveur interne de PHP ignore le .htaccess, Nginx aussi ; un site qui dépend de ces règles demande Apache en local ou un fichier routeur.
• Les limites du php.ini : mémoire, taille d'envoi et durée d'exécution, plus larges en local, plus serrées sur un mutualisé.

La méthode la plus sûre consiste à aligner le serveur local sur l'hébergement : même branche de PHP, mêmes extensions, mêmes limites dans le fichier php.ini. Les écarts restants se repèrent alors dans le journal d'erreurs, et non sur les pages vues par les visiteurs.

Quelle version de PHP choisir sur le serveur ?

La version de PHP à choisir sur un serveur, au 9 octobre 2026, est la 8.4 ou la 8.5. D'après la page des versions prises en charge de php.net, PHP 8.5, sortie le 20 novembre 2025, et PHP 8.4 bénéficient du support actif, avec corrections de bogues et de sécurité. PHP 8.3 et PHP 8.2 ne reçoivent plus que des correctifs de sécurité, et ceux de la 8.2 s'arrêtent le 31 décembre 2026. PHP 8.1, toute la branche 7 et la branche 5 sont en fin de vie : un site qui en dépend tourne sans protection contre les failles découvertes depuis.

Changer la version de PHP d'un site en production se prépare toujours sur une copie. Les guides de migration du manuel de php.net listent, branche par branche, les fonctions retirées et les comportements modifiés. En pratique, le site se copie sur un sous-domaine, reçoit la nouvelle version depuis le panneau de l'hébergement, puis chaque page se parcourt en surveillant le journal d'erreurs. Beaucoup d'offres permettent de choisir la version par dossier ou par domaine, ce qui explique qu'un module paraisse disponible sur un site et absent sur un autre : chaque version a sa propre liste d'extensions chargées.

Mémoire, envoi de fichiers, durée : les limites du serveur PHP

Les limites d'un serveur PHP se lisent d'abord dans les messages d'erreur. Le message Fatal error: Allowed memory size of 268435456 bytes exhausted signifie qu'un script a atteint la limite memory_limit, ici 256 Mo exprimés en octets. Le manuel de php.net donne une valeur par défaut de 128M, que chaque hébergeur ajuste. Relever la limite soulage, mais une consommation qui grimpe sans cesse trahit souvent une boucle ou une extension mal écrite.

; fichier .user.ini ou php.ini, selon ce que l'hébergement autorise
memory_limit = 256M
upload_max_filesize = 64M
post_max_size = 64M
max_execution_time = 120

Les deux réglages d'envoi vont ensemble : post_max_size doit être au moins égal à upload_max_filesize, faute de quoi un fichier trop lourd est refusé sans message clair. Leurs valeurs par défaut, 2M et 8M selon php.net, bloquent vite l'import d'une sauvegarde. Sur un hébergement mutualisé, le fichier php.ini principal reste hors de portée ; un fichier .user.ini déposé à la racine du site, quand l'offre l'accepte, modifie les directives autorisées pour ce dossier. Pour connaître la configuration réellement appliquée, un fichier qui appelle phpinfo(), supprimé aussitôt la lecture terminée, affiche toutes les valeurs et la liste des modules.

Pourquoi certaines fonctions PHP sont-elles désactivées sur le serveur ?

Certaines fonctions PHP sont désactivées par l'hébergeur avec la directive disable_functions, qui retire des fonctions internes comme exec, shell_exec ou system, capables de lancer des programmes sur le serveur. Sur un hébergement partagé, ce verrou limite les dégâts d'un script piraté. Le manuel précise qu'elle se règle uniquement dans php.ini, donc par l'hébergeur, et qu'elle ne suffit pas à elle seule à sécuriser un serveur mutualisé. Un script qui a besoin de ces fonctions doit trouver une autre voie, détaillée dans l'article sur les fonctions interdites dans PHP : une extension PHP dédiée, une API, ou une offre qui ouvre un accès SSH.

Les tâches planifiées suivent la même idée. Plutôt qu'un traitement déclenché par la visite d'une page web, une ligne de crontab sous Linux lance le script à heure fixe avec l'interpréteur PHP en mode CLI :

0 3 * * * /usr/bin/php /chemin/vers/le/site/tache-nocturne.php

Le chemin /usr/bin/php change d'un serveur à l'autre, et la version de PHP en ligne de commande n'est pas forcément celle du site : sur un hébergement à plusieurs versions, il faut utiliser le chemin complet de la bonne branche, que le support ou la documentation de l'offre indique. Sur Debian et Ubuntu, par exemple, les paquets PHP installent un exécutable par branche, comme /usr/bin/php8.4, à côté du lien générique /usr/bin/php.

Sources : page des versions prises en charge de php.net, consultée le 9 octobre 2026 ; manuel PHP, chapitres « Serveur web interne » et directives du fichier php.ini (memory_limit, upload_max_filesize, post_max_size, disable_functions) ; manuel PHP, installation de PHP-FPM.