En ce moment, la Commission européenne fait appel à des alchimistes qui transforment la chape de plomb de la réglementation eFTI en un écosystème de plus en plus palpable - l'histoire ne dit pas encore si de l'or est en jeu, certaines prophéties énoncent 27 Mds d'€ d'économie dans les 20 prochaines années. Circle et RINA s'attellent aux spécifications fonctionnelles de l'écosystème eFTI.

‍

‍

Des travaux définition d'architecture informatique et de process sont en cours pour détailler précisément les fonctions à remplir par l'écosystème eFTI, qui s'y connectera, comment et pour mener quelles actions. Plusieurs possibilités coexistent et le DTLF travaille aujourd'hui à analyse les avantages et les inconvénients de chaque alternative pour trancher, décider, entériner, décréter, bref, faire avancer le schmilblick et surtout assumer ces choix techniques devant des hordes de transitaires enragés à l'idée qu'on bouge les lignes.

‍

‍

Circle est une entreprise italienne créée en 2012 qui a notamment développé MILOS (Making International Logistics Optimization Simple), un écosystème d'applications de tracking, de planification et d'automatisation sur l'ensemble de la chaîne logistique (TOS, GOS, PCS, Customs Registers). Circle fournit également des prestations de conseil en solutions digitales ou en appel d'offres aux projets de l'UE et anime une plateforme d'échanges sur les Motorways of the sea (Si les Motorways of the sea vous font plus penser à Kevin Costner en guenilles qu'au livre blanc de la Commission en 2001, reprenez une tranche de TEN-T) . Et puisque la patrie de Vivaldi et d'Ennio Morriconne montre la voie de la fraternité entre les peuples dans sa vidéo de présentation de MILOS, offrez-vous un intermède Tchaïkovski entre deux gorgées d'IoT.

Quant à RINA (Registro Italiano Navale), c'est à l'origine (160 ans en arrière) une fondation membre de l'IACS qui délivre des certificats de classe de navires mais qui fournit aujourd'hui des services dans des domaines plus étendus que le transport tout en contribuant à l'élaboration de textes réglementaires.

Tout est en construction, une grande partie de tout ce qui vient existe pour l'heure essentiellement sur papier (hors pilot sites, living labs et autres POC qui se frottent à tout ou partie de la problématique). L'enjeu du document résumé est de se projeter dans le fonctionnement de l'écosystème eFTI, identifier les fonctionnalités essentielles, celles aux contours encore flous, jauger la complexité de l'ensemble, et présenter les différentes alternatives pour la minimiser autant que possible. Les solutions décrites ici ne sont à ce stade que des propositions, et rien n'est entériné.

‍

‍

Pour les lignes directrices, la S01E01 est là pour vous. À présent, le principe c'est surtout de garder en tête que le jargon eFTI qui, tapi dans chaque buisson conceptuel, peut surgir à tout moment, sans pitié. Le cas échéant, sortez votre glossaire, compulsez-le frénétiquement ou utilisez la barre de recherche idoine, et offrez la définition à vos angoisses lexicales comme on jette une gousse d'ail à un vampire trop entreprenant.

On utilisera indifféremment eFTI dataset ou données eFTI pour désigner la même chose, à savoir une "propriété" en jeu dans le transport d'une marchandise. Il est à noter que ce concept de donnée eFTI est en cours de définition par le DTLF. Une donnée eFTI peut représenter aussi bien :

• Un Transitaire (avec son nom, un identifiant, une adresse, un site internet).
• Un moyen de transport (un navire et son code Lloyd, un avion et son poids à vide, un train et son système de freinage).
• Une marchandise (son libellé, son HS code, son code IMDG le cas échéant…).
• Un port (sa ville, son code UNLOC, son rôle - est-il un port de déchargement, chargement, transbordement ?).
• Un événement (un déchargement ? Un chargement ? Stuffing ? Unstuffing ? Un accostage ? Quand ?).
  L'un des enjeux en cours mais dont on ne parle pas ici par manque d'élément, c'est de savoir comment on découpe toutes ces données, comment on les relie d'un point de vue du modèle de données eFTI. Si une marchandise possède plusieurs codes IMDG, comment on gère ? Si le contenu d'un container concerne plusieurs transitaires, plusieurs réceptionnaires, plusieurs expéditeurs, comment on articule ces différentes informations ?

À ce sujet, FEDeRATED a publié leur modèle sémantique/ontologique. C'est un peu austère mais ça permet de visualiser comment s'articulent les différents objets qu'on pourrait (au conditionnel, ce modèle-ci ne fait pas foi en matière d'eFTI à ce stade) manipuler sur les plateformes eFTI.

‍

‍

Acteur éco, autorité compétente, points d'accès

Prenons un acteur économique, que l'on appellera Bernard, et une autorité compétente, que l'on appellera Corine. Bernard utilisera une plateforme eFTI pour mettre à disposition les informations requises par Corine. Corinne utilisera un autre système pour traiter les données de Bernard : un Point d'accès (AP - Access point), éventuellement connecté à un Point d'accès national (NAP - National access point). Pour savoir que Bernard est bien Bernard il nous faut des mécanismes d'authentification. Pour savoir que Corine a le droit de tamponner le document, il nous faut des mécanismes d'autorisation.

Le cœur de la matrice, ce sont les plateformes eFTI. Tout y est stocké, tracé et modifié. Les points d'accès ne sont "que" des intermédiaires pour faciliter l'accès de Corine à l'ensemble des plateformes eFTI. Bernard parle à sa plateforme eFTI, Corine parle à son point d'accès, qui parle au point d'accès national. Comme il existera une constellation de plateformes eFTI, il faudra en premier lieu qu'une habile machinerie permette à Corine de localiser sur quelle plateforme eFTI se trouvent les données de Bernard. C'est le NAP qui recense et communique avec toutes les plateformes eFTI certifiées (Alerte rouge, la certification est le fil d'une pelote qu'on n'a pas fini de dérouler. Rendez-vous au prochain épisode.) par l'UE.

Quand on parle de données ou d'informations eFTI "eFTI dataset"), on en parle relativement au transport d'une marchandise d'un point A à un point B par l'intermédiaire d'un contrat. Dans les cas courants, qui courent plutôt les rues en anglais, un eFTI dataset désignera soit des informations liées au transport ("shipment"), soit à la marchandise ("good"). Pour localiser la donnée eFTI dans l'écosystème, selon le souhait de Corine, on dote chaque shipment d'un identifiant unique et c'est cet identifiant que le point d'accès utilise pour interroger les plateformes eFTI. Conséquence immédiate, lourde et implacable : pour une marchandise en transit, il se peut que les données de transport soient hébergées sur une plateforme A et les données de marchandises sur une plateforme B.

Si vous vous dites qu'il "faut revenir aux Mérovingiens pour retrouver galimatias aussi rebutant que [ces gaudrioles]", abandonnez tout de suite. Abandonnons les spécifications de l'eFTI si "300 pages pour nous faire comprendre que Tutur [enfile] Tatave c'est trop" (Authentique citation de Céline, un brin édulcorée pour l'occasion). Abandonnons les specs eFTI mais aussi l'idée de nous révolter une fois que l'écosystème sera en place. Et estimons-nous heureux, car le temps des brochures ARPANET est révolu, aujourd'hui tout est plus beau.

‍

Piment brûle mais asticot vit dedans. Proverbe ivoirien

‍

Quelle forme vont prendre les Points d'accès ? Quelle forme pour les Points d'accès nationaux ? Les Autorités compétentes vont-elles partager les Points d'accès ou chaque Autorité compétente disposera-t-elle de son propre Point d'accès ? Ce sont des questions qu'il n'est pas encore possible de résoudre et qui seront au cœur de l'implémentation de l'infrastructure informatique de demain. Un autre pan de gestion constitue l'identité des organismes qui certifieront et adouberont les nouveaux Points d'accès et Points d'accès nationaux et où sera stocké le certificat.

‍

NAP & certificats

‍

Oui je sais je suis paranoïaque, mais ce n’est pas parce que je suis paranoïaque qu'ils ne sont pas tous après moi. Pierre Descodes face à une avalanche d'eFTI

‍

S'ils ajoutent un intermédiaire de plus dans la chaîne eFTI, les Points d'accès nationaux ont plusieurs intérêts. Il connaît toutes les Plateformes eFTI et leurs certificats publics et peut communiquer facilement avec elles. Il connaît tous les Points d'accès qui dépendent de lui et leurs certificats publics. Conclusion, en étant à la croisée des chemins :

• Il peut servir de routeurs entre la constellation de Plateformes eFTI (gérées par des acteurs privés, donc qui vivront potentiellement sa vie indépendamment des états) et la constellation d'Autorités compétentes (gérées par les états mais spécifiques à chaque état).
• Il peut stopper les demandes erronées (e.g. certificat invalide) d'une constellation avant qu'elle ne vienne polluer l'autre constellation.
• Il peut garantir l'intégrité de la donnée via des mécanismes de cryptographie (qui utilisent les certificats susmentionnés).
  Pas d'entourloupe sur les cryptochats, on est ici dans un contexte de "Public-key cryptography" ou cryptographie asymétrique, mécanisme antédiluvien (1976) permet notamment à deux interlocuteurs de garantir la confidentialité de leur échange. Par exemple une plateforme eFTI communique avec le NAP en encodant le message via la clé publique (i.e. accessible et connue de tous) du NAP, et le NAP décode le message avec une clé privée (i.e. connue du NAP uniquement). Même si un tiers intercepte le message entre la Plateforme eFTI et le NAP, il aura entre les mains un galimatias autrement plus retors que les spécifications de l'architecture fonctionnelle de l'eFTI et ne pourra pas décoder le contenu sans la clé privée du NAP.

‍

Mécanisme d'authentification & d'autorisation

C'est le Point d'accès ou le Point d'accès national qui intégrera ce mécanisme. Dès qu'une Autorité compétente se connecte à une Plateforme eFTI, on lui alloue un token (jeton) qui l'identifie et lui donne l'accès pour une durée déterminée, le tout sur fond de mécanisme de cryptographie, cette fois le NAP encode avec la clé publique de la Plateforme eFTI qui décode avec sa clé privée. D'où, une fois de plus, l'intérêt d'agréger le transit des connexions dans les NAP pour limiter in fine le nombre d'acteurs en jeu sur les aspects sécuritaires.

Le mécanisme d'authentification permet de sécuriser la phase de connexion à l'écosystème, le mécanisme d'autorisation permet de définir ce que chacun peut ou ne peut pas faire au sein de l'écosystème. Pour chaque shipment, tout utilisateur (Acteur économique, Autorité compétente) aura un ou plusieurs rôles. Le rôle permet ou non de lire et d'éditer un shipment, et à quelles données on a accès (eFTI data, eFTI dataset). En tant qu'Acteur économique, je peux avoir le droit d'éditer une date de déchargement d'un container sans pour autant être autorisé à consulter la marchandise à l'intérieur. Par défaut, l'Autorité compétente aura un accès en lecture au shipment, mais le contenu des données consultables est à la main du propriétaire du shipment.

C'est uniquement le propriétaire du shipment qui attribue les rôles et peut les modifier à tout moment. Autrement dit, si je ne suis pas propriétaire d'un shipment et que je peux faire des actions dessus à un instant T, il se peut que je ne puisse rien faire quelques instants plus tard si je ne suis plus concerné par ce shipment. Pour pimenter, le propriétaire peut décider de donner une délégation à un tiers, ce tiers pourra donc créer et éditer de la donnée pour le compte d'un autre.

En complément de ces deux mécanismes qui remplissent le cahier des charges de la régulation eFTI, un troisième mécanisme est envisagé pour des questions de performance : la notification de mise à jour. Pour éviter que tous les acteurs se connectent à de multiples reprises sur la Plateforme eFTI pour connaître le statut d'un shipment, un système de notifications au sein de la plateforme eFTI informera les tiers concernés lorsqu'un événement vient faire avancer le shipment dans la chaîne (e.g. des informations de cabotage additionnelles).

‍

Mécanisme de "découverte"

Pendant nos digressions, Corine cherche toujours le shipment de Bernard. Pour ça, on envisage deux solutions pour l'implémentation de l'identifiant unique :

• L'URL (Uniform Resource Locator) qui porte bien son nom
• L'UUID (Universally Unique Identifier) qui le porte somme toute assez bien lui aussi

‍

URL

Concrètement, si on utilise un URL, on va manipuler ce genre de chaîne de caractères : https://www.IT-HHJUO-12.efti.eu/045484cc-9e15-11ec-b909-0242ac120002/[Consignee]

Si tout est en place et que :

• Je suis enregistré sur la plateforme eFTI IT-HHJUO-12
• Je suis autorisé à consulter (éventuellement éditer) le shipment qui a pour identifiant 045484cc-9e15-11ec-b909-0242ac120002
  Alors je peux consulter le service à cette adresse qui me renverra par exemple (exemple totalement fictif qui ne suit aucune spécification).

‍

{
   "economic-operator": {
       "type": "Consignee"
       "id": "1234589-87",
       "name": "Jean-Jacques Codeman",
       "address": {
           "country": "FR",
           "city": "Trouville",
           "street": "Rue Saint Paul de Métatarse"
       }
   }
}

‍

Ce qui me permet informatiquement de manipuler pour m'enrichir (moi et mes systèmes d'information) ou enrichir la chaîne d'information en aval de ma position.

Ce mécanisme repose sur le mécanisme qui fait tourner les "adresses internets" depuis fort longtemps, c'est donc robuste, économique et facile d'implémentation. Un DNS, et roulez jeunesse. La faiblesse la plus saillante vient du fait que si une plateforme eFTI change d'identifiant - "Souvent, plateforme varie" nous dit le dicton -, l'URL change et les URL antérieurs sont caducs.

‍

UUID

Le principe est assez similaire. Une première différence : un URL est global et un UUID local. Autrement dit, on est assuré qu'un URL est unique à l'échelle du web, tandis que 2 UUID peuvent exister pour désigner 2 objets différents (bien que la nomenclature des UUID rende cette éventualité peu probable, mais les circonstances qui ont mené à l'accident de Fukushima étaient elles aussi peu probables). La deuxième différence, plus structurante et qui découle de l'aspect local de l'UUID, c'est qu'il faut que chaque plateforme eFTI mette à jour un registre avec les UUID de tous les eFTI datasets qu'elle contient pour créer le référentiel des UUID. A priori, c'est une solution plus fastidieuse à mettre en place. Et des registres, il y en a déjà d'autres en jeu (voir tout de suite).

‍

Registres des certificats des Points d'accès

Deux possibilités se présentent pour gérer les certificats/clés publics des Points d'accès (sous-entendu pour contrôler la validité des Points d'accès à tout moment) :

• Registre des certificats des Points d'accès : Un outil supplémentaire servira de registre centralisé - donc potentiellement un point de faiblesse isolé dans l'écosystème - où les Points d'accès nationaux - où d'autres outils à terme - pourront vérifier que le Point d'accès est correctement référencé et certifié.
• Interconnexion des Points d'accès nationaux : Pas de registre supplémentaire cette fois. Chaque Point d'accès national encode les certificats des Point d'accès qui dépendent de lui, et chaque Point d'accès national connaît les clés publiques des autres Points d'accès nationaux. Ce qui sous-tend qu'à un moment donné du process, le Point d'accès national que le certificat du Point d'accès a été émis par un Point d'accès national certifié. Le certificateur aussi doit être certifié, après tout…

‍

‍

Voici une liste informative et laconique des actions qui seront le cœur de l'écosystème eFTI et du quotidien des acteurs de la chaîne. Chaque action une description conséquente pour prendre la mesure de toutes les étapes, mécanismes et intervenants en jeu. Gageons que ce sera l'objet du prochain épisode.

• Pour les opérateurs économiques :
• Connexion à une plateforme eFTI : L'étape primordiale.
• Création d'une donnée eFTI : L'action qui fait de lui le propriétaire de la donnée (dataholder).
• Liaison de deux données eFTI : Quand deux eFTI datasets ont des interactions, on sera amené à créer une liaison entre les deux (et pas forcément sur la même plateforme eFTI !).
• Modification d'une donnée eFTI (Donnée directe ou donnée liée) : C'est là tout l'intérêt de l'écosystème eFTI - Les données VIVENT !
• Pour les autorités compétentes :
• Accès à une donnée eFTI (avec ou sans Point d'accès) : Valeur ajoutée si elle en est de la dématérialisation → Tout est disponible depuis un PC.
• Requête de métadonnée eFTI : Par exemple nature du shipment dans un camion à partir de la plaque d'immatriculation du camion → Ça évite de stopper le camion.
• Pour les deux :
• Notification de modification d'une donnée eFTI : Informer le tiers que ça intéresse que le transport progresse ou que les formalités avancent sans qu'il ait à rafraîchir sa page web lui-même.

‍

‍

Pour orchestrer le tout, le champ des possibles est ouvert aux quatre vents et la multiplicité des cas d'usage et des situations obligent à tout recenser pour vérifier la viabilité de l'écosystème en toutes circonstances, et surtout en cas d'exceptions.

Quand on parle de cas d'usage, on peut travailler avec trois variations :
- Marchandise unique, expéditeur unique
- Marchandises multiples, expéditeur unique
- Marchandise multiple, expéditeurs multiples

Les variations en termes d'infrastructure peuvent se décliner en 5 scénarios, chacun permettant de mener à bien une des actions possibles au sein de l'écosystème eFTI, mais pas forcément dans toutes les configurations qui sont autant d'hypothèses de travail qu'il faudra un jour figer (URL ou UUID ? Existence d'un NAP ou pas ?) :

• Scénario 1 : NAP with Pull from CA → Cas "classique" où l'Autorité compétente passe par un NAP relié au Mécanisme de recherche (serveur DNS) afin de récupérer une donnée eFTI auprès d'une plateforme eFTI.
• Scénario 2 : NAP with Push metadata → Configuration dans laquelle les plateformes eFTI viennent alimenter (pousser) des métadonnées (plaque d'immatriculation d'un camion, cas du transport de matière dangereuse ou de déchets) au sein des NAP pour permettre par exemple des recherches génériques de la part d'une Autorité compétente pour un contrôle ou pour des pompiers en cas d'urgence.
• Scénario 3 : No access point → Pas d'AP, pas de NAP, autrement dit les Autorités compétentes doivent s'authentifier directement sur chaque plateforme eFTI et chaque plateforme eFTI devra régulièrement vérifier les mises à jour des données eFTI d'autres plateformes eFTI liées à ses propres données eFTI.
• Scénario 4 : NAP and Update dispatch mechanism → Scénario 1 auquel on ajoute le mécanisme de notification de mise à jour.
• Scénario 5 : Share encrypt eFTI dataset → Une configuration où l'on s'appuie sur le mécanisme de notification de mise à jour et le chiffrement des données eFTI pour que chaque plateforme héberge toutes les données eFTI qui la concernent (sous formé chiffrés pour les données eFTI liées qui proviennent d'une autre plateforme).

‍

‍

On est en pleins travaux et en plein cœur d'un travail difficile de discernement et de choix techniques. Sans boule de cristal, il faut au DTLF se convaincre, puis convaincre la communauté logistique, des meilleures solutions à adopter à une échelle incommensurable puisque c'est celle de l'Union européenne. Dans cette tâche vertigineuse, il est précieux et crucial de disposer d'initiatives telles que FEDeRATED et FENIX. Ce sont des opportunités pour alimenter la réflexion, donner corps aux idées et confronter les réponses imaginées pour combler le saint eFTI et ses exigences.