Comment ajouter des notifications à votre application : dans l'app, par courriel et push

Pour ajouter des notifications à une app web, commencez par les notifications intégrées à l'app : une table de notifications dans votre base de données et une icône de cloche qui affiche les éléments non lus. Ajoutez le courriel pour les choses que les gens doivent savoir lorsqu'ils sont absents, avec un fournisseur de courriels, et ajoutez le push web seulement lorsque les alertes en temps réel comptent vraiment, car il exige un service worker, l'autorisation de l'utilisateur et, sur iPhone, l'app enregistrée sur l'écran d'accueil. Quels que soient les canaux retenus, créez chaque notification à un seul endroit, sur le serveur, et laissez les utilisateurs choisir ce qu'ils reçoivent.

Ce guide compare les canaux, présente une architecture simple et propose des requêtes que vous pouvez utiliser avec un outil de création d'applications par IA.

Comparaison des principaux canaux

La plupart des applications ont besoin des notifications intégrées et du courriel. Le push et le SMS valent la peine lorsque le moment compte vraiment, comme un rappel de réservation ou une commande prête.

Comment un système de notifications s'articule

Gardez-le simple et centralisé :

1. Un événement se produit. Un commentaire est publié, un paiement échoue, une réservation a lieu 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 aux autres canaux que l'utilisateur a activés pour ce type : le courriel via votre fournisseur, le push via l'API Push.
5. L'interface affiche les notifications non lues et les marque comme lues lorsqu'on les ouvre.

Un seul point d'entrée vous permet d'ajouter un canal, de modifier le libellé ou de respecter les préférences sans fouiller dans tout le code.

Ce qu'il faut stocker

Une table de notifications a généralement besoin de : l'identifiant de l'utilisateur, le type (par exemple comment_reply), un titre et un corps courts, un lien vers la page concernée, la date de création et la date de lecture. Une table de préférences distincte indique quels canaux chaque utilisateur veut 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 des événements envoyés par le serveur : l'effet est instantané, mais cela ajoute des pièces mobiles. Commencez par l'interrogation, sauf si les mises à jour instantanées sont essentielles.

Notifications par courriel

Le courriel nécessite un fournisseur d'envoi et un domaine vérifié; les détails se trouvent dans comment envoyer des courriels depuis votre app. Pour les notifications en particulier :

• Envoyez depuis le serveur, jamais avec une clé de fournisseur dans le navigateur.
• Regroupez les événements bavards. « 3 nouveaux commentaires » dans un seul courriel vaut mieux que trois courriels.
• Proposez un résumé quotidien ou hebdomadaire pour l'activité de faible priorité.
• Incluez un lien de désabonnement ou de préférences dans les courriels non essentiels. Les règles applicables aux courriels promotionnels varient selon les pays : vérifiez celles qui s'appliquent à vous.

Notifications push web

Le push web permet à votre site d'envoyer des alertes qui apparaissent comme des notifications d'app. Selon la documentation de l'API Push de MDN, le fonctionnement est le suivant :

1. Votre site enregistre un service worker, un script que le navigateur peut exécuter en arrière-plan.
2. Une fois que l'utilisateur a accepté, le service worker s'abonne via PushManager.subscribe(). Le navigateur renvoie un abonnement comprenant 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 push web pour les apps web dans iOS et iPadOS 16.4, avec deux conditions énoncées dans son annonce : le site doit être ajouté à l'écran d'accueil, et l'autorisation doit être demandée en réponse à une action de l'utilisateur, comme un toucher sur un bouton d'abonnement. Ainsi, sur iPhone, le push ne rejoint que les utilisateurs qui ont installé votre app web. Consultez apps natives et apps web progressives pour savoir ce que signifie l'installation d'une app web.

Demander l'autorisation avec doigté

Ne demandez pas l'autorisation dès la première visite. Expliquez d'abord l'avantage (« Recevez un rappel une heure avant votre cours »), puis affichez l'invite du navigateur lorsque l'utilisateur touche un bouton. Si quelqu'un refuse, le navigateur peut ne plus vous permettre de demander de nouveau : une invite prématurée peut donc vous faire perdre cette personne pour de bon.

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

Un « rappel 24 heures avant » ou un « résumé hebdomadaire chaque lundi » exige quelque chose qui s'exécute selon un horaire. C'est un problème de tâches en arrière-plan, couvert dans comment exécuter des tâches en arrière-plan. Un modèle courant : un planificateur externe appelle un point de terminaison protégé toutes les quelques minutes, et ce point de terminaison envoie ce qui est dû.

Requêtes à donner à votre outil de création par IA

Commencez par l'intégré à l'app :

Ajoute des notifications dans l'app. 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 notifications 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 le courriel :

Ajoute des paramètres de notification : pour chaque type (réponses aux commentaires, mentions, facturation), l'utilisateur peut choisir dans l'app, par courriel, les deux ou aucun. notify() doit respecter ces réglages. Envoie les courriels via [FOURNISSEUR] avec le secret [NOM_VARIABLE] côté serveur uniquement. Regroupe les courriels de commentaires afin qu'un utilisateur reçoive au plus un courriel toutes les 15 minutes.

Ensuite, 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 seulement 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 courriel à 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 deuxième chance.
• Aucune préférence. Les utilisateurs qui ne peuvent pas désactiver les alertes bruyantes les coupent toutes, ou partent.
• Envoyer depuis le navigateur. Les clés de courriel 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 renseignements 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é. Lorsqu'un utilisateur dit « je n'ai jamais reçu le courriel », les journaux avec les identifiants de messages du fournisseur vous aident à trouver pourquoi.

Liste de contrôle

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

Les notifications dans Mythex

Mythex n'inclut pas de service intégré de courriel ou de push pour les apps que vous créez : vous apportez donc votre propre fournisseur de courriels et générez vos propres clés push, stockées comme secrets du projet. La partie intégrée à l'app n'a besoin que de la base de données du projet, que Mythex ajoute lorsque vous la demandez. Créez avec des requêtes comme celles ci-dessus, testez la cloche et les courriels dans l'aperçu, et testez le push sur votre URL publiée, car les service workers et le push exigent une adresse HTTPS réelle. La recette de la documentation Envoyer un courriel depuis votre app 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