Composer : le gestionnaire de paquets de PHP

En bref : Composer est le gestionnaire de paquets de PHP. Il lit dans le fichier composer.json les bibliothèques dont un projet a besoin, les télécharge dans le dossier vendor, consigne les versions exactes dans le composer.lock et génère un autoloader qui trouve automatiquement les classes. Composer gère ainsi le code de votre application, non l'interpréteur PHP lui-même : une mise à jour de Composer ne comble aucune faille de PHP comme PHP2Shell.

Qu'est-ce que Composer et à quoi sert-il ?

Aujourd'hui, à peine une application PHP se compose uniquement de code propre. Frameworks, bibliothèques de messagerie, génération de PDF ou connexions de paiement s'ajoutent sous forme de paquets prêts à l'emploi. Composer, le gestionnaire de paquets de PHP, veille à ce que ces paquets soient réunis dans des versions compatibles et à ce que chaque dépendance apporte ses propres dépendances.

Pour les décideurs, cela signifie : une grande partie du code qui tourne sur votre serveur provient de tiers. C'est efficace, mais cela demande de l'entretien. Pour les administrateurs et les développeurs, cela signifie : qui utilise Composer proprement peut à tout moment retracer quelle version de quelle bibliothèque tourne en production.

Selon la documentation de Composer, la source standard des paquets est Packagist.org. D'autres sources, par exemple des dépôts internes d'une agence, peuvent être déclarées dans le composer.json sous repositories.

composer.json, composer.lock et vendor : les trois éléments

Composer travaille avec trois éléments qu'il faut connaître avant de reprendre un serveur ou de mandater une agence.

Sous require figurent les paquets dont l'application a besoin en fonctionnement. Sous require-dev figurent les outils de développement et de test, par exemple des frameworks de test ou l'analyse statique. Cette séparation est importante, car les outils de développement n'ont rien à faire sur un serveur de production.

{
    "require": {
        "php": ">=8.3",
        "monolog/monolog": "^3.0"
    },
    "require-dev": {
        "phpunit/phpunit": "^11.0"
    },
    "autoload": {
        "psr-4": { "App\\": "src/" }
    }
}

Les indications de version de l'exemple ne sont choisies qu'à titre d'illustration. Les versions dont votre projet a besoin découlent de ses exigences.

install ou update : la différence en exploitation

Les deux commandes se ressemblent, mais ont des conséquences très différentes.

• composer install lit le composer.lock et installe exactement les versions qui y sont consignées. C'est reproductible et cela relève de la livraison.
• composer update résout de nouveau toutes les dépendances, récupère les dernières versions compatibles et réécrit le composer.lock. Cela relève du développement, suivi de tests.

Selon la documentation de Composer, update exécute en outre, après avoir écrit le fichier de verrouillage, un contrôle de sécurité (audit), sauf s'il est désactivé avec --no-audit. install ne le fait pas par défaut ; l'option --audit existe pour cela.

Autoloading : comment Composer trouve les classes

Composer génère le fichier vendor/autoload.php. Une fois inclus, PHP ne charge chaque classe qu'au moment où elle est nécessaire. Pour le code propre, la section autoload définit quel espace de noms se trouve dans quel dossier. PSR-4, une norme du PHP-FIG, est recommandée pour cela. Le fonctionnement exact est expliqué sur la page Espaces de noms et autoloading ; la page Normes PSR donne un aperçu de toutes les normes.

<?php
require __DIR__ . '/../vendor/autoload.php';

$log = new Monolog\Logger('app');   // chargé automatiquement en cas de besoin

Composer en production : livrer proprement

Pour la livraison, un ordre fixe a fait ses preuves. Il s'exécute de préférence dans un pipeline de build et non à la main sur le serveur.

1. Vérifier le fichier de verrouillage : composer validate s'assure que composer.json est valide et que le composer.lock est à jour.
2. Installer sans paquets de développement : composer install --no-dev omet require-dev.
3. Optimiser l'autoloader : --optimize-autoloader (en abrégé -o) convertit les règles en une liste de classes. Avec --classmap-authoritative, PHP ne charge les classes que depuis cette liste.
4. Contrôle de sécurité : composer audit --locked vérifie les versions du fichier de verrouillage par rapport aux avis de sécurité connus et signale les paquets abandonnés.
5. vendor en dehors de la racine web : seul le dossier public contenant le script d'entrée doit être accessible par URL.

composer validate
composer install --no-dev --optimize-autoloader
composer audit --locked --no-dev

composer outdated montre en outre quels paquets installés ont des versions plus récentes. C'est la base de mises à jour planifiées plutôt que d'actions isolées et précipitées.

Composer, sécurité et PHP2Shell

Composer et PHP2Shell concernent deux niveaux différents. Les failles CVE-2026-109618 et CVE-2026-109619 se trouvent dans l'interpréteur PHP lui-même. Elles sont corrigées dans PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35, et tous les processus PHP doivent ensuite être redémarrés. Aucun composer update ni aucun paquet dans vendor n'y change rien.

Composer a néanmoins sa place dans toute vérification après un incident. Qui amène du code malveillant sur un serveur peut aussi modifier des fichiers dans vendor, et vendor/autoload.php est chargé à chaque requête. Un composer install tout neuf à partir du fichier de verrouillage vérifié, dans un répertoire vide, est donc une bonne méthode pour restaurer l'ensemble des paquets. La manière de vérifier régulièrement les dépendances contre les failles connues est décrite dans le guide composer audit.

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

• Nous recensons pour chaque application la version de PHP, les paquets Composer et l'état du fichier de verrouillage, en séparant clairement l'interpréteur des bibliothèques.
• Nous vérifions si vendor et le fichier de verrouillage correspondent, et si des paquets de développement ou des fichiers modifiés se trouvent en production.
• Nous mettons en place une livraison reproductible avec install --no-dev, un autoloader optimisé et un audit.
• Après un incident, nous restaurons l'ensemble des paquets à partir du fichier de verrouillage vérifié et documentons le résultat.

Questions fréquentes

Sources

• Composer : utilisation de base
• Composer : interface en ligne de commande
• Composer : le schéma de composer.json