Jira Ticket Quality Bot
Un bot qui verifie les tickets Jira avant qu'ils arrivent aux devs.
Le probleme
Les tickets arrivent a l'equipe tech incomplets ou trop verbeux. On passe du temps chaque sprint a poser des questions de clarification.
"Il faudrait un systeme d'alerting pour nous avertir quand le volume de QPS par Endpoint est atteint. Merci !"
→ 4 versions, 11 jours, 3 allers-retours pour avoir les infos necessaires.
Autre pattern : le metier dit "cree-moi un dashboard" au lieu de decrire le besoin. Quand on creuse, un log suffit souvent.
Comment ca marche
1. Analyse automatique
Un nouveau ticket est cree → le bot le score sur via la grille de scoring.
S'il manque des infos, le bot met a jour la description du ticket avec ce qu'il a compris et les questions. Le createur est @mentionne.
- Titre prefixe / /
- Panel colore dans la description
- Statut → "Attente Informations"
- Label
bot:rouge/bot:orange/bot:vert
2. Le metier repond
Le createur repond aux questions en commentaire — pas forcement a tout. Le bot accepte les reponses partielles.
3. Re-analyse
Le bot re-score et met a jour la description. C'est un document vivant : toujours a jour. Le score monte progressivement. La decide quel LLM utiliser.
4. Ticket pret → reecrit pour la tech
Score >= 14/20 : le bot reecrit la description. L'original et l'historique sont replies en bas.
- Sections : Contexte, Besoin, Gestion actuelle, Perimetre, Criteres de succes
- Statut → "To Do" = prenable par un dev
Boucle iterative en action
Exemple reel sur SP-3780 — "Voir les revenus par pays. Merci !"
Ce que j'ai compris : vous voulez voir les revenus par pays.
1. C'est pour quel usage concret ?
2. Comment vous obtenez cette info aujourd'hui ?
3. Pour quels editeurs / pays ?
"C'est pour les QBR avec les editeurs internationaux. Ils veulent savoir combien ils generent par pays, surtout FR, UK, DE, US."
Compris : QBR editeurs, split par pays. Il manque :
1. Comment c'est fait aujourd'hui ?
2. A quelle frequence et par qui ?
"Sophie fait une requete SQL a la main, 30 min par editeur, 4-5 fois par mois."
Toutes les infos sont la. Ticket reecrit :
Besoin : split revenus par pays (FR, UK, DE, US)
Gestion actuelle : requete SQL manuelle, 30 min/editeur, Sophie
Frequence : 4-5 fois/mois
Grille de scoring
Chaque ticket est score sur 20 points :
Detection de solution prescrite (D3)
Le bot detecte quand le ticket decrit comment faire au lieu de pourquoi le faire. Ce n'est pas un rejet — c'est une question pour extraire le vrai besoin.
"Creer une page admin avec un tableau editable pour configurer les timeouts par partenaire"
"Certains partenaires sont lents, on veut ajuster les timeouts sans passer par un dev. Ca arrive 2-3 fois/mois."
Le metier a souvent de bonnes idees — le bot aide a les exprimer sous forme de besoin pour que la tech propose la solution optimale (parfois plus simple que prevu).
Cascade de modeles
Pourquoi payer un gros modele quand un petit suffit ? Clique un scenario pour voir le chemin.
Le petit modele score le ticket. Rapide, pas cher. Il suffit pour les cas evidents.
Ticket quasi vide. Nano suffit — meme un gros modele dirait pareil.
Ambigu. Le petit modele hesite, surtout sur la .
Ticket avec toutes les infos. Nano suffit — tout le monde est d'accord.
Appele uniquement pour la zone grise (~30-40% des tickets). Re-score avec precision, detecte les .
Tickets de demo
4 scenarios joues sur de vrais tickets Jira. Clique pour voir les etapes.
Avant / Apres
Aujourd'hui
- Ticket sommaire arrive dans le sprint
- Le dev ouvre le ticket lundi matin, ne comprend pas
- Allers-retours mails/Slack
- 3-11 jours pour avoir les infos
- Le dev fait des suppositions
Avec le bot
- Ticket score a la creation
- Le metier repond avant le sprint
- 1-3 iterations en quelques heures
- Le dev ouvre un ticket complet
- Zero question a poser
Architecture technique
Prochaines etapes
Dry Run — Vrais tickets
10 tickets SP reels scores le 31 mars 2026. Aucun commentaire poste — observation pure.