AccueilServicesDéveloppement d'applications Android
Développement d'applications Android natives en Kotlin et Jetpack Compose
Le développement d'applications Android couvre la conception, le développement et la publication d'applications pour smartphones, tablettes, appareils pliables et montres Wear OS, distribuées sur Google Play ou déployées sur des appareils d'entreprise gérés. Woltrio développe des applications Android natives en Kotlin avec Jetpack Compose pour des acteurs de la santé, des start-up et des entreprises. Nous prenons aussi en charge le travail lié à Google Play : la section Sécurité des données, la déclaration relative aux applications de santé et la mise à jour annuelle du niveau d'API cible.
Ce que nous développons sur Android
Cinq types d'applications Android, chacun avec ses propres règles de publication, d'appareils et de données. La santé vient en premier, car ses règles sont les plus strictes.
Applications de santé et mHealth (Health Connect)
Sur Android, les applications de santé et de fitness lisent et écrivent des données via Health Connect, intégré au framework Android depuis Android 14 et installé depuis Google Play sur Android 13 et versions antérieures. Nous demandons uniquement les types de données utiles et alignons les autorisations du manifeste sur l'accès à Health Connect déclaré dans la Play Console et ajoutons l'écran de politique de confidentialité requis. Google indique que les API Google Fit sont prises en charge jusqu'à fin 2026 : nouveaux projets et migrations reposent donc sur Health Connect. Chaque application remplit la déclaration santé de Google Play, et les applications hors dispositif médical affichent la mention requise.
Health Connect · Déclaration santé · Migration Google Fit · Justification des autorisations
Télémédecine et applications patients
Les applications patients réunissent rendez-vous, messagerie sécurisée, téléconsultation, formulaires et résultats. Sur Android, les appels vidéo tournent en service de premier plan pour que la consultation continue si le patient change d'application, et nous expliquons les autorisations caméra, micro et audio Bluetooth avant de les demander. Les notifications passent par Firebase Cloud Messaging ; depuis Android 13, l'utilisateur doit les autoriser, nous le demandons donc au bon moment. Le contenu des messages reste derrière la connexion. Si l'application traite des PHI pour un prestataire, elle est conçue avec les garde-fous HIPAA et reliée à votre EHR via FHIR ou vos API existantes.
Téléconsultation · Notifications FCM · Messagerie sécurisée · API FHIR et EHR
Applications d'entreprise et de terrain
Les applications pour équipes de terrain et collaborateurs tournent sur des appareils d'entreprise ou personnels gérés via Android Enterprise. Nous les concevons pour fonctionner dans un profil professionnel, accepter des configurations gérées afin que l'IT définisse adresses de serveur et options depuis la console de gestion, et prendre en charge l'authentification unique avec votre fournisseur d'identité. Les appareils dédiés, comme les tablettes partagées ou les bornes, fonctionnent en mode verrouillé. Le hors-ligne compte avant tout : formulaires, check-lists et photos sont enregistrés dans une base Room sur l'appareil et synchronisés via WorkManager au retour de la connexion, selon des règles de conflit fixées avant le premier écran.
Android Enterprise · Profil professionnel · Configurations gérées · Synchro hors ligne
Applications grand public et par abonnement
Une application grand public dépend d'une prise en main rapide, d'écrans réactifs et d'une raison d'y revenir. Nous construisons des interfaces Compose conformes à Material Design, vendons les abonnements numériques via Google Play Billing et vérifions achats et intégrité de l'application sur votre serveur avec l'API Play Integrity, plutôt que de faire confiance à l'appareil. Les campagnes push passent par Firebase Cloud Messaging, avec des canaux de notification réglables par l'utilisateur. Avant le lancement, nous remplissons la section Sécurité des données à partir de l'inventaire de chaque SDK, car les bibliothèques d'analyse et de publicité collectent aussi des données, puis nous suivons plantages et ANR dans Android Vitals.
Play Billing · Play Integrity · Sécurité des données · Android Vitals
Wear OS et appareils connectés
Les applications Wear OS et les applications compagnons d'appareils Bluetooth intègrent des capteurs au produit. À partir de Wear OS 3, Health Services fournit fréquence cardiaque, données d'exercice et données passives tout en configurant les capteurs pour préserver la batterie, et Compose for Wear OS gère les petits écrans ronds. Pour les lecteurs de glycémie, tensiomètres, balances ou capteurs industriels, nous développons des connexions Bluetooth Low Energy avec appairage, reconnexion et validation des données. Wear OS a sa propre règle de niveau d'API cible sur Google Play, et les applications qui dépendent d'un matériel externe pour une fonction médicale doivent lister les appareils compatibles dans leur fiche.
Health Services · Compose for Wear OS · Bluetooth LE · Applications compagnons
Ce que contient une application Android native
Six briques que nous prévoyons dans chaque projet Android, quel que soit le type d'application.
Kotlin et interface Jetpack Compose
Google recommande Kotlin pour les nouvelles applications Android et présente Jetpack Compose comme sa boîte à outils recommandée pour les interfaces natives. Nous construisons les écrans en Compose avec un design system partagé et des aperçus, et séparons la logique métier dans des modules Kotlin testables.
Learn moreDonnées offline-first et synchronisation
La base Room de l'appareil est la source de vérité : les écrans se chargent sans réseau. Les modifications sont enregistrées localement puis synchronisées par WorkManager au retour de la connexion, avec nouvelles tentatives. Les règles de conflit, comme « la dernière écriture l'emporte » ou la fusion par champ, sont définies par type de données.
Learn moreHealth Connect et données des appareils
Les applications lisent et écrivent pas, fréquence cardiaque, sommeil, nutrition et d'autres données via Health Connect, avec des autorisations par type de données. Nous les relions à votre backend ou à des ressources FHIR, et connectons les objets portés via Health Services sur Wear OS ou Bluetooth Low Energy.
Learn moreNotifications push et messagerie
Firebase Cloud Messaging achemine les messages de notification et de données. Nous configurons les canaux de notification, demandons l'autorisation introduite avec Android 13 au bon moment et gardons les contenus sensibles hors de la notification : l'application reçoit un signal et récupère le message après connexion.
Sécurité applicative et Play Integrity
Clés et jetons sont stockés dans l'Android Keystore, le trafic réseau passe par TLS et la connexion biométrique utilise le BiometricPrompt du système. Votre serveur demande et vérifie les verdicts Play Integrity sur l'application, l'appareil et le compte avant d'accepter les requêtes sensibles.
Learn morePublication et règles Google Play
Nous préparons la fiche Play Store, la section Sécurité des données, la déclaration relative aux applications de santé et la classification du contenu, publions via les canaux de test interne, fermé et ouvert, puis déployons la production par étapes. Chaque année, nous planifions le passage au nouveau niveau d'API cible avant l'échéance de Google.
Learn moreMultiplateforme ou natif
Multiplateforme ou Android natif ?
Les frameworks multiplateformes comme Flutter et React Native permettent à une seule équipe de livrer iOS et Android depuis une base de code commune, et pour beaucoup d'applications de contenu, de réservation ou de commerce, c'est le bon choix. Kotlin natif se justifie quand l'application s'appuie sur des fonctions propres à Android, comme Health Connect, Wear OS, Android Enterprise ou un travail en arrière-plan important, ou quand Android est votre plateforme principale.
iOS et Android en même temps
Off-the-Shelf
Très adapté. Une base de code et une équipe couvrent les deux stores, ce qui réduit les coûts quand les fonctions sont identiques.
Custom-Built with Woltrio
Deux bases de code si vous avez aussi besoin d'iOS. Idéal quand Android est prioritaire ou que chaque plateforme a son propre comportement.
Nouvelles API Android et Health Connect
Off-the-Shelf
Accessibles via des plugins ou votre propre code de pont natif. Les nouvelles API peuvent arriver plus tard que dans les SDK natifs.
Custom-Built with Woltrio
Accès direct à Health Connect, Health Services et aux nouvelles bibliothèques Jetpack dès leur publication par Google.
Wear OS, widgets et arrière-plan
Off-the-Shelf
Possible, mais ces parties demandent en général des modules Kotlin natifs à côté du code partagé.
Custom-Built with Woltrio
Construits avec les outils de la plateforme : Compose for Wear OS, widgets Glance, WorkManager et services de premier plan.
Rendu et usage sur Android
Off-the-Shelf
Bon. Les frameworks reproduisent Material Design, mais certains comportements système demandent un effort supplémentaire.
Custom-Built with Woltrio
Composants Material, gestes de retour, services d'accessibilité et mises en page grand écran se comportent comme les utilisateurs Android l'attendent.
Budget et délai de lancement
Off-the-Shelf
Souvent inférieur pour deux plateformes, et votre équipe maintient un seul framework.
Custom-Built with Woltrio
Plus élevé s'il vous faut les deux plateformes ; comparable pour un produit uniquement Android ou une flotte d'appareils gérés.
Vous hésitez ? Nous recommandons l'approche adaptée à vos fonctions, votre budget et votre équipe, y compris le multiplateforme quand c'est la meilleure réponse.
Intégré dès la première version
Ce dont toute application Android a besoin, qu'elle traite des données de santé ou non.
Connexion via OAuth 2.0 et OpenID Connect, rôles appliqués côté serveur, stockage local chiffré et expiration des sessions. Woltrio dispose d'un système de management de la sécurité de l'information certifié ISO/IEC 27001:2022, et les applications qui traitent des PHI sont conçues avec les garde-fous HIPAA.
Notre façon de travailler sur Android
Notre approche des projets Android, du premier échange à la mise à jour annuelle de la plateforme.
Les règles de santé dès le premier jour
Nous cartographions les PHI, les données Health Connect et les exigences de Google Play en matière de santé avant le design, et décidons de ce qui reste sur l'appareil. Nous signons un Business Associate Agreement (BAA) avec nos clients du secteur de la santé avant tout partage de PHI.
Un conseil de plateforme honnête
Nous recommandons Kotlin natif uniquement quand vos fonctions l'exigent. Si une application multiplateforme vous convient mieux, nous vous le disons et pouvons la développer, pour que le choix repose sur votre produit et votre budget, pas sur notre préférence.
Pensé pour les changements annuels
Android et les règles de Google Play évoluent chaque année. Nous testons sur différentes tailles d'écran et versions d'OS, planifions la mise à jour du niveau d'API cible avant chaque échéance et tenons la section Sécurité des données et les déclarations santé à jour à chaque version.
De l'idée à Google Play
- 01
Cadrage et choix de plateforme
Nous définissons utilisateurs, fonctions, flux de données et appareils, puis choisissons entre Android natif et multiplateforme. Pour une application de santé, nous listons les types de données, autorisations Health Connect et déclarations Play nécessaires.
- 02
UX et prototype
Nous concevons les écrans Compose avec les composants Material, testons des prototypes cliquables avec de vrais utilisateurs et vérifions accessibilité, mises en page grand écran et demandes d'autorisation avant le développement.
- 03
Développement en sprints
Modules Kotlin, couche de données hors ligne, API et intégrations sont développés en sprints de deux semaines. À la fin de chaque sprint, vous recevez une version de test via un canal de test Google Play.
- 04
Tests sur de nombreux appareils
Nous testons sur une matrice de smartphones, tablettes et appareils pliables, de versions Android anciennes et récentes et de plusieurs fabricants, avec des tests d'interface automatisés, des contrôles TalkBack et des scénarios hors ligne ou réseau faible.
- 05
Publication et maintenance
Nous remplissons les déclarations de la Play Console, déployons par étapes, suivons Android Vitals et maintenons l'application à jour avec le niveau d'API cible annuel et les nouvelles règles.
Questions
fréquemment posées
Besoin d’informations de base ? Notre FAQ vous donne des réponses claires aux questions les plus fréquentes.
Quand faut-il choisir une application Android native plutôt que multiplateforme ?
Qu'exige Google Play des applications de santé ?
Une nouvelle application de santé doit-elle utiliser Health Connect ou les API Google Fit ?
La loi HIPAA s'applique-t-elle à mon application Android ?
Que dit l'exigence de Google Play sur le niveau d'API cible ?
Comment testez-vous sur autant d'appareils Android ?
Pouvez-vous aussi développer la version iOS ?
Comment fonctionnent les notifications push sans exposer les données des patients ?
Sources & Standards
- Target API level requirements for Google Play apps (developer.android.com)
- Renseigner la section Sécurité des données de Google Play (support.google.com)
- Formulaire de déclaration relative aux applications de santé (support.google.com)
- Règlement sur les contenus et services de santé (support.google.com)
- Health Connect developer guide (developer.android.com)
- Play Integrity API overview (developer.android.com)
- Android Enterprise developer overview (developer.android.com)
- Health Breach Notification Rule (ftc.gov)
Continuer la visite
Pages associées.
Ready to Build Your Healthcare Software.
Let's discuss your project requirements and build something that delivers real clinical and business value.
