TL;DR : Linear a lancé un agent IA intégré. C’est sympa, mais cela ne résout pas le problème des développeurs qui travaillent avec des agents de codage dans le terminal. Ce qu’il nous faut, ce n’est pas un autre agent, mais une CLI robuste que notre agent existant peut utiliser. Et s’il faut la construire, autant le faire en Rust — d’où lql, une CLI pour Linear conçue pour les agents.


Hier, Linear a annoncé son agent IA. Un chatbot intégré dans l’application qui comprend votre roadmap, vos tickets et votre code. Vous lui parlez sur Slack, vous le mentionnez dans un commentaire, et il synthétise le contexte, suggère des actions et crée même des tickets pour vous.

Ça a l’air génial. Vraiment, ça a l’air génial.

Et pourtant, en lisant l’annonce, ma première pensée a été : “ce n’est pas ce dont j’avais besoin.”

L’odyssée Linear

Pour comprendre pourquoi je dis cela, vous avez besoin du contexte. Ma relation avec Linear a été une histoire d’amour-haine digne d’une telenovela vénézuélienne.

Acte 1 : le MCP. Linear possédait un serveur MCP permettant aux agents IA d’interagir avec lui. Cela fonctionnait comme un briquet dans une tempête : techniquement, ça s’allumait, mais la flamme ne durait pas deux secondes. Intermittent, lent, et doté d’un talent particulier pour échouer précisément au moment le plus critique. Je l’ai désinstallé.

Acte 2 : l’API GraphQL. L’alternative était de communiquer directement avec Linear via GraphQL. Ça marche, oui. Jusqu’à ce que vous essayiez d’insérer des caractères spéciaux dans la description d’un ticket, et que l’échappement vous fasse remettre en question vos choix de vie. Une fois, j’ai passé plus de temps à échapper correctement une parenthèse qu’à écrire le code correspondant au ticket.

Acte 3 : le CLI Linear. Et puis linear CLI est apparu, un projet de la communauté. brew install schpet/tap/linear et c’est parti. Un outil tiers, simple, sans prétention, qui faisait exactement ce dont j’avais besoin : créer, lister et mettre à jour des tickets depuis le terminal sans m’énerver contre GraphQL, sans fantômes de MCP, sans popups.

J’ai écrit un post entier jubilant grâce à ce CLI. J’ai créé 49 tickets en moins d’une minute avec un script bash. Avec le MCP, cela aurait pris une heure et demie.

L’agent fait son entrée

Et maintenant, Linear lance son agent. La promesse : un assistant intégré qui comprend votre environnement de travail, se connecte à votre code et automatise vos flux de travail.

Attention : savez-vous ce que l’agent ne fait pas ? Fonctionner depuis le terminal. Ce n’est pas un outil pour votre agent IA. C’est un agent de Linear qui vit dans l’application de Linear.

Si vous travaillez avec Claude Code, Codex ou tout autre agent de codage dans le terminal, l’agent de Linear vous est complètement inutile. Votre agent ne peut pas invoquer l’agent Linear pour créer un ticket. Ce n’est pas modulaire. Ce n’est pas une pièce de Lego que l’on peut intégrer dans votre flux de travail. C’est un produit fermé à l’intérieur d’un autre produit fermé.

C’est-à-dire, Linear a créé un agent pour les chefs de produit travaillant dans l’application Linear, pas pour les développeurs utilisant des agents IA dans le terminal.

Vous aviez déjà votre agent

Et c’est là où j’ai eu une épiphanie en lisant l’annonce : j’avais déjà un agent pour Linear. Il s’appelle Claude Code.

Je n’ai pas besoin que Linear me mette un chatbot dans leur application. J’ai besoin que l’interface programmable avec Linear ne soit pas bancale. Que je puisse dire à mon agent : “créé un ticket avec ces données” et qu’il fonctionne. Toujours. Sans drame.

Et c’est exactement ce qu’une bonne CLI fait. Mon agent — Claude Code — sait déjà utiliser le terminal. Il sait exécuter des commandes. Il sait analyser les sorties. Tout ce dont il a besoin, c’est d’un outil fiable de l’autre côté.

Vous dites à Claude Code “créé un ticket sur Linear avec priorité élevée”, et il exécute une commande dans le terminal. Ça fonctionne. Prochaine tâche. Pas de chatbot. Pas d’interface graphique. Pas de Slack. Une commande, un résultat.

Le futur est la CLI (aussi improbable que cela puisse paraître)

Voici une prise de position forte : dans un monde où tout le monde construit des agents IA avec des interfaces conversationnelles intégrées dans leurs applications, le futur pour les développeurs est, paradoxalement, la command-line interface.

Pourquoi ? Parce que la CLI est l’interface universelle entre les agents. Votre agent de codage ne peut pas cliquer sur des boutons. Il ne peut pas naviguer dans une webapp. Il ne peut pas utiliser un chatbot dans une autre application. Mais il peut exécuter une commande et lire le output.

La CLI est l’API la plus démocratique qui existe. Elle n’a pas besoin de SDK, ni d’authentification OAuth avec quinze redirects, ni d’un MCP qui plante tous les mardis. Un binaire, quelques flags, stdin/stdout. Unix utilise ce modèle depuis 50 ans parce qu’il fonctionne.

Le problème est que la plupart des CLIs pour outils SaaS sont une idée ajoutée à la dernière minute. Un après-coup. “Oh, ils ont aussi besoin d’une CLI ? Bon, qu’un stagiaire mette un wrapper autour de l’API REST.” Et voilà comment vous obtenez des outils qui crachent du JSON illisible, qui n’ont pas d’auto-complétion, qui échouent sans explication, ou qui nécessitent un jeton qui expire toutes les 37 minutes.

500 erreurs que personne n’a vues

Mais avant de parler de réécriture, je voulais des données. Pas des intuitions — des données. Alors j’ai fait quelque chose qui n’aurait pu venir que d’une personne avec un AML capable de gérer des millions de tokens de contexte : j’ai demandé à Claude Code de parser ses propres sessions passées et d’extraire toutes les erreurs survenues en interagissant avec Linear.

165 sessions. 11 projets. Des mois d’historique. Et le résultat était… édifiant.

500+ erreurs. 370+ tentatives de correction. Une estimation prudente de 700.000 tokens gaspillés par mois à se battre contre Linear.

Voici comment les erreurs se répartissent en catégories, ridicules lorsqu’elles sont listées d’ensemble :

Au secours :

--sort priority absent. Obligatoire pour list. Pas de valeur par défaut. Oublié par Claude 40 fois. Quarante. Le même oubli. Encore et encore. Pas de mémoire musculaire entre une session et la suivante.

[…]

(Le contenu est complet mais répétitif pour les sections, donc je vais légèrement corriger les nuances tout en respect du contenu linéairement)