Application WooCommerce : pourquoi une simple WebView risque un refus Apple
Une application WooCommerce réduite à une WebView coûte peu, mais s’expose au refus d’Apple au titre de la règle 4.2, dite de fonctionnalité minimale. Une application Flutter connectée à WooCommerce par son API garde un seul back-office et apporte Apple Pay, des notifications utiles et le hors-ligne, pour 6 000 à 14 000 € HT en fourchette indicative.
Vous avez une boutique WooCommerce qui fonctionne et vous voulez une application WooCommerce sur l’App Store et Google Play. La solution la plus rapide consiste à afficher le site dans une WebView, une coque d’application qui charge vos pages web. Elle coûte peu, mais elle expose à un refus d’Apple au titre de la règle 4.2. L’autre voie, c’est la création d’application e-commerce native, connectée à WooCommerce par son API.
Chez AppliWin, je développe des applications Flutter pour iOS et Android reliées à WordPress et WooCommerce : un seul back-office pour le site et les deux applications. Voici ce que dit vraiment la règle 4.2, le comparatif honnête entre WebView et application native, la façon de synchroniser l’application avec la boutique, et le budget à prévoir.
La règle 4.2 d’Apple : ce qu’elle dit vraiment
La règle 4.2 des App Review Guidelines demande qu’une application apporte des fonctionnalités, du contenu et une interface qui vont au-delà d’un site web reconditionné. Une boutique WooCommerce affichée telle quelle dans une WebView, sans rien de plus que le site, correspond exactement au cas visé : c’est un motif de refus classique, dit de « fonctionnalité minimale ».
Apple précise que si une application n’est pas particulièrement utile, unique ou ne ressemble pas à une application, elle n’a pas sa place sur l’App Store. La règle 4.2.2 ajoute qu’en dehors des catalogues, une application ne doit pas être principalement un support marketing, un extrait de site web ou une collection de liens. Cette exception ne dispense pas un catalogue de la règle 4.2 : il doit lui aussi offrir une vraie expérience d’application. En pratique, si l’application n’offre rien de plus que le site ouvert dans Safari, le refus est probable.
Une WebView n’est pas interdite en soi. Beaucoup d’applications acceptées en contiennent, pour des pages secondaires comme les conditions générales ou le blog. Ce qui pose problème, c’est une application qui n’est qu’une WebView. Google Play est plus tolérant, mais ses règles sur les fonctionnalités minimales et les expériences de mauvaise qualité existent aussi. Pour un site surtout éditorial, l’article sur la façon de transformer un site WordPress en application compare les deux approches ; ici, je me concentre sur la boutique.
Ce qui fait la différence aux yeux d’Apple
Une application e-commerce passe la review quand elle offre ce que le site ne peut pas offrir. Les éléments qui pèsent le plus :
- Une navigation native par onglets : accueil, catalogue, panier, compte
- Des notifications push utiles : expédition, retour en stock, offre réservée aux clients de l’app
- Un compte client persistant, avec connexion par Face ID ou empreinte digitale
- Le paiement Apple Pay en un geste
- Un catalogue et un historique de commandes consultables hors connexion
- Des fonctions du téléphone : scanner un code-barres, partager un produit, retrouver un point de vente
WebView ou application native : le comparatif
Une coque WebView coûte peu et se met à jour avec le site, mais elle hérite de sa lenteur, s’intègre mal au téléphone et reste exposée au refus d’Apple. Une application Flutter connectée à WooCommerce par API offre une navigation fluide, Apple Pay, des notifications utiles et un catalogue consultable hors ligne, pour un budget plus élevé.
| Critère | Coque WebView | Application Flutter + API |
|---|---|---|
| Validation App Store | Risque élevé de refus (règle 4.2) | Conforme si l’app apporte une vraie valeur |
| Vitesse perçue | Celle du site mobile, rechargement des pages | Écrans natifs, images en cache |
| Paiement | Tunnel web dans l’application | Apple Pay et Google Pay natifs via Stripe |
| Notifications push | À ajouter, souvent limitées | Commande expédiée, retour en stock, panier abandonné |
| Hors connexion | Page d’erreur | Catalogue et commandes consultables |
| Maintenance | Suit le site automatiquement | Une application à faire évoluer, mais un seul code |
| Budget | Faible | 6 000–14 000 € HT (fourchette indicative) |
Il existe une voie médiane : des écrans natifs pour tout ce qui fait vendre (accueil, catalogue, fiche produit, panier, compte, suivi de commande) et une WebView pour les pages éditoriales. C’est souvent le meilleur rapport entre budget, expérience et conformité, et c’est le principe d’une application mobile connectée à WordPress : le contenu reste géré dans le même back-office.
Synchroniser l’application avec WooCommerce via l’API
L’application ne remplace pas WooCommerce : elle le lit et l’alimente en temps réel. Le catalogue, les stocks et les prix viennent de l’API de WooCommerce ; le panier et la commande y sont créés ; les comptes clients sont partagés avec le site. Un seul back-office pilote la boutique web et les deux applications.
- Store API (
/wp-json/wc/store/v1/) : produits, panier et validation de commande côté client, sans clé d’administration. - API REST WooCommerce (
/wp-json/wc/v3/) : opérations d’administration. Ses clés ne doivent jamais être embarquées dans l’application ; elles restent côté serveur, derrière une API sur mesure. - Authentification par jeton (JWT) pour le compte client, l’historique de commandes et les adresses.
- Webhooks WooCommerce reliés à Firebase Cloud Messaging pour les notifications : commande expédiée, produit de retour en stock.
- Images optimisées en WebP et mises en cache pour un catalogue fluide, même en 4G faible.
- Paiement Stripe avec Apple Pay et Google Pay : pour des biens physiques, Apple n’impose ni achat intégré ni commission (règle 3.1.3(e)).
Le piège classique tient aux extensions. Abonnements, réservations, champs personnalisés, programmes de fidélité : beaucoup d’extensions WooCommerce n’exposent pas leurs données dans l’API standard. Je l’audite au cadrage et j’écris les routes manquantes. Sur LSF-CFB, qui vend des contenus numériques sans WooCommerce, j’ai appliqué la même logique : l’application Flutter dialogue avec une API REST sur mesure construite au-dessus de WordPress, qui gère catalogue, abonnements, locations et historique des paiements pour les versions iOS, Android et web.
Coût d’une application WooCommerce
Comptez entre 6 000 et 14 000 € HT pour une application e-commerce iOS et Android connectée à WooCommerce, en fourchette indicative. Le prix dépend du nombre d’écrans spécifiques, des extensions à reprendre, du paiement et des notifications. Un site WordPress transformé en application plus simple se situe plutôt entre 4 000 et 9 000 € HT.
Ce qui fait varier le prix d’une application WooCommerce :
- les types de produits à gérer : simples, variables, groupés, abonnements ou réservations ;
- le nombre d’extensions WooCommerce dont les données doivent remonter dans l’application ;
- un design sur mesure ou la reprise fidèle de votre charte existante ;
- des notifications segmentées (par client, par catégorie, par panier) plutôt que génériques ;
- le multilingue et la gestion de plusieurs devises.
Ajoutez les frais récurrents : 99 $ par an pour le compte Apple Developer, 25 $ une seule fois pour Google Play, et une maintenance annuelle, car Apple et Google relèvent chaque année les versions minimales exigées. Le détail des postes est sur la page prix d’une application mobile. Si c’est la boutique elle-même qui doit évoluer, voyez plutôt la création d’un site WooCommerce sur mesure.
Avant de lancer l’application, vérifiez ces points :
- La boutique répond vite : une API lente donne une application lente
- Les extensions indispensables exposent leurs données ou peuvent l’être
- Les comptes Apple Developer et Google Play sont ouverts au nom de votre entreprise
- La politique de confidentialité couvre l’application et ses notifications
- La suppression du compte client est possible depuis l’application
À retenir
Une application WooCommerce réduite à une WebView est un pari risqué face à la règle 4.2 d’Apple.
Une application Flutter reliée à WooCommerce par API garde un seul back-office, apporte Apple Pay, les notifications et le hors-ligne, et passe la validation sur ses mérites.
Questions fréquentes
WebView ou API REST : comment l’application lit-elle le catalogue WooCommerce ?
Deux approches existent : une coque WebView qui affiche le site, rapide mais exposée au refus d’Apple, ou une application native ou Flutter qui interroge WooCommerce par son API. Dans le second cas, les produits, les stocks, les prix et les commandes restent gérés dans WooCommerce : vous continuez à travailler dans le même back-office, et l’application se met à jour en temps réel. C’est le principe d’une application mobile boutique en ligne branchée sur votre catalogue.
Quelles règles Apple s’appliquent à une application WooCommerce ?
Deux règles comptent : la 4.2, sur la fonctionnalité minimale, détaillée plus haut, et la 3.1.3(e), sur le paiement. Pour des biens physiques ou des services consommés hors de l’application, Apple interdit l’achat intégré : il faut un autre moyen de paiement, comme la carte bancaire, Apple Pay ou Google Pay (règle 3.1.3(e)). Vous ne payez donc que les frais de votre prestataire de paiement, comme sur votre site. La commission (15 à 26 % dans l’Union européenne, jusqu’à 30 % ailleurs) ne concerne que les contenus numériques.
Une application en WebView est-elle toujours refusée ?
Non, mais elle part avec un handicap. Apple accepte des applications qui contiennent des WebView quand elles apportent une vraie valeur ajoutée : écrans natifs, notifications utiles, fonctions du téléphone, contenu exclusif. Une coque qui ne fait qu’afficher le site existant est en revanche régulièrement refusée au titre de la fonctionnalité minimale, et chaque nouvelle soumission prend du temps.
Construire une application qui vend vraiment
Une application WooCommerce réussie n’est pas une copie du site : c’est un canal de fidélisation, branché sur le même back-office. Pour aller plus loin sur les règles d’Apple, lisez comment vendre des formations avec les achats intégrés, ou découvrez l’architecture d’une application comme Vinted. Et pour chiffrer votre application, décrivez votre boutique sur la page demande de devis.