---
title: "Automatisations du backlog (façon Jira Automation)"
module: projects
type: functional
status: active
updated: 2026-08-14
---

# 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`