Objets connectés (IoT) et protocoles de communication en agriculture

Table des matières

Partagez cet article !

Après un précédent dossier sur l’interopérabilité et les standards agricoles, je reviens en force avec un nouveau travail de vulgarisation centré ici sur les protocoles de communication en agriculture. Sujet important où force est de constater que peu de gens y comprennent vraiment grand-chose…

Si je vous parle de protocole de messagerie MQTT, de communication via NB-IOT, Sigfox ou LoRaWAN, ou encore du modèle conceptuel OSI pour présenter la façon dont les réseaux communiquent entre eux, vous êtes totalement à l’aise ? Ou alors peut-être aurez déjà vous pris vos jambes à votre coup… Vous êtes encore-là ?

Entre des anglicismes et des acronymes à coucher dehors, les confusions vont bon train. Néanmoins, il suffit parfois simplement de dérouler les acronymes pour se rendre compte qu’on n’avait en réalité pas compris grand-chose ou pour au contraire enfin ouvrir les yeux sur des concepts que l’on avait du mal à cerner.

Si, pour beaucoup, ce sujet est transparent (et parfois sans intérêt) dans la mesure où ce serait aux fournisseurs d’outils et de services de s’en occuper, c’est pourtant bien dommage parce que comprendre les protocoles de communication permet de mieux appréhender et comprendre l’internet des objets.

Pour les agriculteurs, c’est ainsi une occasion d’ouvrir sa curiosité, de développer sa culture générale, et peut-être et surtout de comprendre ce que les objets connectés sont capables de faire et de ne pas faire. Le tout pour éviter de se prendre de la poudre aux yeux…

Ce dossier sur les objets connectés, et plus particulièrement sur les protocoles de communication en agriculture est également l’occasion de valoriser toute la connaissance qui commence à être capitalisée sur l’annuaire des outils numériques pour l’agriculture. En plus de servir la veille collaborative, cette plateforme est maintenant utilisée pour prendre du recul sur les outils numériques en place et de dégager des tendances.

Ce dossier a été écrit en proximité avec Nicolas Daüy (entreprise Furgo) et Simon Moinard (AgroTIC Services – avec le dispositif du Mobilab). Je les remercie pour le temps qu’ils ont mu m’accorder. Plusieurs articles, rapports et wébinaires m’auront permis de compléter les retours d’entretiens.

Bonne lecture !

Limites des standards et de l'intéropérabilité en agriculture

Soutenez Agriculture et numérique – Blog Aspexit sur Tipeee

Préambule important

Même si nous allons voyager ensemble dans le monde des objets connectés en agriculture et évoquer pas mal de sujets techniques, nous resterons dans des considérations plutôt théoriques et nous ne rentrerons pas dans l’opérationnel. En gros, je m’excuse d’avance mais je ne vous expliquerai pas comment déployer votre réseau d’objets connectés sur votre exploitation, comment installer votre box WiFi ou comment rendre compatible votre puce LoRa au protocole de communication LoRaWan ! Je n’ai d’ailleurs jamais installé moi-même ma propre station LoRa, c’est pour dire…. Mon expérience technique sur le sujet se résume à quelques cours lointains sur les réseaux de capteurs sans fil ou encore à du bricolage très succinct sur des cartes électroniques Arduino pour tenter d’afficher une information de température depuis un capteur très basique de température (je ne me souviens même plus si j’y suis arrivé).

La technique pure bien que de plus en plus facile d’accès reste quand même relativement compliquée, même si elle devient de plus en plus accessible. Alors bien sûr, certains geeks et géo-trouvetou s’en sortent particulièrement bien (et on est ravis pour eux), mais de là où je me place, j’ai quand même parfois l’impression que le bricolage n’est jamais très loin. Quand il faut vraiment passer à l’industrialisation de tout ça, ça n’est plus la même rengaine.

C’est donc encore une fois avec humilité que je vous propose ce dossier. Comme à l’accoutumée, c’est peut-être justement cette entrée naïve qui est intéressante, et qui me permet de tenter de mettre des mots sur des concepts que je n’avais en réalité pas vraiment compris.

Dans ce dossier, je tenterai d’apporter une attention toute particulière au vocabulaire qui, pour moi, est à l’origine de nombreuses confusions et incompréhensions. J’en profiterai également pour revenir sur quelques abus de langage qui, d’apparence, peuvent sembler insignifiant jusqu’à ce qu’ils commencent à prendre une place un peu trop importante dans nos têtes.

Merci de bien garder ça en tête tout au long de la lecture de ce travail !

Une première entrée en matière avec des exemples de parcours de la donnée

Comment diable peut-on visualiser sur notre smartphone (ou toute autre interface d’ailleurs) les données collectées (données de plante, de météo, de sol…) au niveau d’un capteur placé dans une parcelle agricole ? La donnée a en réalité parcouru tout un chemin, invisible à nos yeux, parfois très court ou au contraire très long, avec potentiellement peu d’intermédiaires ou au contraire pléthore. Un vrai parcours du combattant me direz-vous… Retracer ce parcours permet déjà de comprendre les implications techniques et technologiques qui se cachent derrière l’utilisation de ces capteurs connectés. Visualiser ce parcours est également l’occasion de se rendre compte que tout l’imaginaire régulièrement asséné autour de la dématérialisation ou de la virtualisation du numérique est en réalité une farce. Les capteurs connectés imposent l’existence de toute une architecture informatique (antennes, câbles, serveurs, micro-contrôleurs…) bien réelle faite de matière sonnante et trébuchante.

Prenons quelques exemples pour rentrer dans le vif du sujet.

Ne vous inquiétez pas si vous ne comprenez pas l’ensemble du vocabulaire de cette section, nous aurons largement l’occasion d’y revenir dans ce dossier. L’idée est ici d’avoir une vision panoramique et une première sensibilisation au trajet de la donnée pour ensuite pouvoir creuser la chose dans la suite de cet article de blog. Notez bien que ces exemples sont des exemples ! Ce ne sont pas des vérités générales et il y a plusieurs façons d’arriver au même résultat (d’envoyer la donnée) – tout dépend du contexte et du besoin utilisateur. Nous en reparlerons…

PREMIER EXEMPLE (Figure 1) : Visualisation en temps réel de données de température d’une station météo connectée (j’en profite pour vous renvoyer vers un précédent dossier de blog pour aller plus loin sur ces stations : https://www.aspexit.com/les-stations-meteo-connectees-en-arboriculture/ !). En tant qu’agriculteur, vous aimeriez disposer d’une donnée météorologique bien localisée dans votre parcellaire. Vous avez en effet peut-être un parcellaire morcelé ou des parcelles sur des vallons ou versants sensiblement différents. Vous passez le cap, contactez un fournisseur (si vous savez quoi lui demander, c’est quand même toujours mieux), achetez une station et l’installez proche d’une de vos parcelles. Chaque jour, vous suivez en temps réel sur votre smartphone les données de température relevées par votre station connectée au champ. Comment cela est-ce possible ?

La station météo, composée de plusieurs capteurs (thermomètre, pluviomètre, anémomètre…), est l’objet communicant. Le capteur de température présent sur la station mesure un niveau de température et transfère cette donnée en bits (des 0 et des 1) à un microcontrôleur présent au niveau de la station.

La donnée est ensuite agrégée sur un pas de temps (disons toutes les minutes) au sein du microcontrôleur pour recalculer tout un tas de paramètres un peu plus fins (rafales calculées sur un intervalle de temps de 3s, mm de pluie sommée sur l’intervalle d’envoi, intensité de pluviométrie calculée sur une minute…)

A intervalles réguliers, la station envoie un résumé de ces données en bit par ondes radio (via le réseau cellulaire ou non) grâce à un module d’émission installé au niveau de la station) à une structure réceptrice (une antenne gérée par un opérateur télécom comme Orange ou une antenne gérée en propre). La station n’est ainsi pas nécessairement constamment connectée au réseau cellulaire.

L’antenne réceptrice décode les ondes radio et envoie les données décodées via internet sur la base de données de l’opérateur télécom ou du fabricant de la station par exemple).

Les données sont ensuite envoyées sur la base de données du fabricant de station qui met à disposition le site web pour mettre en forme et visualiser ces donénes

En tant qu’agriculteur, vous vous connectez à votre compte utilisateur sur le site du fabricant de station (depuis votre ordinateur ou depuis l’application smartphone dédiée du fabricant). Pour accéder à vos données, une requête informatique est envoyée sur la base de données du fabricant via une API (ou sur celle de l’opérateur si le fabricant ne stocke pas les données sur ses propres bases de données). Les données sont ensuite renvoyées vers vous et vous sont présentées dans votre navigateur.

Le serveur de base de données du fabricant, en suivant en dynamique les données de température collectées dans la base de données, peut également vous envoyer des alertes directement sur votre compte utilisateur (et ne pas attendre que vous vous connectiez au serveur du fabricant)

Le fabricant peut aussi déclencher une mise à jour ou un paramétrage de la station connectée (ou plutôt du capteur de température) en envoyant une requête sur le serveur de l’opérateur (pour une mise à jour du code ou un paramétrage de l’outil connecté). Cette requête sera transmise via le réseau cellulaire et, quand la station se connectera au réseau cellulaire pour envoyer ses données, elle recevra la mise à jour ou le paramétrage demandé.

Figure 1. Exemple de parcours de la donnée d’une station météo. Crédits : Nicolas Daüy

DEUXIEME EXEMPLE : Activation à distance d’une pompe d’irrigation. Vous êtes un agriculteur un peu geek et vous êtes en train d’irriguer une de vos parcelles avec un enrouleur. Votre station de pompage est assez loin de votre exploitation. Chaque déplacement à la station est assez chronophage et fastidieux. Dès que vous avez un problème ou une vérification à faire sur votre enrouleur, vous devez faire un aller-retour à la station. Après vous être questionné sur la technologie à mettre en place, la façon dont vous alliez faire communiquer votre système ou encore ce que votre installation allait vous coûter, vous décidez alors d’installer un objet connecté relativement simple pour vous faciliter la tâche. Vous mettez en place un actionneur commandé par un microcontrôleur Arduino pour activer automatiquement les boutons de votre pompe sans avoir besoin de vous déplacer à votre station de pompage :

Vous envoyez un SMS depuis votre téléphone portable ou smartphone à un microcontrôleur branché sur une carte électronique Arduino installée au niveau de la station de pompage.

Le microcontrôleur reçoit le SMS qui est en réalité un mot de passe et qui commande l’allumage de la pompe

Le microcontrôleur envoie la commande en GSM (via le réseau téléphonique) à un moteur pas à pas (servomoteur) qui active le bouton de la pompe de la station.

Cet exemple nous fait entrevoir qu’il existe plusieurs types d’objets connectés, par exemple un capteur (ici le smartphone) et un actionneur (le servomoteur). L’exemple n’est peut être pas le plus approprié mais il permet de soulever au moins ce sujet.

TROISIEME EXEMPLE : Affichage en local de données d’un capteur de température en utilisant sa propre antenne Lora. Vous êtes agriculteur, un peu geek et vous souhaitez développer une infrastructure entièrement open-source et affranchie de tout prestataire extérieur.

Le capteur de température est branché sur une carte Arduino (microcontrôleur programmable pour débutant).

Un module Lora, installé sur la carte électronique Arduino, permet de transférer les données depuis la carte Arduino jusqu’à l’antenne Lora que vous avez installée en propre chez vous et intégré au réseau The Things Network

Un micro-ordinateur Rapsberry Pi avec un module Wifi récupère les données sur les serveurs de The Things Network par Wifi

Le Raspberry Pi envoie les données récupérées sur une base de données stockée sur votre serveur en local

Les données sont affichées sur une petite interface en local avec l’outil de développement Node-Red

Figure 2. Un exemple schématisé du parcours de la donnée entre un capteur à ultrasons utilisé pour une mesure de distance et un affichage en local sur l’ordinateur d’un utilisateur. Le module ESP8266 ajouté sur la carte électronique Arduino permet de connecter l’objet au réseau Wifi afin d’envoyer (dans l’exemple du schéma) les données dans une base de données relationnelles (« RDMS » pour « Relational Database Management System » ou, en français : « Système de Gestion de Base De Données Relationnelle »)

On continue à prendre un peu de recul avec le dernier schéma suivant qui, finalement, récapitule un certain nombre de choses. On y voit notamment :

Un capteur qui envoie des données via le protocole de communication Zigbee. Pour être plus précis, il faudrait parler d’objet connecté parce que ce capteur est d’ailleurs très certainement branché à un microcontrôleur installé sur une carte électronique (Arduino par exemple). Le capteur en lui-même ne sert qu’à faire de la mesure et c’est bien l’ensemble de l’architecture qui en fait un capteur connecté

Une passerelle (Gateway en anglais) qui fait le lien entre les capteurs connectés et différents types de serveur pour communiquer via internet. Dans ce schéma, la transmission se données se fait via un réseau local (LAN – Local Area Network) mais il aurait pu en être autrement. Cette passerelle est constituée d’un micro-ordinateur Raspberry Pi et d’un ou plusieurs modules pour envoyer les données sur les serveurs. Cette passerelle permet de gérer la communication entre plusieurs infrastructures qui ne communiquent pas forcément avec les mêmes protocoles. Une passerelle remplit plusieurs missions comme la traduction de protocoles de communication, ou encore le traitement, le chiffrement et la gestion des données.

Les serveurs de bases de données (il y en a plusieurs sur le shéma) communiquent ensuite leurs données suite à des requêtes à différents utilitaires (une application smartphone ou un navigateur web) via différents protocoles de communication, respectivement une communication sans fil (par exemple Wifi ou 4G) lorsque l’on cherche à appeler des données sur une base de données depuis son smartphone, ou via le protocole de communication éthernet par exemple lorsque l’on cherche à appeler les données stockées sur un serveur web depuis un autre ordinateur connecté au même réseau.

Figure 3. Du capteur à l’application smartphone ou au navigateur web : trajets de la donnée.

Petit traité d’objet connecté

On pourra trouver le parallèle assez amusant. Des auteurs ont cherché à mettre en réseau ce à quoi les scientifiques s’intéressaient quand ils travaillaient sur les réseaux de capteurs sans fils (WSN – Wireless Sensor Network) en agriculture (Abdollahi et al., 2021). Après une fouille bibliographique dans un certain nombre de journaux dédiés (comme par exemple les revues « Sensors », « Computers and Electronics in Agriculture », ou encore « Wireless Personal Communications »), les auteurs nous proposent un joli maillage de tous les mots clés connectés aux travaux autour des réseaux de capteurs sans fils en agriculture (Figure 4). On y retrouve ici :

des applications agricoles (d’ailleurs pas mal autour du suivi des conditions environnementales et de la gestion de l’eau « smart irrigation », « aquaculture », « Precision Irrigation », « Soil Moisture »),

des concepts très liés protocoles de communication en tout genre (LPWAN, LoRa, WSAN, Zigbee, RFID…) ou

des thématiques liés à la gestion des objets connectés (Application, Authentification, Fault Tolerance…)

Figure 4. Les réseaux de capteurs sans fils (WSN – Wireless Sensor Network) dans la littérature scientifique en agronomie. Source : Abdollahi et al. (2021). Wireless Sensor Networks in Agriculture : Insights from Bibliometric Analysis, Sustainable.

Un capteur est-il forcément un objet connecté ?

SPOILER ALERT : Un capteur tout seul, ce n’est pas un objet connecté ! Si l’on reprend nos exemples cités en début de dossier, la station météo ne devient connectée que parce qu’il y a une infrastructure qui permet d’envoyer les données, un serveur pour stocker la donnée et des pages web (ou autres) pour afficher ces données. L’internet des objets (IoT – Internet Of Things) est l’infrastructure qui permet d’étendre le réseau internet aux objets du monde physique, c’est-à-dire aux capteurs que nous installons dans les parcelles agricoles ou l’environnement, de sorte que nous puissions faire transiter les données de ces capteurs sur le réseau internet et les afficher comme n’importe quelle autre donnée du web. C’est la passerelle entre le monde physique et le monde virtuel – même si nous avons déjà discuté du fait qu’il n’y avait finalement pas grand-chose de virtuel derrière tout ça.

Revenons donc un peu maintenant sur ce qui compose un objet connecté (Figure 5). Avec les exemples du début, vous devriez avoir maintenant quelques billes en tête. Un objet connecté, c’est donc au moins :

Une partie « acquisition de données » : c’est-à-dire un ou plusieurs capteurs et au moins un convertisseur pour transformer le signal analogique du capteur en un signal numérique (constitué de 0 et de 1). On parle de CAN pour Convertisseur Analogique Numérique. C’est ce signal numérique qui pourra être lu et utilisé par l’ensemble des infrastructures du réseau. Dans un contexte agricole, on peut imaginer rajouter une petite antenne GNSS (qui a le rôle de capteur de donnée de géolocalisation) pour suivre le positionnement de l’objet connecté en temps réel.

Une partie « traitement de la donnée » : on retrouve ici un calculateur et agrégateur (le microcontrôleur) sur lequel se branche le capteur, un dispositif pour stocker rapidement la donnée et assurer la mémoire de l’objet connecté, et un système d’exploitation (par exemple installé sur un micro-ordinateur Raspberry Pi)

Une partie « transmission de la donnée » matérialisée par des modules installés sur le microcontrôleur pour émettre ou réceptionner de la donnée via des protocoles de communication sans fil. Aujourd’hui, on ne conçoit presque plus d’objets qui possèdent un microcontrôleur sans y ajouter une connexion sans fil (WiFi, Bluetooth, ou autre). La puce de télécommunications peut d’ailleurs être directement vendue avec le micro-contrôleur.

Une partie « source d’énergie » pour servir à l’alimentation de l’ensemble des unités de l’objet connecté (une pile ou une batterie par exemple). Certains objets connectés sont associés à des systèmes de générateurs d’énergie pour être plus autonomes (on pense par exemple à des petits panneaux solaires qui viendraient alimenter un objet connecté installé au champ).

Figure 5. Schéma simplifié d’un objet connecté (ici une station météo connectée)

L’ensemble de ces dispositifs est branché sur une même carte électronique (on a donné l’exemple d’Arduino). C’est vraiment comme lorsque vous jouiez aux Legos quand vous étiez plus jeune mais là c’est avec de l’électronique – c’est le Lego de l’électronique quoi. La carte Arduino est vraiment faite pour l’intéropérabilité de l’électronique. Cette carte est compatible avec plein de protocoles de communication différents, dispose de sorties analogiques et numériques, utilise un langage de développement lui-aussi appelé Arduino, et peut lire une valeur toutes les micro-secondes. La carte Arduino possède juste une mémoire suffisante pour contenir le code préalablement conçu en langage C/C++ sur l’ordinateur. Il est cependant possible d’ajouter un espace de stockage (comme une la carte SD pour collecter un grand nombre de données)

Le microcontrôleur est vraiment le dispositif central de l’objet connecté qui fait interagir tous les éléments branchés sur la carte électronique. Au sein de cet écosystème (à l’intérieur de cette carte électronique), les données peuvent transiter de plusieurs façons.

Le micro-contrôleur va par exemple communiquer :

avec une puce de télécommunication LoRa en protocole filaire SPI. Cette puce LoRa transformera le signal reçu et l’enverra sur l’antenne LoRa par la suite.

avec une puce radio en protocole filaire Série (RX/TX pour Receive/Transmit). Le micro-contrôleur fera le lien avec le lecteur de carte SIM et les potentiels composants radio présents sur la carte électronique et enverra ces données à l’antenne radio installée elle-aussi sur la carte électronique. Cette antenne fera le lien avec l’antenne relai d’un opérateur tiers ou une antenne installée localement.

Les capteurs vont par exemple envoyer leurs données après les avoir converties en tension et amplifiés :

sous une forme analogique (c’est alors le microcontrôleur qui va lire et convertir ce signal en signal numérique),

sous une forme numérique directement :
- sous un format « Série » avec un protocole RX/TX – les capteurs ont alors des broches d’émission et des broches de réception de signal (tension)
- sous un format « SPI » : les données ne sont pas codées. Il y a simplement une broche avec un identifiant pour un capteur ce qui permet de s’y retrouver plus facilement
- sous un format « I2C » (le capteur doit être compatible I2C) : c’est un câble qui permet aux données de transiter à horaire fixe (une horloge est présente). En début de signal, les premiers bits de données identifient toujours le capteur qui envoie les données – le micro-contrôleur sait donc de quoi on parle.
- On peut aussi citer le format OneWire, c’est-à-dire la communication via un seul fil

Notez que les formats SPI et I2C que j’ai légèrement évoqués ne sont pas spécifiques à l’internet des objets. Le protocole USB – largement plus démocratisé, est lui aussi utilisé pour faire transiter des données entre deux matériels. Un module USB peut ainsi être aussi branché à la carte Arduino pour communiquer via un câble USB avec un ordinateur. Les données transitant vers la carte Arduino par USB seront converties à l’aide d’un convertisseur (par exemple USB / Série que nous avons évoqué plus haut) pour être lues par le micro-contrôleur branché sur la carte Arduino. Ce module USB peut aussi servir à alimenter la carte Arduino en énergie.

Vous avez peut-être noté que j’ai évoqué à plusieurs reprises le nom de « modules » pour exprimer les dispositifs que l’on viendrait rajouter – par exemple sur une carte électronique Arduino. Vous verrez certainement d’autres vocabulaires plus spécifiques si vous continuez à creuser le sujet. Le terme « Shield » (parfois traduit directement par bouclier) désigne un module spécialement dédié à être branché sur une carte Arduino. On parle par exemple de Shield Wifi ou de Shield Sigfox qui sont des antennes de communication branchées sur la carte électronique Arduino pour pouvoir envoyer des données sous le protocole Wifi ou Sigfox. Pour les micro-ordinateurs Raspberry Pi, vous verrez peut-être la terminologie « hats ». Plus généralement, certains utiliseront un peu indistinctement le terme de « Dongle » De manière générale, la carte électronique Arduino est plutôt utilisée pour du prototypage parce qu’on a potentiellement tout un tas de capteurs et de fils qui dépassent. Dans une phase plus industrielle, on aura plutôt tendance à faire passer tout ça sur un circuit imprimé (PCB en anglais) et intégrer le microcontrôleur directement à la carte électronique.

Capteurs et réseaux de capteurs sans fils

Vous devriez maintenant être un peu plus au fait sur ce qu’est un objet connecté ou devrais-je plutôt dire ici un capteur connecté dans notre contexte agricole. Si chaque capteur peut être utilisé complètement indépendamment et que vous pouvez décider de n’en installer qu’un dans un parcellaire agricole, vous avez aussi la possibilité de mettre en place plusieurs capteurs et de les mettre en réseau. On parle alors de réseau de capteur sans fils (avec l’acronyme RCSF en français et WSN en anglais pour Wireless Sensor Networks), qui n’est ni plus ni moins qu’un ensemble de capteurs au sein d’un même réseau sans fil.

Chaque capteur est considéré comme un nœud du réseau de capteurs et l’ensemble de la zone géographique où sont dispersés les capteurs est appelée le champ de captage. L’organisation ou l’architecture du réseau (on parle de topologie de réseau) est très importante à considérer parce qu’elle va définir comment les capteurs interagissent entre eux. On considérera notamment deux topologies principales, à savoir la topologie plate où tous les nœuds/capteurs possèdent le même rôle et la topologie hiérarchique où chaque nœud/capteur a différent niveau de responsabilité (Figure 6).

Figure 6. Topologie de réseaux. Source : wikiwand.com

Parmi les architectures relativement classiques, on retrouvera notamment :

la topologie en étoile : un ensemble de capteurs est disposé autour d’une station de base. Cette station de base (c’est aussi un nœud du réseau), contrairement aux autres nœuds du réseau, jouit par exemple d’une liaison radio longue portée. Les messages de chaque capteur/nœud sont donc envoyés à courte portée à cette station de base pour être ensuite envoyés ensemble ce qui évite de devoir installer une structure de communication plus massive sur chaque capteur. On peut tout à fait imaginer qu’un capteur soit aussi présent sur cette station de base. On pourrait par exemple avoir des capteurs connectés d’humidité du sol sur chacun des nœuds de l’étoile et une station météo connectée au niveau de la station de base. Au cas où ça n’était pas évident, gardez en tête que la communication se fait dans les deux sens. La station de base peut recevoir des informations depuis les nœuds adjacents en étoile mais aussi leur envoyer de l’information (par exemple pour mettre à jour un code sur un capteur). Sans grande surprise dans ce genre de topologie, ces réseaux peuvent être considérés comme vulnérables parce que c’est bien la station de base et elle seule qui envoie les données hors du réseau de capteur. Il faut donc s’assurer qu’il ne lui arrive pas de soucis…

la topologie en grille ou point par point (on parle également de communication multi-sauts) : ici chaque nœud du réseau peut échanger avec n’importe quel autre nœud du réseau si tant est que ces deux nœuds sont à une distance qui le permet (en fonction du protocole de communication utilisé). Si la distance est trop grande entre les noeuds, un nœud contactera son nœud cible en passant par des nœuds intermédiaires. Cette architecture apparait comme plus résiliente et souple (on ne se repose pas sur une seule station de base et on a de la redondance d’informations) mais elle demande un peu de plus de consommation d’énergie et impose potentiellement une latence, surtout si le message doit passer par plusieurs nœuds intermédiaires avant d’arriver à destination.

La topologie de groupe : ici les capteurs du réseau sont hiérarchisés. Chaque capteur peut communiquer avec l’ensemble des capteurs qui lui sont inférieurs en hiérarchie (en passant par des capteurs intermédiaires) et ne peut communiquer qu’avec un seul capteur qui lui est supérieur (son capteur/nœud chef). Et c’est ce nœud chef qui derrière peut communiquer soit avec d’autres nœuds chef de même niveau (qui sont sur une autre hiérarchie) ou alors directement avec la station de base. De la même façon que pour les réseaux en étoile, cette organisation de capteurs est assez sensible parce que la panne d’un objet de niveau supérieur entraine celle des objets situés en dessous. N’y voyez aucun parallèle avec des formes organisations en entreprise (oupsi).

Dans ces topologies, la communication entre les capteurs ou le routage de l’information au sein de ces réseaux peut être considéré comme pro-actif ou comme réactif. Dans le premier cas, les données sont remontées à intervalles de temps régulier ou au moins sur un pas de temps choisi (on parlera en anglais de communication time-driven). Dans le second cas, les capteurs doivent être capables de réagir rapidement à des variations importantes du paramètre qu’ils mesurent.

Toutes ces topologies et routages sont bien évidemment combinables entre elles, formant alors des topologies dites « hybrides ». Au vu de la figure précédente, les possibilités d’organisation semblent infinies. Les choix d’architecture sont alors souvent régis par un certain nombre de contraintes et ou le contexte d’utilisation du réseau de capteurs. On prendra notamment en compte la taille du réseau à déployer, le budget financier à dispo (qui contraint lui aussi la taille du réseau mais surtout le type de capteur choisi), la tolérance de fautes (c’est-à-dire à quel point il est acceptable ou non d’avoir des interférences ou des problèmes de connectivité), la localisation du réseau de capteurs (et contraint ainsi les protocoles de communication utilisés), ou encore la consommation d’énergie au sein du réseau). Petit aparté rapide. Dans le cadre de la topologie en étoile par exemple, la station de base est considérée comme une passerelle (ou gateway en anglais) en ce sens qu’elle permet de faire le pont entre les capteurs connectés et internet. De manière générale et si l’on sort du simple contexte agricole, les exemples de passerelles sont extrêmement nombreux : routeurs domestiques, téléphones mobiles, micro-ordinateur Raspberry Pi, carte électronique Arduino. Les passerelles s’assurent de la connectivité, la sécurité et la gestion des appareils connectés (traduction des protocoles de communication, agrégation de réseaux…).

Dynamique des objets connectés

Les prévisions de marché mondial des objets connectés vont crescendo… Je ne suis pas du tout en train de vous dire de suivre à la lettre ces prévisions parce que certaines de ces prophéties sont parfois simplement auto-réalisatrices (nous allons dans le sens des prévisions qui nous sont faites comme si nous étions appelées à les réaliser) ou encore tout simplement faites au doigt mouillé. Même si ces prévisions sont un peu ronflantes, force est de constater que le sujet des objets connectés intéresse un paquet d’industries différentes. Le deuxième graphique permet de jeter également un œil sur les types de connectivités envisagées. Cette demande croissante pour les objets connectés est rendue possible par toutes les avancées sur la miniaturisation des composants (microcontrôleurs, puces…), l’accessibilité des outils (capteurs etc…), le développement des réseaux, ou encore le coûts des composants.

Figure 7 : Dynamique du marché de l’internet des objets. Source : https://iot-analytics.com/

Comment expliquer la dynamique des outils connectés dans le secteur agricole ? Les raisons sont en réalité assez nombreuses. C’est peut-être déjà une histoire de prix. Les objets connectés, surtout s’ils sont fabriqués par les agriculteurs eux-mêmes, peuvent être obtenus à un prix relativement dérisoire – tout dépend le temps qu’on est prêt à y passer. Les capteurs unitaires présentés dans la section suivante sont pour certains de l’ordre de quelques euros. Il faudra, pour les connecter, rajouter au moins l’achat d’une carte électronique, d’un microcontrôleur et d’un module de télécommunication (puce ou antenne). L’ensemble reste à un prix abordable si tant est que l’on n’ait pas envie de déployer trop de capteurs connectés non plus. De-là à choisir entre quelques capteurs connectés de bonne qualité ou un lot important de capteurs low-cost mais de moins bonne qualité, il sera nécessaire de trouver des compromis. Au vu de la potentielle grande surface à couvrir en agriculture, accepter de déployer un nombre important de capteur au détriment de la qualité des données est aussi un moyen intéressant de dégager des tendances de fond. C’est aussi en ce sens un compromis intéressant pour agréger de la donnée à différentes échelles territoriales (pour de la biosurveillance, pour du pilotage d’irrigation à l’échelle d’un territoire relativement large, ou plus généralement pour appuyer une prise de décision politique).

Avec la démocratisation du smartphone, les agriculteurs ont eu aussi la possibilité d’installer des applications professionnelles sur leur téléphone et ainsi d’accéder potentiellement en temps réel à des données collectées depuis les capteurs présents en parcelle.

Les objets connectés semblent être également un bon moyen d’économiser du temps et d’éviter des déplacements. Pour ceux qui ont lu mon précédent dossier sur les outils numériques en apiculture , j’apprenais par exemple que la charge économique principale d’un apiculteur était liée à ses déplacements. L’exemple cité plus haut dans ce dossier autour de la station de pompage pour éviter les aller-retours inutiles parait lui aussi tombé du bon sens (le fait d’avoir un parcellaire morcelé et/ou loin de son principal site d’exploitation agricole est une autre question). Collecter des données à distance et en temps réel permettrait également de pouvoir analyser et traiter la donnée au bon moment

Pour être totalement transparent, il faudra aussi afficher les contraintes logistiques liées à un tel déploiement d’objets connectés. Ces contraintes tiennent déjà dans l’entretien et la réparation des objets connectés (transmission des données interrompue, capteur abîmé, obstacle ou encombrement du capteur…) qui peuvent affecter la qualité des données remontées (ou même empêcher la remontée de donnée). Même si ces exigences n’incombent pas forcément à l’agriculteur – certains prestataires peuvent avoir un très bon service après-vente ou certains collectifs peuvent se regrouper pour gérer un réseau de capteurs à plusieurs, la dette technique liée à un mauvais entretien ou une mauvaise réparation ne peut pas être totalement éludée. Et pour être sûrs que ces problèmes ne se reproduisent pas, il faudra essayer de relier des incidents à des évènements sur l’exploitation : Depuis quand l’objet a-t-il cessé d’émettre ? Pour quelles raisons potentielles : une tempête, un passage d’engins agricole, un passage de sangliers ?

L’entretien des objets connectés est un sujet multi-factoriel. En plus des sujets cités juste-aussi, l’entretien est également lié à l’autonomie énergétique de l’objet connecté. Si certains dispositifs semblent avoir été conçus pour plusieurs années d’autonomie, ce n’est pas nécessairement le cas de tous. Si le capteur est déployé sur une parcelle relativement proche de l’exploitation, la contrainte n’est peut-être pas trop forte. Par contre, dans un contexte pastoral, avec des capteurs potentiellement installés sur des territoires de haute montagne, le manque d’autonomie du capteur est tout de suite plus préoccupant. Certains objets connectés auront aussi besoin d’être mis à jour de manière plus ou moins régulière. Il sera alors important de se demander si ces mises à jour peuvent être faites à distance (via connexion au réseau cellulaire par exemple) ou si elles sont possibles au moins depuis le bureau de l’exploitant agricole. Rappelons également que ces mises à jour ne sont pas nécessairement gratuites et qu’il faudra s’assurer des conditions générales de vente à l’achat du capteur ou de l’abonnement associé.

Pour éviter d’endommager les objets connectés, certains capteurs devront être mis à l’hivernage en ce sens qu’ils devront être stockés potentiellement à température ambiante, que la tension de la batterie devra être vérifiée et qu’il faudra même peut être vérifier que l’objet connecté est bien éteint quand il n’est plus utilisé à la fin de saison.

Nous reviendrons assez largement sur les enjeux de connectivité et de transmission de données des objets connectés. Avant de parler technique et protocole de communication, ce sont aussi autant de règles bonnes pratiques qu’il faudra mettre en place : capteurs à ne pas placer en fonds de vallon ou à proximité d’une forêt, ou encore s’assurer que l’on capte au moins une barre de connexion auprès d’un opérateur pour une connexion via le réseau cellulaire… Et de choisir ensuite des protocoles de communication adaptés à son usage (nous y reviendrons plus loin), de se demander si le capteur fonctionnera à l’intérieur des bâtiments ou seulement à l’extérieur, de questionner ce qu’il se passe s’il n’y a plus de communication des données (est ce que les données sont quand même stockées in situ ?)

Peut-être qu’un premier test de l’objet connecté au siège de l’exploitation est un pré-requis avant un déploiement sur le terrain, histoire de constater que tout fonctionne correctement et de ne pas avoir de mauvaise surprise au champ…

Les exemples de capteurs en agriculture

Les applications agro-environnementales des capteurs connectés sont assez infinies. Entre du suivi de migrations et déplacements de populations animales, du suivi d’un parc machines pour consolider des bases de données de fonctionnement/pannes et imaginer par exemple un dépannage à distance ou encore pour du pilotage et contrôle en temps réel d’un réseau d’irrigation, vous n’avez que l’embarras du choix.

Figure 8. Exemples de capteurs utilisables dans un contexte en agro-environnement.

Vous manquez d’idées ? Petit florilège de capteurs (à connecter ou pas !). Gardez en tête que pour chacun de ces capteurs (Figure 8), des gammes de prix assez variables (et donc de qualité) existent.

Capteur de « flexion » à installer par exemple sur des roues de tracteur pour évaluer en dynamique la pression des pneus et pourquoi pas déterminer indirectement le poids transporté par le tracteur. En fonction de la flexion, les barres métalliques au sein du capteur se rapprochent plus ou moins pour laisser passer le courant (le capteur contient une alternance de bandes métalliques et non métalliques)

Capteur de « température » ou « pluviomètre » : a-t-on vraiment encore besoin de les présenter ?

Capteur de « pression » qui repose sur un fonctionnement assez similaire à celui du capteur de flexion (les barres métalliques se rapprochent non plus avec la flexion mais avec la pression ambiante). Pourquoi ne pas s’en servir pour mesurer des niveaux de fond de cuve (la pression change avec l’altitude)

Capteur « ultrason » pour mesurer par exemple des hauteurs d’herbe (on parle d’herbomètre) ou plus simplement des distances (le bip bip assez insupportable du radar de recul de votre voiture est souvent basé sur un capteur à ultrasons). Le capteur à ultrasons pourrait aussi être testé pour mesurer des niveaux de cuve. Les ultrasons dépendent de la vitesse du son (jusque-là tout va bien…) et la vitesse du son dépend de tout un tas de choses comme par exemple la température, les vapeurs d’alcools, le niveau de particules ou de saleté.

Capteur « microphone » pour suivre des niveaux de bruit et détecter des présences. On peut penser aux éleveurs qui s’inquiéteraient d’agresseurs rodant autour de leur cheptel

Capteur « proche infrarouge » eux aussi utilisables pour détecter des présences (et relativement connu dans le domaine de la domotique)

Capteur « sonde capacitive » pour s’assurer par exemple que l’eau d’un réseau d’irrigation arrive en bout de ligne dans un cadre de maraichage en goutte à goutte.

Capteur « multispectral » à utiliser en passif ou en actif (avec des diodes sur le capteur) pour prendre des images de végétation et suivre en dynamique ou pas une évolution de cette végétation dans le temps (suivi de la phénologie)

Capteur « Antenne GPS » pour rajouter un module de positionnement sur un outil embarqué sur machines. Je vous renvoie ici vers un précédent dossier sur le géo-positionnement en agriculture

Capteur « Chimique » pour mesurer par exemple en dynamique des niveaux de CO2 ou d’éthanol dans une pièce

….

Et en conditions opérationnelles, ça donne quoi ?

Qu’ils soient fixes, portés à la main ou embarqués (sur animal, plante, machine agricole, drone, avion ou encore satellite), les capteurs sont certainement la catégorie de technologie la plus représentée dans l’écosystème numérique agricole (Figure 9). Les lecteurs intéressés pourront aller retrouver la grande majorité de ces outils sur l’annuaire des outils numériques des agriculteurs une plateforme gratuite, en accès libre et collaborative qui recense les outils numériques disponibles pour les acteurs agricoles.

Figure 9 : Les capteurs, connectés ou non en agriculture. Source : Aspexit

Et pour les aficionados de machines agricoles, une petite figure pour vous montrer l’étendue de capteurs présents sur certains tracteurs (Figure 10).

Figure 10. Exemples de capteurs connectés sur machine agricole.

Les protocoles de communication

Quels paramètres considérer pour choisir un protocole de communication ?

Comme nous allons le voir, les protocoles de communication sont extrêmement nombreux. L’idée n’est pas ici de rentrer dans une liste à la Prévert soporifique au possible et d’expliciter chacun de ces protocoles précisément. Certains l’aurait déjà largement fait beaucoup plus finement que moi (même si le contenu n’est parfois pas vraiment rendu compréhensible pour le commun des mortels). J’essaierais plutôt de vous en dégager les grands enjeux et de poser parfois quelques éléments de comparaison qui me paraissent pertinents – en utilisant d’ailleurs pas mal de figures.

Le protocole de communication définit la structure, le format et la taille des messages à envoyer. Mais mettez-vous bien ça dans le crâne. « The » protocole de communication ultime qui surpasse tous les autres n’existe pas ! Le meilleur protocole à utiliser dépend de votre contexte. Pour envoyer des données depuis un objet connecté à un autre objet connecté ou une station de base (que l’on soit dans un réseau de capteur sans fil ou non), tout est une histoire de compromis entre :

Les fréquences hertziennes utilisées par le protocole (Figure 11) : outre quelques fréquences utilisées dans un contexte militaire, les fréquences définies sont libres mais elles sont contrôlées par l’ARCEP. Il n’est pas possible d’y mettre la puissance que l’on veut. Les réseaux Sigfox et Lora utilisent par exemple la fréquence 868 MHz en Europe (ce n’est pas la même bande de fréquence aux Etats-Unis et le fait d’utiliser des fréquences différentes entre pays peut poser problème pour le déploiement à l’international d’un fournisseur de capteurs connectés en agriculture). Cette fréquence 868 MHz est libre mais contrôlée par l’Arcep. La guerre fait rage au niveau des opérateurs télécom pour acheter des bandes de fréquences pour pouvoir y déployer certains protocoles de communication. Certains protocoles sont également critiqués, notamment la 5G, parce que les ondes radio utilisées par la 5G pourrait venir interférer avec les radars météorologiques

Figure 11. Représentation de quelques protocoles de communication sur le spectre de fréquence. On y retrouve notamment présentés le WiFi, les compteurs intelligents, la téléphonie cellulaire ou encore les lecteurs de code-barre.

La portée du signal envoyé, c’est-à-dire la distance jusqu’à laquelle le protocole peut porter l’information de l’objet connecté jusqu’au point relai (smartphone, passerelle wifi, antenne relai…). Certains protocoles utilisés en domotique comme le Zigbee par exemple ont une portée extrêmement faible contrairement à des protocoles plus largement pensés pour les réseaux de capteurs en extérieurs comme le LTE-M ou le NB-IoT. Notez que certaines personnes ont réussi à diffuser des données via le protocole Lora sur des très grosses distances (+ de 1000 km). Les protocoles de communication sont souvent catégorisés en fonction de leur portée ce qui définit généralement leur cadre d’utilisation. On entend notamment parler – du réseau le plus courte portée à celui le plus longue portée – des réseaux PAN (Personal Area Network), LAN (Local Area Network), MAN (Metropolitan Area Network) et WAN (Wide Area Network). Pour les réseaux bas-débit utilisés dans le cadre des objets connectés, vous verrez aussi certainement la terminologie LPWAN (Low Power Wide Area Network) qui sont des réseaux bas débit à longue portée (Figures 12 et 13)

Figure 12. Classification des protocoles de communication dans les réseaux PAN, LAN, MAN et WAN

Figure 13. Autre représentation des protocoles de communication (avec de nouveaux exemples) en fonction de leur portée. La portée est courte (donut bleu), moyenne (donut noir) et longue (donut orange). On aurait pu y rajouter aussi la technologie Infrarouge.

Les réseaux cellulaires sont des réseaux qui utilisent les ondes radio pour communiquer au travers des antennes d’opérateurs existants. C’est par exemple le cas des réseaux GSM (2G), GPRS, Edge, 3G, 4G et 5G. Les réseaux 3G et 4G n’ont « que » quelques kilomètres de portée (2-3 km) mais nos données sont en réalité transportées d’antenne en antenne ce qui fait que l’on peut y accéder de n’importe où en payant notre abonnement. La 4G n’est pas optimisée pour l’internet des objets (IoT). On lui préfèrera notamment le 4G LTE-M (il faudrait d’ailleurs plutôt parler de 4G-LTE Catégorie M1). Gardez simplement à l’esprit qu’il y a plusieurs catégories de 4G et que la 4G-LTE Catégorie M1 est notamment celle qui permet de transmettre peu de données sur les antennes 4G (c’est donc particulièrement intéressant pour les réseaux d’objets connectés). L’utilisation de la 4G LTE-M est relativement triviale pour les opérateurs télécom parce qu’ils n’ont rien à installer de supplémentaire sur leurs antennes relai existantes (il y avait simplement un petit programme de code à rajouter dessus). Par contre, pour ceux qui n’ont pas d’antennes (comme Sigfox ou Lora), ils ont dû le faire eux-mêmes. Et cette 4G LTE-M permet l’équivalent d’un protocole LoRaWAN déployés sur les infrastructures existantes des opérateurs télécom (en passant donc par le GSM). Pour pouvoir utiliser la 4G LTE-M, il faut être couvert par une antenne 4G.

Outre le 4G LTE-M, vous verrez également souvent évoqué le protocole NB-IoT qui commence à prendre beaucoup de place et qui a fait plutôt mal aux technologies Lora et Sigfox, et dans une moindre mesure le protocole EC-GSM-IoT est déployable sur le réseau GSM existant (2G/3G/4G) avec une simple mise à jour logiciel.

Le débit de données capables de transiter via le protocole sur un temps donné, c’est-à-dire la capacité de transmission de données montantes (vers le réseau) et descendantes (vers le capteur) que l’on peut envoyer par seconde (vous avez peut-être déjà testé de mesurer la qualité de votre connexion à la maison avec des simulateurs simples sur le web). Dans le cas des objets connectés, le débit descendant est important à considérer pour des opérations de maintenance ou de mise à jour. On parle de mises à jour « Over The Air » (OTA) dans le sens où ces mises à jour sont transmises directement aux objets connectés sans intervention en présentiel. Pour les réseaux avec un débit trop faible comme LoRaWAN ou Sigfox, cette mise à jour OTA est relativement compliquée voire impossible. Historiquement, les protocoles de communication ont été principalement pensés pour booster le débit et envoyer toujours plus de données. Ce n’est pas le cas des protocoles de communication bas-débit qui ont été remis à jour suite aux nouveaux besoins d’objets connectés (Figure 14) : envoi de petites données, avec un très faible débit (inférieur au Ko/s) avec une très longue portée (plus de 10km) et une grande autonomie (plusieurs années). Certains utilisent la dénomination 0G pour parler des réseaux bas débits (comme Sigfox ou Lora par exemple) tant les débits sont inférieurs à ceux de la 1G et de la 2G. Avec le réseau Sigfox par exemple, vous ne pouvez envoyer que 144 messages par jour en montant (du capteur vers l’application/interface) de la taille de 12 octets max (une photo de téléphone fait 3 millions d’octets) et que 4 messages par jour en descendant (envoi d’information au capteur [mise à jour, mise en veille, activation]). Et la taille des messages, je ne vous en parle pas. Ce n’est ni plus ni moins que l’équivalent d’un sms de 12 caractères. Même si dans la vie de tous les jours, vous pourriez avoir envie de frapper violemment les gens qui vous envoient un « coucou sa va », ici dans le cadre de l’IoT, il faudra l’accepter parce que la cédille « ç » prendrait plus de place.

Figure 14. Compromis entre débit (axe des ordonnées) et portée (axe des abscisses) de quelques protocoles de communication.

La consommation énergétique de l’objet connecté et de l’envoi de données (Figures 15 et 16). Chaque capteur passe par différentes phases de collecte de données, de traitement, de transmission et d’envoie de données. Chacune de ces phases est consommatrice d’énergie (à plus ou moins haut niveau). Le mode « écoute », c’est-à-dire lorsque le capteur est prêt à réceptionner de l’information qui lui vient d’un autre capteur connecté ou d’un point relai, consomme de l’énergie. Il peut donc être intéressant de passer le capteur en mode veille autant que possible (représenté dans la figure en anglais par le mode « Stand By »). Notez que le passage de l’objet connecté d’un état à un autre consomme aussi de l’énergie. Les capteurs connectés peuvent être soient autonomes en énergie avec une pile ou une batterie sur un certain laps de temps ou directement connectés à une source d’énergie (panneau photovoltaique ou raccordement au réseau électrique quand c’est possible).

La consommation énergétique de votre protocole est un choix. Si vous avez par exemple un objet connecté qui consomme déjà beaucoup d’énergie (on peut penser par exemple à des pièges connectés à papillon qui demandent d’être allumés constamment parce que l’on ne sait jamais quand le papillon va rentrer dans le piège), la consommation d’énergie due à la transmission de données n’est peut-être finalement pas si importante à considérer que ça.

Figure 15. Consommation énergétique des différents niveaux d’état des capteurs connectés. Source : Amengu et al., (2022). SMAC-Based WSN Protocol-Current State of the Art, Challenges, and Future Directions. Journal of Computer Networks and Communications.

Figure 16. Comparaison de la consommation énergétique de différents protocoles de communication. Enocean, non présenté ici, serait un réseau complètement autonome en énergie et déployable dans des zones complètement isolées comme en plein milieu de l’océan.

Les fréquences libres ou les fréquences sous licence (comprenez ici que c’est payant dans ce cas-là). Les fréquences libres peuvent souffrir d’interférences ou de brouillage imprévus contrairement aux fréquences sous licences plus sécurisés. Le prix d’abonnement au protocole n’est bien évidemment pas le même. Il sera également important de s’assurer de la compatibilité des objets connectés avec ces fréquences utilisés par le protocole

Le choix d’un réseau opéré ou d’un réseau non opéré. Dans le cas du réseau opéré, c’est l’opérateur de télécommunication (ex : Orange, Bouygues…) qui gère son propre réseau et qui s’occupe de la maintenance de ces infrastructures (antennes, points relais…) et des potentiels problèmes de connectivité contre le paiement d’un abonnement (en gros, il n’y a qu’à déployer les objets connectés, les opérateurs télécom s’occupent du reste). C’est par exemple ce qui se passe pour le réseau Objenious (déployé par Bouygues, c’est un LoRaWAN opéré en gros) dédié aux objets connectés ou le réseau Sigfox. Dans le cas des réseaux non opérés, l’utilisateur crée lui-même sa connexion au réseau sans opérateur tierce. C’est par exemple le cas du protocole LoraWAN où n’importe qui peut permettre le passage de données entre le réseau LoRaWAN et les réseaux IP classiques en se connectant à une antenne LoRa existante ou en installant sa propre station de base LoRa. Le réseau The Things Network (TTN) est un réseau communautaire qui recense l’ensemble des stations de base (passerelles) LoRa auxquelles un objet connecté peut se raccorder sans frais. TTN vend des boitiers LoRa avec l’objectif que les utilisateurs déploient un réseau LoRa près de chez eux. TTN fait aussi de l’intégration de données avec plusieurs options disponibles (Base de données en propre de TTN donc interrogeable par requête, module MyDevices pour récupérer les donnée sur son smartphone…). La couverture de ce réseau dépend donc des stations déjà installés. Notez que, pour cet exemple, les principaux opérateurs télécom ont eux aussi déployé leur réseau LoRaWAN en passant par leur propre infrastructure (il faudra par contre payer dans ce cas-là un abonnement alors que dans le cas d’un réseau non opéré, vous n’aurez à payer que le coût de votre antenne). Notez également qu’un service peut combiner des réseaux différents (par exemple un réseau LoRaWAN personnel pour capter les données de plusieurs capteurs et les envoyer sur un datalogger et un réseau sigfox pour envoyer les données du datalogger au serveur). Les protocoles Wifi et Bluetooth sont d’autres exemples de réseaux non opérés.

Le coût d’ensemble du réseau, à la fois celui de la partie « hardware », c’est-à-dire le type de capteurs installés et le nombre déployé mais aussi le coût de l’abonnement aux protocoles de communication qui va dépendre de toutes les caractéristiques que nous avons discutées plus haut.

La compatibilité des capteurs avec les protocoles de communication. Avec The Things Network (TTN) par exemple, les utilisateurs un peu geek sont capables d’aller se débrouiller un peu par eux-mêmes en allant sur le site de TTN, en définissant un protocole de communication et en achetant des capteurs connectés compatibles avec The Things Network. Vous pouvez même acheter un capteur pré-paramétré et c’est votre fournisseur Agtech ou autre (par exemple un constructeur de station météo) qui pourra potentiellement faire le lien avec ce capteur. Par contre, si vous achetez un capteur qui n’est pas compatible avec TTN, c’est tout de suite plus compliqué et ça peut être particulièrement gênant si vous aviez acheté une antenne The Things Network par exemple. Nous rediscuterons un peu plus loin des nouveaux protocoles « Matter » et « Thread » qui se veulent devenir globalement unanimes en ce sens qu’ils pourraient faire communiquer les objets connectés directement les uns avec les autres plutôt que de passer par un serveur global

Et chaque protocole de communication a généralement des performances intéressantes sur un ou plusieurs de ces critères et au contraire des succès beaucoup plus limités sur les autres… Comment choisir le protocole de communication le plus pertinent pour son cas d’usage dans tout ce gloubi-boulga ? La réponse n’est pas évidente mais l’ensemble des caractéristiques discutées devrait vous aider à y voir plus clair. J’en profite pour rajouter ici un arbre de décision avec quelques touches d’humour qui pourra également vous apporter quelques clefs de lecture (Figure 17).

Figure 17. Arbre de décision pour aider au choix d’un protocole de communication. Source : eMind

Je rajoute ici une infographie assez parlante – et en plus recontextualisée pour l’agriculture – qui revient sur l’utilisation des protocoles que nous avons évoqués (Figure 18). Vous y voyez par exemple des équipements automatisés en bâtiments d’élevage (ex : capteur gaz et d’ambiance environnementale, caméra connectée…) qui vont communiquer via des protocoles à relativement courte portée (RFID, WiFi, Bluetooth…) avec leur point relais. Vous y trouvez aussi des capteurs connectés au champ (stations météo connectée) ou embarqués sur machine qui eux, communiqueront plutôt sur des protocoles LPWAN cellulaires ou non (3G, LoRa, GPRS, Sigfox, NB-IoT…). L’ensemble de ces données, stockées sur des serveurs seront requêtables par différentes API servies par les fournisseurs et restituées sur les interfaces de l’utilisateur (smartphone, tablette, ordinateur…).

Figure 18. Objets connectés et trajet de la donnée en agriculture. Source : ACTA et FRCUMA Bretagne

Le cas un peu particulier du satellite IoT

Petit aparté sur la transmission de données IoT via satellite qui, même si elle représente une toute petite partie de la communication des objets connectés, est quand même une voie qui mérite au moins une petite présentation. Au vu de la portée des antennes de communication (quelques dizaines de kilomètres), vous serez certainement d’accord pour dire que déployer des antennes sur la totalité du globe est quelque peu fastidieux et surtout particulièrement difficile à mettre en place dans certaines endroits de notre planète – à commencer peut-être par les océans (et je passe sur tous les autres enjeux associés…). Avec la communication des objets connectés directement via satellite, l’idée est de se servir des satellites à la fois come des récepteurs et des émetteurs de données. L’objet connecté va se synchroniser avec le satellite pour lui envoyer ses données lorsque le satellite passera à portée. Le satellite déchargera ensuite l’ensemble de ces données un peu plus tard lorsqu’il passera au-dessus d’une station de base localisée à un endroit plutôt bien accessible. Cette station, connectée à internet, transférera les données reçues sur un serveur qui pourront être disponible pour les utilisateurs.

TinyGS est une application qui propose de déployer de petits objets connectés qui réceptionneront des données satellite. Plusieurs autres projets existent en ce sens, des projets Open Source (Fossa-Sat1 qui utilise une technologie LoRaWAN par satellite – la portée de transmission serait potentiellement très importante si on pointait le faisceau d’un objet connecté vers le ciel) et aussi commerciaux (l’entreprise Kinéis – ancien fabricant des balises Argos, et l’entreprise Lacuna Space en sont des exemples). A l’heure actuelle, une transmission telle quelle par satellite (et au vu du nombre de satellite), offre un temps de latence relativement important (on parle de 6h, c’est incompatible avec un capteur incendie). L’initiative Starlink d’Elon Musk dont l’objectif est d’offrir une connexion internet par satellite demanderait un nombre absolument gigantesque de satellites en orbite pour un débit de toute façon assez bridé. On pourrait imaginer un objet connecté en wifi (peut-être une version du wifi dédiée à l’IoT) pour communiquer par internet via Starlink (à condition d’avoir une source d’énergie suffisante, et la place pour déployer une antenne).

Idées reçues et abus de langage

Premier abus de langage tellement démocratisé que l’on y fait même plus attention : L’Internet et le Web, ce n’est pas la même chose. Le Web, globalement, c’est le contenu et l’Internet, c’est le moyen de transporter et d’accéder à ces contenus. L’internet, c’est l’ensemble des architectures informatiques (câbles, antennes, serveurs…) alors que le Web, ce sont des documents en ligne (les pages/sites web). Internet repose sur le protocole TCP/IP et sur un accès à internet (via un fournisseur d’accès internet). Nous avons vu qu’il y avait énormément de protocoles de communication pour se connecter à internet et que l’internet des objets permettait de connecter des objets physiques (par exemple des capteurs au champ) à internet. Le Web repose sur un système de liens hypertextes et nécessite un navigateur (Chrome, Firefox, Safari) pour accéder aux sites présents sur le web. Pour accéder au Web, vous avez besoin d’Internet mais vous pouvez faire autre chose que simplement aller sur le web avec Internet. Vous pouvez notamment envoyer et recevoir des e-mails sur votre messagerie, accéder à des serveurs FTP pour partager de la donnée etc…

Deuxième surprise : Lorsque vous passez un appel téléphonique, la communication ne passe pas (en très grande majorité) par satellite, non… J’en profite pour glisser ici que le GPS fonctionne sans internet parce que lui, il est satellitaire (c’est pour ça que quand vous coupez internet, vous avez toujours un positionnement sur vos applications smartphone). Le réseau GSM (Global System for Mobile Communication – c’est la 2G), qui a été spécialement conçu pour passer des appels et envoyer des SMS passe dans des grands câbles de cuivre qui sont présents sur l’ensemble de la terre. Le réseau GSM est divisé en sorte de « cellules » crées par des stations de base (la portée autour de la station de base) dont le maillage est fonction de la population à couvrir. La connexion au réseau GSM se fait par la carte SIM (Subscriber Identity Module) que vous avez dans votre téléphone. Cette carte SIM est une clef d’identification sur le réseau GSM qui va chiffrer votre communication pour sécuriser vos échanges. Généralement, vous utilisez une carte SIM mono-opérateur, c’est-à-dire que vous utilisez les infrastructures de télécommunication d’un seul opérateur. Il est possible d’utiliser des cartes SIM multi-opérateurs (comme ce que propose par exemple les entreprises Matooma ou Things Mobile qui ont négocié des contrats d’itinérance dans de nombreux pays différents) de manière à scanner tous les réseaux disponibles dans un espace donné et de connecter vos capteurs au meilleur réseau à l’instant T et ainsi limiter les risques de pertes de communication. Vous imaginez devoir changer manuellement de connexion et de carte SIM a chaque fois que vous passez de la 3G a la 4G, ou au WIFI quand vous arrivez chez vous ?

Le fait de pouvoir changer facilement de réseau comme ça s’appelle le « Roaming ». Le roaming est plutôt bien géré avec le réseau GSM et n’est par exemple pas disponible sur les réseaux Sigfox ou LoRa. Pour optimiser la connexion de vos objets connectés au réseau GSM, vous pouvez donc acheter des forfaits GSM IoT multi-opérateurs avec une facturation souvent faite à la quantité de données transmise par mois et par capteur. Rien ne vous empêche d’avoir également plusieurs protocoles de communication directement installés sur votre objet connecté. Vous pourriez par exemple imaginer deux cartes de communication – une qui ferait du GSM et une autre qui ferait du Sigfox. Cela peut notamment être intéressant si vous déployez votre objet connecté dans plusieurs pays dont certains n’auraient par exemple pas suffisamment d’antennes Sigfox installées, ce qui limiterait la couverture réseau de vos objets connectés localisés à l’étranger (contrairement au réseau GSM qui est mieux disséminé dans le monde).

Certains objets connectés sont capables de fonctionner avec le protocole SMS mais les opérateurs télécom taxent plus les SMS que les quelques kilo-octets de données qui passent par un protocole 2G (c’est le réseau GSM) ou autre. Des millions d’objets connectés fonctionnent en 2G (systèmes d’alarme, boutons d’appels, systèmes de diagnostic où on ne va pas faire de la maintenance rapidement…). Il est néanmoins prévu que la 2G s’arrête, notamment parce que la 2G consomme beaucoup d’énergie par rapport à la quantité de données envoyées. Mais du fait de son utilisation massive pour l’IoT, son arrêt est reporté au fur à mesure que l’échéance approche. Il se pourrait bien que la 3G (finalement plus obsolète) ne soit déconnectée avant. On peut noter que les Etats Unis ont quant à eux déjà commencé à débrancher la 2G.

Quand on vous dit qu’un objet connecté ne communique pas, il faut en fait que vous compreniez que le choix technologique sous-jascent qui a été fait (en termes de protocole de communication par exemple) ne permet pas de communiquer. Ca reste un choix, certes potentiellement tout à fait légitime, mais il y aurait pu en avoir d’autres. Les réseaux cellulaires et la Wifi nécessitent une phase d’accroche au réseau et une phase de validation, ce qui augmente le temps nécessaire pour envoyer un message contrairement aux réseaux radio plus basiques comme LoRa ou Sifgox qui ne confirment pas la réception de messages et qui ne dialoguent pas avec le réseau.

Le modèle OSI et les réseaux

Cette section est peut-être légèrement plus technique que les autres mais elle a l’intérêt de pouvoir prendre du recul sur ce dont on a discuté dans les parties précédentes. Le modèle OSI (Open Systems Interconnection) est une représentation des relations qui existent entre tous éléments informatiques d’un réseau et qui permet de voir comment les données transitent d’un point A vers un point B.

Le modèle OSI se présente en 7 couches distinctes dont 3 couches matérielles (dites couches basses) et 4 couches hautes (Figure 19). Les données des capteurs connectés sont par exemple transmises sur le réseau physique (composants, câbles, broche des capteurs…) en binaire (des 0 et des 1). Les 8 premiers-bit d’une série binaire constituent la trame du message, c’est-à-dire l’adresse MAC (privée) du capteur. Nous l’avons déjà discuté mais les objets connectés ne sont pas directement connectés au réseau internet. N’oubliez d’ailleurs pas que le « i » de « IoT » est bien celui d’internet ! L’internet des objets permet de connecter les objets du monde physique au réseau internet. Cette connexion se fait généralement par des passerelles (les « gateways » ou antennes) qui en assurent l’intermédiation. L’existence de ces passerelles est dû au fait que l’internet n’est pas dimensionné pour gérer l’adressage de milliards d’objets connecté et que le protocole TCP IP/V6 (couches 3 et 4 du modèle OSI) est un protocole trop lourd pour être exploité directement par les objets connectés. Les couches les plus hautes du modèle, notamment la toute dernière – la couche 7 – est celle la plus proche de l’utilisateur final et c’est celle à laquelle nous, en tant qu’utilisateurs, avons directement affaire. C’est par exemple cette couche qui crée l’interface entre l’humain et des applications largement démocratisées comme le navigateur web ou le service d-e mailing.

Figure 19. Les 7 couches du modèle OSI

Le modèle OSI est un modèle théorique et la représentation pratique (simplifiée) est plutôt celle que l’on connait sous le nom plus classique du modèle TCP/IP (Figure 20). Notez également que tous les équipements n’utilisent pas l’entièreté des couches du modèles OSI. Certains, comme les routeurs, par exemple, n’ont besoin que des couches 1 à 3.

Figure 20. Modèles TCP/IP et Modèle OSI

Quand deux personnes (appelons les personnes 1 et 2) communiquent entre elles par exemple, il faut bien comprendre que les données passent de la couche « Application » (couche 4 du modèle TCP/IP ou couche 7 du modèle OSI) de l’ordinateur 1 à la couche « Application » de l’ordinateur 2 (pour être accessible depuis le navigateur de l’utilisateur 2) en passant par l’ensemble des couches du modèle OSI (Figure 21). Les données de l’ordinateur 1 sont encapsulées (on descend dans les couches du modèle) pour être transmises en format binaire (bits) dans le réseau puis desencapsulées (on remonte dans les couches du modèle) pour être accessibles par l’utilisateur 2.

Figure 21. Modélisation du transfert de données entre deux utilisateurs avec la représentation TCP/IP.

Chacune des couches du modèle OSI fait intervenir des protocoles différents, certains de ces protocoles jouant d’ailleurs un rôle du plusieurs couches en même temps (Figure 22). Cette spécificité fait que les protocoles de deux couches différentes ne sont en réalité pas vraiment comparables. La figure X replace sur un même schéma plusieurs protocoles dont nous avons discuté et en fait le lien avec leur place sur les couches du modèle OSI.

Vous y voyez par exemple que les protocoles LoRa et RFID sont seulement des protocoles pour transférer de la donnée binaire, que le protocole Bluetooth intervient à la fois sur les couches « Physiques » et « Liaison » (l’utilisation du Bluetooth pour les objets connectés ne serait intervenue qu’à l’apparition du Bluetooth Low Energie – BLE pour limiter les débits de données et par là-même les consommations d’énergie), ou encore que le Zigbee qui n’est utilisé que pour le transport des données sur le réseau internet. L’intérêt du Zigbee étant de créer un réseau WPAN plus simple et moins cher qu’avec des technologies classiques comme le Bluetooth ou le Wi-Fi parce que l’utilisateur a la main sur les protocoles utilisés sur les couches 1 et 2 du modèle OSI. Pour revenir rapidement à LoRa, faites bien la distinction entre le protocole Lora, qui définit le fonctionnement de la couche de niveau 1 (Physique) et le protocole LoRaWan, promu par la LoRa Alliance qui touche quant à lui à la couche de niveau 2 (Liaison). Vous aurez donc peut-être compris que ce n’est pas parce que votre capteur est compatible LoRa qu’il est nécessairement compatible LoRaWAN. LoRaWAN utilise la technologie Lora pour communiquer mais il existe bien un protocole Lorawan qui est une façon parmi d’autres d’encapsuler la technologie LoRa. LoRaWAN, c’est un standard qui est fait pour que les différents objets connectés compatibles LoRaWAN communiquent avec les antennes LoRaWAN sans avoir à s’embêter avec des problématiques de gestion de fréquences (spreading factor, chirps…). Vous n’êtes donc pas obligés d’utiliser le protocole LoRaWAN pour travailler avec une puce LoRa. Au niveau matériel d’ailleurs, vous pourriez même utiliser une puce LoRA et ne pas la faire émettre des données avec le protocole LoRa (la puce peut émettre avec n’importe quelle modulation de fréquences…).

Figure 22. Représentation de différents protocoles de communication sur les couches du modèle OSI. Source : Linux Embedded.

Et pour les plus geeks d’entre vous, je vous ai trouvé une figure qui revient très en détail sur différents protocoles que vous pourrez trouver au niveau de chaque couche du modèle OSI (Figure 23)

Figure 23. Le modèle OSI et les protocoles de communication en détail.

Le serveur de messagerie MQTT

Difficile de parler d’objets connectés sans évoquer le protocole MQTT (Message Queuing Telemetry Tranport). MQTT est un protocole particulièrement adapté pour transporter les données d’objets connectés sur internet (Figure 24). Si l’on reprend le modèle OSI de la section précédente, MQTT se place plutôt au niveau de la couche 5 (la couche « session) juste au-dessus de la couche réseau TCP/IP. Le protocole MQTT est donc routable par internet. Lorsque l’on envoie des messages d’objets connectés par Wifi ou Ethernet, c’est plutôt intéressant de les envoyer en MQTT parce que le message est léger et qu’il y a suffisamment de sécurité pour que le message ne soit pas perdu dans la nature (nous reviendrons là-dessus juste après). En termes de comparaisons avec d’autres protocoles dont nous avons discuté, The Things Network est plutôt positionné sur la couche applicative 7 du modèle OSI alors que la technologie LoRa est plutôt au niveau de la couche 1.

Il faut comprendre MQTT comme une sorte de serveur de messagerie d’objets connectés (un peu comme un Discord ou un Instagram) où chaque objet connecté viendrait « publier » ses données sur le serveur ; serveur qui ensuite pourrait rediffuser ces données à tout un tas d’applications diverses et variées. Les utilisateurs (qui peuvent être d’autres objets connectés ou des applications) viennent « s’abonner » au fil de publication ou au topic (vraiment comme un topic sur Discord ou Instagram) pour voir les données disponibles. On peut par exemple imaginer un topic « données de température » sur le serveur qui viendrait stocker les données de température envoyées par un capteur de température. Dans le cadre de MQTT, plutôt que de parler de serveur, vous entendrez plutôt le terme de « Broker MQTT ». Ce broker MQTT peut être installé sur un ordinateur portable ou sur un micro-ordinateur Raspberry Pi. L’utilitaire « Mosquitto » permet par exemple de transformer son ordinateur en broker MQTT. Vous pouvez aussi utiliser le dispositif Mosca JS qui est un broker MQTT à part entière.

Un des gros intérêts du MQTT est qu’il introduit la notion de Qualité de Service (QoS), c’est-à-dire que ce dispositif permet de s’assurer que la donnée envoyée a bien été reçue. Contrairement à la communication Sigfox qui utilise une communication via radio sans confirmation de données (le message est envoyé 3 fois mais si le message n’est reçu par aucune antenne, l’objet connecté n’a aucune idée que le message n’est reçu par aucune antenne parce qu’il n’y a pas de communication descendante vers l’objet connecté), le dispositif QoS, avec ses différents niveaux de fiabilité (QoS 0, QoS1 et QoS 2), s’assure d’un aller-retour entre l’objet connecté et le broker MQTT et limite ainsi la potentielle perte de messages. En prenant un peu de recul, MQTT peut ainsi être vu comme un encapsulateur de message, une façon de communiquer pour être sûr d’avoir bien reçu le message à transporter.

La figure 24 retrace un exemple d’utilisation du protocole MQTT. Un capteur de température branché sur une carte Arduino transfère ses données encapsulées en MQTT via un module WiFi (installé sur la carte Arduino). Un brocker MQTT MoscaJS décode le message MQTT et le transfère à un micro-ordinateur Raspberry Pi. Notez que le broker MQTT est sur une adresse IP locale du réseau et il faut que les objets connectés soient au courant de l’adresse IP du broker pour pouvoir lui envoyer des messages. Le Rasberry Pi est chargé de soit stocker les données reçues sur une base de données locales ou de les envoyer sur une base de données tierce (qui sera par exemple requêtable par API). Les données pourraient être soit rendues disponibles toujours en MQTT (beaucoup d’applications sont capables d’ouvrir du MQTT) ou alors converties (dans le format .json par exemple) en amont. Pour un capteur connecté localisé dans une parcelle agricole, on aurait pu imaginer un envoi des données via GSM jusqu’à une antenne. L’antenne aurait pu, via une application dédiée, encapsuler les données dans le protocole MQTT avant de les envoyer dans le reste du réseau.

Figure 24. Exemple d’utilisation du protocole MQTT. Le fruit rouge est le symbole du Rasperry Pi. Crédits : Simon Moinard.

Pour être complètement honnête, j’aurais dû vous dire que le broker MQTT agit certes en temps que serveur de messagerie mais qu’il faut bien lui dire à un moment ou un autre quoi faire. Node-Red est un outil de programmation qui sert justement à gérer les protocoles de communication entre serveurs et interfaces et qui est lui aussi à l’aise avec les requêtes MQTT. L’application Node-Red servira par exemple à expliciter le fait que le broker MQTT récupère un message MQTT d’un capteur de température, extraie la donnée de température du message, et envoie ensuite cette donnée un peu où bon nous semble. Vous pouvez par exemple l’envoyer sur la plateforme « ThingSpeak » dédiée à l’IoT, pour stocker puis afficher la donnée provenant de vos capteurs. Cette plateforme est capable de recevoir des messages directement en MQTT.

Les protocoles Matter et Thread

Vous aurez également peut-être vu passer les noms de nouveaux protocoles qui commencent à gagner du terrain depuis la fin de l’année 2022 – notamment « Matter », « Thread » et « Amazon Sidewalk » poussés par les géants du domaine (Amazon, Google et consoeurs). Ce sont plutôt des protocoles tournés vers la domotique donc je ne saurais vraiment dire si on peut en attendre quelque chose dans les applications agricoles. Malgré tout, les portées annoncées de certains de ces protocoles (plusieurs centaines de mètres) pourraient en intéresser plus d’un.

Matter et Thread semblent être des protocoles dérivés du Zigbee mais adaptés à de la communication IP. Avec les protocoles Matter et Thread, tous les éléments du réseau (capteur connecté par exemple) connaissent les adresses IP des autres éléments du réseau ce qui veut dire globalement que chaque nœud du réseau peut envoyer ses données à un autre nœud du réseau sans passer par une unité centrale. Dans le cas du broker MQTT dont on a parlé, vous aurez compris que c’est ce brocker qui fait le lien entre tous les capteurs du réseau. Si ce brocker lâche, il n’y aura plus de message instantanément parce que chaque capteur communique à l’adresse du broker MQTT. Ce n’est néanmoins pas si problématique parce que je vous rappelle que le broker MQTT a un système de vérification pour s’assurer que le message a été envoyé ou non (donc entre guillemets, si le brocker a un problème, il sait qu’il n’a pas envoyé le message).

Si l’on en revient à Matter ou Thread, l’utilisation de ces protocoles a pour conséquence que tous tes objets connectés du réseau sont compatibles avec ces protocoles et que nous n’avons pas à nous soucier des échanges de données entre les nœuds du réseau. Il suffira par exemple de rajouter un objet compatible Matter (par exemple un capteur de température) dans notre réseau. Si la tête thermostatique de mon radiateur est elle aussi compatible Matter, mon broker MQTT ou ma box domotique n’a plus vraiment d’intérêt parce que la tête thermostatique de mon radiateur peut directement communiquer avec mon capteur de température et l’utiliser comme référence pour adapter la température de mon logement. Qu’est-ce qui se passe en comparaison sans ce protocole Matter, c’est-à-dire si j’utilise par exemple mon broker MQTT ? Dans ce cas-là, il me faudrait une box domotique pour que la donnée du capteur de température soit sauvegardée et que la tête thermostatique de mon radiateur aille interroger la base de données au niveau de ma box en utilisant le brocker comme intermédiaire puis que le brocker aille ensuite commander la tête thermostatique. Si on devait résumer la chose, on pourrait simplement dire que les protocoles Thread et Matter permettent de faire communiquer les objets connectés directement les uns avec les autres plutôt que de passer par un serveur global. C’est par exemple aussi le cas du WiFi qui permet à la fois la connexion sans fil entre un appareil informatique et Internet mais aussi entre plusieurs objets informatiques entre eux (par exemple, entre un ordinateur et une imprimante). Revenons à nos moutons. L’objectif, pour les fournisseurs de ces protocoles Matter et Thread, est que ces protocoles soient déjà installés par défaut sur les capteurs connectés.

Tentons de prendre un peu de recul

Gouvernance et Open Source dans le monde de l’IoT

Prototyper soi-même ses objets connectés est sans aucun doute moins cher et permet de s’affranchir de prestataires et de potentiels verrouillages techniques. C’est effectivement l’occasion de pouvoir choisir ses protocoles de communication ou encore de réparer ses capteurs. Mais les protocoles de communication sont-ils réellement accessibles pour tout le monde ? Les abonnements proposés pour certains protocoles IoT (Sigfox, NB-IoT) sont encore assez orientés vers le monde de l’entreprise avec des packs d’abonnements pour un grand nombre de capteurs à connecter. Outre quelques grandes exploitations agricoles, on peut difficilement imaginer un agriculteur seul ouvrir un compte auprès de ces fournisseurs là pour accéder à leur protocole de communication. Notre regard se tourne également vers les nouveaux protocoles « Matter », « Thread » et « Amazon Sidewalk » poussés par les géants du domaine (certains encore une fois plutôt orientés vers un usage domotique) qui interrogent notre volonté à toujours faire l’usage des supports déjà bien standardisés et encapsulés par les GAFAM. Les protocoles IoT – notamment 4G LTEM et NB-IoT ont également largement volé des parts de marché aux protocoles Sigfox et LoRaWAN (même s’il est difficile de savoir si c’est vraiment le cas pour le secteur de l’agriculture spécifiquement). Toutefois, avec Sigfox placé en redressement judiciaire au début de l’année 2022, on pourrait se demander si l’avenir du LoRa, de son côté, ne pourrait pas se trouver du côté de l’open-source. Nous avons dans ce dossier discuté par exemple de la structure The Things Network cherchant à mettre en réseau l’ensemble des antennes LoRa déployées par des particuliers chez eux.

Le faible coût des capteurs, l’accès très facile à des cartes électroniques et micro-ordinateurs en tout genre, et l’existence d’une communauté absolument gigantesque autour du déploiement de projets IoT en open source donne la possibilité à quiconque, avec un tant soi peu de motivation et de temps (surtout de temps !), de se lancer dans l’aventure (et quelques risques aussi malgré tout, surtout lorsque vous vous exposez à 220V). Vous aurez alors le plaisir de devoir gérer vous-mêmes les problèmes de microcontrôleurs qui crashent, les réseaux de communication trop faibles ou disponibles, les erreurs d’authentification des objets connectés sur le réseau ou encore des enjeux d’alimentation de batterie. Les fablab fleurissent et les dispositifs mobiles comme le Mobilab d’AgroTIC Services permettent de sensibiliser et/ou former des acteurs agricoles directement sur le terrain.

Je ne m’épancherai pas ici sur notre dépendance à certaines entreprises et pays pour le matériel électronique présent dans les objets connectés – dépendance notamment mis au grand jour avec la crise des semi-conducteurs en 2021 (entreprise TSMC à Taiwan). Les semi-conducteurs sont des composants essentiels des micro-contrôleurs (il y en a des centaines de milliers à l’intérieur) qui sont au cœur du fonctionnement de l’internet des objets. Ce sujet laisse quand même à réfléchir quant à notre capacité à réagir aux crises à venir.

Evoquons également rapidement la capacité des objets connectés à pouvoir connecter en seconde monte certains appareils existants plus ou moins vieux. On pense par exemple à des électrovannes connectées en seconde monte en branchement sur solénoïde existant avec un émetteur par capteur installé. Cette seconde monte, outre le gain de temps offert par le suivi et pilotage de l’irrigation à distance, permet de conserver le matériel existant et ainsi éviter d’en acheter un nouveau (potentiellement plus cher). Faites néanmoins la différence entre un prototypage rapide – un peu bidouillé – et une industrialisation plus solide d’un objet connecté. Au vu du faible coût du prototypage, on pourrait être rapidement tenté de critiquer les prix de certains fournisseurs d’objets connectés (bon ok parfois à raison). C’est d’ailleurs un argument qui m’avait été plusieurs fois soulevé dans un précédent dossier sur l’apiculture et le numérique. On ne peut malgré tout pas avoir leur beurre et l’argent du beurre… Les prix parfois jugés élevés du commerce peuvent être justifiés par un nombre assez important de considérations : le coût de la recherche et développement associé, de la production des objets connectés (avec un potentiel recours à des sous-traitants), de l’envoi et de l’emballage des capteurs, du service après-vente du fournisseur, des certifications d’origine (par exemple la certification CE en Europe), les dépôts de brevets et la propriété intellectuelle. Le prototypage permet de se tester, et sera parfois largement suffisant pour les plus geeks d’entre nous, mais l’industrialisation permet le passage à l’échelle.

L’accès à la connectivité en contexte agricole

Le secteur agricole n’est pas un secteur comme les autres. C’est un secteur du vivant évoluant dans un milieu ouvert et non standardisé. Les parcellaires sont potentiellement étendus et/ou morcelés – et les parcelles ne sont pas nécessairement proches du siège de l’exploitation agricole.

La communication des données d’objets connectés peut être limitée par des problèmes d’atténuation du signal. Une pluie trop intense peut réellement constituer un mur d’eau infranchissable. Des obstacles tels que des bosquets et forêts, une végétation trop dense au sein de la parcelle (par exemple pour des capteurs sous le feuillage), des bâtiments ou encore des collines peuvent gêner le routage de l’information. La distance entre capteurs connectés (ou entre les nœuds d’un réseau maintenant que vous êtes familiers avec ces termes) est bien sûr limitante. On pourra alors user de répéteurs pour mieux disséminer l’information ou agrandir le nombre de nœuds dans le réseau.

La communication peut également être affectée par les problèmes de multi-trajet du signal, comprenez-ici les rebonds en tout genre subis par le signal dès qu’il rencontre un obstacle. Ces enjeux-là sont potentiellement plus flagrants en contexte urbain. On pourra noter aussi des problèmes d’interférences dus par exemples aux cables et fils en tout genre que l’on peut trouver sur les parcelles agricoles – notamment pour des cultures pérennes comme la vigne ou les vergers.

En contexte agricole, certains réseaux de capteurs seront d’ailleurs connectés de manière discontinue à leur station de base, et ce pendant des périodes de temps plus ou moins longue. Cette connexion discontinue pourra être assurée en se servant parfois du matériel agricole – tracteur ou drone – lorsqu’il sera en déplacement sur les parcelles agricoles (si ce n’est pas toi qui vient à la connectivité, c’est la connectivité qui vient à toi !). Ces contraintes de connectivité discontinue imposeront parfois de trouver des architectures alternatives aux réseaux de capteurs sans fils utilisés plus classiquement.

Rajoutons à cela que les opérateurs télécom ne couvrent pas l’ensemble du territoire français. Le concept de « zones blanches » s’applique en réalité à des territoires où vivent des habitants et non pas à n’importe quelle zone du territoire français. Une couverture réseau à 99% témoigne en réalité d’une couverture de 99% des habitants vivant sur le territoire et non pas de 99% de la surface du territoire français. Il existe des zones blanches vis-à-vis d’un opérateur certes (vous vous trouvez par exemple dans une zone blanche par rapport à Orange ou Bouygues) mais dans les campagnes, vous ne pouvez pas parler de zone blanche seulement parce que l’opérateur auquel vous êtes abonné n’a pas couvert votre zone. Une vraie zone blanche, c’est quand aucun des opérateurs n’est présent. Si vous pouvez passer un appel d’urgence, ça veut dire qu’il y a au moins un des opérateurs du marché qui couvre (au moins un peu) votre zone.

Malgré le fait que de nombreux protocoles de communication aient été mis en place pour favoriser le développement des objets connectés – et ce même en agriculture – il apparait légitime de questionner les inégalités d’accès au réseau et l’inclusion numérique au sein du secteur agricole (Figure 25). L’ARCEP (l’autorité de régulation des communications électroniques, des postes et de la distribution de la presse) a d’ailleurs récemment lancé un site web pour que chacun puisse évaluer le niveau de connectivité dans sa commune. L’ARCEP met également à disposition une couverture réseau théorique sur son site web « Mon Réseau Mobile ». Ces informations sont accessibles par API. La figure 25 vous présente les taux de couverture déclarés par les agriculteurs (au niveau du siège de l’exploitation et sur leurs parcelles) suite aux enquêtes Agrinaute de 2013 à 2020 que nous avons concaténé sur une interface dynamique.

Figure 25. Couverture du siège d’exploitation et sur les parcelles en réseau cellulaire 2G, 3G et 4G. Source : Aspexit – Agrégation des données des enquêtes Agrinaute 2013 à 2020 : https://aspexit-corentin.shinyapps.io/taux_adoption/

L’engouement pour la 5G pose question au regard des exploitations agricoles qui ne disposeraient pas d’un accès même 2G ou 3G au niveau de leur siège ou sur les parcelles environnantes. Le déploiement de la 5G en agriculture ne favorisera-t-il pas encore plus le déploiement d’objets connectés ou du numérique de manière générale sur certaines exploitations déjà largement avantagées ? De même, l’internet des objets étant largement accéléré par le smartphone que nous avons presque tous dans nos poches, que se passe-t-il pour les agriculteurs qui n’auraient pas de smartphone ?

Consommation énergétique des objets connectés

En agriculture, la recherche d’autonomie dans les objets connectés (pour éviter les déplacements à répétition, notamment dans les zones difficilement accessibles) appelle à raisonner leur consommation énergétique, et c’est déjà plutôt une bonne chose. L’optimisation énergétique peut se faire à plusieurs niveaux, à la fois au niveau du hardware (les composants du capteur connecté), mais aussi au niveau du software pour s’assurer d’un fonctionnement réfléchi du capteur. Nous avons vu en effet en début de dossier que la transmission de données était particulièrement gourmande en énergie et que mettre l’objet connecté en veille une bonne partie du temps paraissait tomber du bon sens (quand l’application agricole désirée le permet). On pourra donc réfléchir de manière générale à l’optimisation de la communication radio, à la gestion des cycles d’activités du capteur (écoute, veille…), à la réduction des données transmises, au routage efficace de l’information entre le capteur et son point relai ou le reste du réseau de capteurs, et au réapprovisionnement de la batterie (type de batterie utilisée, alimentation par panneau solaire…).

Concernant la réduction de la quantité de données transmises, je profite de cette section pour introduire les concepts d’edge computing et de cloud computing que l’on voit fleurir de plus en plus régulièrement dans les appels à projets. L’idée de l’edge computing, contrairement au cloud computing, est de pouvoir réaliser le traitement de la donnée au plus proche de son acquisition (directement sur le terrain) de manière à pouvoir simplifier la donnée avant de la transmettre sur le réseau internet. Pour les capteurs qui collectent de la donnée à très haute résolution, on pense par exemple aux caméras embarquées sur tracteur, le fait d’envoyer l’image brute directement sur les réseaux est tout simplement inconcevable au vu de la connectivité disponible sur les parcelles agricoles. On pourrait certes stocker les données en local sur un petit ordinateur proche du capteur et venir la récupérer en présentiel à l’aide d’une clef USB. Mais on pourrait imaginer aussi traiter la donnée sur cet ordinateur de manière à grandement en réduire le poids. Par exemple, lorsque l’on prend une image à haute résolution d’une adventice avec un capteur embarqué sur un tracteur, on cherche en réalité simplement à savoir si oui ou non il y a une adventice (et potentiellement discriminer le type d’adventices mais restons sur un cas simple). On préfèrera alors simplement transmettre sur le réseau une donnée de localisation avec un tag présence/absence plutôt que d’envoyer l’image complète. Vous aurez compris j’espère que le cloud computing consiste quant à lui à réaliser le traitement de cette donnée sur un serveur une fois que la donnée a été transmise au réseau.

Embarquer le traitement au plus proche de l’outil (Edge Computing) demande alors d’embarquer de l’intelligence et de la puissance de traitement in-situ, ce qui n’est pas complètement évident non plus. Si la diminution de la consommation énergétique de l’objet connecté est complètement contrebalancée par l’énergie requise pour alimenter un traitement embarqué (et c’est notamment le cas si les données acquises sont lourdes et le traitement de la donnée relativement complexe), on pourra se demander si le jeu en vaut vraiment la chandelle.

Si l’on imagine déployer massivement des objets connectés, même si chacun est assez peu gourmand en énergie, on en revient toujours à la question lancinante de l’effet rebond – c’est à dire au fait que le gain énergétique obtenu (efficacité énergétique) via l’amélioration des performances énergétiques de chaque objet connecté considéré unitairement pourrait être balayée par l’augmentation du nombre de capteurs installés et la quantité de données transmises. Il suffit d’ailleurs de regarder rapidement l’augmentation du débit de données permis par la 5G par rapport à la 4G qui, même avec une efficacité de transmission de données par kilo-octet réduite, pourra encore une fois difficilement passer outre cet effet rebond (et je ne parle pas ici de la nécessaire construction d’antennes pour accueillir ce nouveau protocole de communication). Ce découplage entre débit offert et quantité de données transmises n’a pour l’instant jamais eu lieu et il y a assez peu de raisons que ça devienne le cas. On pourra certes toujours arguer que la quantité de données transmises en agriculture est très certainement largement inférieure à la quantité de données de loisirs de la population dans son ensemble (vidéos de petits chats en 4K, fils vidéos sur Tiktok et Instagram…). Il serait quand même dommage de balayer d’un revers de main ce sujet en agriculture sous un seul prétexte d’ordre de grandeur.

En contexte urbain, certains petits malins inclineront plutôt leurs arguments vers les gains d’efficacités apportés sur l’ensemble du système. Je parle ici bien sûr des smarts grids et smart cities – sorte de réseaux maillés d’objets connectés qui, grâce à des mesures en temps réel de l’ensemble de nos activités, permettraient d’économiser une énergie significative par une optimisation et un micro-pilotage à outrance. Si la proposition est alléchante, le sujet de la sobriété énergétique dont nous devrions faire part est souvent reléguée en arrière-plan. Et force est de constater que jusqu’à présent, les promesses de ces réseaux denses ne vont finalement pas beaucoup plus loin que quelques économies de déplacement pour les tournées d’éboueurs et d’économie d’énergie en bâtiment. Philippe Bihouix et co-auteurs, dans leur dernier ouvrage « La ville stationnaire » aux éditeurs Acte Sud, critiquent d’ailleurs le fait qu’à mesure que les villes se densifient et se complexifient, les consommations d’énergie et de matière ont en réalité tendance à augmenter malgré les effets de mutualisation et de mise en commun que l’on pourrait en attendre. Il y aurait selon eux une taille de ville optimale au-delà de laquelle l’augmentation de la densité se ferait au détriment de l’impact écologique soit-disant évité.

Sécurité et protection des données IoT

Les données ne sont pas forcément chiffrées sur l’ensemble des protocoles de communication dont nous avons parlé, ce qui pose des questions en termes de sécurisation et protection des données transmises. Sur des protocoles radio classiques ou sur un protocole comme SigFox par exemple, le chiffrement n’existe pas. Au niveau du protocole IP, lorsque l’on arrive sur internet, les données sont chiffrés et ce chiffrement est généralement plus solide, notamment avec la norme IPV6 en place. Les protocoles de communication utilisant le protocole IP, c’est-à-dire ceux sur les couches « Application » du modèle OSI que nous avons évoqué, comme Matter ou MQTT bénéficieront de cette protection apportée par le réseau internet. Au niveaux des réseaux locaux par contre et particulièrement au niveau des routeurs (on est plutôt ici sur les couches 2 et 3 du modèle OSI), certaines sécurités et clefs de chiffrement présentent encore quelques failles pour l’ensemble des objets connectés communiquant via WiFi, notamment pour les box relativement anciennes qui n’ont pas été mises à jour. La communication WiFi n’étant pas prépondérante pour les réseaux IoT agricoles, si ce n’est peut-être au niveau du siège de l’exploitation, ces enjeux ne sont peut-être pas prioritaires.

Si l’on ne s’intéresse vraiment qu’à un IoT relativement basique ou à quelques capteurs connectés au champ, on pourra quand même se demander ce qu’un hacker pourrait faire de quelques données de température parcellaires… Les attaques auront malgré tout plutôt lieu sur les serveurs (du fabricant, de l’opérateur, d’une coopérative…) que les capteurs en eux-mêmes, là où des données stockées et agrégées sont potentiellement plus intéressantes.

Interopérabilité entre les protocoles de communication

Dans un précédent dossier de blog, j’abordais les enjeux d’intéropérabilité technique et métiers qui complexifiaient les échanges de données en agriculture. Cette question est bien évidemment toujours présente dans le cas des protocoles de communication même si un peu moins prégnante.

Nous avons par exemple évoqué dans ce dossier le cas du broker MQTT – particulière dédié à l’internet des objets – capable de gérer l’interfaçage entre des protocoles de communication différents. Les box domotiques quant à elles s’occupent de l’intéropérabilité à un niveau assez bas dans le sens où elles intègrent l’ensemble des réseaux de communication de manière à agréger les données sans passer par le serveur du fabricant. L’ensemble des données peut converger vers une base de données exploitée par le serveur domotique et une seule application hébergée sur la box domotique permet de récupérer les données. Toujours dans le cas de la domotique, j’avais également rapidement évoqué le cas des protocoles « Matter » et « Thread » dont l’objectif pour leurs fournisseurs est de les installer par défaut sur les objets connectés vendus. Si ces standards sont acceptés, on pourrait imaginer que dans quelques années, un objet qui ne serait pas compatible Matter n’ait plus trop de valeurs…

Ce besoin d’intéropérabilité est également masqué par le déploiement des API – les fabricants de capteurs ou les opérateurs de télécommunication rendant accessibles les données sur le serveur par « simple » requête (même si la construction des API reste quand même un investissement technique et informatique pour ceux qui le mettent en place).

En guise de conclusion

Ce dossier a permis d’aborder, avec une vision assez panoramique, les enjeux de la transmission de données sans fil en agriculture à l’aide d’objets connectés simples ou en réseau. Le choix des capteurs et des protocoles de communication est dirigé par autant de paramètres que le nombre de capteurs à installer, le débit ou la quantité de données à transmettre, le réseau disponible autour du lieu d’acquisition de données, la consommation énergétique des capteurs, le coût de l’ensemble de l’installation du réseau de capteurs (matériel, abonnements…) ou encore la compatibilité des capteurs avec les protocoles de communication choisis. En rentrant dans l’écosystème des objets connectés, on ne peut qu’être plongé dans une diversité absolument fascinante de protocoles de communication et de standards qui, de prime abord, peuvent nous laisser complètement en désarroi. Néanmoins, en prenant le temps de creuser un peu le sujet voire simplement juste de dérouler les acronymes un peu abscons que l’on nous présente, on commence à se prendre au jeu et l’on se prête à croire que l’on a quand même un peu compris ce qui s’y passait.

Les objets connectés restent un bon moyen de démystifier un certain nombre de concepts informatiques et numériques pour les agriculteurs. C’est déjà un moyen de se rendre compte qu’un capteur n’est pas connecté par défaut, et que derrière la dématérialisation généralement mise en avant se cache en réalité une pléthore d’architectures informatiques (capteurs, routeurs, antennes, serveurs…) nécessaires à la transmission de « simples » données provenant de capteurs installés au champ. C’est également l’occasion de rentrer dans un monde où l’open-source joue un rôle largement prépondérant. De nombreux agriculteurs sont en attente de sessions de sensibilisation et de formation pour, dans un premier temps, découvrir l’existence de capteurs à connecter et, dans un second temps, pour prototyper des systèmes connectés. Dans la mesure où les contextes et objectifs de production sont très variables entre deux exploitations voisines, on peut comprendre que les agriculteurs aient envie de déployer leurs solutions sur mesure. Ce prototypage n’est néanmoins pas accessible pour tout le monde et pour les moins geeks d’entre nous, il faudra accepter que l’industrialisation de capteurs connectés (s’ils sont vraiment utiles) rendent les objets connectés sensiblement plus chers.

Pour aller plus loin

Je vous invite à aller regarder quelques vidéos de la très bonne chaine de vulgarisation informatique « Cookie Connecté » sur Youtube.

https://www.linuxembedded.fr/2016/03/protocoles-de-communication-frameworks-et-systemes-dexploitation-pour-les-objets-connectes

Partagez cet article !

Objets connectés (IoT) et protocoles de communication en agriculture

Préambule important

Une première entrée en matière avec des exemples de parcours de la donnée

Petit traité d’objet connecté

Un capteur est-il forcément un objet connecté ?

Capteurs et réseaux de capteurs sans fils

Dynamique des objets connectés

Les exemples de capteurs en agriculture

Les protocoles de communication

Quels paramètres considérer pour choisir un protocole de communication ?

Le cas un peu particulier du satellite IoT

Idées reçues et abus de langage

Le modèle OSI et les réseaux

Le serveur de messagerie MQTT

Les protocoles Matter et Thread

Tentons de prendre un peu de recul

Gouvernance et Open Source dans le monde de l’IoT

L’accès à la connectivité en contexte agricole

Consommation énergétique des objets connectés

Sécurité et protection des données IoT

Interopérabilité entre les protocoles de communication

En guise de conclusion

Pour aller plus loin

1 commentaire sur « Objets connectés (IoT) et protocoles de communication en agriculture »

Laisser un commentaire Annuler la réponse