Le prochain avantage de l’Europe en IA pourrait être une interopérabilité sans éclat.

L'Europe ne rendra pas l'IA plus utile en rendant tous les systèmes identiques. Elle peut la rendre plus gouvernable en exigeant que les systèmes puissent...

Le prochain avantage de l’Europe en IA pourrait être une interopérabilité sans éclat.

La chose ordinaire qui rend un système utilisable

L’interopérabilité a un problème d’image. Cela ressemble à la partie d’un programme laissée aux personnes qui aiment les architectures de référence, les tableaux de versions et la ponctuation précise d’un schéma. Cette réputation n’est pas entièrement injuste. Un bon contrat d’interface ne battra jamais un nouveau modèle lors d’un lancement de produit. Personne n’apporte un gâteau parce que deux services s’accordent enfin sur la signification d’un enregistrement supprimé.

Pourtant, c’est là que commence une grande partie du travail utile. Un modèle peut être impressionnant isolément et rester d’une aide limitée pour une organisation qui ne peut pas le connecter aux enregistrements, aux règles, aux personnes et aux décisions qui donnent un sens au travail. Le modèle peut produire une réponse fluide. Mais si la réponse ne peut pas porter un identifiant de source, si une correction ne peut pas atteindre les systèmes qui ont agi en conséquence, si une personne ne peut pas dire quelle version de politique a été appliquée, alors le système ne fait pas partie du travail. Il est devenu un autre endroit où copier et coller.

Le prochain avantage de l’Europe en matière d’IA pourrait donc être plutôt peu glamour. Il pourrait s’agir de la capacité à faire se rencontrer les systèmes à des frontières explicites, inspectables et faciles à quitter. Pas une super-application continentale. Pas une exigence que chaque hôpital, mairie, laboratoire et fabricant utilise une seule base de données. L’ambition utile est plus étroite et plus difficile : un service devrait pouvoir échanger des informations, préserver leur signification, respecter les conditions qui les entourent et rester opérationnel lorsqu’un autre composant change.

C’est une capacité stratégique. Elle transforme une collection d’outils en infrastructure. Elle permet à une administration d’un État membre de reconnaître un enregistrement produit dans un autre sans prétendre que leurs lois, leurs langues ou leurs procédures sont identiques. Elle permet à une entreprise de changer un service de traitement des données sans perdre les actifs numériques qui font fonctionner le service. Elle donne à un acheteur un moyen de demander si un système d’IA peut rejoindre un processus existant sans en prendre silencieusement possession. Elle donne à un petit fournisseur une chance de concurrencer sur une frontière documentée plutôt que sur la tolérance du client à la douleur de la migration.

Le point est facile à mal comprendre. L’interopérabilité n’est pas une vertu automatique. Une interface mal conçue peut propager rapidement une mauvaise hypothèse. Un modèle de données partagé peut être trop large, trop invasif ou trop vague. Une norme peut devenir une pièce de musée. Une API ouverte peut encore être coûteuse, peu sécurisée ou si mal documentée qu’elle sert surtout de preuve qu’un département API a existé un jour. L’Europe n’a pas besoin d’une pile décorative de spécifications. Elle a besoin de contrats qui fonctionnent dans des conditions ordinaires, y compris la correction, le retrait, la mise à jour, l’interruption et le départ.

La loi sur l’Europe interopérable donne une définition utile pour les services publics. Elle traite l’interopérabilité transfrontalière comme la capacité des entités de l’Union et des organismes du secteur public des États membres à interagir en partageant des données, des informations et des connaissances par des processus numériques qui répondent aux exigences juridiques, organisationnelles, sémantiques et techniques. Les quatre mots comptent. La compatibilité technique n’est qu’une couche. Deux services peuvent échanger des octets et être en désaccord sur l’autorité, la finalité, la conservation ou la signification d’un statut. Ils peuvent partager un champ appelé approuvé tandis que l’un signifie un contrôle préliminaire et l’autre une décision juridique définitive. Le champ voyage. La décision, non.

C’est là que le sujet devient plus intéressant que la plomberie. L’interopérabilité demande ce qui doit rester vrai quand quelque chose franchit une frontière. Quelle organisation est responsable ? Quelle est l’unité d’information ? Qui peut la modifier ? Que se passe-t-il quand une source est corrigée ? Que signifie une valeur manquante ? Quelle identité a été vérifiée ? Combien de temps le destinataire peut-il la conserver ? Un autre système peut-il prouver quelle version il a reçue ? Ce sont des questions publiques, des questions commerciales et des questions d’ingénierie dans le même manteau.

L’IA rend le manteau plus encombré. Un système d’IA peut s’interposer entre les dossiers et les personnes, extraire des informations de plusieurs sources, appliquer une version de modèle, invoquer un outil, recommander une action et laisser une trace de décision. Si aucune de ces transmissions n’a de contrat défini, un modèle performant peut rendre une organisation moins lisible plutôt que plus capable. La réponse peut être convaincante mais intraçable. Le flux de travail peut sembler plus rapide mais devenir dépendant du format de message privé, de l’état d’agent privé et de la définition privée d’une tâche d’un seul fournisseur. Ce n’est pas de l’intelligence. C’est un changement de propriété caché dans une fonctionnalité de commodité.

L’argument en faveur d’une interopérabilité ennuyeuse n’est pas qu’elle rend la technologie terne. C’est qu’elle rend la technologie responsable. L’Europe est particulièrement bien placée pour valoriser cette distinction. Ses services publics traversent les frontières. Ses langues et ses traditions administratives résistent au fantasme qu’un vocabulaire unique puisse simplement être imposé. Ses règles sur les données traitent de plus en plus l’accès, la portabilité et la gouvernance comme des conditions d’un marché fonctionnel. Et ses organisations tentent souvent d’ajouter l’IA à un travail qui a déjà des obligations, des dossiers et des conséquences. La frontière compte parce que des personnes se tiennent déjà des deux côtés.

La compatibilité n’est pas encore la compréhension

Il existe plusieurs façons pour deux systèmes de sembler compatibles. Ils peuvent utiliser le même protocole réseau. Ils peuvent accepter le même type de fichier. Ils peuvent s’authentifier avec le même schéma d’identité. Ils peuvent même réussir le même test de conformité. Chacune est utile. Aucune ne règle la question plus vaste : le système récepteur peut-il utiliser correctement l’information à la fin déclarée ?

Prenons un exemple modeste et hypothétique. Une autorité régionale envoie un avis à une autorité voisine par une interface bien documentée. La charge utile est valide. La signature est vérifiée. Chaque champ requis est présent. Un champ contient une date. Le système émetteur entend le jour où l’événement sous-jacent s’est produit. Le système récepteur le traite comme le jour où l’avis est devenu juridiquement effectif. Aucun paquet n’a été perdu. Aucun serveur n’a échoué. Les systèmes étaient techniquement compatibles et sémantiquement désalignés. Le résultat peut être un délai erroné, un recours inutile ou une personne à qui l’on demande de refaire un travail qu’une machine a déjà effectué.

L’exemple est délibérément hypothétique. Il n’a pas besoin d’une mairie fictive ou d’un mardi matin pour faire valoir son point. De nombreuses défaillances numériques difficiles ne sont pas spectaculaires. Elles arrivent comme un dossier apparemment complet avec une hypothèse non dite qui s’y rattache. Un horodatage n’a pas de fuseau horaire. Une valeur est vide, mais personne ne dit si vide signifie inconnu, non communiqué, sans objet ou pas encore vérifié. Un identifiant est stable dans un système et recyclé dans un autre. Un indicateur de consentement voyage sans le but, la portée et l’expiration qui le rendaient significatif. L’intégration fonctionne jusqu’à ce que quelqu’un s’y fie.

L’interopérabilité sémantique est la discipline qui consiste à rendre ces significations assez explicites pour être partagées. Elle n’exige pas un dictionnaire universel pour toutes les affaires humaines. Elle exige que les participants à un échange défini conviennent de ce à quoi leurs termes se réfèrent, des contraintes qui s’appliquent, des valeurs autorisées et de la manière dont les changements sont communiqués. Dans le langage du travail de normalisation, elle concerne les modèles de données, les vocabulaires, les identifiants, les relations et les règles qui permettent à un destinataire de les interpréter. Dans le langage d’un opérateur, c’est la différence entre recevoir un dossier et recevoir quelque chose sur quoi on peut agir en toute sécurité.

Le comité technique de l'ETSI sur les données décrit son travail en termes de gouvernance des données, d'interopérabilité sémantique, d'ontologies et d'alignement réglementaire, dans le but de rendre les données partageables et réutilisables entre secteurs et frontières. Ce cadrage est rafraîchissant par sa sobriété. Il refuse l'idée que des données ont de la valeur simplement parce qu'elles ont été placées dans un lac, un espace ou une feuille de calcul dotée d'un nombre respectable d'onglets. Les données deviennent réutilisables lorsque les termes qui les entourent sont suffisamment clairs pour qu'une autre partie en fasse un usage délimité et légitime.

La loi européenne sur les données fait le même constat sous un autre angle. Ses dispositions sur l'interopérabilité concernent les espaces de données et les services de traitement de données. L'explication de la Commission indique que les normes et l'interopérabilité sont essentielles pour utiliser des données provenant de différentes sources au sein des espaces européens communs de données et entre eux, ainsi que pour faciliter le changement de fournisseur de services de traitement de données. Il ne s'agit pas d'une promesse selon laquelle chaque système comprendra soudainement tous les autres. C'est une reconnaissance politique du fait qu'un marché de services isolés laisse aux clients moins de choix pratiques.

Il est tentant d'entendre « sémantique » et de songer à une grande ontologie, à un schéma assez vaste pour mériter sa propre adresse postale. Parfois, un domaine nécessite une modélisation partagée substantielle. Mais le meilleur point de départ est plus modeste. Quel est l'objet de cet échange ? Quelle version est envoyée ? Quelle organisation détient la valeur faisant autorité ? Quel événement peut la modifier ? Que doit faire le destinataire lorsque cet événement se produit ? Quel usage est autorisé ? Comment une personne peut-elle consulter la réponse lorsque le parcours automatisé est incertain ? Un contrat étroit et exécutable vaut mieux qu'un schéma exhaustif que personne ne peut mettre en œuvre.

La même retenue s'applique à l'IA. Un flux de travail d'IA pourrait devoir transmettre un élément de travail à un modèle, recevoir une classification proposée, joindre des sources, solliciter une approbation et consigner la décision dans un système de dossier. Il ne devrait pas prétendre qu'une explication en langage naturel constitue une interface suffisante. Le flux de travail a besoin de faits typés en plus des mots : l'identifiant de l'élément de travail, les versions des sources, la tâche déclarée, les outils autorisés, la condition de confiance ou de refus le cas échéant, la décision du relecteur, l'horodatage et la version de la politique. Le modèle peut rester probabiliste. La frontière autour du modèle ne devrait pas être floue par habitude.

C'est pourquoi l'interopérabilité n'est pas la même chose que l'intégration. Une intégration peut être une connexion privée construite pour une seule relation. Elle peut être tout à fait appropriée. Mais lorsque sa sémantique n'existe que dans l'implémentation d'un fournisseur, la mémoire d'un membre du personnel ou un diaporama d'atelier, la connexion ne se transpose pas bien. Une frontière interopérable laisse derrière elle un contrat qu'une autre partie compétente peut lire, tester et contester. Elle est plus lente à établir qu'un connecteur rapide. Elle est plus rapide à réparer lorsque le connecteur d'origine est devenu une dépendance dotée d'un logo.

Le cadre européen part du problème dans son ensemble

La loi sur l'Europe interopérable n'est pas une loi sur l'IA, et il serait erroné de la présenter comme telle. C'est un règlement pour l'interopérabilité transfrontalière du secteur public. Sa valeur pour l'IA est plus fondamentale. Elle décrit une manière de penser les services publics numériques avant qu'une technologie particulière ne soit placée au milieu d'eux.

En vertu du règlement, les entités de l'Union et les organismes du secteur public concernés doivent effectuer une évaluation de l'interopérabilité avant de décider d'exigences contraignantes nouvelles ou substantiellement modifiées. L'évaluation identifie et évalue les effets sur l'interopérabilité transfrontalière, les parties prenantes concernées et les solutions d'Europe interopérable pouvant soutenir la mise en œuvre. Le rapport qui en résulte doit être publié dans un format lisible par machine facilitant la traduction automatique, sous réserve des protections du règlement concernant la propriété intellectuelle, les secrets commerciaux, l'ordre public et la sécurité.

Voilà qui est plus exigeant que de se demander si un système proposé dispose d’une API. Une API peut être techniquement propre et néanmoins créer une barrière pour une administration voisine, un citoyen, une petite entreprise ou un autre organisme public. L’évaluation pose une autre question : qu’est-ce qui change dans la capacité d’interagir lorsque cette exigence est introduite ? Cela laisse la place à l’autorité juridique, à la responsabilité organisationnelle, au sens sémantique et à la conception technique d’apparaître dans la même conversation. Ils ont toujours fait partie de la même conversation. On avait simplement laissé le logiciel tenir la réunion dans des pièces séparées.

Le règlement rend aussi le partage concret. L’article 4 exige qu’une entité de l’Union ou un organisme du secteur public mette à la disposition d’une autre entité ou d’un autre organisme, sur demande, une solution d’interopérabilité soutenant un service public numérique trans européen, y compris la documentation technique et, le cas échéant, l’historique des versions, le code source documenté et les références aux normes ouvertes ou aux spécifications techniques. Il existe des exceptions, notamment les droits de propriété intellectuelle de tiers et les activités en dehors de la mission de service public. Le principe n’est pas que chaque ligne de logiciel du secteur public doive être publiée sans discernement. Le principe est qu’une solution réutilisable ne devrait pas devenir une découverte privée chaque fois qu’une autre administration en a besoin.

Il y a un changement discret dans cette formulation. La documentation et l’historique des versions ne sont pas des formalités secondaires après la création du composant utile. Ils font partie de ce qui rend le composant réutilisable. Un dépôt de code source sans contexte peut être aussi peu utile qu’une valise sans clé. Une architecture de référence sans explication des hypothèses peut devenir une manière très soignée d’exporter la confusion. La chose réutilisable, c’est le code, la spécification, les limites connues, la version, la preuve de la manière dont il était prévu de l’utiliser et les conditions dans lesquelles il ne devrait pas être utilisé.

Le cadre européen d’interopérabilité, que l’acte place au centre de son modèle d’évaluation, aborde de la même manière l’interopérabilité juridique, organisationnelle, sémantique et technique ainsi que la gouvernance. Cette vision en quatre couches est utile car elle empêche qu’un type de succès se fasse passer pour le résultat complet. Une équipe technique peut mettre en œuvre avec succès une interface. Une équipe juridique peut ne trouver aucun obstacle à l’échange. Une équipe opérationnelle peut convenir d’une procédure d’escalade. Une équipe de domaine peut aligner le sens des objets. Le système ne devient fiable à la frontière que lorsque les couches pertinentes sont alignées pour l’usage particulier.

C’est aussi pourquoi une « norme européenne » n’est pas une formule magique. Les normes peuvent réduire les variations inutiles et rendre un contrat accessible à davantage de participants. Elles ne peuvent pas décider si un échange spécifique est proportionné, licite, sécurisé ou utile. Un profil technique doit être sélectionné, mis en œuvre, gouverné et examiné. Il a besoin d’une politique de version. Il a besoin d’une gestion des erreurs. Il a besoin d’un moyen de représenter l’incertitude. Il a besoin d’un processus pour décider quand une extension locale est justifiée et quand elle est devenue une dérivation privée dans un manteau public.

Le cas du secteur public est particulièrement révélateur car le coût de la dérive sémantique est souvent supporté par une personne extérieure à l’équipe technique. Un résident peut être invité à soumettre des informations deux fois. Une entreprise peut avoir besoin de traduire un formulaire d’un vocabulaire administratif à un autre. Un professionnel peut perdre du temps à rapprocher des dossiers. Un service transfrontalier peut ne fonctionner que pour les personnes dont le cas correspond par hasard au chemin le plus simple. L’acte ne garantit pas que ces résultats disparaissent. Il crée des mécanismes pour rendre visibles leurs conséquences en matière d’interopérabilité avant qu’une exigence ne se durcisse en infrastructure.

L’IA devrait hériter de cette discipline. Avant d’ajouter un modèle à un service trans-européen ou à un service ayant d’autres conséquences importantes, le responsable devrait être en mesure d’indiquer quels objets le modèle peut lire, quels objets il peut créer, quelles décisions restent humaines, comment une correction se propage, quelle sortie est une aide plutôt qu’un document faisant autorité, comment le service se comporte lorsque le modèle est indisponible et comment un destinataire peut contester ou inspecter le résultat. Il ne s’agit pas d’une couche de conformité supplémentaire drapée sur un produit par ailleurs complet. C’est la définition de l’interface d’un système qui s’attend à être approuvé par des personnes qui ne partagent pas le contexte privé du modèle.

Survolez une couche et sélectionnez-la. Une frontière ne tient que lorsque les couches concernées s’accordent sur ce qui doit se passer.

La portabilité est un test de la réalité de la frontière

L’interopérabilité devient stratégique lorsqu’une relation change. Un service est mis à jour. Un fournisseur est remplacé. Une administration publique doit réutiliser un composant. Un participant à un espace de données modifie sa politique. Un fournisseur de modèles change le format de ses messages. Une nouvelle condition de sécurité impose qu’une charge de travail s’exécute ailleurs. À ce moment-là, la qualité de la frontière devient visible.

Le règlement sur les données traite cela comme plus qu’un simple inconvénient pour les clients. Ses règles sur le changement de fournisseur et l’interopérabilité des services de traitement de données visent à réduire les obstacles au passage d’un service à un autre, à l’utilisation de plusieurs services en parallèle et à la portabilité des données et des applications. L’étude 2026 de la Commission sur l’interopérabilité des services de traitement de données décrit l’article 35 comme appelant à des spécifications ouvertes et harmonisées qui permettent à des services du même type de fonctionner ensemble et rendent les données et les applications portables sans nuire à la sécurité. Elle note également le référentiel prévu par l’Union pour les normes et spécifications ouvertes pertinentes, ainsi que la possibilité de spécifications communes lorsque les normes harmonisées ne suffisent pas.

Il vaut la peine d’être précis sur ce que cela signifie et ne signifie pas. Le règlement sur les données ne promet pas qu’un client puisse transférer un service complexe d’un fournisseur à un autre sans modification un vendredi après-midi. Il n’exige pas que les fournisseurs divulguent des secrets commerciaux, compromettent la sécurité ou rendent tous les types de services identiques. L’équivalence fonctionnelle, là où le règlement l’exige pour les services du même type, n’est pas une affirmation de consoles identiques, de modèles de prix identiques ou de choix techniques identiques. C’est une idée plus utile et plus modeste : des caractéristiques partagées devraient permettre à la charge de travail du client de poursuivre sa fonction prévue à travers une frontière pertinente.

Cette distinction importe car un fichier portable n’est pas nécessairement un service portable. Une exportation de données peut omettre les relations, l’ordre des événements, la configuration, l’historique des autorisations, les identifiants, l’état de conservation, les versions de politique et les connaissances opérationnelles nécessaires pour restaurer le système. Une sortie de modèle peut être exportée tandis que la configuration de récupération, la version de l’invite, les critères d’évaluation et les autorisations d’outils qui l’ont façonnée restent privés. Le fichier a été déplacé. Les conditions dans lesquelles il pouvait être approuvé ne l’ont pas été.

Le bon test n’est pas « pouvons-nous télécharger quelque chose ? » C’est « une destination compétente peut-elle interpréter et exploiter la partie du service qui importe ? » Ce sont des questions différentes. La première peut être résolue par un bouton. La seconde nécessite un inventaire, un schéma, un chemin de réception, un test, des personnes qui comprennent la frontière et une déclaration honnête de ce qui ne peut pas voyager.

Prenons un autre exemple, explicitement hypothétique. Une équipe utilise un service d’IA pour préparer une première version destinée à une relecture interne. Ce service dispose d’une fonction d’exportation. Lors d’un déménagement planifié, l’équipe reçoit le texte généré et une liste de comptes utilisateurs. Elle ne reçoit pas les versions des sources de connaissances, les registres de décisions qui déterminaient quelles sources étaient autorisées, le statut d’approbation des brouillons, la configuration du modèle ni les règles qui empêchaient le service d’envoyer un brouillon à un destinataire externe. L’équipe a son texte. Elle n’a pas récupéré son flux de travail. Si l’ancien service avait été un éditeur de documents, cela pourrait être tolérable. Si les brouillons façonnent un travail réglementé ou lié à la sécurité, c’est une autre catégorie de problème.

La portabilité comporte donc au moins quatre niveaux. Il y a la portabilité technique : les données et les interfaces peuvent-elles être transférées sous des formes utilisables ? Il y a la portabilité sémantique : le destinataire peut-il comprendre les enregistrements, les événements et les contraintes ? Il y a la portabilité opérationnelle : les personnes peuvent-elles exécuter, sécuriser, observer, corriger et restaurer la charge de travail ? Et il y a la portabilité institutionnelle : l’organisation peut-elle remplir ses obligations publiques, contractuelles et légales pendant le déménagement ? Aucun format d’exportation unique ne règle ces quatre aspects.

C’est là que les achats peuvent devenir une force constructive. Un appel d’offres peut demander les catégories de données et d’actifs numériques exportables, les schémas et leurs versions, les limites de débit, les contrôles d’intégrité, les implications en matière d’identité et d’accès, les limitations connues, le comportement en matière de conservation et de suppression, ainsi que l’assistance disponible pendant une transition. Il peut demander si un export représentatif peut être reçu et validé par une destination sans accès privé à la console du fournisseur. Il peut demander quelles parties sont spécifiques au fournisseur par conception. Une limitation franche est gérable. Une limitation cachée devient un budget d’urgence.

Les mêmes questions aident un fournisseur. Un fournisseur qui sait quelle limite il doit maintenir stable peut concevoir moins de dépendances accidentelles. Il peut rendre explicite une politique de versions. Il peut publier un chemin de dépréciation. Il peut donner aux clients un environnement de test qui se comporte comme une véritable interface plutôt que comme une démonstration marketing. Il peut distinguer la partie d’un système qui est réellement propriétaire de celle qui doit être partagée pour que le client conserve sa capacité d’agir. Ce n’est pas de la charité. C’est un contrat plus clair pour les deux parties.

L’avantage de l’Europe ici n’est pas qu’elle puisse éliminer la dépendance. Les systèmes sérieux ont des dépendances. L’avantage est la possibilité de rendre la dépendance lisible, négociable et suffisamment réversible pour l’usage considéré. Un système qui peut rester chez un fournisseur parce qu’il continue de mériter la relation est plus solide que celui qui reste parce que personne ne peut reconstituer ailleurs le sens de ses enregistrements.

Les espaces de données ne sont pas des entrepôts mieux éclairés

L’expression « espace de données » peut créer une image trompeuse. Elle évoque une grande salle où chacun apporte ses données, les dépose sur une étagère et repart satisfait de l’interopérabilité. L’approche européenne est plus exigeante. Les espaces européens communs de données visent à rendre les données disponibles pour l’accès et la réutilisation dans un environnement sûr et digne de confiance. La Commission décrit les infrastructures communes et les cadres de gouvernance comme les éléments qui soutiennent la mise en commun, l’accès et le partage, aux côtés de règles d’accès équitables, transparentes, proportionnées et non discriminatoires.

Voilà une correction importante. Le partage de données n’est pas un acte de transfert ponctuel. C’est une relation continue entre des parties aux finalités, pouvoirs et responsabilités différents. Un participant peut être autorisé à utiliser un jeu de données pour la recherche, mais pas pour le marketing. Un autre peut avoir l’obligation de corriger une valeur. Un troisième peut être autorisé à recevoir un résultat dérivé, mais pas l’enregistrement sous-jacent. Certaines données doivent être conservées. D’autres doivent être supprimées. Certaines ne peuvent être traitées que dans un environnement particulier. Les conditions qui régissent ces échanges font partie de l’interopérabilité, et non une note de bas de page dans un dossier juridique séparé.

Les travaux de la Commission sur les espaces de données identifient un soutien dans l’architecture de référence, les briques de base, la sémantique, les spécifications d’interopérabilité et les modèles de données, ainsi que des services de conseil via le Data Spaces Support Centre. Cette ampleur est judicieuse. Un connecteur sécurisé sans vocabulaire partagé ne résout pas un problème sémantique. Un vocabulaire partagé sans identité, contrôle d’accès ni gouvernance ne résout pas un problème de confiance. Un modèle capable d’interroger un espace de données sans finalité déclarée, sans enregistrement source ni voie de correction ne rend pas l’espace plus utilisable. Il crée un nouveau consommateur d’informations dont les obligations sont obscures.

Pour l’IA, l’implication est simple. Un modèle ne doit pas être traité comme un raccourci privilégié contournant les limites d’un espace de données. Si une personne ou un service a besoin d’une base d’accès, d’une finalité définie, d’une identité et d’une trace d’utilisation, un flux de travail d’IA doit respecter la même discipline. Il peut y avoir des différences techniques dans la manière dont un agent demande des données ou dont une étape de récupération est exécutée. Il ne doit pas y avoir d’exemption magique où le système déclare « le modèle avait besoin de contexte » et où les règles de gouvernance ordinaires quittent les lieux.

Cela ne signifie pas que chaque requête doive être transformée en cérémonie bureaucratique. Cela signifie que le système doit distinguer une question d’une autorisation. Un modèle peut formuler une requête. Une couche sensible aux politiques doit décider si la requête peut atteindre une source donnée, sous quelle finalité, avec quelle minimisation, et comment la demande et le résultat sont enregistrés. Une réponse peut ensuite citer une source ou expliquer une limitation. Si la source change, le système doit pouvoir savoir quelle réponse ou décision ultérieure pourrait nécessiter un examen. Sinon, la provenance devient un lien décoratif dans une transcription de chat.

Les contrats sémantiques sont particulièrement utiles ici, car ils rendent visible l’unité minimale de confiance. Un identifiant de source n’est pas simplement une chaîne de caractères. Il doit identifier une version ou une référence stable. Une permission n’est pas simplement vraie ou fausse. Elle peut avoir une portée, une finalité, un titulaire, une limite de temps et une base. Une correction n’est pas simplement une mise à jour. Elle peut remplacer une affirmation antérieure tout en préservant l’historique nécessaire pour expliquer ce qui s’est passé. Un refus n’est pas simplement une erreur. Il peut être une limite délibérée qui doit être compréhensible pour la personne qui demande.

La tentation sera de résoudre cela avec une « couche d’interopérabilité IA » universelle qui prétend rendre interchangeables tous les agents, modèles, bases de données et outils de flux de travail. Ce genre d’affirmation confond généralement le transport commun avec le sens commun. Un protocole générique peut être utile. Il ne peut pas dire à un destinataire ce qu’un code clinique, un statut de planification, une décision de prestation ou un indicateur de risque signifie dans le domaine particulier. Il ne peut pas décider qui peut passer outre une suggestion automatisée. Il ne peut pas dire à une organisation combien de temps elle peut conserver un enregistrement récupéré. Les normes portent des accords. Elles ne suppriment pas la nécessité de les conclure.

Il existe une ambition plus concrète. Construire des accords propres à un domaine lorsque le travail partagé les justifie. Réutiliser les briques générales lorsqu’elles conviennent réellement : identité, autorisation, provenance, événementiel, versioning, tests de conformité et documentation accessible. Maintenir la connexion entre une norme générale et une mise en œuvre locale inspectable. Ainsi, un participant peut rejoindre sans abandonner tout son système, et un secteur peut évoluer sans repartir d’une page blanche à chaque arrivée d’un nouveau fournisseur.

C’est une meilleure version de l’échelle. Elle ne mesure pas le succès par la quantité de données centralisées ni par le nombre de services contraints dans une seule interface. Elle mesure le succès par la capacité d’un échange légitime à se produire avec suffisamment de clarté pour que les participants puissent l’utiliser, le corriger, le gouverner et, si nécessaire, l’arrêter.

Sélectionnez une carte pour inspecter la partie d’un échange qui rend un enregistrement utilisable au-delà de son système d’origine.

Les normes ont besoin d’une vie après la publication

Les normes sont souvent décrites comme si leur travail s’achevait à la publication du document. En pratique, la publication est le moment où le travail le plus difficile commence. Quelqu’un doit choisir le profil applicable. Quelqu’un doit le mettre en œuvre. Quelqu’un doit tester les cas limites. Quelqu’un doit décider si une nouvelle version est compatible, quand l’ancienne version est retirée et ce qu’il advient des enregistrements créés sous les règles antérieures. Quelqu’un doit expliquer l’ensemble à une équipe qui n’était pas dans la salle lorsque l’acronyme a été choisi.

La norme EN 18235-1:2026 du CEN et du CENELEC est un exemple récent de cette orientation. Elle concerne le partage et l’échange de données entre organisations, avec un accent sur l’interopérabilité et la responsabilité, et ses applications annoncées incluent les espaces européens communs de données. Le détail importe moins ici que le signal. La confiance dans le partage de données n’est pas traitée comme un sentiment généré par un tableau de bord. Elle est traitée comme quelque chose de façonné par des accords autour de l’échange, de la responsabilité et de la capacité à rendre compte de ce qui s’est passé.

Le meilleur travail normatif laisse de la place pour ce qu’il ne peut pas régler. Une spécification technique peut définir une structure de message. Elle ne peut pas déclarer une base juridique locale. Un vocabulaire peut définir un concept. Il ne peut pas garantir qu’un processus local utilise le concept honnêtement. Un test de conformité peut montrer qu’une mise en œuvre satisfait des cas nommés. Il ne peut pas prouver que l’organisation a formé les personnes qui gèrent les exceptions. Prétendre le contraire dessert les normes. Cela les fait passer pour un substitut au jugement plutôt que pour un outil qui permet au jugement d’aller plus loin.

Les tests de conformité sont particulièrement précieux car ils transforment l’interopérabilité d’une promesse en une propriété observable. Un fournisseur peut affirmer qu’il prend en charge un profil. Un acheteur doit pouvoir demander quelle version, quelles fonctionnalités optionnelles, quels cas négatifs, quelles réponses d’erreur et quelles preuves de test publiées étayent cette affirmation. Un implémenteur doit pouvoir exécuter les mêmes cas avant qu’une intégration n’atteigne la production. Un changement doit déclarer s’il est rétrocompatible et quels consommateurs doivent agir.

Pour les interfaces d'IA, cela peut sembler pointilleux jusqu'à la première modification incompatible. Un appel d'outil attend un montant en centimes. Un autre renvoie une chaîne décimale sans devise. Un agent traite un champ absent comme une demande d'informations supplémentaires. Un autre l'interprète comme une autorisation à déduire une valeur. Une mise à jour de modèle modifie la structure des citations. Un processus en aval analyse toujours l'ancienne forme. Aucun de ces cas n'est une énigme philosophique. Ce sont des défaillances d'interface ordinaires rendues plus lourdes de conséquences par un système capable d'agir rapidement.

Un bon contrat contient donc le refus aussi bien que la réussite. Il précise ce que le système rejettera, ce qu'il renverra lorsqu'une source ne peut pas être vérifiée, ce qu'il fera lorsqu'une politique est manquante, comment le destinataire peut distinguer des données partielles de données complètes et où commence la revue humaine. Le silence est une stratégie d'interopérabilité désastreuse. Un refus clair est souvent la réponse la plus compatible, car il donne au système suivant un état honnête avec lequel travailler.

La gestion des versions mérite le même respect. Une interface utile ne se contente pas d'ajouter un numéro de version à une URL et d'espérer que tout ira bien. Elle déclare le changement, indique le chemin de migration, préserve l'ancien contrat pour la période promise lorsque c'est possible, enregistre comment les données stockées sont interprétées selon les versions et fournit un préavis suffisant pour que les systèmes dépendants puissent s'adapter. Ce n'est pas un travail passionnant. C'est ainsi qu'une frontière cesse d'être une surprise. Aux Pays-Bas, on aime dire qu'une chose est « assez claire » jusqu'à ce que quelqu'un doive la construire. La politique de version est ce qui reste après que cette expression a rencontré un système de production.

Il y a ici un point de vue économique européen. Les petites organisations peuvent participer lorsque les règles de connexion sont publiques, documentées et testables. Elles n'ont pas besoin d'une relation privée avec chaque plateforme dominante pour découvrir comment un échange se comporte. Les grandes organisations y gagnent aussi, car elles peuvent réduire leur dette d'intégration sur mesure et tester les affirmations d'un fournisseur avant qu'une dépendance essentielle ne se forme. Le résultat n'est pas sans friction. C'est une friction plus équitable : le travail est visible, tarifé et partagé plutôt que découvert après que le contrat a réduit les options.

La question pratique est de savoir ce qui survit à la passation

La plupart des programmes d'interopérabilité s'améliorent lorsqu'ils commencent par un petit échange plutôt que par une grande aspiration. Choisissez une décision ou une frontière de service. Décrivez les informations qui doivent la franchir. Nommez la source d'autorité, le destinataire, l'usage autorisé, le vocabulaire, les événements du cycle de vie, les conditions de sécurité et les preuves qui montreront que l'échange s'est déroulé comme prévu. Testez ensuite à la fois la réussite et l'échec.

La conversation qui en résulte est souvent plus révélatrice qu'une comparaison de fonctionnalités. Que se passe-t-il lorsque la source corrige un enregistrement ? Le destinataire peut-il identifier quelle copie est concernée ? Que se passe-t-il lorsqu'un système d'IA ne peut pas étayer une recommandation par une source autorisée ? Renvoie-t-il un refus explicite, un résultat partiel ou une confiance inventée ? Que se passe-t-il lorsqu'un destinataire reçoit une version de schéma qu'il ne comprend pas ? Peut-il rejeter l'échange en toute sécurité ? Que se passe-t-il lorsqu'une personne conteste une classification ? La correction devient-elle un nouvel événement avec une trace, ou l'ancien résultat est-il écrasé jusqu'à ce que personne ne puisse reconstituer la base de l'action d'origine ?

Ce sont des questions de conception, pas seulement des questions de conformité. Elles déterminent si les personnes peuvent utiliser un service, si un fournisseur peut le prendre en charge et si un autre système peut s'y joindre sans hériter d'un risque non documenté. Elles déterminent aussi la qualité de l'IA. Un modèle avec une frontière d'information claire a moins de place pour transformer un contexte ambigu en hypothèses invisibles. Un flux de travail avec des sorties typées et une identité de source donne aux réviseurs quelque chose de concret à inspecter. Un registre de décisions versionné rend l'évaluation possible après que le modèle, l'invite ou la politique a changé.

Il existe des limites raisonnables. Certaines données ne devraient pas circuler. Certaines informations devraient être minimisées ou agrégées. Certains services ont besoin d'une frontière sur mesure, car le travail est inhabituel, sensible ou à haut risque. Une partie du vocabulaire local doit rester locale, car imposer une fausse équivalence détruirait le sens. L'interopérabilité n'exige pas que chaque système expose tout. Elle exige que la frontière choisie soit honnête sur ce qu'elle expose, pourquoi, à qui et avec quelles conséquences.

Cette honnêteté est particulièrement importante lorsque les fournisseurs d'IA proposent une connexion rapide. Un connecteur qui copie silencieusement un vaste corpus dans le contexte d'un modèle peut résoudre un problème de démonstration tout en créant un problème de gouvernance. Un outil qui écrit dans un système métier sans identifiant de travail durable peut créer une automatisation tout en détruisant la capacité à l'auditer. Un protocole d'agent universel peut faciliter la découverte tout en laissant sans réponse l'autorisation, la limitation de finalité et la responsabilité sémantique. La question devrait toujours être ce qui survit au transfert : les données, le sens, l'autorisation, la preuve et la capacité de correction.

Un programme utile donne à chacun de ces éléments un lieu d'accueil. Les données ont besoin d'un format et d'un contrôle d'intégrité. Le sens a besoin d'un modèle, d'un vocabulaire ou d'un mappage explicite. L'autorisation a besoin d'une identité, d'une finalité et d'une frontière de politique. La preuve a besoin d'un enregistrement de la source, de la version, de la transformation et de la décision. La correction a besoin d'un chemin d'événements et d'un propriétaire responsable. L'exploitation a besoin d'un runbook, d'une observabilité et d'un moyen d'arrêter ou d'annuler une modification. Rien de tout cela ne fait un film de lancement héroïque. Cela rend néanmoins possible qu'un système reste utile après que le film de lancement a été remplacé par un ticket de support.

Chez Dweve, nous appliquons ce principe de manière étroite dans la description publique de Fabric. Le site décrit un modèle d'objet centré sur le travail dans lequel les modèles, les agents, les outils, les personnes et les flux de travail participent via des contrats typés, et il décrit des interfaces utilisateur et des API opérant sur le même domaine. C'est une position de conception de produit, et non la preuve qu'un déploiement quelconque est automatiquement interopérable ou qu'une interface typée règle les questions juridiques, sémantiques ou opérationnelles. C'est simplement le type de frontière que nous pensons que les systèmes d'IA sérieux nécessitent : une frontière dans laquelle le travail durable ne disparaît pas dans une conversation propre à un fournisseur.

HEDL offre un exemple public plus restreint. Sa documentation décrit un format texte sous licence Apache 2.0, une spécification de format publiée et des documents de conformité, avec des conversions vers et depuis JSON, YAML, XML, CSV, Parquet et TOON. Ces fonctionnalités ne rendent pas chaque ensemble de données compatible, et elles ne transforment pas une conversion de format en accord sémantique. Elles constituent néanmoins une affirmation utile sur une frontière : un format d'échange doit être inspectable, testable et capable de coexister avec les systèmes existants, plutôt que d'exiger que chaque système devienne son propre dialecte privé.

L'Europe n'a pas besoin de gagner une course à l'IA en s'éloignant de ses propres institutions. Son opportunité est de rendre ces institutions, ces marchés et ces communautés techniques plus faciles à connecter sans prétendre que leurs différences n'ont pas d'importance. Le travail semblera ennuyeux à distance. C'est l'historique des versions, les fixtures de test, les choix de vocabulaire, les règles d'accès, les exercices de migration et la réunion occasionnellement inconfortable sur qui est autorisé à modifier un champ. De près, c'est le travail qui permet à un système d'être digne de confiance pour quelqu'un d'autre que l'équipe qui l'a construit.

C'est un avantage qui vaut la peine d'être possédé. Un modèle peut être remplacé. Un fournisseur peut être changé. Un service peut franchir une frontière. Une correction peut atteindre l'endroit où elle compte. Une personne peut demander ce qui s'est passé et recevoir quelque chose de mieux qu'un paragraphe confiant. La technologie reste ambitieuse. La frontière reste ordinaire. C'est la partie ordinaire qui donne à l'ambition un endroit fiable où se tenir.

Sources