Comment fonctionne un message in-app ?
C'est le SDK de votre produit qui fait le travail. Les messages sont associés à des conditions de déclenchement — un événement précis, une page vue, l'appartenance à un segment — et affichés directement dans l'interface quand ces conditions sont réunies. Comme la livraison passe par du code que vous exécutez déjà, il n'y a ni demande de permission ni abonnement ; toute personne active dans le produit peut en voir un. Des outils comme Braze synchronisent les messages éligibles à l'ouverture de session, puis laissent les règles de diffusion et les plafonds de fréquence décider de ce qui s'affiche.
Message in-app ou push web : quelle différence ?
Une notification push web atteint l'utilisateur hors de votre site, via le système de notifications du navigateur — mais seulement après une autorisation explicite, que beaucoup refusent. Le message in-app est son image inversée : aucune permission, mais aucune portée une fois l'utilisateur parti. Les deux canaux couvrent chacun l'angle mort de l'autre — le push fait revenir, l'in-app guide sur place. Le guide push web et messages in-app explique comment les faire fonctionner comme un seul programme.
Quand afficher un message in-app ?
Chaque fois que la personne à atteindre est déjà dans le produit : checklists d'onboarding, annonces de fonctionnalités, invitations à monter en gamme, conseils contextuels, courts sondages. Les messages in-app fonctionnent aussi comme étapes d'un parcours client plus large — par exemple une infobulle réservée aux utilisateurs arrivés sur le tableau de bord sans avoir créé de projet. Le ciblage est tout l'intérêt ; un message que tout le monde voit n'est que de l'interface.
Quelles sont les limites des messages in-app ?
- Portée liée à la session : un utilisateur perdu ou dormant n'en verra jamais un — la reconquête passe par l'e-mail, le SMS ou le push.
- Coût d'attention : une modale au mauvais moment interrompt un vrai travail ; par défaut, préférez bannières et infobulles, et n'escaladez que si le message le justifie.
- Risque de rendu : le contenu est injecté dans une page active, la plateforme doit donc assainir le HTML des messages — un rendu protégé contre le XSS est une exigence, pas une option.
- Pas d'archive : une fois fermé, le message disparaît ; ce dont l'utilisateur aura besoin plus tard doit aussi exister en e-mail ou dans la documentation.