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é.

Cette page est la doctrine partagée de structuration sous Linear — le support de la remise à niveau d'équipe actée au weekly du 08/06/2026. Elle existe pour que la convention ne vive plus seulement dans la tête de quelques personnes.

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. Romain a reconnu qu'il n'y avait pas eu de vrai effort d'onboarding — la confusion est collective, pas individuelle.

La même doctrine existait déjà, mais uniquement dans la règle personnelle de Romain (collaboration-romain.mdc, section 2 : project vs issue, garde-fou anti-parapluie, hiérarchie initiative/project/issue), gitignorée donc invisible pour l'équipe. Cette fiche la rend partageable.

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-06-08

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. Donc plus d'excuse : si le frein est la méconnaissance de l'outil, on s'entraide.
Ce qui est fait dans la semaine doit « se ressentir dans Linear », pas seulement dans un message envoyé à Romain en parallèle.

Points encore ouverts (non tranchés au 08/06)¶

Visibilité front vs back : pas de tag/label front/back aujourd'hui, donc difficile de voir la nature d'un projet. Trois options évoquées sans arbitrage — labels front/back, projets séparés quand front et back ne commencent/finissent pas au même moment (ex. « step présentation » front livrée avant le back), ou un projet unique de step qui contient les deux. À trancher à la remise à niveau.
Auto-done du projet : passer une PR liée ne bascule l'issue en done, mais pas le projet. Piste évoquée : un workflow Linear qui passe le projet en done quand toutes ses issues le sont.
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.
Règle interne collaboration-romain.mdc § 2 — doctrine project vs issue, garde-fou anti-parapluie, hiérarchie initiative/project/issue (origine de la convention).