# Compiler PHP depuis le code source

> Compiler PHP depuis le code source : prérequis, options de configure, signature, tests et pourquoi un build maison exige son propre suivi des correctifs.

Source : https://phpsos.de/fr/php/php-kompilieren/  
État : 25/10/2026  
Fournisseur : PHP SOS, Assistance d'urgence PHP et sécurité des serveurs. Aide immédiate par WhatsApp : https://wa.me/491736494914?text=Bonjour%20PHP%20SOS%2C%20nous%20avons%20besoin%20d%27aide%20avec%20notre%20serveur%20PHP.%20Entreprise%20%3A%20%E2%80%A6%20Site%20web%20%3A%20%E2%80%A6

**En bref :** compiler PHP, c'est télécharger le paquet source officiel depuis php.net, définir avec `./configure` les interfaces et extensions souhaitées, construire avec `make`, vérifier avec `make test`, puis installer. Cela donne le plein contrôle de la version et du périmètre. Le prix : vous êtes vous-même responsable de chaque mise à jour de sécurité, comme récemment avec PHP2Shell, où il a fallu reconstruire et redémarrer tous les processus.

## Quand des builds PHP maison sont judicieux

La plupart des serveurs obtiennent PHP depuis une source de paquets : la distribution Linux, un dépôt tiers ou une image de conteneur. C'est généralement le meilleur choix pour l'exploitation normale, car les correctifs de sécurité sont livrés automatiquement.

Les builds maison ont néanmoins leur place :

| Situation | Source de paquets | Build maison |
|---|---|---|
| Serveur web ordinaire | généralement mieux | rarement nécessaire |
| Version ou option absente d'une source fiable | non disponible | judicieux |
| Débogage de PHP lui-même, build de debug | limité | judicieux |
| Périmètre fonctionnel minimal pour des systèmes spécifiques | limité | judicieux |
| Mises à jour de sécurité | arrivent avec la source | tâche personnelle |

Qui opte pour des builds maison a besoin d'un processus fixe pour les mises à jour, sinon l'avantage devient un risque.

## Prérequis

Selon le manuel, GNU make et un compilateur C sont nécessaires ; depuis PHP 8.4, le compilateur doit prendre en charge C11. Qui construit depuis le dépôt Git plutôt que depuis un paquet de version a en plus besoin d'autoconf (à partir de 2.68), de re2c (à partir de 1.0.3 pour PHP 8.3 et plus récent) et de bison (à partir de 3.0.0). Le README du code source donne cette entrée en matière pour Ubuntu :

```bash
sudo apt install -y pkg-config build-essential autoconf bison re2c libxml2-dev libsqlite3-dev
```

Pour chaque extension supplémentaire s'ajoutent les paquets de développement correspondants, par exemple pour OpenSSL ou libsodium.

## Télécharger le code source et vérifier son authenticité

Un PHP construit soi-même n'est digne de confiance que dans la mesure où son code source l'est. php.net propose chaque paquet avec une somme de contrôle SHA-256 et une signature GPG ; les clés des release managers figurent sur la page de téléchargement et sur la page des clés GPG.

```bash
curl -O https://www.php.net/distributions/php-8.4.27.tar.xz
curl -O https://www.php.net/distributions/php-8.4.27.tar.xz.asc
sha256sum php-8.4.27.tar.xz                     # comparer avec la valeur sur php.net
gpg --verify php-8.4.27.tar.xz.asc php-8.4.27.tar.xz
```

Ce n'est que lorsque la somme de contrôle et la signature concordent qu'on poursuit.

## Compiler PHP : configure, make, test

Le déroulement comporte quatre étapes :

1. **Configurer :** `./configure` avec les options souhaitées. Pour une construction depuis Git, exécuter d'abord `./buildconf`.
2. **Construire :** `make -j"$(nproc)"` ; selon le README, le nombre de jobs correspond judicieusement au nombre de cœurs du processeur.
3. **Tester :** `make TEST_PHP_ARGS=-j4 test` exécute la suite de tests de PHP.
4. **Installer :** `make install`, selon le répertoire cible avec les droits root.

Un exemple de build PHP-FPM avec son propre répertoire cible :

```bash
tar xf php-8.4.27.tar.xz && cd php-8.4.27
./configure --prefix=/opt/php-8.4 \
  --with-config-file-path=/opt/php-8.4/etc \
  --enable-fpm --with-fpm-user=www-data --with-fpm-group=www-data --with-fpm-systemd \
  --with-openssl --with-sodium \
  --disable-cgi
make -j"$(nproc)"
make TEST_PHP_ARGS=-j4 test
sudo make install
/opt/php-8.4/bin/php -v
```

Les principales options en un coup d'œil :

| Option | Effet |
|---|---|
| `--enable-fpm` | construit PHP-FPM ; avec `--with-fpm-user`, `--with-fpm-group`, `--with-fpm-systemd` |
| `--with-config-file-path` | répertoire dans lequel PHP cherche le php.ini |
| `--with-openssl` | prise en charge d'OpenSSL ; depuis PHP 7.4, le chemin est trouvé via pkg-config |
| `--with-sodium` | cryptographie moderne avec libsodium |
| `--disable-cgi` | renonce à la variante CGI lorsqu'elle n'est pas nécessaire |
| `--enable-debug` | symboles de débogage, recommandés pour le développement selon le README, pas pour la production |
| `--enable-zts` | sûreté des threads pour les modes d'exploitation avec threads |

Avec `--prefix`, plusieurs versions construites soi-même peuvent être installées côte à côte, par exemple sous `/opt/php-8.3` et `/opt/php-8.4`. Cela facilite les transitions, mais exige de la discipline : chaque version installée est un logiciel à part entière, qui doit être reconstruit à chaque version de sécurité, même si aucun site web ne l'utilise pour le moment. Les builds qui ne sont plus nécessaires doivent être entièrement supprimés. Les options d'un build existant sont affichées par `php -i` à la ligne « Configure Command » ; c'est le meilleur modèle pour la prochaine reconstruction.

Remarque sur OPcache : depuis PHP 8.5, OPcache est, selon la RFC adoptée, compilé en dur. Pour les versions plus anciennes, il est construit comme extension et chargé par `zend_extension`. Ce que sont les extensions et les interfaces est expliqué dans [Comprendre les extensions PHP](https://phpsos.de/fr/php/php-erweiterungen/) et [SAPI expliquée](https://phpsos.de/fr/php/sapi-erklaert/).

## Builds maison et sécurité : les obligations après PHP2Shell

Un PHP compilé soi-même a un véritable avantage de sécurité : vous ne construisez que ce dont vous avez besoin. Chaque extension non construite et chaque mode d'exploitation non construit est du code qui ne peut contenir aucune faille. Un build sans CGI, avec peu d'extensions et des chemins clairs est facile à appréhender.

À cela s'oppose une obligation stricte. Pour PHP2Shell, les distributions ont livré en partie des rétroportages le 21 octobre 2026 ; qui construit lui-même ne reçoit rien automatiquement. Concrètement, cela signifiait :

1. Télécharger et vérifier le code source de la version corrigée.
2. Reconstruire avec des options identiques ; `php -i` affiche la ligne configure d'origine.
3. Exécuter les tests et installer.
4. Redémarrer tous les processus PHP, comme décrit sous [Redémarrer PHP-FPM et tous les workers](https://phpsos.de/fr/php2shell/php-fpm-neustart/).
5. Vérifier la version en cours d'exécution, comme expliqué sous [Vérifier correctement la version de PHP et le niveau de correctifs](https://phpsos.de/fr/php2shell/php-version-pruefen/).

> **Important:**
> Un PHP construit soi-même n'apparaît dans aucun gestionnaire de paquets. Tenez un inventaire des serveurs sur lesquels tournent des builds maison, et dans quelle version, faute de quoi ils seront oubliés lors de la prochaine faille.

## Comment PHP SOS aide-t-il concrètement ?

Via le [service de correctifs PHP](https://phpsos.de/fr/leistungen/php-patch-service/), nous accompagnons les exploitants de builds maison :

- **Recenser l'existant :** nous trouvons les versions de PHP construites soi-même et lisons leurs options de build.
- **Reconstruire :** version corrigée avec signature vérifiée, mêmes options et exécution complète des tests.
- **Déployer et redémarrer :** installation, redémarrage de tous les processus, contrôle de la version en cours d'exécution.
- **Simplifier :** là où une source de paquets entretenue remplit le même objectif, nous montrons la transition.


## Questions fréquentes

**Quand vaut-il la peine de compiler PHP soi-même ?**  
Quand une version ou une option nécessaire n'est disponible dans aucune source de paquets fiable, pour le développement et le débogage de PHP lui-même, ou pour des builds très allégés et spécifiques. Pour les serveurs web ordinaires, des paquets entretenus sont généralement le meilleur choix.

**Comment vérifier que le code source de PHP est authentique ?**  
php.net propose pour chaque paquet source une somme de contrôle SHA-256 et une signature GPG. Comparez la somme de contrôle et vérifiez la signature avec les clés des release managers publiées sur php.net.

**Dois-je recompiler après une version de sécurité ?**  
Oui. Un PHP construit soi-même ne reçoit aucune mise à jour de la distribution. Après PHP2Shell, cela signifiait : construire le code source de 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, l'installer et redémarrer tous les processus PHP.

**Où trouver toutes les options de configure ?**  
Avec ./configure --help dans le répertoire source. Le manuel cite les principales options du noyau ; les options des extensions figurent sur leurs pages du manuel.

## Sources

- [Manuel PHP : installation depuis le code source](https://www.php.net/manual/en/install.unix.source.php)
- [Manuel PHP : options de configure](https://www.php.net/manual/en/configure.about.php)
- [Manuel PHP : installer FPM](https://www.php.net/manual/en/install.fpm.install.php)
- [php.net : paquets source avec sommes de contrôle et signatures](https://www.php.net/downloads.php)