Aller au contenu principal

Trier et assigner automatiquement les bugs par gravité

À la fin de cette recette, chaque bug qui atterrit dans votre tracker est labellisé par gravité, tagué vers la bonne zone, assigné à un responsable, mis à l'horloge avec un SLA, et — s'il est Critical — escaladé vers votre équipe, le tout en secondes et sans que personne lève le petit doigt. Le tri est la taxe que chaque équipe engineering paie sur les bugs entrants ; parce que vos reports, board et équipe vivent dans un seul espace de travail, une Automation peut lire chaque nouveau bug et faire le routage pour vous.

Disponibilité : Disponible maintenant (construite comme une Automation). La version où un coéquipier nommé « Triage Lead » surveille le board et labellise et assigne les bugs sous sa propre identité arrive en accès anticipé.

Ce qu'elle fait​

Une seule automation siège sur votre board Bugs et se déclenche dès qu'un nouveau bug arrive — depuis un formulaire, un e-mail, un error tracker, ou un collègue qui le saisit à la main. Pour chacun elle :

  1. Classifie la gravité — lit le titre et la description et le labellise Critical, High, Medium ou Low selon des définitions que vous fixez.
  2. Identifie la zone — classifie quelle partie du produit le bug touche (Frontend, Backend, Payments, Mobile…) pour qu'il puisse être routé.
  3. Assigne le responsable — branche sur cette zone et met la bonne personne sur la ligne.
  4. Démarre le SLA — lance un timer de réponse, plus serré pour une gravité plus haute, pour que rien ne vieillisse silencieusement.
  5. Notifie et escalade — pingue le responsable assigné, et page votre canal engineering immédiatement pour tout Critical.
  6. Le marque Triaged — bascule le statut pour que l'équipe voie d'un coup d'œil que le bug a été traité.

Le résultat : un report brut et désordonné devient un ticket labellisé, porté et à l'horloge avant qu'un humain l'ouvre — et une personne peut encore overrider n'importe quoi.

Construisez-la vous-même​

Configuration unique​

Créer le board Bugs

Créez un board avec une table pour les bugs. Ajoutez des colonnes pour Title, Description (rich text), Severity (single-select : Critical, High, Medium, Low), Area (single-select pour vos zones produit ou équipes), Owner (people), Status (New, Triaged, In Progress, Done), Environment, et une colonne SLA. Ce board est à la fois votre file de tri et votre archive de bugs.

Router chaque intake vers une ligne

Quelle que soit la façon dont les bugs vous atteignent, faites-les atterrir tous comme lignes dans cette table pour qu'une seule automation de tri les couvre. Chemins d'intake réels, tous construits à partir de déclencheurs standards :

  • Un formulaire de report de bug public sur la table (un déclencheur Form submitted qui crée la ligne).
  • Un déclencheur Email received / Gmail received sur votre inbox de bugs qui crée la ligne.
  • Un déclencheur Inbound webhook received alimenté par votre error tracker ou outil de monitoring.

Parce que l'automation de tri ci-dessous se déclenche sur Row created, vous construisez la logique de tri une fois et chaque chemin d'intake l'hérite.

L'automation de tri​

Déclencheur : Row created

Ajoutez un déclencheur Row created sur la table Bugs. Il se déclenche pour chaque nouveau bug, peu importe comment il est arrivé.

Étape IA : Classifier la gravité

Ajoutez une étape AI → Classify qui lit le titre et la description du bug et le trie dans vos libellés de gravité (Critical, High, Medium, Low). Énoncez ce que chaque libellé signifie dans l'étape pour que l'IA colle à la barre de votre équipe — par exemple, Critical = data loss or a full outage.

Étape IA : Classifier la zone

Ajoutez une seconde étape AI → Classify pour labelliser la Area affectée (Frontend, Backend, Payments…). C'est le champ sur lequel vous routerez. Vous voulez plus de structure ? Ajoutez une étape AI → Extract pour tirer l'environment, la version de l'app, et les steps to reproduce du report en texte libre dans leurs propres colonnes.

Action : Définir les champs

Ajoutez des actions Set field pour écrire Severity et Area (et tout détail extrait) sur la ligne déclenchante, pour que les libellés soient visibles dans chaque vue et utilisables par les étapes suivantes.

Condition + Action : Assigner le responsable

Ajoutez une condition Compare sur Area et, sur chaque branche, une action Assign user(s) qui ajoute le responsable de cette zone à la colonne Owner — Frontend → Alex, Backend → Sam, Payments → Jordan. Ajoutez une branche par zone ou équipe vers laquelle vous routez.

Action : Démarrer le timer SLA

Ajoutez une action SLA timer control pour démarrer l'horloge sur la ligne. Définissez les cibles de réponse réelles par gravité sur la politique SLA du board — Critical obtient la deadline la plus serrée — pour que le timer que vous démarrez ici compte à rebours contre la bonne cible.

Condition + Action : Notifier et escalader

Ajoutez une condition Compare sur Severity. Sur la branche Critical, ajoutez une action Post channel message qui page votre canal engineering avec le titre et le lien du bug. Sur l'autre branche, ajoutez une action Send notification au responsable assigné. Tout le monde entend parler de ce qui compte, au volume qu'il mérite.

Action : Status → Triaged

Terminez avec une action Set field qui passe Status à Triaged, pour que l'équipe voie que le bug a déjà été labellisé, porté, et mis à l'horloge.

Ou demandez simplement à Copera AI​

Vous n'avez pas à poser le graphe à la main. Ouvrez Ask Copera AI et décrivez le tout :

« Crée un board Bugs avec des colonnes pour titre, description, gravité (Critical, High, Medium, Low), zone, responsable, statut, environnement et un SLA. Puis construis une automation : quand une nouvelle ligne est créée, classifie la gravité du bug et sa zone, définis les deux champs, assigne le responsable de la zone, démarre le timer SLA, notifie le responsable, et poste tout bug Critical sur le canal #engineering. »

Ask Copera AI peut créer le board et ses colonnes, puis assembler l'automation — déclencheur, classification IA, conditions et actions — pour vous. Avec le mode de permission par défaut Demander avant d'agir, il montre une carte de relecture pour chaque changement avant création, pour que vous approuviez le board et l'automation avant qu'ils existent. Voir Ce que Copera AI peut faire pour la liste complète de ce qu'il peut construire.

En faire un coéquipier permanent​

Confiez le board Bugs à un Triage Lead nommé et il peut lire chaque nouveau bug, le labelliser par gravité et zone, assigner le bon responsable, et poster un coup de pouce dans votre canal engineering — selon son propre planning et sous sa propre identité, sans graphe d'automation à maintenir.

Accès anticipé

Les coéquipiers IA sont déployés progressivement. Si vous ne les voyez pas encore dans votre espace de travail, ils arrivent — tout ce guide peut être construit dès aujourd'hui comme une Automation. En savoir plus sur les AI teammates.

Conseils​

astuce

Déclenchez sur Row created, pas sur le formulaire. Une seule automation de tri couvre alors chaque chemin d'intake — formulaire, e-mail et webhook d'error tracker — parce qu'ils créent tous une ligne. Construisez le routage une fois au lieu de le dupliquer par source.

astuce

Donnez au classifieur des définitions nettes. Dans l'étape Classify, énonciez exactement ce qui sépare Critical de High (par ex. Critical = data loss or full outage; High = major feature broken with no workaround). Des libellés nets font coller les appels de l'IA à la façon dont votre équipe trie réellement.

astuce

Laissez les humains overrider, et gardez la boucle visible. L'automation fixe un point de départ, pas un verdict — les ingénieurs peuvent relabelliser la gravité ou réassigner à tout moment. Passer le statut à Triaged rend évident quels bugs ont été traités et lesquels sont encore bruts.

astuce

Étagez le SLA par gravité, puis laissez un chien de garde chasser les violations. Configurez des cibles plus serrées pour Critical sur la politique SLA du board, et couplez cette recette avec le chien de garde de violation de SLA pour que rien ne reste au-delà de sa deadline sans être remarqué.

astuce

Fixez un plafond de dépense. Les étapes classify et extract tirent sur l'usage IA à chaque nouveau bug, donc donnez à l'automation un plafond de dépense par automation. Un déluge soudain de reports ne dépassera jamais un budget que vous choisissez, et le tableau de bord d'usage montre exactement où sont allés les crédits.

Questions fréquentes​

Copera peut-il assigner automatiquement les bugs entrants à la bonne personne ?​

Oui. L'automation se déclenche quand une nouvelle ligne de bug est créée, classifie sa gravité et sa zone affectée avec l'IA, puis branche sur la zone et lance une action Assign user(s) pour mettre le responsable de cette zone sur la ligne. Elle peut démarrer un timer SLA et notifier le responsable dans la même exécution.

Comment Copera décide-t-il de la gravité d'un bug ?​

Une étape AI Classify lit le titre et la description du bug et le trie dans les libellés de gravité que vous définissez (par exemple Critical, High, Medium, Low). Une action Set field écrit ce libellé sur la ligne. Vous contrôlez les libellés et ce que chacun signifie, pour que le résultat colle aux définitions de votre équipe.

Les bugs peuvent-ils arriver depuis un formulaire, un e-mail ou un error tracker ?​

Oui. Un formulaire de report de bug public, un déclencheur Email received / Gmail received, ou un déclencheur Inbound webhook received depuis votre error tracker peuvent chacun créer la ligne de bug. Parce que le tri tourne sur Row created, une automation couvre chaque chemin d'intake.

Un humain relit-il encore les bugs triés par l'IA ?​

Oui. L'automation labellise, route et assigne comme point de départ, mais les ingénieurs peuvent overrider n'importe quel champ — relabelliser la gravité ou réassigner le responsable — quand ils le souhaitent. Définir le statut sur Triaged montre qu'un bug a été traité, et l'automation ne supprime jamais rien.

Peut-elle escalader les bugs Critical immédiatement ?​

Oui. Une condition branche sur la gravité : les bugs Critical postent un message de canal sur votre canal engineering pour pager l'ingénieur d'astreinte, tandis que les bugs de plus basse gravité envoient simplement une notification in-app au responsable assigné.

Voir aussi​