On entend souvent dire qu’une solution numérique est interopérable puisqu’elle propose l’export de données dans un format commun comme le CSV ou via une API. Même si cela permet effectivement d’échanger ou de récupérer des données cela ne répond pas au véritable défi de l’interopérabilité et peut paradoxalement entraver son déploiement. Dans cet article nous faisons le point sur les niveaux de mise en œuvre de l’interopérabilité et montrons que l’interopérabilité native est clairement l’objectif à atteindre.
4 niveaux de mise en œuvre
Le tableau suivant présente les 4 niveaux de mise en œuvre de l’interopérabilité du plus basique (niveau 1) à l’idéal (niveau 4).
| Niveau de mise en œuvre | Description |
| 1. Interopérabilité par conversion | Les systèmes ne sont pas conçus pour interopérer, mais on ajoute des adaptateurs, traducteurs, ou convertisseurs. |
| 2. Interopérabilité via un médiateur | Un tiers (hub, plateforme d’échange) reçoit les données, les transforme et les redistribue selon des formats standards. Dépendance à un tier (le médiateur). |
| 3. Interopérabilité native partielle | Tous les systèmes s’alignent sur un format commun, un protocole partagé, mais pas forcément une sémantique complète. |
| 4. Interopérabilité native | Les systèmes sont conçus dès le départ pour parler le même langage, avec la même sémantique et les mêmes standards. Aucune traduction nécessaire. |
L’export sérialisé ou l’API : la fausse bonne idée
Si l’export de données ou la mise à disposition de celles-ci via une API part généralement d’une bonne intention cela ne répond pas véritablement au problème si cela ne s’inscrit pas dans une logique de construction commune. En effet, les données ainsi récupérées nécessitent généralement d’être converties ou traduites dans un autre modèle de données et/ou dans un autre format de données pour être utilisées par une autre solution. Pour récupérer les données de manière automatique il faut également parfois recourir à une traduction de protocole.
Cela s’explique par l’absence d’un standard commun entre les solutions. Chaque éditeur d’application peut utiliser un protocole particulier, son propre modèle de données et dans certains cas son propre format (qui peut même être propriétaire). En résulte des incompatibilités entre les systèmes puisque ceux-ci ne vont pas être en mesure de traiter les données échangées (sans conversion).
Certains d’acteurs tentent de résoudre ce problème en traduisant pour vous les données d’un système vers un autre. De la sorte, ils se placent en intermédiaire ce qui pose de sérieux problèmes en terme de souveraineté et de coût. L’intermédiaire peut à tout moment changer sa politique ou ses tarifs, décider de ne plus traduire certains formats, etc. De plus ces solutions de traductions sont très coûteuses à maintenir puisqu’il faut maintenir chaque système traduit. Ces intermédiaires font donc peser un grand risque à l’écosystème qu’ils disent servir et favorisent l’émergence d’encore plus de disparités.
L’interopérabilité native : un objectif positif pour l’ensemble de l’écosystème
L’interopérabilité native consiste à se mettre d’accord sur un protocole technique d’échange de données et un modèle de données commun. Les éditeurs logiciels se reconnaissent et se regroupent. Ils ne se considèrent plus séparés de l’écosystème et ont conscience qu’il est nécessaire de travailler ensemble pour répondre véritablement au défi de l’interopérabilité : l’utilisateur doit pouvoir faire transiter ses données sans effort et sans intermédiaire.
Ce niveau d’interopérabilité est clairement l’objectif à atteindre d’un point de vue utilisateur mais aussi pour les éditeurs de logiciels eux-mêmes. Cette mise en œuvre de l’interopérabilité fait gagner du temps et de l’argent à tout le monde, utilisateurs et concepteurs. Les concepteurs peuvent mutualiser les coûts de recherche et développement et s’affranchir de traduction interne ou externe.
L’union Européenne promeut clairement l’interopérabilité native comme objectif à atteindre dans son European Interoperability Framework (EIF). Le Data Food Consortium répond à cet appel en travaillant sur l’implémentation d’une interopérabilité native dans les applications numériques destinées aux acteurs des circuits courts. Tout un chacun est invité à rejoindre l’initiative pour coconstruire l’interopérabilité de demain.