Cloud, Bluetooth ou Wi-Fi local : quel canal pour piloter un objet connecté ?

Lundi matin, fin mai. Julien a attendu toute la semaine sa nouvelle pompe à chaleur de piscine, et l'installateur vient de repartir. Il ne reste que l'étape « deux minutes » promise par la notice : connecter la pompe à l'application.

Quarante minutes plus tard, Julien est au fond du jardin, le téléphone levé au-dessus de la tête, devant le même message : « La connexion a échoué. Veuillez réessayer. »

Julien n'existe pas, mais toutes les personnes qui ont conçu un objet connecté reconnaîtront cette scène. Elle illustre un sujet presque toujours sous-estimé en début de projet. Pour piloter un objet connecté, il existe plusieurs chemins : le Bluetooth, le Wi-Fi de la maison, le cloud. Chacun a ses avantages, ses contraintes et ses usages. Bien les choisir et, quand il en faut plusieurs, bien les combiner fait la différence entre un produit qu'on recommande à ses voisins et un produit qui finit débranché.

Pour un fabricant, ces choix influencent directement la facilité d’installation, la continuité de service et les demandes adressées au support.

Trois façons de parler à un objet connecté

Le Bluetooth Low Energy (BLE), c'est le tête-à-tête. Le téléphone parle directement à l'objet, sans box ni serveur. Le Bluetooth ne nécessite pas de compte en lui-même, même si le produit peut en imposer un. Il faut être à proximité : une dizaine de mètres peut servir de repère en intérieur, mais la portée varie beaucoup selon le matériel et les obstacles. C'est le canal le plus autonome, mais aussi le plus local. À 200 km de chez soi, il ne sert à rien.

Le Wi-Fi local, c'est la conversation de salon. L'objet et le téléphone sont connectés à la même box et se parlent sans passer par Internet. C'est rapide et ça ne dépend d'aucun serveur extérieur. Encore faut-il que l'application sache retrouver l'objet sur le réseau, entre la télé, l'imprimante et l'aspirateur robot.

Le cloud, c'est le standard téléphonique. L'objet envoie ses données à un serveur sur Internet, et l'application les récupère de n'importe où. En pratique, c'est lui qui permet de piloter à distance et de recevoir des alertes. C'est le canal qui dépend du plus grand nombre d'intermédiaires : la box, la connexion Internet, les serveurs.

Aucun n'est « le meilleur ». La bonne question est : lequel, pour quel usage et dans quelle situation ? Reprenons l'histoire de Julien.

Le jour de l'installation : Bluetooth ou réseau Wi-Fi temporaire ?

Tout juste mise sous tension, la pompe ne connaît pas encore le Wi-Fi de la maison : elle ne peut joindre ni la box, ni le cloud. Il faut d'abord lui transmettre le nom du réseau et son mot de passe. Deux méthodes sont très répandues pour cela.

Méthode 1 : passer par le Bluetooth

C'est celle qu'utilise la pompe de Julien :

1. Le téléphone détecte l'objet en Bluetooth et s'y connecte.
2. L'utilisateur renseigne via une application le nom de son réseau Wi-Fi et le mot de passe, que le téléphone transmet ensuite à l'objet.
3. L'objet se connecte à la box (puis au cloud s'il y en a un).
4. L'application confirme que tout fonctionne.

Son grand avantage : le téléphone reste sur son réseau habituel pendant toute l'opération, et l'application peut guider l'utilisateur jusqu'à la confirmation finale. En contrepartie, l'objet doit gérer le Bluetooth, et l'application doit composer avec les autorisations Bluetooth et les différences de comportement entre téléphones.

Méthode 2 : l'objet crée son propre réseau Wi-Fi

Lors de sa mise en service, l'objet crée un petit réseau Wi-Fi temporaire, du type « Pompe-4F2A » : on parle de mode « point d'accès ». Le téléphone s'y connecte, puis l'application (ou parfois une simple page web) transmet à l'objet les identifiants du Wi-Fi de la maison. L'objet ferme alors son réseau temporaire et rejoint la box.

Son atout : pas besoin de Bluetooth, ce qui autorise des modules Wi-Fi plus simples, et parfois même aucune application. Mais cette méthode a ses propres pièges.

• Le téléphone doit quitter le Wi-Fi de la maison. Certaines applications savent basculer automatiquement sur le réseau de l'objet, après accord de l'utilisateur. Sinon, il faut passer par les réglages du téléphone, et c'est là qu'une partie des utilisateurs décroche.
• Le téléphone se méfie des réseaux sans Internet. Certains le signalent, voire repassent d'eux-mêmes sur la 4G ou sur la box en pleine opération.
• La confirmation est plus délicate. Quand l'objet coupe son réseau pour rejoindre la box, l'application perd le contact. Elle doit ensuite le retrouver, sur le réseau local ou via le cloud, pour confirmer que tout s'est bien passé.

Un critère pèse souvent plus lourd que tous les autres : l’objet aura-t-il un réseau Wi-Fi à rejoindre ? Une box est souvent disponible à la maison, mais son signal n’atteint pas forcément les appareils installés dans le jardin. Avec le Bluetooth, il suffit de s’approcher avec son téléphone. Sans lui, si l’objet propose un mode point d’accès, il faut rejoindre son réseau Wi-Fi à chaque utilisation, avec un risque de perdre temporairement l’accès à Internet. C’est possible, mais pénible au quotidien.

Le Bluetooth est aussi le canal du technicien qui intervient sur place, et la roue de secours quand tout le reste est en panne. Certains produits n'ont d'ailleurs que lui, ce qui impose une rigueur particulière, comme nous l'expliquions dans notre article sur la gestion du Bluetooth Low Energy dans nos applications mobiles.

Les pièges communs aux deux méthodes

Sur le papier, chaque méthode prend deux minutes. Dans la vraie vie, elles se terminent toutes les deux par la même étape, et c'est souvent là que tout se joue : l'objet doit rejoindre la box.

• L'objet est loin de la box. Une pompe à chaleur est rarement installée dans le salon. Si le Wi-Fi capte mal au fond du jardin, l'objet n'arrive pas à se connecter, et l'utilisateur ne comprend pas pourquoi alors que « tout avait l'air de marcher ».
• Le réseau Wi-Fi doit être compatible avec l'objet. Beaucoup de modules Wi-Fi embarqués ne fonctionnent qu'en 2,4 GHz. Cette bande doit donc être activée sur la box. Certaines configurations réseau peuvent aussi compliquer la mise en service : l'application doit aider à identifier le problème.
• Le mot de passe contient une faute de frappe. Si l'objet ne sait pas remonter l'erreur, l'application attend, l'utilisateur aussi.

Pour Julien, c'était le premier cas : la pompe se trouvait à la limite de portée de la box. Un message clair, comme « La pompe n'arrive pas à rejoindre votre Wi-Fi : le signal est trop faible à cet endroit », lui aurait épargné trente-huit minutes et un appel au service client.

💡 À retenir : la mise en service est le premier contact de l'utilisateur avec votre produit. À chaque échec, l’application doit afficher un message compréhensible et proposer une solution, pas un code d'erreur.

Le Wi-Fi local, l'option qu'on oublie trop souvent

Mercredi soir, l'opérateur de Julien a une panne. Sa box est allumée, son Wi-Fi fonctionne, mais plus rien ne sort de la maison. Si l'application ne connaît que le cloud, la pompe est injoignable… alors que Julien se trouve à dix mètres d'elle, sur le même réseau.

C'est exactement le cas que règle le Wi-Fi local : l'application parle directement à l'objet à travers la box, sans passer par Internet. C'est rapide, ça reste utilisable pendant une coupure d’Internet (tant que le réseau local fonctionne), et ça évite à chaque commande de faire le tour d'un datacenter pour atteindre un appareil situé dans le jardin.

Pourquoi tous les objets ne le proposent-ils pas ? Parce qu'il demande plus de travail :

• L'application doit retrouver l'objet sur le réseau, ce que certains routeurs et réseaux d'entreprise compliquent.
• Sur iPhone, l'utilisateur doit autoriser l'accès au réseau local, une permission que certains refusent par réflexe.
• Il faut sécuriser la communication : « local » ne veut pas dire « de confiance ».

Au quotidien, à distance : ce que le cloud apporte

Le lendemain, la connexion rétablie, Julien s'aperçoit que la météo annonce un week-end ensoleillé. Il ouvre l'application et passe la consigne de 24 à 28 °C pour que l'eau soit bonne samedi. Son téléphone est en 4G, la pompe sur le Wi-Fi de la maison : c'est le serveur qui fait le lien entre les deux.

Le cloud facilite aussi plusieurs services à distance :

• Les alertes : si la pompe se met en défaut pendant les vacances, Julien reçoit une notification, où qu'il soit.
• L'historique à long terme : les températures, la consommation et les heures de fonctionnement sont conservées pendant des mois et consultables partout.
• Le suivi par un professionnel : avec l'accord du client, l'installateur peut surveiller les pompes qu'il a posées et anticiper les pannes.
• La supervision d’un parc : un tableau de bord permet de suivre les équipements sur plusieurs sites, de connaître le nombre d’appareils en ligne, de repérer ceux qui ne communiquent plus et de centraliser les défauts pour organiser les interventions.

C'est souvent là que se trouve la valeur commerciale d'un objet connecté. Mais son fonctionnement dépend de toute la chaîne de connexion : une panne de la box, de l’accès Internet ou du service cloud peut rendre la pompe injoignable à distance, alors qu’elle continue de fonctionner. Et pour les fabricants qui visent des milliers d'objets, la question du dimensionnement de l'infrastructure arrive vite. Nous l'avons abordée dans notre article sur l'architecture cloud scalable.

Plusieurs canaux pour un même objet : ce qu'il faut décider

Quand un objet propose plusieurs canaux, l'application doit choisir lequel utiliser, et c'est plus subtil qu'il n'y paraît. Voici les points à trancher dès la conception.

Le canal actif doit être connu de l'application. Elle doit savoir à tout instant si elle parle à l'objet en Bluetooth, en Wi-Fi local ou via le cloud, plutôt que de le deviner au cas par cas. L'afficher est un autre choix : l'information n'intéresse guère l'utilisateur tant que tout fonctionne, mais c'est souvent la première question du support (« Vous êtes connecté comment ? »). Une indication discrète peut faire gagner de précieuses minutes.

Le changement de canal est un événement, pas une surprise. Passer du Bluetooth au cloud à la fin de l'installation, ou du cloud au Bluetooth quand Internet tombe, doit se gérer explicitement : prévenir l'utilisateur, recharger les données, ne perdre aucune commande entre les deux.

Les conflits se prévoient. Le technicien règle la pompe sur place en Bluetooth pendant que Julien, depuis son bureau, modifie la consigne via le cloud. Qui gagne ? Il n'y a pas de réponse universelle : le dernier qui parle, la personne présente sur place, un verrouillage pendant l'intervention… Mais il faut en choisir une avant que la situation se présente.

Et quand il n'y a ni box, ni téléphone à proximité ?

Un apiculteur qui veut suivre le poids de ses ruches au milieu d'un champ n'a ni Wi-Fi, ni personne sur place avec un téléphone. Deux familles de réseaux répondent à ce besoin : les réseaux cellulaires bas débit (LTE-M, NB-IoT), qui fonctionnent comme un téléphone mobile très économe, et les réseaux longue portée comme LoRaWAN, qui transmettent quelques données sur plusieurs kilomètres avec une pile qui dure des années, à condition qu'une antenne couvre la zone. Ils envoient peu de données, et rarement, mais ils permettent de relier au cloud des objets installés loin de tout. Le Bluetooth reste souvent présent à côté, pour l'installation et la maintenance sur place.

Six questions à se poser avant de choisir

1. Où vivra l'objet, et y aura-t-il un Wi-Fi à proximité ? Dans un salon, au fond d'un jardin, dans un local technique en sous-sol, au milieu d'un champ ?
2. Qui va l'utiliser, et d'où ? Un particulier chez lui ou depuis son bureau, un technicien de passage, un gestionnaire qui supervise 300 sites ?
3. Que doit-il se passer si Internet tombe ? Rien de grave, ou faut-il absolument garder le contrôle ?
4. Quelles fonctions sont critiques ? Une alerte de défaut doit être transmise, une courbe de consommation peut attendre.
5. Comment se passera l'installation ? Par qui, avec quelles compétences, dans quelles conditions ?
6. Quel est le budget par objet ? Chaque canal a un coût : composants, logiciel embarqué à maintenir et, pour le cloud ou le cellulaire, frais récurrents.

Les réponses dessinent presque toujours la bonne combinaison. Et elles concernent autant l'électronique que l'application : ce choix se fait au moment de concevoir l'objet, pas une fois la carte électronique fabriquée.

Conclusion

Julien a fini par profiter de sa piscine. Mais son lundi matin aurait pu être celui de n'importe quel client, de n'importe quel fabricant. Ce sont ces premières minutes qui forgent l'image d'un produit.

Le cloud, le Bluetooth et le Wi-Fi local répondent à des situations et à des usages différents : installer l'objet, le piloter sur place, le surveiller à distance. Un produit n'a pas forcément besoin des trois, et certains se contentent très bien d'un seul. Le vrai travail consiste à partir des usages réels pour choisir la bonne combinaison. Quand il y a plusieurs canaux, il faut ensuite décider lequel prend la main et quand, prévoir ce qui se passe quand l'un d'eux lâche, et préserver une expérience compréhensible pour l’utilisateur.

Vous concevez un produit et hésitez sur la meilleure façon de piloter un objet connecté ? Chez Poolker, l'électronique, le cloud et les applications se conçoivent ensemble, justement pour que ces choix soient faits au bon moment. Parlons de votre projet.