Composer en production : mise à jour et suivi

Nous avons déjà exploré dans l’article Composer, pourquoi c’est essentiel ? les fondements de cet outil et son installation pas à pas. Cette fois, entrons dans un usage plus avancé : comment Composer nous accompagne quand un projet PHP est en ligne ou sur le point de l’être.

À travers des cas concrets, nous allons voir comment garder un environnement stable, mettre à jour nos dépendances sans rien casser, comprendre l’utilité du fichier composer.lock, et automatiser certaines vérifications ou tâches répétitives. Car en production, Composer ne se limite pas à installer des bibliothèques : il devient un véritable outil de maintenance.

Composer au cœur de la stabilité d’un projet

Dès qu’un projet PHP passe en production, le fichier composer.lock devient un élément central. Contrairement au fichier composer.json, qui décrit les intentions de version (par exemple, « au moins la 2.0, mais pas au-delà de la 3.0 »), le fichier composer.lock fige précisément les versions installées. C’est lui qui garantit que tous les environnements — développement, recette, production — fonctionnent avec exactement les mêmes dépendances.

Prenons un exemple très simple :

// composer.json
{
  "require": {
    "monolog/monolog": "^2.0"
  }
}

// composer.lock (extrait généré automatiquement après installation)
{
  "packages": [
    {
      "name": "monolog/monolog",
      "version": "2.4.0",
      "source": {
        "url": "https://github.com/Seldaek/monolog",
        "type": "git",
        "reference": "abcd1234..."
      },
      ...
    }
  ]
}

Ici, composer.json indique une contrainte compatible, mais seule la version 2.4.0 est réellement installée et verrouillée dans composer.lock. C’est ce fichier qui est utilisé par Composer pour garantir que tout le monde travaille avec la même version — même plusieurs mois plus tard, sur un autre serveur. C’est pourquoi il est essentiel de le versionner dans Git et de ne pas le modifier à la main.

Composer distingue aussi les dépendances destinées au développement (require-dev) de celles nécessaires à la production (require). Lorsqu’on installe les dépendances sur un serveur, on peut limiter l’installation à l’essentiel grâce à l’option --no-dev. Cela évite d’embarquer des outils superflus (tests, mocks, générateurs de documentation) et réduit les risques de failles ou d’incompatibilités dans l’environnement de production.

Qui lit composer.lock et quand ?

Ce fichier composer.lock n’est pas appelé directement par nous, développeurs : il est utilisé automatiquement par Composer lors de l’exécution de la commande composer install. Tant que ce fichier existe, Composer ignore les éventuelles nouvelles versions disponibles et installe exactement celles qui sont listées et verrouillées dans ce fichier. Cela garantit que tous les environnements, locaux ou serveurs, utiliseront le même socle logiciel. En revanche, une commande comme composer update le régénère : elle cherche les dernières versions compatibles (selon les règles de composer.json), puis met à jour à la fois les paquets et le fichier composer.lock.

Mettre à jour sans casser : réflexes à adopter

Composer propose plusieurs commandes pour gérer les dépendances, mais leur usage n’est pas toujours intuitif. En production, la règle d’or consiste à éviter toute mise à jour non maîtrisée. C’est pourquoi composer install est privilégié : cette commande lit le fichier composer.lock et installe les versions précises qui y sont listées. En revanche, composer update va chercher les dernières versions compatibles selon les règles de composer.json, ce qui peut entraîner des changements inattendus, voire des régressions. Elle est donc à utiliser avec précaution, et plutôt dans un environnement de développement ou de test.

Pour savoir si certaines dépendances de notre projet ne sont plus à jour, Composer propose une commande simple et précieuse : composer outdated. Elle dresse la liste des bibliothèques installées en indiquant, pour chacune, la version actuellement utilisée, la version la plus récente disponible, et parfois même la nature du décalage (mise à jour mineure ou rupture majeure). C’est souvent notre premier réflexe avant toute mise à jour.

composer outdated
## Affiche les paquets installés qui ne sont plus à jour

monolog/monolog     2.3.5  -> 2.9.1   Monolog logging library
guzzlehttp/guzzle   7.2.0  -> 7.7.0   Guzzle HTTP client
phpunit/phpunit     9.5.10 -> 10.5.4  The PHP Unit Testing framework

Composer nous affiche alors les versions actuelles, celles disponibles, et les contraintes définies. Cela nous aide à planifier les mises à jour en connaissance de cause.

Si nous souhaitons cibler une seule bibliothèque, il suffit d’indiquer son nom dans la commande composer update. Par exemple, pour ne mettre à jour que monolog/monolog sans toucher aux autres dépendances :

composer update monolog/monolog
## Met à jour uniquement le paquet ciblé et réécrit le fichier composer.lock

Updating dependencies
Lock file operations: 0 installs, 1 update, 0 removals
  - Upgrading monolog/monolog (2.3.5 => 2.9.1)
Writing lock file
Installing dependencies from lock file

Composer nous encourage à être proactifs, mais pas téméraires : mieux vaut une dépendance à jour manuellement qu’une avalanche de versions qui brisent le projet en silence.

Quand ça coince : conflits, erreurs et retour arrière

Il arrive qu’une mise à jour échoue : dépendance introuvable, versions incompatibles, ou simplement un comportement inattendu dans notre application. Composer tente généralement de résoudre les conflits automatiquement, mais certaines combinaisons de versions sont impossibles à satisfaire. Dans ce cas, il affiche une erreur détaillée. On peut relancer la commande avec l’option -vvv pour obtenir un diagnostic plus complet :

composer update
## Exemple d’erreur de conflit de dépendance

Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - doctrine/orm 2.10.1 requires doctrine/dbal ^3.6 -> found doctrine/dbal[v3.6.0, ...] but these were not loaded, likely because it conflicts with another requirement.
    - Root composer.json requires doctrine/orm ^2.10 -> satisfiable by doctrine/orm[2.10.1].

Mais le vrai risque vient des mises à jour silencieuses qui brisent des fonctionnalités plus tard. Un composer update lancé trop vite peut modifier des versions clés sans qu’on s’en aperçoive. Et comme cette commande réécrit le fichier composer.lock, il n’est pas possible de revenir en arrière avec Composer lui-même.

Heureusement, si ce fichier est bien versionné dans Git, on peut facilement restaurer l’état précédent :

git checkout composer.lock
## Restaure la version précédente du fichier verrouillé depuis le dépôt Git

Puis relancer l’installation telle qu’elle était avant la mise à jour :

composer install
## Réinstalle exactement les dépendances listées dans le fichier lock restauré

Composer ne propose pas de rollback automatique, mais le versionnage du fichier lock fait office de filet de sécurité. C’est pourquoi il est essentiel de toujours le committer, et d’effectuer les mises à jour dans une branche dédiée ou un environnement de test.

Surveiller et maintenir un projet Composer

Une fois en production, notre projet PHP ne doit pas seulement « fonctionner » : il doit aussi rester sécurisé, à jour et prévisible. Composer nous fournit plusieurs outils pour surveiller discrètement l’état de nos dépendances. La commande composer audit, par exemple, interroge une base de données de vulnérabilités connues et signale les failles potentielles dans notre pile logicielle. Elle ne corrige rien, mais elle alerte : c’est une vérification que l’on peut automatiser, ou déclencher à intervalles réguliers.

composer audit
## Vérifie la présence de vulnérabilités connues dans les dépendances

Found 1 security vulnerability:
 - doctrine/dbal[<=2.13.6] : CVE-2022-24784
   SQL injection vulnerability in Identifier Quoting.
   https://github.com/advisories/GHSA-3h63-p4f7-5rpr

D’autres vérifications peuvent être utiles, comme composer validate, qui s’assure que notre fichier composer.json est bien formé et sans incohérences. Dans un environnement professionnel, ces outils sont souvent intégrés à des chaînes d’intégration continue, mais ils peuvent aussi être lancés manuellement à la moindre modification.

composer validate
## Vérifie la validité syntaxique et logique du fichier composer.json

./composer.json is valid for simple usage with Composer 2

Composer propose également une commande peu connue mais précieuse : composer fund. Elle liste les bibliothèques que nous utilisons et qui sont maintenues bénévolement, avec des liens de financement. C’est un moyen simple de prendre conscience de la fragilité de certaines briques, et d’encourager le soutien à leur maintien.

composer fund
## Affiche les bibliothèques utilisées qui proposent un mode de financement

You can support these packages:
  - symfony/console: https://github.com/symfony/console (Sponsor: symfony)
  - phpstan/phpstan: https://github.com/phpstan/phpstan (Sponsor: jetbrains)

Scripts utiles et automatisation légère

Composer ne se limite pas à gérer des paquets : il peut aussi automatiser certaines tâches au moment opportun. Grâce au bloc "scripts" dans le fichier composer.json, nous pouvons demander à Composer d’exécuter automatiquement une commande après une mise à jour, une installation ou tout autre événement. Cela permet, même sans système d’intégration continue, de déclencher des vérifications, des tests ou des opérations de nettoyage.

Par exemple, on peut lancer les tests unitaires automatiquement après chaque mise à jour des dépendances :

"scripts": {
  "post-update-cmd": [
    "phpunit"
  ]
}

Dans ce cas, dès qu’un composer update est exécuté, Composer appelle la commande phpunit. Cela suppose bien sûr que l’outil PHPUnit est installé et reconnu dans le projet (via une dépendance ou globalement). Les tests définis dans notre projet seront alors automatiquement exécutés, ce qui permet de vérifier que les mises à jour n’ont pas introduit de régression. C’est une étape simple mais précieuse dans une logique de déploiement maîtrisé.

De même, nous pouvons demander à Composer de valider la structure du projet ou de lancer un script PHP maison juste après une installation :

"scripts": {
  "post-install-cmd": [
    "composer validate",
    "php bin/clear-cache.php"
  ]
}

Ici, Composer enchaîne deux actions après chaque composer install : la commande composer validate vérifie que notre composer.json est bien formé et sans incohérences, tandis que le fichier clear-cache.php, s’il existe dans notre arborescence, est exécuté via PHP pour effectuer un nettoyage du cache ou préparer certains répertoires.

Ces scripts sont simples, mais très efficaces pour éviter les oublis et garantir que chaque étape importante du cycle de vie du projet est suivie d’un contrôle. On peut même créer ses propres scripts personnalisés en ajoutant des commandes bash ou PHP dans un fichier dédié. En production, cela permet d’automatiser une partie du déploiement ou de renforcer les vérifications sans dépendre d’un outil externe. Bien entendu, il est toujours recommandé de limiter les actions critiques (comme une suppression de fichiers) et de tester chaque script en environnement de développement avant de l’intégrer à Composer.

Conclusion

En environnement de production, Composer devient bien plus qu’un installateur de bibliothèques : c’est un outil de pilotage. Il verrouille les versions, assure la cohérence entre les environnements, alerte sur les failles potentielles, et peut même automatiser des tâches clés. À condition d’en comprendre les mécanismes — composer.lock, les contraintes de version, les scripts post-installation — nous pouvons l’utiliser comme un véritable assistant technique au quotidien. Que notre projet soit modeste ou ambitieux, Composer nous pousse à adopter de bons réflexes : tester avant de mettre à jour, versionner avant d’expérimenter, valider avant de livrer. En maîtrisant cet outil, nous gagnons en sérénité autant qu’en rigueur.