En bref : pour développer PHP en local, il existe trois voies courantes : le serveur web intégré (php -S) pour des essais rapides, les images Docker officielles de PHP pour des environnements reproductibles et des outils comme DDEV, qui génèrent des environnements de projet prêts à l'emploi pour WordPress, TYPO3, Shopware ou Laravel. L'essentiel tient moins à l'outil qu'à la concordance : en local, la même version de PHP avec les mêmes extensions devrait tourner qu'en production. Pour la sécurité, c'est toutefois toujours l'environnement d'exécution du serveur qui compte au final.
Pourquoi un environnement de développement dédié ?
Faire des modifications directement sur le serveur de production est risqué : chaque faute de frappe est immédiatement visible des clients, et les fichiers de test traînent volontiers. Un environnement local sépare l'expérimentation de l'exploitation. C'est aussi l'endroit où les nouvelles versions de PHP et les mises à jour de sécurité sont testées en premier.
Pour la direction et les responsables informatiques, la question n'est donc pas de savoir s'il existe un environnement de développement, mais s'il correspond au système de production. Un environnement local avec PHP 8.4 alors que la production tourne encore sous 8.1 masque les problèmes au lieu de les montrer. Il en va de même pour la version de la base de données, le serveur web et les extensions comme intl, gd ou pdo_mysql : une simple extension manquante peut faire qu'une erreur n'apparaît qu'en production.
Les options en un coup d'œil
| Option | Adaptée à | Atouts | Limites |
|---|---|---|---|
Serveur intégré php -S |
essais courts, petits scripts | sans installation de logiciel supplémentaire | ne remplace pas Nginx ou Apache, pas pour les réseaux publics |
| Image Docker officielle | équipes, environnements reproductibles | version fixable par tag, proche d'une exploitation en conteneurs | configuration et articulation de plusieurs conteneurs à construire soi-même |
| DDEV | projets CMS et frameworks | types de projets prêts à l'emploi, base de données et serveur web inclus | exige Docker, conventions propres |
| PHP installé localement | développeurs individuels | rapide, direct | versions de plusieurs projets difficiles à maintenir en parallèle |
Le serveur web intégré
Depuis PHP 5.4, la ligne de commande inclut un petit serveur web. Il démarre dans le répertoire courant ou, avec -t, dans un autre répertoire de documents :
php -S localhost:8000 -t public/
En option, vous passez un script de routage qui s'exécute d'abord à chaque requête. Le manuel est sans ambiguïté sur sa classification : le serveur doit soutenir le développement, n'est pas un serveur web à part entière et ne doit pas être utilisé sur un réseau public. Liez-le donc à localhost, non à 0.0.0.0, faute de quoi il peut être accessible dans le Wi-Fi de l'entreprise ou de l'hôtel. Plus d'informations sur la ligne de commande sous PHP en ligne de commande.
Docker : les images PHP officielles
Les images officielles existent en plusieurs variantes : cli pour la ligne de commande, apache avec Apache et mod_php, fpm pour une exploitation derrière Nginx ou un autre proxy, ainsi que des variantes Alpine pour de petites images. Un démarrage rapide avec Apache :
docker run --rm -p 8080:80 -v "$PWD":/var/www/html php:8.4-apache
Les images contiennent les modèles php.ini-development et php.ini-production dans le répertoire $PHP_INI_DIR. En local, le modèle de développement est judicieux, car il affiche les erreurs. Pour la production, la documentation de l'image recommande expressément le modèle de production. Vous installez les extensions avec les scripts utilitaires fournis docker-php-ext-configure, docker-php-ext-install et docker-php-ext-enable. Le fonctionnement des tags et des digests est expliqué dans Images Docker PHP officielles.
DDEV : des environnements prêts à l'emploi pour CMS et frameworks
DDEV s'appuie sur Docker et met en place pour un projet un serveur web, PHP, une base de données et des services auxiliaires. Les guides de démarrage rapide suivent presque toujours le même schéma :
ddev config --project-type=wordpress --docroot=web
ddev start
ddev composer install
ddev launch
DDEV connaît notamment comme types de projets wordpress, typo3, shopware6, laravel, symfony, drupal11, magento2 et le type général php. Vous fixez la version de PHP dans .ddev/config.yaml ; selon la documentation, les versions de 5.6 à 8.5 sont possibles, la valeur par défaut est 8.4 :
# .ddev/config.yaml (extrait)
php_version: "8.3"
webserver_type: nginx-fpm # sinon apache-fpm
L'environnement local correspond ainsi à la version de production, même si celle-ci n'est pas encore la plus récente.
Développement local, niveau de correctifs et PHP2Shell
Après PHP2Shell, plusieurs fournisseurs de plateformes ont signalé une erreur de raisonnement typique. Selon son bulletin, Vercel souligne qu'une mise à jour de l'environnement de développement local, du code de l'application ou des plugins ne suffit pas ; ce qui est décisif, c'est l'environnement d'exécution PHP qui sert réellement. Avoir PHP 8.4.27 en local ne protège pas le serveur sous 8.4.26.
Inversement, l'environnement de développement apporte ses propres risques, qui peuvent migrer vers la production :
- ini de développement en production :
display_errorsest activé dansphp.ini-development. Si ce fichier arrive sur le serveur, les visiteurs voient des chemins et des messages d'erreur. Voir Désactiver l'affichage des erreurs en production. - Fichiers de test oubliés : les fichiers
phpinfo(), les dumps de base de données ou les fichiers.envcontenant des identifiants n'ont pas leur place dans le déploiement. - Serveurs de développement ouverts :
php -Sou des conteneurs avec des ports publiés sur des machines du réseau. - Images obsolètes : les images locales ne se mettent pas à jour d'elles-mêmes ; après une version de sécurité de PHP, l'environnement de développement doit lui aussi être reconstruit, afin que les tests tournent avec la version corrigée.
Fixez la version de PHP à un seul endroit, par exemple dans le Dockerfile ou dans .ddev/config.yaml, et modifiez-la lors des mises à jour en même temps que la configuration du serveur.
Comment PHP SOS aide-t-il concrètement ?
Dans le cadre du contrat de maintenance de sécurité, nous veillons à ce que le développement et l'exploitation concordent :
- Rapprochement : nous comparons la version de PHP et les extensions des environnements de développement, de test et de production.
- Déroulement des mises à jour : les nouvelles versions de PHP sont d'abord installées dans l'environnement de test, puis en production, chaque fois avec redémarrage.
- Contrôle du déploiement : nous veillons à ce qu'aucun ini de développement, fichier de test ou identifiant n'arrive sur le serveur.
- Documentation : vous savez à tout moment quelle version tourne où.
Questions fréquentes
Puis-je utiliser publiquement le serveur web intégré de PHP ?
Non. Le manuel PHP dit expressément que le serveur lancé avec php -S sert au développement et ne doit pas être utilisé sur un réseau public. Pour l'exploitation, il faut PHP-FPM avec Nginx ou Apache.
Qu'est-ce que DDEV ?
DDEV est un outil qui s'appuie sur Docker et génère des environnements de développement prêts à l'emploi pour les projets PHP. Il connaît des types de projets pour WordPress, TYPO3, Shopware 6, Laravel, Drupal et d'autres systèmes.
Suffit-il de mettre à jour la version locale de PHP ?
Non. Contre des failles comme PHP2Shell, ce qui compte est l'environnement d'exécution PHP qui sert réellement, donc celui du serveur. L'environnement local devrait toutefois avoir la même version, pour que les tests soient significatifs.
Quel php.ini utiliser en local ?
En local, php.ini-development est judicieux, car il affiche les erreurs. En production, il faut utiliser php.ini-production. Les images Docker officielles fournissent les deux modèles.