Alternatives à Linear : pourquoi le suivi d'issues local-first est plus rapide que vous ne le pensez

Profondeur d'intégration Git : au-delà du lien entre commits et issues

La plupart des issue trackers traitent l'intégration Git comme une case à cocher : mentionnez un ID d'issue dans un message de commit, et un lien apparaît sur l'issue. C'est utile mais superficiel.

Beadbox est construit sur beads, un issue tracker où la sémantique Git est la couche de stockage, pas une intégration ajoutée. Dolt, la base de données sous-jacente, implémente le modèle de données en arbre de Merkle de Git pour les données structurées. Chaque changement d'issue est un commit. Chaque commit a un parent. Vous obtenez dolt diff, dolt log et dolt merge sur votre historique d'issues avec la même sémantique que vous utilisez sur le code.

Ce que cela signifie concrètement :

Votre historique d'issues est auditable. La base de données elle-même est un graphe de commits. Vous pouvez faire un diff entre deux points dans le temps et voir exactement quels champs ont changé sur quels issues. Ce n'est pas une « fonctionnalité de log d'audit » ajoutée par-dessus. Le format de stockage est la piste d'audit.

Les branches fonctionnent sur les issues, pas seulement le code. Dolt supporte les branches nativement. Vous pouvez brancher votre base d'issues pour expérimenter une réorganisation, puis la merger ou la jeter.

La synchronisation est push/pull, pas des appels API. La collaboration multi-machine 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 éditent des champs différents sur le même issue, le merge se résout automatiquement. Si deux personnes éditent le même champ sur le même issue, vous obtenez un conflit qui nécessite une résolution manuelle via le CLI Dolt (dolt conflicts resolve). Beadbox n'a pas encore d'interface de résolution de conflits ; vous gérez les conflits au niveau dolt. En pratique, les conflits sont rares quand chaque personne (ou agent) travaille sur des issues distincts, ce qui est le pattern typique. Mais si votre équipe édite fréquemment les mêmes issues simultanément, c'est un point de friction à connaître. La documentation de merge Dolt couvre le workflow de résolution en détail.

Rendu natif : pourquoi nous intégrons Node.js dans Tauri

Linear tourne dans un onglet de navigateur. Jira, Asana et tous les autres trackers SaaS aussi. Les onglets de navigateur rivalisent pour la mémoire, sont suspendus par l'OS et font leur rendu à travers un compositeur qui ajoute des frames de latence.

Beadbox tourne comme une application de bureau native construite avec Tauri. Les apps Tauri sont généralement minuscules (le runtime Tauri lui-même fait quelques mégaoctets) parce qu'elles utilisent le WebView natif de l'OS au lieu d'embarquer Chromium. Notre bundle est plus gros que les apps Tauri typiques avec environ 160 Mo, et c'est un compromis délibéré qui mérite explication.

84 Mo de ce total est un runtime Node.js embarqué. Nous utilisons une architecture sidecar : Tauri lance un serveur Next.js comme processus enfant, qui gère le server-side rendering, les server actions et la couche WebSocket pour les mises à jour en temps réel. Le WebView de Tauri pointe vers ce serveur local. Nous avons choisi ceci plutôt qu'un backend pur Rust parce que l'écosystème Next.js nous donne les React Server Components, les server actions et une vitesse d'itération rapide sur la couche UI. Le coût est la taille du bundle. Une app Electron équivalente pèserait 400 Mo+. Une app pure Rust + Tauri pèserait moins de 10 Mo mais aurait pris 3x plus de temps à construire et perdrait l'écosystème React.

La différence pratique par rapport à un onglet de navigateur : Beadbox fait son rendu dans un processus WebView dédié qui ne partage pas la mémoire avec vos 47 autres onglets. Déplier un arbre épique avec 100+ issues imbriqués, appliquer des filtres sur tout le backlog, changer de workspace : ces opérations se ressentent qualitativement différemment quand le moteur de rendu ne rivalise pas pour les ressources.

Extension avec le CLI, pas une API REST

Linear a une API GraphQL. Elle est bien conçue. Mais étendre Linear signifie écrire du code qui parle à leurs serveurs, s'authentifie avec leurs tokens et gère leurs limites de débit.

Beadbox prend une approche différente : le CLI bd est l'API. Chaque opération que la GUI effectue passe par bd, le même outil en ligne de commande que vous utiliseriez dans votre terminal.

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

Mise à jour en masse des priorités pour un balayage de triage :

# Passer tous les bugs ouverts en priorité 1 (critique)
bd list --status=open --type=bug --json | \
  jq -r '.[].id' | \
  xargs -I{} bd update {} --priority=1

Générer un résumé quotidien de statut :

# Qu'est-ce qui a changé dans les dernières 24 heures ?
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 crée et revendique du travail :

# L'agent découvre un bug, le déclare et le revendique
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

# ... l'agent fait le travail ...

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 de programmation (Claude Code, Cursor, Copilot Workspace), ils savent déjà exécuter des commandes CLI. Pas de bibliothèque client, pas de danse d'authentification. Juste des pipes Unix et des scripts shell.

Essayez Beadbox pour voir ces workflows visualisés en temps réel pendant que les agents les exécutent.

Offline-first n'est pas une fonctionnalité, c'est une architecture

Certains trackers cloud offrent un « mode offline » qui met en cache les données récentes et synchronise à la reconnexion. C'est une fonctionnalité ajoutée à une architecture fondamentalement en ligne. Les modes de défaillance sont prévisibles : cache périmé, conflits de synchronisation, opérations qui s'empilent silencieusement et échouent plus tard.

Beadbox fonctionne offline parce qu'il n'a jamais été en ligne. En mode embarqué, toute votre base d'issues est un répertoire sur votre système de fichiers. Pas de processus serveur. Pas de démon. Pas de socket réseau. Le CLI bd lit et écrit dans ce répertoire. Beadbox le surveille avec fs.watch() et affiche ce qu'il trouve.

Il n'y a rien à 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 défaut est local. Le défaut est le vôtre.

Qu'en est-il de la sécurité ? Si vous évaluez Beadbox pour des environnements air-gapped ou sensibles, voici la posture concrète :

• Chiffrement au repos : Beadbox ne chiffre pas le répertoire .beads/ lui-même. Il repose sur le chiffrement au niveau de l'OS (FileVault sur macOS, LUKS sur Linux, BitLocker sur Windows). Si votre modèle de menace exige un chiffrement par base de données, c'est une lacune.
• Sauvegardes : Votre répertoire .beads/ est un répertoire ordinaire. cp -r, rsync, Time Machine ou dolt push vers un distant fonctionnent tous. L'historique de commits Dolt signifie aussi que les changements accidentels peuvent être annulés avec dolt reset.
• Ce qui sort de la machine : En mode embarqué, rien. Zéro appel réseau. Dans l'app de bureau, deux connexions sortantes optionnelles existent : l'API GitHub pour vérifier les mises à jour de Beadbox (désactivable dans les paramètres), et l'analytique PostHog si vous acceptez (désactivée par défaut, aucun PII collecté). Aucune ne transmet de données d'issues.

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

Pas de piège du prix par siège

Linear facture $8/month par membre sur le plan Standard. Raisonnable pour une équipe de cinq. Moins raisonnable quand votre "équipe" inclut 13 agents IA qui doivent lire et écrire des issues.

Le modèle par siège suppose des équipes stables et de taille humaine. L'ingénierie agentique casse cette hypothèse. Vous pouvez lancer 3 agents pour un correctif et 13 pour une release. Chacun a besoin d'accéder à l'API. En tarification SaaS, chaque agent est un siège. Chaque siège est une ligne de facturation. Le coût augmente linéairement pour une ressource que vous augmentez exponentiellement.

beads est open-source. Le CLI est gratuit. Pas de tarif par siège, pas de palier d'utilisation, pas de "contactez les ventes pour l'entreprise." Vous pouvez lancer 2 agents ou 200 sur la même base locale et le coût ne change pas.

Beadbox (la GUI) est gratuit pendant la bêta. La tarification post-bêta n'est pas encore finalisée, mais ce ne sera pas par siège. Les agents ne sont pas des personnes. Facturer par agent a autant de sens que facturer par fenêtre de terminal.

Écosystème open-source

beads n'est pas un jardin clos. Le CLI est open-source sur github.com/steveyegge/beads, et la communauté a construit plus de 30 outils dessus : des générateurs de rapports personnalisés, des intégrations CI, des scripts d'orchestration d'agents, des extensions de dashboard et des adaptateurs d'export.

Ce que cela signifie concrètement :

Vous pouvez tout inspecter. Le format de stockage est Dolt, interrogeable en SQL standard. Le code source du CLI est en Go, lisible et forkable. Si bd create fait quelque chose d'inattendu, vous pouvez lire le code qui l'exécute.

Vous pouvez étendre sans demander la permission. Pas de processus d'approbation de marketplace, pas de programme partenaire, pas de négociation de limites d'API. Écrivez un script shell, un plugin Go ou un wrapper Python. Le flag --json du CLI sur chaque commande vous donne une sortie structurée à injecter dans ce que vous construisez.

Vos données sont portables. Le push/pull Dolt permet à votre base d'issues de vivre sur n'importe quel serveur que vous contrôlez, de se synchroniser avec DoltHub, ou de rester sur votre système de fichiers pour toujours. Il n'y a pas d'assistant d'export parce qu'il n'y a rien à exporter. Les données sont déjà les vôtres, dans un format que vous pouvez interroger directement.

La communauté construit des outils spécifiques aux agents. Les développeurs qui utilisent beads au quotidien sont ceux qui gèrent des flottes d'agents IA. Les extensions qu'ils construisent résolvent des problèmes de coordination d'agents : opérations en masse, scripts de résolution de dépendances, rapporteurs d'état de flotte. Ce n'est pas de l'engagement communautaire théorique. Ce sont des praticiens qui construisent des outils pour leurs propres workflows et les publient.

Coordination orientée agents

La plupart des issue trackers traitent "l'automatisation" comme un webhook qui se déclenche quand un humain change un statut. C'est adapter après coup une API à un workflow conçu pour les humains. beads et Beadbox ont été conçus dès le départ pour la coordination d'agents IA.

Identité structurée des agents. Chaque agent a un fichier CLAUDE.md qui définit son rôle, ses limites et son protocole de communication. Les flags --actor et --author du CLI bd rattachent chaque action à un agent spécifique. Quand eng2 prend une tâche et publie un plan, le système sait que c'était eng2, pas une "automatisation" générique.

La commande bd prime. Lancez bd prime dans n'importe quel workspace et elle produit un bloc de contexte conçu pour les assistants de codage IA. Collez-le dans le prompt système de votre agent et il connaît l'ensemble des commandes, les formats de sortie et les patterns de workflow. Apprendre à un nouvel agent à utiliser beads prend une commande, pas une page de documentation.

Des graphes de dépendances que les agents utilisent vraiment. Les agents ne travaillent pas avec des tableaux Kanban. Ils travaillent avec des arbres et des bloqueurs. beads suit nativement les relations parent/enfant et les dépendances de blocage. bd blocked montre chaque bead en attente de quelque chose. bd ready montre tout ce qui est débloqué et prêt. Beadbox affiche cela comme un arbre de dépendances interactif où vous voyez d'un coup d'oeil ce qui bloque et pourquoi.

Visibilité de flotte en temps réel. Beadbox surveille la base beads et met à jour l'interface en quelques secondes. Le Activity Dashboard affiche des cartes d'état des agents (qui est actif, qui est silencieux, qui est bloqué), un flux de pipeline (où le travail s'accumule) et un feed d'événements à filtrage croisé (cliquez sur un agent pour voir uniquement ses actions). C'est la vue "centre de mission" qui rend 13 agents parallèles gérables.

Choisir le bon outil pour votre équipe

Aucun outil n'est universellement correct. Voici un bilan honnête :

Choisissez Linear si :

• Votre équipe compte 10+ personnes et a besoin de gestion de projet centralisée
• Vous dépendez des intégrations Slack/GitHub/Figma
• Des parties prenantes non techniques ont besoin d'accéder à votre issue tracker
• Vous voulez une infrastructure gérée avec zéro overhead opérationnel
• Vous êtes une équipe produit livrant en cycles réguliers

Choisissez Beadbox si :

• Vous valorisez la souveraineté des données (les issues ne quittent jamais votre machine)
• Vous travaillez offline régulièrement ou dans des environnements réseau restreints
• Vous gérez des agents IA qui doivent lire et écrire des issues de façon programmatique
• Vous voulez un historique d'issues Git-native (branch, diff, merge sur vos issues)
• Vous préférez des workflows CLI-first avec un compagnon visuel quand nécessaire
• Vous êtes développeur solo ou petite équipe (1-10) sans besoin de fonctionnalités enterprise

Gardez votre outil actuel si :

• Le coût de changement dépasse la friction que vous subissez
• Votre équipe a investi dans des intégrations qui dépendent de l'API de votre tracker actuel
• Votre workflow correspond déjà aux opinions de votre outil

Migrer depuis Linear (ou d'autres trackers)

Soyons directs : il n'existe pas d'outil automatisé de migration Linear vers Beadbox aujourd'hui. Pas de wizard d'import CSV, pas de pont API, pas d'interface de correspondance de statuts.

Si vous partez de zéro, c'est parfait. bd init, commencez à créer des issues, et Beadbox les voit immédiatement. Zéro friction.

Si vous avez un projet Linear existant à transférer, le chemin viable actuellement est scripté : exportez depuis l'API Linear (ils supportent l'export CSV et API), transformez les données, et utilisez bd create en boucle pour recréer les issues. Vous perdrez les métadonnées spécifiques à Linear (cycles, vues projet, minuteurs SLA) mais conserverez titres, descriptions, priorités et statuts. Un script de migration est un projet de weekend, pas une intégration d'un trimestre.

Nous savons que ce n'est pas suffisant pour les équipes avec des milliers d'issues et des années d'historique. La construction d'un pipeline d'import adéquat est dans notre feuille de route mais pas encore livrée. Si la friction de migration est votre souci principal, attendez que nous l'ayons construit, ou évaluez si repartir de zéro est acceptable pour votre cas d'usage.

Démarrer

Beadbox est gratuit pendant la bêta. Installez-le avec Homebrew :

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

Si vous utilisez déjà beads, Beadbox détecte vos workspaces .beads/ existants automatiquement. Ouvrez l'app, et vos issues sont là. Pas d'étape d'import. Pas de création de compte.

Si vous découvrez beads, Beadbox vous guide dans l'initialisation de votre premier workspace. Vous verrez vos issues en moins de 60 secondes.

Téléchargez Beadbox ou consultez beads pour voir si le suivi d'issues local-first correspond à votre workflow.