Pour que l’information puisse circuler de manière transparente entre différents systèmes informatiques, ceux-ci doivent absolument parler la même langue. Les organismes de réglementation transfrontaliers, s’ils peuvent déterminer quelles données ils exigent, devraient tous utiliser un langage similaire et harmoniser la méthode de soumission des données demandées. Cette normalisation est également essentielle pour que les opérateurs économiques puissent utiliser un seul et même système pour se conformer aux exigences des différentes administrations et des différents pays.

Or ce langage commun existe : il s’agit du Modèle de données de l’OMD. Élaboré et tenu à jour par une équipe de projet ad hoc, l’EPMD, ce modèle est une compilation d’ensembles clairement structurés, harmonisés, normalisés et réutilisables de définitions de données et de messages électroniques, conçue pour répondre aux exigences opérationnelles et juridiques des organismes de réglementation transfrontaliers, dont les douanes[1].

Un article publié en mars 2022 dans le présent magazine[2] décrit les mesures que doivent prendre les administrations douanières qui envisagent d’adopter le Modèle de données de l’OMD.

Cet article explique qu’elles devraient :

• recenser les domaines de mise en œuvre (importations, exportations, transit, déclaration de fret, manifeste, opérateurs économiques autorisés, origine, phytosanitaire, sécurité alimentaire, santé animale, espèces menacées, environnement ou biens culturels, par exemple) ;
• délimiter les besoins en données du processus sélectionné et les harmoniser ;
• faire correspondre la liste des exigences nationales (ou régionales) en matière de données avec le Modèle de données de l’OMD et mettre au point un dossier d’information (« Mon dossier d’information » – MDI) ; et
• appliquer le MDI au système informatique pour s’assurer que le système puisse recevoir et/ou produire des données conformes aux spécifications techniques du Modèle de données de l’OMD.

Les processus douaniers sont complexes et il est très peu probable qu’une solution informatique unique permette de traiter efficacement tous leurs aspects et complications. C’est également le cas pour de nombreux processus opérationnels. Raison pour laquelle de plus en plus d’administrations et d’entreprises mettent au point des systèmes informatiques basés sur une architecture de services, ou architecture orientée services (SOA), approche qui consiste à utiliser les applications et services (unités logicielles autonomes) existants pour le développement de composants informatiques.

Un des grands avantages des architectures de services est qu’elles permettent de mettre au point des solutions technologiques en utilisant différents modules. Les développeurs peuvent ainsi régler les problèmes étape par étape, en abordant le système pièce par pièce, et composant par composant. Parmi les autres avantages, citons la capacité d’adapter facilement le système à une charge de travail accrue ou aux exigences du marché (grande évolutivité), la capacité d’effectuer des ajustements facilement et des coûts de mise en œuvre inférieurs à ceux d’autres méthodes de développement de systèmes informatiques.

La SOA facilite l’élaboration de solutions robustes car elle permet de développer séparément des solutions spécifiques et spécialisées pour répondre aux besoins et aux contraintes des processus et procédures. Les composants liés à la gestion des risques, au guichet unique, au programme des OEA, à la classification tarifaire ou aux inspections, par exemple, peuvent être conçus et construits individuellement et séparément, avec la meilleure technologie et le meilleur fournisseur de services.

Cela étant, assurer la compatibilité et l’interopérabilité entre des composants et des fournisseurs aussi nombreux constitue un défi de taille. L’adoption du Modèle de données de l’OMD est donc cruciale ici aussi, et c’est pourquoi la version 4.0 du modèle prévoira l’utilisation de normes et de syntaxes utilisées dans les systèmes basés sur la SOA.

Nous conseillons à toute personne mettant en œuvre le Modèle de données de l’OMD d’avoir recours à la SOA et aux normes qui la sous-tendent, telles que OpenAPI et JSON qui sont décrites dans les paragraphes suivants.

Autre tendance qui a émergé avec la SOA : l’utilisation d’interfaces de programmation d’applications (API) en remplacement de l’EDI pour l’échange de documents. Ces deux méthodes permettent un échange de données rapide et sécurisé d’un système à l’autre.

Avec l’EDI, les systèmes informatiques sont en mesure de comprendre l’information échangée parce que chaque partie utilise le format de document EDI standard. Les données EDI sont stockées puis transmises. Cependant l’accès et la réactivité en temps réel peuvent s’en trouver limités. En outre, les documents EDI ne transmettent pas d’informations mises à jour, mais une version séquentielle du même document. Il appartient dès lors au destinataire d’analyser le document, de le comparer à la version précédente et de répercuter dans la base de données les éventuelles modifications détectées.

L’API est un ensemble d’instructions et de normes de programmation pour accéder aux applications logicielles basées sur le Web qui permettent aux plateformes logicielles de communiquer entre elles. Contrairement à l’EDI, il ne suppose pas l’utilisation de formats de documents standard prédéfinis pour les transactions d’échange de données. Les transactions API ont recours aux formats JSON, XML, YAML et à d’autres formats de sérialisation des données pour l’échange d’informations. Ces formats sont génériques, pas spécifiques comme les formats de documents EDI. De plus, contrairement à l’EDI, les API permettent l’échange de données en temps réel et sont à même de transférer des données en moins d’une seconde.

L’Équipe de projet chargée du Modèle de données de l’OMD est tout à fait consciente de ces évolutions technologiques, et la version 4.0 du Modèle comprendra des lignes directrices pour l’utilisation des syntaxes OpenAPI et JSON, considérées comme les piliers d’une SOA moderne. OpenAPI est le nom donné à une initiative qui vise à apporter un nouveau moyen de décrire les services électroniques indépendamment du langage de programmation ou de la technologie qui les sous-tendent. Elle est devenue la lingua franca de tout API et offre ainsi la possibilité d’élaborer des services qui, bien que technologiquement indépendants les uns des autres, restent compatibles et interopérables. JSON, quant à lui, fournit un format d’échange de données léger, facilement lisible par les machines et les humains. Sa principale caractéristique est qu’il a été conçu pour prendre en charge de très grands volumes d’informations.

En adoptant les syntaxes SOA, OpenAPI et JSON, les douanes et autres organismes de réglementation seront en mesure de construire leurs plateformes composant par composant, avec le Modèle de données de l’OMD comme langage universel.

Il est déjà possible d’implémenter le Modèle de données en utilisant de telles syntaxes dans le cadre d’une SOA. À titre d’exemple, le guichet unique du Brésil a mis en œuvre le Modèle de données de l’OMD avec OpenAPI et JSON. Il peut ainsi actuellement gérer 2 millions de déclarations d’exportation et 2,4 millions de déclarations d’importation par an. Lorsqu’ils sont combinés et inclus en tant que syntaxe dans le Modèle de données de l’OMD, OpenAPI et JSON assurent la validité technologique et l’agnosticisme technique.

Les modèles de messages électroniques du Modèle de données de l’OMD utilisent actuellement les formats de données EDIFACT-ONU (GOVCBR), ainsi que le langage XML, utilisé pour créer et échanger des données structurées. L’utilisation d’OpenAPI et de JSON ne rend pas le langage XML obsolète. Au contraire, ces deux normes complètent le langage XML et ses schémas, et offrent de nouvelles possibilités pour la mise en œuvre des spécifications XML. Les messages électroniques rédigés en XML sont tout à fait compatibles avec tout système utilisant OpenAPI/JSON, et vice versa.

Cadre de conformité

Le Modèle de données de l’OMD est un langage universel, agnostique à la technologie et aux fournisseurs. Lors du développement d’un système utilisant le Modèle, chaque entité concernée et chaque fournisseur doivent être en mesure de confirmer que les composants du système « parlent » parfaitement ce langage universel.

Pour faciliter ce travail, un outil clé a été mis au point : le « Cadre de conformité ». Ce cadre définit clairement les spécifications techniques du Modèle de données de l’OMD et élimine ainsi toute ambiguïté afin de garantir que les solutions sont conformes au Modèle. Il permet aux autorités douanières, aux organismes gouvernementaux, aux entités financières et aux donateurs qui ne possèdent pas d’expertise concernant le Modèle de données de l’OMD de demander le respect du « Cadre de conformité » en guise de critère fondamental pour accepter les propositions et octroyer les contrats.

Le Modèle de données de l’OMD est une boîte à outils contenant des éléments interdépendants : modèles d’information, codes pour les normes internationales, ensembles de données harmonisés et modèles de processus opérationnels. Bon nombre de systèmes utilisés dans le monde sont en place depuis de nombreuses années. Cela signifie qu’il serait presque impossible, dans la majorité des cas, pour une partie qui déciderait d’adopter le Modèle de données de l’OMD, de se conformer pleinement à tous les éléments du Modèle de données de l’OMD sans repartir de zéro. Qui plus est, nombreuses sont les parties qui rencontreront également des difficultés en raison de la nécessité d’assurer l’intégration avec les applications et les processus métier existants, qu’il faut continuer de supporter.

Voilà pourquoi le Cadre de conformité est un système graduel qui prévoit quatre degrés de conformité au modèle :

• Niveau 1 : chaque élément de données du message utilise le nom et la représentation de format des éléments de données de l’OMD.
• Niveau 2 : chaque élément de données du message répond aux critères de niveau 1 et sa structure est conforme à la structure du diagramme de classes UML du Modèle de données de l’OMD.
• Niveau 3 : répond aux critères de niveau 2 et utilise les listes de codes recommandées par l’OMD.
• Niveau 4 : répond aux critères de niveau 3 et est basé sur un format de message pris en charge par le Modèle de données de l’OMD, par exemple EDIFACT GOVCBR, XML, OpenAPI/JSON.

Le « Cadre de conformité » devrait être considéré comme un certificat d’assurance qualité garantissant la durabilité à long terme du système en cours de construction. La construction de solutions informatiques douanières demande un gros investissement et la durabilité est donc essentielle.

Lors de l’élaboration du « dossier d’information », les administrations douanières doivent faire correspondre la liste des exigences nationales ou régionales en matière de données avec les ensembles de données du Modèle de données de l’OMD. Il y a deux moyens d’y arriver.

La première solution consiste à procéder processus par processus, en se concentrant sur chaque élément de données pour trouver sa correspondance dans le Modèle. Lors de la construction de son guichet unique pour le commerce extérieur (VUCE), le Costa Rica a appliqué cette méthode pour définir les informations que l’importateur doit fournir pour permettre aux organismes gouvernementaux intervenant dans le processus de dédouanement de s’acquitter de leurs tâches. Le nombre de processus couverts par le MDI du Costa Rica est estimé à 129. Il comprend en outre 250 éléments de données du Modèle de données de l’OMD.

La deuxième solution consiste à créer deux interfaces : l’une pour encapsuler les composants de données qui existent actuellement dans le système douanier et l’autre pour traduire ces données en données du Modèle de l’OMD. Les administrations douanières peuvent ainsi mettre en œuvre le Modèle de données tout en ayant plus de temps pour décider des ajustements ou de la reconstruction de leur système informatique, ou pour décider qu’il ne faut pas revoir le système informatique mais seulement le rendre conforme à la norme de l’OMD. C’est le choix qui a été fait en Uruguay, y compris par des entreprises du secteur privé désireuses d’aligner leurs systèmes de gestion sur le Modèle de données de l’OMD et plus particulièrement sur le modèle régional MDI baptisé « MODDA », mis au point par le Mercosur (union douanière entre l’Argentine, le Brésil, le Paraguay, l’Uruguay et le Venezuela).

Dans une architecture orientée services, les composants logiciels sont appelés services. Chacun d’eux fournit une capacité opérationnelle et ils peuvent communiquer entre eux au moyen de différents langages et plateformes, en utilisant une syntaxe et des structures de données normalisées.

Dans cet article, nous avons plaidé pour la mise en œuvre du Modèle de données de l’OMD avec une SOA ainsi qu’avec OpenAPI et JSON. Dans une telle configuration, les différents composants d’une solution informatique peuvent en fin de compte être considérés comme des services. Jusqu’à présent, le Modèle de données de l’OMD s’est concentré sur la définition d’un dictionnaire de données harmonisé à utiliser par les organismes de réglementation aux frontières. À l’avenir, il pourrait inclure les services comme une sorte de prolongement du Modèle. Il existe un nombre infini de services applicables aux données représentées par le Modèle de données de l’OMD. On citera par exemple les services de réception des déclarations du secteur privé, ainsi que la possibilité de les modifier et de les corriger.

Dans un second temps, les différentes règles opérationnelles applicables à une procédure ou à un processus pourraient elles aussi devenir des services. Les règles opérationnelles sont des directives qui définissent (ou restreignent) les activités métier et jettent les bases des systèmes d’automatisation en prenant des informations documentées ou non et en les traduisant en divers énoncés conditionnels. Les autorités de régulation définissent non seulement les données requises, mais aussi un ensemble de règles opérationnelles applicables à ces données. Ces règles vont des contrôles concernant l’information à la vérification de la codification valable des données, en passant par des règles de configuration, par exemple la configuration permettant à un texte d’être reconnu comme courrier électronique valable. Un module d’évaluation des risques peut ainsi être considéré comme un service qui renvoie une valeur de risque pour une transaction.

Ces règles pourraient compléter le MDI, voire en faire partie, ce qui permettrait à quiconque doit soumettre une déclaration d’être au fait des données requises et des règles correspondantes. L’intégration des règles dans le Modèle de données de l’OMD permettrait d’atteindre un nouveau niveau d’harmonisation et de renforcer la coopération entre les organismes de réglementation. Cela ferait du Modèle de données de l’OMD une spécification de services SOA à des fins réglementaires transfrontalières. Nous croyons fermement que c’est là que réside l’avenir du Modèle.

En savoir +
info@customs-hub.com

[1] Voir l’article dans OMD Actu https://mag.wcoomd.org/fr/magazine/wco-news-97-issue-1-2022/making-digital-collaboration-possible-the-wco-data-model/

[2] Idem