« Votre couverture de tests est de combien ? » : cette question, posée par un client avant la recette finale d’une extension de gestion de dons pour une fondation, appelle une réponse plus nuancée qu’un simple pourcentage énoncé sans contexte. Un chiffre brut, sorti de tout contexte, ne dit rien de la solidité réelle du travail effectué, et peut même se retourner contre l’agence si le client découvre ensuite qu’une zone critique reste peu couverte malgré un pourcentage global flatteur.
La check-list qui suit organise la préparation d’un rapport de couverture destiné à un client, construite après plusieurs présentations où un pourcentage isolé avait suscité plus de questions gênantes que de confiance rassurée.
1. Distinguer la couverture globale de la couverture par zone critique
Un pourcentage global de 78 % peut recouvrir une réalité très inégale : 95 % sur les fonctions d’affichage, 40 % sur le module de traitement des paiements. Le rapport présenté sépare systématiquement ces deux niveaux, avec un tableau dédié aux modules jugés critiques pour le client.
| Module | Couverture | Criticité |
|---|---|---|
| Traitement des dons et reçus fiscaux | 91 % | Critique |
| Affichage du formulaire public | 68 % | Modérée |
| Export comptable mensuel | 85 % | Critique |
| Personnalisation graphique du thème | 22 % | Faible |
2. Générer le rapport avec un outil reproductible
Le rapport ne repose jamais sur une capture d’écran isolée, mais sur une commande reproductible, versionnée dans le projet et documentée pour l’équipe :
vendor/bin/phpunit --coverage-html rapports/couverture --coverage-text
Le rapport HTML généré reste consultable en détail par le client s’il le souhaite, tandis que la sortie texte alimente directement le résumé présenté en réunion.
3. Documenter ce que le pourcentage ne couvre pas
Un paragraphe dédié précise explicitement les limites : la couverture mesure les lignes exécutées, pas la pertinence des assertions ; certains scénarios de bout en bout, testés manuellement lors de la recette, ne figurent pas dans ce pourcentage automatisé.
4. Expliquer les zones volontairement moins couvertes
La personnalisation graphique du thème, à 22 % de couverture, n’est pas un oubli mais un choix assumé : son risque fonctionnel reste faible, contrairement au traitement des dons. Le rapport justifie explicitement ce choix, plutôt que de laisser un chiffre bas sans explication.
5. Dater le rapport et le relier à une version précise du code
Chaque rapport présenté mentionne la référence de commit exacte sur laquelle il a été généré, évitant toute ambiguïté si le client compare un rapport ancien à un comportement observé sur une version plus récente du site.
6. Prévoir une trajectoire, pas seulement un instantané
- Comparer le pourcentage actuel à celui du rapport précédent, pour montrer une tendance plutôt qu’un chiffre isolé.
- Indiquer les modules dont la couverture doit progresser lors du prochain sprint, avec un objectif chiffré réaliste.
- Consigner cette trajectoire dans le document de suivi de projet partagé avec le client, pas uniquement en réunion orale.
7. Relire le rapport du point de vue du client, pas du développeur
Un vocabulaire technique comme « branches non couvertes » ou « mutants survivants » perd le client non technique. Le rapport final reformule ces notions en langage accessible, sans pour autant appauvrir l’information transmise.
Un pourcentage sans contexte inquiète ou rassure au hasard ; un rapport structuré informe une décision.
Ce que ce document apporte, au-delà de la présentation elle-même
Au-delà de la seule réunion de recette, ce document daté et relié à un commit précis sert également de référence en cas de litige ultérieur sur la qualité livrée. Si un bug apparaît plusieurs mois après la mise en production, l’agence peut démontrer objectivement quel niveau de couverture existait au moment de la livraison, et pourquoi la zone concernée avait été identifiée comme moins critique à l’époque. Cette traçabilité protège autant l’agence que le client, en évitant les reproches fondés sur une mémoire approximative plutôt que sur un document daté.
La même structure, une fois éprouvée sur un premier projet, se réutilise ensuite d’un client à l’autre sans réinvention à chaque recette, ce qui réduit également le temps de préparation consacré à cette présentation.
En résumé
Documenter la couverture d’une suite de tests avant de la présenter à un client dépasse largement la production d’un pourcentage unique. Les sept points retenus ici, de la distinction par zone critique à la trajectoire de progression, transforment un chiffre potentiellement anxiogène en un outil de dialogue objectif sur l’effort de test réellement fourni, tout en constituant une trace utile en cas de question posée bien après la livraison.
