Automatisations du backlog (façon Jira Automation)

Doc fonctionnelle : décrit le quoi et le pourquoi (point de vue utilisateur / chef de projet).

À quoi ça sert

On veut créer des règles d'automatisation sur le backlog, façon Jira Automation : « QUAND un événement se produit (changement de statut, assignation, plus tard un label de PR / un merge), SI une condition est remplie, ALORS exécuter des actions (changer le statut, assigner, notifier) ». Les statuts existants du backlog ne changent pas ; on automatise les actions autour d'eux. Le socle prépare la synchronisation GitHub à venir (déclencheurs déjà configurables).

Comment ça marche (côté utilisateur)

Onglet « Workflow » d'un projet. Le builder reprend le modèle Jira Automation : une liste de règles par projet, chacune éditée dans un flow vertical.

Activation par projet : les onglets « Workflow » et « Revue de PR » sont désactivés par défaut. On les active projet par projet via l'interrupteur « GitHub & Workflow » dans l'onglet Paramètres du projet.

Deux onglets « Liste » / « Diagramme » permettent de changer de vue (le bouton « Créer une règle » reste accessible dans les deux).

1. Liste des règles : chaque règle affiche son déclencheur, ses conditions et ses actions ; on peut l'activer/désactiver, l'éditer, la supprimer. Bouton « Créer une règle ».
2. Diagramme (façon éditeur de workflow Jira) : un canvas interactif montre les statuts du backlog en nœuds et les règles « Changer le statut » en flèches entre eux (label = nom de la règle + déclencheur).
   • Navigation (tout le monde) : molette = zoom (40 % à 200 %), glisser le fond = déplacer la vue ; la barre d'outils propose zoom −/+, le pourcentage courant et « Recentrer » (cadre tout le diagramme dans la vue). Cliquer un statut met en évidence ses transitions entrantes/sortantes (re-clic pour annuler).
   • Réorganisation (éditeurs) : on glisse les statuts librement sur le canvas (les flèches suivent en direct) et on glisse les labels de flèches pour les décaler quand ils se chevauchent. La disposition est enregistrée au lâcher et partagée par tous les utilisateurs du projet (comme dans Jira). Le bouton « Layout auto » (avec confirmation) revient à la disposition automatique.
   • Créer une transition au drag (éditeurs) : au survol d'un statut, une poignée + apparaît sur son flanc droit ; on la tire vers un autre statut (ou le même, pour une boucle) et l'éditeur s'ouvre pré-rempli — condition « statut d'arrivée = statut source » (aucune condition si on part de « Tout statut ») et action « Changer le statut » vers la cible. Il ne reste qu'à choisir le déclencheur et enregistrer.
   • Cliquer une flèche (ou son label) ouvre l'édition de la règle (si on a le droit d'édition) ; le retour ramène au diagramme.
   • Les règles inactives sont en pointillé ; une règle sans condition de statut part du nœud « Tout statut ». Une règle sans action « Changer le statut » mais conditionnée par une transition de statut (ex. « si statut A tester → À retravailler, notifier / poser un label ») est dessinée comme une flèche départ → arrivée (borne manquante = « Tout statut ») : elle « écoute » cette transition. Seules les règles sans action « Changer le statut » ni condition de statut (notification pure sur assignation, règle GitHub à condition de label…) ne peuvent pas être représentées par une flèche et sont listées sous le canvas en pastilles cliquables.
   • Lisibilité : les flèches sont droites entre cartes alignées et en courbe douce sinon (sortie et arrivée perpendiculaires aux bords des cartes) ; leurs points d'ancrage s'espacent sur les bords quand plusieurs flèches partent ou arrivent du même côté, et les étiquettes de flèches parallèles s'étalent le long du trajet. Sans disposition personnalisée, le placement est automatique en colonnes suivant le sens du flux (un statut est placé à droite de ceux qui mènent à lui, façon organigramme) ; seuls les statuts réellement utilisés par une règle apparaissent.
3. Éditeur de règle (deux colonnes) :
   • À gauche, le flow : carte Déclencheur → (bouton +) Condition → (bouton +) Action(s). On clique une étape pour la configurer.
   • À droite, le panneau de configuration de l'étape sélectionnée (choix + recherche du déclencheur / de l'action, paramètres).
   • Déclencheur : Changement de statut, (Ré)assignation (internes), Relecteur de PR affecté (interne, émis par l'écran « Revue de PR » quand on affecte un relecteur — proposé seulement si un connecteur GitHub actif est branché), ou GitHub (Label de PR modifié, PR mergée, PR ouverte, Issue fermée). Les déclencheurs GitHub n'apparaissent dans le menu que si un connecteur GitHub actif est branché pour le tenant ; sinon un message l'indique (une règle GitHub déjà créée reste éditable).
   • Condition (optionnelle, contextuelle) : pour un déclencheur interne, sur le statut du backlog (départ / arrivée) ; pour un déclencheur GitHub, sur un label GitHub (« la PR a le label ___ » = le « départ »). GitHub ne fournit pas de transition de label native, on vérifie la présence du label sur la PR au moment de l'événement.
   • Actions (une ou plusieurs, ordonnées) : Changer le statut, Assigner des membres, Notifier. L'action Notifier cible, au choix (cumulables) : l'assigné de l'item, des membres précis, et le relecteur de la PR liée à l'item s'il en a un (case « Notifier le relecteur de la PR (si affecté) »). Le relecteur est résolu au moment du déclenchement ; sans PR liée / sans relecteur, cette cible est simplement ignorée — sauf pour le déclencheur Relecteur de PR affecté sur une PR non rattachée : le relecteur est alors directement celui qui vient d'être affecté (il n'y a rien d'autre à résoudre), et c'est la seule action qui s'applique dans ce cas (Changer le statut / Assigner des membres / Poser un label n'ont pas de sens sans item de backlog). L'action Poser / retirer un label GitHub n'est proposée (cliquable) qu'avec un connecteur GitHub actif ; sinon elle est grisée (« connecteur requis »).
   • Bouton « Enregistrer & activer ».

Générateur de nom de branche (bloc Git de la fiche d'un item de backlog) : on choisit le type (feature / bugfix / hotfix) et l'outil génère un nom normalisé ‹type›/backlog-‹id›-‹titre› (ex. feature/backlog-1302-duplication-de-mission). Le bouton copie la commande complète git switch -c ‹branche› (prête à coller). Le type choisi est mémorisé sur l'item (conservé d'une ouverture à l'autre). Ce nom encode l'id du backlog, ce qui sert à relier automatiquement une PR à son item.

Le bloc Git de la fiche (nom de branche + PR/issues liées) n'apparaît que si le Workflow GitHub est activé pour le projet et qu'un connecteur GitHub actif existe ; sinon il est masqué.

Règles d'accès

• Onglet et édition réservés aux utilisateurs pouvant modifier le projet (canUpdateProject).
• Sur le diagramme, un utilisateur sans droit d'édition peut zoomer / se déplacer / surligner (interactions locales), mais ne peut ni déplacer les statuts et labels, ni créer de transition, ni réinitialiser la disposition (poignées et drag masqués, refus côté serveur).
• Isolation stricte par entité (tenant) et par projet : on ne voit et n'édite que les transitions de son propre projet.

Points d'attention

• Les statuts eux-mêmes ne sont pas modifiables ici (colonnes du kanban figées). On configure des règles (déclencheur → conditions → actions) autour des statuts existants.
• Le choix d'un label GitHub propose les labels réels des dépôts. Quand le champ « Dépôts » du connecteur (Store) n'est pas renseigné, seuls les 5 premiers dépôts accessibles sont interrogés et un bandeau signale la liste partielle : renseigner le champ pour obtenir la liste complète.
• Les options GitHub (déclencheurs + action « poser/retirer un label ») sont conditionnées à un connecteur GitHub actif : masquées/grisées sans connecteur, et refusées côté serveur (on ne peut pas créer une automatisation GitHub sans connecteur). Les règles GitHub préexistantes restent visibles et éditables.
• L'auteur d'une action n'est jamais notifié de sa propre action (anti-spam).
• Les changements faits par une règle apparaissent dans l'historique de l'item (panneau « Historique » de la fiche), avec le nom de la règle et le déclencheur : « Statut passé de En cours à À tester — automatisation « PR mergée → À tester » (règle #6, déclencheur github_pr_merged) ». Une assignation y est décrite avec le nom des membres, pas leurs identifiants. Un statut ne bouge donc plus « tout seul » sans explication.
• Quand une règle ne fait rien, la raison est consultable par un développeur ISI dans le journal des automatisations (/admin → onglet Actions → tuile « Log-Viewer » → fichier workflows.log) : label attendu différent du label reçu, statut cible inexistant, notification sans destinataire, interrupteur « GitHub & Workflow » resté fermé… Les cas normaux (label qui ne correspond pas volontairement) restent sous le seuil des anomalies.
• Les notifications sont courtes, avec le titre du backlog en tête (tronqué à 40 caractères au-delà ; à défaut le numéro « #‹id› » si le titre est vide). Le titre de la notification porte l'événement, le message tient sur une ligne : ex. titre « Pull request mergée » + message « Backlog « Fix workflows sans backlogs » : PR mergée », ou « Backlog « … » → Bloqué » pour un changement de statut.

Voir aussi

• Doc technique : ../../.claude/technical-docs/projects/backlog-workflow-builder.md