Une agence qui gère quinze projets WordPress en parallèle, chacun avec un budget de maintenance différent, ne peut pas appliquer la même exigence de tests partout. Viser 100 % de couverture de code sur un site vitrine simple mobilise un temps que le client ne finance pas et que le risque réel ne justifie pas. À l’inverse, laisser un module de paiement ou de calcul tarifaire sans aucun test expose à des bugs coûteux, en argent et en confiance. Après plusieurs années à gérer ce type d’arbitrage, voici la stratégie que nous appliquons.
Cet article détaille comment nous fixons des objectifs de couverture différenciés selon la criticité du code, comment nous utilisons les rapports de couverture sans en faire un objectif en soi, et les erreurs de priorisation les plus fréquentes que nous avons observées chez d’autres équipes.
La couverture de code n’est pas un objectif, c’est un radar
Un pourcentage de couverture élevé ne garantit pas des tests de qualité : il est parfaitement possible d’atteindre 90 % de couverture avec des tests qui n’affirment presque rien, en appelant simplement chaque fonction sans vérifier son comportement. Nous utilisons la couverture pour une seule chose : repérer les zones du code qui ne sont couvertes par aucun test, pas pour fixer un score à atteindre à tout prix.
vendor/bin/phpunit --coverage-html tests/coverage --coverage-textCette commande, qui nécessite Xdebug ou PCOV activé, génère un rapport HTML navigable qui montre, ligne par ligne, ce qui est exécuté par la suite de tests. C’est cette vue, fichier par fichier, qui a le plus de valeur pour une agence : elle révèle rapidement qu’un module de calcul de devis n’est couvert par aucun test, alors qu’un simple shortcode d’affichage l’est à 100 %, ce qui est en général l’inverse de ce qu’on voudrait.
Classer le code par criticité avant de fixer un objectif
Sur chaque projet, nous classons le code en trois catégories avant même de parler de pourcentage de couverture :
- Critique : calculs financiers, gestion des droits d’accès, traitement de données sensibles, intégrations de paiement. Objectif : couverture proche de 90 %, avec des tests qui couvrent explicitement les cas limites.
- Important : logique métier standard, requêtes de contenu, formulaires de contact. Objectif : couverture autour de 60 %, centrée sur les chemins les plus utilisés.
- Cosmétique : gabarits d’affichage, styles conditionnels, petites variations visuelles. Objectif : tests ponctuels seulement, souvent E2E sur les parcours les plus visibles, sans viser de pourcentage précis.
Adapter l’exigence au budget du client
Un site vitrine facturé pour quelques jours de développement n’aura jamais le même budget de tests qu’une plateforme e-commerce avec abonnement de maintenance mensuel. Plutôt que d’imposer un standard unique, nous proposons trois niveaux de service, discutés explicitement avec le client lors du cadrage :
| Niveau | Couverture visée | Type de projet typique |
|---|---|---|
| Essentiel | Tests manuels + PHPCS/PHPStan en CI | Site vitrine, contenu éditorial simple |
| Standard | PHPUnit sur la logique métier (~50-60 %) | Site avec formulaires complexes, intégrations tierces |
| Critique | PHPUnit + E2E ciblé (~80-90 % sur le cœur métier) | E-commerce, plateforme avec paiement ou données sensibles |
Ce classement, présenté explicitement au client, évite deux écueils opposés : sur-investir dans des tests que personne ne lira jamais sur un site simple, ou sous-investir sur un module qui manipule de l’argent réel.
Erreurs de priorisation fréquentes
En auditant les suites de tests d’autres agences pour des reprises de projet, nous retrouvons régulièrement les mêmes déséquilibres :
- Des tests exhaustifs sur des fonctions de formatage triviales, alors que la logique de calcul de prix reste entièrement non testée.
- Une couverture élevée obtenue en testant des getters et setters qui ne contiennent aucune logique, ce qui gonfle artificiellement le pourcentage global.
- Aucun test sur les hooks qui modifient le comportement d’un plugin tiers, alors que ce sont souvent les points de rupture lors d’une mise à jour.
Sur nos projets, nous répétons régulièrement à l’équipe qu’un module à 40 % de couverture concentrée sur les cas critiques vaut infiniment mieux qu’un module à 95 % de couverture qui ne teste que les chemins évidents. Le pourcentage seul ne dit jamais où se trouve réellement le risque.
En résumé
Une stratégie de couverture de tests efficace pour une agence multi-clients commence par une classification honnête de la criticité du code, pas par un pourcentage arbitraire appliqué uniformément. Réserver l’effort le plus important aux modules critiques, accepter une couverture plus légère sur le code cosmétique, et discuter explicitement du niveau de service avec chaque client transforme les tests en un investissement proportionné au risque réel, plutôt qu’en une case à cocher qui rassure sans vraiment protéger.
