vendredi 25 septembre 2026

À propos

Contact

Outils & workflow

VVV, l’environnement historique des cœurs contributeurs : le remonter en 2020

VVV a formé des générations de contributeurs au cœur de WordPress. En 2020, face à Local et Docker, garde-t-il un intérêt pour une équipe d'agence ?

Par Clément Hadrot • 18 juillet 2020 • 4 min de lecture • Aucun commentaire
VVV, l'environnement historique des cœurs contributeurs : le remonter en 2020

VVV, pour Varying Vagrant Vagrants, est probablement l’environnement de développement WordPress le plus ancien encore activement maintenu. Né dans l’orbite des contributeurs au cœur du logiciel, il a longtemps été la référence pour quiconque voulait tester une future version de WordPress dans des conditions proches de celles utilisées par l’équipe core elle-même. En 2020, avec l’essor de Local et l’adoption grandissante de Docker en agence, la question mérite d’être posée frontalement : ce projet garde-t-il un intérêt en dehors du cercle des contributeurs historiques ?

Pour y répondre, on l’a remonté sur une machine récente, à partir d’un dépôt cloné il y a plusieurs années et jamais mis à jour, afin de juger honnêtement de l’expérience qu’il offre aujourd’hui à une équipe qui ne connaît pas déjà ses habitudes.

Ce que propose VVV concrètement

VVV repose sur Vagrant et VirtualBox : une vraie machine virtuelle, provisionnée par des scripts Bash et Ansible, qui installe Apache ou nginx, MySQL, PHP, WP-CLI, et plusieurs sites de test préconfigurés. Le fichier config/config.yml permet de déclarer des sites additionnels, chacun avec son propre domaine local et sa propre base :

sites:
  mon-projet:
    repo: https://github.com/mon-agence/mon-projet.git
    hosts:
      - mon-projet.test

Un vagrant up suffit ensuite à provisionner l’ensemble, mais ce mot « suffit » cache une réalité moins confortable qu’on pourrait l’espérer en 2020.

Le remontage : ce qui a posé problème

L'essentiel à retenir : Environnement de référence des contributeurs core ; Provisioning long mais complet ; Face à Local et Docker, un choix de niche

Sur une machine à jour, la première tentative de vagrant up a buté sur une incompatibilité de version entre VirtualBox et le Vagrantfile généré par une ancienne version de VVV. Il a fallu mettre à jour le dépôt vers la branche stable la plus récente pour que le provisioning morde correctement. Une fois ce point réglé, le provisioning complet a pris un peu plus de quinze minutes, le temps de télécharger la box Ubuntu de base et d’installer l’ensemble de la pile serveur.

Ce délai n’a rien d’anormal pour une vraie machine virtuelle avec un système d’exploitation complet : c’est le prix d’un environnement qui reproduit fidèlement un vrai serveur Linux, avec ses vrais services système, plutôt qu’un ensemble de conteneurs partageant le noyau de l’hôte.

Les vrais atouts qui restent

  • Un environnement extrêmement proche de ce qu’utilise l’équipe de développement du cœur de WordPress pour ses propres tests, utile pour qui contribue à des tickets Trac.
  • Une configuration Ansible lisible et personnalisable en profondeur, sans dépendre d’une interface graphique propriétaire.
  • Plusieurs versions de PHP disponibles simultanément dans la même machine, ce qui facilite les tests de compatibilité multi-version.
  • Un vrai système Linux complet, utile pour reproduire des comportements spécifiques au système de fichiers ou aux permissions Unix.

Ce qui pèse contre lui en 2020

Face à Local, qui propose un environnement fonctionnel en quelques clics avec une interface graphique et un changement de version PHP en un menu déroulant, VVV demande un investissement initial nettement plus lourd : comprendre Vagrant, comprendre Ansible, éditer des fichiers YAML pour chaque nouveau site. Pour une équipe d’agence qui gère des dizaines de projets clients avec un turnover de développeurs, cette courbe d’apprentissage devient un coût réel, répété à chaque arrivée.

Docker, de son côté, offre une isolation comparable avec un démarrage plus rapide et un écosystème d’images already prêtes à l’emploi, sans passer par une virtualisation complète du système d’exploitation.

VVV reste un excellent choix pour qui contribue activement au cœur de WordPress. Pour une agence qui livre des sites clients, ce n’est plus le rapport effort/bénéfice le plus favorable en 2020.

Pour qui VVV garde-t-il du sens

Le profil qui tire encore le plus de valeur de VVV est le contributeur régulier au cœur ou aux tickets Trac, qui a besoin de reproduire l’environnement exact utilisé par l’équipe de développement, avec ses versions de PHP multiples et sa configuration Ansible partagée par la communauté. Pour une équipe qui code des sites vitrine ou des plateformes e-commerce sans lien direct avec le développement du cœur, l’investissement ne se justifie plus face aux alternatives plus rapides à prendre en main.

Notre verdict

VVV n’est pas un projet dépassé, il reste maintenu et fonctionnel. Mais son public naturel s’est resserré autour des contributeurs historiques, et une agence qui cherche avant tout à réduire le temps de mise en route d’un nouveau projet trouvera aujourd’hui plus d’efficacité du côté de Local ou d’une configuration Docker maison. Le remonter en 2020 confirme sa robustesse technique, pas sa pertinence pour tous les usages.

Partager :

À propos de l'auteur

Clément Hadrot

Développeur WordPress, passionné par Elementor, le FSE et l’automatisation par IA.

Voir tous ses articles

Dans la même veine

À lire aussi