Une notification utile informe la bonne personne au moment où une action demande son attention, avec assez de contexte pour décider quoi faire ensuite.
Les logiciels métier envoient des courriels, des alertes dans l’interface ou des messages mobiles. Le problème apparaît quand chaque événement déclenche tout en même temps. Les utilisateurs ignorent les alertes, reçoivent plusieurs copies d’un même message et ne savent plus quelle action est attendue.
Concevez les notifications à partir du travail à effectuer. Un changement d’état n’a pas toujours besoin d’un message immédiat. Une notification doit répondre à trois questions : qui doit agir, pourquoi maintenant et où l’action peut-elle être réalisée ?
Distinguer information et action
Une information peut apparaître dans l’historique ou dans un résumé périodique. Une action urgente peut exiger une alerte directe. Une validation de devis, une erreur d’import et une échéance proche n’ont pas le même niveau de priorité.
Écrivez la conséquence attendue. « Le devis 184 est en attente de validation » donne un contexte et une destination. « Mise à jour effectuée » apporte peu d’aide si plusieurs dossiers ont changé. Ajoutez un lien vers la ressource lorsque les droits permettent son ouverture.
Le message ne doit pas exposer les détails à un destinataire non autorisé. Le serveur doit vérifier les droits au moment de la consultation et au moment de la création de la notification. Un lien deviné ne doit pas permettre d’accéder au dossier.
Définir les préférences par type d’événement
Proposez des préférences compréhensibles. Un utilisateur peut vouloir recevoir les demandes de validation par courriel, mais consulter les changements de statut dans l’application. Certaines alertes nécessaires au fonctionnement du processus peuvent rester obligatoires, avec une fréquence maîtrisée.
Ne présentez pas une longue liste de cases sans explication. Regroupez les événements par travail et indiquez le canal, la fréquence et la possibilité de désactivation. Une préférence doit produire un comportement prévisible. Documentez aussi ce qui se passe lorsque l’utilisateur change d’équipe ou perd un rôle.
Les réglages d’une personne ne doivent pas remplacer une règle métier. Si une commande exige l’intervention d’un responsable, le système doit conserver cette tâche même si le responsable a coupé les alertes facultatives. Une vue des tâches en attente sert de solution de secours.
Éviter les doublons
Une requête peut être répétée après un délai réseau. Sans identifiant stable, le système peut envoyer deux fois le même message. Associez la notification à l’événement métier et utilisez une clé d’unicité adaptée au destinataire, au type et à la ressource.
Le contenu peut être regroupé lorsqu’une série d’événements survient rapidement. Cinq modifications du même dossier peuvent devenir un résumé, à condition de conserver l’historique détaillé ailleurs. La règle de regroupement doit indiquer le délai et le comportement si une action urgente apparaît dans la série.
Une notification échouée doit avoir un état et une prochaine étape. Le fournisseur d’e-mail peut refuser une adresse, ralentir le débit ou être indisponible. Préparez des reprises avec une limite et isolez les messages qui échouent toujours. La validation du dossier doit rester cohérente avec l’état de sa notification.
Gérer les liens et les changements d’état
Un lien de notification peut devenir invalide. Le dossier peut être clôturé, supprimé ou déplacé. Dans ce cas, affichez une explication et un lien vers la liste autorisée, plutôt qu’une page vide. Ne renvoyez pas les détails d’une ressource que le destinataire ne peut plus consulter.
Le contenu du message doit préciser l’état au moment de l’envoi. Si la notification arrive après une nouvelle modification, l’écran doit afficher l’état actuel et l’historique. L’utilisateur doit pouvoir comprendre pourquoi une alerte ancienne est encore visible.
Les critères d’acceptation doivent couvrir une modification concurrente. Par exemple, une personne reçoit une demande, puis une autre valide le dossier avant son clic. Le premier utilisateur doit obtenir une réponse claire, sans réappliquer une action déjà réalisée.
Tester avec de vrais parcours
Préparez des comptes de test pour chaque rôle et chaque canal. Vérifiez la création, la lecture, l’archivage, la reprise après erreur et la désactivation d’une préférence. Testez aussi l’heure locale lorsque les messages sont regroupés ou planifiés.
Mesurez le nombre de notifications envoyées, le taux d’échec, le délai de livraison et les actions déclenchées. Un taux d’ouverture élevé ne prouve pas qu’un problème est résolu. Une notification peut être ouverte parce qu’elle est confuse ou répétée.
Conservez un historique de l’événement et du message envoyé. Le journal d’audit peut enregistrer la décision de notification, tandis que le fournisseur conserve ses propres informations techniques selon votre configuration.
Un système de notification reste lisible quand chaque message correspond à une décision ou à une tâche. Les canaux, les préférences et les reprises doivent servir cette règle, avec une vue dans l’application pour les actions qui ne doivent jamais disparaître.
Sources : RFC 8058, désabonnement en un clic, OWASP, prévention des abus liés aux e-mails.