12 %. C’est la part moyenne du temps de développement consacrée à l’écriture de tests PHPUnit, calculée sur l’ensemble des projets WordPress suivis sur une décennie, en excluant les phases de correction de bugs elles-mêmes. Ce chiffre seul ne dit rien du bénéfice obtenu ; il ne prend son sens qu’en regard de ce que ces tests ont permis d’éviter.
Cette rétrospective ne porte pas sur un projet unique ni sur un client précis : elle agrège des observations relevées sur plusieurs dizaines de projets, suivis dans la durée, où la pratique des tests automatisés s’est installée progressivement plutôt que d’un seul coup.
Ce qui est facile à mesurer : le temps investi
Le temps passé à écrire des tests se retrouve directement dans les feuilles de temps ou les commits horodatés, quand la discipline de séparer les commits de code et de tests est respectée. Sur la période observée, ce temps a représenté, en moyenne, entre 10 % et 15 % du temps total de développement d’une fonctionnalité, avec une variation importante selon la nature du projet : un module de calcul ou de traitement de données complexes tire ce chiffre vers le haut, une page de contenu statique le tire vers zéro.
Ce qui est plus difficile à mesurer : les régressions évitées
Une régression évitée par un test ne laisse, par définition, aucune trace en production. La méthode retenue pour l’estimer a consisté à comptabiliser, sur les projets suivis, le nombre de fois où un test existant a échoué avant une mise en production, empêchant ainsi qu’un changement ne parte en production avec un défaut. Ce nombre reste une estimation basse : il ne compte pas les régressions qu’un test aurait empêchées s’il avait existé, seulement celles effectivement interceptées par des tests déjà écrits.
Le tableau récapitulatif
| Indicateur | Constat sur la période observée |
|---|---|
| Temps moyen consacré aux tests | 12 % du temps de développement |
| Régressions interceptées avant mise en production | Plusieurs dizaines sur l’ensemble des projets suivis |
| Projets où le bénéfice net apparaît dès la première année | Minoritaires |
| Projets où le bénéfice net apparaît après deux ou trois ans | Majoritaires |
Le facteur qui change tout : la durée de vie du projet
Le constat le plus net de cette décennie tient en une observation simple : le retour sur investissement des tests automatisés dépend presque entièrement de la durée de vie prévue du projet. Sur un site conçu pour être remplacé ou profondément remanié en moins d’un an, le temps investi dans une suite de tests complète dépasse rarement le bénéfice obtenu. Sur un projet maintenu et fait évoluer pendant plusieurs années, chaque montée de version de WordPress ou de PHP devient l’occasion où la suite de tests rembourse, en une seule campagne de vérification, l’intégralité du temps investi à sa construction initiale.
Ce que les chiffres ne montrent pas
- Le confort psychologique de déployer sans crainte disproportionnée, difficile à quantifier mais régulièrement cité par les équipes concernées comme un bénéfice à part entière.
- Le coût des tests mal maintenus, qui échouent pour de mauvaises raisons et finissent ignorés, un phénomène qui annule une partie du bénéfice mesuré s’il n’est pas surveillé.
- La valeur de documentation vivante qu’apporte une suite de tests bien nommée, pour une personne qui découvre un projet plusieurs années après sa création.
Le seul chiffre qui compte vraiment, au bout de dix ans, n’est ni le temps investi ni le nombre de régressions évitées : c’est le nombre de fois où une mise à jour majeure s’est déroulée sans mauvaise surprise. C’est aussi, malheureusement, le plus difficile à mettre en tableau.
Notre verdict
Sur dix années d’observation, l’investissement dans une suite PHPUnit ne se justifie pas de façon uniforme : il se justifie en fonction de la durée de vie attendue du projet. Un temps d’écriture de tests autour de 12 % du temps de développement reste un coût raisonnable dès qu’un projet dépasse un horizon de deux ans, ce qui correspond, dans les faits, à la majorité des projets suivis sur cette période.
