---
title: "Workflow d'alertes configurable du backlog"
module: projects
type: functional
status: deprecated
updated: 2026-07-23
---

# Workflow d'alertes configurable du backlog

> ⚠️ **OBSOLÈTE (2026-07-23)** — Le module « Alertes » V1 a été **supprimé** (table
> `project_backlog_alert_rule` droppée, UI et moteur retirés). Il est **entièrement remplacé** par le
> builder de workflow V2 : voir [backlog-workflow-builder](backlog-workflow-builder.md). Ce document
> est conservé pour l'historique uniquement.

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

## À quoi ça sert

Le backlog d'un projet évolue sans notification : pour savoir qu'un item a changé de statut ou a été
assigné, il fallait surveiller le kanban ou relayer l'info à la main sur Teams. Cette fonctionnalité
permet à chaque projet de définir ses propres **règles d'alertes** — façon « automation » Jira —
qui poussent une notification dans la cloche in-app quand un événement précis se produit sur un item.

## Comment ça marche (côté utilisateur)

Un sous-onglet **« Alertes »** est disponible dans l'onglet **Backlog** de chaque projet (à côté de
« Statistiques »). Il liste les règles du projet et permet d'en **créer, éditer, activer/désactiver
ou supprimer**.

Une règle se lit : **QUAND** [événement] **SI** [statut cible optionnel] **ALORS** notifier [cible(s)].

- **Événement déclencheur** (au choix) :
  - *Changement de statut* — l'item passe d'un statut à un autre (ex. vers « Bloqué ») ;
  - *Assignation* — la liste des personnes assignées à l'item change.
- **Statut cible** (uniquement pour l'événement « changement de statut », optionnel) : restreint la
  règle à une transition précise (ex. déclencher **seulement** quand l'item passe en « Bloqué »).
  Laissé vide, la règle se déclenche sur **tout** changement de statut.
- **Cibles à notifier** (au moins une) :
  - *L'assigné de l'item* — cible dynamique, résolue au moment du déclenchement (supporte les
    multi-assignés) ;
  - et/ou une **sélection d'utilisateurs** parmi les **membres du projet**.
- **Actif** : une règle peut être désactivée sans être supprimée (bascule dans la liste).

Quand une règle se déclenche, chaque destinataire reçoit une notification dans la cloche
(« L'item "…" est passé en Bloqué », « L'item "…" vous a été assigné ») avec un lien vers l'item.

**Anti-spam** : la personne qui réalise l'action ne reçoit **jamais** la notification qu'elle a
elle-même provoquée — même si elle figure dans les destinataires explicites.

## Règles d'accès

- Module **`projet`** requis (`hardEnsureHasModule:projet`).
- **Consultation** de l'onglet : droit de lecture du projet (`manageAccessRights('R', …, 16000101)`).
- **Création / édition / activation / suppression** des règles : réservées aux utilisateurs pouvant
  modifier le projet (`canUpdateProject`). Sans ce droit, la liste reste consultable en lecture seule.

## Points d'attention

- **Modifications de masse non couvertes (V1)** : un changement appliqué en lot (ex. changement de
  sprint en masse sur plusieurs items) ne déclenche pas de règle. Seules les actions unitaires
  (kanban, formulaire d'édition) sont prises en compte.
- **Assignation à la création non couverte (V1)** : assigner quelqu'un au moment de *créer* un item
  ne déclenche pas d'alerte. Seules les (ré)assignations ultérieures notifient.
- **Hors périmètre V1** (repoussé) : multi-canal (mail / Teams), préférences de notification par
  utilisateur, moteur de conditions complexe (ET/OU), déclencheurs « item créé », « priorité
  changée », « échéance dépassée ».

## Voir aussi

- Doc technique : `../../.claude/technical-docs/projects/backlog-alert-workflow.md`