Objet connecté et app Flutter : bien les relier

Un capteur qui mesure, une application qui affiche : sur le papier, relier un objet connecté à un smartphone paraît simple. En pratique, c'est là que se jouent la fiabilité, la sécurité et l'expérience. Voici les choix qui comptent, illustrés par un projet réel : Bluff, un jeu instrumenté qui relie une carte ESP32 à une application Flutter.

Trois façons de relier un objet à une application

Le Bluetooth Low Energy (BLE)

L'objet communique directement avec le téléphone, sans passer par Internet. C'est la solution des montres, des capteurs de sport ou des serrures connectées.

• Avantages : pas de réseau nécessaire, faible consommation, appairage local.
• Limites : portée de quelques mètres, un téléphone à proximité obligatoire, et des restrictions sur le fonctionnement en arrière-plan, surtout sur iPhone.

Le Wi-Fi en direct

L'objet et le téléphone sont sur le même réseau local et échangent directement. C'est simple pour un prototype, mais fragile en usage réel : réseaux d'entreprise filtrés, Wi-Fi d'invités isolés, adresses qui changent.

Le Wi-Fi via un broker MQTT

L'objet publie ses mesures sur un serveur intermédiaire, le broker, et l'application s'y abonne. Ni l'un ni l'autre n'a besoin de connaître l'adresse de l'autre : chacun se connecte au broker.

MQTT est un protocole léger conçu pour l'Internet des objets. Il fonctionne par sujets (par exemple bluff/capteur/mesures), propose plusieurs niveaux de garantie de livraison (QoS 0, 1 et 2), et permet de prévenir automatiquement les abonnés quand un objet se déconnecte.

C'est le choix fait pour Bluff : la carte ESP32 publie ses mesures environ quatre fois par seconde, et l'application les reçoit en direct, où qu'elle soit.

Côté Flutter : ce qu'il faut prévoir

Une architecture qui sépare les rôles

Une application d'objet connecté mélange vite tout : réception réseau, calculs, affichage, stockage. Une architecture en couches (par exemple MVVM) évite ce piège :

1. Le dépôt de données gère la connexion MQTT ou Bluetooth et le stockage local.
2. La logique transforme les mesures brutes en informations utiles.
3. L'interface se contente d'afficher un état, sans rien savoir du réseau.

Dans Bluff, cette séparation est stricte, avec Riverpod pour la gestion d'état, et des tests empêchent une couche d'importer ce qui ne la concerne pas. Résultat : la logique se teste sans capteur branché.

La perte de connexion, un cas normal

Un objet connecté perd son réseau. Toujours. Le Wi-Fi faiblit, le téléphone change d'antenne, le broker redémarre. L'application doit le prévoir dès le départ :

• se reconnecter automatiquement, avec un délai croissant entre les tentatives ;
• se réabonner aux bons sujets après la reconnexion ;
• garder en file d'attente les messages à envoyer, et les transmettre au retour du réseau sans créer de doublons ;
• afficher clairement l'état à l'utilisateur : en direct, ou dernière mesure il y a quelques secondes.

Le bon rythme de données

Envoyer chaque mesure brute dès qu'elle est lue sature le réseau et vide la batterie. Il vaut souvent mieux calculer sur l'objet lui-même (lissage, détection de battements, moyenne) et ne transmettre que des valeurs utiles, à un rythme adapté à l'affichage.

La carte calcule, l'application décide, le téléphone garde.

La sécurité, dès le premier jour

Un objet connecté est une porte d'entrée. Quelques règles ne se négocient pas :

• chiffrer les échanges : MQTT sur TLS, jamais en clair sur Internet ;
• authentifier l'objet et l'application auprès du broker, avec des identifiants propres à chacun ;
• limiter les droits : un capteur publie sur ses sujets, il n'a pas à lire ceux des autres ;
• chiffrer les données stockées sur le téléphone quand elles sont sensibles ;
• minimiser ce qui part dans le cloud : ne transmettre que le nécessaire, et seulement avec l'accord de l'utilisateur.

Pour Bluff, qui mesure des données physiologiques, les échanges sont chiffrés en TLS, les données locales en AES-256, la synchronisation cloud est facultative, et les parties du mode le plus intime ne quittent jamais le téléphone.

Comment choisir

• L'objet est toujours à côté du téléphone, et doit fonctionner sans réseau : Bluetooth Low Energy.
• L'objet doit être consulté à distance, ou par plusieurs applications : Wi-Fi et broker MQTT.
• Les deux usages existent : c'est possible, avec un appairage en Bluetooth puis une communication via le broker.

Dans tous les cas, prévoyez la perte de connexion, la sécurité et la protection des données avant d'écrire la première ligne d'interface. Ce sont elles qui font la différence entre une démonstration qui marche sur un bureau et un produit qui tient en conditions réelles.

Vous avez un projet d'objet connecté ou d'application mobile ? Découvrez notre approche des applications mobiles, ou parlons-en.