Gates de revue

Une gate est un critère explicite et binaire : le reviewer la déclare PASS ou FAIL avant que le pipeline passe à la phase suivante. Rien d’implicite, rien de « à l’œil ».

Pourquoi — le problème que ça résout

Sans critères écrits, une revue dépend de l’humeur et de la mémoire du relecteur. Les gates rendent la revue reproductible : chaque verdict s’appuie sur une liste de contrôles connue d’avance, partagée par le producteur et le reviewer. Une gate qui échoue bloque la transition (BLOCKER) ou signale un risque (HIGH/MEDIUM) — jamais un ressenti vague.

Comment lire ce catalogue

Chaque phase possède sa propre grille de gates, vérifiée par un reviewer indépendant organisé en lentilles (chaque lentille regroupe les gates qui défendent une même qualité). Pour chaque gate : son identifiant Gxx, ce qu’elle vérifie et sa condition de passage (binaire).

Les quatre phases de revue d’artefact — DISCOVER, DISCUSS, DESIGN, DISTILL — portent en plus une sévérité, qui dit comment une gate échouée retombe dans le verdict du reviewer :

Sévérité Signification Effet sur le verdict
BLOCKER Violation fondamentale qui invalide l’artefact. Force rejected — la phase ne passe pas.
HIGH Défaut significatif, source de rework en aval. Force changes_requested.
MEDIUM Design smell, choix sous-optimal. Force changes_requested.
LOW Détail de style ou de cohérence. approved avec note.

DELIVER ne porte pas cette échelle : chaque gate qualité bloque. Il n’y a pas de niveau advisory, pas de niveau warning, pas d’override, et aucune justification n’achète d’exemption — le skill skraft-quality-bar détient le niveau d’application de chaque gate et la valeur de chaque seuil, et rien en aval ne les redéfinit.

Total : 48 gates réparties sur les workflows produit et les phases d’ingénierie. Tout ce qui suit est la grille intégrale, telle que chaque reviewer l’applique.

DISCOVER — G1 à G6

Reviewer : backlog-discoverer-reviewer. 3 lentilles. Vérifie le rapport de triage et la proposition de sprint.

Lentille 1 — Complétude

ID Ce que la gate vérifie Condition de passage Sévérité
G1 Les 3 modes de découverte (assignés, pilotés par artefact, par recherche) ont été considérés — ou le rapport documente explicitement pourquoi un mode est sauté. Tous les modes pris en compte dans le rapport. HIGH
G2 Aucune issue P0 ou P1 ouverte n’existe dans le dépôt sans figurer au rapport de triage. Vérification par échantillon sur les 5 plus récentes. Zéro issue critique absente du triage. BLOCKER

Lentille 2 — Priorisation

ID Ce que la gate vérifie Condition de passage Sévérité
G3 Toute P0 a une justification écrite ; P1→P3 suit l’ordre de valeur métier décroissante ; aucune inversion de priorité. Aucune inversion, toutes les P0 justifiées. HIGH
G4 La proposition de sprint respecte la capacité déclarée (jours-équipe × 0,7) ; aucune P2/P3 ne prend une place pendant qu’une P0/P1 est exclue ; aucune issue au-delà de 8 points dans le sprint. Capacité respectée, issues au-delà de 8 points exclues. HIGH

Lentille 3 — Détection de doublons

ID Ce que la gate vérifie Condition de passage Sévérité
G5 Deux issues ne décrivent pas le même problème (similarité de titre normalisée > 80 %). Zéro paire de doublons non détectée. HIGH
G6 Les paires à similarité 40–80 % sont signalées avec une recommandation (fusionner, lier, garder séparées). Toutes les paires proches signalées. MEDIUM

DISCUSS — G1 à G8

Reviewer : backlog-planner-reviewer. 4 lentilles. Vérifie les stories, les critères d’acceptation et le plan de sprint.

Lentille 1 — INVEST

ID Ce que la gate vérifie Condition de passage Sévérité
G1 Chaque story satisfait les 6 critères INVEST (Independent, Negotiable, Valuable, Estimable, Small, Testable). Tous les critères passent pour chaque story. HIGH
G2 Toutes les stories sont livrables indépendamment ; aucune dépendance circulaire. Le graphe de dépendances est un DAG valide. HIGH

Lentille 2 — Qualité des critères d’acceptation

ID Ce que la gate vérifie Condition de passage Sévérité
G3 Chaque story a ≥ 3 critères d’acceptation au format Given/When/Then ou liste ; aucun n’est une étape d’implémentation. 3+ critères par story, bon format, sans prescription technique. HIGH
G4 Aucun critère n’a deux interprétations valides pour un expert métier sans connaissance du code (pas de code HTTP, de verbe HTTP, de nom de classe). Chaque critère résout à un résultat unique. BLOCKER

Lentille 3 — Cohérence de planification

ID Ce que la gate vérifie Condition de passage Sévérité
G5 Les stories cadrent avec le thème du milestone ; aucune ne chevauche plusieurs thèmes sans décomposition. Chaque story aligne avec le thème et la fenêtre du milestone. HIGH
G6 Pas de dépendance circulaire ; la séquence de livraison respecte l’ordre topologique. Le graphe est un DAG, le séquencement est dérivable. BLOCKER

Lentille 4 — Conformité au Definition of Ready

ID Ce que la gate vérifie Condition de passage Sévérité
G7 Chaque story passe les 8 items du DoR : énoncé du problème, persona précis, ≥ 3 exemples métier, scénarios UAT, critères dérivés des UAT, bon calibrage, notes techniques, dépendances. 8/8 items pour chaque story. BLOCKER
G8 Zéro anti-pattern CRITIQUE (Implement-X, Giant Stories, No Examples) ni HAUT (critère technique, données génériques, tests après le code, persona vague, dépendances manquantes). Aucun anti-pattern critique détecté. BLOCKER / HIGH

DESIGN — G1 à G15

Reviewer : solution-architect-reviewer. 3 lentilles + 1 gate transverse d’escalade. Vérifie les ADR, le registre de supersession, les diagrammes, les contrats, les matrices de cohérence.

Lentille 1 — Cohérence

ID Ce que la gate vérifie Condition de passage Sévérité
G1 Tout engagement structurel — visible dans un diagramme ou détecté dans le code (bus de commande/requête, event store, saga, ACL inter-contexte) — est justifié par un ADR Accepted traçable. Chaque élément structurel référence ≥ 1 ADR accepté. BLOCKER
G2 Deux ADR ne se contredisent pas ; toute supersession est enregistrée dans le corps du nouvel ADR ET dans le registre append-only supersessions.md. Zéro décision contradictoire, liens de supersession complets. BLOCKER
G10 Une matrice de cohérence existe par story et sa ligne consistency-gate est PASS ; le journal de back-propagation explique chaque réécriture. Une matrice par story, toutes PASS. BLOCKER
G12 Chaque ligne d’un plan de supersession est réalisée (corps de l’ADR, ligne de registre, plus aucune référence à l’ADR remplacé comme source de vérité). Les trois conditions tiennent pour chaque supersession. BLOCKER
G14 Aucun ADR n’encode le verdict dans le nom de fichier ; le verdict vit dans le frontmatter Status:. Un Status: Rejected n’est admissible que s’il trace à une story et nomme l’alternative adoptée. Zéro nom de fichier porteur de verdict, chaque rejet tracé. BLOCKER

Lentille 2 — Conformité architecturale

ID Ce que la gate vérifie Condition de passage Sévérité
G3 Règle de dépendance : les couches Domain et Application ne dépendent ni d’Infrastructure ni d’API. Zéro import d’Infrastructure/API dans Domain ou Application. BLOCKER
G4 Toutes les interfaces applicatives (repositories, gateways, publishers) sont définies dans la couche Application, jamais dans Infrastructure. Zéro interface définie par l’Infrastructure. BLOCKER
G5 Chaque agrégat fait respecter ses propres invariants, pas ceux d’un autre agrégat. Zéro invariant inter-agrégat. HIGH
G6 Le context map déclare chaque relation inter-contexte avec un pattern explicite (ACL, Conformist, Shared Kernel, Partnership, OHS, Published Language) et chaque étiquette est admissible. Zéro flèche non étiquetée, zéro étiquette inadmissible. HIGH

Lentille 3 — Adéquation (fitness)

ID Ce que la gate vérifie Condition de passage Sévérité
G7 Chaque story de DISCUSS mappe à ≥ 1 déclencheur (Command ou Query) du modèle d’événements. Tous les IDs de story apparaissent dans une tranche. HIGH
G8 Chaque Command a au moins un événement de domaine correspondant ; les Queries en sont exemptées. Zéro commande sans événement. HIGH
G9 Aucun agrégat, contexte, adoption d’Event Sourcing ou Saga n’est introduit sans justification par une story. Zéro élément architectural injustifié. MEDIUM
G11 Tout ADR adoptant un pattern complexifiant (CQRS, Event Sourcing, Saga, cohérence éventuelle, split micro-service, ACL) cite une force admissible ET évalue l’option « faire sans ». Force admissible + alternative « faire sans » pour chaque ADR complexifiant. HIGH
G15 Aucun ADR ne ratifie une contrainte qui est le socle imposé du projet (CQS au niveau méthode, frontières Clean Architecture, DI par convention, repository). Les déviations et ajouts restent valides. Zéro ADR Accepted qui répète un socle imposé. HIGH

Transverse — Escalade

ID Ce que la gate vérifie Condition de passage Sévérité
G13 Chaque blocker decision-drift-* a un fichier -resolution.md frère contenant la réponse humaine. Un blocker ouvert signifie qu’un humain doit trancher. Un fichier de résolution pour chaque blocker. BLOCKER (court-circuit)

Si G13 échoue, le reviewer renvoie REJECTED immédiatement sans évaluer les autres gates : la prochaine action est l’escalade humaine, pas un nouvel essai.

DISTILL — G1 à G8

Reviewer : acceptance-designer-reviewer. 4 lentilles. Vérifie les scénarios Gherkin, le plan de test et le plan d’implémentation.

Lentille 1 — Couverture

ID Ce que la gate vérifie Condition de passage Sévérité
G1 Bijection critère↔scénario : chaque critère d’acceptation mappe à ≥ 1 scénario, aucun scénario n’est orphelin. Tous les critères couverts, aucun scénario orphelin. BLOCKER
G2 Les conditions limites et cas négatifs des exemples métier sont représentés en scénarios. ≥ 1 cas limite par règle métier. HIGH

Lentille 2 — Alignement métier

ID Ce que la gate vérifie Condition de passage Sévérité
G3 Tout le vocabulaire des étapes Given/When/Then appartient au lexique métier — aucun nom de classe, de méthode, de verbe HTTP ou de framework. Zéro identifiant technique dans les .feature. HIGH
G4 Les étapes ne contiennent aucun détail d’implémentation (code HTTP, terme ORM, langage SQL, conteneur DI). Zéro fuite d’implémentation. BLOCKER

Lentille 3 — Testabilité

ID Ce que la gate vérifie Condition de passage Sévérité
G5 Chaque étape est implémentable sans demander de clarification : un seul sens dans le vocabulaire métier. Chaque étape mappe à une action/un état unique. HIGH
G6 Chaque scénario des .feature a une entrée correspondante dans le plan d’implémentation (chemin de fichier + frontière de cas d’usage). Bijection scénarios ↔ entrées du plan. HIGH

Lentille 4 — Respect des frontières

ID Ce que la gate vérifie Condition de passage Sévérité
G7 Chaque ligne de la matrice de couverture vise un cas d’usage de la couche Application nommé dans les contrats — jamais un adaptateur d’Infrastructure comme point d’entrée. Chaque entrée référence une frontière de cas d’usage. BLOCKER
G8 Au moins un scénario walking skeleton par flux majeur est identifié (tag @smoke ou marqué dans la matrice). ≥ 1 walking skeleton par flux. HIGH

DELIVER — G1 à G11

Producteur : software-engineer ; vérificateur : quality-gates-lens. Chaque gate est attestée par une évidence falsifiable (SHA git, sortie d’outil déposée sur disque) que le reviewer re-résout sans jamais rejouer le build.

Toutes les gates ci-dessous bloquent, sur chaque dépôt et chaque work item. Le framework portait autrefois un cadran de rigueur global au dépôt qui pouvait abaisser cette grille — moins de lentilles de revue, un seuil de mutation plus bas, la gate Gherkin désactivée. Ce cadran a disparu, et il servait aussi de gouverneur de coût : chaque run paie désormais la forme complète. Le propriétaire du dépôt a accepté ce compromis délibérément — la qualité ne se négocie pas.

ID Ce que la gate atteste Condition de passage
G1 Les tests d’acceptation passent. Le scénario BDD de la story active est vert.
G2 Tous les tests unitaires passent. La suite unitaire complète est verte.
G3 Le build passe. Compilation / vérification de types réussie.
G4 L’analyse statique passe. Linter/analyseur sans problème bloquant.
G5 Les règles d’architecture passent. Les tests de direction de dépendance (Clean Architecture) passent.
G6 Le score de mutation atteint la barre. Les deux scripts de mutation séquencés sortent en 0 : le cœur d’abord (Domain et Application, 100 %), puis la frontière (API et Infrastructure, 80 %).
G7 Aucun mock dans le cœur Domain/Application. Attestation par grep : zéro symbole de framework de mock dans ces couches.
G8 Message complet du commit conventionnel. Chaque commit couvert utilise le scope fonctionnel, le sign-off et l’issue connue ; la cloture exige un travail reellement termine et toutes les gates requises passees.
G9 Aucune altération de test (intégrité RED→GREEN). Pour chaque cycle, le fichier de test n’a changé que par ajout entre les snapshots RED et GREEN.
G10 RED constaté : le test a bien été exécuté et a échoué avant l’arrivée de l’implémentation. Pour chaque cycle, un stdout RED capturé au moment du RED et haché en sha256, plus un code de sortie non nul enregistré.
G11 La couverture de lignes atteint la barre. Le runner de couverture, invoqué avec les drapeaux de seuil de la barre (100 % de lignes sur Domain et Application), sort en 0.

Politique G8 : consignes de commit directement dans les agents existants, sur les deux clients natifs (Copilot et Claude Code). Aucun skill, validateur ou recu de completion supplementaire.

G6 est un code de sortie, pas un nombre. Chaque adaptateur quality-gates-<tech> embarque deux scripts de mutation séquencés — mutation-core.sh puis mutation-boundary.sh en .NET. Chaque script porte sa propre valeur attendue et la passe au --break-at du runner : le runner sort non nul sous la barre, et ce code de sortie est le verdict. Le cœur passe en premier et court-circuite : il n’y a rien à apprendre en mutant les adaptateurs tant que le domaine n’est pas prouvé. Un score lu dans un rapport et jugé en prose est une opinion sur une gate, pas une gate — et G11 s’atteste de la même façon, par les drapeaux de seuil du runner de couverture.

Une gate réellement non pertinente est marquée not_applicable avec justification — jamais en remplacement d’un fail ou d’une évidence manquante. Une gate qui ne peut pas s’exécuter — runner de mutation absent, SDK absent — est fail, jamais not_applicable.

Logique de verdict

Sur les quatre phases de revue d’artefact, le reviewer agrège les gates selon une règle déterministe — pas de pondération floue :

Constat Verdict
≥ 1 gate BLOCKER échouée (ou G13 ouverte en DESIGN) rejected
≥ 1 gate HIGH, aucune BLOCKER changes_requested
Gates MEDIUM seules changes_requested
Gates LOW seules, ou tout passe approved

Sur DELIVER, la règle est plate, puisque chaque gate bloque :

Constat Verdict
≥ 1 gate en fail — quel que soit son id fail
Log absent ou malformé, fichier référencé introuvable, sha256 ou snapshot qui ne correspond pas inconclusive
Chaque gate applicable en pass et chaque référence résolue pass

inconclusive n’équivaut jamais à pass : l’absence d’évidence n’est pas une évidence de succès.

Pourquoi cette pratique

« A software inspection is a rigorous review with explicit entry and exit criteria. » — Wiegers, K., Peer Reviews in Software, 2002.

Des critères d’entrée/sortie explicites, c’est exactement ce qu’une gate matérialise : la phase n’est « finie » que lorsque ses gates sont franchies.

Pièges & anti-patterns

Pour aller plus loin

Sources

Termes à connaître : gate, reviewer, BLOCKER, INVEST, walking skeleton — voir le glossaire.