Notifications

Libre WebUI conserve une boîte de réception de notifications durable et propre à chaque utilisateur. L’activité de l’équipe — mentions, messages directs, partages, échecs d’automatisations et rappels de calendrier — atteint ainsi les personnes même lorsque la page concernée est fermée.

Fenêtres contextuelles d’état

Les messages d’état courts, par exemple une modification enregistrée ou une opération Git terminée, apparaissent près du haut de la page. Utilisez le bouton Fermer pour masquer une fenêtre contextuelle, au pointeur comme au clavier. Le survol garde le message affiché le temps de le lire ; le fermer fait disparaître le message, tandis que l’opération sous-jacente conserve son état actuel.

La boîte de réception

Les notifications sont d’abord des lignes de base de données : leur titre et leur corps sont chiffrés au repos, leur nombre est limité à 500 par utilisateur (les plus anciennes sont élaguées) et une clé source facultative permet de les dédupliquer. Une publication répétée est ainsi regroupée en une seule entrée au lieu de faire sonner la cloche sans cesse. La surface REST permet de les répertorier, de compter les éléments non lus, de les marquer comme lus (une notification ou toutes) et de les supprimer.

La livraison en direct emprunte le flux d’événements durable propre à l’utilisateur notify:<userId> via GET /api/notifications/events (SSE). L’identité du flux provient de la session authentifiée, jamais d’une entrée du client, et la boîte de réception SQL reste la source de vérité : un événement manqué est récupéré en relisant la liste, et non en rejouant le flux.

Origine des notifications

Type	Déclenchement
channel-dm	Quelqu’un vous envoie un message direct
channel-mention	Quelqu’un vous @mentions dans un canal ou répond à votre message
channel-invite	Vous êtes ajouté à un canal
share	Quelqu’un partage une ressource avec vous
automation-failed	L’une de vos automatisations échoue (sauf si elle a désactivé cette option)
calendar-reminder	Un événement avec un délai de rappel atteint l’heure prévue
work-run-finished	L’un de vos agents Work recrutés termine une exécution
work-run-attention	Un agent recruté s’arrête pour demander une intervention ou rencontre une erreur
work-takeover	Un agent Work vous demande de prendre le contrôle de son écran
work-approval	Une exécution Work attend que vous approuviez une action à effet
system	Annonces au niveau de l’instance

Les notifications sont toujours publiées uniquement à l’utilisateur concerné ; mentionner le nom d’un utilisateur qui n’est pas membre du canal ne produit rien.

Les notifications peuvent aussi déclencher des automatisations : une automatisation dotée d’un déclencheur event s’exécute chaque fois qu’une notification du type choisi atteint son propriétaire, avec un délai de récupération d’une minute par automatisation.

Webhooks sortants

Les administrateurs peuvent enregistrer des cibles de webhook qui reçoivent les événements de l’équipe.

• Sortie protégée. Les cibles sont soumises à la même politique de destination que les serveurs d’outils : URL exacte, aucune redirection, aucune adresse privée ou locale au lien, sauf si l’administrateur a explicitement ajouté un hôte à TOOLS_PRIVATE_NETWORK_ALLOWLIST. Les noms d’hôtes sont résolus et revérifiés à chaque livraison.
• Signature. Lorsqu’un secret est configuré, chaque livraison porte X-Libre-Signature: sha256=<hmac>, calculé sur le corps exact.
• Caviardage. L’enveloppe contient le type d’événement, le type de notification, le titre, les identifiants et les horodatages. Les corps des notifications, le contenu des messages, les invites et les documents ne quittent jamais l’instance.
• Durabilité. Les livraisons s’exécutent comme des tâches durables avec un nombre limité de tentatives ; une réponse 5xx du destinataire déclenche une nouvelle tentative, tandis qu’une réponse 4xx est considérée comme son verdict et clôt la livraison.
• Portée. Chaque cible s’abonne à des types de notifications précis (ou à *).

Notifications push du navigateur

Paramètres → Notifications enregistre ce navigateur pour Web Push, afin que les mentions, partages, rappels et tâches terminées atteignent l’appareil même lorsque l’onglet est fermé. La mise en œuvre est standard et autonome :

• VAPID (RFC 8292). Le serveur signe chaque livraison avec une paire de clés ES256, générée une fois et stockée sous forme chiffrée, ou fixée au moyen de VAPID_PUBLIC_KEY/VAPID_PRIVATE_KEY (VAPID_SUBJECT définit la déclaration de contact). Aucune bibliothèque push ni aucun compte de service tiers n’intervient, en dehors du point de terminaison push du fournisseur du navigateur.
• Charges utiles chiffrées (RFC 8291). Chaque message est chiffré pour les clés propres à l’appareil avec aes128gcm avant de quitter l’instance ; le service push relaie un texte chiffré qu’il ne peut pas lire.
• Par appareil et liée à la session. Un abonnement appartient au navigateur qui l’a créé et à la session d’authentification de ce navigateur : se déconnecter de la session (ou « déconnecter les autres sessions ») supprime également son enregistrement push. Les points de terminaison sont stockés sous forme chiffrée avec un jeton de recherche à clé et doivent être des destinations HTTPS publiques, selon les mêmes règles de sécurité des sorties que les webhooks.
• Durabilité. Les livraisons push s’exécutent comme des tâches durables avec un nombre limité de tentatives ; si un service push signale la disparition de l’abonnement (404/410), celui-ci est supprimé.
• La charge utile contient le titre de la notification, son corps facultatif, son type et son lien cible, avec le même niveau de caviardage que la boîte de réception.

Les notifications push exigent l’application de production (le service worker ne s’y enregistre que dans ce cas) et une origine sécurisée. Le même service worker fournit l’enveloppe hors ligne et la possibilité d’installer l’application : le manifeste rend Libre WebUI installable, les navigations se rabattent sur l’enveloppe mise en cache hors ligne et les ressources de build hachées sont mises en cache de façon immuable. Le trafic de l’API n’est jamais mis en cache.

E-mail

Le courrier électronique est le troisième canal de livraison, et le seul qui exige une configuration par un administrateur. Paramètres → Gestion des utilisateurs → Accès et politiques → Notifications par e-mail contient un unique serveur SMTP sortant : hôte, port, sécurité de connexion (STARTTLS, TLS implicite, ou aucune pour un réseau de confiance), identifiants facultatifs, adresse d’expédition et URL publique utilisée pour les liens. Les variables d’environnement SMTP_* dans les Variables d’environnement amorcent les mêmes champs pour les déploiements en conteneur ; une valeur enregistrée dans l’interface prévaut. Le mot de passe est stocké chiffré et n’est jamais renvoyé au navigateur. Envoyer un test livre un message à la propre adresse de l’administrateur (ou à toute adresse saisie) afin que l’aller-retour soit prouvé avant que les utilisateurs n’en dépendent.

Les administrateurs choisissent aussi un modèle d’e-mail Clair ou Sombre et le prévisualisent avant d’enregistrer. Clair est la valeur par défaut. Le préréglage enregistré s’applique à chaque notification et e-mail de test de cette instance, y compris les résultats Markdown ; il est indépendant du thème d’interface de chaque utilisateur. L’aperçu affiche un contenu d’exemple sans contacter SMTP, envoyer de message ni mettre de tâche en file. Seuls les administrateurs peuvent lire ou modifier le préréglage ou demander un aperçu. Les préréglages intégrés gardent le texte, les liens, les blocs de code et les boutons lisibles ; les modèles HTML personnalisés ne sont pas acceptés. Les clients de messagerie peuvent toutefois ajuster les couleurs selon leurs propres réglages d’affichage.

Une fois l’interrupteur activé, chaque utilisateur choisit ce qui atteint sa boîte de réception sous Paramètres → Notifications → Notifications par e-mail :

• Mentions dans les canaux : un message qui vous mentionne dans un canal, avec l’aperçu et un lien vers le canal.
• Résultats des automatisations : le résultat de chacune de vos exécutions d’automatisation, succès ou échec. Une exécution de chat transporte la réponse de l’assistant elle-même (jusqu’à quelques milliers de caractères) ; une exécution Work transporte la ligne d’état de la tâche ; un échec transporte l’erreur. Le lien ouvre la discussion ou la tâche correspondante.

Les deux interrupteurs restent désactivés tant que l’utilisateur ne les active pas, et ils ne fonctionnent que pour les comptes disposant d’une adresse e-mail, que le titulaire du compte définit à l’inscription ou qu’un administrateur ajoute sous Utilisateurs. Les messages partent par le même environnement d’exécution de tâches durables que Web Push, avec des tentatives limitées en cas d’échec transitoire du relais, et le client SMTP est une petite mise en œuvre intégrée (EHLO, STARTTLS, AUTH PLAIN ou LOGIN) qui n’envoie jamais d’identifiants sur une connexion non chiffrée, sauf lorsque le mode est explicitement none. Chaque message possède une partie texte brut et une alternative HTML dans le style du site web : le logo Libre WebUI, une carte avec le contenu, un bouton corail vers la cible, et un pied de page renvoyant vers Paramètres → Notifications. Un résultat d’automatisation est rendu à partir de Markdown (titres, listes, emphase, code, liens vers des cibles http(s) uniquement) ; tout le reste est échappé, et la seule image externe est le logo servi depuis librewebui.org. Aucun suivi.

Frontières

• Les préférences utilisateur par type ne sont pas encore implémentées ; les automatisations respectent leur propre réglage de notification et quitter un canal interrompt ses notifications.