Installer Composer sur Ubuntu - Guide Complet et Sans Erreurs

Pourquoi Composer compte quand on travaille sur Ubuntu

Je considère Composer comme un outil de cohérence technique avant d’être un simple installateur de bibliothèques. Il lit le fichier composer.json, résout les dépendances, puis installe exactement ce qu’un projet demande dans son dossier vendor. C’est ce qui le rend utile en DevOps: on ne dépend pas d’un état flou de la machine, on décrit un environnement et on le rejoue.

Sur Ubuntu, cette logique a un avantage concret. Une équipe peut garder la même version de PHP, les mêmes dépendances et la même arborescence sur un poste local, un serveur de recette et une image de build. Pour moi, c’est là que Composer devient vraiment intéressant: il réduit les écarts entre développement, intégration et déploiement.

Je rappelle aussi un point souvent mal compris: Composer n’est pas un remplaçant de apt. apt gère les paquets système, Composer gère les dépendances PHP du projet. Cette séparation est saine, et elle évite beaucoup de bricolage quand l’application grossit. La suite logique, c’est donc de préparer Ubuntu pour qu’il puisse exécuter Composer sans friction.

Préparer Ubuntu avant l’installation

Je commence toujours par vérifier que la machine sait exécuter PHP en ligne de commande. Sans php-cli, Composer ne sert pas à grand-chose. Je mets aussi à jour l’index des paquets, puis j’installe les utilitaires qui servent le plus souvent pendant l’installation ou les dépendances projet.

sudo apt update
sudo apt install php-cli curl unzip git
php -v

curl permet de récupérer des fichiers depuis le terminal, unzip aide à extraire certaines dépendances, et git devient vite indispensable dès qu’un package est lié à un dépôt versionné. Si php -v renvoie une erreur, je ne passe pas à l’étape suivante: j’installe d’abord PHP correctement, parce qu’un Composer installé sur une base bancale ne fera que déplacer le problème.

Dans un contexte de serveur ou de VM éphémère, je fais aussi attention à la version PHP utilisée par le shell. Une machine peut avoir plusieurs versions de PHP, et la version utilisée par Apache ou Nginx n’est pas forcément celle du terminal. C’est un détail banal, mais il explique une bonne partie des bugs d’installation. Une fois ce socle vérifié, on peut choisir la méthode d’installation la plus adaptée.

Installer Composer proprement avec l’installateur officiel

Quand je veux une installation propre et maîtrisée, je préfère la méthode officielle. L’idée est simple: récupérer l’installateur, vérifier son intégrité, lancer l’installation, puis supprimer le script temporaire. C’est plus sérieux qu’un copier-coller improvisé, surtout sur une machine qui sert à développer, builder ou déployer.

Une fois le fichier composer.phar obtenu et vérifié, je le place en général dans un répertoire présent dans le PATH. Sur Ubuntu, /usr/local/bin reste le choix le plus lisible pour une installation globale.

sudo mv composer.phar /usr/local/bin/composer
sudo chmod +x /usr/local/bin/composer
composer --version

Cette version globale est confortable, parce qu’on peut invoquer composer depuis n’importe quel dossier sans préciser php composer.phar à chaque fois. La logique suivante consiste justement à choisir entre cette approche globale et une installation locale plus stricte.

Choisir entre installation globale et locale

Je tranche ce choix selon l’usage réel, pas selon une préférence théorique. Sur une machine personnelle ou un poste de travail partagé avec plusieurs projets PHP, l’installation globale est plus fluide. Dans un projet très cadré, ou dans une image Docker destinée à être reconstruite souvent, je trouve l’installation locale plus rassurante.

Vérifier, diagnostiquer et mettre à jour sans surprise

Je ne considère jamais une installation comme terminée tant que je n’ai pas validé trois choses: la version affichée, le diagnostic de base et le comportement de mise à jour. composer --version me dit si le binaire répond vraiment, composer diagnose repère des problèmes fréquents, et la commande de mise à jour dépend du mode d’installation choisi.

composer --version
composer diagnose

Si j’ai installé Composer globalement avec le PHAR officiel, je mets ensuite à jour avec composer self-update. Si j’ai choisi le paquet Ubuntu, je reste dans la logique du gestionnaire système et je passe par apt. Ce point paraît secondaire, mais il évite de mélanger deux chaînes de maintenance différentes dans le même poste.

Je fais aussi un test simple sur un projet vide, parce qu’il révèle vite un problème de permissions ou de réseau. Une installation peut répondre correctement à --version et échouer dès qu’elle doit écrire dans un répertoire de travail. C’est précisément ce genre de détail que je veux voir avant de l’embarquer dans une chaîne de build.

Les pièges que je vois le plus souvent sur Ubuntu

Les échecs d’installation de Composer sont rarement mystérieux. Ils reviennent presque toujours à quelques causes connues, et je préfère les traiter tout de suite plutôt que d’attendre qu’elles remontent en CI.

Mon réflexe, dans tous ces cas, est de revenir au socle: PHP CLI, droits sur les fichiers, puis accès réseau. Composer n’invente pas les problèmes, il les rend juste plus visibles. Quand ces trois couches sont propres, l’installation devient stable, et c’est là que je peux l’intégrer sereinement dans un flux DevOps.

Ce que je garde en tête quand Composer entre dans un pipeline DevOps

Une fois Composer installé, je ne l’utilise pas de la même façon sur un poste local, une image Docker ou un runner CI. Dans un pipeline, je veux de la répétabilité, donc je m’appuie sur composer.lock et je réserve composer update aux moments où je choisis explicitement de faire évoluer les dépendances. En déploiement, la commande qui revient le plus souvent chez moi ressemble à ceci:

composer install --no-dev --no-interaction --prefer-dist --optimize-autoloader

--no-dev retire les dépendances de développement, --prefer-dist favorise les archives prêtes à l’emploi, et --optimize-autoloader améliore le chargement des classes en production. Je garde aussi une règle simple: même version de PHP entre le build et l’exécution, sinon Composer peut valider un environnement que l’application ne retrouve plus au runtime.

Si je devais résumer ma méthode en une phrase, ce serait celle-ci: sur Ubuntu, Composer s’installe vite, mais il ne devient vraiment utile que quand l’environnement PHP, le chemin d’exécution et la stratégie de déploiement sont déjà alignés. Quand ces trois points sont en place, l’outil fait exactement ce qu’on attend de lui, sans bruit inutile.