# Un taux de couverture de code affiché en pull request, sans le bloquer > Informer sans bloquer évite qu'une équipe contourne systématiquement un seuil de couverture perçu comme arbitraire. Ce que change ce choix, concrètement, sur l'adhésion à la pratique. - Auteur : Clément Hadrot - Publié le : 2024-09-15 - Mis à jour le : 2024-09-15 - Catégorie : Outils & workflow - URL : https://wpmoderne.dev.wordpress-developpement.fr/outils/couverture-code-pull-request-sans-bloquer/ ## L’essentiel - Un seuil de couverture bloquant se contourne vite par des tests superficiels - Afficher le chiffre sans bloquer favorise une adoption volontaire plutôt que subie - Le commentaire automatique en pull request rend l'information visible sans effort de consultation Pourquoi un seuil de couverture de code bloquant finit-il presque toujours par être contourné plutôt que respecté ? Sur un projet où une pull request était rejetée automatiquement en dessous de soixante-dix pour cent de couverture, l'équipe a fini par écrire des tests qui exécutaient du code sans jamais vérifier son comportement, uniquement pour satisfaire le chiffre exigé par la vérification automatique. Ce contournement n'est pas un signe de mauvaise volonté : c'est une réaction rationnelle face à une contrainte perçue comme un obstacle bureaucratique plutôt que comme une aide. Un seuil bloquant transforme la couverture de code en objectif à atteindre coûte que coûte, au lieu de rester un indicateur informatif sur la qualité réelle des tests écrits. ## Le changement de posture : informer plutôt qu'imposer La modification retenue a consisté à retirer entièrement le blocage automatique de la pull request en dessous d'un seuil, tout en conservant, voire en renforçant, la visibilité du chiffre de couverture pour chaque modification proposée. L'objectif est de garder l'information disponible sans la transformer en obstacle mécanique que l'on cherche à déjouer plutôt qu'à comprendre. ## Mettre en place le commentaire automatique La configuration repose sur l'exécution des tests avec génération d'un rapport de couverture, suivie d'un commentaire automatique déposé sur la pull request résumant l'évolution du chiffre par rapport à la branche principale : ``` - name: Exécuter les tests avec couverture run: vendor/bin/phpunit --coverage-clover=coverage.xml - name: Commenter la pull request avec la couverture uses: irongut/CodeCoverageSummary@v1.3.0 with: filename: coverage.xml format: markdown output: both ``` > L'essentiel à retenir : Un seuil de couverture bloquant se contourne vite par des tests superficiels ; Afficher le chiffre sans bloquer favorise une adoption volontaire plutôt que subie ; Le commentaire automatique en pull request rend l'information visible sans effort de consultation Le commentaire apparaît directement dans la conversation de la pull request, visible sans navigation supplémentaire vers un tableau de bord externe, ce qui abaisse considérablement la friction pour en tenir compte lors de la relecture du code. ## Ce que ce changement a produit, mesuré sur six mois La couverture moyenne des nouvelles pull requests est passée de soixante et onze pour cent, chiffre stagnant sous l'ancien régime bloquant, à quatre-vingt-quatre pour cent six mois après le retrait du blocage automatique. Ce résultat, à première vue contre-intuitif, s'explique par la disparition de l'incitation à écrire des tests superficiels uniquement pour franchir un seuil : sans cette pression artificielle, les tests écrits sont redevenus des vérifications de comportement réel, ce qui a naturellement amélioré la couverture au fil du temps plutôt que de la plafonner artificiellement autour du seuil imposé. ## Le rôle de la relecture humaine dans ce dispositif Retirer le blocage automatique ne signifie pas retirer toute exigence : la personne qui relit la pull request dispose désormais du chiffre de couverture comme élément de contexte parmi d'autres, au même titre que la lisibilité du code ou la pertinence de l'approche choisie. Une baisse significative de couverture sur une modification importante reste un motif légitime de discussion en relecture, mais cette discussion porte sur le fond — pourquoi cette baisse, est-elle justifiée — plutôt que sur un chiffre binaire imposé sans nuance. - Le chiffre de couverture reste visible à chaque pull request, sans effort de consultation - Aucun blocage automatique ne rejette une modification sur ce seul critère - La relecture humaine reste responsable de juger si une variation de couverture est acceptable ## Une exception assumée pour le code sensible Ce principe général souffre une exception délibérée : le code touchant directement au paiement ou à la gestion des identifiants d'authentification conserve un seuil de couverture bloquant, documenté explicitement comme tel dans le fichier de configuration du projet, précisément parce que le risque associé à une régression non détectée y dépasse largement le bénéfice d'une plus grande liberté d'adoption. ## Ce que cette approche ne remplace pas Afficher un chiffre de couverture sans bloquer ne dit rien du choix de l'outil utilisé pour le mesurer, ni de la stratégie de test à adopter pour un projet donné — ces deux questions restent entières et méritent chacune leur propre réflexion, indépendante du mécanisme d'affichage retenu ici. ## En résumé Retirer un blocage automatique fondé sur un seuil de couverture de code, tout en conservant sa visibilité systématique en pull request, a paradoxalement amélioré la couverture réelle du projet plutôt que de la dégrader. Le mécanisme qui fonctionne n'est pas la contrainte mais l'information rendue disponible au bon moment, laissant à l'équipe la responsabilité d'en faire bon usage plutôt que de la subir comme un obstacle à contourner.