FR 3151685 A1 20250131 FR 2307925 A 20230724 Procédé et système de contrôle de la livraison d’une marchandise Ce procédé est mis en œuvre par un système de contrôle (KX) et comporte: - l’enregistrement (E10) d’ un utilisateur (EXP-MGR) auprès d’un module de gestion d’accès (MODS GA ) et la fourniture (8) de moyens d’authentification (TOK EM ) à un poste de travail (PC EXPM ) dudit au moins un utilisateur (EXP-MGR) ; - le téléchargement (E30) d’un fichier de configuration (F CONF ) de la livraison comportant des informations sur au moins une opération devant se dérouler au cours de ladite livraison ; - l’enregistrement (E40) d’un résultat d’une opération dans une base de données de visibilité de la livraison (BD VIS ) sur requête (18, 21) d’un utilisateur ; - l’enregistrement (E90) d’au moins une transaction représentative de ladite au moins une opération et d’une signature de ladite transaction dans une base de données d’audit immuable et vérifiable (BD AUD ), ladite signature étant effectuée en utilisant une clé privée dudit système (KX). Fig 1. Procédé et système de contrôle de la livraison d’une marchandise Domaine de l’invention La présente invention se situe dans le domaine du contrôle d’un flux logistique, et plus particulièrement de la livraison d’une marchandise. Elle s’applique en particulier mais de façon non limitative au contrôle ou à la surveillance d’un processus de livraison de médicaments. Etat de la technique antétrieure Les flux logistiques et en particulier la livraison de médicaments sont des processus complexes. Ils font généralement intervenir plusieurs entités, typiquement au moins un expéditeur des marchandises, au moins un prestataire de logistique, par exemple un transporteur et un client destinataire des marchandises. Le flux logistique peut logiquement être décomposé en un certain nombres d’opérations, par exemple des opérations d’emballage des marchandises, des opérations de transport des marchandises, des opérations administratives, par exemples douanières, par exemple de fourniture de certificats de conformité. Le flux logistique doit aussi parfois s’effectuer dans le respect de conditions de livraison, par exemple de localisation de la marchandise, de température ou d’humidité pour la bonne conservation des marchandises, ... Il existe un besoin général de permettre, au fur et à mesure du déroulement de la livraison, voire ultérieurement, à des personnes autorisées mais de façon confidentielle, d’obtenir une bonne visibilité sur les différentes opérations, conditions et événements produits pendant la livraison. Il n’existe pas de système satisfaisant à ce jour. Objet et résumé de l’invention Ainsi, l’invention propose un procédé de contrôle de la livraison d’une marchandise, ledit procédé étant mis en œuvre par un système de contrôle et comportant: - une étape d’enregistrement d’au moins un utilisateur auprès d’un module de gestion d’accès dudit système de contrôle et de fourniture de moyens d’authentification à un poste de travail dudit au moins un utilisateur ; - une étape de téléchargement, depuis le poste de travail d’un dit utilisateur, d’un fichier de configuration de la livraison, ce fichier comportant des informations sur au moins une opération devant se dérouler au cours de ladite livraison, ledit téléchargement étant conditionné par une authentification dudit utilisateur à partir dudit moyen d’authentification fourni à cet utilisateur et par la vérification d’un droit de cet utilisateur à effectuer ledit téléchargement au vu d’un rôle de l’utilisateur et de ses droits conformément à une politique de sécurité ; - une étape d’enregistrement d’un résultat d’au moins une dite opération dans une base de données de visibilité de la livraison sur requête d’un utilisateur, ledit enregistrement étant conditionné par une authentification dudit utilisateur et par la vérification d’un droit de cet utilisateur à formuler ladite requête au vu d’un rôle de l’utilisateur et de ses droits conformément à ladite politique de sécurité ; et - une étape d’enregistrement d’au moins une transaction représentative de ladite au moins une opération et d’une signature de ladite transaction dans une base de données d’audit immuable et vérifiable, ladite signature étant effectuée en utilisant une clé privée dudit système. Corrélativement, l’invention concerne un système de contrôle de la livraison d’une marchandise, ce système comportant: - un module de gestion d’accès configuré pour enregistrer au moins un utilisateur et pour fournir des moyens d’authentification à un poste de travail dudit au moins un utilisateur ; - un module de téléchargement, depuis le poste de travail d’un dit utilisateur d’un fichier de configuration de la livraison, ce fichier comportant des informations sur au moins une opération devant se dérouler au cours de ladite livraison, ledit téléchargement étant conditionné par : (i) une authentification dudit utilisateur par ledit module de gestion d’accès à partir dudit moyen d’authentification fourni à cet utilisateur et par (ii) la vérification, par un module d’application d’une politique de sécurité, d’un droit de cet utilisateur à effectuer ledit téléchargement au vu d’un rôle de l’utilisateur et de ses droits conformément à ladite politique de sécurité ; - un module de gestion de la visibilité de la livraison configuré pour enregistrer un résultat d’au moins une dite opération dans une base de données de visibilité de la livraison sur requête d’un utilisateur, ledit enregistrement étant conditionné par : (i) l’authentification dudit utilisateur par ledit module de gestion d’accès et par (ii) la vérification, par un module d’application d’une politique de sécurité, d’un droit de cet utilisateur à formuler ladite requête au vu d’un rôle de l’utilisateur et de ses droits conformément à ladite politique de sécurité ; - ledit module de gestion de la visibilité étant configuré pour enregistrer au moins une transaction représentative de ladite au moins une opération et une signature de ladite transaction dans une base de données d’audit immuable et vérifiable, ladite signature étant effectuée en utilisant une clé privée dudit système. Ainsi, et d’une façon générale, l’invention propose un procédé et un système de contrôle d’une livraison d’une marchandise, ce procédé et ce système offrant la possibilité, à des personnes autorisées, d'accéder et de surveiller des données et des états relatifs à des opérations critiques du processus de livraison. En effet, dans un mode de réalisation, le procédé selon l’invention comporte, sur requête d’un utilisateur, une étape d’interrogation de la base de données de visibilité, cette interrogation étant conditionnée par une authentification de cet utilisateur et par la vérification d’un droit de cet utilisateur à formuler cette requête au vu d’un rôle de l’utilisateur et de ses droits conformément à ladite politique de sécurité. L’invention propose de définir les opérations et les conditions de la livraison dans un fichier de configuration et de contrôler que ce fichier de configuration est effectivement téléchargé par une personne authentifiée et autorisée. Ainsi, le téléchargement et toute accès subséquent au système selon l’invention par un utilisateur, en lecture et en écriture ne peut se faire que par des utilisateurs authentifiés et dans le respect d’une politique de sécurité. Dans un mode de réalisation de l’invention, la politique de sécurité est conforme au modèle ABAC. On rappelle qu’une politique ABAC (en anglais « Attributs-Based Access Control ») est un modèle de contrôle d'accès qui utilise les attributs des utilisateurs, des ressources et des conditions pour déterminer si un utilisateur est autorisé à accéder à une ressource donnée. Par ailleurs, et de façon très avantageuse, l’invention propose, pour chaque opération enregistrée dans la base de données de visibilité d’enregistrer une transaction correspondante et la signature de cette transaction dans une autre base de données, celle-ci étant immuable et infalsifiable. De façon très avantageuse, les signatures sont toutes générées en utilisant une clé privée nt secrète, du système de contrôle de livraison. - ledit module de gestion de la visibilité étant configuré pour enregistrer au moins une transaction représentative de ladite au moins une opération et une signature de ladite transaction dans une base de données d’audit immuable et vérifiable, ladite signature étant effectuée en utilisant une clé privée dudit système. Cette base de données immuable et vérifiable peut être une chaîne de blocs. Cette base de données peut être qualifiée de base de données d’audit car elle permet ultérieurement de prendre connaissance de l’ensembles des opérations et des événements pertinents produits au cours de la livraison. Dans un mode de réalisation du procédé de contrôle, le fichier de configuration comporte au moins certaines informations parmi : - des informations sur des données à saisir et sur les personnes autorisées à effectuer une telle saisie; - des informations sur au moins une étape de transport de la marchandise; - des informations sur au moins un document à télécharge et sur les personnes autorisées à effectuer ce téléchargement ; -des conditions de ladite livraison. Conformément à un mode particulier de réalisation de l’invention, en plus des utilisateurs autorisés, des objets connectés peuvent accéder en écriture et/ou en lecture au système de contrôle de livraison, dès lors que ces objets ont été spécifiquement référencés dans le système par un utilisateur authentifié et ayant des droits pour le faire. Ainsi, dans un mode de réalisation, des données saisies par une personne autorisée comportent un identifiant d’un objet connecté configuré pour mesurer des données représentant des conditions de livraison de ladite marchandise, le procédé comportant : - une étape d’obtention, par l’objet connecté, de mesures de données représentant des conditions de livraison ,et d’enregistrement de ces mesures dans une base de données de conditions de livraison; - une étape d’enregistrement d’au moins une transaction représentative desdites mesures et d’une signature de ladite transaction dans la base de données d’audit immuable et vérifiable, ladite signature étant effectuée en utilisant la clé privée dudit système ; et - si ces mesures ne sont pas conformes aux conditions de ladite livraison, une étape d’enregistrement de ces mesures dans une base de données d’exception. Cette caractéristique permet avantageusement de mesurer en temps réel les conditions de la livraison (localisation, température, humidité, chocs, luminosité ou autre), par exemple en fixant sur la marchandise un objet connecté déclaré dans le système. Chaque mesure fait l’objet d’une transaction, enregistrée avec sa signature, dans la base de données daudit. Dans un mode de réalisation, l’invention propose de mettre en place un mécanisme de détection d’anomalie automatique, une anomalie étant détectée si les opérations prévues dans le fichier de configuration ne sont pas enregistrées telles quelles dans la base de données de visibilité. Toute anomalie détectée fait l’objet d’une transaction enregistrée avec sa signature dans la base de données d’audit. Ainsi, dans un mode de réalisation, le procédé comporte: - une étape de vérification de la conformité des informations enregistrées dans la base de données de visibilité par rapport aux informations du fichier de configuration et si ce n’est pas le cas une étape d’enregistrement d’une anomalie dans une base de données d’exception ; et - une étape d’enregistrement d’au moins une transaction représentative de ladite anomalie et d’une signature de ladite transaction dans la base de données d’audit immuable et vérifiable, ladite signature étant effectuée en utilisant la clé privée dudit système. Comme mentionné ci-dessus, lorsqu’une mesure n’est pas conforme aux conditions prévues de la livraison, elle fait l’objet, en plus de l’enregistrement de la transaction correspondante dans la base de données d’audit, d’un enregistrement dans une base de données d’exceptions. Dans un mode particulier de réalisation, l’invention propose un mécanisme automatique de traitement de ces exceptions. Ainsi, dans un mode de réalisation, le procédé comporte : - une étape d’interrogation de la base de données d’exception pour identifier des mesures non conformes aux conditions de livraison ; et, le cas échéant : - une étape de décision du traitement à apporter à cette dite mesure. Un traitement peut par exemple consister à alerter un utilisateur. Dans un mode de réalisation, les étapes de vérification de conformité et de traitement de mesure non conforme sont effectuées par un module de traitement d’anomalie entraîné pour détecter des anomalies et pour décider de leur traitement à partir d’un ensemble de règles et de données d’historique. En résumé, l’invention offre aux utilisateurs autorisés une visibilité, possiblement, en temps réel sur des informations pertinentes de la livraison. Cela peut notamment inclure des informations sur le déroulé des opérations, des valeurs de capteurs, des informations d'état, et des documents. Toutes ces informations font l’objet d’une transaction signée enregsitrée dans la base de données d’audit. Liste des figures La illustre les principales étapes d’un procédé de contrôle de livraison conforme à un mode particulier de réalisation de l’invention.; La représente schématiquement un système de contrôle de livraison conforme à un mode particulier de réalisation de l’invention; La est un exemple de fichier de configuration. Description détaillée La représente sous forme d’organigramme les principales étapes d’un procédé P CL de contrôle de livraison conforme à un mode particulier de réalisation de l’invention. Dans le mode de réalisation, ce procédé est mis en œuvre par un système de contrôle de livraison KX qui sera décrit en référence aux figures 2 et 3 dans un exemple de scénario mettant en œuvre l’invention. Dans le mode de réalisation décrit ici, le procédé de contrôle KX comporte une étape E10 d’enregistrement des utilisateurs autorisés à interagir avec le système KX. Cette étape d’enregistrement comporte par exemple une phase d’initialisation d’un mot de passe et de fourniture de moyens d’authentification propres aux utilisateurs (jetons, certificats, …). De tels moyens d’enregistrement sont connus de l’homme du métier. Ils permettent au système KX de vérifier, pour chaque accès d’un utilisateur au système, si cet utilisateur est un utilisateur autorisé. Ensuite, dès qu’un utilisateur souhaite accéder au système KX pour faire une opération, le procédé vérifie au cours d’une étape E20, d’une part que l’utilisateur est authentifié mais également que l’utilisateur possède des droits pour effectuer cette opération. C’est par exemple le cas, si un utilisateur demande à télécharger un fichier F CONF de configuration d’une livraison : le téléchargement de ce fichier par un utilisateur (étape F30) ne peut être effectué qu’après authentification de l’utilisateur et vérification d’un droit de l’utilisateur a effectué ce téléchargement. Dans un mode préféré de réalisation, les droits d’un utilisateur à effectuer une opération sont définis en fonction du ou des rôles de l’utilisateur et d’une politique de sécurité de type ABAC. De la même façon, si un utilisateur souhaite enregistrer (étape E40) le résultat d’une opération ou tout autre information dans le système KX, cet enregistrement est conditionné par l’étape E20 d’authentification de l’utilisateur et de vérification droit de cet utilisateur à formuler une telle requête d’enregistrement au vu de son rôle l’utilisateur et de ses droits définis par la politique de sécurité. Idem, le téléchargement d’un document dans le système KX par un utilisateur est soumis aux mêmes exigences. Dans le mode de réalisation décrit ici, le système KX comporte une base de données de visibilité dans laquelle sont enregistrés tous les événements pertinents de la livraison, notamment ceux enregistrés par les utilisateurs autorisés. Il peut s’agir par exemple des événements relatifs au transport de la marchandise ou à la réalisation de formalités. Toute information saisie par un utilisateur autorisé (relative par exemple au numéro de lot ou au numéro de série des marchandises) est également enregistrée dans cette base de données de visibilité. De la même façon, si un utilisateur souhaite interroger cette base de données de visibilité pour obtenir des informations sur la livraison, la fourniture d’une telle information est conditionné par l’étape E20 d’authentification de l’utilisateur et de vérification droit de cet utilisateur à demander cette information au vu de son rôle et de ses droits définis par la politique de sécurité. Dans un mode de réalisation de l’invention, le fichier de configuration peut comporter au moins certaines informations parmi : - des informations sur des données à saisir et sur les personnes autorisées à effectuer cette saisie; - des informations sur au moins une étape de transport de la marchandise; - des informations sur au moins un document à télécharge et sur les personnes autorisées à effectuer ce téléchargement ; -des conditions de ladite livraison. Dans un mode de réalisation de l’invention, un utilisateur peut également demander à ce qu’un ou plusieurs objets connectés effectuent des mesures de données représentatives de conditions de livraison de la marchandise. Par exemple, l’utilisateur peut renseigner le numéro de série d’un tel objet connecté, cette saisie n’étant autorisée qu’après authentification de l’utilisateur et vérification de ses droits au vu de la politique de sécurité. Ces objets connectés sont par exemple un capteur de température, un module GPS, un capteur d’humidité, un détecteur de chocs (par exemple un accéléromètre), un détecteur de lumière fixé aux marchandises pour détecter respectivement la température ou l’humidité au niveau de la marchandise, si la marchandise a été ouverte, ou un éventuel choc. Lorsqu’un tel objet connecté a été valablement déclaré et configuré pour effectuer les mesures attendues, ces mesures sont effectuées, par exemple régulièrement ou à des instants définis dans le fichier de configuration, au cours d’une étape référencée E60. Ces mesures sont par exemple enregistrées dans une base de données de conditions de livraison. Dans le mode de réalisation décrit ici, si le système KX détecte (étape E70) que les données mesurées ne sont pas conformes à celles définies dans le fichier de configuration, elles sont enregistrées dans une base de données d’exception (étape E80). Dans le mode de réalisation décrit ici, le procédé de contrôle P CL met en œuvre un mécanisme de détection d’anomalies et pour d’entre elles, un mécanisme de traitement de ces anomalies. Dans le mode de réalisation décrit ici, les anomalies sont traitées par un système expert ou par un module entraîné à cet effet qui s’appuie sur un ensemble de règles et sur des données d’historique. Ainsi, au cours d’une étape E100, le module de gestion des anomalies vérifie la conformité des informations enregistrées dans la base de données de visibilité par rapport aux informations du fichier de configuration et en cas de non-conformité, il enregistre une anomalie dans une base de données d’exception. Dans le mode de réalisation décrit ici, le module de gestion des anomalies est en outre configuré pour traiter le cas des mesures de conditions de livraison non conformes au fichier de configuration. Ainsi, au cours d’une étape E110, le module de gestion d’anomalies interroge la base de données d’exception pour identifier des mesures non conformes aux conditions de livraison ; et, le cas échéant décide du traitement à apporter à cette mesure. Dans le mode de réalisation décrit ici, le procédé de contrôle de livraison comporte une étape E90, mise en œuvre, à chaque fois : -qu’une information est enregistrée dans la base de données de visibilité (étape E40) ; - qu’une mesure d’une donnée représentative d’une condition de livraison environnementale est prise (étape E60) ; - à chaque fois qu’une, anomalie est détectée (étape E100), cette étape consistant à enregistrer dans une base de données d’audit immuable et vérifiable, une transaction représentative de cette événement et d’une signature de cette transaction effectuée en utilisant la clé privée du système. Cette base de données d’audit offre une traçabilité complète de la livraison en agrégeant des informations de la base de visibilité BD VIS et de la base de données de mesure BD IoT . La représente un système et un procédé de contrôle de transport de marchandises conforme à un mode de réalisation de l’invention. Dans l’exemple de la , on considère trois entités, à savoir un expéditeur EXP, un prestataire de logistique LOG, et un client CLT. Pour chacune des trois entités EXP, LOG, CLT on a un représenté trois utilisateurs, à savoir : - un utilisateur ayant un rôle ADM d’administrateur EXP-ADM, LOG-ADM, CLT-ADM ; - un utilisateur ayant un rôle MNG de responsable (en anglais manager) EXP-MNG, LOG-MNG, CLT-MNG ; et - un utilisateur ayant un rôle OP d’opérateur EXP-OP, LOG-OP, CLT-OP. Sur la , on a également représenté le poste de travail, par exemple un ordinateur personnel, un serveur, une tablette ou un téléphone intelligent de chacun de ces utilisateurs. Le poste de travail de l’administrateur (respectivement du responsable, de l’opérateur) de l’entité ENT (ou ENT représente l’expéditeur EXP, le prestataire de logistique LOG ou le client CLT) est noté PC ENTA (respectivement PC ENTM , PC ENTO ). Les chiffres encerclés représentent des étapes qui peuvent être mises en œuvre dans au moins un mode particulier d’un procédé de contrôle de transport de marchandises conforme à un mode particulier de réalisation de l’invention. Enregistrement du responsable EXP-MGR de l’expéditeur MXP auprès du serveur KX Au cours d’une étape 1, le responsable EXP-MGR de l’expéditeur EXP utilise son poste de travail PC EXPM pour s’enregistrer auprès du serveur KX. Cet enregistrement peut par exemple s’effectuer au moyen d’une page WEB. Dans le mode de réalisation décrit ici, au cours d’une étape 2, le responsable EXP-MGR renseigne son prénom, son nom, son adresse de courrier électronique, son nom d’utilisateur EXP-MGR et le nom de son entité EXP auprès d’un module d’administration MOD AdmSer pour que ces informations (ou attributs) soient mémorisées (étape 3) dans une base de données de permissions BD PERM . Au cours d’une étape générale 4, un module MOD ABAC d’application d’une politique de sécurité ABAC vérifie périodiquement les nouvelles permissions enregistrées dans la base de données de permissions BD PERM . Au cours d’une étape 5, le module d’administration MOD Adm enregistre le responsable EXP-MNG de l’expéditeur EXP auprès d’un module de gestion d’accès MOD SGA (en anglais Identity Access Management System). Ce module de gestion d’accès MOD SGA est par exemple une plateforme d’un réseau en nuage (an anglais cloud computing) administrée par un fournisseur de service, par exemple la plateforme AWS (marque déposée, Amazon Web Services) de la société Amazon (marque déposée). Au cours d’une étape 6, le module de gestion d’accès MOD SGA envoie une requête (par exemple un courrier électronique) au poste de travail PC EXPM du responsable EXP-MNG de l’expéditeur EXP pour lui demander de réinitialiser son mot de passe. Au cours d’une étape 7, le responsable EXP-MNG de l’expéditeur EXP utilise son poste de travail PC EXPM pour modifier son mot de passe. Dans le mode de réalisation décrit ici, cette étape connue de l’homme du métier est effectuée sous le contrôle du module de gestion d’accès MOD SGA . Au cours d’une étape 8a, le module de gestion d’accès MOD SGA vérifie le attributs du nouvel utilisateur. Si le résultat de la vérification est positif, , le module de gestion d’accès MOD SGA mémorise le mot de passe du responsable EXP-MNG de l’expéditeur EXP et génère un jeton d’authentification TOK EM qui est stocké dans le navigateur de cet utilisateur, dans son poste de travail PC EXPM à l’étape 8. Dans le mode de réalisation décrit ici, ce jeton est valide tant que le responsable EXP-MNG communique avec le serveur KX. Il est par exemple invalidé par le serveur KX en cas d’inactivité du responsable EXP-MNG pendant une période déterminée, par exemple 30 minutes. Ce jeton TOK EM permet de garantir la validité et l’authenticité des échanges entre le navigateur de l’utilisateur EXP-MNG et le serveur KX. Configuration d’un flux d’livraison Au cours d’une étape 9, l’administrateur EXP-ADM de l’expéditeur EXP utilise son poste de travail PC EXPA pour s’enregistrer auprès du serveur KX. Cette étape est similaire à l’étape 1 d’enregistrement du responsable EXP-MNG. Au cours d’une étape 10, l’administrateur EXP-ADM de l’expéditeur EXP modifie son mot de passe sur requête du module de gestion d’accès MOD SGA . Cette étape est similaire aux étapes 6 et 7 de modification du mot de passe du responsable EXP-MNG. Au cours d’une étape 11, le module de gestion d’accès MOD SGA mémorise le mot de passe de l’administrateur EXP-ADM et génère un jeton d’authentification TOK EA qui est stocké dans le navigateur de cet administrateur, dans son poste de travail PC EXPA . Cette étape est similaire à l’étape 8, le jeton TOK EA permettant de garantir la validité et l’authenticité des échanges entre le navigateur de l’administrateur EXP-ADM et le serveur KX. Au cours d’une étape 12, l'administrateur EXP-ADM télécharge un fichier F CONF de configuration de la livraison, ce fichier comportant des informations sur des opérations devant se dérouler durant ladite livraison. En variante, l’administrateur peut utiliser une interface utilisateur et créer un tel fichier de configuration. Le fichier de configuration F CONF peut aussi comprendre des informations sur des données à saisir, par exemple des numéros de lots et/ou des numéros de série des marchandises, et les personnes autorisées à effectuer cette saisie. Le fichier de configuration F CONF peut comprendre des informations sur une ou plusieurs étapes de transport de la marchandise, par exemple un lieu de départ et un lieu d’arrivée ainsi que la date estimée de cette étape de transport. Le fichier de configuration peut comprendre des informations sur des documents à télécharger (certificat de conformité, documents douaniers, bons de livraison, …) par exemple le type de ce document, la date estimée de téléchargement, les personnes autorisées à effectuer ces téléchargements. Un exemple de fichier de configuration F CONF est représenté à la . Ce fichier décrit les étapes d’une livraison. Dans cet exemple, le fichier de configuration F CONF comporte une ligne pour chaque étape, cette ligne comportant : : - une colonne ET# comportant un numéro de cette étape; - une colonne ETN qui comporte un nom de cette étape; - une colonne VO qui comporte une ville du démarrage de cette étape; - une colonne PO qui comporte un pays de démarrage de cette étape; - une colonne LgO qui comporte la longitude du lieu de démarrage de cette étape; - une colonne LtO qui comporte la latitude du lieu de démarrage de cette étape; - une colonne EDO qui comporte une date d’estimation du début de démarrage de cette étape; - une colonne VD qui comporte une ville de fin de cette étape; - une colonne PD qui comporte un pays de fin de cette étape; - une colonne LgD qui comporte la longitude du lieu de fin de cette étape; - une colonne LtD qui comporte la latitude du lieu de fin de cette étape; - une colonne EDD qui comporte une date d’estimation de la fin de cette étape; - au moins une action RA à effectuer ; - un numéro RA# de cette action RA ; - une type TA de cette action ;; - un identifiant RESP de la personne responsable de cette action ; - éventuellement, un type de document TD à enregistrer au cours de ladite action ; - une liste SW d’identifiants de personnes qui peuvent accéder au résultat de cette action. Pour certaines étapes, le lieu de démarrage et de fin d’une étape peuvent être identiques. Dans le mode de réalisation décrit ici, les types d’action TA comportent : - le type UPL : pour une étape de téléchargement d’un document ; - le type DATA : pour une étape de saisie de données ; - le type ACK pour une étape de vérification. Dans le mode de réalisation décrit ici, les types de document TD comportent : - le type COO : pour les certificats d’origine; - le type COC: pour les certificats de conformité; - le type EPOD pour les preuves numériques de livraison. Dans le mode de réalisation décrit ici, le fichier de configuration F CONF comporte également une table pour enregistrer des identifiants d’objets connectés à utiliser pour suivre des conditions de la livraison. Dans l’exemple décrit ici, cette table comporte : - une colonne IoT# comportant un numéro d’objet connecté ; - une colonne MN comportant une marque ou un type d’objet connecté à utiliser ; - une colonne « Serial# » destinée à recevoir un numéro de série d’un objet connecté de la marque ou du type de la colonne MN ; - une condition à mesurer, par exemple une température, un degré d’humidité, une luminosité , …. ; - une borne basse BB et une borne haute BH. Dans l’exemple de la , le fichier de configuration F CONF décrit un flux en quatre étapes. Première étape . - Numéro de l’étape (ET#) : 1 - Nom de l’étape (ETN) : « Préparation de livraison »; - Ville et pays d’origine du lieu de démarrage de l’étape (VO, PO) : « Pune, Inde »; - Ville et pays du lieu de fin de l’étape (VD, PD) : « Pune, Inde »; - Longitude et latitude du lieu de démarrage de l’étape (LgO, LtO) : « 73.94; 25.26 » - Longitude et latitude du lieu de fin de l’étape (LgD, LtD) : « 73.94; 25.26 » - Date de commencement de l’étape (EDO) : « 22/11/11 » - Date de fin de l’étape (EDD) : « 22/11/11 ». Actions à effectuer : - Action 1 : Action à effectuer RA : Télécharger le certificat d’origine. Type d’action TA : UPL, action de téléchargement ; Responsable de l’action RESP : l’opérateur EXP-OP de l’expéditeur EXP ; Type de document à télécharger TD : COO : certificat d’origine. . Personnes pouvant prendre connaissance du résultat de cette action : LOG-OP (opérateur LOG-MNG du prestataire logistique), LOG-MNG (responsable du prestataire logistique) et CLT-OP (opérateur du client). - Action 2 : Action à effectuer RA : Télécharger le certificat de conformité. Type d’action TA : UPL, action de téléchargement ; Responsable de l’action RESP : l’opérateur EXP-OP de l’expéditeur EXP ; Type de document à télécharger TD : COC : certificat de conformité. . Personnes pouvant prendre connaissance du résultat de cette action : LOG-OP (opérateur LOG-MNG du prestataire logistique), LOG-MNG (responsable du prestataire logistique) et CLT-OP (opérateur du client). - Action 3 : Action à effectuer RA : Saisir les numéros de lot Lot# des marchandises, les numéros de série Serial # des marchandises, et les numéros IoT# d’objets connectés autorisés à effectuer des mesures de température des marchandises au cours de la livraison ; Type d’action TA : DATA, saisie de données; Responsable de l’action RESP : l’opérateur EXP-OP de l’expéditeur EXP ; . Personnes pouvant prendre connaissance du résultat de cette action : LOG-OP (opérateur LOG-MNG du prestataire logistique), LOG-MNG (responsable du prestataire logistique) et CLT-OP (opérateur du client). Deuxième étape. - Nom de l’étape (ESN) : « Transport vers Mumbai»; - Ville et pays d’origine du lieu de démarrage de l’étape (VO, PO) : « Pune, Inde »; - Longitude et latitude de ce lieu (LgO, LtO) : « 73.94 ; 25.26 » - Ville et pays de du lieu de fin de l’étape (VD, PD) : « Mumbai, Inde »; - Longitude et latitude de ce lieu (LgD, LtD) : « 72.87; 19.07» - Date de démarrage de l’étape (EDO) : « 22/11/11 » - Date de fin de l’étape (EDD) : « 22/11/11 » Actions à effectuer : - Action 1 : Action à effectuer RA : Saisir le numéro de vol de Mumbai à Doha. Type d’action TA : DATA, saisie de données; Responsable de l’action RESP : LOG-OP du prestataire de logistique LOG. . Personnes pouvant prendre connaissance du résultat de cette action : EXP-OP (opérateur de l’expéditeur), EXP-MNG (responsable de l’expéditeur) et CLT-OP (opérateur du client). - Action 2 : Action à effectuer : Confirmer que les formalités douanières d’exportation à Mumbai ont été effectuées. Type d’action TA : ACK, vérification; Responsable de l’action RESP : LOG-OP du prestataire de logistique LOG. . Personnes pouvant prendre connaissance du résultat de cette action : EXP-OP (opérateur de l’expéditeur), EXP-MNG (responsable de l’expéditeur) et CLT-OP (opérateur du client). Troisième étape. - Nom de l’étape (ESN) : « Transport vers Doha»; - Ville et pays du lieu de démarrage de l’étape (VO, PO) : « Mumbai, Inde »; - Longitude et latitude de ce lieu (LgO, LtO) : « 72.87 ; 19.07 » - Ville et pays de du lieu de fin de l’étape (VD, PD) : « Doha, Qatar »; - Longitude et latitude de ce lieu (LgD, LtD) : « 51.43 ; 25.28 » - Date de démarrage de l’étape (EDO) : « 22/11/11 » - Date de fin de l’étape (EDD) : « 22/11/12 ». Actions à effectuer : - Action 1 : Action à effectuer RA : Confirmer que les formalités douanières d’exportation à Doha ont été effectuées. Type d’action TA : ACK, vérification; Responsable de l’action RESP : LOG-OP du prestataire de logistique LOG. . Personnes pouvant prendre connaissance du résultat de cette action : EXP-OP (opérateur de l’expéditeur), EXP-MNG (responsable de l’expéditeur) et CLT-OP (opérateur du client). Quatrième étape. - Nom de l’étape (ESN) : « Transport au client»; - Ville et pays du lieu de démarrage de l’étape (VO, PO) : « Doha, Qatar »; - Longitude et latitude de ce lieu (LgO, LtO) : « 51.43 ; 25.28 » - Ville et pays du lieu de fin de l’étape (VD, PD) : « Rumaylah, Qatar »; - Longitude et latitude de ce lieu (LgD, LtD) : « 72.87 ; 19.07» - Date de démarrage de l’étape (EDO) : « 22/11/12 » - Date de fin de l’étape (EDD) : « 22/11/12 » Actions à effectuer : - Action 1 : Action à effectuer RA : Télécharger la preuve du bon de livraison. Type d’action TA : UPL, action de téléchargement ; Responsable de l’action RESP : l’opérateur CLT-OP du client CLT; Type de document à télécharger EPOD: COO : preuve électronique de livraison . Personnes pouvant prendre connaissance du résultat de cette action : EXP-OP (opérateur de l’expéditeur), EXP-MNG (responsable de l’expéditeur) et LOG-OP (opérateur du prestataire logistique). Dans l’exemple décrit ici, cette table comporte : - une colonne Nb comportant un numéro d’objet connecté ; - une colonne MN comportant une marque ou un type d’objet connecté à utiliser ; - une colonne « Serial# » destinée à recevoir un numéro de série d’un objet connecté de la marque ou du type de la colonne MN ; - une condition à mesurer, par exemple une température, un degré d’humidité, une luminosité , …. ; - une borne basse BB et une borne haute BH. Dans l’exemple de la , la table des objets connectés du fichier de configuration F CONF comporte : - un seul objet connecté (Nb=1); - de la marque XYZ (colonne MN) ; - pour mesurer une condition de température (colonne COND) : - la température devant être comprise entre 24° (borne basse BB) et 26° (borne haute BH). Au cours d’une étape 13, le module MOD ABAC d’application de la politique de sécurité ABAC vérifie si l'administrateur EXP-ADM de l’expéditeur EXP était autorisé (étape 12) à télécharger le fichier F CONF de configuration du flux d’livraison. Il utilise à cet effet les lignes 1 à 7 de la politique de sécurité de l’Annexe 1. Si le module MOD ABAC vérifie, au vu de la politique de sécurité ABAC, que l'administrateur EXP-ADM de l’expéditeur EXP était autorisé à télécharger le fichier de configuration F CONF , le module MOD ABAC applique la politique de sécurité ABAC et transfert une requête pour gérer la visibilité de la livraison à un module MOD VIS de gestion de la visibilité de la livraison. Au cours d’une étape 14, le module MOD VIS de gestion de la visibilité enregistre les informations du fichier de configuration F CONF dans une base de données BD VIS de visibilité de la livraison. Exécution des étapes du flux de la livraison Nous décrivons maintenant l’exécution des étapes du flux de la livraison. Au cours d’une étape 15, l’opérateur EXP-OP de l’expéditeur EXP utilise son poste de travail PC EXPO pour s’enregistrer auprès du serveur KX. Cette étape est similaire à l’étape 1 d’enregistrement du responsable EXP-MNG. Au cours d’une étape 16, l’opérateur EXP-OP de l’expéditeur EXP modifie son mot de passe sur requête du module de gestion d’accès MOD SGA . Cette étape est similaire aux étapes 6 et 7 de modification du mot de passe du responsable EXP-MNG. Au cours d’une étape 17, le module de gestion d’accès MOD SGA mémorise le mot de passe de l’opérateur EXP-OP et génère un jeton d’authentification TOK EO qui est stocké dans le navigateur de cet opérateur, dans son poste de travail PC EXPO . Cette étape est similaire à l’étape 8, le jeton TOK EO permettant de garantir la validité et l’authenticité des échanges entre le navigateur de l’opérateur EXP-OP et le serveur KX. Au cours d’une étape 18, l'opérateur EXP-OP télécharge le certificat d’origine COO (comme requis par le fichier F CONF . de configuration du flux d’livraison (étape 1 « Prestation de livraison », action RA1 « Télécharger certificat d’origine »). Le module MOD ABAC d’application de la politique de sécurité ABAC vérifie si l’opérateur EXP-OP de l’expéditeur EXP est autorisé à télécharger des documents de type TD certificat d’origine COO. Il utilise à cet effet les lignes 17 à 24 de la politique de sécurité de l’Annexe 1.. Uniquement s’il est déterminé que l’opérateur est autorisé à télécharger ce certificat, au cours d’une étape 19, le module MOD VIS de gestion de la visibilité enregistre dans la base de données de visibilité BD VIS une information selon laquelle le certificat d’origine COO a été téléchargé et le module MOD VIS de gestion de la visibilité enregistre le certificat d’origine COO dans la base de données de documents BD DOC au cours d’une étape 20. Au cours d’une étape 21, l'opérateur EXP-OP télécharge le certificat de conformité COC (comme requis par le fichier F CONF . de configuration du flux d’livraison (étape 1 « Prestation de livraison », action RA2 « Télécharger certificat de conformité»). Le module MOD ABAC d’applicaton de la politique de sécurité ABAC vérifie si l’opérateur EXP-OP de l’expéditeur EXP est autorisé à télécharger des documents de type TD certificat de conformité COC. Il utilise à cet effet les lignes 25 à 33 de la politique de sécurité de l’Annexe 1. Au cours d’une étape 22 le module MOD VIS de gestion du de la visibilité met à jour la base de données de visibilité BD VIS pour indiquer que le téléchargement du certificat de conformité COO a été effectué le 22/11/11 à Pune par l’opérateur EXP-OP. Au cours d’une étape 23, le module MOD VIS de gestion de la visibilité enregistre le certificat de conformité COC dans la base de données de documents BD DOC . Au cours d’une étape 24, l'opérateur EXP-OP saisit les numéros de lot Lot# des marchandises, les numéros de série Serial # des marchandises. Dans l’exemple décrit ici : Lot# =ABCXR123 Serial# =123456789 Il saisit également le numéro de série « Serial # » d’un objet connecté de la marque MN pous suivre la température de la marchandise. Dans l’exemple décrit ici ; IoT#=K12345. Au cours d’une étape 25, le module MOD ABAC d’application de la politique de sécurité ABAC vérifie si l’opérateur EXP-OP de l’expéditeur EXP est autorisé à saisir ces informations. Il utilise à cet effet les lignes 35 à 42 de la politique de sécurité de l’Annexe 1. Uniquement si c’est le cas, au cours d’une étape 26 le module MOD VIS de gestion de la visibilité met à jour la base de données de visibilité BD VIS en enregistrant les informations suivantes: « Livraison du Lot# =ABCXR123, Serial# =123456789, Température à surveiller entre 24°C et 26°C par IoT#=K12345. » Au cours de cette même étape, l’opérateur EXP-OP définit la température à surveiller par l’objet connecté IoT de numéro de série IoT#=K12345, à savoir la plage autorisée [24°C, 26°C]. Au cours d’une étape 27, le module MOD VIS de gestion de la visibilité enregistre dans une base de données d’audit BD AUDIT immuable et vérifiable des transactions représentatives des opérations et le serveur KX signe ces transactions avec sa clé privée. Les informations enregistrées dans cette base de données sont inviolables et infalsifiables. Des nouvelles transactions peuvent être enregistrées mais les transactions enregistrées ne peuvent ni être détruites ni être modifiées. Enregistrement des conditions par les IoT Dans le mode de réalisation décrit ici, lorsqu’un objet connecté a été déclaré et configuré pour surveiller les conditions d’une livraison (étape 26), un module MOD IoT de gestion des objets connecté obtient, par exemple régulièrement, au cours d’une étape 28 des mesures effectuées par ces objets connectés et enregistre ces mesures dans une base de données de conditions de livraison BD IoT (étape 29). Si les mesures ne sont pas dans la plage définie dans fichier de configuration F CONF , les transactions correspondantes sont enregistrées dans une base de données d’exception BD EXC . Par exemple la transaction suivante est enregistrée « température détectée de 28°C le 22/11/11 par l’objet connecté IoT# = K12345. Au cours d’une étape 30, le module MOD IoT de gestion des objets connectés du flux enregistre toutes les transactions dans la base de données d’audit BD AUDIT et le serveur KX signe ces transactions avec sa clé privée. Interactions avec l’opérateur du prestataire de logistique Au cours d’une étape 31, l’opérateur LOG-OP du prestataire de logistique LOG utilise son poste de travail PC LOGO pour s’enregistrer auprès du serveur KX. Au cours d’une étape 32, l’opérateur LOG-OP modifie son mot de passe sur requête du module de gestion d’accès MOD SGA . Au cours d’une étape 33, le module de gestion d’accès MOD SGA mémorise le mot de passe de l’opérateur LOG-OP et génère un jeton d’authentification TOK LO qui est stocké dans le navigateur de cet opérateur, dans son poste de travail PC LOGO . Au cours d’une étape 34, l’opérateur LOG-OP vérifie si les formalités douanières ont été effectuées à Mumbai en interrogeant la base de données de visibilité BD VIS. Au cours d’une étape 35, le module MOD ABAC d’application de la politique de sécurité ABAC vérifie si l’opérateur LOG-OP du prestataire de logistique LOG est autorisé à effectuer cette vérification en fonction de la politique de sécurité. Il utilise à cette effet les lignes 43 à 52 de la politique présentée à l’Annexe 1. Uniquement si c’est le cas, au cours d’une étape 36 le module MOD VIS de gestion de la visibilité met à jour la base de données de visibilité d'informations de gestion de flux d’livraisons pour indiquer que les formalités douanières ont été effectuées à Mumbai le 22/11/11 par l’opérateur LOG-OP. Détection des anomalies Le serveur KX comporte un module MOD AI de détection d’anomalie entraîné pour détecter des événements non conformes à la procédure définie dans le fichier de configuration F CONF . A cet effet, le module MOD AI de détection d’anomalie accède, par exemple régulièrement, : - à la base de données de visibilité BD VIS pour identifier les événements prévus par le fichier de configuration F CONF . ; et - à la base de données d’exception BD EXC pour vérifier si des mesures de température non conformes aux exigences du fichier de configuration F CONF y ont été enregistrées. Dans l’exemple décrit ici, l’action1 de la troisième étape« Transport vers Doha » prévoit que la confirmation de l’exécution des formalités douanières d’exportation à Doha doit être effectuée le 22/11/12. Si le module MOD AI de détection d’anomalie détecte (au cours d’une étape 37) que ces formalités n’ont pas été effectuées, il enregistre une exception dans la base de données d’exception BD EXC . Au cours d’une étape 38, le module MOD AI de détection d’anomalie enregistre une transaction représentative de ladite exception dans la base de données d’audit BD AUDIT et le serveur KX signe ces transactions avec sa clé privée. De la même façon, le fichier de configuration F CONF comporte une indication selon laquelle la température des marchandises doit être comprise entre 24° (borne basse BB) et 26° (borne haute BH). Si le module MOD AI de détection d’anomalie détecte (étape 39) en interrogeant la base de données d’exception BD EXC une mesure de température en dehors de cette plage, il décide comment traiter cette exception au cours d’une étape 40. Il utilise par exemple pour cela un ensemble de règles de décision et un historique des mesures de température. Par exemple, une action peut consister à alerter des utilisateurs ayant accès au workflow. Si le module MOD AI de détection d’anomalie détecte (au cours d’une étape 42) que des marchandises ne se trouvent pas dans un lieu attendu à un instant donné, par exemple dans cet exemple à Mumbai le 22-11-12 au matin, il décide, à partie d’un ensemble de règles, si une Au cours d’une étape 44, le module MOD AI de détection d’anomalie enregistre l’exception dans la base de données d’audit BD AUDIT et le serveur KX signe ces transactions avec sa clé privée. Interactions avec l’opérateur du client Au cours d’une étape 45, l’opérateur CLT-OP du client utilise son poste de travail PC CLTO pour s’enregistrer auprès du serveur KX. Au cours d’une étape 46, l’opérateur CLT-OP modifie son mot de passe sur requête du module de gestion d’accès MOD SGA . Au cours d’une étape 47, le module de gestion d’accès MOD SGA mémorise le mot de passe de l’opérateur CLT-OP et génère un jeton d’authentification TOK CO qui est stocké dans le navigateur du poste de travail PC CLTO de cet opérateur. Au cours d’une étape 48, l’opérateur CLT-OP interroge le serveur KX pour connaître l’endroit où se trouvent les marchandises. Au cours d’une étape 49, le module MOD ABAC d’application de la politique de sécurité ABAC vérifie si l’opérateur CLT-OP du prestataire de logistique LOG est autorisé à obtenir cette information et uniquement si c’est le cas lui fournit l’information de localisation enregistrée dans la base de données de visibilité BD VIS . ANNEXE 1 1: { 2: "application": "KATALX_APP", 3: "comment": "", 4: "version": "20220831", 5: "policy": { 6: "rules": [ 7: { 8: "resource": "F-config", 9: "action": "DOWNLOAD", 10: "conditions": [ 11: "principal:role = 'ADM'", 12: "&principal:organization = 'EXP'" 13: "&principal:status = 'active'" 14: ] 15: }, 16: { 17: "resource": "COO-doc", 18: "action": "DOWNLOAD", 19: "conditions": [ 20: "principal:role = 'OP'", 21: "&principal:organization = 'EXP'" 22: "&principal:status = 'active'" 23: ] 24: }, 25: { 26: "resource": "COC-doc", 27: "action": "DOWNLOAD", 28: "conditions": [ 29: "principal:role = 'OP'", 30: "&principal:organization = 'EXP'" 31: "&principal:status = 'active'" 32: ] 33: }, 34: { 35: "resource": "SHIPMENT-details", 36: "action": "EDIT", 37: "conditions": [ 38: "principal:role = 'OP'", 39: "&principal:organization = 'EXP'" 40: "&principal:status = 'active'" 41: ] 42: }, 43: { 44: "resource": "CUSTOMS", 45: "action": "EDIT", 46: "conditions": [ 47: "principal:role = 'OP'", 48: "&principal:organization = 'LOG'", 49: "&principal:region = 'IN'", 50: "&principal:status = 'active'" 51 : ] 52 : }, 53 : 54 : « ressource » : « clé» 55 : « action » : « partager » 56 : « conditions » : (28) 57 : « principal : statut = ‘actif’ » 58 : 59 : « ressource » : « clé» 60 : « action » : « obtenir» 61 : « conditions » : (32) 62 : « principal : location ct [‘na’] », 63 : « & principal : departement ct contexte : masterKeyInfo :cryptage :departement », 64 : « & contexte: masterKeyInfo :cryptage :expiration>MAINTENANT() » 65 : 66 : « ressource » : « enregistrementDescription » 67 : « action » : « décrypter » 68: « conditions » : 69: « principal : decryptionKeys ct contexte DecryptionKeys », 70: « & contexte :decryptionKey :expiration>MAINTENANT() » Procédé de contrôle de la livraison d’une marchandise, ledit procédé étant mis en œuvre par un système de contrôle (KX) et comportant: - une étape (E10, 1, 5) d’enregistrement d’au moins un utilisateur (EXP-MGR) auprès d’un module de gestion d’accès (MODS GA ) dudit système de contrôle (KX) et de fourniture (8) de moyens d’authentification (TOK EM ) à un poste de travail (PC EXPM ) dudit au moins un utilisateur (EXP-MGR) ; - une étape (E30, 12) de téléchargement, depuis le poste de travail d’un dit utilisateur (EXP-MGR) d’un fichier de configuration (F CONF ) de la livraison, ce fichier (F CONF ) comportant des informations sur au moins une opération devant se dérouler au cours de ladite livraison, ledit téléchargement étant conditionné par (E20) une authentification (11) dudit utilisateur à partir dudit moyen d’authentification (TOK EM ) fourni à cet utilisateur et par la vérification (13) d’un droit de cet utilisateur à effectuer ledit téléchargement au vu d’un rôle (OP) de l’utilisateur et de ses droits conformément à une politique de sécurité ; - une étape (E40, 19, 22, 26, 36) d’enregistrement d’un résultat d’au moins une dite opération dans une base de données de visibilité de la livraison (BD VIS ) sur requête (18, 21) d’un utilisateur, ledit enregistrement étant conditionné (E20) par une authentification dudit utilisateur et par la vérification (4) d’un droit de cet utilisateur à formuler ladite requête au vu d’un rôle (OP) de l’utilisateur et de ses droits conformément à ladite politique de sécurité ; et - une étape (E90, 27) d’enregistrement d’au moins une transaction représentative de ladite au moins une opération et d’une signature de ladite transaction dans une base de données d’audit immuable et vérifiable (BD AUD ), ladite signature étant effectuée en utilisant une clé privée dudit système (KX). Procédé de contrôle de la livraison d’une marchandise selon la revendication 1 dans lequel ledit fichier de configuration (FCONF) comporte au moins certaines informations parmi : - des informations sur des données à saisir et sur les personnes autorisées à effectuer cette saisie; - des informations sur au moins une étape de transport de la marchandise; - des informations sur au moins un document à télécharge et sur les personnes autorisées à effectuer ce téléchargement ; -des conditions de livraison de ladite livraison. Procédé de contrôle selon la revendication 2, dans lequel desdites données saisies (24) par une personne autorisée (EXP-OP) comportent un identifiant d’un objet connecté configuré pour mesurer des données représentatives de conditions de livraison de ladite marchandise, le procédé comportant : - une étape (E60, 28) d’obtention, par l’objet connecté, de mesures de représentatives de conditions de ladite livraison, et (29) d’enregistrement de ces mesures dans une base de données de conditions (BD IoT ) ; - une étape (E90, 30) d’enregistrement d’au moins une transaction représentative desdites mesures et d’une signature de ladite transaction dans ladite base de données d’audit immuable et vérifiable (BD AUD ), ladite signature étant effectuée en utilisant la clé privée dudit système (KX) ; et - si lesdites mesures ne sont pas conformes aux conditions de ladite livraison (E70), une étape (E80) d’enregistrement desdites mesures dans une base de données d’exception (BD EXC ). Procédé de contrôle selon l’une des revendications 1 à 3, comportant, sur requête (31, 48) d’un utilisateur une étape (E50, 49) d’interrogation de la base de données de visibilité (BD VIS ), ladite interrogation étant conditionnée (E20) par une authentification dudit utilisateur et par la vérification (33, 47) d’un droit de cet utilisateur à formuler ladite requête au vu d’un rôle (OP) de l’utilisateur et de ses droits conformément à ladite politique de sécurité. Procédé de contrôle selon l’une des revendications 1 à 4, comportant : - une étape (E100, 37) de vérification de la conformité des informations enregistrées (19, 22, 26, 36, 42) dans la base de visibilité (BD VIS ) par rapport aux informations du fichier de configuration (F CONF ) et en cas de non-conformité une étape d’enregistrement d’une anomalie dans une base de données d’exception (BD EXC ) ; et - une étape (E90, 38) d’enregistrement d’au moins une transaction représentative de ladite anomalie et d’une signature de ladite transaction dans ladite base de données d’audit immuable et vérifiable (BD AUD ), ladite signature étant effectuée en utilisant la clé privée dudit système (KX). Procédé de contrôle selon la revendication 3, comportant : - une étape (E110, 39) d’interrogation de la base de données d’exception (BD EXC ) pour identifier des mesures non conformes aux conditions de livraison ; et, le cas échéant : - une étape (E120, 40) de décision du traitement à apporter à cette dite mesure. Procédé de contrôle selon la revendication 5 et 6 caractérisé en ce que lesdites étapes (E110, 37) de vérification de conformité et (E120, 40) de traitement de mesure non conforme sont mises en œuvre par un module de traitement d’anomalie (MOD AI ) entraîné pour détecter des anomalies et pour décider de leur traitement à partir d’un ensemble de règles et de données d’historique. Procédé de contrôle selon quelconque des revendications 1 à 7 dans lequel l la politique de sécurité est conforme au modèle ABAC. Système (KX) de contrôle de la livraison d’une marchandise, ledit système (KX) comportant: - un module (MOD S GA ) de gestion d’accès configuré pour enregistrer au moins un utilisateur (EXP-MGR) et pour fournir des moyens d’authentification (TOK EM ) à un poste de travail (PC EXPM ) dudit au moins un utilisateur (EXP-MGR) ; - un module de téléchargement, depuis le poste de travail d’un dit utilisateur (EXP-MGR) d’un fichier de configuration (F CONF ) de la livraison, ce fichier (F CONF ) comportant des informations sur au moins une opération devant se dérouler au cours de ladite livraison, ledit téléchargement étant conditionné par : (i) une authentification dudit utilisateur par ledit module (MOD SGA ) de gestion d’accès à partir dudit moyen d’authentification (TOK EM ) fourni à cet utilisateur et par (ii) la vérification (4), par un module (MOD ABAC ) d’application d’une politique de sécurité, d’un droit de cet utilisateur à effectuer ledit téléchargement au vu d’un rôle (OP) de l’utilisateur et de ses droits conformément à ladite politique de sécurité ; - un module (MOD VIS ) de gestion de la visibilité de la livraison configuré pour enregistrer un résultat d’au moins une dite opération dans une base de données de visibilité de la livraison (BD VIS ) sur requête (18, 21) d’un utilisateur, ledit enregistrement étant conditionné par : (i) l’authentification dudit utilisateur par ledit module (MOD SGA ) de gestion d’accès et par (ii) la vérification (4), par un module (MOD ABAC ) d’application d’une politique de sécurité, d’un droit de cet utilisateur à formuler ladite requête au vu d’un rôle (OP) de l’utilisateur et de ses droits conformément à ladite politique de sécurité ; - ledit module (MODVIS) de gestion de la visibilité étant configuré pour enregistrer au moins une transaction représentative de ladite au moins une opération et une signature de ladite transaction dans une base de données d’audit immuable et vérifiable (BD AUD ), ladite signature étant effectuée en utilisant une clé privée dudit système (KX).