Aller au contenu

title: Trame de création d'un ticket Linear

type: concept owner: auto confidentiality: internal last_updated: 2026-07-13 last_reviewed: 2026-07-13 review_cadence: quarterly tags: [concept, linear, specs, product, engineering]

Trame de création d'un ticket Linear

Modèle partageable pour rédiger une issue Linear chez Bricks — tickets humains et tickets éligibles à l'agent autonome.

Avant de créer le ticket

Issue ou project ?

Situation Où le mettre
1 livrable cohérent (1 PR, 1 feature, 1 fix) Issue dans un project existant
≥2 livrables séparables, ≥2 surfaces, ou décision structurante Project dédié + plusieurs issues liées

Cf. Conventions Linear Bricks pour la hiérarchie initiative / project / issue.

Titre

Action concrète et observable, orientée métier.

  • Bon : « Ajouter un export CSV sur la liste des projets »
  • Mauvais : « Implémenter route GET /projects/export »

Trame type — description du ticket

Copier-coller dans le corps de l'issue Linear :

## Contexte

[1-3 phrases : pourquoi ce ticket existe, d'où il vient (meeting, ADR, demande user, bug remonté).
Lien vers la source si elle existe.]

## Problème

[Qui souffre, de quoi — 1-2 phrases.
À remplir si sujet produit. Omit si ticket purement technique sans pari produit.]

## Hypothèse

[Si [action], alors [résultat attendu] parce que [mécanisme].
Omit si N/A.]

## Outcome / métrique de succès

[Métrique + comment on la mesure + fenêtre temporelle.
Écrire `[outcome non formulé]` si inconnu — ne pas inventer.]

## Plus petit incrément (MVP de ce ticket)

[Minimum livrable pour apprendre ou débloquer — pas le scope complet du project.]

## Kill criteria

[Optionnel. Seuil ou date d'invalidation du pari pour CE ticket.]

## Parcours user (si impact UI)

[Entrée → happy path → sorties → retours en arrière.
Omit si ticket back / data sans surface user.]

## États couverts (si impact UI)

[Liste exhaustive : happy, vide, chargement, erreur, partiel, désactivé.
+ edge cases nommés : donnée tronquée, double action, hors ligne, abandon.
Tout ce qui n'est pas listé ne sera pas implémenté.]

## Niveau de fidélité retenu (si impact UI)

[zoning / wireframe / mid-fi / high-fi — et pourquoi.
Lien Figma si applicable.]

## Critères de QA design (si impact UI)

- États visuels à vérifier (happy + vide + chargement + erreur + partiel)
- Edge cases listés ci-dessus
- Accessibilité minimale (contraste, clavier, labels)
- Cohérence design system (pas de one-off)
- Qui valide vs maquette, et quand

## Story

En tant que [persona], je veux [action] pour [bénéfice].

## Critères d'acceptation

- [ ] Critère 1 — observable et testable
- [ ] Critère 2
- [ ] Critère 3

## Hors scope

[Liste explicite de ce qui n'est PAS dans ce ticket.]

## Risques, edge cases et données

- Edge cases fonctionnels (donnée absente, doublon, permission, erreur réseau, timeout…)
- Risques data / migration (volumes, invariants, rollback)
- Données de test nécessaires
- Cas explicitement reportés

## Vérification ownership

- Test manuel du parcours critique à réaliser
- Vérification preprod / prod (déploiement, feature flag, migration, activation)
- Logs / métriques à surveiller si pertinent
- Personnes à prévenir ou à faire tester
- Follow-up post-ship si nécessaire

## Contraintes techniques

[À remplir si applicable :
- Migration DB autorisée + schéma cible détaillé
- Dépendance npm autorisée + version + justification
- Surface sensible (paiements, KYC, votes…) → review humaine obligatoire
- Convention spécifique à respecter]

## Sources

- [ADR / meeting / Slack / transcript](url)

Sections à garder selon le type de ticket

Type Sections obligatoires
Tout ticket Contexte · Story · Critères d'acceptation · Hors scope (si risque de scope creep)
Sujet produit + Problème · Hypothèse · Outcome · Plus petit incrément
Impact UI + Parcours · États couverts · Fidélité · QA design
Ticket éligible agent Tout le template ci-dessus, sans ambiguïté résiduelle
Ticket technique pur Contexte · Critères d'acceptation · Risques/edge cases · Contraintes techniques · Vérification ownership

Métadonnées Linear (en plus du corps)

  • Project : rattacher au project pertinent (ou préciser si ticket isolé)
  • Priorité : Urgent / High / Medium / Low — posée maintenant, pas « à voir »
  • Label éligible agent : uniquement si le ticket est prêt pour l'agent autonome (spec complète, zéro arbitrage ouvert)
  • Relations : blockedBy / relatedTo / parent si dépendances

Test mental pour les dépendances : « Si A est fait mais B ne l'est pas, A peut-il être considéré comme livré ? »

  • Oui → A bloque B
  • Non → A est bloqué par B

Règles de rédaction

  1. Orienté métier, pas implémentation — ne pas prescrire contrôleurs, routes, hooks ; décrire le comportement attendu.
  2. Critères d'acceptation observables — pas « bonne UX » ou « code propre ».
  3. 1 ticket = 1 livrable cohérent — pas de ticket fourre-tout API + front + cleanup.
  4. Hors scope explicite — limite le scope creep.
  5. Pas d'ambiguïté — si un arbitrage n'est pas tranché, le ticket n'est pas prêt ; créer d'abord une ADR ou une synchro.
  6. Done = shippé en prod — une PR mergée ou un design fait ne suffit pas à fermer le sujet (conventions Linear).

Anti-patterns à éviter

Mauvais Pourquoi
« À voir avec l'équipe si on utilise X ou Y » Arbitrage non tranché → ticket bloqué
« Améliorer la gestion des exports » Trop large → découper en project + issues
Critères flous (« bien intégré ») Pas vérifiable
Pré-mâcher l'implémentation Le dev (ou l'agent) traduit
Ticket sans - [ ] dans les critères Pas de validation possible

Version courte (ticket simple, exécution humaine)

Pour un ticket ops ou technique sans pari produit :

## Contexte
[Pourquoi, source]

## Story
En tant que [persona], je veux [action] pour [bénéfice].

## Critères d'acceptation
- [ ] …
- [ ] …

## Hors scope
- …

## Vérification
[Comment on sait que c'est fait — test manuel, prod, qui valide]

Sources