Skip to content

21 — Notifications et Push

1. Objectif métier

Configurer les alertes utiles pour que l’équipe réagisse rapidement (nouvelle commande, escalation humaine, feedback, rendez-vous).

2. Qui utilise ce module (admin/operator)

admin: définit les préférences par événement/canal.
operator: reçoit et traite les notifications.

3. Prérequis

Utilisateurs actifs.
Politique d’alerting validée.
Tokens push disponibles sur les appareils mobiles.

4. Procédure pas-à-pas (orientée actions produit)

Configurer les préférences de notification (event/channel/enable).
Enregistrer les tokens push des appareils (subscribe).
Générer un événement test (ex: nouvelle commande) et vérifier réception.
Suivre le feed notifications et le compteur non lu.
Marquer lu (unitaire ou global) selon votre process.

5. Scénarios concrets (minimum 2)

Scénario A: alerte immédiate sur HUMAN_ESCALATION pour l’équipe support.
Scénario B: notifications push mobile sur nouvelles commandes.

6. Erreurs fréquentes et résolution

Pas de push reçu: vérifier token, abonnement, et état actif du device.
Trop d’alertes: revoir les préférences par événement/canal.
Compteur non lu incohérent: synchroniser les actions mark-read/read-all.

7. Bonnes pratiques et limites

Limiter les alertes critiques à des événements réellement actionnables.
Nettoyer les tokens obsolètes.
Nommer clairement la politique de notification par équipe.

8. Référence rapide (champs/statuts/modes)

Événements clés: new_order, human_escalation, feedback, appointment_pending, appointment_rescheduled, appointment_cancelled.
Canaux: database, websocket, webhook.
Actions: subscribe/unsubscribe, feed, unread-count, mark-read.

9. Liens vers modules liés