Linear pour le support client : transformez les tickets en rapports de bug et prévenez les clients quand c'est corrigé

Un client signale un bug le lundi. Votre agent le poste dans le canal des développeurs, quelqu'un ouvre une issue dans Linear, et le ticket reste en plan. Vendredi, 20 autres clients ont déjà signalé le même bug.

Le correctif est sorti mercredi, et personne ne les a prévenus. Ce guide montre comment confier les bugs à Linear, regrouper les doublons sur une seule issue et prévenir les clients quand le correctif est en ligne.

En bref

• Cherchez avant de créer. Cherchez d'abord une issue existante dans Linear, par sa clé ou par des mots du titre.
• Écrivez le rapport pour un développeur. Étapes pour reproduire, résultat attendu et résultat obtenu, environnement, impact. Aucun nom ni coordonnées de client.
• Un bug, une issue, plusieurs tickets. Chaque ticket qui parle du même bug est lié à la même issue. Le nombre de tickets liés montre à l'équipe technique l'ampleur du problème.
• Laissez le statut revenir sur le ticket. Les agents ne devraient pas avoir à consulter Linear ni à recopier les mises à jour à la main.
• Prévenez le client quand le correctif est en ligne. Done dans Linear et en ligne pour vos clients, cela peut tomber 2 jours différents.

Deskwoot, le help desk que nous développons, gère les liens et le suivi du statut grâce à son intégration Linear. Tout le reste de ce guide fonctionne avec les outils que vous utilisez déjà.

Pourquoi les bugs se perdent entre le help desk et Linear

Le support vit dans le help desk, l'équipe technique vit dans Linear. Un rapport de bug passe de l'un à l'autre une seule fois, puis les 2 fiches s'éloignent peu à peu.

Personne ne s'occupe du retour

L'agent qui a créé l'issue passe aux 40 tickets suivants. Le développeur clôt l'issue et passe lui aussi à autre chose. Si rien ne ramène le statut sur le ticket, le client le découvre en réessayant.

Linear explique comment sa propre équipe support évite ce piège dans un article sur la façon dont son équipe Customer Experience travaille dans Linear. Quand une issue passe en Done, la conversation de support liée se rouvre avec une note, et l'équipe support contacte alors le client pour lui annoncer le correctif et vérifier qu'il fonctionne.

Des mises à jour de statut à la main

Sans lien, quelqu'un au support ouvre Linear chaque matin, parcourt une liste d'issues et recopie le statut dans les tickets. Cela prend du temps, on le saute les jours chargés, et c'est déjà faux l'après-midi.

Le même bug, 20 fois

Quand les agents ne voient pas ce que l'équipe technique sait déjà, chacun crée sa propre issue. Les développeurs perdent alors du temps à fusionner les doublons, et la vraie taille du problème reste cachée derrière 5 issues qui affichent chacune 1 ou 2 signalements.

Avant de créer une issue

Un ticket qui dit « ça ne marche pas » n'est pas toujours un bug. L'équipe technique cesse vite de faire confiance aux rapports du support si la moitié se révèlent être des questions sur le fonctionnement d'une fonctionnalité.

3 questions à se poser d'abord

1. Pouvez-vous le reproduire ? Essayez vous-même, avec le même forfait, le même navigateur ou la même version de l'app que le client.
2. Est-ce le comportement prévu ? Consultez votre centre d'aide et la documentation du produit. Si ce comportement est documenté, c'est une question sur la fonctionnalité, et le client a peut-être besoin d'une meilleure explication.
3. Une issue existe-t-elle déjà ? Cherchez dans Linear avec les mots qu'un développeur mettrait dans un titre, comme « export » ou « CSV », et avec l'écran où le problème se produit.

Si la réponse à la troisième question est oui, liez le ticket à cette issue et ajoutez les nouveautés en commentaire. Ne créez une nouvelle issue que si rien ne correspond.

Ce qui rend un rapport de bug utile aux développeurs

Les consignes de Mozilla pour rédiger un rapport de bug ont été écrites pour Firefox, et elles valent pour toute équipe logicielle. Le résumé doit expliquer le problème, pas la solution que vous proposez, et le rapport doit séparer les faits des suppositions.

Un modèle que vos agents peuvent copier

• Titre : ce qui ne va pas et où. « L'export CSV perd la dernière ligne quand un filtre est actif » vaut mieux que « Export cassé ».
• Étapes pour reproduire : numérotées, aussi courtes que possible, en précisant si le problème arrive à chaque fois ou seulement parfois.
• Résultat attendu : ce qui aurait dû se passer.
• Résultat obtenu : ce qui s'est vraiment passé, avec le texte exact de l'erreur ou une capture d'écran.
• Environnement : forfait, navigateur ou version de l'app, appareil, et l'heure à laquelle c'est arrivé, pour que les développeurs le retrouvent dans les logs.
• Impact : combien de clients l'ont signalé, s'ils sont bloqués, et toute solution de contournement que vous avez trouvée.
• Ce que le support a déjà essayé : vider le cache, un autre navigateur, un autre compte.

Dans l'article CX de Linear, les bugs que son équipe support crée depuis Slack reprennent les mots exacts du client et un lien vers la conversation d'origine. Ajoutez les deux à vos rapports, vous aussi. La citation montre aux développeurs ce que le client a vu, avec ses propres mots.

Laissez les données personnelles de côté

Tout ce que vous collez dans Linear reste dans Linear. Quand un client vous demande plus tard de supprimer ses données, votre help desk ne peut pas atteindre cette copie.

Écrivez donc « un client avec l'abonnement annuel » plutôt qu'un nom, et laissez de côté les adresses e-mail, numéros de téléphone et numéros de commande dont les développeurs n'ont pas besoin. S'ils doivent regarder le compte, ils peuvent suivre le lien vers le ticket.

Un bug, une issue, plusieurs tickets

L'habitude la plus utile de tout ce guide : chaque ticket qui parle du même bug est lié à la même issue Linear. Les développeurs ont un seul endroit où travailler, et vous avez un seul endroit à surveiller quand le correctif arrive.

Laissez parler le nombre

Une issue avec 20 tickets liés plaide sa propre cause en réunion de planification. Demandez aux agents d'ajouter un court commentaire sur l'issue quand un nouveau signalement apporte quelque chose de nouveau, comme un autre navigateur ou un client complètement bloqué.

Évitez les commentaires qui disent seulement « +1 ». Le ticket lié compte déjà.

Les doublons qui passent quand même

Il y en aura. Dans Linear, un développeur marque une issue comme doublon de l'autre. Depuis mai 2026, l'issue reçoit alors son propre statut Duplicate, et Linear déplace ses pièces jointes et ses demandes clients vers l'issue d'origine, comme l'explique le changelog de Linear.

Quand vous voyez l'issue d'un ticket passer en Duplicate, liez aussi ce ticket à l'issue d'origine. Sinon, le ticket suit une issue sur laquelle plus personne ne travaillera.

Où arrivent les nouveaux signalements dans Linear

Une équipe Linear peut activer Triage, une boîte de réception spéciale pour cette équipe. Les issues créées par une intégration, ou par quelqu'un d'extérieur à l'équipe, y arrivent d'abord. Quelqu'un de l'équipe accepte, refuse, marque comme doublon ou reporte chacune d'elles.

Demandez à vos développeurs s'ils utilisent Triage et qui s'en occupe. Un rapport propre, avec l'impact en premier, est accepté plus vite.

Informer les clients sans recopier les mises à jour

Les clients n'ont pas besoin de chaque changement de statut. Ils ont besoin de savoir que vous avez confirmé le bug, que quelqu'un s'en occupe et que vous leur écrirez quand il sera corrigé.

Faire correspondre les statuts Linear au ticket

Les statuts par défaut de Linear sont Backlog, Todo, In Progress, Done et Canceled, et chaque équipe peut ajouter les siens. Une correspondance simple côté ticket :

• Triage, Backlog ou Todo : le ticket attend le développement. Mettez son SLA en pause, pour qu'il ne soit pas dépassé pendant que l'équipe technique travaille.
• In Progress : rien à dire au client pour l'instant.
• Done : le ticket revient à un agent, qui vérifie que le correctif est en ligne.
• Canceled ou Won't fix : l'agent écrit une réponse honnête, avec une solution de contournement s'il y en a une.
• Duplicate : liez le ticket à l'issue d'origine et continuez d'attendre.

Done ne veut pas toujours dire en ligne

Linear le dit clairement dans sa documentation sur les Releases : le statut Done d'une issue ne veut pas toujours dire que le correctif est arrivé chez vos clients. La pull request peut encore attendre en staging, ou un correctif mobile peut attendre la prochaine version de l'app.

La personne qui récupère le ticket vérifie donc le correctif en production, ou pose la question au développeur, avant d'écrire au client.

Combien de temps les clients peuvent attendre

Demandez leurs objectifs à vos développeurs et partagez-les avec votre équipe. Linear publie les siens dans un article sur sa politique zéro bug : 48 heures pour les bugs de haute priorité et 7 jours pour les autres.

Les chiffres de votre équipe seront différents. Ils aident les agents à annoncer des délais honnêtes, mais un objectif n'est pas une date à donner à un client.

Le message quand vous confirmez le bug

« Merci pour cette description très claire. Nous arrivons à reproduire le problème, et nos développeurs l'ont dans leur liste. Je vous écris ici dès que le correctif est en ligne, vous n'avez donc pas besoin de revenir vérifier. »

Ne donnez une date que si vos développeurs s'y sont engagés. Une date manquée coûte plus de confiance que pas de date du tout.

Le message le jour du correctif

« Bonne nouvelle : depuis ce matin, l'export CSV contient de nouveau toutes les lignes, même avec des filtres. Pourriez-vous réessayer et me dire si cela fonctionne pour vous ? Merci de nous l'avoir signalé, votre description nous a aidés à trouver le problème rapidement. »

Nommez le problème que le client a signalé et demandez-lui de confirmer. Une réponse du genre « ça marche maintenant » clôt vraiment le ticket.

Comment ça marche dans Deskwoot

Deskwoot est le help desk que nous développons. Une fois Linear connecté, les agents créent ou lient des issues depuis le ticket, et le statut de l'issue revient tout seul sur le ticket.

La configuration

1. Activez les tickets dans Paramètres > Tickets. Les tickets et Linear sont inclus dans le forfait Enterprise.
2. Cliquez sur Connecter Linear dans Paramètres > Intégrations > Linear. Il vous faut l'autorisation Gérer les intégrations.
3. Un admin de l'espace de travail Linear autorise Deskwoot et choisit les équipes qu'il peut voir. Choisissez ensuite l'Équipe pour les nouvelles issues.

Les agents n'ont pas besoin de compte Linear, car Deskwoot rejoint Linear en tant qu'app. Le guide d'aide Linear montre chaque étape.

Ce que vos agents y gagnent

• Créer ou lier depuis le ticket. Liez une issue par sa clé, comme ENG-123, ou cliquez sur Créer une issue. Rédiger un rapport de bug avec Copilot écrit le rapport. Copilot a pour consigne de laisser de côté le nom et les coordonnées du client, et l'agent vérifie le texte.
• Le statut sur le ticket. Chaque changement de statut ajoute une ligne dans chaque ticket lié. Une recherche par la clé trouve tous les tickets liés : votre liste pour le jour du correctif.
• 2 règles prêtes à l'emploi. L'une donne un statut au ticket quand une issue est créée ou liée, par exemple un statut qui met le SLA en pause. L'autre renvoie le ticket, avec une note, à la personne qui a lié l'issue dès que celle-ci est terminée.
• Bugs connus. Quand un client signale un problème, Copilot cherche dans les issues ouvertes de l'équipe pour les nouvelles issues et des équipes auxquelles vos tickets sont liés. Il a pour consigne de ne donner une date de correctif que si l'issue en contient une qui n'est pas encore passée.

Les clients ne voient jamais l'issue ni ses lignes de statut.

Ce que ça coûte

Enterprise coûte $12 par agent et par mois, ou $9.60 en facturation annuelle, donc 10 agents paient $120 par mois. Connecter Linear ne coûte rien de plus (voir les tarifs). Hacker, Startup et Business ne l'incluent pas, et chaque espace de travail Deskwoot se connecte à un seul espace de travail Linear.

Essayez sur un bug

Choisissez le bug ouvert qui a le plus de tickets derrière lui. Créez un compte, connectez Linear, liez ces tickets à son issue et enregistrez la règle prête à l'emploi pour les issues terminées. L'essai gratuit Enterprise de 7 jours ne demande pas de carte, couvre jusqu'à 30 sièges, le vôtre compris, et inclut Linear.