En bref
Ces deux canaux se ressemblent parce que tous deux affichent de petits messages dans votre produit, mais ils se situent de part et d'autre de deux lignes : la portée et le consentement. Le push web quitte votre site et atterrit sur l'appareil une fois que l'utilisateur a accordé une permission du navigateur. Le message in-app reste dans une session active et n'exige aucune permission distincte. Considérez-les comme deux outils, pas un seul.
Comment fonctionne le push web
Le push web repose sur trois éléments du navigateur qui collaborent : un service worker (un script d'arrière-plan que le navigateur maintient actif), l'API Push (qui abonne le navigateur à un service de push et reçoit les messages) et l'API Notifications (qui affiche la notification système). L'utilisateur doit cliquer explicitement sur Autoriser dans l'invite de permission du navigateur ; tant qu'il ne l'a pas fait, vous ne pouvez rien envoyer. Après l'opt-in, vous obtenez un point de terminaison d'abonnement et des clés de chiffrement, et votre serveur envoie via le service de push du navigateur même quand l'onglet est fermé. Comme le message arrive hors site, le push web est le canal de réengagement du groupe — plus proche par sa mission du SMS ou de l'e-mail que de tout ce qui vit dans votre application. Le revers : il est borné par le support du navigateur et de l'OS, et l'utilisateur peut révoquer la permission à tout moment.
La réserve iOS
Sur iPhone et iPad, le push web ne fonctionne pas pour un simple onglet Safari. Apple n'a ajouté le push web que pour les applications web que l'utilisateur a ajoutées à l'écran d'accueil, à partir de Safari 16.4 (mars 2023). La demande de permission doit faire suite à un geste direct — par exemple un bouton S'abonner — et non au chargement de la page. Ainsi, sur iOS, votre audience joignable est le sous-ensemble d'utilisateurs ayant installé votre site en application web puis accordé la permission. Prévoyez cet écart plutôt que de supposer une parité avec l'ordinateur de bureau.
Comment fonctionne le message in-app
Les messages in-app s'affichent dans une session active — une bannière, une fenêtre modale, un panneau latéral ou une infobulle dessinés par votre produit pendant que l'utilisateur s'en sert. Il n'y a pas d'opt-in distinct car l'utilisateur est déjà dans votre produit ; le message fait partie de l'expérience. La contrepartie est la portée : l'in-app ne touche que les personnes présentes maintenant. Il ne peut pas ramener un utilisateur inactif, et un utilisateur désabonné ne le verra jamais.
Quand utiliser lequel
| Mission | Canal à choisir |
|---|---|
| Ramener un utilisateur inactif | Push web (ou e-mail / SMS) |
| Annoncer une fonctionnalité aux utilisateurs actifs | Bannière ou modale in-app |
| Guider un nouvel utilisateur dans la configuration | Infobulle ou panneau in-app |
| Alerter sur un événement urgent hors site | Push web |
| Proposer une mise à niveau en pleine action | Modale in-app |
Le partage honnête : l'in-app s'occupe des gens déjà dans la pièce, le push web part chercher ceux qui sont partis. La plupart des produits utilisent les deux, coordonnés dans un parcours client pour qu'une même personne ne reçoive pas une relance in-app et un push pour la même chose à quelques minutes d'intervalle. Décider quel canal porte quel message, dans quel ordre, sans chevauchement, c'est passer d'avoir plusieurs canaux à les faire fonctionner comme un seul — le sujet de multi-canal contre omnicanal. Des outils dédiés comme OneSignal ou Novu se spécialisent dans la livraison de push et de notifications ; une plateforme d'engagement intègre le push et l'in-app à la même logique de parcours que le reste de vos canaux.