Push in-app vs push système : arbitrer canal et contexte

Le choix du canal push est un arbitrage d’attention, pas un simple réglage de notification

Dans une stratégie mobile mature, opposer push in-app et push système comme deux formats interchangeables est une erreur de pilotage. Le push système, notification envoyée par l’application via l’OS et visible hors application, sur l’écran verrouillé ou dans le centre de notifications, est un canal d’interruption. Le push in-app, message affiché uniquement lorsque l’utilisateur est déjà présent dans l’application, est un canal d’accompagnement contextuel. Le premier crée une opportunité de retour vers l’app ou vers le magasin. Le second oriente une session déjà engagée. Leur valeur ne se mesure donc pas avec les mêmes indicateurs, ni au même moment du funnel, parcours allant de l’exposition à la considération, puis à la conversion et à la fidélisation.

Pour les annonceurs retail, locaux et omnicanaux, l’enjeu est particulièrement sensible. Une notification système peut pousser une offre magasin à proximité, relancer un panier, annoncer un stock disponible ou rappeler un rendez-vous. Mais elle consomme un capital attentionnel rare : si elle est jugée intrusive, l’utilisateur peut désactiver les notifications de l’application, voire la désinstaller. Le message in-app est moins risqué sur le plan relationnel, mais il dépend d’un préalable : l’utilisateur doit ouvrir l’application. Il ne peut donc pas compenser une faiblesse de reach, mais il peut fortement améliorer la conversion des sessions actives.

La décision ne doit pas partir de la technologie mais du contexte d’usage. Est-ce que l’information a une valeur immédiate hors application ? Est-elle attendue par l’utilisateur ? Est-elle liée à un signal d’intention récent ? Peut-elle attendre la prochaine session ? La réponse détermine le canal. Un push système pour signaler qu’une commande click and collect est prête a une utilité claire. Un push système pour répéter une promotion générique vue en email et en display peut dégrader la préférence de marque. À l’inverse, un message in-app qui propose une disponibilité magasin, une prise de rendez-vous ou un coupon au moment où l’utilisateur consulte une fiche produit peut réduire la friction sans interrompre.

Le bon arbitrage consiste à attribuer à chaque canal un rôle précis dans l’architecture d’activation. Le push système sert à déclencher ou réactiver. Le push in-app sert à orienter, personnaliser et finaliser. Les deux peuvent coexister, mais seulement si le capping, limitation du nombre de sollicitations sur une période donnée, est consolidé au niveau individu et si les événements de session, de visite, d’achat et d’opt-out alimentent une règle de décision commune. Sans cette gouvernance, l’annonceur risque de multiplier les sollicitations visibles tout en sous-exploitant les moments où l’utilisateur est réellement disponible.

Comprendre la différence structurelle : interruption externe contre guidance en session

Le push système est distribué par les mécanismes de notification d’iOS ou d’Android. Il peut apparaître lorsque l’application est fermée, en arrière-plan ou non consultée depuis plusieurs jours. Sa force est de créer un point de contact autonome. Sa faiblesse est d’être soumis à trois contraintes fortes : l’autorisation de notification, les règles de l’OS et la tolérance de l’utilisateur. Depuis l’évolution des interfaces de permission, notamment sur iOS où l’opt-in explicite conditionne la réception, les taux d’acceptation varient fortement selon la promesse applicative. Des applications à forte utilité transactionnelle peuvent dépasser 60 % d’opt-in, tandis que des apps retail purement promotionnelles peuvent se situer beaucoup plus bas, parfois entre 25 % et 45 % selon la marque, la fréquence et la qualité de l’onboarding.

Le push in-app ne dépend pas de la même logique de permission système, puisqu’il s’affiche dans l’environnement contrôlé de l’application. Il n’a pas la même capacité à faire revenir un utilisateur dormant, mais il bénéficie d’un contexte plus riche : page consultée, catégorie, panier, statut fidélité, magasin favori, stock local, historique de navigation, profondeur de session. L’annonceur peut y personnaliser plus finement le message sans imposer une interruption externe. Dans une application retail, un bandeau in-app proposant le retrait dans le magasin le plus proche après consultation d’un produit peut être plus performant qu’un push système envoyé deux heures plus tard, car il intervient au moment où l’intention est active.

Cette différence crée deux coûts d’attention distincts. Le coût d’attention du push système est élevé, car il interrompt un contexte qui n’appartient pas à la marque : travail, transport, sommeil, conversation, usage d’une autre application. Sa valeur doit donc être justifiée par l’urgence, la personnalisation ou le service. Le coût d’attention du push in-app est plus faible, mais il peut devenir contre-productif s’il perturbe la navigation ou masque une étape critique. Un pop-up in-app affiché trop tôt dans une session, avant que l’utilisateur ait exprimé une intention, peut générer de la fermeture mécanique et abaisser le taux de conversion.

La bonne grille de lecture est celle de la disponibilité cognitive. Un utilisateur hors application peut être joignable techniquement mais indisponible mentalement. Un utilisateur dans l’application est déjà dans un environnement de marque, mais pas nécessairement prêt à convertir. Le rôle du marketing mobile est d’aligner le niveau d’intrusion sur la valeur du signal. Plus le signal est faible, plus le canal doit être discret. Plus le signal est fort, plus une sollicitation visible peut être défendable. Une baisse de prix sur un produit mis en favori, un créneau de rendez-vous libéré ou un stock revenu dans le magasin préféré justifient davantage un push système qu’une animation commerciale générique.

Positionner chaque canal dans le funnel : acquisition, activation, conversion et fidélisation

Dans le haut de funnel, le push système a un rôle limité, car il s’adresse à une base déjà installée et opt-in. Il ne remplace pas les leviers d’acquisition comme le paid social, le search, le SMS opt-in, le display mobile ou la publicité programmatique. La DSP, demand-side platform, plateforme permettant aux annonceurs d’acheter automatiquement des impressions publicitaires, et le RTB, real-time bidding, mécanisme d’enchères en temps réel pour acheter une impression disponible, restent des outils de couverture et de recrutement. Le push intervient plutôt après l’installation ou l’identification, lorsque la marque dispose d’une relation applicative.

En phase d’activation, le push système peut être décisif. Une application installée mais peu ouverte est un actif dormant. Un scénario d’onboarding peut utiliser une notification système dans les 24 à 72 heures suivant l’installation si l’utilisateur n’a pas complété une action structurante : choix du magasin favori, connexion au programme de fidélité, activation du wallet, premier ajout au panier, consultation de stock. Mais la notification doit apporter une raison d’usage, pas seulement rappeler l’existence de l’application. Par exemple : sélectionnez votre magasin pour voir les stocks en temps réel. Ce type de message améliore la valeur future de l’app, alors qu’un simple profitez de nos offres risque d’être perçu comme prématuré.

En phase de conversion, le push in-app est souvent plus efficace, car il intervient lorsque l’utilisateur est déjà engagé. Les cas les plus performants sont ceux où le message réduit une incertitude : disponibilité locale, délai de retrait, avis clients, avantage fidélité, seuil de livraison, prise de rendez-vous, paiement en magasin, comparaison de tailles. Dans un parcours drive-to-store, stratégie visant à générer du trafic qualifié vers un point de vente physique, un in-app peut afficher le magasin le plus accessible et le stock disponible au moment de la consultation produit. Il transforme une intention digitale en action locale sans attendre une relance.

Le push système garde néanmoins une utilité en bas de funnel lorsque la fenêtre d’action est courte. Un panier abandonné avec produit en stock dans le magasin favori peut justifier une notification dans les deux à six heures, à condition que l’utilisateur ait accepté ce type de sollicitation et que la pression récente soit faible. Une offre valable jusqu’à la fermeture du magasin peut fonctionner si elle est réellement locale et pertinente. Mais l’arbitrage doit intégrer la probabilité organique de conversion. Relancer par push système un client qui reviendrait naturellement dans l’application peut améliorer l’attribution, méthode qui assigne une conversion à un ou plusieurs points de contact marketing, sans créer de valeur incrémentale.

En fidélisation, les deux canaux doivent être séparés entre service et commerce. Les notifications de service, comme commande prête, produit de nouveau disponible, rendez-vous confirmé ou bon d’achat expirant bientôt, obtiennent généralement une meilleure acceptabilité que les notifications promotionnelles. Les messages in-app peuvent enrichir l’expérience de fidélité : progression vers un statut, avantages disponibles, recommandations après achat, invitation à noter un produit. La règle est simple : le push système doit annoncer ce qui mérite d’être vu maintenant ; le push in-app doit exploiter ce qui devient utile pendant la session.

Arbitrer avec une matrice canal-contexte : urgence, intention, valeur et risque relationnel

Un framework opérationnel peut croiser quatre variables : urgence du message, intensité de l’intention, valeur économique attendue et risque relationnel. L’urgence mesure la nécessité d’une exposition immédiate. L’intention évalue la proximité comportementale avec l’action : recherche produit, ajout panier, consultation stock, géolocalisation près d’un magasin, ouverture récente d’un email, scan d’un code en magasin. La valeur économique combine panier, marge, probabilité de conversion et LTV, lifetime value, valeur économique attendue d’un client sur la durée de relation. Le risque relationnel agrège fréquence récente, opt-out probable, sensibilité promotionnelle, ancienneté, statut fidélité et historique d’interactions négatives.

Lorsque urgence et intention sont élevées, le push système est souvent légitime. Exemple : un client a demandé une alerte sur un produit indisponible, le stock revient dans son magasin favori et le volume disponible est limité. L’utilisateur a exprimé une attente explicite ; l’information perd de la valeur si elle attend la prochaine session. Le canal système maximise la probabilité d’action. Lorsque l’intention est élevée mais l’urgence faible, le push in-app peut suffire. Exemple : un client consulte plusieurs modèles de chaussures, sans panier ni alerte. À la prochaine session, un message in-app peut proposer le guide des tailles, le stock local ou la réservation en magasin.

Lorsque l’urgence est faible et l’intention faible, le push système doit être évité ou fortement limité. Une opération nationale générique, envoyée à toute la base opt-in, peut générer un volume de sessions à court terme mais dégrader la base à long terme. Si 1 million d’utilisateurs reçoivent une notification avec un taux d’ouverture de 3 %, cela produit 30 000 sessions. Mais si le taux de désactivation des notifications augmente de 0,4 point, la marque perd 4 000 permissions. Pour évaluer l’opération, il faut comparer la marge générée par les sessions incrémentales à la valeur future des permissions perdues.

Lorsque la valeur économique est forte mais le risque relationnel élevé, la décision doit être nuancée. Un client VIP ayant un panier élevé peut sembler prioritaire pour les relances. Mais sa valeur future rend la pression plus coûteuse. Une enseigne de mode premium peut préférer un message in-app élégant ou un email personnalisé plutôt qu’un push système promotionnel. À l’inverse, un client très appétent aux offres, ayant activé les alertes de baisse de prix et ouvert plusieurs notifications récentes, peut recevoir un push système commercial avec un risque plus faible.

Cette matrice peut être traduite en règles simples. Push système si le message est attendu, temporel, transactionnel ou lié à une intention forte. Push in-app si le message améliore une session, guide une décision ou personnalise un parcours. Aucun push si le message n’apporte pas d’information nouvelle, si la pression récente dépasse le seuil défini ou si la conversion attendue est essentiellement organique. La discipline consiste à ne pas utiliser le canal le plus visible pour compenser une proposition de valeur faible.

Mesurer la performance réelle : ouverture, conversion et incrémentalité ne racontent pas la même histoire

Le reporting des pushs est souvent dominé par des métriques faciles à collecter : taux d’envoi, taux de réception, taux d’ouverture, clic, session démarrée, conversion attribuée. Ces indicateurs sont utiles, mais insuffisants pour arbitrer entre push in-app et push système. Le taux d’ouverture d’un push système mesure surtout sa capacité à interrompre et à générer une réaction immédiate. Il ne prouve pas que la conversion n’aurait pas eu lieu sans notification. Le taux d’interaction d’un message in-app mesure l’engagement dans une session, mais il peut masquer un effet de cannibalisation si le message détourne l’utilisateur d’un parcours plus rentable.

Le CPA, cost per acquisition, coût nécessaire pour générer une conversion attribuée, et le ROAS, return on ad spend, ratio entre chiffre d’affaires attribué ou incrémental et dépenses marketing, doivent être interprétés avec prudence dans le contexte push. Le coût d’envoi d’un push système est faible par rapport au SMS ou au paid media, ce qui peut donner l’illusion d’un ROI quasi automatique. Mais le coût réel inclut l’opt-out notification, la désinstallation, la baisse d’engagement futur et la fatigue. Un push gratuit qui fait perdre des permissions qualifiées n’est pas gratuit économiquement.

Un exemple chiffré illustre le biais. Une enseigne beauté envoie un push système à 800 000 utilisateurs opt-in pour une offre week-end. Taux de réception : 92 %. Taux d’ouverture : 4,5 %. Ventes attribuées sur 48 heures : 180 000 euros. Coût opérationnel marginal faible, ROAS apparent très élevé si l’on ne compte que l’outil d’envoi. Mais un holdout, groupe témoin volontairement non exposé, représentant 10 % de la population éligible, montre que les utilisateurs non exposés auraient généré 130 000 euros de ventes comparables rapportées à taille équivalente. L’incrément réel est donc de 50 000 euros, pas 180 000. Si la marge brute est de 45 %, la marge incrémentale est de 22 500 euros. Si la campagne provoque 3 200 désactivations de notifications et que la valeur attendue d’une permission active est estimée à 4 euros sur douze mois, le coût relationnel atteint 12 800 euros. Le bilan reste positif, mais beaucoup moins spectaculaire.

Pour le push in-app, le test doit être conçu différemment. Il faut randomiser les sessions ou les utilisateurs éligibles : une partie voit le message, une autre poursuit le parcours sans exposition. Les indicateurs à suivre ne doivent pas se limiter au clic sur le message. Il faut mesurer le taux d’ajout panier, la conversion, le choix du magasin, la prise de rendez-vous, la marge, le temps de session, les abandons et le réachat. Un in-app qui augmente le clic sur coupon mais réduit le panier moyen peut améliorer le taux de conversion tout en dégradant la marge.

La mesure incrémentale doit aussi tenir compte de la temporalité. Un push système peut accélérer une conversion sans l’augmenter. Pour un retailer alimentaire, cette accélération peut être utile si l’objectif est de lisser le trafic ou de vider un stock. Pour un achat de cycle long, comme l’ameublement ou l’optique, accélérer une décision d’un jour n’a pas la même valeur qu’obtenir une vente additionnelle. Les équipes doivent donc distinguer uplift de volume, uplift de marge et effet de timing. Sans cette distinction, le canal le plus intrusif est souvent récompensé par l’attribution, alors qu’il ne crée pas nécessairement plus de valeur.

Scénariser les séquences : combiner in-app et système sans surexposer l’utilisateur

Le débat ne doit pas aboutir à choisir définitivement un canal contre l’autre. Les stratégies les plus performantes organisent une séquence où chaque canal intervient à son moment. Le push in-app capte et enrichit l’intention pendant la session ; le push système relance uniquement si un signal justifie une sortie de l’application. Cette logique suppose une orchestration événementielle et non un calendrier d’envoi figé.

Un scénario retail type peut suivre cinq étapes. Premièrement, l’utilisateur consulte une catégorie dans l’application. Aucun push système n’est déclenché, mais un message in-app peut proposer de sélectionner un magasin pour afficher les stocks. Deuxièmement, l’utilisateur consulte trois fiches produits et choisit un magasin. Un in-app affiche la disponibilité locale et l’option de réservation. Troisièmement, il ajoute un produit au panier ou demande une alerte de stock. La marque dispose alors d’un signal fort. Quatrièmement, si l’utilisateur quitte l’application sans achat, un push système peut être envoyé après un délai contrôlé, par exemple deux heures pour un produit à achat rapide, vingt-quatre heures pour un achat plus réfléchi. Cinquièmement, après achat ou réservation, l’utilisateur est exclu des relances commerciales et bascule vers des notifications de service.

La fréquence doit être pilotée au niveau global. Un utilisateur ne raisonne pas en silos push, email, SMS, display, social et in-app. Il perçoit une pression cumulée. Un capping mature peut définir plusieurs seuils : maximum de notifications système commerciales par semaine, maximum de messages in-app par session, délai minimal entre deux sollicitations, exclusion après achat, réduction de pression après non-réaction répétée. Par exemple, une enseigne peut fixer une règle de 2 pushs système commerciaux maximum sur 7 jours, 1 message in-app principal par session et 0 relance système si l’utilisateur a déjà reçu un SMS promotionnel dans les dernières 48 heures.

La personnalisation doit également progresser au fil de la séquence. Répéter le même contenu en in-app puis en push système produit de la redondance. Le premier message peut aider au choix, le second rappeler une disponibilité ou une échéance. Exemple : en session, le message in-app indique que le produit est disponible dans le magasin de Lyon Part-Dieu avec retrait en deux heures. Hors session, si le panier est abandonné, le push système peut préciser que le stock est encore disponible jusqu’à ce soir. La relance apporte une information temporelle nouvelle, ce qui justifie mieux l’interruption.

Les exclusions sont centrales. Beaucoup de campagnes mobiles échouent non parce que le canal est mauvais, mais parce que les événements ne sont pas synchronisés. Un utilisateur achète en magasin après avoir vu un in-app, puis reçoit un push système de relance panier. Un client désactive les notifications commerciales mais continue à voir des interstitiels in-app agressifs. Un acheteur e-commerce reçoit un message drive-to-store pour le même produit. Ces incohérences dégradent la confiance et gonflent artificiellement les conversions attribuées. L’orchestration doit donc s’appuyer sur une CDP, customer data platform, plateforme permettant d’unifier et d’activer les données clients, ou sur un moteur de décision capable de réconcilier sessions, achats, opt-in, consentements, pression et stocks.

Intégrer les contraintes techniques et juridiques : permissions, OS, consentement et fatigue

Le push système dépend d’un écosystème technique que les marketeurs ne contrôlent pas entièrement. Les OS peuvent regrouper les notifications, limiter leur visibilité, filtrer les interruptions, introduire des résumés programmés ou renforcer les modes concentration. Sur iOS, le statut de permission est un actif critique : autorisé, refusé, provisoire, silencieux selon les cas et versions. Sur Android, l’évolution des permissions de notification a également renforcé la nécessité d’expliquer la valeur avant de demander l’autorisation. Une demande d’opt-in affichée trop tôt, avant que l’utilisateur ait compris l’utilité de l’app, peut réduire durablement la base adressable.

Le bon onboarding doit donc préparer la permission. Plutôt que de déclencher immédiatement la demande système, l’application peut afficher un écran pédagogique indiquant les bénéfices concrets : suivi de commande, alertes de stock, offres du magasin favori, rappels de rendez-vous. La demande doit être liée à une fonctionnalité perçue comme utile. Une app retail qui demande l’autorisation après que l’utilisateur a choisi son magasin ou demandé une alerte produit obtient généralement une permission plus qualifiée qu’une app qui demande tout à la première ouverture.

Le consentement doit être traité avec précision. Le RGPD, règlement général sur la protection des données, impose transparence, finalité déterminée, minimisation, droit d’opposition et preuve lorsque le consentement est requis. Une autorisation système de notification ne suffit pas toujours à couvrir tous les usages marketing, notamment lorsque la personnalisation repose sur des données de localisation, d’achat ou de comportement. Les équipes doivent distinguer notification de service, notification commerciale, personnalisation, géolocalisation et partage éventuel avec des partenaires. Un push géolocalisé déclenché à proximité d’un point de vente n’a pas la même sensibilité qu’un message in-app affiché après consultation d’un produit.

Le push in-app n’est pas exempt de contraintes. Il peut être perçu comme une forme de dark pattern, interface conçue pour orienter l’utilisateur vers un choix qu’il n’aurait pas pris librement, s’il bloque l’accès au contenu, rend la fermeture difficile ou force l’acceptation d’une offre. Il doit respecter la hiérarchie de l’expérience. Sur une page produit, un bandeau discret ou un module intégré peut être plus efficace qu’un pop-up plein écran. En checkout, toute interruption doit être justifiée par une réduction de friction, par exemple proposer un retrait plus rapide ou rappeler un avantage fidélité disponible, et non par une promotion secondaire qui détourne de l’achat.

La fatigue doit être mesurée comme un KPI à part entière. Les signaux incluent la baisse d’ouverture des notifications, la désactivation du canal, la désinstallation, la baisse de fréquence d’ouverture de l’application, la fermeture immédiate des in-app, l’augmentation des sessions courtes et la baisse de conversion post-exposition. Ces métriques doivent être suivies par segment. Un nouvel utilisateur peut tolérer une séquence d’onboarding dense pendant quelques jours ; un client fidèle peut attendre surtout des messages de service ; un dormant peut nécessiter une relance ponctuelle mais non une pression répétée.

Conclusion : une règle simple pour décider, une gouvernance stricte pour durer

Arbitrer entre push in-app et push système revient à répondre à une question : le message mérite-t-il d’interrompre l’utilisateur hors application, ou doit-il enrichir une session existante ? Si l’information est attendue, urgente, personnalisée et liée à une intention forte, le push système peut créer de la valeur. Si l’information guide un choix, réduit une friction ou personnalise un parcours en cours, le push in-app est souvent plus pertinent. Si le message n’apporte ni nouveauté, ni service, ni contexte, il ne devrait probablement être envoyé sur aucun des deux canaux.

Une feuille de route actionnable peut se structurer en huit décisions. Premièrement, classifier tous les messages en service, commerce, relationnel, géolocalisé, transactionnel ou fidélité. Deuxièmement, associer à chaque classe un canal prioritaire : système pour les alertes temporelles, in-app pour la guidance en session. Troisièmement, définir les signaux d’éligibilité : panier, stock, magasin favori, proximité, historique, statut fidélité, appétence, pression récente. Quatrièmement, fixer un capping omnicanal intégrant push système, in-app, SMS, email, social et display. Cinquièmement, construire des scénarios événementiels plutôt que des envois calendaires. Sixièmement, mesurer l’incrémentalité avec holdout ou tests de session, pas seulement l’ouverture et la conversion attribuée. Septièmement, intégrer les coûts relationnels : opt-out, désactivation, désinstallation, baisse d’engagement. Huitièmement, synchroniser les exclusions post-achat, les consentements et les événements magasin.

Le push système est puissant parce qu’il sort de l’application. C’est aussi sa limite. Le push in-app est plus respectueux du contexte parce qu’il intervient dans une session. C’est aussi sa contrainte. La maturité marketing consiste à ne pas confondre visibilité et efficacité. Une notification vue n’est pas forcément une notification utile ; un message discret peut générer plus de marge s’il intervient au bon moment. Dans un environnement mobile où l’attention se raréfie et où les permissions deviennent un actif stratégique, le canal gagnant n’est pas le plus bruyant. C’est celui qui respecte le contexte, exploite le signal juste et sait s’arrêter lorsque la valeur marginale disparaît.