Conventions Linear Bricks¶

Contexte¶

L'équipe produit/tech a basculé son suivi de Notion vers Linear. La bascule visait à sortir d'un Notion « très endormi » et à avoir un suivi qui puisse être mis à jour par n'importe quel outil (Cursor, Claude Code, l'app) en fonction de ce qui a été fait dans la semaine. La contrepartie : sans conventions partagées, les trois niveaux de Linear (initiative / projet / issue) deviennent vite confus, et la vue collective perd sa lisibilité.

Pourquoi on en parle¶

Au weekly du 08/06/2026, le sujet est revenu cinq fois sous des formes différentes : projets « fourre-tout » sans fin, confusion sur les trois niveaux, absence de visibilité front vs back, projets invisibles dans la timeline tant qu'ils ne sont pas démarrés, et plusieurs personnes qui se disent peu à l'aise avec l'outil. L'équipe n'avait pas bénéficié d'un onboarding Linear structuré ; la confusion était collective.

Cette fiche rend la doctrine partageable et la relie au cycle de cadrage et à la priorisation produit.

Hiérarchie cible (auto)¶

Dernière mise à jour : 2026-06-08

Doctrine reformulée et validée collectivement au weekly du 08/06/2026 (portée par Hugo, alignée avec la règle interne existante) :

Initiative = parapluie thématique infini, rolling, multi-trimestres (ex : Backoffice — amélioration continue, Sécurité). Porte le sens long terme, pas une fin.
Projet = un sujet scopé, avec un début et une fin (même sans date précise) et idéalement des milestones. C'est l'unité qu'on lit dans la timeline et qu'on parcourt ensemble au weekly. Aussi spécifique que le cas qu'il porte.
Issue = un livrable opérationnel cohérent, qui sert surtout à s'organiser soi et à découper le travail à l'intérieur d'un projet.

Conséquence pratique : un sujet structurant se range dans un projet scopé, jamais dans une issue fourre-tout, ni dans un projet sans fin.

La vue timeline est le support du weekly¶

C'est la vue par projet, dans la timeline, qu'on regarde collectivement. Deux implications :

Le détail (les issues) sert à descendre d'un cran sous un projet, pas à remplacer le projet. Découper un projet en sous-projets front/back ferait perdre la possibilité, pour celui qui le porte, de poser ses propres issues de découpage.
Un projet n'apparaît dans la timeline que s'il a un statut actif (in progress) et des dates. Un projet en backlog ou sans date reste invisible — source de confusion récurrente au weekly (« je suis à zéro dans les initiatives »).

Règles et garde-fous (auto)¶

Dernière mise à jour : 2026-07-06

Définition de « Done » = shippé en prod (acté 06/07)¶

Un item n'est Done que lorsqu'il est en prod, pas quand le design est fait ni quand une PR est mergée. Une issue de sous-étape peut être terminée, mais le projet reste open tant que le résultat n'est pas livré et vérifié. Cette règle suit le canon ownership engineering.

Anti-fourre-tout (garde-fou central)¶

Pas de projet parapluie sans fin du type « amélioration de X » qui anticipe des cas futurs. Si le titre évoque « et tous les cas similaires », c'est un signal de scope creep → restreindre au cas concret.
À la place : packager un lot d'issues cohérentes dans un projet scopé, avec un début et une fin, sous l'initiative infinie correspondante. Exemple cité comme bon pattern : un projet qui regroupait plusieurs améliorations back-office, mais packagées ensemble avec une cohérence et une fin.
Si d'autres cas similaires arrivent un jour, on crée d'autres projets (ou on les regroupe sous une initiative commune) — on n'élargit pas le scope du projet existant.

Linear doit rester à jour¶

La bascule depuis Notion visait justement à sortir de l'état « endormi ». L'outil est censé pouvoir être mis à jour par n'importe quel outil (Cursor, Claude Code, l'app) en fonction de ce qui a été fait dans la semaine. Si la maîtrise de l'outil reste un frein, l'équipe organise une entraide ciblée.
Ce qui est fait dans la semaine doit « se ressentir dans Linear », pas seulement dans un message envoyé à Romain en parallèle.
Si la timeline ne montre pas la suite ou si des tickets manquent, la priorisation doit être refaite en parallèle. C'est une décision non appliquée au sens du réflexe 8, pas un sujet neuf.

Arbitrages complétés le 14/09¶

Visibilité front / back : un seul projet porte l'outcome. Le front et le back se découpent en issues cohérentes dans ce projet. On ne duplique pas le projet par discipline.
Clôture du projet : elle reste manuelle. Le DRI ferme le projet seulement quand le résultat est en production et vérifié. La complétion de toutes les issues ne ferme pas automatiquement le projet.

Points de configuration à appliquer¶

Filtres de la vue : masquer les projets non démarrés depuis plus de deux semaines ; label Hide from timeline pour sortir certains projets (Tech Days, etc.) de la vue. À mettre en place.
Supprimer la couche initiative ? Option évoquée pour simplifier (juste projets + issues). Écartée à ce stade : on y perdrait la vue timeline par initiative, et les projets seraient « mal rangés ». À reconfirmer.

Action actée¶

Une session de remise à niveau / formation Linear est à organiser, ouverte à tous ceux qui ne sont pas à l'aise avec l'outil. Objectif : partir des besoins concrets, prendre des exemples réels, et faire émerger d'éventuels nouveaux besoins de configuration.

Articulation avec d'autres conventions¶

Workflow agent autonome Linear → Code → GitHub — le pipeline agent s'appuie sur ces niveaux (statut projet pilote, label agent sur les issues).
Rédaction de specs « agent-ready » — cf. règle .cursor/rules/specs-pour-agent.mdc.
Weekly squad — la timeline Linear est le support du parcours collectif hebdo.
SOS Captain — entretient le tableau (priorisation, repasse to-do/backlog).

Sources¶

Weekly équipe du 2026-06-08 (transcript fourni en session, non promu en fiche meeting) — sujet récurrent du call, doctrine reformulée par Hugo, action de remise à niveau actée.
Cadrage produit — tickets après cadrage, project scopé
Priorisation produit — choix du portefeuille avant découpage
Ownership engineering — définition de fin jusqu'à la production