Connectivité des dispositifs

Connectivité des dispositifs : un sujet central à anticiper dès la phase de conception

Lors de la définition d’un dispositif connecté et de la plateforme IoT chargée de recevoir les données générées, plusieurs décisions relatives à la connectivité doivent être prises très tôt dans le processus de conception.
Ces choix ont un impact aussi bien sur le matériel que sur le logiciel, qui doivent être co-construits dans une boucle de rétroaction étroite. Ainsi, une série de critères doit être évaluée à chaque étape du cycle de développement pour garantir que le comportement du produit corresponde bien à l’usage prévu.

Les points clés à définir avant de se lancer dans un projet de connectivité

Localisation

Le dispositif sera-t-il principalement utilisé en intérieur, par exemple dans un bâtiment tertiaire, une installation industrielle comme une usine, ou même au domicile d’un particulier ? À l’inverse, est-il prévu que l’objet connecté fonctionne dans des zones isolées, dans des conditions extrêmes, voire les deux ? Fera-t-il partie d’une unité mobile de transport, en déplacement constant ?

Contextes d’usage

Certains dispositifs peuvent devoir transmettre des données très fréquemment, avec une charge utile non critique, pouvant parfois être perdue ou dupliquée. À l’inverse, d’autres objets connectés peuvent émettre de la télémétrie moins régulièrement mais avec une exigence forte de fiabilité sur chaque donnée transmise. La robustesse globale de toute la chaîne de données est essentielle.

Risques de sécurité

Certaines données collectées, notamment lorsqu’elles proviennent de sources publiques ou partagées, peuvent sembler anodines et ne pas soulever de questions de sécurité. L’adage « Nous n’avons rien à cacher » est encore trop souvent utilisé. Mais cela revient à ne considérer que la confidentialité du transfert… alors que la sécurité englobe bien d’autres aspects.

SUCCESS STORY

Assurer la connectivité des vannes industrielles de Velan

La nouvelle gamme de vannes connectées de Velan offre aux utilisateurs une télémétrie précise et à jour, grâce à l’expertise de Witekio en connectivité des dispositifs et développement d’applications.

Une plateforme Windows IoT sur mesure pour migrer les données des capteurs vers un data lake.
Une application web avec une interface graphique intuitive.
Des conseils en sécurité pour les transferts de données, la connectivité cloud, et plus encore.

Forces et faiblesses des protocoles de communication

Le modèle réseau OSI est bien connu des ingénieurs, mais sa structure en forme d’oignon, où chaque couche supérieure dépend des garanties offertes par les couches inférieures, rend sa maîtrise globale non triviale. Différents profils de développeurs possèdent une expertise sur des aspects distincts, mais au final, tout doit fonctionner de manière fiable, de haut en bas.

Par exemple, les développeurs embarqués ont des opinions bien arrêtées sur les couches données et liaison, plus proches du matériel. Pendant le processus de conception d’un produit, ils travaillent avec les équipes hardware et doivent être capables de comprendre leurs contraintes et conclusions, voire de les influencer positivement.

Les développeurs applicatifs et cloud s’appuient sur cet ensemble initial de décisions physiques pour les confronter aux besoins métier et à la manière dont les données doivent être exposées à l’utilisateur final. Passons en revue une liste non exhaustive de solutions techniques disponibles lorsqu’il est question de connectivité des dispositifs.

Transport longue distance

LoRaWAN, SigFox ou NB-IoT sont particulièrement efficaces pour une flotte de dispositifs répartis sur une vaste zone géographique couvrant des centaines de kilomètres, voire plusieurs régions ou pays. Des machines lourdes, équipements miniers, stations météo ou véhicules agricoles peuvent être surveillés via ces moyens. Ces protocoles sont économes en énergie mais ne permettent pas de transporter de lourdes charges de données. La même contrainte s’applique aux relais satellites comme Iridium. De plus, les données doivent souvent transiter via l’infrastructure du partenaire choisi, qui doit donc garantir un SLA solide selon le cas d’usage.

Solutions de proximité

À l’autre extrémité du spectre, certains dispositifs ne communiquent que dans un rayon de quelques centimètres à quelques mètres. C’est le domaine des technologies telles que NFC/RFID, UltraWide‑Band (UWB), Bluetooth, Bluetooth Low Energy ou ZigBee, parfaitement adaptées. Les données sont envoyées à un appareil associé, comme une passerelle locale ou un smartphone. La charge utile (payload) peut ensuite être agrégée et traitée avant d’être éventuellement transférée vers des récepteurs plus larges, comme un back‑end distant. On retrouve dans cette catégorie des dispositifs IoT tels que les capteurs d’usine, les appareils domestiques ou les équipements domotiques. Lorsque c’est possible, les solutions sans fil peuvent également être remplacées par des connexions filaires classiques pour améliorer la fiabilité. Un dispositif équipé d’un port Ethernet RJ45 ou d’un port USB en plus du Wi‑Fi présente moins de risques de problèmes à long terme.

Couverture intermédiaire

Si l’appareil est destiné à fonctionner en zone urbaine ou en campagne bien couverte, la dernière génération de connectivité GSM, la 5G, peut offrir les performances attendues en termes de latence, de bande passante et de disponibilité. Elle nécessite une carte SIM (virtuelle ou non), et le choix de l’opérateur dépendra des contraintes financières : comment réduire le coût pour une flotte de milliers de dispositifs sous contrat ? Qu’en est-il du roaming entre pays ?

TCP/UDP/IP

Ce trio de protocoles constitue la base des échanges sur Internet depuis plusieurs décennies. Les solutions IoT peuvent s’appuyer sur ces fondations solides. Selon le cas d’usage, des datagrammes UDP peuvent suffire pour des messages légers et non critiques en « fire-and-forget ». En revanche, la redondance et les accusés de réception offerts par TCP sont souvent indispensables pour une collecte de données fiable, devenant le seul choix viable. Des milliards d’objets IoT viennent chaque année s’ajouter à un réseau déjà surchargé. Malgré les alertes concernant l’épuisement des adresses IPv4, ce protocole reste utilisé. Le NAT robuste dans les routeurs permet aux sous-réseaux d’exploiter cette plage d’adresses limitée. Cependant, si tous les nœuds peuvent utiliser IPv6, cela constitue un atout net, notamment pour cibler un appareil à distance pour un diagnostic.

HTTP

Étant un protocole stateless (sans cookies, jetons ou sessions), HTTP se prête bien à la télémétrie appareil-vers-cloud. Pour la synchronisation inverse — par exemple, appliquer une modification de configuration sur un digital twin — on peut configurer des requêtes en polling régulier selon un intervalle pertinent. L’avantage principal : on réutilise l’infrastructure existante (serveurs web, proxies…) et des pratiques largement maîtrisées comme les API REST, avec une main-d’œuvre abondante. Le format de la charge utile est flexible : on peut utiliser des données binaires via Protobuf, ou du JSON si la bande passante le permet. Pour les mises à jour Over-The-Air, HTTP gère les réponses partielles (range responses), facilitant la relance ou le téléchargement par segments de gros fichiers. Les versions récentes du protocole, comme HTTP/3 basé sur QUIC, peuvent aussi être utilisées avantageusement dans certains contextes.

MQTT

Pour une connexion plus durable et légère, MQTT est souvent préférable lorsque la nature éphémère d’HTTP atteint ses limites. Ce protocole IoT dédié vient de fêter ses 25 ans et reste pertinent, surtout avec les nouveautés de la version 5. À l’image de WebSocket qui permet les communications bidirectionnelles avec mises à jour partielles de l’interface utilisateur, MQTT supporte la communication bidirectionnelle et la diffusion basée sur des « topics », ce qui est idéal pour répondre aux besoins de communication cloud->appareil à l’échelle d’une flotte. Les appels de procédure à distance (RPC) quasi temps réel sont également bien pris en charge.

TLS

Ni HTTP ni MQTT n’apportent de garanties suffisantes concernant les enjeux de sécurité évoqués précédemment. Heureusement, ces protocoles peuvent être utilisés dans leurs versions sécurisées : HTTPS et MQTTS, qui reposent toutes deux sur TLS (Transport Layer Security). Les avancées récentes, notamment TLS 1.3, simplifient la procédure de négociation (handshake) en réduisant le nombre d’échanges nécessaires à l’établissement d’une connexion — un atout dans des conditions réseau instables. De plus, les suites de chiffrement sont mises à jour selon les meilleurs algorithmes actuels : plus sûrs, plus légers. Comme mentionné précédemment, une infrastructure à clé publique (PKI) robuste est essentielle pour tirer pleinement parti de ces technologies. Also, cipher suites are adjusted to state of the art of algorithm which are more secure and lighter. As mentioned earlier a strong PKI is needed to obtain its full potential.

Facettes de la sécurité de la connectivité des dispositifs

Intégrité des données

L’intégrité des données est essentielle pour garantir que la charge utile n’a pas été altérée : un seul bit modifié peut entraîner des conséquences graves dans l’interprétation d’une mesure. Pire encore : des messages « empoisonnés » pourraient être conçus pour compromettre le récepteur.

Authenticité des communications

L’authenticité de la communication est tout aussi critique, des deux côtés du réseau.

Tout comme un utilisateur fait confiance au site de sa banque grâce à un certificat valide, les dispositifs doivent également faire confiance au serveur qui communique avec eux. Les équilibreurs de charge, serveurs ou brokers ont les mêmes exigences : ils ne doivent établir une connexion qu’avec des dispositifs dont l’identité est vérifiée. Dans des scénarios simples ou en phase de développement, un secret partagé peut suffire, mais rapidement, une solution plus robuste devient nécessaire. Les dispositifs doivent présenter un certificat client, souvent conforme à la norme X.509. Cela implique l’usage d’une clé privée, qu’il faut protéger coûte que coûte, notamment via un Trusted Platform Module (TPM) ou un Hardware Security Module (HSM) jouant le rôle de coffre-fort inviolable.

Pour établir cette chaîne de confiance, il faut mettre en place une infrastructure à clés publiques (PKI), nécessitant expertise technique et organisationnelle. Le scénario idéal, lorsque tout fonctionne, peut être mis en œuvre avec un effort modéré. Mais beaucoup de questions doivent aussi trouver une réponse : que se passe-t-il à l’expiration d’un certificat ? En cas de compromission ? Si la clé privée de l’autorité est divulguée ?

Quoi qu’il en soit, une règle simple mais souvent oubliée doit être respectée scrupuleusement : ne jamais inventer ses propres primitives cryptographiques ! Il est beaucoup trop facile de faire des erreurs en cherchant à réinventer la roue. Des suites de chiffrement éprouvées existent : il faut les utiliser si elles sont pertinentes et les abandonner dès qu’elles ne sont plus suffisamment sécurisées.

Au-delà de la couche réseau, ces mêmes exigences s’appliquent aux microservices au sein même de la plateforme IoT. Même si le point d’ingestion gère le chiffrement avec le dispositif, les données doivent toujours circuler de manière sécurisée dans les files d’attente et les pipelines internes.

Witekio peut accompagner votre projet de connectivité

Sans être exhaustives, les explications précédentes révèlent de nombreuses questions et réponses courantes auxquelles les équipes d’ingénierie comme Witekio doivent répondre. Pour chacun de ces concepts clés, certaines bonnes pratiques permettent de couvrir environ 80 % des besoins ; pour combler les 20 % restants, une expertise pointue et un savoir‑faire spécifique sont nécessaires pour garantir que votre flotte de dispositifs atteigne son plein potentiel.

Connectivité des dispositifs