Comment ajouter des notifications à votre application : dans l'appli, e-mail et push

Pour ajouter des notifications à une application web, commencez par les notifications dans l'application : une table de notifications dans votre base de données et une icône de cloche qui affiche les éléments non lus. Ajoutez l'e-mail pour les informations que les gens doivent connaître lorsqu'ils sont absents, à l'aide d'un fournisseur d'e-mails, et ajoutez le push web uniquement lorsque les alertes en temps réel comptent vraiment, car il nécessite un service worker, l'autorisation de l'utilisateur et, sur iPhone, l'application enregistrée sur l'écran d'accueil. Quels que soient les canaux utilisés, créez chaque notification à un seul endroit, côté serveur, et laissez les utilisateurs choisir ce qu'ils reçoivent.

Ce guide compare les canaux, présente une architecture simple et donne des requêtes à utiliser avec un créateur d'applications par IA.

Les principaux canaux comparés

La plupart des applications ont besoin de l'intégré plus l'e-mail. Le push et le SMS valent le coup lorsque le timing compte vraiment, comme un rappel de réservation ou une commande prête.

Comment un système de notifications s'organise

Gardez-le simple et centralisé :

1. Un événement se produit. Un commentaire est publié, un paiement échoue, une réservation est prévue pour demain.
2. Votre serveur appelle une seule fonction, par exemple notify(user, type, data).
3. Cette fonction vérifie les préférences de l'utilisateur et écrit une ligne dans la table notifications (pour la cloche).
4. Elle envoie ensuite vers les autres canaux activés par l'utilisateur pour ce type : e-mail via votre fournisseur, push via l'API Push.
5. L'interface affiche les notifications non lues et les marque comme lues à l'ouverture.

Un point d'entrée unique permet d'ajouter un canal, de modifier un texte ou de respecter les préférences sans chercher dans toute la base de code.

Ce qu'il faut stocker

Une table de notifications nécessite en général : l'identifiant de l'utilisateur, le type (par exemple comment_reply), un court titre et un corps de texte, un lien vers la page concernée, la date de création et la date de lecture. Une table de préférences distincte enregistre les canaux souhaités par chaque utilisateur pour chaque type.

Afficher les nouvelles notifications

• Charger à l'affichage de la page et interroger le serveur toutes les 30 à 60 secondes. Simple et fiable.
• Mises à jour en temps réel avec WebSockets ou server-sent events : l'effet est instantané, mais cela ajoute des pièces mobiles. Commencez par l'interrogation périodique, sauf si l'instantanéité est essentielle.

Notifications par e-mail

L'e-mail nécessite un fournisseur d'envoi et un domaine vérifié ; les détails figurent dans comment envoyer des e-mails depuis votre application. Pour les notifications en particulier :

• Envoyez depuis le serveur, jamais avec une clé du fournisseur dans le navigateur.
• Regroupez les événements bavards. « 3 nouveaux commentaires » dans un seul e-mail vaut mieux que trois e-mails.
• Proposez un récapitulatif quotidien ou hebdomadaire pour l'activité de faible priorité.
• Ajoutez un lien de désabonnement ou de préférences dans les e-mails non essentiels. Les règles applicables aux e-mails marketing varient selon les pays ; vérifiez ce qui vous concerne.

Notifications push web

Le push web permet à votre site d'envoyer des alertes qui apparaissent comme des notifications d'application. Selon la documentation MDN de l'API Push, cela fonctionne ainsi :

1. Votre site enregistre un service worker, un script que le navigateur peut exécuter en arrière-plan.
2. Une fois l'utilisateur d'accord, le service worker s'abonne via PushManager.subscribe(). Le navigateur renvoie un abonnement comportant un point de terminaison et des clés de chiffrement.
3. Votre serveur enregistre cet abonnement et, lorsqu'un événement survient, envoie un message au point de terminaison, généralement signé avec des clés VAPID (une paire de clés qui identifie votre serveur).
4. Le navigateur démarre votre service worker, qui affiche la notification, même si votre page n'est pas ouverte.

MDN précise aussi que le point de terminaison doit rester secret, car le connaître suffit pour envoyer des messages à cet utilisateur.

iPhone et iPad

WebKit a ajouté le Web Push pour les applications web dans iOS et iPadOS 16.4, avec deux conditions indiquées dans son annonce : le site doit être ajouté à l'écran d'accueil, et l'autorisation doit être demandée en réaction à une action de l'utilisateur, par exemple un tap sur un bouton « S'abonner ». Ainsi, sur iPhone, le push n'atteint que les utilisateurs qui ont installé votre application web. Voir applications natives et applications web progressives pour ce que signifie installer une application web.

Bien demander l'autorisation

Ne demandez pas dès la première visite. Expliquez d'abord l'intérêt (« Recevez un rappel une heure avant votre cours »), puis affichez l'invite du navigateur lorsque l'utilisateur tape sur un bouton. Si quelqu'un refuse, le navigateur peut ne plus vous laisser redemander, donc une invite trop précoce peut vous faire perdre cette personne définitivement.

Les notifications programmées ont besoin d'un déclencheur

« Rappel 24 heures avant » ou « récapitulatif hebdomadaire chaque lundi » nécessitent quelque chose qui s'exécute selon un calendrier. C'est un problème de tâches en arrière-plan, traité dans comment exécuter des tâches en arrière-plan. Un schéma courant : un planificateur externe appelle un point de terminaison protégé toutes les quelques minutes, et ce point de terminaison envoie tout ce qui est échu.

Requêtes à donner à votre créateur d'applications par IA

Commencez par l'intégré :

Ajoute des notifications dans l'application. Crée une table notifications (utilisateur, type, titre, corps, lien, created_at, read_at). Ajoute une fonction serveur notify(userId, type, data) que chaque fonctionnalité appelle. Affiche une icône de cloche dans l'en-tête avec le nombre de non-lues, une liste déroulante des 20 plus récentes et un bouton « Tout marquer comme lu ». Interroge le serveur toutes les 60 secondes pour les nouvelles.

Puis les préférences et l'e-mail :

Ajoute des paramètres de notification : pour chaque type (réponses aux commentaires, mentions, facturation), l'utilisateur choisit dans l'application, par e-mail, les deux ou aucun. notify() doit respecter ces choix. Envoie les e-mails via [PROVIDER] en utilisant le secret [ENV_NAME], côté serveur uniquement. Regroupe les e-mails de commentaires pour qu'un utilisateur reçoive au maximum un e-mail toutes les 15 minutes.

Puis le push, si vous en avez besoin :

Ajoute le push web facultatif. Enregistre un service worker, génère des clés VAPID et stocke la clé privée comme secret. Ajoute un bouton « Activer les notifications » dans les paramètres qui demande l'autorisation uniquement au clic. Stocke chaque abonnement par utilisateur et par appareil, envoie les push depuis notify() lorsque l'utilisateur a accepté, et supprime les abonnements que le service push signale comme expirés.

Erreurs courantes

• Des notifications dispersées dans le code. Chaque fonctionnalité envoie son propre e-mail à sa façon, et les préférences sont ignorées. Utilisez une seule fonction notify().
• Demander l'autorisation push au chargement de la page. La plupart des gens refusent, et vous n'aurez peut-être pas de seconde chance.
• Aucune préférence. Les utilisateurs qui ne peuvent pas désactiver les alertes gênantes les désactivent toutes, ou partent.
• Envoyer depuis le navigateur. Les clés d'e-mail et de push doivent rester sur le serveur.
• Ne pas nettoyer les abonnements push morts. Les abonnements expirés s'accumulent et gaspillent des envois.
• Des détails sensibles dans le texte de la notification. Les écrans de verrouillage l'affichent. « Vous avez un nouveau message » est plus sûr que le message lui-même.
• Aucune trace de ce qui a été envoyé. Quand un utilisateur dit « je n'ai jamais reçu l'e-mail », des journaux avec les identifiants de messages du fournisseur vous aident à comprendre pourquoi.

Liste de contrôle

• Une fonction notify() côté serveur utilisée partout
• Table de notifications avec l'état de lecture, et une cloche avec le nombre de non-lues
• Préférences de canal par type, respectées par notify()
• E-mails envoyés depuis le serveur avec un domaine vérifié ; récapitulatif ou regroupement pour les événements bavards
• Autorisation push demandée uniquement après une action de l'utilisateur, avec une explication
• Push testé sur ordinateur et sur iPhone, avec l'application ajoutée à l'écran d'accueil
• Abonnements push expirés supprimés
• Aucun contenu sensible dans les aperçus de push ou d'e-mail
• Les rappels programmés ont un déclencheur fiable

Les notifications sur Mythex

Mythex n'inclut pas de service d'e-mail ni de push intégré pour les applications que vous créez : vous apportez donc votre propre fournisseur d'e-mails et générez vos propres clés push, stockées comme secrets du projet. La partie intégrée n'a besoin que de la base de données du projet, que Mythex ajoute lorsque vous la demandez. Construisez avec des requêtes semblables à celles ci-dessus, testez la cloche et les e-mails dans l'aperçu, et testez le push sur votre URL publiée, car les service workers et le push nécessitent une vraie adresse HTTPS. La recette de la documentation Envoyer un e-mail depuis votre application propose une requête de départ. Mythex ne documente pas les tâches planifiées ; prévoyez donc les rappels programmés avec un déclencheur externe, comme décrit dans comment exécuter des tâches en arrière-plan.

Questions