ubuntu pro free

Ubuntu Pro : activer le support étendu sur Ubuntu LTS pour 10 ans

Ubuntu Pro permet de prolonger la durée de vie des versions Ubuntu LTS avec des mises à jour de sécurité étendues, des correctifs pour davantage de paquets, Livepatch, Landscape et plusieurs outils de conformité.

Pour un poste personnel, un petit serveur ou une machine que vous ne pouvez pas migrer tout de suite, c’est une option très pratique. Pour un vieux serveur oublié dans un placard numérique, c’est plutôt une béquille temporaire. Utile, certes. Magique, non.

Voici ce qu’Ubuntu Pro apporte réellement, quand l’activer, comment vérifier l’état d’une machine, et surtout quand il vaut mieux prévoir une vraie mise à niveau.

Ubuntu LTS, support standard, ESM : de quoi parle-t-on ?

Ubuntu publie une version LTS tous les deux ans. Ces versions Long Term Support reçoivent 5 ans de maintenance de sécurité standard. Elles conviennent donc mieux aux serveurs, postes de travail stables, environnements de production et machines que l’on ne veut pas réinstaller tous les neuf mois.

Après ces 5 ans, la version LTS sort du support standard. Elle ne disparaît pas soudainement dans une trappe façon vieux jeu DOS, mais elle ne reçoit plus les mêmes mises à jour de sécurité via le canal gratuit standard.

C’est là qu’intervient Ubuntu Pro. Il donne accès à l’ESM, pour Expanded Security Maintenance. En clair : Canonical continue de fournir des correctifs de sécurité sur une période plus longue.

Le cycle ressemble donc à ceci :

  • années 1 à 5 : support standard Ubuntu LTS ;
  • années 6 à 10 : maintenance étendue avec Ubuntu Pro et ESM ;
  • années 11 à 15 : extension possible avec l’add-on Legacy, surtout pour les organisations qui ne peuvent pas migrer rapidement.

Pour la plupart des utilisateurs, il faut surtout retenir ceci : Ubuntu Pro ne remplace pas une stratégie de migration. Il donne du temps. Et parfois, du temps, c’est précisément ce qui manque.

Ubuntu Pro est-il gratuit ?

Oui, dans certains cas.

Canonical propose Ubuntu Pro gratuitement pour un usage personnel jusqu’à 5 machines. Cela peut inclure des postes de travail, des machines virtuelles ou des serveurs personnels. Les membres officiels de la communauté Ubuntu peuvent bénéficier d’une limite plus élevée.

Pour les entreprises, les parcs importants, les besoins de conformité ou le support contractuel, Ubuntu Pro devient une offre commerciale. Le support téléphonique ou par ticket fait partie d’un niveau séparé, généralement nommé Ubuntu Pro + Support.

Donc, pour un admin qui maintient quelques machines personnelles ou un petit serveur, l’offre gratuite est intéressante. Pour une infrastructure client ou une flotte de production, il faut regarder les conditions de licence et le niveau de support attendu.

Ce qu’Ubuntu Pro ajoute vraiment

Ubuntu Pro ne se limite pas à “garder Ubuntu plus longtemps”. Il ajoute plusieurs services autour de la sécurité et de la maintenance.

ESM Infra

esm-infra couvre les paquets du dépôt Main après la fin des 5 ans de maintenance standard. Ce sont les paquets centraux du système Ubuntu : base système, bibliothèques essentielles, composants serveur courants, outils fondamentaux.

C’est la partie la plus proche de l’ancien modèle ESM historique.

ESM Apps

esm-apps couvre les paquets du dépôt Universe. C’est important, car beaucoup de serveurs et postes Ubuntu utilisent des paquets qui ne viennent pas uniquement de Main.

On y trouve de nombreux outils, applications et bibliothèques issus de Debian et de la communauté Ubuntu. Sur un serveur web, un serveur applicatif ou une machine de développement, cette différence peut compter énormément.

Livepatch

Livepatch permet d’appliquer certains correctifs de sécurité du noyau Linux sans redémarrer immédiatement la machine. C’est très utile sur les serveurs qui doivent rester disponibles.

Attention tout de même : Livepatch ne supprime pas le besoin de redémarrer à vie. Il réduit surtout l’urgence de certains redémarrages liés au kernel. Pour une maintenance propre, il faut encore planifier des redémarrages réguliers.

Landscape

Landscape sert à gérer un parc Ubuntu : inventaire, mises à jour, supervision, reporting et administration centralisée. Sur une seule machine personnelle, c’est souvent trop lourd. Sur plusieurs serveurs, cela devient plus intéressant.

Conformité et durcissement

Ubuntu Pro inclut aussi des fonctions liées à la conformité : profils CIS, DISA-STIG, FIPS et autres exigences selon les environnements. Pour un blog personnel, c’est rarement le sujet. Pour une organisation soumise à des contraintes réglementaires, cela peut devenir central.

Quand faut-il activer Ubuntu Pro ?

Ubuntu Pro est utile dans plusieurs cas concrets.

  • Vous utilisez une version Ubuntu LTS proche de la fin du support standard.
  • Vous maintenez un serveur que vous ne pouvez pas migrer immédiatement.
  • Vous utilisez des paquets du dépôt Universe et vous voulez une meilleure couverture de sécurité.
  • Vous avez besoin de Livepatch pour réduire les redémarrages urgents.
  • Vous gérez plusieurs machines Ubuntu et vous voulez centraliser une partie de la maintenance.
  • Vous préparez une migration, mais vous avez besoin de quelques mois de sécurité supplémentaire.

En revanche, Ubuntu Pro n’est pas une excuse pour garder éternellement une vieille version. Si votre machine tourne encore avec une LTS très ancienne, des dépôts tiers abandonnés, une pile PHP morte et des scripts maison non maintenus, Ubuntu Pro ne transformera pas ça en architecture moderne. Il mettra juste un casque sur un dinosaure.

Vérifier la version Ubuntu installée

Avant d’activer quoi que ce soit, commencez par vérifier votre version Ubuntu :

lsb_release -a

Vous pouvez aussi lire directement le fichier système :

cat /etc/os-release

Sur un serveur, vérifiez également le noyau actif :

uname -a

Ensuite, regardez si le client Ubuntu Pro est déjà installé :

pro --version

Sur les versions récentes d’Ubuntu, le paquet est souvent déjà présent. Sinon, installez-le :

sudo apt update
sudo apt install ubuntu-pro-client

Voir l’état Ubuntu Pro de la machine

Pour afficher l’état actuel de la machine :

pro status

La commande indique si la machine est attachée à un abonnement Ubuntu Pro, et quels services sont activés ou disponibles.

Pour obtenir un état plus orienté sécurité :

pro security-status

Cette commande aide à comprendre quels paquets sont couverts, notamment selon leur dépôt d’origine : Main ou Universe.

Activer Ubuntu Pro sur une machine

Pour activer Ubuntu Pro, il faut un compte Ubuntu One et une souscription Ubuntu Pro. Pour un usage personnel, la souscription gratuite suffit jusqu’à 5 machines.

Vous devez vous identifier avec votre compte Ubuntu One, ensuite vous rendre sur la page Ubuntu Pro, et cliquer sur le bouton Register qui se trouve au milieu de la page.

Cela vous crée une clé API que vous pouvez retrouver sur la page de votre tableau de bord Ubuntu Pro.

Copiez votre clé API et ajoutez-la sur le serveur:

sudo pro attach

La commande affiche ensuite un lien et un code. Ouvrez le lien dans votre navigateur, connectez-vous avec votre compte Ubuntu One, puis validez l’attachement de la machine.

Une fois l’opération terminée, vérifiez l’état :

pro status

Vous devriez voir les services disponibles, activés ou désactivés. Selon la version, Ubuntu peut activer automatiquement esm-apps, esm-infra ou Livepatch.

Activer ou désactiver un service Ubuntu Pro

Après attachement, vous pouvez activer un service précis :

sudo pro enable esm-infra
sudo pro enable esm-apps

Pour Livepatch :

sudo pro enable livepatch

Et pour désactiver un service :

sudo pro disable livepatch

Avant d’activer des services de conformité comme FIPS ou certains profils de durcissement, lisez la documentation et testez sur une machine non critique. Ces fonctions peuvent modifier le comportement du système et des paquets. Sur un serveur de production, on évite le freestyle.

Mettre à jour le système après activation

Une fois Ubuntu Pro attaché, mettez à jour les index et appliquez les mises à jour disponibles :

sudo apt update
sudo apt list --upgradable
sudo apt upgradeLangage du code : PHP (php)

Sur un serveur, je préfère généralement séparer l’inspection et l’application. Cela évite les surprises, surtout si des paquets critiques comme le kernel, OpenSSL, PHP, MariaDB, MySQL ou Nginx sont concernés.

Pour appliquer toutes les mises à jour avec gestion des dépendances :

sudo apt full-upgrade

Puis vérifiez si un redémarrage est nécessaire :

test -f /var/run/reboot-required && cat /var/run/reboot-requiredLangage du code : JavaScript (javascript)

Détacher une machine Ubuntu Pro

Si vous remplacez une machine ou si vous voulez libérer une souscription, vous pouvez détacher le système :

sudo pro detach

Ensuite, vérifiez l’état :

pro status

La machine ne recevra plus les mises à jour réservées à Ubuntu Pro. Sur une LTS encore dans sa période de support standard, ce n’est généralement pas dramatique. Sur une version sortie du support standard, c’est une autre histoire.

Ubuntu Pro ou mise à niveau vers une nouvelle LTS ?

La bonne réponse dépend de votre situation.

Ubuntu Pro est pertinent si vous avez besoin de temps. Par exemple, une application métier dépend d’une vieille version de Python, un serveur héberge plusieurs sites clients, ou une migration demande des tests sérieux.

En revanche, si vous pouvez migrer proprement vers une LTS récente, faites-le. Une version récente apporte un kernel plus moderne, de meilleurs paquets, une compatibilité matérielle plus actuelle et un écosystème logiciel moins poussiéreux.

Sur un serveur web, la vraie question n’est pas seulement “ai-je encore des correctifs de sécurité ?”. Il faut aussi regarder PHP, MySQL ou MariaDB, Nginx ou Apache, OpenSSL, Redis, les dépôts tiers, les certificats, les tâches cron, les sauvegardes et les versions applicatives.

Ubuntu Pro sécurise mieux une base existante. Il ne modernise pas toute votre pile applicative à votre place.

Cas pratique : serveur WordPress ou WooCommerce

Sur un serveur WordPress ou WooCommerce, Ubuntu Pro peut être très utile, mais il ne suffit pas.

Il faut aussi vérifier :

  • la version PHP utilisée par les sites ;
  • les extensions PHP installées ;
  • les versions de MySQL ou MariaDB ;
  • les règles Nginx ou Apache ;
  • la configuration TLS ;
  • les droits fichiers ;
  • les sauvegardes ;
  • les plugins WordPress obsolètes ;
  • les tâches cron ;
  • les journaux d’erreur PHP-FPM et serveur web.

Ubuntu Pro peut corriger des CVE sur des paquets système, mais il ne corrigera pas un plugin WordPress abandonné, un thème bricolé ou une boutique WooCommerce qui tourne avec des extensions périmées.

Pour un serveur de production, utilisez Ubuntu Pro comme une couche de sécurité supplémentaire, pas comme un substitut à la maintenance applicative.

Commandes utiles à garder sous la main

Afficher l’état Ubuntu Pro :

pro status

Afficher l’état sécurité :

pro security-status

Attacher la machine :

sudo pro attach

Activer ESM Infra :

sudo pro enable esm-infra

Activer ESM Apps :

sudo pro enable esm-apps

Activer Livepatch :

sudo pro enable livepatch

Détacher la machine :

sudo pro detach

Mettre à jour le système :

sudo apt update
sudo apt upgrade

Checklist avant d’activer Ubuntu Pro sur un serveur

  • Vérifier la version Ubuntu avec lsb_release -a.
  • Vérifier si la version est encore dans le support standard.
  • Contrôler les dépôts tiers dans /etc/apt/sources.list et /etc/apt/sources.list.d/.
  • Vérifier les paquets bloqués avec apt-mark showhold.
  • Faire une sauvegarde avant les mises à jour importantes.
  • Tester les mises à jour sur une machine de staging si possible.
  • Planifier un redémarrage si un nouveau kernel est installé.
  • Prévoir une migration vers une LTS récente si la version est trop ancienne.

Faut-il activer Ubuntu Pro sur toutes vos machines ?

Sur une machine personnelle en LTS, oui, cela peut valoir le coup. C’est gratuit dans la limite prévue par Canonical, simple à activer, et cela ajoute une couche de sécurité.

Sur un serveur de production, oui aussi, mais avec méthode. Il faut documenter ce qui est activé, surveiller les mises à jour, et ne pas utiliser Ubuntu Pro comme prétexte pour repousser éternellement les migrations.

Sur une machine de test jetable, ce n’est pas forcément nécessaire. Si vous reconstruisez la VM toutes les deux semaines, mieux vaut automatiser votre provisioning que collectionner les abonnements Pro.

FAQ

Ubuntu Pro remplace-t-il les mises à niveau Ubuntu ?

Non. Ubuntu Pro prolonge la maintenance de sécurité, mais il ne remplace pas une migration vers une version LTS récente. Il sert surtout à gagner du temps sans laisser une machine sans correctifs.

Ubuntu Pro est-il vraiment gratuit ?

Oui, pour un usage personnel jusqu’à 5 machines. Les organisations, les flottes plus larges et les besoins de support professionnel relèvent d’offres commerciales.

Quelle est la différence entre esm-infra et esm-apps ?

esm-infra couvre les paquets du dépôt Main après les 5 ans de support standard. esm-apps couvre les paquets du dépôt Universe, qui contient de nombreuses applications et bibliothèques open source.

Ubuntu Pro active-t-il Livepatch automatiquement ?

Selon la version et la configuration, Livepatch peut être proposé ou activé pendant l’attachement. Vous pouvez vérifier avec pro status et l’activer explicitement avec sudo pro enable livepatch.

Ubuntu Pro protège-t-il mes applications WordPress ?

Il protège certains paquets système et composants open source fournis par Ubuntu. Il ne corrige pas vos plugins WordPress, vos thèmes, vos snippets PHP ou vos extensions commerciales. Pour WordPress, la maintenance applicative reste indispensable.

Conclusion

Ubuntu Pro est une bonne option pour prolonger la sécurité d’une version Ubuntu LTS, surtout lorsqu’une migration immédiate n’est pas possible. Son intérêt dépasse le simple support étendu : ESM couvre davantage de paquets, Livepatch réduit certains redémarrages urgents, et Landscape peut aider à gérer plusieurs machines.

Mais gardez la bonne lecture : Ubuntu Pro vous achète du temps. Il ne transforme pas une vieille infrastructure en plateforme moderne. Pour un serveur critique, activez-le si nécessaire, appliquez les correctifs, puis planifiez une migration propre vers une LTS récente.


Besoin d’aide pour optimiser, sécuriser ou maintenir votre site WordPress ?

Je suis développeur WordPress et WooCommerce freelance. J’aide les entreprises, indépendants et éditeurs de sites à améliorer leurs performances, renforcer leur sécurité, corriger les erreurs techniques et développer des fonctionnalités sur mesure.

Audit de performance, nettoyage de plugins, optimisation serveur, sécurisation WordPress, migration, maintenance, développement PHP, WooCommerce ou automatisations : je peux intervenir proprement, sans empiler des extensions inutiles.

Vous avez un site lent, fragile, mal configuré ou envahi par les robots ? Je peux vous aider à remettre les choses au carré.

À lire aussi sur SkyMinds

Sources

PHP8

Tester la compatibilité WordPress avec PHP 8.4 et 8.5

Changer la version PHP d’un site WordPress peut améliorer les performances, renforcer la sécurité et prolonger la durée de vie technique du site. Mais cela peut aussi révéler un vieux plugin bancal, un thème oublié ou un snippet copié-collé en 2014. Bref, PHP ne casse pas toujours WordPress. Il révèle souvent ce qui était déjà fissuré.

Voici une méthode propre pour tester la compatibilité d’un site WordPress avec PHP 8.4 ou PHP 8.5 avant de basculer la production.

WordPress et PHP 8 : où en est-on ?

WordPress recommande aujourd’hui PHP 8.3 ou supérieur pour de meilleures performances et une meilleure sécurité. WordPress peut encore fonctionner avec PHP 7.4, mais cette branche est officiellement en fin de vie. Elle ne doit plus servir de base sérieuse pour un site maintenu.

La situation actuelle est simple :

  • PHP 8.5 : excellent objectif pour un site WordPress très bien maintenu.
  • PHP 8.4 : meilleur compromis pour la majorité des sites récents et propres.
  • PHP 8.3 : base minimale recommandée aujourd’hui.
  • PHP 8.2 et inférieur : à éviter pour une nouvelle migration.
  • PHP 7.4 : branche en fin de vie, à sortir du parc dès que possible.

Le point crucial : WordPress core n’est généralement pas le problème. Les blocages viennent presque toujours des plugins, thèmes, mu-plugins, snippets, intégrations WooCommerce ou vieux bouts de code maison.

Lire Tester la compatibilité WordPress avec PHP 8.4 et 8.5

PHP Composer Banner

PHP : installer Composer sous Ubuntu Server

Voici comment installer Composer, le gestionnaire de dépendances PHP, sur Ubuntu Server.

Composer simplifie énormément la gestion des bibliothèques PHP. Au lieu de télécharger manuellement des paquets, de gérer leurs dépendances, puis de vérifier leurs versions une par une, on décrit les besoins du projet dans un fichier composer.json, et Composer s’occupe du reste.

Je l’utilise notamment pour auditer des sites hébergés sur un serveur, tester la compatibilité avec une version récente de PHP, installer des outils de développement, ou gérer les dépendances d’un plugin WordPress. On peut évidemment tout rapatrier en local, mais parfois, tester directement sur le serveur évite un aller-retour de fichiers parfaitement inutile.

Composer peut s’installer localement dans un projet, ou globalement comme commande système. La documentation officielle présente ces deux approches : installation locale dans un projet, ou installation globale comme exécutable disponible partout.

Installer les paquets prérequis

On commence par mettre à jour la liste des paquets :

sudo apt update

Ensuite, on installe les dépendances utiles :

sudo apt install curl unzip php-cli php-mbstring php-xml php-curl

Le paquet php-cli permet d’exécuter PHP en ligne de commande. curl sert à télécharger l’installeur. unzip permet d’extraire certaines archives de paquets. Enfin, php-mbstring, php-xml et php-curl évitent pas mal d’avertissements selon les dépendances installées.

On peut vérifier la version de PHP disponible en CLI :

php -v

Et vérifier les extensions chargées :

php -m

Télécharger l’installeur de Composer

On télécharge l’installeur officiel depuis le site de Composer :

php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"Langage du code : JavaScript (javascript)

On peut aussi utiliser curl :

curl -sS https://getcomposer.org/installer -o composer-setup.phpLangage du code : JavaScript (javascript)

Les deux méthodes fonctionnent. Si votre installation PHP a un problème de certificats SSL, curl peut parfois donner une erreur plus lisible. Charmant, mais utile.

Vérifier la signature de l’installeur

Avant d’exécuter l’installeur, il faut vérifier sa signature SHA-384. Le hash change régulièrement, donc récupérez toujours la valeur actuelle depuis la page officielle de téléchargement de Composer. La page officielle affiche les commandes de téléchargement, de vérification, d’exécution et de suppression de l’installeur.

Voici la méthode automatisée :

EXPECTED_SIGNATURE="$(curl -s https://composer.github.io/installer.sig)"
ACTUAL_SIGNATURE="$(php -r "echo hash_file('sha384', 'composer-setup.php');")"

if [ "$EXPECTED_SIGNATURE" != "$ACTUAL_SIGNATURE" ]; then
    echo "Installer corrupt"
    rm composer-setup.php
    exit 1
fi

echo "Installer verified"Langage du code : PHP (php)

Si la commande affiche Installer verified, on peut continuer. Si elle affiche Installer corrupt, on supprime le fichier et on recommence. Pas de bravoure inutile ici.

Installer Composer globalement

Pour installer Composer comme commande disponible partout sur le serveur, on l’installe dans /usr/local/bin :

sudo php composer-setup.php --install-dir=/usr/local/bin --filename=composerLangage du code : JavaScript (javascript)

Composer sera alors accessible avec la commande :

composer

On peut vérifier l’installation avec :

composer --version

Enfin, on supprime l’installeur :

rm composer-setup.phpLangage du code : CSS (css)

La documentation officielle indique que l’installeur télécharge le dernier composer.phar, et que l’installation globale permet d’utiliser Composer comme exécutable système.

Installation complète en une seule séquence

Voici la séquence complète, pratique à garder sous le coude :

sudo apt update
sudo apt install curl unzip php-cli php-mbstring php-xml php-curl

curl -sS https://getcomposer.org/installer -o composer-setup.php

EXPECTED_SIGNATURE="$(curl -s https://composer.github.io/installer.sig)"
ACTUAL_SIGNATURE="$(php -r "echo hash_file('sha384', 'composer-setup.php');")"

if [ "$EXPECTED_SIGNATURE" != "$ACTUAL_SIGNATURE" ]; then
    echo "Installer corrupt"
    rm composer-setup.php
    exit 1
fi

echo "Installer verified"

sudo php composer-setup.php --install-dir=/usr/local/bin --filename=composer
rm composer-setup.php

composer --versionLangage du code : PHP (php)

Cette version évite de copier-coller manuellement une signature qui peut devenir obsolète.

Installer Composer localement dans un projet

Il n’est pas obligatoire d’installer Composer globalement. On peut aussi l’installer dans un projet sous forme de fichier composer.phar.

Depuis le dossier du projet :

php composer-setup.phpLangage du code : CSS (css)

Composer crée alors un fichier :

composer.pharLangage du code : CSS (css)

On l’utilise ensuite ainsi :

php composer.phar installLangage du code : CSS (css)

Cette approche peut être utile sur un hébergement où vous n’avez pas les droits sudo, ou quand vous voulez figer Composer dans un environnement précis.

Composer installé via APT ou via l’installeur officiel ?

Ubuntu propose parfois un paquet composer dans ses dépôts :

sudo apt install composer

C’est simple, mais la version peut être plus ancienne que celle proposée par le projet Composer. Pour un serveur de développement ou un serveur qui doit tester des projets récents, je préfère l’installation officielle via l’installeur Composer.

Autre différence importante : si Composer a été installé via un gestionnaire de paquets système, la commande self-update peut ne pas être disponible. La documentation Composer précise que self-update n’est pas disponible si Composer n’a pas été installé comme PHAR, ce qui peut arriver avec une installation par gestionnaire de paquets.

Mettre à jour Composer

Pour mettre à jour Composer lui-même, il ne faut pas utiliser :

composer update

Cette commande met à jour les dépendances du projet courant. Elle lit le fichier composer.json, tient compte de composer.lock, puis met à jour les paquets du projet. Ce n’est pas la commande qui met à jour l’exécutable Composer.

Pour mettre à jour Composer lui-même, utilisez :

sudo -H composer self-updateLangage du code : PHP (php)

La documentation officielle indique que self-update remplace le fichier composer.phar par la dernière version disponible. Elle précise aussi qu’une installation globale peut nécessiter les droits root.

Pour revenir à la version précédente si quelque chose se passe mal :

sudo -H composer self-update --rollbackLangage du code : PHP (php)

Et pour forcer le canal stable :

sudo -H composer self-update --stableLangage du code : PHP (php)

Installer les dépendances d’un projet

Une fois Composer installé, on se place dans le dossier du projet, là où se trouve le fichier composer.json :

cd /home/www/example.com/public_html

Pour installer les dépendances exactes définies par composer.lock :

composer install

Pour mettre à jour les dépendances selon les contraintes du fichier composer.json :

composer update

La distinction est importante :

  • composer install installe ce qui est verrouillé dans composer.lock ;
  • composer update recalcule les versions et modifie composer.lock ;
  • composer self-update met à jour Composer lui-même.

En production, on utilise généralement composer install, pas composer update. Sinon, on change les versions des dépendances directement sur le serveur. Sportif, mais pas idéal.

Commandes utiles sur un serveur

Voici quelques commandes que j’utilise souvent après l’installation de Composer.

Vérifier la configuration :

composer diagnose

Afficher la version :

composer --version

Afficher la configuration globale :

composer config --global --listLangage du code : PHP (php)

Valider un fichier composer.json :

composer validate

Lister les paquets installés :

composer show

Voir pourquoi un paquet est installé :

composer why vendor/package

Voir pourquoi une version de PHP bloque une dépendance :

composer why-not php 8.3Langage du code : CSS (css)

Cette dernière commande est très pratique pour auditer la compatibilité d’un projet avec PHP 8.2, PHP 8.3 ou PHP 8.4.

Utiliser Composer pour tester la compatibilité PHP

Si l’objectif est de vérifier si un projet accepte une version donnée de PHP, Composer peut donner une première indication.

Depuis le dossier du projet :

composer check-platform-reqs

Cette commande vérifie les exigences de plateforme, comme la version de PHP et les extensions nécessaires.

On peut aussi simuler une version de PHP dans la configuration Composer du projet :

composer config platform.php 8.3.0Langage du code : CSS (css)

Puis demander pourquoi certaines dépendances bloquent :

composer update --dry-run
composer why-not php 8.3Langage du code : CSS (css)

Le --dry-run permet de tester sans écrire les changements. Toujours appréciable quand on préfère éviter les surprises en production. Étonnant, je sais.

Composer et WordPress

Dans l’écosystème WordPress, Composer sert souvent à gérer des dépendances dans un plugin, un thème, un mu-plugin, ou un projet complet basé sur Bedrock.

Pour un plugin WordPress, on peut par exemple installer une bibliothèque PHP :

composer require vendor/packageLangage du code : JavaScript (javascript)

Puis charger l’autoloader dans le plugin :

<?php
/**
 * Plugin Name: Example Composer Plugin
 */

defined( 'ABSPATH' ) || exit;

$autoload = __DIR__ . '/vendor/autoload.php';

if ( is_readable( $autoload ) ) {
    require_once $autoload;
}Langage du code : HTML, XML (xml)

Dans un plugin distribué publiquement, pensez à inclure le dossier vendor dans le zip final, sauf si votre processus de déploiement installe les dépendances automatiquement. WordPress.org n’exécute pas Composer pour les utilisateurs.

Éviter d’exécuter Composer en root dans les projets

Installer Composer globalement avec sudo est normal, car on écrit dans /usr/local/bin. En revanche, exécuter composer install ou composer update en root dans un projet est rarement une bonne idée.

Dans un site web, utilisez plutôt l’utilisateur propriétaire des fichiers du site. Par exemple :

sudo -u www-data composer install --no-dev --optimize-autoloader

Ou, selon votre organisation serveur :

sudo -u deploy composer install --no-dev --optimize-autoloader

Cela évite de créer des fichiers appartenant à root dans le projet. Sinon, le prochain déploiement ou la prochaine mise à jour risque de râler. Et il aura raison.

Installation optimisée pour production

Sur un serveur de production, on installe généralement les dépendances sans les outils de développement :

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

Pour des projets plus sensibles aux performances, on peut ajouter l’autoloader classmap autoritaire :

composer install --no-dev --prefer-dist --optimize-autoloader --classmap-authoritative

Cette option peut améliorer les performances d’autoloading, mais elle suppose que toutes les classes soient correctement déclarées dans l’autoload Composer. À utiliser quand le projet est propre.

Résoudre les erreurs fréquentes

Si Composer se plaint d’une extension manquante, installez le paquet PHP correspondant. Par exemple :

sudo apt install php-zip php-intl php-gd php-mysql php-bcmath

Puis vérifiez que l’extension est bien chargée :

php -m | grep zip

Si Composer échoue à cause de certificats SSL, vérifiez les certificats racines :

sudo apt install ca-certificates
sudo update-ca-certificates

Si la mémoire manque pendant une opération lourde :

COMPOSER_MEMORY_LIMIT=-1 composer install

Ce n’est pas une solution élégante à utiliser partout, mais cela dépanne lors d’un audit ou d’une migration ponctuelle.

Désinstaller Composer

Si Composer a été installé globalement dans /usr/local/bin, la désinstallation est simple :

sudo rm /usr/local/bin/composer

On peut vérifier qu’il n’est plus disponible :

which composer
composer --version

Si Composer a été installé via APT :

sudo apt remove composer

Mémo rapide

# Installer les prérequis.
sudo apt update
sudo apt install curl unzip php-cli php-mbstring php-xml php-curl

# Télécharger Composer.
curl -sS https://getcomposer.org/installer -o composer-setup.php

# Vérifier la signature.
EXPECTED_SIGNATURE="$(curl -s https://composer.github.io/installer.sig)"
ACTUAL_SIGNATURE="$(php -r "echo hash_file('sha384', 'composer-setup.php');")"

if [ "$EXPECTED_SIGNATURE" != "$ACTUAL_SIGNATURE" ]; then
    echo "Installer corrupt"
    rm composer-setup.php
    exit 1
fi

# Installer Composer globalement.
sudo php composer-setup.php --install-dir=/usr/local/bin --filename=composer

# Nettoyer.
rm composer-setup.php

# Vérifier.
composer --version

# Mettre à jour Composer lui-même.
sudo -H composer self-update

# Installer les dépendances d’un projet.
composer install

# Mettre à jour les dépendances d’un projet.
composer update

# Vérifier les exigences PHP/extensions.
composer check-platform-reqsLangage du code : PHP (php)

Conclusion

Installer Composer sur Ubuntu Server est simple, mais autant le faire proprement : installer les prérequis, télécharger l’installeur officiel, vérifier sa signature SHA-384, puis installer l’exécutable dans /usr/local/bin.

Une fois installé, Composer devient vite indispensable pour gérer les dépendances PHP, auditer un projet, tester une compatibilité avec PHP 8.x, ou préparer un déploiement plus propre.

Gardez surtout la distinction en tête : composer install installe les dépendances verrouillées, composer update met à jour les dépendances du projet, et composer self-update met à jour Composer lui-même. Trois commandes proches, trois effets très différents. Le genre de détail qui évite une journée délicieusement absurde.