Révision d'une pull request par rapport au ticket
La dernière étape avant qu'une pull request soit prête. Elle répond à une question — cette diff livre-t-elle le ticket, dans le respect de l'architecture ? — et elle y répond en s'appuyant sur deux sources qui priment sur le goût du relecteur : les critères d'acceptation, et l'architecture de référence.
Cette révision lit et rapporte. Elle ne modifie pas : une révision qui corrige ce qu'elle trouve détruit la preuve de ce qui n'allait pas, et personne n'apprend le schéma.
Dernière des trois phases, après TICKET-ANALYSIS.md et
IMPLEMENTATION-PHASE.md. WORKFLOW.md explique comment
ils s'assemblent et comment les installer.
Sommaire
- Établir ce qui est réellement révisé
- Les critères d'acceptation d'abord
- La passe architecturale
- La passe des tests
- Sévérité et verdict
- Modes de défaillance
- Liste de contrôle
1. Établir la diff
Faites un diff de la branche par rapport à la branche de base réelle du dépôt, et non par rapport à une supposition sur laquelle elle est. Révisez chaque fichier modifié ; un fichier ignoré parce qu'il a l'air banal est l'endroit où se cache la modification de configuration.
Notez ce que la diff touche et que le ticket n'a pas mentionné. Cette liste est une entrée pour les §2 et §5, pas encore une constatation.
2. Les critères d'acceptation d'abord
Prenez les critères d'acceptation un par un et, pour chacun, nommez le code qui le satisfait et le test qui le prouve. Les deux, ou il n'est pas satisfait.
- Un critère avec du code et sans test n'est pas prouvé.
- Un critère avec un test et sans code est un test qui vérifie le framework.
- Un critère que vous ne pouvez pas du tout localiser est la constatation la plus importante, et elle prime sur toute observation de style dans la révision.
Ensuite, dans l'autre sens : les modifications sans critère derrière elles. Certaines sont légitimes — une correction à l'intérieur du code déjà modifié (IMPLEMENTATION-PHASE.md §2). Le reste est un élargissement du périmètre, et il est moins coûteux de le nommer ici que de l'expliquer après la mise en production.
3. La passe architecturale
Parcourez la liste de contrôle de conformité pour les couches que la diff touche. Les constatations qui valent le plus sont celles qu'un build réussi ne peut pas montrer :
- P2 — tout élément de type domaine ajouté au noyau partagé : une entité, DTO, enum, jeu de données de base, constante de tarification, chaîne destinée à l'utilisateur.
- P3 — une lecture ou écriture inter-contextes ; un second service accédant à la base de données du service propriétaire.
- P4 — schéma modifié sans migration, ou une migration non portable entre fournisseurs.
- P5 — un secret, une clé ou une chaîne de connexion dans le code source, la configuration ou un commentaire ; une configuration lue ailleurs que dans l'environnement.
- P8 — une nouvelle dépendance qui échoue au démarrage plutôt que de dégrader, ou absente du point de terminaison de santé et de la bannière de démarrage.
- P9 / P10 — câblage intégré dans
Program.cs; un point d'extension ajouté comme classe de base plutôt qu'une interface enregistrée dans DI. - P11 — une forme externe atteignant le domaine non traduite.
- P15 — un nouveau chemin sans traces, métriques ni logs.
SERVICE-API-PATTERNS.md— un endpoint en dehors des groupes de confiance, une liste non bridée, un corps d'erreur non uniforme, un appel sortant sans délai d'attente explicite, une écriture indéterminée relancée.- Sécurité — tout élément nouvellement exposé publiquement reçoit la passe
SECURITY-REVIEW.mdavant d'être livré, pas après.
Un écart que la pull request enregistre comme une décision avec une raison n'est pas une constatation. Le même écart, silencieux, en est une — cette distinction est P14 qui fait son travail.
4. La passe des tests
Lisez les corps des tests. Le nombre de tests, le nombre de fichiers et la structure des dossiers ne prouvent rien ; un audit du 14 août 2026 d'une suite de 447 tests a révélé qu'environ 45 % d'entre eux étaient des espaces réservés ou protégés pour ne jamais rien vérifier, et rien de cela n'était visible de l'extérieur (P13).
- Chaque nouveau test se trouve-t-il au niveau de la couche qui contient la logique, ou un navigateur sert-il de substitut à un validateur ?
- Vérifie-t-il un résultat, ou qu'un bouton a été cliqué ?
- Existe-t-il un test de régression pour chaque chemin existant que la diff touche, ou seulement des tests pour la nouvelle branche ?
- Atteint-il la barre par test — indépendant,
data-testid, pas de temps d'attente, pas d'identifiants de production (TESTING-STRATEGY.md§6) ? - Un nouveau point d'entrée de test est-il exécuté par un contexte CI (§9) ?
5. Sévérité et verdict
Classez chaque constatation, et classez-la par conséquence plutôt que par facilité de description :
| Niveau | Ce que cela signifie |
|---|---|
| Bloquant | Un critère d'acceptation n'est pas satisfait ou prouvé ; un principe est violé sans décision enregistrée ; un secret est exposé ; un test a été affaibli ou supprimé pour obtenir le feu vert |
| À corriger | Correct mais hors schéma : mauvais niveau de test, couverture de régression manquante, hypothèse non enregistrée, documentation rendue inexacte par la modification |
| À considérer | Vraiment facultatif. Gardez cette section courte — une section longue enterre les deux premières |
Concluez avec le verdict dont la porte du diagramme a besoin, énoncé clairement : cette pull request livre-t-elle le ticket, et est-elle conforme à l'architecture ? Une des trois réponses — validée ; validée avec les constatations non bloquantes listées ; ou non validée, avec les constatations bloquantes nommées. « Ça a l'air bien, quelques commentaires » n'est pas un verdict.
6. Modes de défaillance
| Symptôme | Cause |
|---|---|
| La révision approuve une diff qui manque une exigence | La passe a commencé par le code au lieu des critères d'acceptation |
| La révision est une liste d'opinions de style | Les passes architecturales et de tests ont été ignorées parce que le build était vert — ce qu'elles vérifient précisément |
| Une suite verte est considérée comme une preuve | Les corps des tests n'ont jamais été lus ; le nombre et la structure ont été pris pour argent comptant |
| Les constatations sont toutes rapportées avec le même poids | Aucun classement de sévérité, donc la constatation bloquante se retrouve sous un détail de nommage |
| La même violation se répète entre les pull requests | Les constatations ont été corrigées par le relecteur plutôt que signalées, donc le schéma n'a jamais été appris |
| Un écart est signalé alors que l'auteur l'avait déjà justifié | Les décisions enregistrées de la pull request n'ont pas été lues avant la révision |
7. Liste de contrôle
- Diff effectué par rapport à la branche de base réelle du dépôt ; chaque fichier modifié lu
- Chaque critère d'acceptation associé au code qui le satisfait et au test qui le prouve
- Modifications sans critère derrière elles identifiées et classifiées
- Liste de contrôle de conformité parcourue pour chaque couche que la diff touche
- Décisions enregistrées lues d'abord, afin que les écarts justifiés ne soient pas signalés comme des constatations
- Tout élément nouvellement public a reçu la passe de révision de sécurité
- Corps des tests lus, non comptés ; couche, assertions de résultat, couverture de régression et barre par test vérifiés
- Constations classées bloquantes / à corriger / à considérer
- Un verdict explicite donné par rapport au ticket
- Rien modifié pendant la révision
Généré à partir de docs/delivery/PR-REVIEW.md par scripts/build-marketplace.mjs. Ne modifiez pas ce fichier : changez le document source, ou son entrée dans catalog/marketplace.catalog.json, et relancez le générateur.