Chapitre 2 sur 5

Installer Composer sur un serveur Debian 13

vérifié le 2 septembre 2026 · 4 min

Réponse rapide

Téléchargez le programme d’installation, comparez son empreinte SHA-384 à celle publiée sur composer.github.io/installer.sig, et ne l’exécutez que si les deux concordent. Installez-le dans /usr/local/bin/composer pour le rendre disponible à tous les utilisateurs. N’utilisez ensuite jamais sudo composer install : lancez Composer avec le compte propriétaire du projet.

Composer installe Laravel et l’ensemble de ses dépendances. Sur Debian, la question n’est pas seulement de l’installer, mais de le faire sans exécuter un script téléchargé sans contrôle : la procédure officielle vérifie l’empreinte du programme d’installation avant de le lancer.

Étapes exécutées sur Debian 13 « trixie » le 2 septembre 2026, avec PHP 8.4.24. Ce chapitre s’inscrit dans l’installation de Laravel sur Debian, dans le parcours Développement web.

Prérequis

Composer est un programme PHP : il faut PHP en ligne de commande avant lui.

bash
php -v
sudo apt install -y php-cli unzip curl ca-certificates

unzip n’est pas décoratif : sans lui, Composer décompresse les archives en PHP, beaucoup plus lentement.

Installer Composer avec vérification de signature

Quatre commandes, dans cet ordre. La troisième est celle qui compte : elle compare l’empreinte du fichier téléchargé à celle publiée par le projet.

bash
# 1. l'empreinte de référence, publiée par le projet Composer
EXPECTED="$(curl -sS https://composer.github.io/installer.sig)"

# 2. le programme d'installation
curl -sS https://getcomposer.org/installer -o composer-setup.php

# 3. l'empreinte du fichier reçu
ACTUAL="$(php -r 'echo hash_file("sha384", "composer-setup.php");')"

# 4. on ne lance rien si les deux diffèrent
if [ "$EXPECTED" = "$ACTUAL" ]; then
    sudo php composer-setup.php --install-dir=/usr/local/bin --filename=composer
    rm composer-setup.php
else
    >&2 echo "Signature invalide : téléchargement corrompu ou altéré."
    rm composer-setup.php
    exit 1
fi

Sur l’installation de test, les deux empreintes concordent :

code
attendue : c8b085408188070d5f52bcfe4ecfbee5f727afa458b2573b8eaaf77b3419b0bf2768dc67c86944da1544f06fa544fd47
obtenue  : c8b085408188070d5f52bcfe4ecfbee5f727afa458b2573b8eaaf77b3419b0bf2768dc67c86944da1544f06fa544fd47
→ signature valide
Pourquoi cette étape n’est pas facultative

Sans elle, vous exécutez avec les droits sudo un script PHP téléchargé sur le réseau, sans aucune garantie sur son contenu. C’est la raison pour laquelle la documentation officielle publie une empreinte de référence. Les tutoriels qui enchaînent curl puis php composer-setup.php sans comparaison sautent la seule protection disponible.

Vérifiez le résultat :

bash
composer --version
code
Composer version 2.10.3 2026-08-27 13:34:23
PHP version 8.4.24 (/usr/bin/php8.4)

Le placement dans /usr/local/bin avec le nom composer rend la commande disponible pour tous les utilisateurs du serveur, sans réglage de PATH.

Et le paquet Debian ?

Debian propose un paquet composer. Il fonctionne, mais il suit le rythme de la distribution : la version des dépôts est presque toujours en retard sur la version courante. Comme Composer se met à jour lui-même en une commande, l’installation manuelle reste préférable sur un serveur applicatif.

bash
sudo composer self-update          # dernière version stable
sudo composer self-update --rollback   # revenir à la précédente

Ne pas lancer Composer en root

Installer le binaire avec sudo est normal. L’utiliser avec sudo ne l’est pas.

bash
# à éviter
sudo composer install

# correct : l'utilisateur propriétaire du projet
su - deploy
cd /var/www/mon-projet
composer install --no-dev --optimize-autoloader

Sur un poste macOS, le problème se pose différemment et se traduit souvent par une commande laravel introuvable.

Deux raisons. Les scripts post-install des dépendances s’exécutent avec les droits que vous leur donnez, ce qui fait de sudo composer install une exécution de code tiers en root. Et les fichiers créés appartiennent alors à root, ce qui provoque des erreurs d’écriture dès que le serveur web tente d’écrire dans storage/.

Composer avertit d’ailleurs de lui-même quand il est lancé en root sans COMPOSER_ALLOW_SUPERUSER.

Options utiles en production

bash
composer install --no-dev --optimize-autoloader --no-interaction
Option Effet
--no-dev ignore les dépendances de développement (tests, outils de débogage)
--optimize-autoloader génère une table de classes statique, plus rapide au chargement
--no-interaction aucune question posée, indispensable en déploiement automatisé

Déployez toujours le fichier composer.lock avec le projet, et lancez composer install et non composer update : la première commande installe exactement les versions du verrou, la seconde les recalcule et peut introduire des changements non testés en pleine mise en production.

Erreurs fréquentes

Exécuter l’installateur sans vérifier la signature Vous lancez avec sudo un script PHP téléchargé sur le réseau, sans garantie sur son contenu. La comparaison d’empreinte est la seule protection disponible.
sudo composer install Les scripts post-install des dépendances s’exécutent en root, et les fichiers créés appartiennent à root, ce qui bloque ensuite l’écriture par le serveur web.
composer update en production Recalcule les versions et peut introduire des changements non testés. En déploiement, c’est composer install à partir du composer.lock.
Oublier unzip Composer décompresse alors les archives en PHP, nettement plus lentement.
Se fier au paquet Debian Il fonctionne mais reste en retard sur la version courante, alors que Composer se met à jour lui-même avec self-update.
Newsletter

Les nouveaux tests, tutoriels et projets, par e-mail.

Tests reproductibles, code versionné, résultats datés. Jamais de spam.