Toutes nos sciences et domaines de travaux regorgent de normes, de standards, et de formats d’échange. L’agriculture n’y fait pas exception (vous trouverez en annexe une liste d’organisations et d’institutions impliqués de près ou de loin dans la standardisation en agriculture). Nous avons besoin d’échanger, de collaborer, de partager de la donnée et de l’information, et il est nous est donc nécessaire de parler un langage commun. Que ce soient pour des échanges machines-outils, machines-logiciel, logiciel-logiciel, machines-machines, ou tout simplement pour discuter de façon informelle, nous allons voir que les standards agricoles et les formats d’échange mis en place ont permis de changer la donne dans le domaine du numérique agricole. Certains diront que cette dynamique et l’inertie des acteurs agricoles sont très lentes ; d’autres, que de belles collaborations et de gros efforts ont pu être faits.
Le sujet est extrêmement vaste. Nous ne pourrons donc pas tout traiter ici. Pour que ce soit clair, nous ne parlerons pas de dossiers juridiques (RGPD – Registre général de protection des données – et consœurs), de propriété, de consentement, ou encore de sécurité de la donnée. Nous nous concentrerons bien plus sur des aspects de standardisation – donc plutôt un sujet technique – même s’il faut bien sûr avouer que tous ces sujets sont interconnectés dans une plus ou moins grande mesure.
Comme d’habitude, pour les lecteurs du blog, cet article est issu d’entretiens téléphoniques avec des acteurs du secteur (dont vous trouverez les noms à la fin de l’article) que je remercie pour le temps qu’ils ont pu m’accorder. Plusieurs lectures d’articles scientifiques, forums, et blogs m’auront permis de compléter les retours d’entretiens.
Bienvenue dans le monde des sigles, de la sémantique, et de l’interopérabilité agricole.
Soutenez Agriculture et numérique – Blog Aspexit sur Tipeee
Brève introduction
Par où commencer… Peut-être déjà par rappeler que les mots ont leur importance. Sur tous les acronymes et sigles qui seront présentés dans cet article, tous ne se rapportent pas à la même chose. On y trouvera notamment des protocoles de communication, des standards/normes/formats d’échange, des instituts/organismes de standardisation ou encore des référentiels et dictionnaires de données. Comme tous les membres de cette grande famille ne sont pas réellement indépendants les uns des autres, on peut rapidement avoir la tête qui tourne et ne pas y retrouver ses petits.
Pour rentrer plus simplement dans le sujet, je vous propose de commencer par distinguer deux gros secteurs différents : celui de l’équipement mobile, et celui de l’équipement fixe :
Dans l’équipement mobile,
- On pourra retrouver notamment les tracteurs, machines, et outils attelés/tractés (semoir, pulvérisateur, charrue…) – et on pourra résumer grossièrement les échanges au sein de ces équipements à l’ISOBUS (nous irons quand même un peu plus loin que ça).
Dans l’équipement fixe, une séparation pourrait à nouveau être faite entre d’une part
- les équipements fixes au sens strict (robots de traite, les distributeurs automatiques de concentrés [DAC] ou encore les machines à poste fixe) qui n’ont pas d’équivalent ISOBUS, mais où ce n’est finalement pas si important que ça parce que ces machines ne sont pas vouées à être attelées à quoi que ce soit. Nous ne nous y intéresserons pas particulièrement dans cet article,
- les outils logiciels (gestion parcellaire, comptabilité…) et cloud associés sur lesquels peuvent transiter beaucoup de flux de données différents. Là, par contre, il y a pas mal de choses à en dire,
Les échanges de données dans les agro-équipements mobiles
Quelques éléments de contexte
L’ISO, c’est l’organisation internationale de normalisation. Les normes ISO, il y globalement assez peu de chances que vous n’en ayiez jamais vu passer. On en parle souvent sur des problématiques de qualité, de management, de sécurité, ou encore de santé, et ce dans plein de domaines différents (et il faut avouer que ce n’est pas particulièrement excitant, c’est souvent synonyme de procédures et d’administratif). Dans l’agro-équipemement mobile, il y a depuis quelques années une norme ISO assez bien respectée – l’ISO 11783 – autrement connue sous le nom plus classique de norme ISOBUS. Pourquoi cette norme a-t-elle été mise en place ? Au départ, tout simplement pour pouvoir standardiser, harmoniser, et simplifier les échanges de données entre une machine et un outil tracté/attelé à cette machine. L’objectif étant bien qu’une machine et un outil puissent communiquer entre eux, de manière à pouvoir remonter ce qu’est en train de faire l’outil (l’opération culturale en cours) sur le terminal d’un tracteur et de donner des instructions à l’outil pour réaliser son opération culturale.
Mais pour qu’une machine et un outil communiquent ensemble, il n’y a à priori pas besoin d’une norme ou d’un standard tel qu’ISOBUS, non ? Là où ça devient plus compliqué, c’est quand plusieurs outils peuvent être attelés à plusieurs machines différentes… Ce besoin de standardisation est né au départ dans les pays européens parce que, chez les agriculteurs d’ici-bas, les machines et outils ne sont pas forcément de la même marque. Certains agriculteurs pourront avoir sur leur exploitation jusqu’à cinq voire peut-être même plus de marques différentes. Cette problématique était moins présente dans d’autres pays comme les Etats Unis, ou certains constructeurs présents comme John Deere ou CNH pouvaient avoir une gamme longue d’agro-équipements avec un réseau de distribution associé (des constructeurs dits « full-liner »). Comment alors faire en sorte de ne pas avoir une multitude de standards d’échange ? Hé bien en créant un standard commun ! Facile, non ? Pas tant que ça… Pour choisir un standard commun, il a d’abord fallu que tous les constructeurs se mettent autour de la table et s’accordent. Pas évident quand les enjeux vont plus loin qu’une simple problématique technique (qui était d’ailleurs loin d’être simple). Certains acteurs n’étaient par exemple pas forcément intéressés par de l’interopérabilité avec d’autres constructeurs pour des raisons économiques ou de présence sur le marché. D’autres n’avaient pas forcément envie de voir la norme ISO arriver. Pour la petite anecdote, à l’époque, l’Allemagne, qui était secrétaire du groupe ISO, avait une norme concurrente à l’ISOBUS à l’institut allemand de normalisation (DIN – Deutsches Institut für Normung). En 2008, après une première dynamique un peu lente, plusieurs constructeurs ont décidé de créer l’AEF – l’Agricultural Industry Electronics Foundation – pour faire en sorte que ce standard commun puisse naitre dans les meilleures conditions. L’AEF a alors pris en charge les « Plug Fest », ces fameux speed dating organisés tous les deux ans entre constructeurs pour tester leur compatibilité machines, et les entreprises ont commencé à s’impliquer au-delà de l’ISO et à communiquer ensemble. Imaginé au départ autour de 6-7 chapitres, il n’a pas fallu moins de 14 chapitres pour définir ce standard d’interopérabilité. L’ISOBUS était né.
L’ISOBUS
Le standard ISOBUS est composé de plusieurs fonctionnalités que l’on peut retrouver sur la partie droite de la jolie vignette bleue de l’AEF (Figure 1). Pour l’instant, seules 6 fonctionnalités sont clairement définies (UT, TECU….), et plusieurs autres sont à venir. Avant de revenir rapidement sur ces fonctionnalités, qui doivent être activées sur les consoles et outils, il faut bien comprendre qu’un appareil est compatible ISOBUS pour des fonctionnalités et des versions associées, c’est-à-dire qu’un matériel peut être compatible sur la fonctionnalité UT, mais pas la fonctionnalité TC-GEO, et que la compatibilité n’est pas forcément assurée si la version d’un appareil ou d’un matériel est amenée à changer (en achetant par exemple un nouveau matériel). Sur cet aspect de versioning, une attention particulière doit être portée à la rétrocompatibilité, c’est-à-dire le fait qu’un nouveau matériel ne sera pas forcément compatible avec un matériel plus ancien. Rajoutons à cela que pour qu’une machine et un outil soient compatibles, il est nécessaire que les deux soient certifiés ISOBUS, encore une fois pour la fonctionnalité souhaitée et en s’assurant de la bonne compatibilité de version. La certification ISOBUS est payante, et elle est généralement obtenue après des participations réussies aux Plug-Fest, et au respect des protocoles de l’AEF. Notez néanmoins que les constructeurs ne certifient pas forcément leurs mises à jour. Pour vérifier les compatibilités entre matériels, l’AEF a mis à disposition une base de données ISOBUS (www.aef-isobus-database.org), aussi disponible en application mobile. En d’autres termes, si vous devez retenir une chose, c’est qu’il ne s’agit pas d’une compatibilité générale ISOBUS.
Figure 1. La vignette ISOBUS
Les fonctionnalités opérationnelles ISOBUS :
- UT : aussi appelée fonctionnalité de terminal universel parce qu’elle permet d’actionner un outil depuis n’importe quel terminal de machines
- TECU : pour permettre au tracteur de partager ses données (ex : régime de prise de force ou sa vitesse), avec l’outil attelé. Il faut bien comprendre que l’échange de données s’effectue depuis le tracteur vers l’outil.
- AUX-N : pour commander l’outil tracté ou attelé à la machine avec une commande auxiliaire, par exemple un joystick.
- TC-BAS : pour la gestion de tâches classiques (opérations culturales) non géo-référencées
- TC-GEO : pour la gestion de tâches (opérations culturales) géo-référencées, notamment pour faire de la modulation intra-parcellaire, contrairement à la fonctionnalité TC-BAS. Cette fonctionnalité nécessite donc, sans grande surprise, une carte de modulation.
- TS-SC : pour la gestion de tâches qui peuvent nécessiter des changements automatiques ou des contrôles de sections (dans le cadre d’une pulvérisation, d’un semis ou autre) et ainsi diminuer les recouvrements entre des passages successifs de machines. Cette fonctionnalité nécessite un contour parcellaire pour la gestion des bordures
L’ISOBUS n’est pas quelque chose de gravé dans le marbre, le standard est amené à évoluer. Trois fonctionnalités sont d’ailleurs en cours d’amélioration, et viendront compléter les six fonctionnalités précédentes :
- TIM (Tractor Implement Management) : Contrairement à la fonctionnalité TECU, la fonctionnalité TIM permet un échange de données bidirectionnel, c’est-à-dire à la fois depuis la machine vers l’outil, mais aussi depuis l’outil vers la machine, de façon à ce que l’outil lui aussi puisse commander certaines fonctions du tracteur comme sa vitesse ou son régime moteur. En termes d’exemples, une presse à balles rondes, une fois la balle prête, peut stopper le tracteur et faire en sorte d’éjecter la balle ; de manière à simplifier encore plus le travail de l’opérateur du tracteur.
- LOG pour l’enregistrement de valeurs indépendamment de la tâche effectuée par la machine
- ISB pour désactiver un des outils commandés par ISOBUS lorsque plusieurs outils sont disponibles, et ainsi travailler avec l’outil souhaité
Gardez en tête que l’AEF ne se résume pas seulement à l’ISOBUS. De nombreux groupes de travail sont mis en place au sein de cette association (https://www.aef-online.org/fr/laef/equipes-de-projet.html#/Aproposde) avec notamment des actions autour des logiciels de gestion parcellaire (nous y reviendrons), des normes de radiocommunications pour les échanges entre machines, des questions de sécurité, ou encore de la gestion de connectivité entre caméras de tracteurs et d’outils.
NB : Je n’ai pas pu trouver de chiffres clairs sur la quantité d’agro-équipement français compatible ISOBUS. Une des personnes interviewées estimera qu’autour de 15% du parc serait compatible (ce chiffre devrait être considéré avec des pincettes).
Le bus CAN, mais pas que..
L’ISOBUS, ça reste une norme d’échange, ça n’explique pas comment les données transitent entre les machines et les outils. Pour ça, il faut introduire la notion de « bus ». Un bus informatique, c’est une fibre optique ou un câble cuivre (un tuyau en quelque sorte), au sein duquel vont transiter des données machines du tracteur et de l’outil attelé (régime moteur, consommation de carburant, relevage de l’outil…) mais aussi des messages de gestion. Ces données machines sont gérées par des calculateurs, aussi appelés unités de commande électronique, qui sont en fait des boitiers électroniques qui font le lien entre le bus informatique et tous les composants électroniques (capteurs, actionneurs, modules de régulation….) reliés au boitier. En anglais, ces unités de commande électronique s’appellent les « Electronic Control Unit » ou « ECU ». On retrouve donc ici le lien avec la fonctionnalité TECU de l’isobus (qu’il faudrait plutôt lire Tracteur ECU). Le gros intérêt d’avoir mis en place ces bus informatiques, c’est que ça permet d’avoir un seul tuyau pour faire le lien entre un tracteur et les composants électroniques des outils attelés. Imaginez-vous l’immense quantité de câblage qu’il faudrait installer s’il fallait considérer un fil par type d’information à transmettre entre le tracteur et l’outil. Avec ce système de bus informatique, on évite donc la connexion ou liaison point-à-point (un fil par information) et on lui préfère une approche plus globale dite de multiplexage (un seul tuyau). Avec une approche de multiplexage, le terminal du tracteur peut donc être considéré comme virtuel (on entend souvent le terme de terminal virtuel) dans ce sens où c’est comme si le terminal était spécifique à chaque outil attelé à la machine et qu’il était en mesure de piloter l’outil.
Figure 2. Isobus et Bus CAN. Source : Ouest CUMA
Pour les bus informatiques, il y a pas mal d’écoles différentes. Certains constructeurs ont un bus pour le moteur, un bus pour le calculateur du pulvérisateur, etc… en gros un bus par type d’actions. D’autres constructeurs vont tout faire transiter sur le même bus. Dans ce cas-là, on parlera plutôt de bus CAN ou de réseau CAN (Controller Area Network), car ce sont les bus les plus utilisés dans le domaine de l’agro-équipement. Ces différentes écoles s’expliquent assez simplement parce que certains constructeurs ne vont pas produire tout leur matériel eux-mêmes. Par exemple, un constructeur peut très bien acheter un moteur à un constructeur de moteurs, et assembler ce moteur sur une machine qui a déjà son propre bus informatique. Et si ce constructeur rajoute ensuite un pulvérisateur qui a son propre bus, ça en fait donc encore un nouveau ! En fonction des constructeurs, ces bus-là pourront donc être indépendants et/ou communiquer entre eux. Dans le cas où quelqu’un (un fournisseur de services par exemple) voudrait connecter un boitier au tracteur pour récupérer des données machines (boitiers FieldView ou Samsys par exemple), il faudrait donc soit qu’il se branche simplement sur la prise diagnostic ou prise ISO du tracteur (il faudrait alors un boitier suffisamment puissant pour décoder toutes les trames Isobus), ou alors qu’il puisse se brancher directement sur le bus CAN ou sur plusieurs bus différents si les bus de la machine sont indépendants.
Au sein de ces bus informatiques, notamment le bus CAN, les données transitent suivant certains protocoles. Le protocole J1939 est certainement le plus standardisé, et permet de récupérer un certain nombre de données machines. Encore faut-il que les constructeurs fassent passer les données sur leur bus avec ce protocole…. Certains bus CAN sont en effet propriétaires (malgré que certains constructeurs soient certifiés ISOBUS), tout comme certains protocoles, ce qui ne facilite pas nécessairement l’échange de données et tout ce qu’on appelle la telematics de façon générale.
Si l’on s’intéresse maintenant aux espèces sonnantes et trébuchantes, on se rend compte que l’utilisateur va quand même devoir mettre un peu la main à la poche s’il désire avoir un système ISOBUS complet. Je ne dis pas ici qu’il est nécessaire d’avoir l’ensemble des fonctionnalités décrites plus haut, ou que le jeu n’en vaut pas la chandelle (on commence à connaitre les bénéfices des technologies de géo-positionnement en agriculture), mais que c’est néanmoins un élément à prendre en compte. Il faut considérer en effet:
- Un outil attelé/tracté certifié ISOBUS
- Une console ISOBUS compatible avec l’outil attelé
- Potentiellement un joystick pour faciliter le pilotage de l’outil
- L’installation d’une antenne GNSS raccordée à la console et un abonnement à un service de correction du géo-positionnement (je vous invite à relire l’article de blog sur le sujet), notamment par exemple pour utiliser finement la fonctionnalités isobus TC-GEO et réaliser de la modulation intra-parcellaire.
- L’achat des fonctions TC-SC et TC-GEO pour faire de la coupure de tronçons et de la modulation
Il existe néanmoins des solutions moins couteuses. Il est par exemple possible de faire du retrofitting, c’est-à-dire d’équiper un vieil outil ou tracteur en ISOBUS ou en d’autres termes, de monter de l’ISOBUS sur de l’existant. Cette approche permet de sortir des équipements haute gamme ISOBUS. Certains constructeurs le font déjà (c’est par exemple le cas de la solution Iso FIT de Reichhardt). Pour développer une solution technique de rétrofitting, il n’y au final pas besoin de grand-chose ! A minima une ECU tracteur et une prise 12 Volts. Autre solution pour qu’un tracteur identifie un outil spécifiquement, pourquoi ne pas simplement équiper l’outil avec un tag Bluetooth ? Alors, certes, l’objectif ne serait pas ici de remonter de la donnée machine précise, mais on aurait déjà le moyen de faire de l’identification à très bas coût (il serait également possible d’ajouter un tag tractoriste pour reparamétrer la tracteur et l’outil en fonction du conducteur). Sur le sujet du géo-positionnement, même si ce n’est pas complètement le sujet ici, et pour réduire encore plus les coûts, il est également possible d’aller jusqu’à bricoler soi-même son autoguidage agricole avec la solution canadienne AgOpen GPS, et d’utiliser le réseau RTK open source Centipede, mis en place par l’INRAE. A noter que les développeurs du réseau Centipede ont fait en sorte d’être le plus compatible possible avec le matériel constructeur.
Les échanges de données dans les agro-équipements fixes
Jusqu’à présent, on s’est concentrés sur les échanges de données entre machines et outils. Il y avait déjà pas mal de choses à en dire – on a notamment pu parler d’Isobus et de bus informatique – mais quand on prend un peu de recul, on se rend compte qu’il n’y a finalement pas tant d’acteurs autour de la table (toute proportion gardée). Il y a quelques institutions (on a parlé de l’AEF) et les constructeurs d’agro-équipement (outils, tracteurs et autres) certes, mais on peut globalement résumer les échanges de données à ça. On pourrait rajouter les entreprises qui proposent des boitiers à connecter aux différentes prises tracteurs/outils pour remonter de la donnée ou plus simplement des boitiers accrochés aux machines pour remonter de la donnée d’utilisation de machines, mais ça n’augmente pas tellement la quantité d’acteurs en jeu (et puis ces dernières entreprises n’ont pas forcément leur mot à dire sur ces standards). Quand on commence à s’intéresser aux échanges de données sur de l’agro-équipement fixe, notamment avec les logiciels de gestion parcellaire et les infrastructures cloud, là ça commence à faire mal… Vous allez le voir, mais le domaine de l’interopérabilité dans l’agro-équipement fixe est extrêmement large, avec beaucoup d’organisations, d’initiatives, de standards et de formats. Dans le domaine de l’élevage, on va toucher l’éleveur, le vétérinaire, le conseil, la génétique, la grande distribution et j’en passe. En production végétale, on se rapprochera de près ou de loin de l’agriculteur, du conseil, des organismes de collecte et stockage, de la grande distribution, des filières, du consommateur ; bref, ça commence à en faire du monde. Et plus il y a de monde, plus y a de besoins et d’intérêts différents, et plus il est difficile de s’accorder sur des standards et des formats d’échanges (Figure 3).
Figure 3. Une multitude d’acteurs impliquée dans l’échange de données en agriculture. Source : AgGateway.
Nous nous concentrerons principalement ici sur les échanges qui ont lieu entre machines, logiciels de gestion parcellaires et autres solutions télématiques (boitiers, portail web/cloud) : échanges machines-machines, machines-logiciels, logiciels-portail web, logiciels-logiciels…).
Dans le cas de l’agro-équipement mobile, nous avions vu que le besoin d’harmonisation était principalement dû au fait que beaucoup d’exploitations agricoles disposaient de matériel de différents constructeurs. Dans le cas de l’agro-équipement fixe, au final, on a toujours les mêmes problèmes mais il y en a d’autres ! Pourquoi vouloir communiquer directement avec une machine par un logiciel de gestion parcellaire ou un cloud constructeur ? Tout simplement pour éviter de devoir travailler avec des clés USB que l’on peut perdre, qu’il faut brancher sur son tracteur et sur son poste de travail, où il faut dézipper des dossiers (ce qui n’est pas facile pour tout le monde) pour accéder aux fichiers que l’on souhaite. A côté de ça, il suffit de regarder la diversité des constructeurs, des logiciels de gestion parcellaire et de cloud pour se convaincre qu’utiliser des standards agricoles pourrait faciliter les échanges de données et les partenariats.
Pour y voir plus clair, commençons déjà par présenter les trois grandes organisations du domaine. Les penchants de l’AEF sur l’agro-équipement fixe s’appellent AgGateway, AgroEDI Europe et AEF (hé oui, encore elle). Ces trois organisations, plutôt orientées au départ vers l’Amérique du Nord pour la première et l’Europe pour la seconde, sont publiques et sont chacune composées d’un certain nombre d’entreprises adhérentes. AgGateway, AgroEDI Europe, et AEF sont organisées en différents groupes de travaux, tous s’intéressant de près ou de loin à la définition :
- de standards de modélisation ou de modèle de données : par exemple, une opération culturale doit avoir une date, une surface, un libellé…
- de dictionnaires ou référentiels de données, c’est-à-dire le contenu des données : par exemple le code culture ou le nom standard du blé tendre d’hiver est… ;
- ou de standards d’échange : on en a déjà pas mal parlé avec l’agro-équipement mobile mais ici, c’est pour l’agro-équipement fixe.
AgGateway
AgGateway compte près de 200 structures adhérentes. Pour ce qui nous intéresse dans cet article de blog, les projets d’AgGateway sont organisés autour de trois grandes thématiques d’agriculture de précision (Figure 4) :
- la gestion des opérations culturales comme le semis, la fertilisation ou encore la pulvérisation (les projets SPADE1, SPADE2 et SPADE 3)
- les applications de la télématique/télémétrie très en lien avec les opérations culturales pour faire en sorte que les plateformes agricoles échangent et communiquent plus facilement (les projets WAVE et CART sont imbriqués dans le projet SPADE 3), et
- la gestion de l’eau (projets PAIL 1 et PAIL 2)
On peut voir également que les projets SPADE restent également en lien avec la norme Isobus de l’AEF (ISO-11783). Pour chaque thématique, les groupes de travaux sont chargés de préparer des modèles de données, des référentiels, ou encore des moyens faciles d’accéder à ces référentiels (via des API par exemple ; nous reviendrons plus tard sur ce concept).
Il est intéressant de voir que de nombreux organismes de standardisation (publics et privés) sont maintenant adhérents d’AgGateway et participent à ces groupes de travaux. Par exemple, de 2001 à 2011, l’AgXML a élaboré des normes applicables aux processus de production de céréales et d’oléagineux. En 2012, ses sociétés membres ont accepté de mener des activités au sein d’AgGateway dans le cadre du projet CART. L’American Society of Agricultural and Biological Engineers (ASABE), qui publie aussi pas mal d’articles scientifiques en agriculture de précision, participe à l’élaboration de normes et de standards au sein des projets PAIL1 et PAIL2 autour de la gestion de l’eau. AgGateway développe donc certains de ces standards grâce à certains organismes qui l’ont rejoint, mais utilise aussi certains standards existants hors de la communauté AgGateway (par exemple ceux de GS1 ou d’autres).
Figure 4. Les groupes de travaux sur l’intéropérabilité agricole chez AgGateway. Source : AgGateway.
C’est au sein des groupes de travaux SPADE qu’est apparue l’initiative « ADAPT » (Ag Data Application Programming Toolkit), après une première preuve de concept réussie appelée au départ « SPADE Conversion Toolbox ». ADAPT est une solution open-source mise en place pour répondre aux problèmes d’interopérabilité entre des machines et unités de commande électronique (ECU) mais aussi et surtout entre les échanges machines et logiciel de gestion parcellaire (FMIS), et les échanges entre différents FMIS. La solution ADAPT contient à la fois un modèle de données pour les opérations culturales à réaliser sur les parcelles, un ensemble de plugins propriétaires fournis par les constructeurs pour convertir des données propriétaires d’un format à un autre, un gestionnaire de plugins pour gérer ces plugins propriétaires, un plugin ISO open-source pour travailler avec des données ISOXML, et un ensemble d’API RESTful open-source pour permettre de rajouter des informations contextuelles aux données (ce sont des ContextItems comme le pays, la région, ou des informations spécifiques sur les parcelles, les personnes). Pour compléter sur cette notion de ContextItems, il faut comprendre que le format ISOXML, qui sera présenté un peu plus loin, gère des définitions de données universelles comme un rendement par unité de surface ou une densité de semis par unité de surface. L’utilisation de ContextItems permet d’aller plus loin en renseignant une information contextuelle, ce qui permettra non plus de lire un rendement par unité de surface mais des tonnes par hectare ou des bushels per acre par exemple.
Il faut bien comprendre qu’ADAPT n’est pas un logiciel indépendant. C’est un ensemble de librairies .NET qui sont intégrées à d’autres logiciels (de gestion parcellaire par exemple). Dans ADAPT, les données ne sont pas stockées ni transportées. Il faut vraiment comprendre qu’ADAPT permet de convertir les données d’un format à un autre.
AgroEDI
AgroEDI Europe (AEE) est la communauté EDI (Echange de Données Informatisées) du secteur agricole. Elle regroupe actuellement plus de 280 adhérents des différents secteurs agricoles. Au départ, les échanges de données informatisées en agriculture se résumaient majoritairement au secteur commercial et aux liens entre fournisseurs et distributeurs, en utilisant la norme de référence EDIFACT, produite par l’organisme des nations unies UN/CEFACT. AgroEDI Europe a beaucoup travaillé sur la standardisation de données en agriculture, et notamment sur la transmission de données parcellaires en mettant en place le format DAPLOS (Data PLOt Sheet) qui contient les informations relatives à la parcelle ainsi que tous les événements qui lui sont associés (semis, fertilisation, traitements phytosanitaires, irrigation, récolte). Ce format d’échange standard pour la fiche parcellaire a été mis en place sur la base normalisée du langage EDIFACT. Chaque intervention est reconnue avec un ensemble de chiffres et de lettres qui se suivent (Figure 5).
Figure 5. Extrait d’un fichier d’échanges au format Daplos. Source : Perspectives agricoles, 2008 (Les échanges de données, vers un langage universel).
A la fin des années 2000, AgroEDI Europe avait l’ambition de mettre en place une plateforme pour connecter les coopératives agricoles et le HCCA (Haut Conseil de la Coopération Agricole) en faisant le lien entre des données techniques de type DAPLOS et les documents comptables (Bilans, comptes de résultats, annexes et PV d’AG). Ce projet de plateforme, appelé RES-AGRI, se voyait donc faire de l’échange de données multi-EDI (échange de données informatisées) au travers d’un hub entre différents acteurs du secteur et en utilisant plusieurs formats standardisés (ebXML, EDIFACT, EFI, EDI…). En plus de ces échanges entre les coopératives et le haut conseil de la coopération agricole, la plateforme RES-AGRI était censée gérer un certain nombre d’autres flux, notamment entre l’agriculteur et plusieurs entités autour de lui : l’agence unique de paiement (AUP) avec Telepac, sa coopérative ou son négoce, et les chambres d’agriculture. Ces échanges avaient été standardisés sous les formats XML AUP, eDAPLOS, et DAPLOS (Figure 6). Malgré le fait que cette plateforme RES-AGRI ne soit plus vraiment d’actualité, certains standards sont toujours utilisés. C’est par exemple le cas du message eDAPLOS, utilisé dans le cadre du projet AgroSyst mené par l’INRAE pour répondre aux enjeux du plan ECOPHYTO 2018.
AgroEDI Europe a également contribué à la production et à l’harmonisation de référentiels agricoles, et c’est peut-être maintenant ce pour quoi cette organisation est la plus connue. On peut par exemple y retrouver des dictionnaires de données mis en place dans le cadre de projets de standardisation nationaux GIEA et GIEA2 (Gestion des informations de l’exploitation agricole) pilotés à l’époque par les chambres d’agriculture (APCA), des référentiels de cultures, de stades de cultures, de nuisibles ou encore de matériel agricole. Ces référentiels sont toujours bien d’actualité, avec par exemple le cas des référentiels sur les nuisibles (messages informatisés AgroObs) adoptés par la DGAL dans leur système d’épidémio-surveillance Epiphyt.
Il est également important de garder en tête qu’AgroEDI a rejoint la communauté AgGateway.
Figure 6. Plateforme RES-Agri et formats standardisés associés.
AEF
Nous avons déjà parlé de l’Agricultural Industry Electronics Foundation (AEF) dans le cadre des équipement mobiles, notamment au sujet de l’ISOBUS. Cette organisation regroupe plus de 200 membres. Nous en reparlons ici pour les équipement fixes parce qu’un des groupes de travaux de l’AEF a notamment mis en place le format d’échanges ISOXML pour faire le lien entre le controleur de tâches du tracteur ou de l’outil et le logiciel de gestion parcellaire (en anglais Farm Management Information System – FMIS). Il faut bien comprendre qu’ISOXML fait aussi partie de la norme ISO 11783, tout comme ISOBUS. Ce fichier est transmis dans un dossier TASKDATA, vous y avez peut-être déjà eu affaire (Figure 7). Le format ISOXML n’est pas utilisé dans la communication tracteur-outil ; nous avons vu plus haut que cette communication était plutôt basée sur le protocole J1939 du bus CAN. L’ISOXML n’est pas non plus utilisé pour enregistrer le rapport de tâches du tracteur/outil. C’est généralement fait dans un format propriétaire du constructeur et gardé en mémoire, puis traduit en ISOXML pour l’exportation.
Figure 7. ISOXML : Les balises XML d’un fichier TASK Data
Mais les initiatives ne s’arrêtent pas là…
Vous en aviez eu assez ? Laissez-moi vous en rajouter quelques couches. Une initiative française, Numagri, est en train de voir le jour. Porté notamment par la FNSEA, le groupe Avril, la coopération agricole, et les chambres d’agriculture, ce projet en cours de développement vise à déployer des standards (notamment ceux de GS1, une organisation mondiale de standardisation non spécifique à l’agriculture spécialisée dans les codes-barres et la méthodologie de standardisation, mais pourquoi pas aussi en fonction du besoin ceux d’AgroEDI Europe, de l’AFNOR, du CEN ou encore de l’ISO) et des référentiels d’informations issues des exploitations agricoles françaises. Ce sont bien des standards existants qui seront utilisés. L’initiative ne vise pas à en créer de nouveaux. Le consortium AgDataHub sera le bras actif de Numagri sur les volets de consentement (avec Orange), d’échanges (avec API-AGRO et Dawex) et de stockage des données (avec 3DS Outscale) agricoles. AgDatahub ne fait donc pas simplement du partage de données (« data sharing ») mais bien de l’échange de données (« data exchange ») en fournissant, au sein d’une plateforme d’échanges en mode SaaS (Software as a Service), un environnement de transaction sécurisé juridiquement, contractuellement et commercialement. Sur cette plateforme, l’émetteur peut exposer ses données et les diffuser à un écosystème très large d’acteurs, que ce soit en open data, avec des frais payants ou dans le cadre d’un partenariat privé.
Les constructeurs d’agro-équipement ne sont pas en reste non plus. John Deere, Claas et CNH se sont regroupés autour de l’initiative DataConnect pour connecter leurs portails web ensemble. L’éditeur de logiciels 365FarmNet est aussi de la partie. Pourront alors discuter ensemble les cloud MyPLMConnect et AFS Connect (CNH), Claas Telematics (CLAAS), John Deere Operations Center (John Deere), et 365FarmNet. Cette initiative cloud to cloud permet donc à tout utilisateur disposant de plusieurs machines de marques constructeurs différentes d’accéder à ses données machines (géolocalisation, consommation, performance du parc machines…) depuis la plateforme de son choix. Ce n’est donc pas une nouvelle plateforme mais bien le fait de pouvoir, depuis les plateformes existantes, avoir accès aux données de flottes machines concurrentes. Pour l’instant, DataConnect permettra seulement à un constructeur d’afficher des données d’un autre constructeur ; ces dernières ne seront pas partagées. Ce sera donc au départ simplement de la consultation, et pas du téléchargement. A l’avenir par contre, ces informations seront échangeables, et récupérables, notamment au travers de l’interface de 365FarmNet. Au sein de DataConnect, les constructeurs essaieront certainement de définir leur propre standard d’échange cloud to cloud.
De son côté, l’entreprise Bosch, en partenariat avec de gros acteurs du secteur agricole de divers horizons – équipementiers, fournisseurs de services et de capteurs (Topcon, Amazone, Lemken , Syngenta…) a déployé son écosystème ouvert NEVONEX. L’objectif est de permettre à ces acteurs agricoles d’envoyer des données, cartes de modulation ou encore des résultats d’OAD directement sur les machines des agriculteurs, et indépendamment de la marque de machine utilisée. Bosch se positionne ici vraiment comme un acteur indépendant et transparent du monde agricole, visant à regrouper, au sein d’un même écosystème ouvert et indépendant, des acteurs ayant des intérêts à connecter leurs outils et services, et ce sur l’ensemble de la chaine agricole. Comprenez bien que NEVONEX ne collecte pas et ne stocke pas les données, mais fait en sorte qu’elles soient échangées de manière sécurisée et consentie. Il n’y a ici pas besoin d’acheter de nouvelle machine ou d’outil pour échanger et transmettre ses données, mais seulement d’installer un boitier de contrôle NEVONEX sur ses machines pour les rendre compatibles avec le système Nevonex et les ouvrir au cloud (comme on l’a vu avec l’ISOBUS, il est donc également possible ici de rétrofitter des machines agricoles pour qu’elles deviennent compatibles avec le système NEVONEX). Ce boitier de contrôle permet d’agir directement sur les fonctionnalités de la machine et/ou de l’outil attelé, ce qui distingue le système NEVONEX de plusieurs autres initiatives orientées sur des échanges majoritairement cloud. Notez également qu’un des intérêts du système NEVONEX est de pouvoir utiliser des outils et capteurs déjà pré-installés sur les machines agricoles (on peut penser à des capteurs météo par exemple) de manière à prendre en compte les données collectées par ces capteurs pour améliorer les itinéraires et applications au champ.
Le consortium DKE-Data a mis en place la solution AgriRouteur pour connecter les logiciels de gestion parcellaire et les machines agricoles. Il faut bien comprendre que AgriRouteur est une sorte de Hub d’échange de données (c’est un peu comme la Poste pour le courrier). DKE-Data n’a pas défini de standards ; il en utilise, certes, (Shape, ISOXML..) mais ce n’est pas lui qui les a mis en place.
En France, la plateforme MyEasyFarm certifiée ISOBUS centralise les informations parcellaires des logiciels de gestion agricole et les données, ressources et cartographies issues de fournisseurs de services. Des partenariats avec DKE-Data (Agrirouteur) et entreprises de télématique (par exemple le boitier télématique BHTronik) lui permettent ensuite de faire le lien avec les machines agricoles sur le terrain. MyEasyFarm a également rejoint l’écosystème NEVONEX.
L’entreprise Proagrica, au travers de sa division F4F spécialisée dans les standards et la connectivité agricoles se positionne entre les logiciels de gestion parcellaire pour les faire communiquer entre eux. F4F utilise également le système ADAPT d’AgGateway pour remonter de la donnée des agro-équipements.
Au Pays Bas, un regroupement de coopératives a créé la plateforme de données indépendantes à but non lucratif JoinData. Cette plateforme cherche à faire en sorte que les agriculteurs retrouvent le contrôle de leur donnée et puissent choisir avec qui leurs données sont partagées (centre de recherche, fournisseurs de services…). Les acteurs qui veulent récupérer de la donnée d’agriculteurs doivent se connecter eux aussi à la plateforme JoinData, ce qui permet aux agriculteurs d’avoir accès également à plusieurs services agronomiques (OAD et autres). L’initiative des Pays-Bas est donc dans la même veine que celle proposée par AgDataHub.
L’Open Geospatial Consortium (OGC) a lancé lui aussi un projet pilote (Agripilot) autour de l’agriculture de précision (https://www.ogc.org/projects/initiatives/agripilot2018) pour avancer sur les questions d’interopérabilité en agriculture. On retrouve même un article de 2009 dans la revue Precision Agriculture, où des chercheurs avaient proposé d’utiliser les standards géospatiaux de l’OGC (notamment les formats WFS et WMS) pour des problématiques en agriculture, même si ce n’était pas ce pourquoi ils avaient été définis (Nash et al., 2009). Le gros intérêt pour eux étant que ces standards étaient adaptés à des données géospatiales, et que les données d’agriculture de précision avaient une dimension spatiale forte.
En 2019, la Brazilian Association of Machinery and Equipment Industry (Abimaq) a lancé sa plateforme BDCA (Farmer Collaborative Database) pour centraliser les données de machines et capteurs des agriculteurs brésiliens. La plateforme BDCA fera également en sorte de mettre en place un standard d’échanges de données (en propre ou en utilisant un standard existant).
Les Néo-Zélandais ont eu aussi lancé leur initiative DataLinker pour faciliter les échanges de données en agriculture et agro-alimentaire. On y retrouve des modèles de données (un peu comme ce que pourrait faire AgGateway avec ADAPT) qui sont basés sur des standards agricoles néo-zélandais. Notez que DataLinker inclue aussi des outils pour sécuriser les échanges de données, et faire en sorte que les agriculteurs puissent consentir ou non à partager leurs données.
Citons pour finir le projet européen IoF2020 (Internet of Food and Farm 2020) qui inclue notamment le projet ATLAS (Agricultural Interoperability and Analysis System – https://www.atlas-h2020.eu/), piloté par l’Allemagne, et qui pourrait tout aussi bien inclure des standards et systèmes d’échanges déjà développés (ADAPT, référentiels AgroEDI…), ou pas…
Un petit tableau de synthèse des initiatives ci-dessous :
| Initiatives | Structures | Maturité |
| ADAPT + référentiels | AgGateway | Opérationnel |
| AgDatahub | AgDatahub | Opérationnel |
| Agripilot | Open Geospatial Consortium (OGC) | En développement |
| AgriRouteur | DKE-Data | Opérationnel |
| BDCA | Brazilian Association of Machinery and Equipment Industry | En développement |
| DAPLOS, eDAPLOS + référentiels | AgroEDI Europe | Opérationnel |
| DataConnect | John Deere, CNH, Claas, 365FarmNet | Opérationnel |
| DataLinker | Red Meat Profit Partnership (RMPP) | Opérationnel |
| ISOXML | AEF | Opérationnel |
| JoinData | JoinData | Opérationnel |
| MyEasyFarm | MyEasyFarm | Opérationnel |
| Nevonex | Bosch | Opérationnel |
| Numagri | FNSEA, Coopération agricole, Groupe Avril, APCA | En développement |
Quelques compléments d’information
Nous venons de voir qu’en termes d’interopérabilité, ce n’étaient pas les initiatives qui manquaient. On a parlé beaucoup d’échanges de données mais avez-vous réellement compris les différences, quand il y en a, entre toutes les solutions proposées ? Même si j’espère que oui, je vous propose ici un petit tableau comparatif entre ADAPT (AgGateway), ISOXML (AEF), et Agrirouteur (DKE-Data).
| ADAPT | ISOXML | Agrirouteur |
| Modèle de données et outil de conversion entre formats | Format de données | Passerelle de données |
| Ne communique pas directement avec une machine ou outil. Utilise un plugin pour convertir au bon format (ex : le plugin ISOXML, il en existe d’autres) | Communique avec la machine ou l’outil (fichier TASKDATA). Communication finale se fait avec le protocole J1939 | Ne communique pas directement avec une machine ou outil. Les fichiers sont déjà standardisés (shape, ISOXML…) |
| Centré sur le métier. Fait pour gérer des données agronomiques ou d’organisation | Centré sur l’outil et la machine. N’est pas fait pour gérer des données agronomiques ou d’organisation | Centré sur l’outil et la machine. N’est pas fait pour gérer des données agronomiques ou d’organisation |
| Prend en compte le champ d’application ISOXML (avec le plugin ISOXML) | Ne prend pas en compte le champ d’application ADAPT | Peut transporter des fichiers ISOXML |
| Non exclusif à l’ISOXML | Exclusif à l’ISOXML | Non exclusif à l’ISOXML |
| Peut-être utilisé pour des échanges avec des logiciels de gestion parcellaire (FMIS) et des portails web (cloud) | Peut-être utilisé pour des échanges avec des logiciels de gestion parcellaire (FMIS) | Peut-être utilisé pour des échanges avec des logiciels de gestion parcellaire (FMIS) et des portails web (cloud) |
| Récupère ce qui est fait dans le champ (paramétrage, liste de taches, tâches réalisées…) ET ce pourquoi ça a été fait (recommandations, observations, historique…) | Récupère ce qui est fait dans le champ (paramétrage, liste de taches, tâches réalisées…) | Ca reste une passerelle de données |
| Utilisation d’un système de données contextuelles (ContextItems) pour avoir une information en lien avec où l’on se trouve (ex : tonnes par hectare, bushel per acre…) via des API RESTful | Dictionnaire de données général (ex : rendement par unité de surface, densité de plantes par unité de surface..). Peut inclure les données contextuelles d’ADAPT (ContextItems) | Ca reste une passerelle de données |
| Open Source | Public | Privé |
Nous l’avions encore peu évoqué jusqu’ici mais les API (Application Programming Interface) sont des solutions de plus en plus utilisées en agriculture pour faciliter les échanges entre plusieurs partenaires : fournisseurs de services, éditeurs de logiciels… Derrière une API, il faut simplement y voir une interface à laquelle un utilisateur (humain, logiciel..) va se connecter pour accéder à un service particulier. C’est une sorte de porte d’entrée, une façade pour faire en sorte que deux logiciels interagissent l’un avec l’autre. Encore autrement expliqué, c’est une sorte de moulinette standardisée sur laquelle on va envoyer des données d’une certaine façon et qui va nous renvoyer quelque chose de manière standardisée. Via une API, un utilisateur peut par exemple avoir accès à une base de données ou un portail Open Data, avoir accès à un outil d’aide à la décision ou un service agronomique, ou encore accéder à des éléments graphiques. On peut donc récupérer tout type d’information via une API, que ce soit un flux de données en temps réel, une cartographie, ou encore une requête ponctuelle à un outil d’aide à la décision. Gardez en tête que dans beaucoup de cas, on utilise des API pour faire des interrogations (on veut accéder à de l’information), mais on peut les utiliser aussi pour écrire de l’information. Notez également que les API peuvent être publiques ou privées. Dans le premier cas, ces API sont ouvertes à tout le monde, et plusieurs niveaux de services peuvent être proposées, avec des restrictions potentielles d’utilisation. Dans le deuxième cas, ce sont plutôt des API réservées à des partenaires professionnels, ou même parfois réservées à une utilisation complètement en interne pour une entreprise (qui voudrait par exemple faciliter l’accès à différentes données ou services pour ses employés).
Les API sont intéressantes en ce sens qu’elles ne sont pas très compliquées à développer. Et plein de modèles économiques peuvent y être associées, en fonction par exemple d’un nombre de requêtes, d’un temps de traitement d’une requête, d’un nombre d’éléments physiques (ex : nombre de parcelles traitées), ou encore d’un abonnement mensuel.
Pour les API aussi il y a des standards. Les plus récents sont les standards SOAP et REST (on parle par exemple d’API REST). Les API REST sont actuellement les plus utilisées parce qu’elles sont plus légères et flexibles à développer. Les communications se font principalement en suivant un protocole HTTP et plusieurs formats de données sont potentiellement transférables : XML, HTML, texte brut, ou encore JSON. Le format JSON (et son penchant spatial GeoJSON) est prédominant pour plusieurs raisons : (1) il n’est pas nécessaire d’avoir une structure fixe sur un JSON ce qui permet d’y rajouter autant de métadonnées que l’on souhaite, (2) c’est le langage utilisé pour les bases de données NoSQL, (3) il est assez lisible même pour des humains, et (4) pas mal de logiciels permettent de tester et visualiser ces données. Les données tabulaires, type .csv, sont moins utilisées parce qu’il est plus dur d’en vérifier l’intégrité (possibilité de confondre avec Excel), les parseurs sont moins bons qu’en JSON, et le format .csv reste un tableau à plusieurs dimensions qui est plus difficile à gérer. Outre ces standards, il est tout à fait possible de développer une API à sa façon, notamment pour une utilisation en interne dans une entreprise, mais il est généralement mieux de suivre les standards et bonnes pratiques.
En France, l’entreprise API-AGRO s’est positionnée sur le secteur des API (comme son nom l’indique), avec la volonté de donner accès, sur une même plateforme, à un grand nombre d’API du secteur agricole. C’est donc le positionnement d’un intermédiaire ou d’un entremetteur qui est adopté ici. Gardez en tête que de nombreux acteurs agricoles déploient leurs API (le nombre d’API est en forte hausse et ça n’est pas prêt de s’arrêter) pour donner accès à leurs services, à leur outils ou encore à leurs données, et faciliter ainsi les échanges avec le reste de l’écosystème.
Tentons de prendre un peu de recul
Alors, est ce que vous êtes impressionnés par la diversité des standards du marché, ou alors complètement paniqués parce que vous vous sentez en retard ? Laissez-moi vous ramener à la réalité. Il y a la théorie, c’est ce qu’on a vu – tout est beau, tout est joli – et puis il y a la pratique. Malgré tout ce qu’on pourra en dire, l’interopérabilité en agriculture, c’est pas encore complètement la panacée. Les discours sont souvent en avance sur la réalité. Soyons clairs, aucun standard n’a véritablement émergé, et dans beaucoup de cas, chacun reste encore à développer son petit truc dans son coin. Certains échanges de données sont toujours faits par le protocole FTP (avec un bon vieux serveur FTP où on dépose des fichiers). Beaucoup de données sont transférées sous un format plat (Excel, .csv). Deux entreprises partenaires sont presque tout le temps obligées de cartographier la façon dont l’autre a modélisé, défini ou renseigné ses données, parce que les deux entreprises utilisent des standards différents (quand elles en utilisent). Certaines entreprises ont des fichiers internes standardisés à leur façon, mais sans suivre les standards du marché, ce qui rend donc les partenariats beaucoup moins souples et ce qui, in fine, verrouille les échanges de données parcellaires.
Mais pourquoi a-t-on tant l’impression que ça patine et que c’est si lent ? Est-ce que l’intéropérabilité avance quand même dans le bon sens ? Est-ce vraiment si compliqué de suivre un standard d’échange ou un référentiel de données ? Peut-on vraiment rendre tout intéropérable, et est-ce que ça a vraiment du sens ? Certaines entreprises ont-elles intérêt à ce que ça n’avance pas si vite que ça ? Qui a le plus à gagner et qui a le plus à perdre à l’interopérabilité agricole ? Ce sujet soulève tellement de questions ! Après en avoir discuté avec plusieurs acteurs du marché, force est de constater que les raisons sont multi-factorielles.
Il y a souvent une question d’argent derrière
On pourrait avoir l’impression que tout le monde a besoin d’échanger mais certains interviewés constatent qu’il n’y aurait au final pas tant de besoins réels identifiés et applicables. Il faudrait donc mettre en regard le besoin d’échanger des utilisateurs, et le coût d’implémentation de ces échanges qui reste très important. L’intéropérabilité se paie d’un point de vue informatique, et ça peut vite coûter cher. Tous les coûts d’implémentation, de développement et de liaison sont élevés (notamment les coûts de maintien parce que les normes et standards évoluent très vite) et il est difficile de les monétiser auprès de l’utilisateur final. Certaines entreprises peuvent être prêtes à en prendre une partie à leur charge de façon à être compatible avec les acteurs du marché (par exemple parce que les agris ne seront pas capables de le financer), mais il n’en reste pas moins que le coût final est élevé. Quels acteurs sont capables de payer pour ça ? Pour le prix actuel des abonnements aux logiciels de gestion parcellaire, peut-on réellement attendre une interopérabilité avec énormément d’acteurs du marché ? Si ces échanges doivent être mis en place pour peu d’utilisateurs, aucune entreprise n’aura d’intérêt à passer du temps dessus. De la même façon, mettre en place un échange avec un seul acteur ne peut pas se justifier économiquement. L’exemple de DataConnect est fort d’enseignement en ce sens. En mutualisant, les constructeurs se rendent compte que l’intéropérabilité leur coutera moins cher parce que c’est au niveau de l’utilisation et de la valorisation des données échangées qu’ils pourront faire du business. Chaque constructeur, pris isolément, n’aurait sans doute pas les moyens d’imposer un standard particulier. De manière générale, les acteurs du marché sont très demandeurs de standardisation parce que c’est d’autant plus d’économie à faire en termes de coût de développement.
Les entreprises ne font pas du bénévolat, ni de l’open data. Elles doivent dégager un chiffre d’affaires et se déploient dans un secteur concurrentiel. Pour les interviewés, les usages sont dans les vrais cas. L’interopérabilité arrivera si beaucoup d’agriculteurs veulent qu’une telle interopérabilité arrive. Si toutes les parties prenantes sont convaincues de l’intérêt économique d’un projet d’interopérabilité – que cette économie soit directe ou indirecte, qu’elle fasse augmenter des ventes, accélérer la distribution d’un outil ou encore de la fidélisation client – alors il n’y a pas de raison que ce projet ne se fasse pas. Mettons de côté le fantasme marketing qu’il peut y avoir derrière l’annonce d’intéropérabilité entre deux solutions du marché où, dans la pratique, la compatibilité fonctionne dans des conditions tellement spécifiques et/ou compliquées que ça ne concerne finalement que quelques personnes. Revient donc finalement toujours la question lancinante : Y a-t-il un intérêt économique dans l’usage de ces données agricoles ? Selon certains interviewés, la principale difficulté réside dans la valeur des outils numériques sur le marché agricole. La rentabilité des outils numériques en agriculture est très compliquée, et d’autant plus compliquée en France parce que tous les acteurs ne cherchent pas la rentabilité. Les structures publiques ou parapubliques peuvent bénéficier de subventions. Certains constructeurs peuvent financer un outil ou service numérique par la vente d’un agro-équipement. Des alternatives de valorisation de données peuvent avoir du mal à émerger quand par exemple un OAD doit être tamponné par un institut ayant lui-même un OAD concurrent.
Le modèle économique derrière tout ça n’est donc pas évident à trouver. En tant qu’acteur du marché, faut-il plutôt ouvrir ses données aux autres au maximum ou, au contraire, avoir tendance à garder la main dessus ? On peut comprendre que les entreprises qui ont amassé beaucoup d’informations puissent avoir le sentiment de perdre du capital en partageant leur donnée, et aient alors envie de capitaliser et protéger leur actif pour garder leur avantage compétitif (dans le cas de l’élevage, c’était par exemple le cas au départ des organismes de contrôle laitier, et des constructeurs de robot de traite). Ceux qui ont ces informations savent ce que leur a coûté leur acquisition de clients, et que ces informations peuvent être un élément clairement différenciant sur le marché. Certains acteurs ne voudront par exemple pas échanger leurs données pour être sûrs de pouvoir vendre leur propre outil ou service se nourrissant de ces données. Par exemple, pourquoi donner accès aux données d’un capteur de rendement sur une moissonneuse-batteuse si je vends derrière le logiciel pour pouvoir visualiser des cartes de rendement ? Les acteurs ayant une stratégie basée exclusivement sur de la rétention de données s’intéresseront certainement plus à l’utilisation de formats propriétaires qu’aux standards et formats généraux du marché. Il faut avouer également que ceux qui ont tendance à vouloir de la donnée sont souvent ceux qui en ont le moins, l’accès aux données pouvant être un frein au développement d’une activité. Certains iront également jusqu’à dire que le manque de standard est parfois une excuse pour ceux qui n’ont pas forcément les solutions qui vont bien.
La tendance générale reste néanmoins à l’ouverture des données, les acteurs du marché ayant l’idée que la valeur ajoutée se trouve dans le service associé à la donnée valorisée (outil d’aide à la décision, indicateurs agronomique…). Par exemple, il peut être intéressant de faire le lien entre une donnée météo locale et un logiciel de gestion parcellaire pour modifier ou recommander une modification d’intervention de pulvérisation prévue, et ainsi améliorer la qualité et l’efficacité de cette interventions. La valorisation de données machines et l’échange de ces données cloud à cloud permettrait d’aller plus loin sur la maintenance des machines à distance, les tests de performance des machines, et sur des notions de garanties, de contrats ou encore de location d’équipements. Autant donc se rapprocher d’outils ou de services existants qui savent comment retirer une information décisionnelle ou porteuse de sens de ces données amassées. Cette « ouverture » n’est pas non plus totale, certains acteurs préférant par exemple développer des échanges (API ou autres) en partenariat privilégié et serré. L’orientation générale vers une ouverture des données est aussi tirée par les utilisateurs, qui ont pour certains compris que les plateformes, clouds, et logiciels étaient flexibles. Les utilisateurs utilisent leur smartphone pour répondre à plusieurs besoins et attendent donc que ces plateformes puissent faire la même chose, avec un prix le plus raisonnable possible. Dans un monde où tout serait interconnecté, par exemple dans le cas où tous les OAD phytosanitaires seraient connectés à toutes les stations météo, la différentiation serait alors vraiment faite sur la qualité du service.
Des raisons techniques et des normes encore trop permissives
Première chose à réaliser, sur ces sujets techniques : il est toujours plus simple de ne partir de rien que de se trimbaler avec plusieurs années d’existant et de faire de la compatibilité ascendante, c’est-à-dire de se mettre à jour sur les derniers standards les plus utilisés. Il faut prendre conscience que l’inertie de certains acteurs est très importante et que le choix d’un standard plutôt qu’un autre pour une entreprise peut être synonyme de grande réussite comme de complète dégringolade. Choisir un standard qui ne sera pas adopté par la communauté ou les partenaires, un standard qui ne sera peut-être plus maintenu dans le futur, ou un standard qui ne répond pas à ses contraintes techniques et opérationnelles, peut très vite se révéler désastreux pour une entreprise. Les technologies ont énormément évolué, et continuent à le faire. Par exemple, quand l’ISO a commencé, Windows n’était pas encore vraiment là, et les protocoles mis en place étaient donc ceux de l’époque. Peu de personnes auraient pu imaginer à l’époque l’essor des plateformes et des cloud.
L’interopérabilité est également rendue compliquée par le fait que les normes sont assez voire trop permissives. Prenons l’exemple de l’ISOXML. A la base, ce standard a été mis en place par des constructeurs. Ce n’est que plus tard que les éditeurs de logiciels ont été intégrés aux groupes de travaux. La conception du standard n’est donc pas 100% adaptée aux problématiques des éditeurs, notamment sur la question de la traçabilité. A titre d’exemple, l’échange de tâches (opérations culturales) entre un logiciel de gestion parcellaire et une machine n’est pas si simple que ça. Sur un terminal, il est par exemple possible de réaliser une intervention sans la rattacher à une parcelle. Si aucun identifiant n’a été attribué à une parcelle, il ne sera donc pas possible de remonter tout ce qui a été fait au cours de l’opération culturale. Tous les acteurs n’ont par exemple pas forcément considéré la possibilité d’avoir des successions de cultures et des cultures dérobées au sein d’une même campagne, ou la notion de rang ou d’inter-rang pour du parcellaire viticole.
En dehors de problèmes assez classiques (la console n’est pas connectée, l’import/export en fichier shape ne se fait pas bien, la console n’a pas été mise à jour….), la standardisation ISOXML est encore implémentée de manière différente selon les acteurs. Il semblerait que chacun l’implémente à sa manière (de manière partielle ou en rajoutant des couches propriétaires). Il peut également y avoir des spécificités selon les constructeurs ou encore selon l’équipement installé (par exemple l’âge de la console). Rajoutons à cela que puisque les équipementiers ne sont pas des spécialistes de la gestion parcellaire, pas mal d’informations n’ont pas été considérées et ne sont donc pas susceptibles d’être remontées facilement, comme par exemple la météo ou encore des caractéristiques de sol. Beaucoup d’informations restent également optionnelles, comme la consommation du tracteur. Sur cet exemple précis, ce n’est pas parce qu’un échange est certifié isobus des deux côtés (parce que la machine et l’outil sont certifiés) que la consommation du tracteur sera accessible parce que certains acteurs ne veulent pas la partager. En se branchant sur une prise diagnostic du tracteur ou sur le bus CAN, il arrive que certains constructeurs ne respectent pas les formats d’échange classiques, rendant alors impossible la remontée d’informations. Rappelons également l’exemple des données de rendement cité un peu plus haut. Dans ce cas-là, les données peuvent être cachées ou offusquées parce que certains constructeurs sont dans un modèle économique où lorsqu’une machine est achetée, il faut acheter le logiciel en plus pour lire ces données de rendement (et donc on n’a pas forcément envie qu’une entreprise tiers viennent récupérer ces données là).
D’une manière générale, il est donc plus simple d’importer des données sur un matériel agricole que de les exporter puisqu’on peut contrôler plus facilement ce qu’on envoie sur une machine que ce qu’on peut y récupérer. ISOXML reste donc un format d’échanges (comme d’autres) mais les données à l’intérieur ne sont pas forcément standardisées. Difficile donc de ne pas évoquer non plus la question des référentiels ou dictionnaires de données qui viennent remplir les fichiers au format ISOXML. Encore une fois, tout le monde n’utilise pas les mêmes ontologies pour définir ses données. Par exemple, la définition des variétés est différente entre le GNIS, la PAC, l’AgroEDI, ou encore le COMIFER. Aucune ontologie n’a été actée pour les produits fertilisants. Un des problèmes vient du fait que les ontologies ne sont pas toutes ouvertes. Il faut donc parfois être adhérent d’un organisme et/ou payer pour y avoir accès, comme dans le cas d’AgGateway ou d’AgroEDI Europe pour des référentiels un peu en tout genre ou de Lexagri pour les produits phytosanitaires. Dans le cas de GS1, il est par contre possible de récupérer les résultats de travaux sans être membre (mais il faut être membre pour participer aux travaux). On peut aussi rajouter le problème de la langue : travailler à l’international (ou même avec des partenaires qui ont des clients à l’international) avec des attributs français peut assez vite se retrouver limitant. Beaucoup de données sont utiles en agronomie, mais il faut prendre chaque cas de manière séparée ; il n’existe pas de norme qui définisse tout en même temps, à la fois des engrais, des itinéraires, des phytos…
D’un point de vue très opérationnel, mettons le doigt sur le fait que la certification de l’ISOXML par l’AEF se fait de manière très théorique ; ce sont des développeurs qui travaillent sur ce sujet d’intéropérabilité. Mais sur le terrain, il peut être relativement compliqué d’identifier les conditions dans lesquelles la liaison fonctionne. Qui appeler sur le terrain lorsqu’il y a un problème ? Le concessionnaire ? La coopérative ou négoce ? L’éditeur de logiciels ?
Peut-être peut-on se rassurer avec le fait qu’en France, la réglementation de la PAC est la même pour tout le pays, alors que dans d’autres pays comme l’Allemagne, chaque région a ses propres contraintes et procédures de déclaration…
Peut-on vraiment rendre tout intéropérable ?
Peut-on vraiment tout harmoniser et standardiser ? Est-ce souhaitable ? D’un point de vue technologique, force est de constater que ça n’est pas évident. Il y aura toujours quelqu’un pour créer une nouvelle solution pas forcément adaptable à des standards du passé. Certains constructeurs se disent par exemple limités par l’ISOBUS et la capacité du bus CAN (peut-être même limité par la connexion électrique elle-même) à faire transiter la masse de données que leurs machines génèrent. Ces constructeurs feraient face à une limite plutôt de l’ordre de la communication que de la technique. On pourrait néanmoins questionner l’intérêt de collecter des masses de données machines aussi importantes (mais c’est un autre débat…). Dans un monde numérique, tout évolue vite. Peut-être faut-il plutôt se concentrer sur un tronc commun de façon à être le plus flexible et le plus résilient à toute évolution de formats ou de standards d’échange. Conserver une base de données lisible le plus longtemps possible pourrait déjà être un bon point de départ.
D’un point de vue métier, la réponse n’est pas simple non plus. L’exemple de la définition de la parcelle est peut-être le plus parlant. Même si le sujet a été bien avancé en grandes cultures, beaucoup d’acteurs en ont une définition différente parce que les besoins de ces acteurs sont différents. Il existe par exemple une définition de l’ISOXML pour la parcelle, encore une autre pour la PAC, et ce ne sont pas les mêmes définitions pour des besoins en traçabilité ou en agriculture de précision. Par exemple, certains ETA considéreront deux parcelles agricoles pour des raisons de traçabilité, mais une seule lorsqu’il s’agira d’une application de modulation intra-parcellaire. On impose en réalité aux agriculteurs une définition qui ne s’applique pas à nécessairement à leurs conditions de travail (le tracteur réalise une application d’une certaine manière). Sur cette définition de parcelle, le contexte est encore plus compliqué dans le cas de la viticulture, parce que la numérisation y est beaucoup moins importante qu’en grandes cultures (et que les besoins n’y sont pas forcément ressentis). On recense par exemple un parcellaire cadastral, un parcellaire CVI, un parcellaire PAC, ou encore un parcellaire au pied de vigne. Chaque parcelle peut contenir plusieurs cépages (parfois mélangés aléatoirement), avec différentes années de plantation. D’un point de vue géographique, il peut en résulter des couches et des sous-couches à gérer ; bref rien de bien simple là-dedans.
Tout standardiser n’a peut-être pas finalement tant de sens que ça. Standardiser des données qui répondent à un besoin et à un usage concret en aurait beaucoup plus.
Echange ou saisie de données
De façon assez paradoxale, il semblerait que l’on se concentre plus sur la façon d’échanger les données plutôt que de les récupérer. On a l’impression qu’on envoie beaucoup plus d’informations vers la machine (information descendante) et qu’on en remonte beaucoup moins depuis la machine (information montante). Nous avons vu tout le lot d’initiatives et de projets pour faciliter l’échange de données, mais encore faut-il en avoir, et surtout en avoir des qualifiées, c’est-à-dire qui apportent de l’information pertinente. Avoir tous les contours parcellaires de France et en faire une carte, c’est déjà bien, mais qu’est-ce que l’on en fait après ? Connaitre les interventions prévues sur une parcelle est intéressant pour de la traçabilité mais n’avoir aucune information associée à cette parcelle sur la date de semis, ou encore sur le rendement obtenu, peut être assez limitant pour aller plus loin. Cette remontée d’information peut être fait de plusieurs façons différentes, avec notamment certaines initiatives présentées plus haut, à l’aide d’applications mobiles sur le terrain, ou encore au travers de boitiers branchés sur les machines (dans la section sur l’Isobus, nous avions donné l’exemple de branchements sur les prises diagnostic ou ISO du tracteur, et de tags Bluetooth). Cette saisie – automatique ou non – pourrait aussi gagner à être associée à une date de mise à jour (pour savoir par exemple quand le parcellaire a été digitalisé pour la dernière fois) et à un niveau de fiabilité pour connaitre le niveau de confiance que l’on peut accorder à la donnée. Cette notion de fiabilité pourrait être intéressante pour apporter différents niveaux de service et se rapprocher de besoins plus opérationnels, sans faire de la sur-qualité.
En guise de conclusion
Comment va évoluer la standardisation des données agricoles ? Bien prétentieux celui qui pourra le prédire avec précision. Nous avons vu beaucoup d’initiatives et de propositions en cours. Ce n’est peut-être pas si mal. Aurait-on vraiment voulu voir un seul acteur majeur arriver avec son standard et l’imposer à tout le monde ? Certains interviewés me diront néanmoins qu’en France, nous serions les spécialistes pour ne pas aller regarder ce qui a été fait ailleurs et pour vouloir tout faire soi-même, quitte à réinventer la roue…. Au vu du coût des échanges de données en agriculture, le marché se rendra certainement compte que tous les acteurs ne peuvent pas mettre autant d’argent sur la table et que quelques standards émergeront et se stabiliseront dans le temps. L’ISOXML semble être assez largement utilisé ; le shapefile aussi, malgré ce qu’on aurait pu en croire. Il n’y aura sans doute pas d’évènements majeurs qui changeront complètement la donne sur ce sujet de standardisation. L’implémentation sera certainement incrémentale, par petits pas, en fonction des partenariats avec les entreprises du secteur et on peut l’espérer, des besoins des agriculteurs. Un changement brutal pourrait néanmoins advenir avec une réglementation (nationale ou européenne). Cela avait par exemple été le cas avec une directive européenne sur l’identification automatique des ovins/caprins par puce radiofréquence en utilisant la norme ISO. Il y aura peut-être également pas mal à attendre du « Data Governance Act » de la Commission Européenne sur l’échange de données voté d’ici à la fin 2022. La Commission parle même d’agriculture de précision dans les bénéfices associés à l’échange de données en agriculture (https://ec.europa.eu/digital-single-market/en/european-data-governance). Cette loi sera le penchant du RGPD pour les données non-personnelles, qui représentent une grande partie des données du monde agricole.
Pour l’instant, on pourrait plutôt dire que les agriculteurs se sont informatisés pour répondre à des contraintes (traçabilité ou autres). La relation est plutôt déséquilibrée dans le sens où la traçabilité des données parcellaires a été réfléchie par l’UE et l’Etat Français principalement (à laquelle les acteurs du secteur dont les éditeurs de logiciels doivent s’adapter), sans que les besoins des agriculteurs aient été évalués. Il y a bien évidemment des enjeux d’intérêt pour les agriculteurs (par exemple la gestion des ZNT et le label HVE qui pourraient bénéficier d’une remontée automatisée de données) mais le sujet de la traçabilité n’est-il pas traité de façon trop complexe ? De la même façon, le déploiement des applications d’agriculture de précision – et donc de ces besoins d’intéropérabilité – semble plus répondre à un besoin des entreprises du secteur qu’à une réelle demande des agriculteurs. La standardisation peut avoir de très bons côtés certes en démultipliant les données et services à disposition des agriculteurs, mais il faudra néanmoins garder en tête qu’une standardisation de bout en bout demande une grosse organisation avec beaucoup d’intervenants qui rentrent en jeu. Vers qui l’agriculteur devra se retourner quand il y aura un problème ? Vers son concessionnaire ? Le constructeur ? Le fournisseur de services ? Sa coopérative ? A force de rendre la chose trop simple, on pourrait se retrouver avec des effets contraires à ceux imaginés au départ.
Nous considérons encore trop le problème du point de vue de l’entreprise – ce que nous pouvons faire de la donnée – et pas du point de vue de l’agriculteur, ce que lui peut, veut ou a besoin de faire de sa donnée. Une chose est certaine, pour que la question de la standardisation évolue, les agriculteurs devront prendre conscience des enjeux et s’acculturer au sujet de la donnée, pour éviter de devenir captif d’une plateforme ou d’un cloud propriétaire (comme ça peut être le cas actuellement – on parle ici de portabilité de la donnée, c’est-à-dire le fait d’être attaché à un fournisseur), et comprendre ce qui est fait de leurs données. Nous ne pouvons pas accepter qu’un agriculteur ne puisse pas récupérer simplement des données qu’il aurait lui-même remplies. Nous ne pouvons pas accepter qu’un agriculteur ne sache pas ce qui est fait de ses données. Nous ne pouvons pas accepter qu’un agriculteur ne retire aucun bénéfice de la donnée qu’il partage.
Mais au final, tout ce qu’on vient de dire dans le secteur agricole ne s’applique t-il pas à tous les autres domaines qui ressentent le besoin de plus d’intéropérabilité ?
Soutenez Agriculture et numérique – Blog Aspexit sur TipeeePersonnes Interviewées
| Nom | Structure |
| Julien ANCELIN | INRAE |
| Guilhem BRUNEL | Montpellier SupAgro |
| Jean-Christophe CHASSINE | Claas |
| Gaelle CHERUY | Agro EDI Europe |
| Anthony CLENET | SMAG |
| Alexandre DIAZ | Isagri |
| Clément FRAIGNEAU | Permagro |
| Gilbert GRENIER | Agro Bordeaux |
| Eric GUEMENE | 365FarmNet |
| David JOULIN | Ekylibre |
| Thomas KIRSTE | Bosch |
| Sébastien PICARDART | API-Agro / AgDataHub |
| Julien SAINT LAURENT | John Deere |
| François THIERART | MyEasyFarm |
| Romain TRIBOUT | Samsys |
| Jim WILSON | AgGateway |
Bibliographie
AgGateway, 2016. Organization Alignment in Standards Development. Louisville
Applegate, D.B. et al. (2016). Toward geopolitical-context-enabled interoperability in precision agriculture: AgGateway’s SPADE, PAIL, WAVE, CART and ADAPT. ISPA, 13th Conference on Precision Agriculture
Bahlo, C. et al. (2019). The role of interoperable data standards in precision livestock farming inextensive livestock systems: A review. Computers and Electronics in Agriculture, 156, 459-466
Grenier, G. (2010). Bus CAN sur machines agricoles : les technologies de l’information au service de l’agriculture de précision et de la traçabilité. Ingénieries eau-agriculture-territoires, Lavoisier ; IRSTEA ; CEMAGREF, 67-76 Nash, E., Korduan, P., et Bill. R (2009). Applications of open geospatial web services in precision agriculture: a review. Precision Agriculture, 10, 546-560
Annexe
Voici une liste non exhaustive des acteurs qui font de la standardisation en agriculture (certains sont plus spécialistes que d’autres, certains ne développent pas des standards spécifiquement pour l’agriculture mais ces derniers peuvent être utilisés dans des applications agricoles). On peut y retrouver des organisations nationales/internationales, des associations d’industriels ou de professionnels, des groupes informels… Cette liste est tirée d’un séminaire de Jim Wilson d’AgGateway :
AEF : Agriculture Industry Electronics Foundation
AFNOR : Association française de normalisation
AgGateway
AgroConnect (Pays-Bas)
ANSI : American National Standards Institute
ASABE : American Society of Agricultural and Biological Engineers
CEN : Comité Européen de Normalisation (European Committee for Standardization)
CNIS : China National Institute of Standardization
DIN : German Institute for Standardization
ICAR : International Committee for Animal Recording
IEC : International Electrotechnical Commission
ISO : International Organisation for Standardisation
ITU : International Telecommunication Union
GODAN : Global Open Data for Agriculture and Nutrition
GS1
OAGI : Open Applications Group
OASIS : Organization for the Advancement of Structured Information Standards
OGC : Open Geospatial Consortium
Standards New Zealand
UN/CEFACT : United Nations Centre for Trade Facilitation and Electronic BusinessW3C : World Wide Web Consortium
4 commentaires sur « Standards et échanges de données dans le numérique agricole »