Alternatives a Linear : pourquoi le suivi de tickets local-first est plus rapide que vous ne le pensez

Linear est rapide. Credit ou le credit est du. Ils ont investi massivement dans la performance percue, et pour la plupart des equipes, c'est le meilleur issue tracker SaaS disponible. Mais "meilleur SaaS" vient avec des contraintes que certains developpeurs ne peuvent pas accepter : vos donnees vivent sur les serveurs de quelqu'un d'autre, votre workflow se plie pour correspondre a leurs opinions, et chaque interaction paie un impot de round-trip reseau.

Cet article est pour les developpeurs qui ont heurte ces murs. Peut-etre que vous gerez des flottes d'agents IA qui creent 50 tickets par heure. Peut-etre que vous travaillez en air-gapped ou offline-first. Peut-etre que vous ne voulez simplement pas d'ecran de connexion entre vous et vos tickets. Voici ce que nous avons appris en construisant Beadbox, un issue tracker desktop natif qui garde tout en local.

Allez directement a ce qui vous interesse :

• Vitesse local-first -- mesures CLI et UI sur des datasets reels
• Historique Git-natif -- branchez, diffez et fusionnez votre base de tickets
• Offline / air-gapped -- pas de reseau, pas de daemon, pas de probleme
• Scripts et agents -- trois workflows a copier-coller
• Limitations -- limitations honnetes avant d'investir du temps
• Matrice de decision -- quel outil pour quelle forme d'equipe
• Migration depuis Linear -- ce qui existe et ce qui n'existe pas

Pourquoi les developpeurs cherchent des alternatives a Linear

La reponse habituelle est "Linear est trop opiniatre." C'est vrai mais imprecis. Linear impose des cycles, des structures d'equipe et des etats de workflow qui supposent que vous etes une equipe produit livrant sur des cadences de deux semaines. Si c'est votre cas, Linear est excellent. Si vous etes un developpeur solo coordonnant des agents IA, ou une equipe de recherche avec des schemas d'iteration non standards, ou un groupe DevOps qui a besoin de tickets lies a des commits git plutot qu'a des threads Slack, les opinions de Linear deviennent de la friction.

Le probleme plus profond est architectural. Linear est un produit SaaS cloud-first. Chaque mutation voyage jusqu'a leurs serveurs et revient. Chaque requete depend de leur disponibilite. Vos donnees de tickets existent dans leur base de donnees, interrogeables via leur API, a leurs conditions. Pour la plupart des equipes, c'est un compromis acceptable. Pour les developpeurs qui se soucient de souverainete des donnees, d'acces hors ligne ou de vitesse brute de requete sur de grands datasets, c'est redhibitoire.

Ce que Beadbox ne fait pas

Avant d'entrer dans ce que Beadbox fait bien, voici ou ce n'est pas le bon choix. Sauter cette section ne vous aidera pas ; heurter ces murs apres avoir adopte l'outil, oui.

Pas de permissions multi-utilisateurs ni de controle d'acces. Il n'y a pas de comptes utilisateurs, pas de roles, pas de restrictions de visibilite par ticket. Toute personne avec un acces systeme de fichiers au repertoire .beads/ (ou au serveur Dolt) peut tout lire et ecrire. Si vous devez restreindre qui voit quoi, Beadbox n'est pas pour vous aujourd'hui.

Collaboration en temps reel limitee. Deux personnes peuvent travailler sur le meme ensemble de tickets, mais le modele de collaboration est push/pull (comme Git), pas des curseurs en direct et des indicateurs de presence. En mode serveur, Beadbox interroge les changements toutes les 3-5 secondes. En mode embedded, la surveillance du systeme de fichiers detecte les changements plus rapidement (sub-seconde), mais les ecritures concurrentes sur la meme base Dolt depuis deux processus peuvent provoquer un crash. Le schema sur est : un seul ecrivain a la fois, ou utilisez le mode serveur avec Dolt gerant la concurrence.

Pas d'integrations avec Slack, GitHub, Figma ou d'autres outils SaaS. Le point d'extension est le CLI bd et les scripts shell. Si votre workflow depend de "ticket ferme declenche un message Slack", vous devrez construire cette colle vous-meme.

Le plafond d'echelle est reel mais lointain. Nous testons sur des datasets de 10K et 20K tickets (voir les benchmarks ci-dessous). Ca fonctionne bien. Nous n'avons pas fait de stress-test a 100K+ tickets. Si vous etes une grande organisation generant des centaines de milliers de tickets par an, ce n'est pas un territoire eprouve.

Pas d'acces pour les parties prenantes non-techniques. Il n'y a pas de portail web, pas de visualiseur invite, pas d'URL de tableau de bord partageable. Beadbox est une application desktop qui lit une base de donnees locale. Montrer la progression a un PM qui n'utilise pas votre machine signifie un partage d'ecran ou un script bd qui genere un rapport.

Comment Beadbox fonctionne (la version 30 secondes)

Avant que les benchmarks aient du sens, voici l'architecture :

Mode embedded : La base de donnees Dolt vit dans .beads/ sur votre systeme de fichiers. Pas de processus serveur, pas de daemon. Le CLI bd lit et ecrit directement. Beadbox detecte les changements via fs.watch() avec un debounce de 250ms et diffuse via WebSocket vers l'interface. C'est le chemin zero-setup.

Mode serveur : Un processus dolt sql-server tourne separement (local ou LAN). Le CLI bd se connecte via le protocole MySQL. Beadbox interroge le serveur toutes les 3-5 secondes pour les changements au lieu de surveiller le systeme de fichiers. Ce mode supporte plusieurs ecrivains concurrents.

Chaque operation que l'interface execute passe par le CLI bd. Beadbox ne touche jamais la base de donnees directement. Si bd show et Beadbox ne sont pas d'accord, c'est un bug dans Beadbox.

Performance : benchmarks reels sur un dataset de 10K tickets

Le CLI beads publie des benchmarks que vous pouvez reproduire sur votre propre materiel. Voici des chiffres reels d'un M2 Pro executant la suite de benchmarks Go contre une base Dolt de 10 000 tickets :

Ce sont des benchmarks au niveau CLI : le temps que met bd pour lire ou ecrire dans la base Dolt locale. L'interface Beadbox ajoute un overhead de rendu par-dessus. Nos cibles de conception pour la stack complete (appel CLI + rendu React + propagation WebSocket) sont :

Nous ne publions pas de benchmarks contre Linear ou d'autres trackers car nous n'avons pas fait de comparaisons controlees, et des chiffres cherry-picks ne seraient pas honnetes. Ce que nous pouvons dire : l'integralite du chemin de donnees est local. Il n'y a pas de saut reseau entre cliquer sur un filtre et voir les resultats. Que cela compte pour vous depend de votre reference. Si Linear vous semble assez rapide pour la taille de votre dataset et votre localisation, il l'est probablement. Si vous avez deja senti le lag sur un backlog de 500 tickets depuis le Wi-Fi d'un hotel de conference, vous connaissez la douleur que ces chiffres adressent.

Pour reproduire : clonez beads, lancez go test -tags=bench -bench=. -benchmem ./internal/storage/dolt/... et comparez avec votre materiel. Les datasets en cache atterrissent dans /tmp/beads-bench-cache/.

Profondeur de l'integration Git : au-dela du lien entre commits et tickets

La plupart des gestionnaires de tickets traitent l'integration Git comme une case a cocher : mentionnez un ID de ticket dans un message de commit, et un lien apparait sur le ticket. C'est utile mais superficiel.

Beadbox est construit sur beads, un gestionnaire de tickets ou la semantique Git est la couche de stockage, pas une integration ajoutee apres coup. Dolt, la base de donnees sous-jacente, implemente le modele de donnees merkle tree de Git pour les donnees structurees. Chaque changement de ticket est un commit. Chaque commit a un parent. Vous obtenez dolt diff, dolt log et dolt merge sur l'historique de vos tickets avec la meme semantique que vous utilisez sur le code.

Ce que ca signifie en pratique :

Votre historique de tickets est auditable. La base de donnees elle-meme est un graphe de commits. Vous pouvez differ deux points dans le temps et voir exactement quels champs ont change sur quels tickets. Ce n'est pas une "fonctionnalite de journal d'audit" ajoutee par-dessus. Le format de stockage est la piste d'audit.

Le branching fonctionne sur les tickets, pas seulement sur le code. Dolt supporte les branches nativement. Vous pouvez brancher votre base de tickets pour experimenter une reorganisation, puis la fusionner ou l'abandonner.

La synchronisation est push/pull, pas des appels API. La collaboration multi-machines fonctionne comme git push et git pull. Pas de tokens API, pas de webhooks, pas de flux OAuth. Pointez votre remote Dolt vers un serveur (ou DoltHub) et poussez. L'autre machine tire.

Une note sur les conflits : Dolt utilise le three-way merge, comme Git. Si deux personnes editent des champs differents sur le meme ticket, le merge se resout automatiquement. Si deux personnes editent le meme champ sur le meme ticket, vous obtenez un conflit qui necessite une resolution manuelle via le CLI Dolt (dolt conflicts resolve). Beadbox n'a pas encore d'interface de resolution de conflits ; vous gerez les conflits au niveau dolt. En pratique, les conflits sont rares quand chaque personne (ou agent) travaille sur des tickets distincts, ce qui est le schema typique. Mais si votre equipe edite frequemment les memes tickets de maniere concurrente, c'est un point de friction a connaitre. La documentation de merge de Dolt couvre le workflow de resolution en detail.

Rendu natif : pourquoi nous embarquons Node.js dans Tauri

Linear tourne dans un onglet de navigateur. Jira, Asana et tous les autres trackers SaaS aussi. Les onglets de navigateur se disputent la memoire, sont suspendus par l'OS et passent par un compositeur qui ajoute des frames de latence.

Beadbox tourne comme une application desktop native construite avec Tauri. Les applications Tauri sont typiquement petites (le runtime Tauri lui-meme fait quelques megaoctets) car elles utilisent le WebView natif de l'OS au lieu d'embarquer Chromium. Notre bundle est plus gros que les applications Tauri typiques a ~160MB, et c'est un compromis delibere qui merite explication.

84MB de cela sont un runtime Node.js embarque. Nous utilisons une architecture sidecar : Tauri lance un serveur Next.js comme processus enfant, qui gere le server-side rendering, les server actions et la couche WebSocket pour les mises a jour en temps reel. Le WebView Tauri pointe vers ce serveur local. Nous avons choisi cela plutot qu'un backend pur Rust car l'ecosysteme Next.js nous donne React Server Components, les server actions et une vitesse d'iteration rapide sur la couche UI. Le cout est la taille du bundle. Une application Electron equivalente ferait 400MB+. Une application pure Rust + Tauri ferait moins de 10MB mais aurait pris 3x plus de temps a construire et aurait perdu l'ecosysteme React.

La difference pratique par rapport a un onglet de navigateur : Beadbox rend dans un processus WebView dedie qui ne partage pas la memoire avec vos 47 autres onglets. Deplier un arbre d'epic avec 100+ tickets imbriques, appliquer des filtres sur un backlog complet, basculer entre les workspaces : ces operations se ressentent qualitativement differemment quand le moteur de rendu n'est pas en competition pour les ressources.

Etendre avec le CLI, pas une API REST

Linear a une API GraphQL. Elle est bien concue. Mais etendre Linear signifie ecrire du code qui parle a leurs serveurs, s'authentifie avec leurs tokens et gere leurs rate limits.

Beadbox prend une approche differente : le CLI bd est l'API. Chaque operation que l'interface execute passe par bd, le meme outil en ligne de commande que vous utiliseriez dans votre terminal.

Voici trois workflows que vous pouvez copier-coller aujourd'hui :

Mise a jour en masse des priorites pour un sweep de triage :

# Set all open bugs to priority 1 (critical)
bd list --status=open --type=bug --json | \
  jq -r '.[].id' | \
  xargs -I{} bd update {} --priority=1

Generer un resume de statut quotidien :

# What changed in the last 24 hours?
echo "=== Closed today ==="
bd list --status=closed --json | \
  jq -r '.[] | select(.updated > (now - 86400 | todate)) | "\(.id) \(.title)"'

echo "=== Currently blocked ==="
bd blocked --json | \
  jq -r '.[] | "\(.id) \(.title) (blocked by: \(.blocked_by | join(", ")))"'

echo "=== Ready to work ==="
bd ready --json | jq -r '.[] | "\(.id) [P\(.priority)] \(.title)"'

Un agent IA cree et revendique du travail :

# Agent discovers a bug, files it, and claims it
ISSUE_ID=$(bd create \
  --title "Fix race condition in auth middleware" \
  --type bug \
  --priority 1 \
  --json | jq -r '.id')

bd update "$ISSUE_ID" --status=in_progress --assignee=agent-3

# ... agent does the work ...

bd update "$ISSUE_ID" --status=closed
bd comments add "$ISSUE_ID" --author agent-3 \
  "Fixed in commit abc1234. Root cause: mutex not held during token refresh."

Si vous faites tourner des agents IA (Claude Code, Cursor, Copilot Workspace), ils savent deja executer des commandes CLI. Pas de bibliotheque client API, pas de danse d'authentification. Juste des Unix pipes et des scripts shell.

Essayez Beadbox pour voir ces workflows visualises en temps reel pendant que les agents les executent.

Offline-first n'est pas une fonctionnalite, c'est une architecture

Certains trackers cloud offrent un "mode hors ligne" qui met en cache les donnees recentes et synchronise a la reconnexion. C'est une fonctionnalite greffee sur une architecture fondamentalement en ligne. Les modes de defaillance sont previsibles : cache obsolete, conflits de synchronisation, operations qui s'empilent silencieusement et echouent plus tard.

Beadbox fonctionne hors ligne parce qu'il n'a jamais ete en ligne. En mode embedded, votre base de tickets entiere est un repertoire sur votre systeme de fichiers. Pas de processus serveur. Pas de daemon. Pas de socket reseau. Le CLI bd lit et ecrit dans ce repertoire. Beadbox le surveille avec fs.watch() et affiche ce qu'il trouve.

Il n'y a rien a synchroniser parce qu'il n'y a rien de distant. Si vous choisissez plus tard de collaborer, le push/pull de Dolt vous donne une synchronisation explicite et visible. Mais le defaut est local. Le defaut est a vous.

Qu'en est-il de la securite ? Si vous evaluez Beadbox pour des environnements air-gapped ou sensibles, voici la posture concrete :

• Chiffrement au repos : Beadbox ne chiffre pas le repertoire .beads/ lui-meme. Il repose sur le chiffrement au niveau du systeme d'exploitation (FileVault sur macOS, LUKS sur Linux, BitLocker sur Windows). Si votre modele de menace exige un chiffrement par base de donnees, c'est une lacune.
• Sauvegardes : Votre repertoire .beads/ est un repertoire ordinaire. cp -r, rsync, Time Machine ou dolt push vers un remote fonctionnent. L'historique de commits de Dolt signifie aussi que les changements accidentels peuvent etre annules avec dolt reset.
• Ce qui quitte la machine : En mode embedded, rien. Zero appels reseau. Dans l'application desktop, deux connexions sortantes optionnelles existent : l'API GitHub pour verifier les mises a jour de Beadbox (desactivable dans les parametres) et les analytics PostHog si vous y consentez (desactive par defaut, aucune PII collectee). Aucune ne transmet de donnees de tickets.

Pour les environnements air-gapped, les projets classifies ou les developpeurs qui travaillent dans les avions et les trains, ce n'est pas un bonus. C'est la seule architecture qui fonctionne.

Choisir le bon outil pour votre equipe

Aucun outil n'est universellement correct. Voici une analyse honnete :

Choisissez Linear si :

• Votre equipe compte 10+ personnes et a besoin de gestion de projet centralisee
• Vous dependez d'integrations Slack/GitHub/Figma
• Des parties prenantes non-techniques ont besoin d'acceder a votre gestionnaire de tickets
• Vous voulez une infrastructure geree avec zero overhead operationnel
• Vous etes une equipe produit livrant sur des cycles reguliers

Choisissez Beadbox si :

• Vous valorisez la souverainete des donnees (les tickets ne quittent jamais votre machine)
• Vous travaillez regulierement hors ligne ou dans des environnements reseau restreints
• Vous gerez des agents IA qui doivent lire et ecrire des tickets programmatiquement
• Vous voulez un historique de tickets Git-natif (branchez, diffez, fusionnez vos tickets)
• Vous preferez des workflows CLI-first avec un complement visuel quand necessaire
• Vous etes un developpeur solo ou une petite equipe (1-10) qui n'a pas besoin de fonctionnalites enterprise

Gardez votre outil actuel si :

• Le cout de changement depasse la friction que vous experimentez
• Votre equipe a investi dans des integrations qui dependent de l'API de votre tracker actuel
• Votre workflow correspond deja aux opinions de votre outil

Migrer depuis Linear (ou d'autres trackers)

Soyons directs : il n'existe pas d'outil de migration automatique de Linear vers Beadbox aujourd'hui. Pas d'assistant d'import CSV, pas de pont API, pas d'interface de mapping de statuts.

Si vous partez de zero, pas de probleme. bd init, commencez a creer des tickets, et Beadbox les voit immediatement. Zero friction.

Si vous avez un projet Linear existant que vous voulez migrer, le chemin viable pour l'instant est par script : exportez depuis l'API de Linear (ils supportent l'export CSV et API), transformez les donnees et utilisez bd create en boucle pour recreer les tickets. Vous perdrez les metadonnees specifiques a Linear (cycles, vues de projet, timers SLA) mais conserverez les titres, descriptions, priorites et statuts. Un script de migration est un projet de week-end, pas une integration trimestrielle.

Nous savons que ce n'est pas suffisant pour les equipes avec des milliers de tickets et des annees d'historique. Construire un pipeline d'import adequat est dans notre feuille de route mais pas encore livre. Si la friction de migration est votre preoccupation principale, attendez que nous l'ayons construit, ou evaluez si repartir de zero est acceptable pour votre cas d'usage.

Pour commencer

Beadbox est gratuit pendant la beta. Installez-le avec Homebrew :

brew tap beadbox/cask && brew install --cask beadbox

Si vous utilisez deja beads, Beadbox detecte automatiquement vos workspaces .beads/ existants. Ouvrez l'application et vos tickets sont la. Pas d'import. Pas de creation de compte.

Si vous decouvrez beads, Beadbox vous guide pour initialiser votre premier workspace. Vous regarderez vos tickets en moins de 60 secondes.

Telechargez Beadbox ou decouvrez beads pour voir si le suivi de tickets local-first correspond a votre workflow.