Applications mobiles pour produits IoT, passerelles, configuration, télémétrie.
Un produit IoT industriel a presque toujours besoin d'une application mobile : configuration initiale, supervision terrain, dépannage opérateur, télémétrie remontée. Nous concevons ces apps comme des outils techniques, pas comme du marketing, Flutter, BLE robuste, MQTT vers backend.
- Bluetooth 5.4
- MQTT 5.0
- TLS 1.3
- Material Design 3
- Apple HIG
- RGPD
Flutter, le bon outil pour les apps de produit
Pour une app produit (configuration, supervision, télémétrie d'un capteur ou d'une machine), Flutter est aujourd'hui le meilleur choix : un seul codebase pour Android et iOS, performances quasi-natives, écosystème mature pour BLE et MQTT, déploiement simple en interne ou sur les stores.
Nos apps Flutter sont écrites avec Riverpod ou Bloc pour la gestion d'état, un séparation claire UI / business logic, et des tests unitaires + widget pour les fonctions critiques. La maintenance long terme (mise à jour OS, ajout de fonctionnalités) reste fluide.
BLE, robuste, vraiment
Le Bluetooth Low Energy est notoirement capricieux : connexions qui timeout, services qui changent d'UUID après update, gestion d'énergie côté capteur qui interrompt la session. Une app BLE qui marche sur le banc et casse en clientèle est un classique.
Notre approche : state machine BLE explicite (pas implicite), gestion de toutes les transitions (connexion, déconnexion, reconnexion automatique, perte de service), tests sur 5+ appareils Android différents et 3+ iPhones (iOS et Android ont des bugs BLE différents, les deux doivent passer). Pour les produits cold-chain où la connexion BLE peut durer des semaines, la robustesse n'est pas négociable.
MQTT 5.0 vers backend
MQTT 5.0 (la version actuelle) ajoute des fonctionnalités importantes pour l'IoT industriel : Reason Codes (diagnostic structuré), User Properties (métadonnées extensibles), Shared Subscriptions (load balancing entre instances backend), Session Expiry. Nous utilisons couramment Mosquitto auto-hébergé, EMQX en managé, ou AWS IoT Core selon les contraintes du client.
Côté app mobile, le client MQTT supporte la reconnexion automatique, les QoS 1/2 pour les messages critiques, et le buffering offline pour les zones sans connexion (chantiers, entrepôts en zone blanche).
Passerelles Android industrielles, cold-chain et fleet
Cas d'usage typique : un opérateur en tournée scanne des capteurs BLE en passant à proximité, l'app collecte les données et les renvoie vers un backend MQTT en arrière-plan. Le téléphone est une passerelle.
Nous avons développé des apps Android industrielles dédiées au cold-chain (capteurs température disposés dans des camions frigorifiques, vérification de la chaîne du froid en temps réel) et au fleet management. Contraintes typiques : foreground service Android pour la collecte BLE continue, base SQLite locale (outbox pattern) pour résister aux pertes de connectivité, gestion fine de la batterie, conformité RGPD pour les données collectées.
FAQ
- Flutter ou React Native ?
Pour une app produit avec BLE intensif et calculs côté client, Flutter a un avantage en performances et en stabilité. React Native reste pertinent si l'équipe cliente a déjà des compétences React. Pour une app majoritairement UI sans contraintes lourdes, les deux conviennent. Nous évitons les frameworks anciens (Cordova, Ionic) qui ont des limites BLE.
- Pouvez-vous publier sur l'App Store et le Play Store ?
Oui, gestion complète : signature, profils Apple, listing store, gestion des versions, suivi des crashes (Sentry, Firebase Crashlytics). Pour les apps internes (déploiement entreprise), nous gérons aussi MDM (Mobile Device Management) et signature B2B. Compter 2 à 4 semaines entre la candidate finale et la première version publiée.
- Quelle est la durée typique d'un projet d'app IoT ?
Pour une app produit complète (provisioning + supervision + télémétrie), comptez 4 à 8 mois selon complexité. La phase de spécification UX prend 2-4 semaines. Le développement initial 3-5 mois. Les phases de test sur appareils réels et de stabilisation BLE 1-2 mois. La maintenance évolutive est un poste à part qui peut s'étaler sur plusieurs années.
Firmware
Un firmware industriel n'est pas un script qui marche le jour de la livraison. C'est un système qui doit fonctionner après dix ans de production série, supporter des mises à jour OTA sécurisées, et résister à un environnement réglementaire qui évolue (CRA, IEC 62443).
Hardware
Un PCB livré chez nous est un PCB qu'on peut fabriquer en série, certifier sans reprise, et poser en usine sans surprise. La CEM, les standards IPC et la DFM sont intégrés au schéma, pas ajoutés après que le prototype ait fumé.
Industrialisation
Le piège classique : un design fonctionnel en proto, qui demande six mois et un re-spin pour tenir en production série. Notre signature technique, c'est l'inverse, la DFM, les standards IPC et la testabilité sont intégrés au schéma initial. Le proto est déjà une carte fabricable.