Les nouveautés NAPPS : de juin à août 2026

Trois mois de nouveautés.

Les pages personnalisées ne dépendent plus de nous : c'est vous qui les créez. Vous choisissez maintenant qui reçoit chaque notification et quand elle doit attendre. Le tableau de bord d'analyse est disponible. Et l'app elle-même a une nouvelle apparence, sur des fondations plus rapides.

Voici ce qui a changé, dans l'ordre où cela devrait vous importer.

Les pages personnalisées sont disponibles

Jusqu'ici, une page personnalisée dans votre app voulait dire nous demander de la construire. C'est terminé.

Les pages personnalisées ont désormais leur propre éditeur. Il se place à côté de Home, PLP, PDP et Menu, et il fonctionne de la même façon : vous glissez des composants, vous les organisez, vous publiez. Vous connaissez déjà ces composants, car ce sont les mêmes que dans les autres éditeurs. Tout composant Expresso créé par votre équipe ou votre agence y est également disponible.

Chaque page peut être atteinte directement depuis votre navigation. Vous pouvez la prévisualiser telle qu'elle apparaîtra dans l'app, chercher parmi vos pages dès que vous en avez plusieurs, et placer les pages personnalisées derrière leur propre autorisation pour décider qui les modifie.

Guides des tailles. Histoires de marque. Instructions d'entretien. Pages de destination pour vos campagnes. Tout ce dont votre boutique a besoin et qu'une page de collection n'allait jamais pouvoir porter.

Les notifications : qui elles touchent et quand elles attendent

Deux changements. Ensemble, ils changent la fréquence à laquelle vous pouvez vous permettre d'envoyer.

Segments. Une notification peut désormais toucher une partie de votre audience au lieu de la totalité. Créez un segment une fois à partir du pays, de la langue et du statut du client (tout le monde, les clients enregistrés ou les utilisateurs anonymes de l'app), puis réutilisez-le. La liste des segments affiche la part de vos clients que chacun touche : vous connaissez la taille de l'audience avant l'envoi.

Heures de silence. Donnez à toute notification automatisée une fenêtre de silence, avec son heure de début, son heure de fin et son fuseau horaire. Le message de panier abandonné qui partait à 3 heures du matin attend maintenant le matin. Le fuseau horaire est respecté notification par notification : une boutique qui vend sur trois marchés n'a plus à en choisir un seul.

Une vraie destination pour chaque envoi. Une notification peut maintenant ouvrir la liste de souhaits, le menu, le fil Drops, le profil du client, une page personnalisée ou n'importe quel lien, en plus des destinations produit, collection, commande et panier que vous aviez déjà. Fini d'envoyer quelqu'un sur l'écran d'accueil en espérant qu'il trouve.

Leur gestion est aussi plus simple. Vous pouvez chercher parmi les notifications, chacune affiche son audience sur sa fiche, et les notifications automatisées acceptent des traductions : le message se lit correctement sur chaque marché où vous vendez.

Le tableau de bord d'analyse est disponible

Votre app rend maintenant compte d'elle-même, dans le tableau de bord, à côté du reste.

Il répond aux questions auxquelles l'interface d'administration de votre boutique ne peut pas répondre : quels produits sont vus mais pas ajoutés au panier, ce que les gens cherchent sans rien trouver, quel contenu des notifications push génère réellement du chiffre d'affaires, comment se comporte chaque format de Drop, et quelle part de votre base installée vous pouvez joindre avec une notification.

Le chiffre d'affaires des notifications push et des Drops est attribué dans une fenêtre de 12 heures et compté dans la devise de chaque commande. Cette fenêtre est un choix, tout comme le fait de garder ces chiffres séparés de ceux de Shopify, de l'e-mail et de la publicité payante. Si vous voulez le raisonnement, et un cadre pour savoir quel chiffre appartient à quel système, nous l'avons écrit ici : les indicateurs d'app mobile pour les marques Shopify.

Pour que ces rapports soient précis, il a fallu du nouveau travail dans l'app : depuis quelle carte et quelle mise en page un produit a été touché, d'où vient chaque ajout à la liste de souhaits, et le suivi au niveau de l'écran. C'est la différence entre savoir que votre app convertit et savoir quelle décision de merchandising l'a permis.

Une nouvelle apparence, et une barre de navigation que vous contrôlez

Nous avons reconstruit la navigation et les barres d'outils de l'app autour d'un matériau de verre. Barre inférieure translucide, barres de verre sur Home, PLP, PDP, la recherche, le menu, la liste de souhaits et le profil, un indicateur en forme de pilule qui glisse d'un onglet à l'autre, et une barre qui s'escamote sur les écrans où le contenu compte plus que la navigation.

La barre inférieure est aussi configurable, là où elle était fixe :

• Choisissez quelles pages apparaissent, et dans quel ordre.
• Choisissez une icône par élément dans la bibliothèque d'icônes, ou revenez aux valeurs par défaut.
• Traduisez chaque libellé.
• Définissez les couleurs de la barre dans le thème.
• Utilisez une barre de verre flottante sur Android, et plus seulement sur iOS.

L'essentiel à savoir sur le verre : il s'adapte au téléphone, sur les deux plateformes.

L'app lit le niveau de performance de l'appareil et réduit l'effet sur le matériel de milieu de gamme. Sur les appareils Android d'entrée de gamme, et sur Android 12 et antérieurs, elle revient à des barres opaques. Sur iOS 18 et antérieurs, le client obtient la barre inférieure native de cette génération, celle qu'il connaît déjà dans toutes les autres apps du téléphone.

Personne ne reçoit une app lente pour le plaisir d'une jolie barre. Votre client équipé d'un téléphone de trois ans reçoit la version qui tourne bien dessus.

Une app plus rapide

L'essentiel est invisible, et c'est le but.

• Toutes les pages se chargent en dehors du thread principal : l'app continue de répondre pendant qu'elle travaille.
• Les composants se chargent à la demande, partout. L'app précharge les composants que le client est sur le point de voir et ignore ceux qu'il n'atteindra pas. Rien ne se charge simplement parce qu'il se trouve plus bas dans la page.
• Le travail de rendu a été réduit à plusieurs endroits, dont le bouton d'ajout au panier de la PDP, les stories produit, Drops et la barre inférieure.
• Drops précharge toujours la vidéo suivante : le fil ne s'interrompt pas entre deux clips. Les données de Drops se préchargent après Home et Menu, dans cet ordre.
• C'est le chargement à la demande qui allège la mémoire et le processeur. Le préchargement en dépense une partie volontairement, là où il achète un premier écran plus rapide. Au-delà, le cache réseau est plafonné, et quand le téléphone signale qu'il manque de mémoire, l'app vide son cache en mémoire au lieu d'attendre d'être fermée.

Plantages et corrections : l'app ne plante plus à l'ouverture sans connexion, ni pendant l'onboarding, ni sur certains retours en arrière. La vidéo s'arrête quand l'app passe en arrière-plan. Une fuite de mémoire dans la couche de rendu est corrigée.

La confidentialité, détaillée

Votre app demandait déjà le consentement pendant l'onboarding. Ce qui a changé, c'est ce que le client peut voir et décider à cette étape.

L'étape de confidentialité indique maintenant ce qui est collecté et à quelle fin, section par section, et propose un interrupteur par section au lieu d'un seul oui ou non global. Un client prêt à aider sur un point et pas sur un autre peut le dire précisément, dès la première ouverture, sans chercher dans les réglages.

Nous l'avons changé pour le RGPD. Cette raison a dicté deux décisions : indiquer ce que chaque section collecte, et permettre au client d'accepter une finalité sans accepter les autres. Ce dont votre boutique a besoin pour être en conformité relève de votre équipe juridique, et cette étape de consentement est assez précise pour qu'elle puisse s'appuyer dessus.

Chaque message et chaque description sont traduits dans 16 langues, y compris l'invite de suivi d'Apple : le client les lit dans sa langue et non en anglais. Sa réponse est respectée partout où l'app envoie des données, et il peut la modifier plus tard depuis ses préférences de confidentialité.

Les données essentielles et de performance continuent d'être collectées dans tous les cas, car sans elles l'app ne peut ni fonctionner ni rester stable. Aucune donnée personnelle ne circule avant un accord.

Boutiques, stock et retrait

Pour les marques avec des boutiques physiques :

• Click and Collect sur la page produit, avec la disponibilité affichée par variante.
• Une boutique préférée qui est conservée, avec un sélecteur de boutiques trié et une disponibilité qui se met à jour quand le client change de boutique.
• La navigation depuis la page produit vers la disponibilité en boutique.
• Une option de restriction géographique, pour limiter l'accès à l'app selon la localisation.

Améliorations de confort dans le tableau de bord

• Dupliquez un éditeur en le nommant, et emportez ses traductions avec lui.
• Importez une mise en page depuis un éditeur existant au lieu de repartir de zéro.
• Programmez les mises en page de PDP, comme vous programmez déjà Home et Menu.
• Réinitialisez un thème, ou les icônes, aux valeurs par défaut.
• Effacez les données d'une collection en une seule action, avec une confirmation avant d'abandonner des modifications de traduction.
• La gestion de la zone de sécurité sur la PLP : les produits de la collection ne sont plus rognés.

Pour vos développeurs et votre agence

Expresso a gagné ce trimestre un véritable environnement d'exécution et de véritables outils.

L'environnement d'exécution prend maintenant en charge les API JavaScript standard dont un vrai composant a besoin : fetch avec données de formulaire, multipart et flux, WebSocket, Web Streams, Web Crypto, Compression, URL et URLPattern, TextEncoder, Blob, Performance et minuteurs. La génération des définitions TypeScript s'est améliorée : écrire un composant s'appuie sur de vrais types et une vraie autocomplétion.

Les outils sont nouveaux : un arbre d'interface que vous pouvez inspecter, le rechargement à chaud, les journaux de console recopiés dans les devtools intégrés aux deux plateformes, et des sessions de développement délimitées qui injectent un composant dans une app en cours d'exécution. Le tout repose sur une série de tests couvrant le SDK, la couche de rendu et les éditeurs Home, PLP et PDP.

Les composants personnalisés peuvent désormais être placés dans les pages personnalisées, et les composants personnalisés de page produit émettent des événements. Les agences s'authentifient auprès d'une API partenaires avec un accès par client et choisissent la boutique sur laquelle elles travaillent.

Vous voulez activer l'un de ces éléments, ou voir une démonstration des segments et du tableau de bord d'analyse ?