L’interopérabilité est souvent présentée comme une évidence dans les grands programmes numériques : qu’il s’agisse de santé, de services publics, d’identité ou de territoires intelligents. Dans les faits, c’est rarement là que les difficultés sont anticipées… et presque toujours là qu’elles apparaissent. 

Quand l’interopérabilité est mal adressée, la transformation numérique crée des silos supplémentaires au lieu de les supprimer. Et malgré des standards partagés et des architectures ambitieuses, elle reste aujourd’hui l’une des principales sources de fragilité des systèmes en production. 

Avec le recul acquis sur des projets nationaux et internationaux, une chose apparaît clairement : l’interopérabilité n’est pas qu’un sujet technique. Elle commence bien plus tôt, au niveau de la gouvernance, de l’organisation des acteurs et de la manière dont les échanges sont réellement testés. 

De cette expérience terrain, un constat revient systématiquement : 
👉 L’interopérabilité a besoin de la conformité comme prérequis. 
👉 La conformité n’a de valeur que si elle mène à l’interopérabilité. 

C’est cette articulation, souvent simplifiée, parfois mal comprise, qui conditionne la fiabilité des échanges numériques critiques. 

La conformité : un passage obligé 

Dans tous les écosystèmes que j’ai pu observer, les tests de conformité constituent le point de départ. Ils permettent de vérifier qu’une implémentation respecte ce qui a été spécifié : 
formats, modèles de données, règles métier, contraintes syntaxiques et sémantiques, mécanismes de sécurité, signatures ou chaînes de confiance. 

Dans de nombreux contextes, cette conformité n’est d’ailleurs pas optionnelle. Elle est imposée par des cadres réglementaires, contractuels ou institutionnels, et conditionne l’accès à un programme ou à un écosystème. 

Sans conformité, il n’y a tout simplement pas de base fiable. Les échanges deviennent instables, non reproductibles, parfois même dangereux. 
Mais l’expérience montre aussi une autre réalité, plus inconfortable : la conformité seule ne suffit pas. 

Quand la conformité ne suffit plus 

Il est parfaitement possible et fréquent que deux systèmes soient conformes à une même spécification… et pourtant incapables d’échanger correctement. 

Pourquoi ? 
Parce que les tests de conformité sont souvent réalisés en isolation, dans des environnements maîtrisés, avec des scénarios limités. Ils valident des comportements attendus, mais rarement l’ensemble des interactions possibles entre systèmes développés par des équipes différentes, avec leurs propres interprétations et contraintes. 

C’est dans ces interstices que surgissent les problèmes : 
différences d’interprétation, écarts d’implémentation, comportements inattendus qui n’apparaissent qu’une fois les systèmes mis en relation. 

C’est précisément là que l’interopérabilité devient un sujet à part entière. 

Tester l’interopérabilité, pour de vrai 

Les tests d’interopérabilité consistent à confronter des systèmes réels, portés par des acteurs différents, dans des scénarios proches des usages terrain. 
Ils ne cherchent pas seulement à vérifier qu’un message est valide, mais qu’il est compris, traité correctement, et qu’il s’inscrit dans une chaîne fonctionnelle cohérente. 

Ce type de tests permet d’observer ce que la conformité ne révèle pas : 
la robustesse des échanges dans la durée, la gestion des cas limites, les effets de bord liés à la sécurité, à l’organisation ou aux dépendances techniques. 

C’est l’objectif des sessions de test d’interopérabilité, dénommées « Connectathons / Projectathons¹ », « Plugtests » … Quel que soit le nom qu’on leur donne, ces évènements réunissant les éditeurs et les industriels pour tester l’interopérabilité de leurs systèmes, ont fait leurs preuves depuis de nombreuses années. 

Des démarches éprouvées, sur le terrain 

Cette articulation entre conformité et interopérabilité n’est pas théorique. Elle est aujourd’hui mise en œuvre sur des projets structurants, à différentes échelles. 

Au niveau européen, le Once-Only Technical System (OOTS) illustre bien cette logique : les implémentations nationales sont d’abord validées individuellement, avant d’être confrontées lors de Projectathons transfrontaliers, où les échanges réels mettent rapidement en évidence les points de friction. 

À l’échelle nationale, de nombreux pays ont adopté des démarches similaires, combinant validation des règles et tests d’échanges concrets entre acteurs d’un écosystème distribué. On retrouve cette approche au Canada, en France, en Suisse, en Autriche, aux Pays-Bas, en Afrique du Sud… avec des cadres réglementaires différents, mais des enjeux similaires. 

À l’international, ces méthodes sont également appliquées dans des contextes à forte contrainte opérationnelle, comme l’échange de certificats de vaccination numériques en Amérique latine ou la prise en charge de patients internationaux lors du Hajj, le pèlerinage que font les musulmans aux lieux saints de la ville de La Mecque, en Arabie saoudite. Dans ces situations, l’interopérabilité n’est pas un confort, elle conditionne directement la continuité des soins et la sécurité des personnes. 

Dans le domaine de la santé, les Connectathons IHE incarnent cette démarche depuis plus de vingt ans, en combinant validation des profils techniques et tests d’interopérabilité en conditions réalistes (imagerie, laboratoire, pharmacie…). 

Quand l’échelle change, l’orchestration devient clé 

À mesure que les écosystèmes grandissent, un besoin apparaît très clairement : orchestrer les tests. 

Il ne s’agit plus seulement de tester, mais de structurer des campagnes cohérentes, de gérer des rôles multiples, d’enchaîner conformité et interopérabilité, et surtout de capitaliser sur ce qui a été appris. 

Sans orchestration, les tests restent ponctuels, coûteux et difficilement reproductibles. Avec elle, ils deviennent un véritable levier de maturité pour l’écosystème. 

Les outils : utiles, mais jamais une fin en soi 

Dans ce contexte, les outils de test jouent un rôle essentiel, à condition de les considérer pour ce qu’ils sont : des moyens. 

Les moteurs de tests de conformité (ITB, Matchbox, Inferno, Robot Framework, et d’autres) apportent des capacités génériques et réutilisables pour vérifier le respect des spécifications. Leur force réside dans leur adaptabilité à des contextes variés. 

Les plateformes d’orchestration, comme Gazelle, répondent à un autre besoin : structurer, coordonner et industrialiser les campagnes de tests dans des environnements multi-acteurs, en articulant différents moteurs selon les besoins. 

Ces deux approches ne s’opposent pas. Elles se complètent. 
C’est leur combinaison qui permet de construire des dispositifs de tests pérennes, capables d’évoluer sans remettre en cause les fondations à chaque nouveau programme. 

En conclusion 

Les projets numériques critiques ne peuvent plus se contenter d’une vision simpliste des tests. 

Ce que montre le terrain, encore et encore, c’est la nécessité d’une approche équilibrée : 
la conformité comme fondation, l’interopérabilité comme objectif, et l’orchestration comme facilitateur. 

C’est cette combinaison, appliquée avec pragmatisme et constance, qui permet aujourd’hui de sécuriser des échanges numériques à grande échelle, au service des citoyens, des usagers et des administrations.