Interoperability is often presented as a given in large-scale digital programmes, whether in healthcare, public services, identity management or smart cities. In reality, it is rarely where difficulties are anticipated… and almost always where they arise.

When interoperability is poorly addressed, digital transformation creates additional silos instead of removing them. And despite shared standards and ambitious architectures, it remains one of the main sources of fragility in production systems today.

With the benefit of hindsight gained from national and international projects, one thing is clear: interoperability is not just a technical issue. It starts much earlier, at the level of governance, the organisation of stakeholders and the way in which exchanges are actually tested.

From this field experience, one observation consistently emerges:

👉 Interoperability requires compliance as a prerequisite.

👉 Compliance is only valuable if it leads to interoperability.

It is this relationship, often simplified and sometimes misunderstood, that determines the reliability of critical digital exchanges.

Compliance: a necessary step

In all the ecosystems I have observed, compliance testing is the starting point. It makes it possible to verify that an implementation complies with what has been specified: formats, data models, business rules, syntactic and semantic constraints, security mechanisms, signatures, or trust chains.

In many contexts, this compliance is not optional. It is imposed by regulatory, contractual or institutional frameworks and determines access to a programme or ecosystem.

Without compliance, there is simply no reliable foundation. Exchanges become inconsistent, non-reproducible, and sometimes even dangerous.  But experience also shows another, more uncomfortable reality: compliance alone is not enough.

When compliance is no longer enough

It is entirely possible and common for two systems to comply with the same specification… yet be unable to communicate properly.

Why?  Because compliance tests are often carried out in isolation, in controlled environments, with limited scenarios. They validate expected behaviours, but rarely the full range of possible interactions between systems developed by different teams, each with their own interpretations and constraints.

It is in these gaps that problems arise: differences in interpretation, implementation discrepancies, unexpected behaviours that only appear once the systems are connected.

This is precisely where interoperability becomes a subject in its own right.

Testing interoperability, for real

Interoperability testing involves evaluating real-world systems, operated by different actors, in scenarios that closely resemble actual use cases.

The aim is not only to verify that a message is valid, but also that it is understood, processed correctly, and integrated into a coherent functional chain.

This type of testing makes it possible to observe what compliance does not reveal: the robustness of exchanges over time, the management of edge cases, and side effects related to security, organisation, or technical dependencies.

This is the purpose of the interoperability testing sessions, known as « Connectathons / Projectathons », « Plugtests » … Whatever name they are given, these events, which bring together vendors and solution providers to test the interoperability of their systems, have proven their worth over many years.

Proven approaches, in the field

This link between compliance and interoperability is not theoretical. It is currently being implemented in structural projects on various scales.

At European level, the Once-Only Technical System (OOTS) illustrates this logic well: national implementations are first validated individually, before being tested against each other during cross-border Projectathons, where real exchanges quickly highlight points of friction.

At the national level, many countries have adopted similar approaches, combining validation of rules and testing of concrete exchanges between actors in a distributed ecosystem. This approach can be found in Canada, France, Switzerland, Austria, the Netherlands, South Africa, and elsewhere, with different regulatory frameworks but similar challenges.

Internationally, these methods are also applied in contexts with significant operational constraints, such as the exchange of digital vaccination certificates in Latin America or the care of international patients during the Hajj, the pilgrimage made by Muslims to the holy sites in the city of Mecca, Saudi Arabia. In these situations, interoperability is not a luxury, it directly affects the continuity of care and the safety of individuals.

In the healthcare sector, IHE Connectathons have embodied this approach for over twenty years, combining validation of technical profiles and interoperability testing under realistic conditions (imaging, laboratory, pharmacy, etc.).

When the scale changes, orchestration becomes key

As ecosystems grow, one need becomes very clear: orchestrating tests.

It is no longer just a matter of testing, but of structuring coherent campaigns, managing multiple roles, ensuring compliance and interoperability, and above all, capitalising on what has been learned.

Without orchestration, tests remain ad hoc, costly and difficult to reproduce. With orchestration, they become a real lever for maturity within the ecosystem.

Tools: useful, but never an end in themselves

In this context, testing tools play an essential role, provided they are considered for what they are: a means to an end.

Compliance testing engines (ITB, Matchbox, Inferno, Robot Framework, and others) provide generic and reusable capabilities for verifying compliance with specifications. Their strength lies in their adaptability to a variety of contexts.

Orchestration platforms, such as Gazelle, meet another need: structuring, coordinating, and industrialising test campaigns in multi-stakeholder environments, linking different engines as needed.

These two approaches are not mutually exclusive. They complement each other.

It is their combination that enables the construction of sustainable testing systems capable of evolving without compromising the foundations of each new programme.

In conclusion

Critical digital projects can no longer rely on a simplistic view of testing.

What experience in the field shows, time and time again, is the need for a balanced approach: compliance as a foundation, interoperability as a goal, and orchestration as a facilitator.

It is this combination, applied pragmatically and consistently, that now makes it possible to secure large-scale digital exchanges for the benefit of citizens, users and administrations.