Votre app Shopify est-elle une webview ? Une vérification en cinq minutes

Vous payez entre 500 et 2 000 dollars par mois pour votre app mobile « native premium ». Le marketing dit native. L'argumentaire commercial disait native. Mais quand le client ouvre votre programme de fidélité, le chargement traîne. Quand il regarde des vidéos produit, le défilement saccade. Quand il utilise vos composants personnalisés, quelque chose cloche.

Une bonne partie d'une app « native » ne l'est peut-être pas. Il peut s'agir de webviews, c'est-à-dire de pages web intégrées et affichées à l'intérieur de l'app. Vous payez alors un tarif premium pour une expérience qui se comporte comme le site mobile.

Soyons clairs : une webview bien construite peut être tout à fait utilisable, et une app native mal construite peut être lente. Cet article vous aide à voir comment sont affichés les écrans critiques pour le chiffre d'affaires, afin que vous sachiez ce que vous payez.

Cet article compare le natif et la webview sur les fonctionnalités qui comptent le plus (programmes de fidélité, achat par vidéo et composants personnalisés), montre ce que chaque technologie apporte réellement et à quel prix, et vous donne un test de cinq minutes pour savoir laquelle vous avez.

Les implémentations en webview peuvent ralentir l'expérience client, rendre l'app moins distinctive et réduire le retour sur l'investissement. Beaucoup de marques ne voient pas la différence avant d'avoir signé un contrat.

Le natif et la webview, définis

Avant de comparer les fonctionnalités, voici ce que sont réellement ces deux approches.

Le développement natif signifie que l'interface est écrite dans le langage propre à la plateforme et compilée pour s'exécuter directement sur l'appareil : Swift avec SwiftUI sur iOS, Kotlin avec Jetpack Compose sur Android. Il peut offrir des animations fluides, une navigation réactive et un accès complet aux fonctions et aux gestes de l'appareil.

Le développement en webview signifie que l'interface est du HTML, du CSS et du JavaScript affichés dans un cadre de navigateur intégré à l'app (WKWebView sur iOS et Android WebView). Elle se comporte davantage comme un site mobile et peut introduire des délais de chargement, des interactions moins réactives, un accès limité à l'appareil et une navigation de type navigateur.

Les apps hybrides (mixtes) sont courantes. Certains écrans sont natifs et d'autres sont des webviews dans la même app. La structure et quelques écrans peuvent être natifs pendant que les fonctionnalités critiques pour le chiffre d'affaires utilisent des webviews. Quand cet article demande si une app est une webview, il demande si les écrans qui comptent sont affichés en webview. La plupart des apps réelles sont mixtes : testez donc les écrans qui pèsent sur le chiffre d'affaires.

Pour le contexte plus large sur la façon dont les apps sont construites et sur le coût de chaque approche, voir le guide pour transformer une boutique Shopify en app mobile.

Quand une webview convient, et quand elle ne convient pas

Tout usage de webview n'est pas un problème. Certains contenus ont réellement leur place en web, là où la performance ne fait pas bouger un indicateur commercial.

Le problème est que la plupart des plateformes utilisent des webviews pour les deux colonnes. Votre programme de fidélité est traité comme vos conditions d'utilisation, et les fonctionnalités qui génèrent du chiffre d'affaires héritent de la performance de celles qui n'en génèrent pas.

Le paiement est un cas à part : les apps Shopify le gèrent avec le Checkout Kit de Shopify, pas avec une webview ni un développement natif sur mesure contrôlé par le prestataire de l'app. Il relève du côté natif, mais le test natif contre webview de cet article ne s'y applique pas comme il s'applique à la fidélité, à la vidéo ou aux composants personnalisés.

Comment savoir laquelle vous avez

Comment utiliser ces vérifications. N'étiquetez pas une app entière comme « native » ou « webview », car la plupart sont mixtes. Faites les huit vérifications ci-dessous sur les écrans critiques pour le chiffre d'affaires : fidélité, vidéo, produit et composants personnalisés. Un indice isolé peut être un choix de conception. Plusieurs sur le même écran justifient de demander au prestataire comment cet écran est construit. C'est un test de comportement que vous pouvez faire avec votre propre téléphone, pas une revue du code source.

Vous pouvez les faire en cinq minutes environ, sans développeur. Ouvrez votre app et testez chaque écran. Un résultat isolé peut être une coïncidence. Plusieurs ensemble méritent une réponse du prestataire.

La vérification la plus rapide est le mode avion. Une webview n'a rien à afficher quand elle ne peut pas joindre le web ; une app native, si.

Vous pouvez aussi poser deux questions à votre prestataire : « L'interface est-elle construite avec SwiftUI et Jetpack Compose, ou est-ce un WKWebView ou un Android WebView qui enveloppe notre site ? » et « Si elle est native, pourquoi se comporte-t-elle comme un navigateur aux tests ci-dessus ? ». Méfiez-vous des formules évasives comme « elle utilise des technologies web pour la souplesse » ou du mot « hybride » employé pour masquer la réalité. Afficher les pages de votre site dans un cadre reste une app fondée sur une webview, quel que soit le nom employé sur la page tarifaire.

Programmes de fidélité : natif contre webview

Les programmes de fidélité déclenchent le réachat et augmentent la valeur client à long terme. Ils sont trop importants pour reposer sur une technologie lente, et ce sont pourtant l'une des fonctionnalités que les plateformes affichent le plus souvent en webview sans le dire.

Un écran de fidélité rapide permet au client de consulter et d'utiliser ses points sans effort, et il donne l'impression de faire partie de l'app. Un écran lent en webview peut décourager son usage et faire paraître le programme extérieur à l'app. Dans les deux cas, vous payez peut-être toujours Yotpo ou Smile.io : la mise en œuvre compte donc. La fidélité dans l'app fonctionne mieux quand le client peut la voir et l'utiliser facilement.

Prix premium, mise en œuvre au rabais. Represent, une marque de streetwear, fait tourner son app sur Venn Apps, dont le forfait publié le plus bas commence à 1 999 dollars par mois, avec des tarifs sur mesure « contactez-nous » au-dessus pour les marques qui ont besoin de plus de personnalisation. Une marque de la taille de Represent se situe presque certainement sur ce palier supérieur sur mesure et peut avoir négocié son propre accord. Le chiffre réel dépasse donc le tarif d'entrée de 1 999 dollars, sans correspondre exactement à ce nombre. Et malgré tout cela, l'app fait toujours tourner un programme de fidélité dans une app fondée sur une webview où le client se connecte deux fois : une fois pour l'app, une fois pour la fidélité. Délai de chargement, authentification séparée, incohérence visuelle. Voilà ce que « premium » peut vouloir dire en pratique.

Achat par vidéo : natif contre webview

L'achat par vidéo stimule l'engagement et la conversion. TikTok a prouvé que le client veut un fil vidéo qu'on fait défiler, mais seule une implémentation native produit vraiment cette sensation.

La vidéo exige beaucoup de performance : les limites de la webview se voient donc ici plus qu'ailleurs. En natif, le client fait défiler sans à-coups, touche des étiquettes produit qui répondent immédiatement et regarde généralement plusieurs vidéos par session. En webview, il attend le chargement de chaque clip, les étiquettes réagissent en retard et la plupart des clients partent après une ou deux vidéos. Le client ressent immédiatement l'écart entre TikTok (natif) et un fil en webview, même s'il ne sait pas le nommer. Une expérience vidéo native passe par une intégration directe avec des prestataires comme Videowise ou Tolstoy, en utilisant le lecteur vidéo et la gestion des gestes de la plateforme elle-même plutôt qu'un lecteur web intégré.

Composants personnalisés : natif contre webview

Les composants personnalisés sont ce qui différencie votre marque : configurateurs de produit, parcours de composition de coffret, sélecteurs d'abonnement, mises en page uniques. C'est aussi là que le marketing du « développement sur mesure » cache le plus souvent du code web.

Les prix de cet article sont des prix catalogue mensuels, vérifiés le 29 octobre 2026 : les forfaits NAPPS d'après notre grille actuelle, et Venn Apps d'après sa page de tarifs publique. Les autres fourchettes sont des chiffres courants du marché, pas des devis d'un fournisseur précis.

Un composant natif se conçoit dans Figma, se construit pour iOS et Android dans votre système de design exact, avec des animations fluides et un accès complet à l'appareil, la logique métier étant écrite en TypeScript. Un composant en webview est du code web affiché dans un cadre : contraint par les limites du web, avec des animations heurtées, des gestes qui ne se comportent pas comme en natif et une performance qui se dégrade à mesure que le composant se complexifie. Pour un exemple réel, voir comment Planeta Huerto a reconstruit six composants natifs de sa page produit, une marque d'alimentation biologique dont l'app native a remplacé des composants en webview par des composants natifs sur mesure dans son système de design exact.

Des « Custom Blocks » qui ne sont pas natifs. Tapcart commercialise des apps natives, mais sa principale fonctionnalité de personnalisation, les « Custom Blocks », est un éditeur HTML, CSS et JavaScript : vous écrivez du code web qui s'affiche dans une app fondée sur une webview. Ce n'est pas du développement natif. C'est intégrer une page web dans votre app, au tarif d'un plan Enterprise.

Pourquoi les plateformes facturent un tarif premium pour une webview

Si construire en webview coûte moins cher, pourquoi les plateformes facturent-elles autant ? Pour quatre raisons :

• Les tarifs du marché. Elles facturent ce que le marché accepte. Si les marques paient 2 000 dollars par mois, rien ne pousse à baisser les prix.
• Le positionnement enterprise. « Développement sur mesure » sonne premium, même quand il s'agit de HTML et de CSS.
• L'absence d'alternative, jusqu'à récemment. Les marques ne pouvaient pas obtenir du natif à un prix raisonnable, elles n'avaient donc pas le choix.
• L'écart de connaissance. La plupart des marques ne distinguent pas le natif de la webview avant d'avoir signé.

Ce dernier point explique tout, et c'est pourquoi le test de cinq minutes ci-dessus compte.

Que faire s'il s'agit bien d'une webview

Découvrir que votre app utilise des webviews n'est pas une crise. Vous pouvez changer de prestataire sans perdre votre fiche, vos avis ni votre base d'installations. Planeta Huerto, une marque d'alimentation biologique, est passée d'une app en webview à une app native et a amélioré les résultats du canal app, avec une dépense par client supérieure de 47 % et un taux de réachat de 72 %. Un relancement n'est pas un test à une seule variable. Le travail de fidélisation, les promotions et le calendrier ont changé en même temps que la migration : lisez donc ce résultat comme un indice directionnel plutôt que comme une preuve de causalité.

L'écart de performance apparaît le plus nettement sur le canal qu'une app native est censée alimenter : les notifications push. En natif, toucher une notification ouvre une session instantanée, déjà connectée et avec le panier intact ; en webview, elle ouvre la même page web mobile lente que le client venait de quitter, si bien que le canal stagne au lieu de se renforcer. Nous traitons ce point dans l'analyse des notifications push et de la fidélisation, y compris le taux de conversion de l'app de Zippy de 7,20 % contre 1,53 % sur le web mobile. Cet écart est lui aussi directionnel, pas une preuve de l'effet du natif seul : les utilisateurs d'app sont généralement les clients les plus engagés et à la plus forte intention d'achat avant même d'installer l'app, si bien que l'auto-sélection joue autant que l'expérience native.

Deux choses rendent le changement plus simple qu'il n'y paraît : un bon prestataire couvre le temps restant sur votre contrat actuel pour que vous ne payiez pas deux fois (NAPPS vous offre ces mois), et vous pouvez construire la version native et lui faire passer les huit tests ci-dessus avant de la publier.

Si le natif n'entre pas encore dans le budget

Le natif a la réputation d'être cher et, historiquement, il l'a méritée : les plateformes d'apps facturent entre 1 000 et 2 000 dollars par mois pour un développement natif, et un développement entièrement sur mesure en agence coûte entre 150 000 et 200 000 dollars au départ, plus la maintenance. Même le palier sur mesure le plus complet de NAPPS sur le forfait Enterprise (999 dollars par mois) n'est pas réaliste pour toutes les marques. Voici les conseils honnêtes si vous n'y êtes pas encore.

Option 1 : commencez plus petit et ajoutez des composants natifs à mesure que vous grandissez. Vous n'avez pas besoin du forfait le plus élevé pour obtenir des composants natifs personnalisés. Vous pouvez commencer sur le forfait Business à 299 dollars par mois, qui inclut Expresso (la couche de composants natifs de NAPPS, où les écrans sur mesure sont construits en SwiftUI et Jetpack Compose plutôt qu'en webview). Expresso est inclus sans frais dans tous les forfaits. Cela met de vrais composants natifs à partir de 299 dollars par mois, sans passer directement au palier enterprise.

Option 2 : attendez et investissez ailleurs. Si même cela n'est pas réaliste, ne construisez pas encore d'app. Une app lente en webview qui frustre le client fait plus de mal que pas d'app du tout : les avis négatifs et les mauvaises premières impressions restent. Ce budget rapporte davantage en photographie produit, en conversion sur le site, en e-mail, en service client ou en stock. Construisez d'abord l'activité, puis ajoutez l'app quand le public est prêt.

Option 3 : commencez par une app web (PWA), dans un cas précis. Si vous avez des achats à fréquence élevée (alimentation, abonnements, consommables) et que vous devez être sur le téléphone de vos clients maintenant, une Progressive Web App place une icône sur l'écran d'accueil pour un faible coût unique. Le revers : une PWA est entièrement du contenu web, elle n'est pas dans l'App Store et iOS limite ses notifications. C'est un pont, pas une destination. La règle honnête : une bonne app web vaut mieux qu'une mauvaise app native, mais une vraie app native vaut mieux que les deux. Commencez par une PWA, faites grandir le public et migrez vers le natif quand vous le pouvez.

Comparez le natif et la webview sur votre propre boutique

Lire une comparaison ne mène que jusqu'à un certain point ; la différence de performance se ressent. NAPPS, une plateforme de création d'apps mobiles natives pour les marques Shopify et Shopify Plus, construira votre boutique en app native avec vos vrais produits et vous montrera la comparaison côte à côte : la fidélité qui se charge en une fraction de seconde, un fil vidéo qui se comporte comme TikTok et des composants personnalisés construits dans le design exact de votre marque. La différence est en général évidente en trente secondes, et c'est celle que vos clients ressentent déjà chaque fois qu'ils ouvrent votre app.

Si vous quittez un prestataire de webview, NAPPS couvre le temps restant sur votre contrat actuel, et ces mois sont à notre charge. L'app est gratuite jusqu'à ce que vous soyez prêt à la publier : vous pouvez donc faire la comparaison avant de vous engager.

Réservez un appel de 20 minutes et comparez le natif à la webview sur votre catalogue

En résumé

Vous payez pour une technologie qui devrait servir l'activité. Les implémentations en webview peuvent brider les fonctionnalités qui génèrent du chiffre d'affaires. Les implémentations natives peuvent offrir plus de contrôle, mais la qualité dépend toujours de la façon dont chaque écran est construit. Utilisez les tests ci-dessus pour comprendre ce que vous avez, puis décidez si l'implémentation actuelle fait le travail.

Réservez un appel de 20 minutes et voyez la différence sur votre propre boutique