82 % de couverture de code affichés dans le rapport de livraison d’une extension développée par un prestataire externe pour une association de tourisme solidaire — un chiffre qui semblait rassurant, jusqu’à ce qu’un examen plus poussé révèle que le module de gestion des règlements, le plus sensible du projet, plafonnait en réalité à 31 % une fois isolé du reste.
Le chef de projet qui reçoit une extension livrée par un prestataire externe fait souvent face à ce même écart entre un chiffre global rassurant et une réalité bien plus contrastée selon les modules. Une grille de vérification structurée permet d’éviter de se fier à un pourcentage affiché sans en comprendre la composition.
Pourquoi un pourcentage global ne suffit jamais
Un taux de couverture agrégé mélange des modules à faible risque (affichage, mise en forme) et des modules critiques (paiement, données personnelles, permissions). Un module d’affichage entièrement couvert peut à lui seul tirer la moyenne globale vers le haut, sans qu’aucune ligne du module de paiement ne soit réellement testée.
La grille de vérification à exiger avant validation
- Demander un rapport de couverture détaillé par fichier ou par module, jamais seulement le chiffre agrégé final, sous un format exploitable (HTML ou Clover XML généré par PHPUnit avec l’option
--coverage-html). - Identifier les modules critiques du projet avant même de recevoir le rapport, avec le prestataire, pour fixer un seuil minimal spécifique à chacun d’eux, distinct du seuil global.
- Vérifier la nature des assertions, pas seulement leur nombre : un test qui exécute une fonction sans vérifier son résultat (
$this->assertTrue(true);en fin de test) compte dans la couverture sans apporter aucune garantie réelle. - Faire échouer volontairement une fonctionnalité critique et vérifier qu’au moins un test du module concerné échoue en conséquence, preuve tangible que la couverture affichée correspond à une détection réelle.
Un exemple de seuils différenciés retenus
| Module | Seuil minimal exigé | Justification |
|---|---|---|
| Traitement des règlements | 85 % | Impact financier direct en cas de bug |
| Gestion des adhérents | 70 % | Données personnelles, risque de conformité |
| Affichage du catalogue de séjours | 40 % | Impact limité à l’esthétique, risque faible |
Ce qui a été découvert sur ce projet
La demande d’un rapport détaillé par module a révélé que la majorité des tests portaient sur des fonctions utilitaires simples, faciles à tester et peu risquées, tandis que la logique de validation des règlements par virement différé, plus complexe à tester, avait été largement laissée de côté. Le prestataire a dû compléter la couverture de ce module spécifique avant validation finale de la recette, avec un délai supplémentaire négocié en conséquence.
Ce que cette grille ne mesure pas
Cette grille porte sur la vérification d’un niveau de couverture déclaré, pas sur la mesure technique elle-même (choix de l’outil, configuration de PCOV ou Xdebug), qui reste une décision de l’équipe de développement du prestataire, hors du périmètre de cette négociation contractuelle.
Formaliser l’exigence dans le contrat, pas seulement à l’oral
Un seuil négocié verbalement en réunion de cadrage se dilue facilement au fil du projet, surtout si le calendrier se resserre. Sur ce projet, les seuils différenciés ont été ajoutés en annexe du contrat de prestation, avec une clause précisant que la recette ne serait validée qu’après remise du rapport détaillé par module, et non sur simple déclaration du prestataire. Cette formalisation a évité toute discussion tendue au moment de la livraison, chaque partie disposant d’un critère écrit et daté pour trancher un éventuel désaccord.
La clause a également prévu le cas d’un module ajouté en cours de projet, non anticipé dans la liste initiale : dans ce cas, le seuil par défaut applicable est celui du module le plus proche par nature (paiement, données personnelles, affichage), à défaut d’un seuil spécifique négocié séparément.
Un pourcentage de couverture sans détail par module ne prouve rien de plus qu’un chiffre choisi pour rassurer.
En résumé
Exiger un rapport détaillé par module plutôt qu’un chiffre global, fixer des seuils différenciés selon le risque métier, et vérifier la pertinence réelle des assertions permet à un chef de projet de valider une recette en connaissance de cause. Sur ce projet, cette grille a permis d’identifier un écart de couverture critique avant la mise en ligne, plutôt que de le découvrir après un incident sur le module de paiement.
