Classer les tickets Jira avec l’IA : étiqueter automatiquement les work items avec Jira Automation et Jev

Jira Cloud appelle désormais les tickets des work items et les projets des spaces ; la documentation d’automatisation emploie ces noms, mais les smart values commencent toujours par issue. Les équipes qui reçoivent des demandes de nombreuses personnes, via un service desk, un formulaire d’entrée ou des collègues qui créent directement des tickets, passent du temps sur la même première étape : lire chaque nouveau work item et décider de quel type de travail il s’agit. Classer automatise cette étape avec un label tiré d’une liste courte et fixe, par exemple bug, feature_request, question ou other, pour qu’un filtre de tableau, une file ou la règle suivante le prenne en charge. Séparez cette catégorie d’une seconde question qui compte souvent autant : le texte dit-il que quelqu’un est bloqué maintenant ? Posez-la en oui/non indépendant, pas en label, et servez-vous-en pour ajouter un commentaire ou prévenir quelqu’un, pas pour changer la priorité avant d’avoir mesuré sa fiabilité. Commencez par des labels, peu coûteux à ajouter et faciles à retirer ; changer le type de travail, le responsable ou le statut touche aux workflows et aux rapports, où une erreur automatique coûte cher. Si vos tickets vivent dans GitHub plutôt que Jira, le guide d’étiquetage des issues GitHub décrit la même idée avec GitHub Actions.

Six composants. 1) Déclencheur : Work item created, éventuellement limité par JQL aux types de travail à classer. 2) Action : Re-fetch work item data, pour charger les champs remplis à la création avant de construire la requête ; Jira ne rafraîchit pas seul les données {{issue}} pendant une exécution. 3) Action : Send web request vers https://jevmodel.app/api/v1/systemone en POST, avec un en-tête Content-Type: application/json, un en-tête Authorization avec Bearer et une clé créée dans JevModel Console → API keys depuis un compte vérifié (cochez Hidden pour masquer la valeur après enregistrement), et Custom data comme corps. Cochez « Delay execution of subsequent rule actions until we’ve received a response for this web request », et aussi « Continue running the rule even if the request response is not successful » si la branche de repli doit s’exécuter quand l’API renvoie un statut d’erreur. 4) Bloc if/else avec une condition de comparaison avancée : {{webResponse.body.code}} égale 0. 5) Dans la branche if, Edit work item avec le champ Labels dans le JSON des champs supplémentaires, en ajoutant ai- suivi du label choisi ; une seconde condition sur la réponse oui/non peut ajouter un commentaire. 6) Dans la branche else, ajoutez le label needs-triage. Les labels Jira ne peuvent pas contenir d’espaces, une raison de plus pour des ID comme feature_request.

Quatre problèmes expliquent la plupart des règles en échec. Valeurs de réponse vides : la base de connaissances d’Atlassian cite comme causes courantes l’option d’attente de réponse non cochée, la lecture de la réponse hors du bloc if où la requête a été envoyée, et une réponse dont le Content-Type n’est pas application/json ; JevModel renvoie du JSON, ce sont donc les deux premières à vérifier. JSON cassé : un résumé avec des guillemets ou une description avec des retours à la ligne donnent un JSON invalide s’ils sont collés bruts ; entourez chaque valeur d’asJsonString, qui échappe les caractères spéciaux et ajoute les guillemets. Si la description peut être vide, ajoutez une condition « non vide » ou n’envoyez que le résumé. Taille : la requête JevModel entière, state plus questions, doit tenir en 8 000 caractères ; utilisez abbreviate sur la description (l’exemple garde 5 000 caractères). Exécutions répétées : JevModel n’a pas de clé d’idempotence, donc une règle sur Work item updated enverrait une nouvelle requête facturée à chaque modification et pourrait empiler des labels après une correction humaine ; ne déclenchez qu’à la création. Deux points de gouvernance comptent autant. Atlassian avertit que quiconque peut modifier une règle peut reconfigurer une action Send web request pour envoyer les données ailleurs : limitez les éditeurs. Les valeurs Hidden des en-têtes sont perdues quand la règle ou l’action est dupliquée, exportée ou importée : ressaisissez alors la clé. N’envoyez que le résumé et la description, ni noms ni e-mails du rapporteur.

Jira Automation propose aussi l’action Use Rovo agent, qui demande à un agent de générer une réponse à transmettre ensuite à une action à sortie texte, comme un commentaire. Le tableau compare la forme de chaque voie telle que documentée, pas la précision, et aucune ligne n’est un benchmark.

Les règles se construisent dans l’éditeur de règles ; l’exemple montre donc chaque composant en texte avec les valeurs à coller. La requête suit le contrat documenté de JevModel : POST /api/v1/systemone avec une clé Bearer d’un compte vérifié, un state et des questions nommées, ici un Choice nommé kind et un Noul nommé blocking ; une réponse réussie a code 0 et data.answers. Pas de champ model, car le site appelle toujours typesafe/jev-1.13 via OpenRouter ; JevModel est indépendant de TypeSafe AI, qui développe Jev. Le préfixe ai- rend les labels automatiques faciles à repérer et à retirer. Les smart values Jira se prêtent mal à la lecture d’une probabilité par clé dynamique : cette règle applique le label et laisse le contrôle des probabilités à votre échantillon de test ; pour un seuil par label, ajoutez une condition par label sur {{webResponse.body.data.answers.kind.probabilities.bug}} et ses équivalents. Le 0,8 de blocking est une valeur d’attente, pas une recommandation. Pendant les tests, utilisez une action Log avec {{webResponse.body}} et lisez le journal d’audit de la règle.

# Illustrative only. Jira Cloud automation rule, written out component by component.
# Trigger:  Work item created            (optional JQL: type in (Bug, Task, Story))
# Action:   Re-fetch work item data
# Action:   Send web request
#   Web request URL:  https://jevmodel.app/api/v1/systemone
#   HTTP method:      POST
#   Headers:          Content-Type = application/json
#                     Authorization = Bearer <your JevModel key>   [x] Hidden
#   Web request body: Custom data
#   [x] Delay execution of subsequent rule actions until we've received a response
#   [x] Continue running the rule even if the request response is not successful
{
  "state": {
    "summary": {{issue.summary.asJsonString}},
    "description": {{issue.description.abbreviate(5000).asJsonString}}
  },
  "questions": {
    "kind": {
      "type": "choice",
      "instructions": "Which kind of work item is this, based on its summary and description?",
      "criteria": {
        "bug": "Something that used to work is broken, slow, or shows an error.",
        "feature_request": "Asks for new behavior the product does not have yet.",
        "question": "Asks how to do something; nothing is broken.",
        "other": "Anything that fits none of the labels above."
      }
    },
    "blocking": {
      "type": "noul",
      "instructions": "Does the text say that users, customers, or a release are blocked right now?",
      "criteria": {
        "true": "Someone cannot continue their work until this is resolved.",
        "false": "Work can continue while this waits in the backlog."
      }
    }
  }
}
# If:  Advanced compare  {{webResponse.body.code}}  equals  0
#   Action: Edit work item → More options → Additional fields:
{ "update": { "labels": [ { "add": "ai-{{webResponse.body.data.answers.kind.choice}}" } ] } }
#   If:  Advanced compare  {{webResponse.body.data.answers.blocking.noul}}  greater than  0.8   (placeholder)
#     Action: Comment on work item: "Automatic check: this may be blocking someone. Please confirm."
# Else:
#   Action: Edit work item → Additional fields:
{ "update": { "labels": [ { "add": "needs-triage" } ] } }

Vos work items résolus forment un jeu étiqueté tout prêt : leur type, leurs composants ou leurs labels ont été fixés par des personnes. Exportez-en quelques centaines avec un filtre JQL, par exemple les work items résolus du dernier trimestre, gardez résumé, description et catégorie humaine, puis passez le texte dans JevModel Console → Batch avec la même question Choice. Batch renvoie des réponses par ligne sans calculer la précision : joignez-les à la colonne humaine dans un tableur. Vérifiez l’accord par label, les paires confondues (bug et question se mélangent souvent quand le rapporteur décrit une erreur d’usage comme un bug) et la fréquence de blocking vrai sur des work items qui n’étaient pas urgents. Réécrivez les définitions floues et relancez le même échantillon. Activez ensuite la règle sur un seul space, lisez le journal d’audit pendant une semaine et comptez combien de labels ai- sont retirés. Les anciennes catégories ont été posées dans l’urgence ; lisez quelques désaccords avant d’accuser le modèle. N’ajoutez des changements de responsable ou de priorité qu’après, et gardez-les réversibles.

Choisissez Send web request plus Jev quand vous voulez des labels tirés d’une liste que vous maîtrisez, fiables pour les filtres, tableaux et règles suivantes, et que vous pouvez maintenir une règle avec un corps JSON. Choisissez une action d’agent Rovo quand l’objectif est un résumé ou une suggestion générés, lus par une personne dans un commentaire. Choisissez l’export CSV et Console → Batch pour tester les définitions ou étiqueter un existant ponctuel sans toucher à Jira. Si les demandes arrivent sous forme de tickets Zendesk, de messages Slack ou d’issues GitHub, des guides dédiés couvrent ces sources. Checklist commune : 1) définitions de labels avec un other explicite ; 2) urgence posée à part en oui/non ; 3) déclenchement à la création seulement, JevModel n’ayant pas de clé d’idempotence ; 4) n’envoyer que résumé et description, abrégés sous la limite de 8 000 caractères ; 5) limiter les éditeurs de la règle et garder la clé dans un en-tête Hidden ; 6) commencer par des labels ai- et un repli needs-triage, et n’élargir la règle qu’après avoir mesuré l’accord sur des work items résolus. JevModel est limité au texte et n’est pas open source ; captures, pièces jointes et journaux attachés à un work item ne sont pas classés par cette règle.