Application mobile IoT industriel — Flutter Android / iOS

Développement d’applications mobiles pour produits IoT industriels

Chez AESTECHNO, bureau d’études électronique basé à Montpellier, nous développons les applications mobiles qui accompagnent les produits IoT industriels que nous concevons. Android et iOS avec une base de code unique via Flutter, pipeline CI/CD avec auto-déploiement sur le Play Store, et intégration native avec les cartes électroniques connectées que nous produisons.

Pourquoi confier l’app mobile au bureau d’études qui conçoit le hardware ?

La plupart des projets IoT échouent au moment où l’application mobile rencontre le firmware : protocoles BLE mal synchronisés, latences imprévues, gestion de l’alimentation qui tue la batterie du capteur, ou pire, une app qui marche sur un téléphone de test mais pas sur les dix références du parc client. Dans notre pratique, nous avons constaté que ces problèmes s’évitent lorsque le développement mobile démarre en parallèle du firmware, pas après.

Contrairement à l’approche classique où l’app mobile est sous-traitée à un studio web externe après la livraison du hardware, notre équipe développe les deux couches avec les mêmes outils de tests et le même pipeline CI/CD. Résultat concret : une détection des incompatibilités BLE ou des drifts de protocole en moins de 24 heures au lieu de plusieurs semaines d’aller-retour entre équipes séparées.

Notre stack mobile

Nous privilégions Flutter pour les projets IoT industriels. Un codebase unique Dart couvre Android 8+ et iOS 13+, avec un build size typique de 15-25 MB après optimisation, contre 40-80 MB pour des stacks natives équivalentes. Flutter permet d’intégrer les pipes BLE natifs (flutter_blue_plus, flutter_reactive_ble) et les couches crypto platform-specific sans casser le cross-platform.

• Flutter (Dart) — UI cross-platform, 60 FPS animations, hot reload en phase dev <1 s
• Bluetooth LE — connexions concurrentes jusqu’à 7 périphériques, MTU 244-512 octets configurable
• MQTT / HTTPS / CoAP — synchronisation cloud avec retry + reconnexion automatique
• SQLite + encryption — stockage local chiffré AES-256 des credentials et historique capteur
• Firebase / AWS IoT Core / back-end custom — selon la criticité et la sovereignty requise

Pour les projets avec contraintes temps réel strictes (audio, vidéo embarquée 30+ FPS, streaming LiDAR) nous développons en natif Kotlin ou Swift. Le choix n’est jamais religieux — il dépend des contraintes de latence, de l’accès hardware requis et du budget de maintenance à 5 ans.

Flutter vs React Native vs natif : quel framework choisir ?

Le choix du framework mobile impacte directement le coût de maintenance sur 3-5 ans. Voici les arbitrages que nous pratiquons avec nos clients, basés sur la typologie du projet plutôt que sur la hype du moment.

Pour la majorité des apps compagnons de produits IoT que nous livrons, Flutter reste le meilleur compromis : une équipe maintient une base Dart, les mises à jour suivent un cycle unique, et la différence de performance avec le natif est imperceptible sur des UIs de monitoring ou configuration.

Notre méthodologie produit mobile industriel

L’application mobile suit le même cadre de jalons que nos projets hardware : EVT pour prouver la faisabilité, DVT pour valider l’intégration bout-en-bout, PVT pour la mise en production sur les magasins. Chaque jalon produit des livrables vérifiables et un rapport de tests documenté.

1. Cadrage — User stories, wireframes, spécification BLE/cloud/stockage local, analyse des contraintes iOS (permissions background, HealthKit), analyse Android (foreground service, Doze mode)
2. Architecture — Choix du framework (Flutter / natif / hybride), dimensionnement back-end, modèle de données offline-first avec synchronisation différentielle
3. Développement itératif — Sprints 2 semaines, démo intermédiaire, intégration continue avec le firmware dès qu’une carte prototype est fonctionnelle
4. Tests — Tests unitaires >70% coverage, tests widget Flutter, tests d’intégration avec le hardware réel, sessions UX sur 5-10 utilisateurs cibles
5. Déploiement continu — Pipeline CI/CD avec tests bloquants, signature automatique, auto-déploiement vers le Play Store ou TestFlight selon le produit

Sécurité mobile : ce que le CRA exige en 2026

Une app mobile compagnon d’un produit IoT tombe directement sous le Cyber Resilience Act (règlement UE 2024/2847) au même titre que le firmware qu’elle pilote. Les échéances contraignantes sont les mêmes : reporting des vulnérabilités sous 24h à compter du 11 septembre 2026, application pleine au 11 décembre 2027.

Concrètement, nos apps intègrent systématiquement : certificate pinning TLS 1.3, stockage cryptographique via Android Keystore et iOS Keychain, mécanisme de mise à jour signé via les stores officiels, et une politique de divulgation publique (security.txt) alignée avec celle du firmware. Pour approfondir, consultez notre guide de conformité CRA et notre article sur la sécurisation des produits IoT.

FAQ — Application mobile IoT

Combien coûte le développement d’une application mobile IoT ?
Le coût dépend de la complexité fonctionnelle et du degré d’intégration hardware. Une app compagnon simple (configuration + monitoring d’un produit BLE) demande typiquement 4-8 semaines de développement. Une app industrielle avec back-end cloud, gestion multi-utilisateurs, streaming temps réel et certification médicale ou ATEX peut s’étaler sur 4-6 mois. Nous proposons systématiquement un cadrage chiffré par jalons EVT/DVT/PVT avant tout engagement de production.

Peut-on développer une seule fois pour Android et iOS ?
Oui, avec Flutter, une base de code Dart unique couvre les deux plateformes avec un rendu UI identique en 60 FPS. Les différences résiduelles (permissions, icônes, store guidelines) représentent typiquement 5-10% du code. Pour des cas d’usage extrêmes (vidéo, AR, audio professionnel), le natif reste parfois justifié — mais pour 90% des applications IoT compagnons, Flutter est le meilleur compromis coût/performance/maintenance.

Comment gérez-vous la synchronisation BLE entre l’app et le capteur ?
Nous implémentons une couche d’abstraction qui gère les reconnexions automatiques (MTU renégocié après chaque reconnexion), la file d’attente des commandes avec timeout configurable (typiquement 5-10 s), la reprise sur erreur, et la fallback sur la cache locale quand le capteur est hors portée. Sur un projet récent avec synchronisation multi-capteurs BLE 5.4 PAwR, nous avons mesuré des latences de synchronisation inférieures à 5 µs sur 100 périphériques concurrents.

L’application mobile est-elle concernée par le Cyber Resilience Act ?
Oui. Dès qu’une application mobile est fournie comme composant d’un produit avec éléments numériques, elle hérite des obligations CRA : exigences de sécurité by design, SBOM, politique de divulgation de vulnérabilités, mises à jour signées sur la durée de support (5 ans minimum). Le règlement s’applique aux apps Android, iOS, et aux éventuels outils web d’administration associés.

Faites-vous la maintenance de l’app après le lancement ?
Oui, nous proposons des contrats de maintenance évolutive qui couvrent les mises à jour OS (Android et iOS publient 1 version majeure par an), les correctifs de sécurité, le portage vers les nouvelles versions Flutter, et les évolutions fonctionnelles selon roadmap client. Le pipeline CI/CD mis en place dès le développement permet de livrer des correctifs en quelques heures sans recompilation manuelle.

En résumé

Une application mobile IoT n’est pas un projet web qu’on greffe sur un produit électronique : c’est la couche qui fait le lien entre le matériel et l’utilisateur final, et sa qualité détermine directement la perception produit. En développant l’app mobile au sein du même bureau d’études que le firmware, nous éliminons les ruptures de protocole BLE, nous intégrons la sécurité CRA dès l’architecture, et nous déployons un pipeline CI/CD unique qui couvre du schéma électronique au Play Store.

Si vous préparez un produit IoT destiné au marché européen et que vous cherchez un partenaire capable de livrer l’ensemble hardware + firmware + mobile avec un seul point de contact technique, parlons de votre projet.

Pour approfondir

• Cyber Resilience Act 2026 : guide de conformité IoT
• DevOps embarqué : CI/CD et tests automatisés
• Sécuriser un produit IoT de la conception au déploiement
• Bluetooth 5.4 : PAwR, mesh, haut débit
• Bureau d’études électronique : méthode & industrialisation