Connecter Linear à n8n : automatiser le triage des tickets avec l'IA (guide complet)

Linear s'est imposé chez les équipes produit et engineering pour sa rapidité et la discipline qu'il impose autour des cycles et des priorités — mais cette discipline suppose qu'un humain lise, qualifie et route chaque ticket entrant. Connecter Linear à n8n déplace une partie de ce travail vers un workflow : un signalement client peut devenir un ticket Linear déjà catégorisé et priorisé par un modèle de langage, une issue nouvellement créée peut déclencher une notification ciblée, et un rapport de cycle peut se générer tout seul chaque semaine. Ce guide couvre l'authentification, la nature GraphQL de l'API Linear, les opérations du node, le fonctionnement du Linear Trigger, et deux exemples complets.

L'automatisation du triage n'est pas un gadget récent : une étude désormais classique de John Anvik, Lyndon Hiew et Gail C. Murphy, Who Should Fix This Bug?, présentée à l'ICSE 2006 et récompensée dix ans plus tard par le prix du papier le plus influent de la conférence, montrait qu'un algorithme d'apprentissage automatique entraîné sur l'historique des rapports de bugs atteignait 57 % de précision sur Eclipse et 64 % sur Firefox pour suggérer le bon développeur à qui assigner un ticket. Vingt ans après, un LLM correctement guidé par un prompt fait sensiblement mieux sur la catégorisation et la priorisation — de quoi justifier qu'on lui confie la première passe de triage plutôt que de la laisser reposer entièrement sur l'équipe.

Quand automatiser Linear avec n8n

Trois familles de cas d'usage reviennent le plus souvent :

• Triage IA des tickets entrants : un message support, un email ou un retour utilisateur devient une issue Linear déjà classée (bug, demande, question), taguée en priorité et assignée à la bonne équipe, avant qu'un humain ne l'ouvre.
• Notifications et digests ciblés : plutôt que de laisser chacun surveiller Linear en continu, un digest de cycle envoyé chaque lundi vers Slack, ou une alerte immédiate quand un ticket passe en priorité urgente.
• Synchronisation avec le reste de l'outillage : créer une issue Linear depuis un ticket de support, un message Slack ou une alerte de monitoring, ou au contraire pousser l'avancement d'un cycle vers un tableau de bord externe.

Si votre équipe travaille plutôt sur Jira, Trello, Asana ou ClickUp, la même recette s'applique avec leurs nodes respectifs : voyez nos guides pour automatiser Jira avec n8n, connecter Trello à n8n, connecter Asana à n8n et connecter ClickUp à n8n.

Authentification : Personal API Key ou OAuth2

n8n propose deux credentials pour Linear, valables à la fois pour le node Linear et pour le Linear Trigger :

1. Personal API Key — la voie la plus simple pour un usage interne. Dans Linear, ouvrez Settings → Security & access, créez une clé API personnelle nommée, copiez-la immédiatement, puis collez-la dans n8n : Credentials → New → Linear API. Le workflow agit alors avec les permissions de votre compte Linear.
2. OAuth2 — nécessaire pour qu'une application agisse au nom de plusieurs utilisateurs. Créez une application OAuth dans Linear, renseignez-y l'URL de redirection fournie par n8n, puis choisissez un Actor : User (les ressources créées apparaissent comme venant de l'utilisateur qui a autorisé l'application) ou Application (elles apparaissent comme venant du bot Linear). Pour utiliser ce credential avec le Linear Trigger, le toggle Include Admin Scope doit être activé — sans lui, l'enregistrement du webhook échoue.

Pour un workflow d'équipe classique, la Personal API Key suffit largement ; réservez OAuth2 aux intégrations distribuées à plusieurs comptes.

L'API Linear est en GraphQL — ce que ça change pour vous

Contrairement à Asana, Jira ou Trello qui exposent une API REST, Linear n'expose qu'une API GraphQL unique (https://api.linear.app/graphql). Le node Linear de n8n masque cette complexité derrière des opérations à formulaires classiques pour les cas les plus courants. Pour tout ce qui sort de ce périmètre (labels personnalisés, cycles, roadmaps, sous-issues avancées…), la méthode documentée par n8n est d'ajouter un node HTTP Request, de choisir Authentication → Predefined Credential Type → Linear API, et d'y écrire directement la requête ou la mutation GraphQL voulue, en réutilisant le credential déjà configuré.

Les opérations du node Linear

Une fois le credential connecté, le node Linear expose deux ressources principales :

• Issue : Create, Update, Get, Get Many et Delete — le cœur de la plupart des workflows, avec les champs classiques (titre, description, équipe, priorité, assigné, labels, état).
• Comment : Create (ajouter un commentaire) avec un champ Parent Comment ID optionnel, pour répondre dans un fil existant plutôt que de créer un nouveau commentaire racine — utile pour qu'un agent IA journalise son raisonnement sans polluer la conversation humaine.

Comme n'importe quel node d'action, le node Linear peut aussi être branché en Tool sur un node AI Agent : voyez notre guide du node AI Agent pour comprendre comment un agent décide lui-même quand créer une issue ou poster un commentaire.

Le Linear Trigger : un webhook, sans distinction native création/modification

Le Linear Trigger enregistre un webhook côté Linear. Sa configuration tient en deux champs : le Team ID de l'équipe à surveiller, et la Resource (typiquement Issue). Dès qu'un événement survient sur cette ressource, Linear notifie l'URL du workflow, et n8n gère la vérification de la livraison.

Le point à connaître avant de construire dessus : ce webhook se déclenche aussi bien à la création qu'à la modification d'une issue, sans champ dédié pour ne garder que les créations. La parade la plus simple est un node IF juste après le trigger, qui compare les horodatages createdAt et updatedAt de l'issue reçue : quasi identiques à la seconde près pour une création, nettement différents dès la première modification. Notre guide du routage conditionnel avec IF et Switch détaille la mécanique de ce genre de filtre.

Exemple n°1 : triage IA des tickets support entrants

Scénario : les messages reçus sur une boîte support ou un formulaire deviennent des issues Linear déjà qualifiées.

1. Trigger en amont (email entrant, formulaire ou webhook d'un outil de support) qui capture le texte du signalement.
2. AI Agent ou LLM Chain : à partir d'un prompt qui décrit vos catégories (bug, question, demande commerciale, urgence), le modèle choisit un type de ticket, une priorité (0 à 4 côté Linear) et rédige un résumé structuré — la logique est la même que celle détaillée dans notre guide du scoring de tickets support par IA.
3. Linear (Issue → Create) : titre généré par le modèle, description reprenant le message original, équipe et priorité déduites du triage.
4. Linear (Comment → Create) : le modèle poste en commentaire sa justification (« classé bug critique car mention d'une perte de données en production »), dans l'esprit du guide de journalisation des décisions d'un agent IA.
5. Si la priorité est urgente, un node Slack alerte immédiatement le bon canal (voir notre guide du bot Slack IA).

Ce pattern de qualification est celui du tri d'emails du Pack Inbox IA (79 €), appliqué ici à des tickets Linear plutôt qu'à une boîte mail. Et si votre équipe doit prouver, en audit, que chaque signalement a bien été traité et tracé, le Pack Conformité & Audit (149 €) fournit déjà la piste d'audit Supabase pour journaliser ce type de décision automatisée.

Exemple n°2 : digest hebdomadaire de cycle vers Slack

1. Schedule Trigger chaque lundi à 8 h 30 — attention au fuseau horaire, détaillé dans notre guide du Schedule Trigger et des expressions cron.
2. HTTP Request vers l'API GraphQL de Linear (avec le credential Linear en Predefined Credential Type) pour récupérer les issues du cycle en cours de l'équipe, groupées par état.
3. Un node Code regroupe les issues en retard ou sans assigné et calcule un pourcentage d'avancement du cycle.
4. Un node Slack poste un message unique, avec le lien direct vers chaque ticket en retard — un digest hebdomadaire plutôt qu'une notification par ticket, dans la continuité de l'idée de triage automatisé développée plus haut.
5. Optionnel : un modèle de langage résume l'état du cycle en trois lignes en tête de message.

Le même squelette fonctionne avec une base Notion à la place de Linear pour le suivi projet — voyez notre guide de connexion Notion à n8n.

Limites et bonnes pratiques

• API GraphQL uniquement : toute opération absente du node (labels, cycles, sous-issues avancées) passe par un HTTP Request en GraphQL — pas de raccourci REST.
• Rate limiting à la complexité : Linear limite les appels selon la complexité des requêtes GraphQL plutôt qu'un simple nombre d'appels ; les requêtes larges (beaucoup de champs imbriqués) consomment davantage de ce budget, à surveiller sur un digest qui interroge tout un cycle d'un coup.
• Webhook sans filtre natif : le Linear Trigger notifie créations et modifications indifféremment ; filtrez systématiquement en aval avec la comparaison createdAt / updatedAt.
• Include Admin Scope obligatoire pour OAuth2 : sans ce toggle, le Linear Trigger ne peut pas enregistrer son webhook.
• Plan gratuit limité mais fonctionnel : 2 équipes et 250 tickets actifs suffisent pour tester l'intégration avant de basculer sur un plan payant si le volume grandit.

En résumé

La Personal API Key suffit pour la quasi-totalité des workflows internes, l'API Linear tourne entièrement en GraphQL derrière le node (avec un HTTP Request en secours pour le reste), et le Linear Trigger est un vrai webhook — à condition de filtrer soi-même les créations des modifications, faute de champ dédié côté n8n. Avec ces trois réflexes, le triage IA des tickets entrants et le digest hebdomadaire de cycle se montent en une heure. Pour partir d'une qualification IA déjà assemblée, prompts compris, le Pack Inbox IA (79 €) s'adapte directement à un flux de tickets Linear.