Deux fichiers, composer.json et composer.lock, ont suffi à remplacer des dizaines de dossiers de bibliothèques que nos dépôts versionnaient auparavant ligne par ligne. Ce changement paraît d’abord technique. Il ne l’est pas seulement : il a transformé la manière dont un projet se construit, se transmet et se relit d’une personne à l’autre dans une équipe.
Avant l’adoption généralisée de Composer sur les projets WordPress, une bibliothèque PHP tierce s’ajoutait en copiant son code source directement dans le dépôt du thème ou de l’extension. La mise à jour consistait à remplacer le dossier entier, en croisant les doigts pour ne rien casser au passage. Ce billet ne traite pas de la configuration de Composer lui-même, mais de ce que son adoption a changé dans la façon de livrer un projet.
Le dépôt racontait autrefois tout, y compris ce qu’il ne devrait pas contenir
Un dépôt Git de projet WordPress, en 2018 encore, mélangeait fréquemment le code métier écrit par l’équipe et le code de bibliothèques tierces recopiées telles quelles. Cette confusion avait un coût : un historique de commits pollué par des mises à jour de bibliothèques sans rapport avec le travail réel, une taille de dépôt qui gonflait sans limite, et surtout une incapacité à savoir, sans ouvrir chaque fichier, quelle version d’une bibliothèque tournait réellement en production.
La déclaration des dépendances dans composer.json a inversé cette logique. Le dépôt ne décrit plus le contenu des bibliothèques, il décrit une intention : telle version de telle bibliothèque, avec une contrainte de compatibilité. Le contenu réel, lui, se reconstruit à partir de cette intention.
Le lockfile est devenu la véritable source de vérité d’une livraison
Le fichier composer.lock a pris une place que peu d’équipes anticipaient au départ. Il ne se contente pas de fixer des numéros de version : il fige l’arbre complet des dépendances, y compris les dépendances des dépendances, avec leurs sommes de contrôle. Deux machines qui installent à partir du même lockfile obtiennent, en théorie, un code strictement identique.
Cette garantie a changé la nature de ce qu’on livre à un client ou qu’on transmet à un collègue. Avant, on livrait un état de fichiers. Depuis, on livre une intention reproductible : le lockfile, associé au dépôt, permet de reconstruire l’état exact du projet sur n’importe quelle machine correctement configurée.
- Le lockfile doit être versionné, jamais ignoré par erreur dans un fichier
.gitignoretrop large. - Une mise à jour de dépendance devient un commit isolé et relisable, pas un remplacement silencieux de dossier.
- La différence entre deux livraisons se lit désormais dans le diff du lockfile, pas dans des dossiers de bibliothèques entiers.
Un changement de posture pour l’équipe, pas seulement pour l’outillage
Ce déplacement a eu une conséquence qu’on mesure surtout après coup : le développeur passe moins de temps à recopier du code tiers et plus de temps à arbitrer des versions. Faut-il figer une bibliothèque sur une version précise par prudence, ou accepter une plage de versions compatibles pour bénéficier des correctifs de sécurité sans intervention manuelle ? Cette question, avant, ne se posait presque jamais aussi explicitement.
Elle a aussi changé la relecture de code. Un pair qui relit une proposition de modification voit désormais un composer.json qui évolue rarement, et un composer.lock qui évolue à chaque mise à jour de dépendance. Cette séparation rend visible ce qui, avant, restait noyé dans des dossiers entiers recopiés.
Un effet secondaire sur la taille des dépôts
La taille des dépôts a mécaniquement diminué, puisque le code des bibliothèques n’est plus versionné. Ce n’était pas l’objectif premier de l’outil, mais c’est devenu un argument pratique pour convaincre une équipe encore attachée à l’ancienne méthode : cloner un projet devient plus rapide, et l’historique Git redevient lisible.
Ce que ce changement n’a pas résolu
Cette évolution n’a pas supprimé le besoin de comprendre ce que chaque dépendance fait réellement. Elle a simplement déplacé le risque : d’une copie de code mal maîtrisée vers une confiance parfois excessive dans une contrainte de version mal choisie. Une contrainte trop permissive peut introduire, sans commit visible dans le dépôt principal, une version qui casse une compatibilité PHP ou qui change un comportement attendu.
Une dépendance qu’on ne relit jamais reste une dépendance qu’on subit, même si elle est parfaitement versionnée.
C’est pourquoi le passage à cette gestion déclarative des dépendances s’est accompagné, dans nos pratiques, d’une revue régulière du contenu du lockfile lors des mises à jour majeures, plutôt que d’une confiance aveugle dans la mécanique.
En résumé
Le changement introduit par Composer sur un projet d’agence n’est pas d’abord une question d’outil, mais d’habitude de livraison. Le dépôt cesse de contenir ce qu’il n’a pas besoin de contenir, le lockfile devient la référence partagée d’une équipe, et l’attention du développeur se déplace du recopiage de code vers l’arbitrage des versions. C’est un déplacement discret, mais il a changé durablement la façon dont un projet WordPress se transmet d’une personne à l’autre.
