Planeta Huerto, du webview au natif : toutes les métriques ont progressé, à l'échelle d'une marketplace

« Toutes les statistiques de l'App Store explosent par rapport aux performances passées, du temps où ils utilisaient des webviews. »

Albert MiraDirecteur technique, Planeta Huerto

À propos de Planeta Huerto

Planeta Huerto est un distributeur espagnol de produits de santé et d'alimentation bio sur Shopify Plus, avec l'un des catalogues les plus vastes et les plus complexes de sa catégorie. Ses fiches produit sont très fortement pilotées par la donnée : informations vendeur, prix par palier, filtres alimentaires et logique de collection sont tous encodés dans des metafields et des metaobjects. À cela s'ajoute une marketplace opérée avec Mirakl : un seul catalogue mêle donc des produits que Planeta Huerto vend et expédie directement à des produits de vendeurs tiers, chacun avec ses propres règles de vendeur, d'expédition et de livraison.

Le problème

L'app de Planeta Huerto devait sembler native, sur un catalogue de marketplace que la plupart des créateurs d'apps ne savent même pas modéliser.

Le site de Planeta Huerto est réellement bien optimisé. Le problème d'une app en webview ne vient pas du site qu'elle charge : c'est que le webview enveloppe ce site dans une coque native, et que les deux modèles d'interaction se contrarient. Les gestes natifs comme le balayage, le défilement et le geste retour du système entrent en collision avec la navigation et les gestes propres du site, si bien que l'app sonne faux d'une manière que les clients remarquent, même quand chaque page s'affiche correctement.

En dessous se trouvait l'objection la plus difficile pour tout distributeur complexe : aucun créateur d'apps ne peut reconstruire ce que nous avons encodé dans notre thème, et encore moins notre logique de marketplace. Les fiches produit de Planeta Huerto comportent six composants distincts pilotés par des metafields, et une marketplace Mirakl tourne sous l'ensemble du catalogue. Il leur fallait des composants natifs avec un accès complet aux metafields et aux metaobjects, une gestion native des produits marketplace face aux produits directs, et un modèle d'interaction qui se comporte comme une app au lieu de lutter contre elle.

Il y avait une seconde crainte, liée au coût. Planeta Huerto savait exactement combien de travail son équipe avait investi dans ces composants sur le site, et supposait qu'une plateforme facturerait des tarifs de développement sur mesure grand compte pour les reconstruire, autour de 2 000 à 3 000 $ par mois, ou les obligerait à tout simplifier pour tenir dans un modèle. Aucune des deux options n'était acceptable. Ces composants existaient pour une raison.

La solution

NAPPS a reconstruit en natif chaque composant de fiche produit sur Expresso, et Planeta Huerto est devenu le premier client à tourner dessus, et le premier à le prouver à grande échelle.

Expresso est la couche de NAPPS qui traduit React et TypeScript en natif : elle transforme React et TypeScript en véritables composants SwiftUI et Jetpack Compose, et non en encapsulations web. Planeta Huerto a été le premier client construit sur Expresso, et son catalogue en a été le premier vrai test de résistance. Un catalogue vaste, très riche en metafields et adossé à une marketplace, c'est exactement le type de charge qui expose les limites d'une app en webview, et un premier test exigeant pour une plateforme entièrement native. Si Expresso tenait ici, il tiendrait partout.

Deux éléments ont permis à la reconstruction de fonctionner :

1. Un accès complet aux metafields et aux metaobjects. Chaque donnée produit que Planeta Huerto avait encodée dans son thème était accessible aux composants natifs, donc rien n'a eu besoin d'être simplifié ni abandonné pour entrer dans l'app.
2. Une gestion native de la marketplace. L'app récupère les données de marketplace à la fois depuis les metafields produit et depuis l'intégration Mirakl, et affiche correctement les produits marketplace et directs : le bon vendeur, le bon coût d'expédition, et des estimations de livraison qui changent selon le type de vendeur et le jour de la semaine. La marketplace a cessé d'être quelque chose que l'app devait cacher dans une page web.

Tout cela sans imposer de choix sur le prix. Les six composants étaient inclus dans l'offre de Planeta Huerto, et non facturés comme du développement sur mesure grand compte, ce qui répondait à la crainte qu'une telle personnalisation coûte plusieurs fois plus cher ou doive être rognée. Et tout n'a pas nécessité un design neuf : deux des trois composants les plus difficiles (la carte de mise en avant et les paliers de remise par quantité) étaient de nouvelles interfaces natives, tandis que le troisième (le carrousel intelligent) réutilisait un composant NAPPS existant, avec la logique propre de Planeta Huerto écrite par-dessus. De la logique sur mesure posée sur des interfaces partagées quand c'est possible, de nouvelles interfaces seulement là où l'interaction n'existait vraiment pas : c'est ainsi que le chantier est resté efficace.

Réalité de la mise en œuvre : cela a pris environ quatre semaines, plus qu'un lancement NAPPS habituel, et la raison honnête est qu'Expresso n'existait pas encore tout à fait. NAPPS construisait la plateforme en même temps que l'app de Planeta Huerto : le pont entre le code natif et la couche React et TypeScript, les services de lecture des données Shopify (collections, produits, metaobjects) et des API dont l'équipe n'a découvert le besoin qu'en cours de projet, comme le rendu de texte enrichi pour la carte de mise en avant. Planeta Huerto a été patient et a fait confiance au processus. Tout ce qui a été construit ici (le pont, les services, le texte enrichi, les icônes dynamiques, les callbacks d'événements, le formatage selon la langue) fait désormais partie de la plateforme et bénéficie à tous les clients NAPPS. Rien n'était un bricolage ponctuel : chaque brique a été construite pour resservir.

Nous avions des années de logique construite dans nos pages produit, et une marketplace par-dessus. Nous nous attendions à ce qu'une app aplatisse tout cela. Au lieu de quoi, chaque composant est revenu en natif, y compris notre marketplace, et les chiffres de l'App Store ont bougé dès l'instant où nous avons basculé.

Albert MiraCTO, Planeta Huerto

La stratégie et les leviers

Reconstruire en composants natifs tout ce que votre thème fait avec les metafields, logique de marketplace incluse.

1. Carte de mise en avant vendeur et expédition (nouveau composant natif, construit en 5 jours). Elle affiche le nom du vendeur (cliquable, relié à sa collection), le coût d'expédition et une estimation de livraison qui change avec le calendrier : commande du lundi au jeudi et l'envoi part le lendemain, commande le vendredi et il part le lundi, commande le week-end et il part le mardi. Elle lit aussi si un produit est direct ou marketplace et applique les bonnes règles de vendeur et d'expédition pour chacun, en puisant dans les metafields produit, les metaobjects vendeur et l'intégration Mirakl. NAPPS l'a voulue flexible : nombre d'éléments illimité, n'importe quelle icône, mise en forme en texte enrichi. Le levier pour tout opérateur Mirakl ou multivendeur : afficher nativement l'expédition et la livraison par vendeur, pour que les produits marketplace soient traités sur un pied d'égalité. Le même composant porte aujourd'hui des certifications (Bio, Fair Trade), des informations de durabilité ou des caractéristiques produit chez d'autres marques.
2. Composant de remise par quantité (nouveau composant natif, construit en 4 jours). Il affiche les paliers de remise sur volume sur la fiche produit (1 acheté au prix normal, 3 achetés 10 % de remise, 5 achetés 20 % de remise) avec plusieurs éléments intégrés : un nombre de paliers dynamique (de 2 à 10, et non 3 figés), des tags comme « Le plus populaire » sur n'importe quel palier, un suivi en direct de la sélection et des callbacks au clic qui renvoient l'événement vers la logique propre de la marque pour recalculer. Le levier : garder une interface native et standard, mais laisser chaque marque brancher sa propre logique tarifaire en dessous, pour que la remise se mette à jour instantanément, sans aller-retour web.
3. Carrousel produit intelligent (interface existante, logique sur mesure, construit en 1 jour). Celui-ci réutilisait un carrousel que NAPPS possédait déjà ; ce qui était sur mesure, c'était la logique de choix de la collection à afficher. Les collections de Planeta Huerto sont nommées par fil d'Ariane (Accueil > Alimentation > Bio > Légumes), et un produit peut appartenir à plusieurs à la fois. La logique compte la profondeur du fil d'Ariane, fait remonter la collection la plus spécifique et titre la rangée depuis un metafield personnalisé, dans la langue du client. Le levier : utiliser la structure de votre propre catalogue pour merchandiser automatiquement les produits liés, sans curation manuelle, sur une interface que vous n'avez pas eu à concevoir.

Les résultats

Toutes les métriques suivies ont progressé après le passage d'une app en webview à une app véritablement native.

Ces gains ne viennent pas d'une nouvelle stratégie de croissance. Ils viennent de la reconstruction des mêmes fiches produit en composants natifs : marketplace incluse, et chaque geste, chaque transition et chaque navigation fonctionnant comme les clients l'attendent sur leur téléphone, au lieu de lutter contre l'app.

Conclusion

Planeta Huerto est le cas des catalogues complexes et des marketplaces : les marques dont les fiches produit reposent sur des metafields, des metaobjects et des vendeurs tiers, et qui supposent qu'aucun créateur d'apps ne peut égaler cela sans tarif grand compte ni compromis lourd. C'est aussi la preuve qu'Expresso tient à grande échelle, puisque c'est là qu'il a été construit. Natif ne veut pas dire enfermé dans des modèles, et si la logique de votre site fonctionne, elle peut être transposée : le défi n'a jamais été la complexité, seulement le fait de disposer d'une plateforme avec les services, la couche React et TypeScript et les composants natifs pour la porter. Si votre objection est « notre catalogue est trop spécifique pour une app », voilà à quoi cela ressemble quand ce n'est pas le cas.

La relation ne cesse de s'approfondir. Les composants que NAPPS a construits ici bénéficient aujourd'hui à tous les clients, et les développeurs de Planeta Huerto ont depuis rejoint le programme en accès fermé d'Expresso : ils créent désormais de nouveaux composants conçus spécifiquement pour l'app et les publient à la volée, sans attendre un cycle de validation sur les stores. Ce qui a commencé comme une migration est devenu une plateforme sur laquelle l'équipe de la marque construit directement.