# PHP en ligne de commande (CLI)

> PHP CLI expliqué : différences avec la version web, options utiles comme -l, -m et --ini, tâches Cron, serveur intégré et pourquoi php -v trompe souvent.

Source : https://phpsos.de/fr/php/php-cli/  
É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 :** la PHP CLI (Command Line Interface) est la variante de PHP pour la ligne de commande. Elle exécute des scripts sans serveur web, par exemple pour des tâches Cron, Composer ou des tâches de maintenance. Elle a ses propres valeurs par défaut, souvent son propre php.ini et parfois même une autre version que le site web. C'est pourquoi `php -v` n'est pas une preuve fiable que le site est corrigé après PHP2Shell.

## Qu'est-ce que la PHP CLI ?

Le manuel PHP cite deux grands domaines d'utilisation de PHP : les scripts pour les sites web et les scripts en ligne de commande. Pour ces derniers, il existe une SAPI propre nommée `cli`. Elle n'a besoin ni de serveur web ni de navigateur, seulement de l'interpréteur PHP. Selon le manuel, elle convient particulièrement aux tâches exécutées régulièrement par Cron sous Linux ou par le planificateur de tâches sous Windows.

Exemples typiques du quotidien en entreprise : imports nocturnes dans la boutique, envoi de newsletters, nettoyage de caches, mises à jour via Composer ou outils en ligne de commande de CMS comme WP-CLI ou la console Symfony. Sous Windows, le fichier s'appelle `php.exe`, la variante CGI `php-cgi.exe`.

Contrairement à PHP-FPM, la CLI n'est pas un service. Chaque appel démarre un nouveau processus, relit la configuration, selon le manuel, et se termine quand le script est fini. Un redémarrage après une mise à jour n'est donc pas nécessaire. Font exception les processus de longue durée lancés via la CLI, comme les workers de files d'attente de frameworks ou les démons sous systemd ou Supervisor. Ils tournent pendant des jours avec l'interpréteur chargé une fois pour toutes et doivent, après une mise à jour de PHP, être redémarrés exactement comme les workers web.

Pour la direction et la conduite de projet, cela signifie : les tâches de fond aussi doivent figurer dans l'inventaire et dans chaque plan de mise à jour.

## En quoi la CLI diffère-t-elle de la version web ?

Selon le manuel, la CLI impose de façon fixe certains réglages. Ils ne peuvent pas être modifiés via le php.ini, seulement à l'exécution par `ini_set()` :

| Directive | Valeur dans la CLI | Justification selon le manuel |
|---|---|---|
| `html_errors` | désactivé | les balises HTML gênent dans le terminal |
| `implicit_flush` | activé | les sorties doivent apparaître immédiatement |
| `max_execution_time` | 0 (illimité) | les scripts en ligne de commande durent souvent longtemps |
| `register_argc_argv` | activé | les scripts reçoivent toujours `$argc` et `$argv` |
| `output_buffering` | désactivé | codé en dur, les fonctions de tampon restent utilisables |
| `max_input_time` | désactivé | la CLI ne connaît ni GET, ni POST, ni téléversements |

Autre différence : la CLI ne se place pas dans le répertoire du script. Qui appelle `php -f ordner/skript.php` depuis `/tmp` continue de travailler dans `/tmp`. Les chemins relatifs dans les tâches Cron sont donc une source d'erreur fréquente.

Un petit script qui ne doit s'exécuter qu'en ligne de commande :

```php
<?php
if (PHP_SAPI !== 'cli') {
    http_response_code(403);
    exit('Nur für die Kommandozeile.');
}
$tage = (int) ($argv[1] ?? 30);
$grenze = time() - $tage * 86400;
$alt = 0;
foreach (glob(__DIR__ . '/cache/*.tmp') ?: [] as $datei) {
    if (filemtime($datei) < $grenze) { $alt++; }
}
fwrite(STDOUT, "Dateien älter als $tage Tage: $alt\n");
```

La vérification de `PHP_SAPI` empêche qu'un script de maintenance soit déclenché via le navigateur s'il se trouve par erreur dans le répertoire web. Le manuel recommande expressément de vérifier ainsi la SAPI plutôt que de se fier à la présence de `$argv`.

## Les principales options de la PHP CLI

Les options suivantes proviennent de l'aperçu des options du manuel PHP et sont particulièrement utiles pour les administrateurs :

1. **`php -v`** affiche le numéro de version de la CLI.
2. **`php --ini`** indique quels fichiers de configuration sont chargés.
3. **`php -m`** liste les modules compilés et chargés.
4. **`php -i`** appelle `phpinfo()` et restitue le résultat sous forme de texte.
5. **`php -l datei.php`** vérifie uniquement la syntaxe (lint). Depuis PHP 8.3, aussi pour plusieurs fichiers à la fois.
6. **`php -r 'code'`** exécute du code directement, sans `<?php`.
7. **`php -d name=wert`** définit un réglage INI pour cet appel.
8. **`php -n`** ignore entièrement le php.ini.
9. **`php --ri name`** affiche la configuration d'une extension.

```bash
php --ini
php -m | grep -i -E "opcache|sodium|pdo"
php --ri session | grep upload_progress
php -l src/Controller.php src/Model.php
```

## Le serveur web intégré : uniquement pour le développement

Avec `php -S localhost:8000`, la CLI démarre un petit serveur web. L'exemple de sortie du manuel cite PHP 5.4.0 comme point de départ. Le manuel est sans ambiguïté : le serveur sert au développement, n'est pas un serveur web complet et ne doit tourner ni sur des réseaux publics ni en production. S'il tourne en permanence sur un serveur et est joignable de l'extérieur, c'est un constat à corriger.

## CLI, Cron et sécurité après PHP2Shell

Les avis connus sur PHP2Shell citent PHP-FPM, mod_php, php-cgi, FrankenPHP et LiteSpeed comme modes d'exécution concernés. La CLI ne traite pas de requêtes provenant du réseau. Pour la sécurité, elle n'en est pas moins importante à trois titres :

- **Fausse preuve :** `php -v` indique la version de la CLI. Le site peut utiliser une autre version, et les rétroportages des distributions ne changent souvent pas le numéro affiché. La manière de prouver correctement l'état figure sous [Vérifier la version de PHP et l'état des correctifs](https://phpsos.de/fr/php2shell/php-version-pruefen/) et dans l'article [Pourquoi php -v affiche le même numéro](https://phpsos.de/fr/blog/php-v-zeigt-alte-nummer/).
- **Persistance via Cron :** après une intrusion, les attaquants aiment utiliser des tâches Cron qui lancent régulièrement un script PHP. Des indications pour la recherche figurent dans [Repérer les tâches Cron cachées comme porte dérobée](https://phpsos.de/fr/blog/cronjobs-als-hintertuer/).
- **Même paquet :** la CLI provient le plus souvent de la même source de paquets que PHP-FPM et doit être mise à jour avec lui.

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

- **Comparer les versions :** nous comparons l'état de la CLI et celui du web et prouvons quelle version votre site livre réellement.
- **Vérifier les tâches Cron :** nous listons toutes les tâches PHP planifiées de tous les utilisateurs et les rattachons à leurs applications.
- **Sécuriser la maintenance :** nous déplaçons les scripts de maintenance hors du répertoire web et mettons en place des vérifications de SAPI.
- **Assurer un suivi durable :** dans le [contrat de maintenance sécurité](https://phpsos.de/fr/leistungen/security-wartungsvertrag/), nous maintenons ensemble à jour la CLI, la SAPI web et les tâches Cron.


## Questions fréquentes

**php -v indique-t-il la version de mon site web ?**  
Pas forcément. php -v indique la version de la variante en ligne de commande. Le site peut tourner via une autre version de PHP-FPM ou un module Apache. Pour le site, ce qui compte est l'état de la SAPI web, que vous déterminez via le service ou un fichier de test déposé brièvement.

**Pourquoi les scripts CLI s'exécutent-ils sans limite de durée ?**  
Selon le manuel PHP, la CLI fixe max_execution_time à 0, donc illimité, parce que les scripts en ligne de commande accomplissent souvent de longues tâches. La durée peut être limitée par le script lui-même ou par des outils comme timeout.

**Puis-je utiliser en production le serveur intégré php -S ?**  
Non. Le manuel le décrit comme une aide au développement, non comme un serveur web complet, et déconseille son usage sur des réseaux publics et en production. Pour les systèmes en production, Apache, Nginx ou LiteSpeed avec PHP-FPM doivent être placés devant.

**OPcache est-il actif en ligne de commande ?**  
Pas par défaut. Selon le manuel, opcache.enable_cli vaut 0. Pour des scripts courts, le cache apporte de toute façon peu, puisque chaque appel est un nouveau processus.

## Sources

- [Manuel PHP : PHP en ligne de commande](https://www.php.net/manual/en/features.commandline.php)
- [Manuel PHP : différences de la SAPI CLI](https://www.php.net/manual/en/features.commandline.differences.php)
- [Manuel PHP : options de la CLI](https://www.php.net/manual/en/features.commandline.options.php)
- [Manuel PHP : serveur web intégré](https://www.php.net/manual/en/features.commandline.webserver.php)