Étude de cas · HealthTech · Nutrition
Comment nous avons livré une application grand public de nutrition multiplateforme — prête pour l'App Store et Google Play, avec une seule base de code Flutter, un moteur de calories et de macros, un constructeur de plans repas hebdomadaires, et une intégration des achats intégrés résistant à la validation de reçus pour les audiences aux États-Unis et dans l'Union européenne dès le premier jour.
L'équipe produit de BasilDoc gérait un service de régime en ligne établi et souhaitait un pendant mobile sur iOS et Android. Le backend et un système de design partiel étaient déjà en place, mais l'équipe n'avait aucune capacité mobile en interne, une spécification incomplète et une exigence ferme que les achats intégrés fonctionnent proprement sur Apple StoreKit et Google Play Billing — pour des audiences aux États-Unis et dans l'Union européenne où les règles des stores et la fiscalité diffèrent d'une façon qui compte au niveau du chemin de code. Nous avons développé le client mobile en Flutter avec Dart pour livrer les deux plateformes depuis une seule base de code. Comme la spécification était légère, nous avons mené des entretiens avec les parties prenantes pour clarifier les vrais flux utilisateurs — sélection des objectifs, calcul calorique, consommation de recettes, planification hebdomadaire — et les réponses ont conduit à des ajustements backend et de design qui ont été livrés avant qu'aucune ligne de code de production ne soit écrite. Une cadence Scrum/Kanban combinée a absorbé les évolutions de périmètre sans perdre de vélocité, et le circuit des achats intégrés a été traité comme son propre flux de travail avec une validation des reçus côté serveur contre les points de vérification d'Apple et de Google. Le résultat est une application HealthTech grand public prête pour les stores américains et européens, positionnée comme un build phare dans notre pratique de développement d'applications mobiles.
Un aperçu de ce que le build BasilDoc a permis de réaliser sur une seule base de code Flutter, le moteur calorique et le circuit des achats intégrés au cours de son premier cycle de production.
Le choix du stack domine tous les autres choix architecturaux dans un build HealthTech multiplateforme. Nous avons choisi Flutter avec Dart plutôt que React Native, iOS et Android natifs en parallèle, et Ionic / Capacitor, parce que les compromis correspondent parfaitement à un produit de nutrition grand public où la parité de pixels entre plateformes est une fonctionnalité. Flutter effectue le rendu via son propre pipeline Skia plutôt que de déléguer les arbres de widgets aux primitives natives de l'OS, ce qui signifie qu'une grille de plans repas se comporte de façon identique sur iPhone et Pixel sans dérive de layout par plateforme. Material 3 couvre Android et les widgets Cupertino couvrent iOS, tous deux depuis la même source Dart.
React Native a été éliminé parce que la surcharge du bridge et les différences de pipeline de rendu ajoutent une dérive par plateforme précisément là où une interface HealthTech ne peut pas se le permettre — les chiffres du moteur calorique, les barres de macros, la grille de plans repas doivent tous atterrir sur le même pixel sur les deux plateformes. iOS et Android natifs en parallèle auraient doublé les cycles de build, QA et publication pour un ensemble de fonctionnalités qui ne nécessite pas d'intégrations profondes spécifiques à la plateforme. Le rendu soutenu par WebView d'Ionic / Capacitor perd la fluidité gestuelle dont une application HealthTech grand public a besoin.
| Dimension | Flutter (BasilDoc) | React Native | Native iOS + Android / Ionic |
|---|---|---|---|
| Modèle de rendu | Basé sur Skia ; parité de pixels entre plateformes | Primitives natives via bridge JS | Natif : direct ; Ionic : WebView |
| Nombre de bases de code | Une seule base de code Dart pour les deux stores | Une base de code JS/TS avec branches par plateforme | Natif : deux bases de code ; Ionic : une base web |
| Cohérence de l'interface | Material 3 + Cupertino — identique sur iOS et Android | Par défaut plateforme — dérive sur les bords de layout | Natif : travail de parité complet ; Ionic : rendu web |
| Cadence de build / publication | Une seule matrice CI construit les deux stores | Matrice unique ; les modules natifs ralentissent | Natif : deux matrices ; Ionic : web + enveloppes |
| Profondeur d'intégration IAP | Plugins officiels StoreKit + Play Billing | Plugins communautaires ; qualité variable | Natif : plus profond ; Ionic : restrictions WebView |
| Fluidité gestuelle | Élevée — Skia maîtrise le cadre | Variable — le bridge peut perdre des images | Natif : meilleure ; Ionic : plafond WebView |
| Écosystème de plugins mature | Solide sur les surfaces grand public — paiements, médias, push | Solide, mais qualité hétérogène | Natif : plateforme complète ; Ionic : héritage Cordova |
Références : Apple StoreKit documentation, Google Play Billing reference, Material 3.
La surface iOS utilise des widgets Cupertino pour que l'expérience BasilDoc se lise comme native pour un utilisateur iPhone — le rythme de navigation, les feuilles modales, le comportement du sélecteur correspondent tous à ce qu'une audience iOS aux États-Unis ou dans l'UE attend d'emblée. Le moteur de calories et de macros réside dans la couche partagée Dart : un sélecteur basé sur les objectifs résout en un objectif calorique journalier et une répartition de macros (protéines, glucides, lipides), le moteur de recommandation basé sur les objectifs affiche les programmes correspondant au profil de l'utilisateur, et la bibliothèque de recettes rend avec un lecteur d'instructions vidéo qui respecte les règles d'audio en arrière-plan iOS afin qu'un utilisateur puisse continuer à cuisiner pendant qu'une étape est lue.
L'ensemble de la surface iOS — intégration, sélection des objectifs, moteur calorique, bibliothèque de recettes, constructeur de plans repas — est piloté depuis le même code Dart qui pilote Android, avec des widgets sensibles à la plateforme résolvant la couche visuelle au moment du rendu. Le chemin des achats intégrés est connecté via le plugin Apple StoreKit officiel, avec des appels de validation de reçus postés au même point de terminaison serveur qu'Android utilise. La surface combinée est fournie dans le cadre de notre pratique de développement d'applications mobiles, avec une porte CI stricte de non-dérive entre plateformes maintenant iOS et Android en parallèle à chaque publication.
La surface Android utilise Material 3 depuis la même source Dart, avec des widgets sensibles à la plateforme résolvant la navigation, les dialogues et les animations selon les rythmes natifs Android. Le constructeur de plans repas hebdomadaires est la pièce maîtresse : les utilisateurs choisissent un programme, le moteur calorique résout un objectif journalier et une répartition de macros, et le constructeur remplit sept jours depuis la bibliothèque de recettes avec des créneaux facilement substituables afin qu'un utilisateur puisse remplacer le petit-déjeuner du mardi sans reconstruire le reste de la semaine. L'export de liste de courses regroupe la semaine sélectionnée en une seule liste partageable, et les rappels push pour les repas sont connectés via Firebase Cloud Messaging sur Android avec un consentement par défaut opt-in pour rester conforme au RGPD pour les utilisateurs dans l'Union européenne.
Le chemin des achats intégrés sur Android passe par Google Play Billing avec le même validateur côté serveur qu'utilise le chemin iOS. L'enregistrement d'habilitation unique pilote le filtrage des fonctionnalités sur les programmes de régime, l'accès aux recettes et l'historique des plans repas — ce qui signifie qu'un utilisateur qui s'abonne sur Android, puis change de téléphone pour iOS, restaure l'accès proprement parce que l'habilitation est côté serveur, pas côté store. Les workers en arrière-plan gèrent les opérations non urgentes — synchronisation de la bibliothèque de recettes, planification des notifications push, rotation des certificats — avec une sémantique de backoff qui respecte les états d'économie de batterie d'Android 10 à Android 14 sur les familles d'appareils Samsung, Xiaomi, OnePlus et Pixel.
La posture de confidentialité de BasilDoc était une décision d'architecture avant d'être une affirmation marketing. L'application collecte uniquement les données personnelles dont le moteur calorique a besoin — objectif, tranche d'âge, objectif de poids, restrictions alimentaires — et les stocke sous un ID utilisateur opaque délibérément séparé de l'identité de paiement. Les points de vérification d'Apple et de Google conservent les reçus ; le validateur côté serveur normalise la réponse et écrit un seul enregistrement d'habilitation indexé par l'ID opaque. Le côté store ne voit jamais le profil alimentaire de l'utilisateur, et le côté alimentaire ne voit jamais l'Apple ID ou le compte Google de l'utilisateur.
Les flux de consentement sensibles à la région sont connectés au niveau du client : les utilisateurs dans l'UE et l'EEE reçoivent un écran de consentement granulaire de style RGPD avec des bascules distinctes pour les analyses de produit optionnelles ; les utilisateurs en Californie reçoivent une divulgation de style CCPA « Ne pas vendre ou partager mes informations personnelles » dans le même flux. La posture est conçue pour s'aligner sur les obligations RGPD pour les utilisateurs dans l'Union européenne et sur les obligations CCPA / CPRA pour les utilisateurs en Californie et aux États-Unis — afin que toute future revue de confidentialité indépendante soit un exercice de documentation plutôt qu'une refonte architecturale.
Posture de conformité : Conforme au RGPD · Prêt pour ISO 27001 · SOC 2 Type II en cours · Compatible HIPAA · CCPA pris en compte.
Un build en cinq phases qui a conduit BasilDoc d'une spécification légère et d'un service de régime web uniquement à une application iOS et Android en production avec le circuit des achats intégrés.
Entretiens avec les parties prenantes, validation des flux utilisateurs, contrat entrée/sortie du moteur calorique, analyse des lacunes backend, cartographie de la posture RGPD + CCPA, revue des politiques de soumission Apple et Google.
Couche partagée Flutter, stratégie Material 3 + Cupertino, moteur de calories et de macros, modèle de données du constructeur de plans repas, schéma d'habilitation IAP, squelette du validateur de reçus côté serveur.
Sélection de régime basée sur les objectifs, bibliothèque de recettes avec lecteur vidéo, constructeur de plans repas hebdomadaires, export de liste de courses, rappels push, achats intégrés sur les deux stores.
Renforcement de la validation des reçus côté serveur, rédaction de la politique de confidentialité, flux de consentement sensibles à la région, divulgation HealthTech de l'App Store, préparation à la revue des données sensibles Google Play.
Soumission sur App Store + Google Play dans les espaces de vente US et UE, déploiement du niveau payant, ajustement des cohortes de rappels push, analytique opt-in pour le taux d'atteinte des objectifs.
La couche de monétisation de BasilDoc a été conçue pour maintenir de façon vérifiable la séparation entre l'identité de paiement et le profil alimentaire, car une posture de confidentialité HealthTech s'effondre dès qu'une seule base de données relie une transaction StoreKit à une sélection d'objectif. Les abonnements sont vendus via Apple StoreKit sur iOS et Google Play Billing sur Android, avec une validation des reçus côté serveur contre le point de vérification de chaque store et l'écriture d'un seul enregistrement d'habilitation indexé par un identifiant opaque et rotatif — jamais par Apple ID, compte Google ou adresse e-mail. À l'intérieur du moteur calorique et du constructeur de plans repas, la seule chose visible est un jeton porteur à courte durée de vie qui se mappe à l'habilitation et expire rapidement. L'accès aux programmes de régime, le déblocage de la bibliothèque de recettes, le filtrage du lecteur vidéo et l'historique des plans repas hebdomadaires lisent tous le même enregistrement d'habilitation, de sorte qu'un seul abonnement se résout proprement lors des réinstallations, des échanges d'appareils et du futur transfert au compte web. L'ensemble du sous-système a été conçu en vue de son extensibilité : ajouter un forfait famille, une habilitation multi-appareils ou un niveau coach-et-client avec profils appariés est un changement de configuration du service d'habilitation, non une mise en production de code. La même posture laisse de la place pour de futures fonctionnalités d'ingénierie IA/ML & données — recommandations personnalisées ajustées sur des cohortes anonymisées, non jointes à l'identité de paiement.
BasilDoc a été développé pour les stores Apple App Store et Google Play actifs aux États-Unis et dans l'Union européenne. La version en langue anglaise dessert les utilisateurs en Californie, New York, Texas, Floride et Washington aux États-Unis, ainsi que les utilisateurs aux Pays-Bas, en Allemagne, en France, en Irlande et en Suède dans l'UE, sans base de code distincte par région. Les flux de consentement sont sensibles à la région au niveau du client : les utilisateurs dans l'UE et l'EEE reçoivent un écran de consentement granulaire de style RGPD avec des bascules distinctes pour les analyses de produit optionnelles ; les utilisateurs en Californie reçoivent une divulgation de style CCPA « Ne pas vendre ou partager mes informations personnelles » dans le même flux. Les pratiques de traitement des données sont alignées sur le RGPD pour les utilisateurs européens et sur l'ensemble de lois américaines sur la confidentialité — CCPA / CPRA (Californie), VCDPA (Virginie), CPA (Colorado), CTDPA (Connecticut), UCPA (Utah), TDPSA (Texas) et Oregon CPA. Comme l'ID utilisateur opaque isole les données alimentaires de l'identité de paiement, la conformité régionale se réduit à une divulgation honnête plutôt qu'à une ségrégation des données par juridiction.
Les pipelines des achats intégrés ont été testés contre l'environnement sandbox d'Apple et le canal de test de licence de Google Play dans les deux régions en parallèle, et la classification par âge de l'App Store ainsi que la classification de contenu de Google Play ont été calibrées pour l'ensemble des fonctionnalités HealthTech. La politique de confidentialité a été rédigée pour documenter précisément l'architecture ci-dessus, citant directement les obligations RGPD et les obligations CCPA de Californie. L'équipe d'ingénierie à l'origine du build travaille sur le fuseau CET avec un chevauchement avec la côte est des États-Unis (9 h–13 h ET) pour les stand-ups, la coordination des soumissions en store et la gestion des incidents — le fuseau horaire qui permet à une équipe produit américaine et une équipe d'ingénierie européenne de partager quatre heures de chevauchement en direct chaque jour.
La feuille de route active de développement logiciel sur mesure pour BasilDoc comprend un chemin d'ingestion de données de wearables pour Apple Health et Google Fit, un cache de recettes offline-first pour les voyages à faible connectivité, un niveau coach-et-client apparié pour les nutritionnistes aux États-Unis et dans l'UE, et un compagnon de bureau partageant la logique métier Flutter via Flutter Desktop. Un entonnoir de croissance centré sur les États-Unis et un autre centré sur l'UE sont planifiés avec des bibliothèques de recettes spécifiques à la région, et le sous-système d'habilitation prend déjà en charge l'attribution multi-sièges dont un futur niveau de nutrition B2B aura besoin.
Si vous planifiez une application multiplateforme de régime, de nutrition ou de HealthTech où le circuit des achats intégrés et la posture de confidentialité doivent résister à une revue Apple et Google pour des audiences aux États-Unis et dans l'UE, nous avons livré ce stack de bout en bout et pouvons réduire sensiblement le délai de développement. L'équipe d'ingénierie derrière lui fait partie de YuSMP Group. Nous travaillons au prix fixe pour les MVP bien définis et avec des équipes de développement dédiées pour la livraison continue, avec une journée de travail CET et une fenêtre garantie de chevauchement avec la côte est des États-Unis (9 h–13 h ET) pour les stand-ups, les démonstrations et la gestion des incidents.
Un MVP multiplateforme de régime et de planification de repas couvrant iOS et Android via Flutter, un moteur de calories et de macros, une bibliothèque de recettes et le circuit des achats intégrés coûte généralement entre 90k et 210k USD. L'ajout d'un moteur de recommandation basé sur les objectifs, d'un constructeur de plans repas hebdomadaires, d'un export de liste de courses, d'un lecteur vidéo et de rappels push porte un produit complet à 250k–520k USD. Les principaux facteurs de coût sont la précision du moteur calorique, la validation des reçus des achats intégrés sur deux stores et le flux de consentement RGPD et CCPA ajusté pour les stores américains et européens.
Flutter livre une seule base de code Dart sur iOS et Android avec des widgets Material 3 et Cupertino précis au pixel, ce qui convient à un produit HealthTech grand public où la parité entre plateformes est une fonctionnalité, non un hasard. Par rapport à React Native, le pipeline de rendu est plus prévisible et la surcharge du bridge est plus faible. Par rapport à iOS et Android natifs en parallèle, une seule base de code réduit les cycles de build, QA et publication d'environ de moitié pour un ensemble de fonctionnalités qui ne nécessite pas d'intégrations profondes spécifiques à la plateforme.
Les achats intégrés constituent leur propre flux de travail. Le client iOS intègre Apple StoreKit, le client Android intègre Google Play Billing, et les deux chemins clients postent des reçus dans un seul validateur côté serveur qui appelle les points de vérification d'Apple et de Google, normalise la réponse et écrit un enregistrement d'habilitation par utilisateur. Cet enregistrement pilote le filtrage des fonctionnalités sur les programmes de régime, les plans repas et l'accès aux recettes. La validation côté serveur est obligatoire — les vérifications de reçus côté client uniquement sont trivialement contournables et disqualifient l'ensemble de la posture d'abonnement.
L'application collecte uniquement les données personnelles nécessaires au fonctionnement du moteur calorique — objectif, tranche d'âge, objectif de poids, restrictions alimentaires — et les stocke sous un ID utilisateur opaque non joint à l'identité de paiement. Les flux de consentement sensibles à la région présentent un écran de consentement granulaire de style RGPD aux utilisateurs dans l'UE et l'EEE et une divulgation de style CCPA aux utilisateurs en Californie. Les rappels push sont opt-in par défaut dans les deux régions, et la politique de confidentialité documente chaque chemin de données qu'utilisent le moteur calorique et le constructeur de plans repas.
Un MVP ciblé avec la sélection de régime basée sur les objectifs, un moteur de calories et de macros, une bibliothèque de recettes, un constructeur de plans repas hebdomadaires et les achats intégrés sur les deux stores prend généralement 14 à 22 semaines. L'ajout d'un lecteur vidéo, d'un export de liste de courses, de recommandations personnalisées et de rappels push pour les repas ajoute 6 à 10 semaines. Le passage de soumission aux stores et de coordination des revues — divulgation HealthTech d'Apple, revue des données sensibles de Google Play et une politique de confidentialité couvrant les flux de consentement américains et européens — devrait être budgétisé à 3 à 5 semaines de travail dédié.
Études de cas associées
Application patient pour un réseau de laboratoires multi-villes — prise de rendez-vous, résultats, notifications push, intégration comptable.
Voir l'étude →
Application consultant retail pour l'inventaire boutique — recherche ElasticSearch, intégration 1C.
Voir l'étude →
Application marketplace mobile locale pour une chaîne hors ligne d'articles pour enfants — catalogue flexible, synchronisation de stock en ligne.
Voir l'étude →
MVP prêt pour les investisseurs livré en 12 semaines pour 60-120k EUR. Chef de projet senior, designer, ingénieurs, QA.
En savoir plus →
Applications iOS, Android et multiplateformes natives avec pipelines de publication prêts pour les stores.
En savoir plus →
Plateformes SaaS multi-tenant avec SSO, facturation, résidence régionale fixée. SOC 2 en cours.
En savoir plus →Partagez quelques détails et un consultant senior vous répondra dans un délai d'un jour ouvré.