Nightwatch MCP + Linear : monter un pipeline “alert → ticket” sans noyer l’équipe (ni mentir au produit)

Un pipeline “alert → ticket”, c’est une bonne idée… jusqu’au jour où tu te retrouves avec une to-do list remplie de faux positifs, des tickets sans preuve, et un produit qui jure que “tout est rouge” alors que personne ne ressent rien.

Avec l’intégration Nightwatch MCP + Linear, tu peux automatiser la création de tickets à partir de signaux (erreurs, perfs, régressions). Mais si tu n’ajoutes pas des garde-fous, tu automatises surtout le bruit. Ici, je te donne une méthode concrète : quelles alertes méritent un ticket, comment regrouper/dédupliquer, quels champs imposer, et où garder un humain dans la boucle pour ne pas transformer Linear en poubelle à notifications.

Pourquoi “alert → ticket” échoue presque toujours

Ce qui tue ces pipelines n’est pas la technique. C’est l’absence de contrat.

• Tout est urgent : donc plus rien ne l’est. Si chaque spike crée un ticket, tu désensibilises l’équipe.
• Tickets sans contexte : “Erreur 500” ne sert à rien si tu n’as ni route, ni release, ni fréquence, ni impact.
• Pas d’ownership : un ticket sans propriétaire réel, c’est un ticket qui pourrit.
• Pas de preuve côté utilisateur : sans RUM/impact réel, tu risques d’optimiser un chiffre, pas l’expérience.
• Pas de dédup : un incident = 40 tickets = personne ne lit.

Donc la question n’est pas “comment créer des tickets automatiquement ?”. La question est : comment créer des tickets qui ont une chance d’être traités.

Ce que l’intégration Nightwatch MCP + Linear te permet (et ce qu’elle ne doit pas faire)

L’idée (très saine) : Nightwatch détecte des signaux, et via MCP tu peux les transformer en actions dans Linear. En pratique, ça doit produire :

• des tickets déjà triés (pas “raw alerts”)
• des tickets avec preuve (liens Nightwatch, métriques, fenêtres temporelles)
• des tickets routés (équipe, label, priorité, owner ou rotation)
• des tickets regroupés (un incident = un ticket vivant)

Ce que ça ne doit pas faire : remplacer ta stratégie produit. Un ticket automatique ne doit jamais “décider” de la priorité. Il doit proposer, avec des critères explicites.

Étape 1 : définir “ticket-worthy” (sinon tu vas spammer Linear)

Tu veux une règle simple : une alerte devient un ticket seulement si elle dépasse un seuil ET si elle a un impact plausible. Voilà une grille qui marche bien.

Les signaux qui méritent (souvent) un ticket

• Erreurs serveur : hausse durable d’un type d’erreur (même signature) au-dessus d’un seuil (volume + %).
• Régressions perf post-release : dégradation qui commence après un déploiement identifié.
• Endpoints business critiques : checkout, login, paiement, onboarding, recherche… (définis une liste courte).
• Budget perf dépassé : SLO/SLI cassé sur une fenêtre (pas un pic de 3 minutes).

Les signaux qui ne doivent pas créer de ticket par défaut

• Spikes isolés (trafic bot, job batch, partenaire qui martèle une API)
• Erreurs sans utilisateurs (environnements non-prod, routes admin internes, robots)
• Alertes sans “delta” : si c’est dégradé depuis 6 mois, ce n’est pas un incident, c’est de la dette (à traiter autrement).

Règle d’or : “durée” + “delta” + “surface”

Si tu ne devais garder qu’une règle de triage :

• Durée : ça dure assez longtemps pour être réel (ex. 15–30 min).
• Delta : c’est une vraie rupture vs baseline (ex. +30% vs moyenne 7 jours).
• Surface : ça touche un parcours important ou un volume d’utilisateurs significatif.

Étape 2 : dédupliquer et regrouper (un incident = un ticket)

La plupart des outils te balancent des alertes “par symptôme”. Toi, tu veux un ticket “par problème”. Concrètement, tu as besoin d’une clé de regroupement stable.

Exemples de clés efficaces :

• Erreur : {env}:{exception_class}:{top_frame}:{route_group}
• Perf endpoint : {env}:{method}:{route}:{metric_name}
• Job : {env}:{queue}:{job_class}

Et tu appliques deux comportements :

• Si un ticket “ouvert” existe déjà pour cette clé → tu commentes/updates (nouvelle occurrence, nouveaux chiffres, nouvelle release).
• Si aucun ticket → tu crées un nouveau ticket avec un template strict.

Étape 3 : imposer des champs obligatoires (sinon c’est du vent)

Un ticket auto doit être actionnable sans chasse au trésor. Donc tu imposes une structure, toujours la même.

Les champs minimum que je veux voir

• Preuve : lien direct vers Nightwatch (graph/trace/logs) + fenêtre temporelle.
• Impact : utilisateurs affectés (ou requêtes), % de trafic, parcours concerné.
• Déclencheur suspect : release/version, feature flag, migration, changement infra (si détectable).
• Scope : env, région, endpoint(s), template/page si front.
• Confiance : “élevée / moyenne / faible” (oui, assume l’incertitude).

Astuce simple : “pas de preuve = pas de ticket”

Ça peut sembler violent, mais c’est un excellent filtre. Si l’alerte ne sait pas pointer une vue exploitable, alors elle doit passer en review humaine, pas en “todo” d’équipe.

Étape 4 : routing et ownership (le ticket doit tomber chez la bonne personne)

Créer un ticket est facile. Le faire arriver au bon endroit, c’est là que ça devient utile.

• 1 équipe par type de signal : API/perf backend, frontend web perf, data/queues, etc.
• Rotation : si c’est incident/perf critique, route vers une rotation (on-call light) plutôt que “tout le monde”.
• Labels cohérents : nightwatch, perf, errors, regression, needs-triage.
• Priorité : calculée par règles (impact x durée x criticité du parcours), mais validée humainement si tu veux éviter le “tout P1”.

Étape 5 : garder un humain dans la boucle (sans casser l’automatisation)

Le compromis qui marche : deux modes.

Mode A — Auto-création (quand tu es sûr)

Uniquement pour des alertes très fiables (ex. taux d’erreur sur checkout, crash rate, SLO cassé sur endpoint critique).

• création directe d’un ticket
• assign à la rotation
• priorité calculée

Mode B — Auto-proposition (quand tu n’es pas sûr)

Pour le bruit potentiel (spikes, nouveaux signaux, zones grises), tu crées soit :

• un ticket dans une queue “Triage” (équipe Observabilité/Tech Lead)
• ou un commentaire sur un ticket existant “tracking”

Le but : un humain clique “valider” pour promouvoir en vrai ticket d’équipe. Tu automatises la collecte de contexte, pas la décision finale.

Exemple de template Linear (simple, mais non négociable)

Tu peux standardiser la description envoyée à Linear. Voilà une version efficace (à adapter à ton vocabulaire).

{
  "title": "[Nightwatch] Erreurs 500 en hausse sur POST /checkout",
  "labels": ["nightwatch", "errors", "regression"],
  "priority": "P1",
  "description": "## Résumé\nHausse d'erreurs 500 détectée sur POST /checkout sur 30 min.\n\n## Preuves\n- Nightwatch: https://… (graph + logs)\n- Fenêtre: 2026-03-11 10:00 → 10:30 UTC\n\n## Impact\n- Requêtes affectées: 2 340\n- % du trafic checkout: 38%\n- Utilisateurs estimés: ~620\n\n## Contexte\n- Env: production\n- Release suspecte: 2026.03.11.1\n- Corrélation: début 3 min après déploiement\n\n## Hypothèses\n- Middleware X\n- Timeout service Y\n\n## Next step (triage)\n- Confirmer la signature principale\n- Identifier top endpoint / top exception\n- Rollback si la corrélation release est forte"
}

Important : un template n’est pas “de la paperasse”. C’est ce qui évite le ticket “à moitié vrai” qui coûte 45 minutes de contexte à chaque fois.

Implémentation : une stratégie de règles avant la tuyauterie

Avant de brancher Nightwatch → MCP → Linear, écris tes règles. Même dans un fichier YAML interne. Tu veux pouvoir relire, discuter, modifier.

rules:
  - name: checkout_error_rate
    when:
      signal: http_error_rate
      route: "POST /checkout"
      window_minutes: 30
      threshold:
        error_rate_pct: 2
        min_requests: 500
    grouping_key: "prod:POST:/checkout:5xx"
    mode: "auto_create"
    linear:
      team: "Core"
      labels: ["nightwatch", "errors", "checkout"]
      priority: "P1"

  - name: perf_regression_generic
    when:
      signal: p95_latency
      window_minutes: 60
      threshold:
        delta_pct_vs_7d: 30
        min_requests: 1000
    grouping_key: "prod:${method}:${route}:p95"
    mode: "needs_triage"
    linear:
      team: "Observability"
      labels: ["nightwatch", "perf", "needs-triage"]
      priority: "P3"

Le garde-fou que tout le monde oublie : la “preuve produit”

Si tu veux “ne pas mentir au produit”, il te faut une règle : on ne vend pas une régression technique comme une catastrophe utilisateur sans signal utilisateur.

Concrètement, tu ajoutes un champ dans le ticket :

• RUM impact : métriques front (LCP/INP/CLS), taux d’abandon, taux de conversion, ou au minimum un proxy fiable.
• Sinon : le ticket est tagué needs-product-impact et reste en priorité basse tant que personne n’a confirmé l’impact.

Ça n’empêche pas de traiter des problèmes techniques sérieux. Ça empêche juste de raconter n’importe quoi en réunion.

Rollout sans drama : commence petit, mesure, puis élargis

• Semaine 1 : un seul flux (ex. erreurs 5xx sur 2 routes critiques) + dédup + template strict.
• Semaine 2 : ajout du mode “needs-triage” pour le reste (pas d’auto-création).
• Semaine 3 : routing fin par équipe + rotation + SLA interne.
• Semaine 4 : budget perf / SLO + lien release + auto-update de ticket existant.

Checklist rapide (si tu veux un pipeline qui survit au réel)

• Une alerte ne crée un ticket que si durée + delta + surface sont vrais.
• Un incident = un ticket (clé de regroupement + update/comment au lieu de créer).
• Pas de ticket sans preuve (lien Nightwatch + fenêtre + chiffres).
• Ownership explicite : équipe + labels + priorité + rotation.
• Deux modes : auto-create (signaux fiables) et needs-triage (zone grise).
• Un champ “impact produit” pour ne pas transformer l’observabilité en storytelling.

Mon avis (sec) : l’automatisation utile, c’est de la contrainte

Si ton pipeline se contente de “copier une alerte dans Linear”, tu vas le couper au bout de deux semaines. La valeur de Nightwatch MCP + Linear, c’est de te permettre de pousser des tickets déjà cadrés : regroupés, prouvés, routés, et priorisés avec des règles discutables (donc discutées).

Automatise la collecte et la mise en forme. Garde la décision finale là où elle doit rester : dans une équipe qui assume ses priorités.

Sources

• Laravel February Product Updates (Nightwatch MCP & Linear integration)