Quatorze versions différentes d’une même bibliothèque PHP, utilisée par quatorze projets distincts d’une même agence, sans qu’aucune décision explicite n’ait jamais été prise en ce sens : ce constat, tiré d’un inventaire mené sur l’ensemble d’un parc de projets WordPress, a motivé la mise en place d’un fichier de contraintes central plutôt qu’un simple rappel de bonnes pratiques.
Ce genre de dérive ne vient pas d’une négligence identifiable. Chaque projet évolue à son propre rythme : une mise à jour de sécurité appliquée en urgence sur l’un, une contrainte de compatibilité imposée par une extension tierce sur un autre, un simple oubli de mise à jour sur un troisième resté inactif plusieurs mois. Individuellement, chaque choix est défendable. Collectivement, l’absence de référence commune transforme le parc en une collection de projets qui ne partagent plus rien de reproductible.
Le problème que résout un fichier de contraintes central
L’écosystème Composer permet de définir des contraintes de version dans le fichier composer.json de chaque projet, mais rien n’empêche ces contraintes de diverger d’un projet à l’autre au fil du temps. Un fichier de contraintes central répond à un besoin différent : fournir une source de vérité unique, versionnée séparément, qui définit les versions recommandées ou imposées pour l’ensemble des bibliothèques transverses utilisées par plusieurs projets du parc.
Ce fichier ne remplace pas le composer.json de chaque projet, il le complète : chaque projet référence le fichier central pour connaître la version à utiliser pour une bibliothèque donnée, plutôt que de la choisir indépendamment.
La structure retenue
Le fichier central prend la forme d’un dépôt Git séparé, contenant un fichier contraintes.json structuré ainsi :
{
"monolog/monolog": "^3.0",
"guzzlehttp/guzzle": "^7.5",
"symfony/console": "^6.3",
"vlucas/phpdotenv": "^5.5"
}Chaque projet du parc inclut ce dépôt comme dépendance de développement, et un script exécuté avant chaque composer update compare les contraintes déclarées dans le composer.json local à celles du fichier central, en signalant tout écart plutôt qu’en l’imposant silencieusement.
Pourquoi signaler plutôt qu’imposer automatiquement
Un mécanisme qui forcerait automatiquement chaque projet à adopter la version du fichier central, sans validation humaine, casserait régulièrement des projets dont les contraintes locales avaient une raison précise de diverger — une extension tierce incompatible avec la dernière version majeure d’une bibliothèque, par exemple. Le choix retenu privilégie donc un avertissement explicite lors de la mise à jour des dépendances, laissant à la personne qui exécute la mise à jour la décision d’aligner le projet ou de documenter une exception justifiée.
- Le fichier central est la référence par défaut, pas une contrainte absolue
- Tout écart documenté reste acceptable s’il est explicite et justifié
- La mise à jour du fichier central elle-même passe par une revue avant fusion, comme tout changement transverse
Ce que ce mécanisme a changé sur le parc
Six mois après l’introduction du fichier central, le nombre de versions différentes observées pour les bibliothèques les plus utilisées est passé de quatorze à trois pour l’exemple cité en ouverture, les trois versions restantes étant chacune documentée par une raison précise de compatibilité. Ce résultat n’élimine pas toute divergence — ce n’était pas l’objectif — mais rend chaque divergence restante traçable et volontaire plutôt qu’accidentelle.
Les limites de cette approche
Ce fichier de contraintes ne couvre que les bibliothèques transverses, celles partagées par plusieurs projets ; les dépendances spécifiques à un seul projet restent hors de son périmètre, ce qui est cohérent avec son objectif. Il ne remplace pas non plus un outil de veille automatisée sur les vulnérabilités des dépendances, qui répond à une préoccupation différente et complémentaire, déjà traitée par ailleurs dans l’outillage du parc.
En résumé
Un fichier de contraintes central ne demande aucun outil supplémentaire au-delà de Composer et d’un script de comparaison simple, mais il referme durablement un écart qui, laissé sans surveillance, s’élargit inévitablement projet après projet. La valeur ne vient pas de l’automatisation d’une contrainte rigide, mais de la visibilité qu’elle apporte sur des décisions qui, sans elle, restaient invisibles jusqu’au jour où elles posaient problème.
