Inter-connexion des services

Inter-connexion des services

Interconnexion des applications Nous abordons la question de l’inter-connexion des applications internes et externes au service collaboratif, à travers quatre problématiques technologiques fondamentales : — La scalabilité de la solution de traçabilité, — L’inter-connection des applications pour la traçabilité en réseau des marchandises, — La sécurisation et la confidentialité, — L’exploitation du réseau de données et sa gouvernance.

Scalabilité de la solution de traçabilité

Le caractère générique de notre approche signifie que l’on vise ici, au-delà du cas d’étude, à étendre le dispositif à d’autres assets logistiques (emballages réutilisables, véhicules, sites) et aux marchandises contenues. En termes d’architecture de solutions EPC, certaines solutions peuvent se baser sur des principes de distributions exposés par [Gautier, 2007]. Les objets communicants peuvent en effet entrer directement en relation directe avec les opérateurs de terrain, sans forcement nécessiter un traitement et une validation par le pilote de l’ensemble des flux. A ce titre, l’expérimentation nous montre que le moteur de données OTC peut aussi être implémenté localement, à petite échelle, chez un prestataire, connecté directement aux données (locales) de son EPCIS et fournir un premier niveau de service à l’échelle d’une entreprise donnée, comme nous l’avons schématisé sur la figure 101. Nos choix de configuration de l’expérimentation OTC concourent à cette ouverture, et ce déploiement à petite et grande échelle : les développements sont basés sur des modules Open Source (Fosstrack) , la mise en œuvre de standards industriels, l’utilisation de matériel de capture est non spécifique et économiquement abordable (smartphones Android), le produit-service est composé d’un parc d’emballages réutilisables partagé entre acteurs des produits de grande consommation. La palette OTC-Kaypal(r) MR fait ainsi figure de palette “augmentée”, parce que porteuse d’un tag RFID et de fonctionnalités dépassant son statut classique de support logistique. En termes architecturaux, ces résultats proposent différentes alternatives d’emploi des bases de données standardisées :

Mode classique : l’entreprise emploie cette technologie pour un usage interne, le plus souvent au sein d’un entrepôt Exemple : Suivi du stock d’un entrepôt de palette, Traçabilité des flux d’entrée/sortie d’une plateforme logistique. Dans ce cas, les données sont principalement exploitées dans une seule entreprise, sans diffusion au delà. Une seule base suffit amplement à stocker et contrôler la diffusion 2

2. Une Traçabilité étendue mais dédié à une seule offre de service Exemple : Suivi des flux de palettes autour d’une plateforme de groupage/dégroupage du fournisseur amont, aux clients distributeurs et aux tournées de livraisons aval. Fonction d’alertes sur litiges marchandises et opérations de transport, Ouverture du service de traçabilité aux clients et prestataires afin de leur apporter la visibilité sur les flux de produits et leurs prestations logistiques

3. Traçabilité étendue, multi-services Exemple : Suivi du transit douanier de conteneurs maritimes : suivi mise à la consommation et transit terrestre Commerciales : suivi des commandes depuis le port de départ, Logistique : favoriser le report modal, Infrastructures : disponibilité des places à quai. Technologie support : un à plusieurs EPCIS en fonction des liens institutionnels et la complexité de l’acheminement

Interconnexion et traçabilité des marchandises

A terme, comme nous l’avons souligné précédemment, la connexion de l’application de traçabilité avec les applications actuelles du monde du transport et de la logistique est inévitable, que ce soit en import, ou en export de données. Après avoir conçu et testé le dispositif OTC isolément, dans une configuration autonome (“stand alone”), la condition 237 Chapitre 8. Inter-connexion des services Applications clientes de la prestation numérique (collaborative ou strictement contractuelle) Applications externes : Clients industriels du service logistique collaboratif et/ou Clients de clients : distributeurs destinataires des marchandises et de leurs contenants (palettes, conteneurs maritimes, caisses mobiles) ou Prestataires logistiques 3PL de ces derniers Applications externes de la prestation logistique collaborative : Partenaires 2/3 PL transporteurs, plateformes logistiques, Applications clientes internes ; pilotage de flux, simulation, routage, gestion commerciale Intranet Prestataire Numérique/Logistique ou Interface externe au SI : API, Connecteur EPC, Export fichiers, BlockChain Moteur de données EPC/OTC, pseudo-Discovery Service Internet Interface Query Réseau de bases EPCIS Internet Réseaux du point de capture (Wi-Fi, intranet, GSM) Lecteur EPC Unité logistique « connectée » Figure 102 – Degré d’inter-connexion et d’imbrication ex-centrique des systèmes d’informations : internes, externes et des prestations logistiques et numériques et les moyens d’inter-opérabilité de cette solution vis-à-vis des systèmes d’informations internes (service) et externes (clients), se posent. Dans un premier temps, l’expérimentation de ce système ne nécessite pas d’interconnexion avec les systèmes d’informations propres à chaque acteur 1 . Ces systèmes d’information sont le plus souvent de type propriétaire, c’est-à-dire développés pour servir un besoin particulier, selon une approche technique spécifique, et ne sont donc généralement pas basés sur les standards EPCGlobal Comme le montre la figure 102, illustrant l’encastrement des SI et des prestations, l’indépendance de ce système vis-à-vis des systèmes d’informations en place n’est néanmoins pas totale puisque que, comme notre Cas 2 l’a montré, lors d’un déploiement du dispositif OTC à l’échelle industrielle, nous dépendons d’une part de leurs données d’entrée (input) et, d’autre part, nous cherchons, “en sortie”, à alimenter ces applications « métier » (outputs). Cette représentation souligne également les différents réseaux et interfaces mobilisés, suivant l’échelle à laquelle nous déployons le système d’information et les services numériques. La question de l’interfaçage entre ces éléments fait donc partie des futurs défis technologiques à relever pour exploiter au mieux le dispositif OTC et tester sa valeur ajoutée au systèmes en place. Le second cas d’application Cas 2, analysé dans le chapitre 5, renforce la conviction d’une nécessaire combinaison et convergence des systèmes d’information événementiels et transactionnels, basés sur les réseaux EPC et EDI. À terme, un tel système exploitera les données de traçabilité les plus basiques possibles, sans mention préalable d’un code de site 2 , et se contentant d’une position géographique 3 de l’objet au temps “t”. 2ème itération OTC-Kaypal!R MR : traçabilité des marchandises Pour répondre à cette problématique d’interfaçage entre applications logistiques, à l’issue de l’expérimentation sur le parc Kaypal!R MR, nous avons testé la traçabilité des marchandises associées aux supports carton intercalaires (figure 103). Les palettes hétérogènes marchandise+support sont tracées par le type de code EPCGlobal dédié à la traçabilité de ces marchandises : le SSCC (Serial Shipping Container Code). Le modèle de traçabilité des marchandises diffère du modèle classique; en utilisant les traces des supports, nous traçons indirectement la marchandise par association contenant-contenu. Cela dispense l’industriel de marquer unitairement en RFID chaque colis. Les données de traçabilité contenant-contenu étant distribuées et disponibles sur ce réseau de bases de données, le système de traçabilité opère alors en réseau, et non en cascade : l’information de traçabilité relative à chaque partie de la chaîne de responsabilité est directement accessible par tout un chacun (figure 104) sur les bases de données du réseau. Cet accès facilité aux informations évite une succession d’intermédiaires organisés en chaine de traitement, ce qui accélère d’autant le traitement d’une alerte, du retrait d’un lot donné : ce nouveau mode facilite l’accès et permet de localiser et traiter, plus finement et plus rapidement, le lot incriminé. Cet accès direct à l’information limite le nombre d’intermédiaires et le risque de ne pas avoir accès à l’information à temps ou que l’un de ces intermédiaires fasse défaut. Ce démonstrateur valide également une double utilisation des données de traça2. De lecture, de provenance, de destination 3. Transmise par les réseaux GPS ou LoRa contenant-contenu en réseau bilité logistique par deux services connectés au réseau commun : il permet d’exploiter à deux niveaux une même donnée, lui donnant à la fois un sens «palette support“ et un sens ”palette de marchandises » dans la deuxième application.

Sécurisation et confidentialité

Cette ouverture du système d’information a pour corollaire l’obligation de sécuriser les échanges de données aux interfaces de ce système. Même si une seule base EPCIS est implémentée, et que cette dernière n’est connectée qu’à un seul tableau de bord ne servant d’un seul type d’application, ces échanges utilisent Internet et sont donc exposés aux risques sécuritaires de ce réseau public. Au cours de nos deux expérimentations, nous avons été exposés à ces intrusions sur les bases EPCIS. La question de la sécurisation des données s’étudie à deux niveaux : les modalités de contrôle d’accès et leur impact sur la performance.

Contrôle d’accès

Rappel : la mutualisation des lectures se réalise en équipant les transporteurs, multipliant ainsi les point de lectures. Nous avons équipé les transporteurs chargés de collecter les palettes sur plusieurs sites distributeurs. Cela nous dispense à la fois d’équiper et de former les sites distributeurs et permet de lire plusieurs points de collecte à l’aide d’un même matériel. Si les transporteurs sont déjà équipés (smartphones Android), le pilote de flux 4PL est dispensé de fournir le matériel à ses prestataires de transport, conformément à l’approche collaborative que cette entreprise promeut. . Bien que chaque membre de la chaîne logistique contribue aux publications évènementielles sur les bases, tous ne disposent pas, en retour, de droits d’accès égaux à ces données : suivant que l’on cherche à construire un système de traçabilité en réseau vraiment ouvert ou plus fermé, différentes modalités de gestion des droits d’accès sont envisageables.