On nous demande régulièrement, en formation ou en entretien technique, quelle est « la » bonne stack d’outillage pour WordPress. La question appelle une réponse honnête plutôt qu’un classement définitif : la nôtre a changé plusieurs fois en quelques années, chaque changement motivé par un problème concret rencontré, jamais par la simple envie de suivre une tendance. Voici où elle en est aujourd’hui, catégorie par catégorie, avec la raison de chaque choix plutôt qu’une description exhaustive de chaque outil.
Environnement local : DDEV
Nous sommes passés à DDEV après avoir constaté trop de divergences de configuration entre les postes d’une équipe qui utilisait chacun sa propre installation locale. L’argument décisif reste le même aujourd’hui : la configuration se versionne dans le dépôt du projet, ce qui garantit qu’un nouveau développeur démarre exactement le même environnement que ses collègues, sans réglage manuel de version de PHP ou de base de données.
Build front-end : pnpm et @wordpress/scripts
Pour le build JavaScript et CSS, @wordpress/scripts reste notre socle, complété selon les projets par une configuration Vite quand un rechargement instantané plus rapide se justifie. Le choix de pnpm comme gestionnaire de paquets, plutôt que npm, tient à l’économie d’espace disque sur un poste qui héberge des dizaines de projets WordPress en parallèle, plus qu’à un gain de vitesse à l’usage quotidien.
Qualité de code : PHPCS, PHPStan et les tests unitaires
Trois outils composent notre chaîne de qualité, chacun avec un rôle distinct : PHPCS pour le respect des conventions de codage (avec le standard WordPress Coding Standards comme base, adapté par quelques règles internes), PHPStan pour l’analyse statique qui détecte des erreurs de type avant l’exécution, et PHPUnit pour les tests unitaires sur la logique métier la plus critique de chaque projet — jamais une couverture à cent pour cent, mais systématiquement sur les fonctions qui touchent au paiement ou aux données personnelles.
{
"scripts": {
"lint:php": "phpcs --standard=phpcs.xml",
"analyse": "phpstan analyse --memory-limit=512M",
"test": "phpunit --testdox"
}
}
Intégration continue : GitHub Actions avec workflows réutilisables
Après avoir dupliqué le même pipeline dans une dizaine de dépôts, nous centralisons désormais la logique commune (lint, analyse statique, tests) dans des workflows réutilisables, appelés depuis chaque projet client avec un minimum de paramètres propres à ce projet. Le gain principal n’est pas la vitesse d’exécution, mais la garantie qu’une évolution de la chaîne de qualité se propage à tous les projets sans les modifier un par un.
Déploiement : releases atomiques via Deployer
Le déploiement en production repose sur un schéma de releases atomiques, chaque nouvelle version étant déployée dans un dossier isolé avant qu’un lien symbolique ne soit repointé vers elle. Ce choix a été acté après un incident où un déploiement en place, interrompu à mi-transfert, avait laissé un site dans un état incohérent pendant plusieurs minutes. Le rollback, dans ce schéma, se résume à repointer le lien vers la release précédente.
Monitoring : sonde d’uptime et journal centralisé
Pour le monitoring, nous restons volontairement modestes sur la majorité des projets : une sonde d’uptime externe qui vérifie la disponibilité toutes les cinq minutes, et un agrégateur de journaux qui centralise les erreurs PHP de tous les sites du parc en un seul endroit consultable. L’instrumentation plus poussée (traces distribuées, métriques détaillées) reste réservée aux quelques projets dont l’architecture ou le trafic la justifie réellement, plutôt que généralisée par principe.
| Catégorie | Outil retenu | Ce qu’il a remplacé |
|---|---|---|
| Environnement local | DDEV | Installations locales non versionnées |
| Build front-end | @wordpress/scripts + pnpm | Configurations Webpack maison, npm |
| Qualité de code | PHPCS, PHPStan, PHPUnit | Relecture manuelle seule |
| CI | GitHub Actions, workflows réutilisables | Pipelines dupliqués par projet |
| Déploiement | Deployer, releases atomiques | rsync en place |
| Monitoring | Sonde d’uptime + journal centralisé | Vérification manuelle occasionnelle |
Ce qui compte plus que chaque outil pris isolément
Aucun de ces choix n’est gravé dans le marbre, et plusieurs ont déjà été révisés une fois depuis leur adoption initiale. Ce qui compte davantage que la performance brute de chaque outil pris isolément, c’est leur cohérence entre eux : une configuration DDEV qui déclare la même version de PHP que celle testée en CI et déployée en production évite bien plus d’incidents qu’un choix individuellement optimal mais isolé des autres maillons de la chaîne.
On change rarement un outil de la stack sur un coup de tête. Chaque changement qu’on a fait ces dernières années répondait à un incident précis ou à une friction répétée, jamais à l’envie d’essayer la nouveauté du moment.
En résumé
Cette stack n’a rien d’exceptionnel prise outil par outil : chacun de ces choix est documenté ailleurs individuellement, avec ses détails de mise en œuvre. Ce qui la rend efficace, c’est la cohérence maintenue entre chaque maillon — environnement local, build, qualité, CI, déploiement, monitoring — plutôt que la recherche du meilleur outil possible dans chaque catégorie prise isolément.
