Aller au contenu

Cadrage produit — cycle opératoire Bricks

Définition

Un cadrage est le travail qui transforme une demande floue en pari borné : problème, preuve, hypothèse, outcome, hors-scope, DRI, boucle, appétit, définition de fin.

Ce n'est pas une réunion. Ce n'est pas un tas de tickets Linear. Ce n'est pas une maquette.

La réunion valide un cadrage déjà mâché. Les tickets tracent l'alignement. La maquette cadre la solution UI après l'hypothèse.

Références

Question Canon
Comment on choisit quoi travailler ? Priorisation produit
Quoi construire et pourquoi ? Lean PM
Comment on parle et on tranche en groupe ? Réflexes réunion & cadrage
Comment on cadre l'UI ? Product Design
Comment on range le travail ? Conventions Linear
Comment on own jusqu'à la prod ? Ownership engineering
Comment on rédige un ticket ? Specs pour agent
Comment on recrute ou évalue un PM ? Référentiel d'évaluation local

Deux chemins (ne pas tout cadrer pareil)

Chemin Quand Ce qu'on fait
Court Cause, solution et impact déjà compris. Correctif local. Rayon petit. Ticket + owner. Pas d'atelier.
Complet Nouvelle feature, nouveau flux, plusieurs couches, UI nouvelle, argent / legal, ou sujet qu'on ne sait pas encore formuler. Cycle ci-dessous.

Règle reprise de ADR-035 analyse (généralisable) : une évolution structurante se cadre avec le produit et la tech avant l'écriture finale des tickets. Pas après, pas « on verra en implémentant ».

Cycle

flowchart LR
    q["1. Qualifier"]
    s["2. Solo"]
    c["3. Croisé"]
    g["4. Geler"]
    b["5. Build"]
    m["6. Mesurer"]
    q --> s --> c --> g --> b --> m
    m -.->|outcome non atteint| s

1. Qualifier (15–30 min)

Décider le chemin. Poser :

  • Qui souffre, de quoi, aujourd'hui ?
  • Est-ce un sujet structurant (project Linear, pas une issue fourre-tout) ?
  • Chemin court ou complet ?
  • Qui est le DRI — une seule personne, pas un comité (TEMPLATE project) ?

Sortie : chemin + DRI, ou « on ne le fait pas ».

2. Solo (le DRI produit)

Discovery avant la synchro. La synchro n'est pas le lieu pour découvrir (lean § Discovery en solo).

Le DRI produit sa première lecture avant de demander à l'IA de raisonner. L'IA prépare la matière si besoin, puis challenge un jugement déjà formulé (garde-fou IA).

Le DRI sort un artefact lisible à froid (page wiki project, ou 1 page markdown) avec :

  1. Problème — qui, de quoi, aujourd'hui.
  2. Preuve — donnée, ticket support, observation. Sinon [non sourcé].
  3. Hors-scope — ce qu'on ne fait pas. Obligatoire.
  4. Hypothèse — Si… alors… parce que…
  5. Outcome — métrique + baseline + target + date. Ou [outcome non formulé].
  6. Plus petit test — pour apprendre, pas le scope complet.
  7. Kill criteria.
  8. Déjà tranché vs ouvert — voir État du cadrage.
  9. 1–2 questions de close — ce que la synchro doit trancher. Pas un re-brief.

Si le sujet touche l'UI : pas de high-fi ici. Au plus un zoning. La lentille design s'enclenche après l'hypothèse.

3. Croisé (atelier court, pas un comité)

Réunir seulement les gens qui ont une décision à prendre (table Qui dans la boucle).

Le DRI arrive avec le solo déjà écrit. On ne redécouvre pas à l'oral.

On confronte :

  • le flux réel (souvent un schéma simple) ;
  • les options produit et techniques — le produit éclaire, la tech possède le comment ;
  • l'appétit : temps qu'on accepte d'investir avant de réévaluer ;
  • la définition de fin observable.

On clôt par la question 10 des réflexes : décision = X ; next steps = Y (owner, échéance).

4. Geler

Le cadrage est gelé quand la définition de fin du cadrage est cochée.

Alors seulement : écrire ou ajuster les tickets. Les tickets sont la trace de l'alignement, pas le point de départ de la réflexion (ADR-035).

Issue de cadrage (owner produit) ≠ issue d'implémentation (portée par le dev). Le produit ne pré-écrit pas le comment technique.

5. Build

Le DRI reste redevable du problème. La tech owns l'implémentation. Le design owns le pack UI si impact UI (handoff).

Done Linear = en prod, pas « PR mergée » ni « maquette faite » (conventions Linear).

6. Mesurer

Relire l'outcome. Outcome non atteint → retour au solo (pivot / stop / scale), pas « on ajoute une feature ».

Qui dans la boucle

Principe : le moins de monde possible pour trancher, le bon monde pour informer. Inviter tout le monde à chaque cadrage, c'est de la discovery collective — anti-pattern.

Rôles (ce que chacun possède)

Rôle Possède Ne possède pas
DRI produit (PM / PB) Problème, outcome, hors-scope, communication, close Le comment technique. Le mécanisme cash / legal s'il n'est pas son métier.
Tech Faisabilité, archi, comment, edge cases techniques, implémentation Le problème user. La priorisation business.
Design (si UI) Parcours, états, fidélité, QA design Le mécanisme métier (règles d'argent, paiement, legal). Consulté tôt, pas owner du mécanisme.
Métier / user interne Preuve du problème, contraintes d'usage La solution. Pas un droit de veto sur chaque ticket.
Leadership (B&B, Cédric, Yoann…) Appétit et policy lorsqu'ils dépassent la squad La discovery. Le détail d'un flux.

Un project a un DRI. Les owners d'issues sont autre chose. Sans DRI, chaque brique avance et les trous entre les briques n'appartiennent à personne.

Qui est dans la pièce, à quel moment

Étape Obligatoire Si UI Si structurant / archi / data Informé (pas dans la pièce)
Qualifier DRI — 15 min tech si le chemin n'est pas évident —
Solo DRI PD prévenu (pas un atelier) Avis tech court si besoin —
Croisé DRI + un référent tech PD owner du sujet Le métier qui souffre, une personne Le reste de la squad au weekly
Geler / tickets DRI PD si pack handoff Le dev qui implémente Timeline Linear
Build DRI suit le problème QA design avant ship Dev owns le comment Weekly
Mesurer DRI PD si outcome UX Tech si métrique technique Squad

Pas dans un cadrage par défaut : toute la squad, le leadership, les deux PD, le métier « au cas où ». On les ajoute pour une décision qu'eux seuls peuvent prendre.

Produit ↔ tech — règle dure

Le produit apporte la compréhension (fonctionnel, parcours, contraintes, pourquoi). La tech choisit le comment (archi, découpage, solution).

Conséquence : on ne fait pas trancher une option technique A vs B dans un cadrage produit. On soumet les options connues. La tech tranche.

Sur un sujet à impact UI : avis tech avant le high-fi (design principe 5), pas au handoff.

État du cadrage

Chaque sujet structurant porte cet état à l'écrit (page wiki project). C'est ce qui rend une reprise possible.

Statut Signifie Prochaine action
intake Demande reçue, chemin pas choisi Qualifier
solo DRI en train d'écrire Finir le 1-pager
croisé Solo prêt, atelier à caler ou en cours Trancher les questions de close
gelé Cadrage terminé, tickets OK Build
build En implémentation DRI suit le problème
mesure En prod, on lit l'outcome Stop / pivot / scale
pause Trio pas aligné, ou appétit consommé Requalifier ou tuer

Dans l'artefact, séparer visuellement :

  • Déjà tranché — on ne rouvre pas sans « qu'est-ce qui a changé ? » (réflexe 8).
  • Hypothèse — pari encore ouvert, nommé comme tel.
  • Ouvert — question de close, owner, date.

Exemple réel de cette séparation : Expiration invest auto H-1 (invariant d'expiration avant ouverture tranché ; paramètres opérationnels suivis dans Linear).

Reprendre un cadrage

Un PM / PB qui prend le relai ne doit pas dépendre du contexte implicite de la personne précédente. Il lit, il classe, il close.

Checklist de reprise (1–2 h)

  1. Page wiki du project — le pourquoi. Si elle n'existe pas : la créer avant de relancer des synchros.
  2. Project Linear — DRI, issues, ce qui est Done vs open. Done = prod.
  3. sources.md + 1–2 derniers meetings / threads — le delta, pas tout l'historique.
  4. Remplir l'état — tranché / hypothèse / ouvert. Ce que tu ne trouves pas = [à vérifier], pas une invention.
  5. Ne pas rouvrir ce qui est tranché, sauf preuve que le contexte a changé.
  6. Écrire la fiche de reprise (ci-dessous). La synchro suivante valide cette fiche. Elle ne rediscute pas le sujet depuis zéro.

Fiche de reprise (copier-coller)

# Reprise — <nom du sujet> — YYYY-MM-DD — DRI : <qui>

## En deux mots
<problème + état actuel, 3 phrases max>

## Déjà tranché
- …

## Encore une hypothèse
- …

## Ouvert (questions de close)
1. <question> — à trancher avec <qui> — avant <date>
2. …

## Hors-scope (rappel)
- …

## Boucle
- Aligner : …
- Valide : …
- Informer : …

## Next
- <action> — owner — date

Si le solo d'origine n'existe pas : tu le produis. Tu ne compenseras pas un texte absent par un discours en réunion.

Cadrage terminé = prêt à builder (ou à passer)

Un cadrage est terminé quand tout ceci est vrai, ou explicitement marqué :

  • [ ] Les 5 questions lean ont une réponse ou un marqueur.
  • [ ] Le hors-scope est écrit.
  • [ ] Le DRI est nommé.
  • [ ] La boucle est nommée (aligner / valide / informer).
  • [ ] L'appétit et la définition de fin sont posés.
  • [ ] Si UI : parcours + états, ou marqueurs [parcours non spécifié] / [états non listés].
  • [ ] Si structurant : la tech a vu le flux avant les tickets finaux.
  • [ ] Tranché / hypothèse / ouvert sont séparés à l'écrit.
  • [ ] Les tickets (s'il y en a) tracent cet alignement.

Un cadrage « dans la tête du DRI » n'est pas transférable.

Artefacts — qui vit où

Artefact Porte Ne porte pas
Page wiki project Pourquoi, pari, état du cadrage, DRI Le board vivant
Project Linear Exécution, issues, dates, lead Le re-contexte exhaustif
Issues 1 livrable cohérent chacune Un sujet structurant entier
ADR Choix durable (stack, policy, règle) Un arbitrage de sprint
Prep markdown Un rituel (weekly, 1-1, B&B) Le cadrage du project
Figma Solution UI, états Le problème

Wiki = cerveau. Linear = mains. On ne duplique pas.

État actuel

Dernière mise à jour : 2026-09-16

  • V1 — cycle opératoire et checklist de reprise.
  • À roder sur le premier sujet repris par un PM recruté, puis ajuster la checklist de reprise.
  • Statuts intake → mesure : convention nouvelle. À greffer sur les projects active au fil de l'eau, pas en backfill massif.

Sources