Déployer WordPress avec Composer : gérer le cœur et les plugins en dépendances

Un site WordPress installé de façon classique mélange dans un même répertoire le cœur du logiciel, les extensions téléchargées, les thèmes et le peu de code réellement propre au projet. Versionner cet ensemble revient à placer dans un dépôt des dizaines de milliers de fichiers que personne n'a écrits et que personne ne modifiera. Déclarer plutôt ces composants comme des dépendances, avec leurs versions, réduit le dépôt à ce qui appartient au projet et rend l'installation reproductible. Cette approche demande un peu de mise en place et elle change durablement la façon de travailler.

Ce que l'approche change

Le bénéfice mérite d'être posé clairement, parce que la mise en place demande un investissement initial et qu'elle déroute les personnes habituées à l'installation traditionnelle. Trois changements structurants justifient l'effort. Les mécanismes de base de l'outil sont présentés dans notre article sur l'autoload PSR-4 et Composer sur un site fait main.

Un dépôt réduit à l'essentiel

Le dépôt ne contient plus que le fichier de dépendances, la configuration, le thème enfant et les éventuelles extensions maison. Il passe de plusieurs dizaines de milliers de fichiers à quelques dizaines, ce qui rend les comparaisons lisibles et les historiques exploitables. Le clonage du dépôt devient par ailleurs instantané, là où il prenait plusieurs minutes. Une modification apportée au projet apparaît immédiatement, au lieu de se noyer dans une mise à jour de cœur. C'est le changement le plus visible au quotidien. Une revue de code devient enfin possible, ce qui était illusoire sur un dépôt où chaque mise à jour produisait des milliers de lignes de différence.

Des versions explicites

Chaque composant est déclaré avec une contrainte de version, ce qui rend l'installation reproductible : deux installations à partir du même fichier produisent exactement le même site. Cette propriété élimine la classe entière des problèmes que l'on résume habituellement par la formule cela fonctionne pourtant chez moi. Elle permet aussi de savoir précisément quelle version d'une extension tourne en production, information souvent approximative autrement. Cette précision devient déterminante lorsqu'une vulnérabilité est annoncée sur une version donnée.

Des mises à jour maîtrisées

Mettre à jour devient une commande, suivie d'un test et d'un déploiement, plutôt qu'un clic dans une interface d'administration. Le fichier de verrouillage enregistre les versions exactes installées, ce qui permet de revenir en arrière en une opération. Cette maîtrise est particulièrement précieuse lorsqu'une mise à jour casse quelque chose. Elle suppose en contrepartie de désactiver les mises à jour depuis l'interface, sous peine d'incohérence. Ce changement d'habitude est le principal point de friction avec les équipes qui géraient le site auparavant.

Un déploiement reproductible

Le déploiement consiste à récupérer le dépôt et à installer les dépendances, ce qui produit une installation identique à chaque fois. Aucun transfert de fichiers volumineux n'est nécessaire, seule la liste des composants circulant. Sur un site comptant vingt extensions, le gain de temps est net, un déploiement classique par transfert prenant plusieurs minutes pour le même résultat. Cette reproductibilité est la condition d'une chaîne d'intégration continue utile. Sans elle, chaque déploiement produit un état légèrement différent et les tests perdent leur valeur.

Ce que cela ne règle pas

La base de données, les fichiers téléversés et les réglages enregistrés en base restent hors du périmètre. Une installation fraîche produit un site fonctionnel et vide, ce qui suffit pour un environnement de développement et pas pour reproduire la production. La séparation entre code et données reste donc entière et elle doit être traitée par les sauvegardes, qui restent indispensables. Cette limite doit être comprise avant de croire l'ensemble du site versionné. Les réglages enregistrés en base, en particulier, continuent d'échapper à toute traçabilité, ce qui reste le point faible de l'écosystème.

Les contraintes acceptées

L'approche suppose un accès en ligne de commande, au moins au moment du déploiement, ce que tous les hébergements ne permettent pas. Elle demande aussi que l'équipe accepte de ne plus installer d'extension depuis l'interface, changement d'habitude parfois mal vécu. Sur un site géré par un client autonome, cette contrainte peut être rédhibitoire. L'approche convient donc surtout aux projets suivis par une équipe technique. Sur un site vitrine confié à un client après livraison, une installation classique reste souvent le choix le plus raisonnable.

Structurer le projet

La structure retenue détermine la simplicité de la suite. Deux organisations coexistent et la seconde s'est largement imposée.

Le cœur dans un sous répertoire

La structure recommandée place le cœur dans un répertoire dédié, distinct de la racine web, avec les contenus dans un autre répertoire. Cette séparation permet de mettre à jour le cœur sans jamais toucher aux contenus, et elle réduit la surface exposée publiquement. Elle demande quelques lignes de configuration pour indiquer au logiciel où il se trouve. C'est la structure à retenir sur un nouveau projet. La migration d'un site existant vers cette organisation est possible et elle demande une intervention sur les adresses enregistrées en base.

Le point d'entrée

Un fichier d'amorçage placé à la racine web charge la configuration puis le cœur situé ailleurs. Ce fichier appartient au projet et il est versionné, contrairement au cœur lui même. Sa présence explique pourquoi la structure fonctionne malgré le déplacement du cœur. Il tient en quelques lignes et il ne bouge plus ensuite. Un modèle éprouvé se copie d'un projet à l'autre, ce qui réduit cette étape à quelques secondes.

La configuration par environnement

Les identifiants de base de données, les clés et les adresses diffèrent entre développement, recette et production. Les placer dans des variables d'environnement, lues par un fichier de configuration unique versionné, évite de maintenir trois fichiers divergents. Cette approche est devenue la norme et elle simplifie considérablement les déploiements. Le fichier contenant les valeurs réelles ne doit évidemment jamais être versionné. Un exemplaire d'exemple, sans valeurs, versionné à côté, documente les variables attendues sans rien exposer.

Le thème enfant et les extensions maison

Le code réellement écrit pour le projet doit vivre dans le dépôt, aux emplacements attendus par le logiciel. Une configuration indique à l'outil de dépendances de ne pas toucher à ces répertoires, sous peine de les voir écrasés. Cette distinction entre code du projet et composants installés est le point de vigilance principal de la mise en place. Une erreur à cet endroit efface du travail. Le contrôle consiste à lancer une installation sur une copie et à vérifier que le thème enfant et les extensions maison sont toujours là.

Les répertoires à exclure

Le répertoire des médias, celui du cache et les fichiers produits par les extensions ne doivent pas être versionnés. Une liste d'exclusions bien écrite évite un dépôt qui grossit indéfiniment et des conflits sans objet. Cette liste doit être établie au moment de la mise en place et relue à chaque ajout d'extension produisant des fichiers. Un dépôt qui grossit de plusieurs mégaoctets par semaine signale généralement une exclusion oubliée.

La cohérence avec le serveur

La configuration du serveur web doit pointer vers la racine du projet et non vers le répertoire du cœur. Une erreur à ce niveau expose des fichiers qui ne devraient pas l'être, ou produit un site inaccessible. Ce réglage se fait une fois et il doit être documenté, notamment lorsque l'hébergement est infogéré et que la modification passe par une demande au prestataire. Une erreur fréquente consiste à conserver l'ancienne racine après migration, ce qui laisse deux points d'entrée fonctionnels. Les mécanismes d'installation en ligne de commande sont détaillés dans notre article sur l'installation de WordPress en ligne de commande sur un VPS Debian.

Déclarer les composants

La déclaration passe par un fichier unique, dont quelques sections méritent une attention particulière.

Les dépôts de paquets

Un dépôt communautaire expose l'ensemble des extensions et thèmes du dépôt officiel sous forme de paquets installables. Le déclarer dans le fichier de configuration donne accès à des milliers de composants sans démarche supplémentaire. C'est ce qui rend l'approche praticable, la quasi totalité des extensions courantes étant disponibles. Sans lui, il faudrait déclarer chaque extension à la main comme un paquet distant, ce qui serait rédhibitoire. Son fonctionnement repose sur une synchronisation automatique avec le dépôt officiel, avec un décalage de quelques minutes après la publication d'une nouvelle version.

Les contraintes de version

Chaque composant se déclare avec une contrainte, qui peut être une version exacte, une plage ou une règle autorisant les correctifs. Figer une version exacte garantit la stabilité et impose une intervention manuelle à chaque mise à jour de sécurité. Autoriser les correctifs sans changement majeur constitue le compromis courant. Il laisse passer les corrections de sécurité tout en écartant les changements de comportement. Le choix doit être conscient plutôt que laissé aux valeurs proposées par défaut. Sur les extensions critiques du site, figer la version et tester chaque montée reste la position la plus prudente.

Le fichier de verrouillage

Un second fichier enregistre les versions exactes installées lors de la dernière résolution. C'est lui qui garantit la reproductibilité et il doit impérativement être versionné. Le déploiement doit installer à partir de ce fichier plutôt que de recalculer les versions, ce qui suppose d'employer la bonne commande. Cette nuance est essentielle et elle est régulièrement ignorée. Employer la commande de résolution en production revient à annuler tout le bénéfice de reproductibilité recherché.

L'emplacement d'installation

Une section de configuration indique où chaque type de composant doit être installé : extensions dans un répertoire, thèmes dans un autre, cœur ailleurs. Sans cette déclaration, tout atterrit dans le répertoire des bibliothèques, où le logiciel ne trouvera rien. Cette configuration se copie d'un projet à l'autre et elle constitue le passage obligé de la mise en place. Elle repose sur une extension dédiée, à déclarer elle même comme dépendance.

Les extensions payantes

Les extensions commerciales ne figurent pas dans le dépôt communautaire et demandent un traitement particulier. Certains éditeurs proposent un dépôt privé accessible avec une clé de licence, ce qui est la solution la plus propre. À défaut, une archive déposée sur un espace privé, déclarée comme paquet, fonctionne parfaitement, au prix d'une mise à jour manuelle de l'archive à chaque nouvelle version. La clé de licence doit être traitée comme un secret et elle ne doit jamais figurer dans le dépôt. Un fichier d'authentification séparé, ou une variable d'environnement, remplit ce rôle proprement.

Les correctifs locaux

Modifier directement le code d'une extension installée en dépendance est perdu à la première mise à jour. Un mécanisme de correctifs permet d'appliquer automatiquement une modification après chaque installation, ce qui rend la retouche durable. Cette approche est nettement préférable à la duplication de l'extension entière, qui prive le projet de toutes les mises à jour ultérieures. Elle doit rester exceptionnelle et documentée, un correctif oublié devenant incompréhensible. Signaler le problème à l'éditeur reste par ailleurs la meilleure façon de faire disparaître le correctif à terme.

Déployer et maintenir

Le quotidien change plus que la mise en place ne le laisse penser, et quelques habitudes rendent le dispositif durable.

La commande de déploiement

Le déploiement consiste à récupérer la version du dépôt puis à installer les dépendances sans recalculer les versions, avec les optimisations destinées à la production. Cette séquence tient en trois commandes et elle s'automatise immédiatement dans une chaîne d'intégration continue. Elle produit un site identique à celui testé en recette, ce qui est tout l'intérêt de la démarche et sa principale justification. Le temps d'installation dépend du nombre de composants et il reste inférieur à une minute dans les cas courants. Une mise en cache des paquets sur le serveur réduit encore ce délai sur les déploiements répétés.

Désactiver les mises à jour depuis l'interface

Une mise à jour effectuée depuis l'administration écrase un composant installé par dépendance, ce qui produit une divergence entre le dépôt et la production. Cette divergence disparaît au déploiement suivant, avec un retour en arrière inattendu et particulièrement déroutant pour qui ne connaît pas le mécanisme. Désactiver ces mises à jour par une constante de configuration évite ce cycle. C'est le premier réglage à poser après la migration. Il vaut mieux l'accompagner d'une explication aux personnes concernées, faute de quoi la disparition du bouton sera vécue comme une panne.

Tester avant de déployer

La mise à jour d'un composant se fait en local ou en recette, avec un contrôle du site, avant d'être validée dans le dépôt. Cette discipline est ce qui transforme l'approche en gain réel : sans elle, on remplace un clic risqué par une commande risquée, sans rien gagner d'autre qu'un dépôt plus propre. Un parcours de dix minutes sur les gabarits principaux suffit à écarter la quasi totalité des régressions visibles. Il doit inclure les fonctions les plus sensibles du site, formulaires, tunnel de commande et espace connecté selon les cas.

Revenir en arrière

Un retour à la version précédente consiste à restaurer les deux fichiers de dépendances et à réinstaller. L'opération prend une minute et elle produit exactement l'état antérieur. Cette possibilité est le principal argument de l'approche auprès des équipes réticentes. Le démontrer une fois, sur un cas réel, convainc plus sûrement que toute explication théorique. Elle suppose que la base n'ait pas été modifiée entre temps, ce qui est le cas pour la plupart des mises à jour d'extensions. Les rares mises à jour modifiant la structure de la base demandent en revanche une restauration complète.

Surveiller les vulnérabilités

Des outils analysent le fichier de verrouillage et signalent les composants comportant une vulnérabilité connue. Cette vérification peut être automatisée dans une chaîne d'intégration et exécutée chaque semaine, avec une alerte en cas de composant concerné. Elle remplace avantageusement la surveillance manuelle des annonces de sécurité, exercice que personne ne tient sérieusement sur la durée. C'est un bénéfice inattendu de l'approche et l'un des plus utiles. Il transforme une veille manuelle, que personne ne tient dans la durée, en contrôle automatique.

Documenter la structure

Une note expliquant où se trouve chaque chose, comment installer, comment mettre à jour et comment déployer permet à un nouvel intervenant de démarrer. Sans elle, une structure non standard déroute et pousse à revenir à une installation classique, ce qui annule le travail de mise en place. Cette documentation doit accompagner le dépôt et rester courte. Un fichier de présentation à la racine, listant les commandes usuelles, remplit parfaitement ce rôle et se lit en deux minutes. Les commandes d'administration complémentaires sont détaillées dans notre article sur les commandes WP-CLI et la gestion avancée de WordPress. Elle se place à la racine du dépôt, où le prochain intervenant la trouvera sans avoir à la chercher.