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) au plus performant (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’interopérabilité par conversion ou via un médiateur sont des impasses délétères
Ces deux niveaux d’interopérabilité sont les plus basiques et se retrouvent dans les systèmes qui permettent l’export de données dans un ou plusieurs format et/ou qui fournissent une API. C’est par exemple le cas des systèmes dits « passerelle » ou « proxy » (intermédiaire).
L’interopérabilité par conversion et l’interopérabilité via un médiateur reposent toutes les deux sur une traduction. Pour la première la traduction est effectuée directement au niveau du système émettant les données (système source). Pour la seconde la traduction est prise en charge par l’intermédiaire qui traduit les données du système source vers le système consommateur. La traduction concerne les données en elles-mêmes (modèle de données et/ou format de données) mais aussi parfois le protocole utilisé pour l’échange. Chaque système 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). Au fil du temps les systèmes évoluent et maintenir la traduction s’avère très coûteux.
Ces deux niveaux d’interopérabilité posent de sérieux problèmes en terme de souveraineté et de coût. Le coût de la mise en place et de la maintenance de la traduction est fonction du nombre de systèmes à interconnecter. Plus il y a de systèmes à traduire et plus cher il faudra payer. Ce prix se répercute in fine sur le consommateur de la donnée et rien ne garantie qu’il reste stable dans le temps. De plus les fournisseurs de données ou les intermédiaires peuvent à tout moment changer leur politique et décider de stopper par exemple la traduction vers certains formats.
En conséquence, recourir à l’interopérabilité par conversion ou à l’interopérabilité via un médiateur menace l’écosystème et favorise l’émergence d’encore plus de disparités. Si un acteur de la chaîne d’interopérabilité accepte de prendre les risques que nous venons de voir c’est l’ensemble des acteurs interconnectés qui est impacté. En effet si cet acteur n’est plus capable d’interopérer c’est toute la chaîne qui perd de la valeur. Par ailleurs, ces deux niveaux d’interopérabilité n’encouragent pas l’émergence d’un standard commun mais pérennisent au contraire le status quo. On peut donc les qualifier de « rustines » et sont à éviter. Il faut leur préférer l’interopérabilité native.
L’interopérabilité native : la solution pour un écosystème sain et durable
L’interopérabilité native consiste à se mettre d’accord sur un protocole technique d’échange de données et sur une représentation commune des données : c’est la coconstruction d’un standard commun (qui repose généralement sur des standards existants). 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.