Comment on a supprimé Linear et laissé Claude Code faire tourner nos sprints

Il y a un mois, on a résilié notre abonnement Linear. Deux développeurs et un designer sur une app React Native. À peu près 30 issues par sprint. Zéro outil de project management sur la stack. On n'ouvre jamais un onglet navigateur pour gérer le travail. Claude Code lit le sprint, file des nouvelles issues quand on spot des bugs, et pose les labels et assignees comme le ferait un humain. Depuis le changement, on shippe plus et notre facture d'outillage est plus légère.

Rien contre Linear, c'est un produit solide. Mais une fois qu'un coding agent peut filer des issues depuis la conversation, tu n'as plus du tout besoin d'UI de PM. Tu as juste besoin d'une plateforme que l'agent peut driver à travers le CLI.

Pourquoi on a tué Linear

Deux coûts se sont empilés. L'argent était faible mais réel : par siège, par mois, pour toujours. Le coût en tokens, c'est celui qui a vraiment mordu.

Une fois que tu wires Linear dans Claude Code via son MCP server, chaque session charge le schéma MCP dans le context window. Des centaines de messages par semaine multipliés par l'overhead MCP devient une ligne mesurable sur ta facture. Le schéma reste là même quand l'agent n'en a pas besoin, ce qui est le cas la plupart des tours. Tu paies une taxe d'attention sur chaque appel.

Le problème plus profond, c'était la duplication. On écrivait des commit messages, des descriptions de PR, des règles CLAUDE.md et des tickets Linear qui disaient tous à peu près la même chose dans un langage légèrement différent. GitHub était la vraie source de vérité. Linear était une UI dérivée qu'on sync à la main.

GitHub a déjà des issues, des projects, des iterations, des labels, des milestone. Le CLI gh expose tout ça avec zéro overhead MCP. Si l'agent peut filer une issue GitHub depuis du langage naturel, il ne reste rien à faire pour Linear dans notre flow.

La stack

Quatre pièces tiennent le système.

GitHub Projects v2 pour les iteration, les fields et le board de sprint. Natif sur la plateforme qu'on paie déjà.

Le CLI gh pour chaque opération issue et PR. Preinstallé dans notre environnement de dev, donc Claude Code l'invoque directement. Pas de MCP à charger, pas de danse d'auth par session.

Un fichier de règles à .ai-rules/github-project.md. C'est là que la team devient lisible pour l'agent : le project ID, l'iteration field ID, le username GitHub de chaque dev, la taxonomie de labels, le mapping taille-vers-estimate. Quand Claude file une issue, il lit ce fichier d'abord et obtient les bonnes valeurs de fields.

Une couche CI qui catche ce que l'agent rate. Un workflow valide le naming de branche. Un autre valide que chaque PR porte les bons labels. Un troisième checke si la PR touche du code native et auto-tag needs-native-build ou ota-safe. Ce dernier compte parce qu'on ship une app React Native et que le flow de release diffère entre les deux.

Les trois premiers donnent à Claude assez de contexte pour faire le travail. La couche CI, c'est le filet de sécurité pour quand il se trompe.

Une journée dans le sprint

Le matin démarre dans le terminal. Je demande à Claude « what's on my plate this iteration ? » et il lance une requête GraphQL contre GitHub Projects, filtre par mon username, print une liste triée par priorité.

J'en choisis une. Si ça implique un composant UI, notre designer l'a en général déjà build dans Storybook à l'intérieur de /packages/ui, donc je peux le câbler dans l'app directement. Si l'issue est underscoppée, je demande à Claude de la casser et de mettre à jour le body avant que je commence à coder. Puis je branche, taffe, push, ouvre la PR. Le CI check les labels et le nom de branche. Claude met à jour l'issue s'il y a quelque chose à signaler aux reviewers.

Quand je veux zoom out sur le sprint, je lance /sprint-status. C'est une slash command qui wrappe quelques queries gh et qui print le burn-down, les blockers, les items stale. Trois secondes, toujours dans le terminal.

Je peux ouvrir github.com si je veux voir le board visuellement. La plupart des jours, je ne le fais pas.

Capturer les bugs depuis la conversation

Ça, c'est la partie à laquelle je ne m'attendais pas.

Avant, quand je spottais un bug au milieu d'autre chose, j'avais deux mauvaises options. Tout arrêter et filer le ticket proprement, ce qui voulait dire trois minutes de context switch pour une observation d'une ligne. Ou le laisser dans ma tête en espérant m'en souvenir plus tard. La moitié du temps, non.

Maintenant le flow est en langage naturel. « Hey, je viens de remarquer que l'avatar de profil s'étire sur iPad quand tu passes en paysage. » Je drop le screenshot. Puis je retourne à ce que je faisais.

Claude fait trois choses à la suite.

Il investigate. Grepe la codebase pour le composant, regarde les props de style, forme une hypothèse sur la cause racine. Rien de lourd, une minute de reconnaissance pour que l'issue ait du vrai contexte au lieu d'un simple symptôme.

Il écrit le body de l'issue. Description, étapes de repro, fichiers suspects, screenshot attaché. Le genre de body qu'un reviewer peut prendre cold.

Il file avec gh issue create, ajoute l'item au GitHub Project, met l'iteration sur le sprint courant, attache les bons labels (bug, area:mobile, probablement ota-safe), et assigne un développeur. L'assignee par défaut, c'est moi en tant que reporter, sauf si je précise quelqu'un d'autre.

Pas d'UI, pas de context switch, et le bug est enregistré dans un état sur lequel un coéquipier peut vraiment agir. Le coût de workflow de capture s'est effondré. Le gap entre le moment où tu notices et le moment où tu files est sous les dix secondes maintenant, ce qui veut dire qu'on file tout ce qu'on notice au lieu d'en perdre la moitié à la friction. Notre bug hygiene est meilleure qu'elle ne l'était avec Linear, pour la raison la moins glamour : l'outil ne coûte rien à utiliser.

Pourquoi ne pas juste installer un MCP Linear

On nous pose la question à chaque fois. Trois raisons.

Les tokens. Le schéma du MCP vit dans ton context window que tu l'utilises sur ce tour ou non. À deux devs et des centaines de messages par semaine, c'est mesurable.

La surface de dependency. gh est toujours là parce que GitHub est toujours là. Un MCP Linear, c'est une pièce mobile de plus qui peut updater, fail ou drift hors sync avec l'API upstream.

Le cimetière d'UI. Au moment où l'agent peut filer depuis la conversation, personne n'ouvre Linear sauf par habitude. Les tickets commencent à être à moitié mis à jour là-bas, le vrai état vit dans GitHub, et tu paies pour une source de vérité qui n'est plus la source de vérité.

Aller natif sur la plateforme qu'on utilisait déjà a tué les trois problèmes d'un coup.

Où ça peut casser

On ne sait pas exactement où ça arrête de marcher.

Pour deux développeurs et un designer partageant un projet, on n'a pas touché de plafond. Le backlog reste à jour. Rien ne passe à travers parce que cliquer ne fait plus partie du flow.

À vingt développeurs avec des dependencies cross-team et des product managers dédiés, je m'attendrais à ce que ce setup grince. La logique d'assignment devient politique, la charge de review demande du routing, les besoins de reporting sont façonnés par des gens qui ne vivent pas dans un terminal. Ce n'est pas un remplacement de Jira pour une boîte de 200 personnes. Pour le genre de petite team focusée qui ship la majeure partie du logiciel en production, ça marche.

Le vrai point de fragilité, c'est le fichier de règles. Si .ai-rules/github-project.md devient stale (un nouveau label, un field renommé, une nouvelle convention de naming d'iteration), Claude commence à filer des issues dans les mauvais slots. Garder ce fichier à jour est une habitude hebdomadaire, la même habitude que tu aurais pour n'importe quelle pièce d'infrastructure.

Tout le reste tient.

Le vrai takeaway

La plupart des teams qui adoptent des outils de coding IA le font en MCPant chaque outil qu'elles utilisent déjà. MCP Linear, MCP Jira, MCP Slack, MCP Notion. Chaque couche coûte des tokens et ajoute des failure modes. Par-dessus, l'agent a maintenant une UI de plus à tenir en sync.

On est partis de l'autre côté. Choisis la plateforme minimum qui fait déjà le job. Écris un fichier de règles qui rend ta team lisible à l'agent. Laisse l'agent driver cette plateforme à travers le CLI comme le ferait un humain.

Ça, c'est tout le système. Un CLAUDE.md, un fichier de règles pour GitHub Projects, quelques slash commands. Linear n'est plus sur la stack. On shippe plus. Et comme filer un bug ne coûte plus rien, on capture tout ce qu'on notice.

Le walkthrough complet du fichier de règles, des workflows gh et des slash commands qu'on a bâties pour ça est dans le cours d'agentic coding.

Si tu veux décaper la stack PM de ta team et router le travail à travers l'agent à la place, parlons de ce que ça donnerait sur ta codebase.