# Traitement des bugs — règle de circuit

Validée par Enguerran le 19/08/2026, pendant la recette de la refonte.
Pendant que la règle des lots dit COMMENT on développe (1 issue = 1 branche =
1 PR, lots/sprints), celle-ci dit QUAND un défaut entre dans le circuit.

## Principe

**La criticité choisit le circuit, pas la nature du travail.** Un bug n'a pas de
file spéciale parce que c'est un bug : sous le seuil du blocage, il rejoint le
cycle normal et se priorise avec les évolutions. **Seul le vital a un
passe-droit.**

## Les quatre circuits

### 1. Vital → court-circuite le sprint
Effondrement d'une fonction essentielle, perte ou fuite de données, preuve
réglementaire compromise. Notification immédiate au pilote produit, **arrêt du
parcours de recette** si la suite en dépend, correctif traité en priorité,
**train dédié sans attendre le lot**. C'est le SEUL cas qui déroge au cycle.

### 2. Majeur BLOQUANT une phase en cours → au fil de l'eau
Un majeur qui empêche une recette d'avancer, ou qui bloque une mise en
production engagée, se corrige **pendant la phase**, sur mandat explicite du
pilote produit (c'est le mandat donné pour la recette du 19/08). Hors phase
active : tête du prochain lot.

### 3. Majeur non bloquant, mineur, confort → cycle standard
Backlog, embarqués dans les lots/sprints **comme les évolutions**, triés par
criticité à la constitution du lot. Pas de circuit dérogatoire.

### 4. KO attendu → pas un circuit, une issue déjà tracée
Un écart déjà connu et documenté (fonction non livrée, décision produit
assumée) n'ouvre PAS d'issue nouvelle : le constat de recette est **commenté
sur l'issue existante**, avec la date et le testeur. Il confirme l'actualité de
l'issue, il ne la duplique pas.

## Règles transverses (s'appliquent aux quatre circuits)

- **Un bug corrigé = un test qui l'empêche de revenir.** Sans exception.
- **Inscription au registre « corrigé-vérifié ».** Si le défaut réapparaît,
  c'est une **RÉGRESSION** : criticité montée d'un cran, et l'absence du test
  de non-régression devient elle-même un constat.
- **Preuve avant fermeture — la règle des deux volets** (validée par Enguerran
  le 25/08). Une issue se ferme sur **deux preuves complémentaires** :
  la **re-passe humaine du testeur** pour tout ce qui est **visible à l'écran**,
  et la **mesure serveur datée du pilote** pour tout ce qui lui est
  **invisible** (règle serveur, état en base, garde de sécurité) — **les deux
  tracées dans l'issue** par un commentaire daté citant le signalement du
  testeur (référence Sentry + release) et la mesure du pilote. Une issue dont
  TOUT le contenu est invisible au testeur se ferme sur la seule mesure pilote,
  explicitement qualifiée comme telle. Jamais sur un « Closes #N », jamais sur
  la parole d'un fil. Premier cas d'application : BACK#412 (refus sans points),
  fermée le 25/08 — volet visible rejoué par le testeur, volet points mesuré
  0 → 0 par le pilote.
- **Un correctif qui change un parcours de recette met le cahier à jour DANS
  le train** — sinon les testeurs jouent des étapes périmées.
- **Le journal des correctifs de la feuille de suivi** est alimenté à chaque
  train, en distinguant « À REJOUER » de « déployé » : c'est ce qui dit aux
  testeurs quoi refaire et quand rafraîchir leur navigateur.

## Ce que la règle ne dit pas

Elle ne fixe pas la criticité — celle-ci se propose au gabarit d'issue et
s'arbitre. Elle ne dispense pas du cadrage : un correctif qui change les règles
du produit reste un **chantier socle**, donc soumis à arbitrage avant d'être
lancé, quelle que soit sa criticité.