La messagerie in-app est l’un des meilleurs moyens d’atteindre vos utilisateurs pendant qu’ils sont dans votre app. La solution la plus courante a toujours été l’éditeur in-app HTML classique. Idéale pour des designs complexes et sur mesure, mais lourde pour les tests rapides et les hypothèses qu’un responsable marketing enchaîne au quotidien.
Désormais, les messages in-app natifs donnent aux marketeurs une autonomie complète. Vous choisissez une mise en page prête à l’emploi directement dans l’éditeur, vous la personnalisez, et vous lancez en quelques minutes, sans l’aide d’un designer ou d’une équipe technique.
Ce guide couvre ce que sont les messages in-app natifs, comment les personnaliser, et comment choisir la bonne mise en page selon l’objectif — onboarding, conversion, winback ou rétention.
📖 Nouveau sur ce canal ? Commencez par comprendre ce que sont les messages in-app et pourquoi ils fonctionnent.
7 mises en page, aucun code, aperçu en direct.
Qu’est-ce qu’un message in-app natif ?
Il existe 2 façons de construire un message in-app.
Un in-app HTML classique est une page web personnalisée que le SDK affiche en overlay au-dessus de votre interface native, avec un contrôle total du design et un rendu web. C’est le bon choix quand vous avez besoin de quelque chose que les mises en page prêtes à l’emploi ne permettent pas : un formulaire de feedback ou d’enquête, du contenu interactif sur mesure, ou un design entièrement personnalisé importé en ZIP.
Un message in-app natif est différent : le SDK le dessine avec les composants natifs de la plateforme, à partir d’une mise en page prête que vous remplissez dans l’éditeur — pas de HTML, pas de web view. Il s’ouvre plus vite, s’anime plus fluidement, et fait partie intégrante de l’app.
Les 7 types de messages in-app natifs et quand les utiliser
Pushwoosh met à disposition 7 mises en page natives directement dans l’éditeur in-app. Comment savoir laquelle choisir ?
Le choix d’une mise en page est avant tout une question d’interruption : quelle part de l’écran, et quelle part de l’attention de l’utilisateur, ce message mérite-t-il à cet instant ? Répondez d’abord à cette question, et la mise en page s’impose d’elle-même.
- N’interrompez pas : banner. Une barre compacte épinglée en haut ou en bas. L’utilisateur continue ce qu’il faisait, le message est simplement là. À réserver aux relances qui peuvent attendre un ou deux taps : une étape non terminée, une nouvelle fonctionnalité, une petite récompense.
- Interrompez un peu : sheet. Un panneau glisse depuis le bas, avec une poignée pour le refermer d’un geste. Il signale «une chose rapide à propos de ce que vous regardez». C’est l’endroit pour les actions contextuelles au sein d’une session : enregistrer cet article, activer ce réglage, confirmer ce choix.
- Interrompez brièvement : modal. Une carte centrée sur un écran assombri. Elle arrête l’utilisateur, mais pour une seule décision. Offres, mises à jour, choix oui/non.
- Prenez tout l’écran : fullscreen, stories, carousel, video. Réservées aux moments où l’utilisateur accepte de s’arrêter. Onboarding, grande promotion, démonstration produit. À utiliser quand le bénéfice justifie une vraie pause, pas parce que la mise en page fait de l’effet dans l’éditeur.
Cette échelle indique combien d’écran occuper. Voyons maintenant chaque mise en page en détail : ce qu’elle est, le moment où elle s’applique, l’étape du cycle de vie utilisateur, et le KPI à suivre.
| Mise en page | Ce que c'est | Meilleur moment | Étape du cycle de vie | KPI à suivre |
|---|---|---|---|---|
| Banner | Barre compacte, en haut ou en bas, non bloquante | Une relance qui ne doit pas casser la session | Engagement, rétention | CTR |
| Sheet | Panneau du bas avec poignée | Une action contextuelle sur l'écran en cours | Engagement, conversion | Taux d'interaction, objectif de parcours |
| Modal | Carte centrée sur un fond assombri | Une offre ou une mise à jour qui exige une décision | Conversion, winback | CTR, objectif de parcours |
| Fullscreen | Image de couverture plein écran avec texte et boutons | Onboarding, grande promotion | Onboarding, conversion | Objectif de parcours (activation, achat) |
| Stories | Slides séquentiels plein écran avec barres de progression | Une série d'étapes ou de fonctionnalités | Onboarding, adoption fonctionnalité | Interactions, objectif de parcours (fonctionnalité utilisée) |
| Carousel | Cartes plein écran défilables avec points de pagination | Une sélection ou un catalogue | Engagement, conversion | CTR vers le produit, objectif de parcours |
| Video | Lecteur plein écran HLS ou MP4 avec texte et boutons en surimpression | Une démo produit ou fonctionnalité | Onboarding, conversion | Interactions sur le bouton en surimpression, objectif de parcours |
Personnalisez votre message in-app
Une mise en page native n’est que la moitié de la valeur. L’autre moitié, c’est que chaque champ à l’intérieur peut être adapté par utilisateur.
3 techniques de personnalisation couvrent l’essentiel des besoins d’un marketeur.
Contenu dynamique. Injectez n’importe quel attribut utilisateur dans le texte — prénom, formule, ville, dernière catégorie achetée — avec des modificateurs de format pour rester propre, puis utilisez Liquid pour la logique conditionnelle : montrez une offre aux utilisateurs en essai et une autre aux abonnés, changez le CTA selon le segment.
Localisation. Un message in-app natif démarre dans 1 langue. Ajoutez-en d’autres, et Pushwoosh recopie le contenu par défaut — texte, images et libellés de boutons — dans chaque nouvelle langue, à vous de traduire. Chaque utilisateur voit ensuite la version qui correspond à la langue de son appareil : un message construit une fois s’adresse à chaque audience dans sa langue. Les données de langue et d’attributs utilisateur restent hébergées dans l’infrastructure UE et US de Pushwoosh, conforme RGPD.
Générateur de code-barres et QR code. L’éditeur natif génère des codes-barres ou des QR codes et peut récupérer la valeur depuis un tag device au format {Coupon|String|}. Chaque utilisateur obtient son propre code scannable, rendu directement sur l’appareil, sans rien à héberger ni aucune image à générer côté serveur.
Le message in-app natif en action : cas d’usage et exemples
Voici à quoi cela ressemble en conditions réelles. Chaque cas ci-dessous part d’un problème que vous avez probablement déjà vu dans votre propre funnel, nomme la mise en page qui le résout, et détaille la configuration dans Pushwoosh.
👋 Onboarding : accueillez vos utilisateurs avec fullscreen ou stories
Le problème : un nouvel utilisateur ouvre l’app pour la première fois et doit comprendre la valeur seul. La plupart des premières sessions se terminent sans qu’il l’ait trouvée.
La capacité : fullscreen s’approprie le premier écran pour un accueil clair et une action unique. Stories déroule les fonctionnalités clés en slides cliquables, avec des barres de progression qui montrent le chemin restant.
Dans Pushwoosh : au premier app_open, déclenchez un fullscreen avec la valeur principale et un seul CTA. Enchaînez avec un message stories — un slide par fonctionnalité clé — pour amener au premier usage.
📖 Pour aller plus loin : les messages in-app de bienvenue.
💸 Winback : une modal avec un coupon scannable
Le problème : un acheteur inactif a besoin d’une vraie raison de revenir, pas juste d’un message «vous nous manquez».
La capacité : un template in-app natif défini comme action de clic du push, pour que le tap ouvre une modal avec un QR code personnel généré depuis le tag device {Coupon|String|}.
Dans Pushwoosh : segmentez les acheteurs inactifs depuis 21 jours ou plus, affichez une modal portant leur code personnel — scannable en caisse, sans image tierce à générer. En France, ce déclencheur fonctionne particulièrement bien calé sur les Soldes ou les French Days, quand la fenêtre de réachat est courte.
📖 Décryptage complet des parcours de coupons scannables : le marketing par coupon pour applications mobiles.
🛍️ En session : un carousel qui fonctionne comme un catalogue
Le problème : une offre statique unique correspond rarement à ce qu’un acheteur donné recherche vraiment.
La capacité : la mise en page carousel, cartes plein écran défilables, avec Liquid qui récupère le nom de la catégorie et le texte depuis la dernière catégorie consultée par l’utilisateur.
Dans Pushwoosh : déclenchez sur un événement de vue de catégorie, affichez un carousel de 4 cartes : «Sélectionné pour vous en {LastCategory}», chaque carte associant une image produit, un prix et un bouton vers la fiche produit. Le déclencheur fonctionne à l’identique que le catalogue soit connecté via Shopify, WooCommerce ou PrestaShop, les 3 plateformes e-commerce les plus utilisées par les marchands français.
💳 Relance rétention : un banner qui n’interrompt pas
Le problème : une app d’investissement ou de gestion de budget a des utilisateurs inscrits, ayant lié un compte, mais jamais terminé la vérification. Une modal à chaque ouverture leur apprend à fermer des modals.
La capacité : la mise en page banner, épinglée en bas, visible sur chaque écran jusqu’à ce que l’étape soit terminée, refermable sans perdre la session.
Dans Pushwoosh : quand un utilisateur a une vérification inachevée ou une fonctionnalité non utilisée, affichez un banner — «Terminez votre vérification pour débloquer les virements» — un tap, zéro interruption. Pour une app FinTech visant le marché français, ce type de relance s’appuie sur une messagerie hébergée en UE et conforme RGPD, un prérequis pour ce secteur.
Créez votre 1er message in-app natif en 5 étapes
Le parcours complet, d’un template à un message actif dans le Customer Journey Builder :
- 1
Choisissez la mise en page selon le niveau d'interruption
Décidez quelle part de l'écran le message mérite, puis choisissez le type d'affichage.
- 2
Construisez-le dans l'éditeur natif
Contenu → In-apps → Créer un in-app → Créer un rich media natif. Les champs sont regroupés en Contenu (texte, images depuis une URL ou le stockage média), Config (couleurs, arrière-plan, comportement) et Actions (boutons et leur comportement). Le guide pas à pas couvre chaque champ.
- 3
Ajoutez des tags et du Liquid
Insérez un prénom, un segment, une offre ou un code coupon pour que chaque utilisateur voie sa propre version.
- 4
Vérifiez l'aperçu en direct
L'éditeur restitue le message tel qu'il apparaîtra sur l'appareil. Vérifiez-le ici avant la mise en ligne.
- 5
Lancez
Définissez le déclencheur et l'audience, placez le nœud in-app dans le parcours, et passez en production.
🚨 Les erreurs qui cassent discrètement les messages in-app natifs :
- Livrer sur un SDK ancien. Sheet, carousel et banner nécessitent iOS 7.2.1+ / Android 6.10.1+ ; video nécessite Android 6.11.0+. En dessous du minimum, rien ne s’affiche.
- Penser en HTML. Le natif n’est pas une web view. Vous construisez à partir de blocs et concevez pour la mise en page, pas pour une page web.
- Lancer sans aperçu. L’aperçu en direct existe pour qu’un rendu cassé n’atteigne jamais un utilisateur. Utilisez-le à chaque fois.
Engagez vos utilisateurs en session avec les messages in-app natifs Pushwoosh
Les messages in-app natifs vous offrent 7 mises en page prêtes à l’emploi, une personnalisation par utilisateur dans chacune d’elles, et un aperçu en direct qui rattrape les problèmes avant la mise en ligne — sans HTML, sans dépendre d’un designer. Choisissez le moment qui compte le plus pour votre app : une étape d’onboarding, un winback, une relance en session, et construisez l’in-app qui va avec.
Articles connexes
Tout voir