FR 3014578 A1 20150612 FR 1362428 A 20131211 L'invention concerne le domaine du traitement numérique de données et plus particulièrement un procédé et système de génération de documents électroniques de certification. Les documents de certification actuels (communément appelés certificats : certificats d'origine, d'authenticité, d'audit, de propriété, etc) sont nécessaires aujourd'hui pour répondre à des obligations légales et des contraintes réglementaires ou métier. Cependant, ces documents ne sont actuellement que peu ou pas sécurisés : il s'agit en effet souvent de documents papiers faciles à reproduire, de versions dématérialisées non liées à des identités fortes d'acteurs ou dont le stockage n'est pas pérenne, etc. Dans les nouvelles réglementations telles que : - le document de la U.S. Food and Drug Administration, FDA 2006 "Compliance Policy Guide for the Prescription Drug Marketing Act. 2006", disponible à l'adresse http://www.fda.gov/OHRMS/DOCKETS/98fr/06-9211.htm - la Directive Européenne 1169/2011 concernant l'information des consommateurs sur les den rées alimentaires, disponible à l'adresse suivante http://eur- lex.eu ropa .eu/LexUriServ/LexUriServ.do?u ri -03: L: 2011:304:0018: 0063: FR: PDF - le document du Ministère de l'Agriculture en France, intitulé « Le paquet hygiène. Ministère de l'agriculture, de l'alimentation, de la pêche, de la ruralité et de l'aménagement du territoire », de 2006, disponible à l'adresse http://agriculture.gouv.fr/le-paquet-hygiene se trouve réaffirmé le besoin de sécurisation de ces documents de certification, notamment afin de garantir aux consommateurs l'origine, la composition, le circuit d'approvisionnement, la non-altérité et la non contrefaçon des produits qu'ils achètent. Cependant, aucune solution technologique n'a répondu à ce jour de manière entièrement satisfaisante à ces nouvelles exigences de sécurisation des documents de certification. La moins sécurisée est la technique usuelle de génération d'un document « papier », transféré et amendé par des procédures de signatures à valeur légale. Le document « papier » peut être aisément contrefait (fausses identités des acteurs métiers, faux documents créés à partir de documents existants mais portant sur d'autres produits et transactions) La dématérialisation de ce même processus, par exemple via des échanges informatisés de documents numériques, pose les mêmes problèmes de sécurisation et de complexité, auxquels il faut ajouter les éventuelles contraintes réglementaires nationales liées à la dématérialisation des signatures et aux identités numériques, nécessaires pour pouvoir donner une valeur probatoire au document de certification généré et mis à jour lors des échanges entre acteurs. A titre d'exemple, le standard Drug Pedigree Messaging Standard (DPMS) publié par GS1 en 2007 n'a jamais réellement été utilisé du fait de sa complexité de mise en oeuvre, et notamment à cause du coût induit pour les différents acteurs : pour répondre à la réglementation de la FDA, le standard propose un échange informatisé de documents (XML) entre les différents acteurs de la chaîne logistique pharmaceutique aux Etats-Unis, depuis les laboratoires jusqu'aux officines pharmaceutiques, chaque acteur ayant pour tâche de générer des versions mises à jour des documents de certification et de les signer numériquement, et ainsi d'apporter la preuve (à leur charge financière) qu'ils deviennent propriétaires de produits dont ils peuvent démontrer l'historique des précédents propriétaires. Suite au constat d'échec du standard DPMS, des réflexions ont été lancées après 2010 dans l'organisme de standardisation GS1, à l'initiative des acteurs de la pharmacie nord-américaine et d'experts techniques, au sein des groupes de travail Network-Centric ePedigree (travaux terminés) puis maintenant Pedigree Security Choreography Checking Service. Ces travaux, toujours en cours, ont pris l'orientation de proposer une solution de génération des documents de certification qui soit basée sur des observations physiques (lecture de codes à barres des lots pharmaceutiques ou lectures des étiquettes à radiofréquence, RFID par exemple), dont les données seraient enregistrées dans des bases de données d'historique des événements sur les objets, conformes au standard GS1 EPCIS (GS1, EPC Information Services (EPCIS), Version 1.0.1, EPCglobal standards, publié en 2007). Le groupe a aussi déjà défini quelques règles de génération des documents de certification à partir des données d'observation, qui dans le monde pharmaceutique doivent être conformes à une succession d'étapes prédéfinies (par exemple : un événement d'expédition doit être précédé d'un événement de fabrication) et nécessairement liées à des informations de transactions métier : ordres d'achat (« purchase order »), bons d'expédition (« despatch advice »), etc. Néanmoins, un certain nombre de questions de ce groupe de travail restent en suspens et aucune solution n'a été proposée pour répondre aux problèmes suivants : - comment attester de l'authenticité de l'observation physique, liée ou non à une transaction métier ? - comment attester de l'identité des acteurs métiers qui ont pour mission de mettre à jour et signer les documents de certification associés aux observations physiques ? - la sécurisation des échanges est-elle suffisante pour certifier que les données d'observation traitées par le service applicatif de vérification sont bien authentiques (non altération, non injection de données erronées) ? - comment concevoir un système de manière à ce qu'il soit applicable à tout domaine métier et tout type de document de certification ? Un des buts de l'invention est de remédier à au moins une partie des problèmes, inconvénients ou insuffisances de l'état de la technique et/ou d'y apporter des améliorations. L'invention concerne, selon un premier aspect, un procédé de génération d'au moins un document électronique de certification de données numériques pour au moins un produit, le procédé comprenant - une étape d'obtention d'un ensemble de données comprenant - au moins un jeu de données numériques, acquises par au moins un dispositif d'acquisition et relatives audit produit, - des données de contexte représentatives d'un contexte d'acquisition dudit jeu de données numériques et - des données de déclenchement de règle, - une étape d'identification, sur la base des données de déclenchement de règle, parmi un ensemble de règles de génération de document, d'au moins une règle de génération de document à appliquer, - une étape d'exécution, par application de la règle de génération de document identifiée, d'au moins une vérification de conformité d'au moins une partie de l'ensemble de données, - une étape de génération d'au moins un document de certification à partir dudit ensemble de données lorsque la vérification de conformité est positive. Le procédé de génération de documents de certification est mis en oeuvre par un serveur, dit serveur applicatif, de génération de documents de certification. Corrélativement, l'invention concerne ainsi un serveur de génération d'au moins un document électronique de certification de données numériques pour au moins un produit, le serveur comprenant - un module d'obtention d'un ensemble de données comprenant - au moins un jeu de données numériques, acquises par au moins un dispositif d'acquisition et relatives audit produit, - des données de contexte représentatives d'un contexte d'acquisition dudit jeu de données numériques et - des données de déclenchement de règle, - un module d'identification, sur la base des données de déclenchement de règle, parmi un ensemble de règles de génération de document, d'au moins une règle de génération de document à appliquer, - un module d'exécution, par application de la règle de génération de document identifiée, d'au moins une vérification de conformité d'au moins une partie de l'ensemble de données, - un module de génération d'au moins un document de certification à partir dudit ensemble de données lorsque la vérification de conformité est positive. Le procédé de génération de document représente une alternative aux méthodes actuelles de production des documents de certification qui se base sur des données numériques acquises par un dispositif d'acquisition, appelées données d'observations, obtenues pour un ou des produits pour lesquels un document de certification est à produire. Ces produits peuvent être tout type de produit : produit manufacturé (objets d'arts, téléphone mobile, téléviseur, vêtement, sac, etc), produit fini ou semi-fini, tout type de produit alimentaire (viande, pâtes, boisson, etc), ou autre produit agricole (plantes, fleurs, céréales, etc), produit pharmaceutique, etc, pour lequel une certification est requise. Ces produits (appelés ici aussi objets) sont usuellement associés à un support d'information permettant une identification de ce produit : étiquette papier avec code barre ou identifiant, étiquette électronique, puce électronique, badge magnétique, emballage ou conteneur, etc. Les données de contexte sont des données représentatives d'un contexte d'acquisition de données d'observation et qui complètent les données d'observation: date et heure d'acquisition, lieu d'acquisition, étape métier, informations sur le produit, numéro ou type d'opération / de transaction; etc. Par l'utilisation de règles de génération de document qui s'appuient sur des données de déclenchement de règles associées à des données d'observations, l'invention permet une automatisation de la génération des documents de certification par un serveur applicatif, à partir des données d'observations issues d'une phase d'acquisition de données numériques, en assurant leur traitement selon des règles de génération de document définies au préalable. En outre, les règles de génération de document permettent la prise en compte de différents besoins propres à un métier ou un à type de document de certification, avec la définition de vérifications de conformité qui doivent être effectuées avant la génération du ou des documents de certification pour le besoin de ce métier. Ces vérifications de conformité sont applicables notamment aux données de contexte, qui sont représentatives d'un contexte d'acquisition et reflètent ainsi certaines au moins des caractéristiques de l'étape métier concernée par l'acquisition des données numériques. Une vérification de conformité de données peut par exemple correspondre à tout type d'opération de vérification nécessaire pour une génération de document de certification donné : vérification de complétude, de cohérence, d'origine, d'identité et/ou d'authenticité, de non altérité des données. En outre, aussi bien les vérifications de conformité à effectuer que le ou les documents de certification à générer peuvent être définis par la règle de génération de document, de sorte que la seule présence de données de déclenchement de règles en association avec les données numériques acquises suffit à contrôler le déclenchement d'une chaîne complète d'opérations aboutissant à un document de certification : sélection de la règle, vérification de conformité définie par la règle, génération du document de certification défini par la règle. Selon un mode de réalisation, l'ensemble de données reçu comprend des données de certification résultant d'une opération de certification appliquée aux données numériques acquises et/ou aux données de contexte, ladite vérification de conformité comprenant une opération de vérification des données de certification. Par données de certification, on entend ici des données d'authentification / de certification / de signature numérique permettant de vérifier l'origine et/ou l'authenticité des données, l'identité des entités (équipements et/ou utilisateurs, personnes physiques) ayant généré ces données, la non altérité des données, etc. Une opération de certification est par exemple : - une opération d'authentification d'une entité (équipement et/ou utilisateur, personne physique) intervenant dans une phase d'acquisition de données; - une opération de génération d'une signature numérique d'une entité intervenant dans une phase d'acquisition de données ; - une opération de vérification et/ou certification de données obtenues dans une phase d'acquisition de données ou de données relatives à cette phase d'acquisition de données. Une opération de certification effectuée sur les données d'observations et/ou les données de contexte peut être réalisée de manière décentralisée, en amont de la chaîne de traitement, au moment même de l'acquisition des données, sur les données numériques acquises et/ou les données de contexte, c'est-à-dire par exemple lors d'une étape métier (production, expédition-livraison, audit, vente, etc) de traitement du produit concerné. Le serveur de génération de document a alors simplement pour tâche d'effectuer des opérations de vérification sur les données de certification reçues: par exemple, une vérification d'une donnée d'identification / d'authentification, une vérification d'une signature numérique. Le coût du système de génération de document de certification est donc réduit du fait même que certaines opérations de certification peuvent être intégrées aux étapes métiers telles que : contrôle de production, préparation de commande, activation de garantie suite à une vente, etc. Selon un mode de réalisation, les données de contexte reçues comprennent une donnée d'identification d'un dispositif de certification, intervenu préalablement à la réception de l'ensemble des données par le serveur, pour authentifier, certifier ou signer au moins une partie des données dudit ensemble de données, le procédé comprenant une étape d'interrogation du dispositif de certification pour effectuer une vérification de conformité. Le serveur de génération de document peut donc effectuer des vérifications complémentaires au moment de la génération du document de certification, notamment pour faire vérifier des données de certification produites par le dispositif de certification ou pour authentifier ce dispositif de certification. Selon un mode de réalisation particulier, les données de contexte reçues comprennent au moins une donnée d'identification et/ou d'authentification d'un dispositif de certification ayant procédé à une opération de certification sur les données numériques acquises et/ou les données de contexte, le procédé comprenant une étape de vérification consistant à vérifier à partir de la donnée d'identification et/ou d'authentification que ledit dispositif d'authentification est référencé dans une base de données. Le serveur de génération de documents se charge de vérification(s) sur l'identité d'un dispositif de certification impliqué dans une opération de certification sur les données numériques acquises et/ou les données de contexte. Ainsi une pluralité de dispositifs de certification peuvent être référencés dans une liste de dispositifs autorisés ou réputés valides, ces différents dispositifs de certification pouvant dans ce cas être répartis géographiquement dans différents équipements connectés chacun à des dispositifs d'acquisition afin de procéder à des opérations de certification dans le contexte même d'une phase d'acquisition de données numériques, de manière adaptée aux besoins de cette phase d'acquisition et au dispositif d'acquisition utilisé. Ainsi les données d'observations et/ou les données de contexte font l'objet d'une opération de certification et/ou authentification et/ou génération de signature, préalablement à la génération des documents. Le processus de génération de document de certification peut alors s'appuyer sur des données préalablement certifiées, et ne procéder qu'à des vérifications complémentaires, qui consistent à vérifier la provenance des données de certification, c'est-à- dire à identifier le dispositif de certification utilisé pour l'opération de certification et/ou authentification et/ou génération de signature. Le serveur de génération de document intervient alors comme entité de certification de deuxième niveau, validant a posteriori les opérations de certification effectuées à un premier niveau par un dispositif de certification. Selon un mode de réalisation particulier, les données de contexte reçues comprennent au moins une donnée d'identification d'une entité dans le groupe comprenant - le dispositif d'acquisition, - un dispositif source conçu pour délivrer audit dispositif d'acquisition un jeu de données, - un utilisateur du dispositif d'acquisition de données, le procédé comprenant une étape de vérification consistant à vérifier à partir de la donnée d'identification que ladite entité est référencée dans une base de données. Ainsi le serveur de génération de documents se charge de vérification a posteriori sur l'identité des entités impliquées dans une étape d'acquisition des données numériques. Selon un mode de réalisation, l'ensemble de données obtenu est relatif à au moins une étape du cycle de vie d'un produit et comprend une identification dudit produit et une identification de ladite étape du cycle de vie. Ceci permet la génération de documents de certification relatif à une ou plusieurs des étapes du cycle de vie, notamment des certificats d'authenticité pour lesquels il est nécessaire de disposer d'un historique sur de telles étapes de cycle de vie. Selon un mode de réalisation, le document de certification est généré pour plusieurs jeux de données numériques acquis successivement pour un même produit, chaque jeu de données numériques étant relatif à au moins une étape du cycle de vie dudit produit. L'ensemble du cycle de vie d'un produit ou au moins une pluralité d'étapes du cycle de vie peut être pris en compte pour générer un document relatif à un produit. Selon un mode de réalisation, le procédé comprend une étape de réception de données de définition d'une règle de génération de document et une étape de stockage desdites données dans une base de données de règles de génération de document, les données de définition comprenant des conditions de déclenchement de règle et une identification d'au moins un type de document de certification à générer lorsque ladite règle est exécutée. Les règles de génération de document définies auprès du serveur de génération de document sont modifiables via une interface de réception de données de définition de règles. Ainsi le système de génération de document s'adapte aisément à tous les besoins, chaque règle servant à contrôler le déclenchement d'une chaîne complète d'opérations aboutissant à un document de certification : sélection de la règle en rapport avec des conditions de déclenchement de la règle, vérification de conformité définie par la règle, génération du document de certification défini par la règle Les différents modes de réalisation mentionnés ci-dessus sont combinables entre eux pour la mise en oeuvre de l'invention. Les avantages énoncés pour le procédé selon l'invention sont transposables directement au serveur selon l'invention. Ce serveur comprend notamment des moyens de mise en oeuvre des étapes du procédé selon l'invention dans ses différents modes de réalisation. Selon une implémentation préférée, les différentes étapes du procédé selon l'invention sont mises en oeuvre par un logiciel ou programme d'ordinateur. L'invention concerne ainsi un logiciel ou programme, susceptible d'être exécuté par un ordinateur ou par un processeur de données, ce logiciel / programme comportant des instructions pour commander l'exécution des étapes d'un procédé de génération de documents électroniques de certification. Ces instructions sont destinées à être stockées dans une mémoire d'un dispositif informatique, chargées puis exécutées par un processeur de ce dispositif informatique. Ce logiciel / programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable. Le dispositif informatique peut être mis en oeuvre par une ou plusieurs machines physiquement distinctes et présente globalement l'architecture d'un ordinateur, incluant des constituants d'une telle architecture: mémoire(s) de données, processeur(s), bus de communication, interface(s) matérielle(s) pour la connexion de ce dispositif informatique à un réseau ou un autre équipement, interface(s) utilisateur, etc. L'invention concerne aussi un support d'informations lisible par un processeur de données, et comportant des instructions d'un programme tel que mentionné ci-dessus. Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. D'autres buts, caractéristiques et avantages de l'invention apparaîtront à travers la description qui va suivre, donnée uniquement à titre d'exemple non limitatif, et faite par référence aux dessins annexés dans lesquels: - la figure 1 représente de manière schématique un système de communication intégrant un dispositif selon l'invention; - la figure 2 représente un organigramme d'un mode de réalisation du procédé selon l'invention. - la figure 3 représente un serveur applicatif selon un mode de réalisation de l'invention. 25 Le système SYS de génération de documents électroniques de certification - appelé en abrégé système SYS de certification - est composé de différentes entités fonctionnelles qui coopèrent entre elles pour la mise en oeuvre de l'invention. La répartition de ces entités fonctionnelles entre les équipements physiques disponibles (serveurs, plateformes, terminaux) 30 peut être réalisée de différentes manières, un même équipement physique pouvant selon le besoin ou la pertinence incorporer une ou plusieurs des entités fonctionnelles ci-dessous. Dans un mode de réalisation, représenté schématiquement à la figure 1, le système SYS de génération de documents électroniques de certification est composé des entités fonctionnelles suivantes : 35 - un serveur applicatif de génération de documents de certification - appelé également serveur applicatif SRV - en charge de la génération des documents de certification, conformément à un ensemble de règles de génération de documents; - un ou plusieurs dispositifs DACQ1, DACQ2 d'acquisition de données numériques : il s'agit par exemple de lecteur d'étiquettes électroniques (RFID, NFC, ou autres) ou d'un lecteur de codes barres, de capteurs de mesures de grandeurs physiques (capteurs de température, de pression, etc), de détecteurs (détecteurs de fumée, détecteur de bruit, etc), d'équipements d'enregistrement de données numériques (appareil photo, enregistreur de vidéo numérique, enregistreur audio, etc), etc; les données numériques acquises par les dispositifs DACQ1, DACQ2 d'acquisition seront nommées également données d'observations ; - un ou plusieurs dispositifs DSRC1, DSRC2 sources, susceptibles de servir de source de données à un des dispositifs DACQ1, DACQ2 d'acquisition précités : il s'agit par exemple d'étiquettes électroniques (RFID, NFC, ou autres), de serveurs de données (serveurs de flux de données numériques, par exemple serveur vidéo), d'images ou photos, d'un support de données (par exemple, codes barres), numériques ou non, susceptibles d'être lus ou scannés par dispositif DACQ1, DACQ2 d'acquisition, etc; ces dispositifs sources sont typiquement associés, liés, apposés sur ou intégrés à des produits dont on souhaite suivre le cycle de vie ; - un ou plusieurs dispositifs DCTX1, DCTX2 de marquage, prévus pour interagir et/ou communiquer avec les dispositifs DACQ1, DACQ2 d'acquisition et qui servent à obtenir ou générer des données de contexte, qui sont représentatives d'un contexte d'acquisition de données d'observation et qui complètent les données d'observation: date et heure d'acquisition, lieu d'acquisition, étape métier (fabrication, congélation, stockage, vente, expédition, livraison ...) dans le cycle de vie du produit associé au dispositif DSRC1, DSRC2 source concerné, informations sur ce produit (identifiant, numéro expédition, livraison, informations techniques ou commerciales, etc), numéro ou type d'opération / de transaction dans le cadre de laquelle a lieu l'acquisition; etc ; les dispositifs DCTX1, DCTX2 de marquage servent également à obtenir ou générer des données de déclenchement de règle (sous forme de mots clefs ou codes, numériques ou alphanumériques, par exemple), servant à l'identification et au déclenchement par le serveur SRV applicatif de règles de génération de documents ; - un ou plusieurs dispositifs DAUTH1, DAUTH2 d'authentification et de certification appelés ici aussi selon le cas dispositifs de certification ou dispositifs d'authentification - prévus pour interagir et/ou communiquer avec les dispositifs DACQ1, DACQ2 d'acquisition afin d'authentifier et/ou certifier des données relatives à une ou plusieurs acquisitions de données numériques effectuées au moyen d'un au moins de ces dispositifs DACQ1, DACQ2 d'acquisition; ces dispositifs DAUTH1, DAUTH2 de certification génèrent, pour un jeu de données d'observations acquises au moyen d'au moins un des dispositifs DACQ1, DACQ2 d'acquisition, des données de certification relatives aux données numériques acquises et/ou à un contexte d'acquisition de ce jeu de données numériques ; - une ou plusieurs bases DST1, DST2 de données pour le stockage de jeux de données d'observations et les données associées à ces données d'observations: données de contexte, données de déclenchement de règles, données de certification; ces données sont par exemple codées et structurées en respectant le standard GS1 EPC Global : EPCIS (Electronic Product Code Information Services) ou tout autre standard ; - une ou plusieurs bases DAN1, DAN2 de données, servant d'annuaire pour le référencement et le stockage de données d'identification d'entités autorisées à intervenir dans le processus d'acquisition et/ou de certification de données : ces entités peuvent être des dispositifs DACQ1, DACQ2 d'acquisition, dispositifs DSRC1, DSRC2 sources, des dispositifs DAUTH1, DAUTH2 d'authentification et de certification, des utilisateurs (personnes physiques) de ces dispositifs, etc ; - au moins un dispositif de stockage de documents de certification - appelé en abrégé, référentiel DREF - servant au stockage et à la consultation de documents de certification générés par le serveur applicatif SRV. Chacun de ces dispositifs, serveurs, bases de données constitutifs du système SYS de certification correspond à un ensemble de modules logiciels et/ou matériels mettant en oeuvre les fonctions décrites dans ce document pour ce dispositif, serveur ou base de données. Dans l'exemple représenté à la figure 1, un terminal T1 intègre à la fois le dispositif DACQ1 d'acquisition et le dispositif de marquage associé DCTX1 qui génère des données de contexte pour les données d'observation acquises par le dispositif DACQ1 d'acquisition. De même, dans cet exemple, un terminal T2 intègre à la fois le dispositif DACQ2 d'acquisition et le dispositif de marquage associé DCTX2 qui génère des données de contexte pour les données d'observation acquises par le dispositif DACQ2 d'acquisition. Le serveur applicatif SRV, représenté schématiquement à la figure 3, est l'équipement central mettant en oeuvre le procédé selon l'invention. Il est doté des moyens suivants: - des moyens MEM de stockage, notamment une mémoire, pour le stockage d'instructions de programme conçues pour commander l'exécution des étapes d'un procédé de génération de documents électroniques de certification ; - des moyens PROC de traitement de données, comprenant notamment un processeur de données, apte à exécuter les instructions de programme stockées afin de mettre en oeuvre les étapes du procédé de génération de documents électroniques de certification. Ce serveur comprend en outre des moyens de mise en oeuvre des étapes du procédé de génération de document. Ces moyens sont constitués par des modules logiciels (software) et/ou matériels (hardware). Dans cette optique, le terme "module" correspond dans ce document à un composant logiciel, à un composant matériel ou bien à un ensemble de composants matériels et/ou logiciels, apte à mettre en oeuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit ci-dessous pour le module concerné. Authentification et certification Les dispositifs DAUTH1, DAUTH2 de certification mettent en oeuvre une ou plusieurs opérations de certification, préalablement, concomitamment ou consécutivement à une opération d'acquisition d'un jeu de données d'observations. Les dispositifs DAUTH1, DAUTH2 de certification sont mis en oeuvre - soit dans le ou les dispositifs DACQ1, DACQ2 d'acquisition de données numériques qui effectuent l'acquisition de données numériques (cas non représenté), - soit dans un terminal T1, T2 ou un équipement connecté au dispositif DACQ1, DACQ2 d'acquisition de données numériques ou incorporant ce dispositif DACQ1, DACQ2 d'acquisition de données numériques (cas non représenté); - soit dans un serveur S1, S2 dédié connecté - directement ou non - à ce dispositif DACQ1, DACQ2 d'acquisition de données numériques, par exemple un serveur d'un tiers de confiance (cas représenté sur la figure 1), - soit encore dans un dispositif ou serveur intégré dans ou connecté à une des bases DST1, DST2 de données pour le stockage qui traitent les données d'observation à leur réception et génère les données de certification associées (cas non représenté). Une opération de certification est par exemple : - une opération d'authentification d'une entité intervenant dans une phase d'acquisition de données; - une opération de génération d'une signature numérique d'une entité intervenant dans une phase d'acquisition de données ; - une opération de vérification et/ou certification de données obtenues dans une phase d'acquisition de données ou de données relatives à cette phase d'acquisition de données. Ces opérations d'authentification et/ou de certification / de signature numérique de données sont appliquées à tout ou partie d'un jeu de données d'observation résultant d'une phase d'acquisition de données et/ou à tout ou partie des données associées à ce jeu de données d'observation : données de déclenchement de règle et/ou données de contexte, représentatives d'un contexte d'acquisition de ce jeu de données d'observation. Chacune de ces opérations de certification aboutit à la génération de données de certification. Ces opérations de certification et les données de certification en résultant sont maintenant décrites plus en détail. L'entité concernée par l'opération d'authentification d'une entité (dispositif, équipement ou personne physique) intervenant dans le processus d'acquisition peut être le dispositif DACQ1, DACQ2 d'acquisition et/ou un dispositif / équipement interconnecté au dispositif DACQ1, DACQ2 d'acquisition ou intégrant celui-ci et/ou un utilisateur d'un équipement interconnecté au dispositif DACQ1, DACQ2 d'acquisition ou intégrant celui-ci. Cette opération d'authentification d'une entité est par exemple : - une opération d'authentification du dispositif DACQ1, DACQ2 d'acquisition de données au moyen du quel le jeu de données d'observation est obtenu, le dispositif d'authentification et de certification authentifiant le dispositif d'acquisition à partir d'une donnée d'identification de ce dispositif d'acquisition et de données d'authentification associées; - une opération d'authentification du dispositif DSR1, DSRC2 source de données ayant fourni les données d'observation au dispositif DACQ1, DACQ2 d'acquisition de données, le dispositif d'authentification et de certification authentifiant le dispositif source à partir de données fournies par ce dispositif source, notamment d'une donnée d'identification de ce dispositif source et de données d'authentification associées ; - une opération d'authentification mutuelle du dispositif DACQ1, DACQ2 d'acquisition de données au moyen du quel le jeu de données d'observation est obtenu et du dispositif DSR1, DSRC2 source de données ayant fourni les données d'observation au dispositif DACQ1, DACQ2 d'acquisition de données, le dispositif d'acquisition jouant le rôle dans ce cas du dispositif d'authentification en procédant à cette authentification mutuelle; - une opération d'authentification de l'utilisateur du dispositif DACQ1, DACQ2 d'acquisition de données ou d'un équipement interconnecté au dispositif DACQ1, DACQ2 d'acquisition ou intégrant ce dispositif d'acquisition, par exemple en utilisant une méthode d'authentification par un tiers de confiance d'un utilisateur d'un terminal mobile incorporant le dispositif DACQ1, DACQ2 d'acquisition de données ou couplé à celui-ci ; à titre d'exemple, la méthode d'authentification décrite dans le document de brevet WO 2013/121127 est applicable pour l'authentification d'un utilisateur d'un dispositif d'acquisition ou terminal équipé d'une carte SIM (suscriber identity module) : il en résulte une donnée d'identité dérivée d'une information d'identité authentique, cette donnée d'identité dérivée pouvant être vérifiée par une plateforme (dispositif de certification) ayant généré cette donnée d'identité dérivée. Dans le cas d'une opération d'authentification, les données de certification comprennent par exemple : - une identification du dispositif d'authentification ayant procédé à l'opération d'authentification d'une entité et/ou - une identification de toute entité ayant été authentifiée : le dispositif d'acquisition, le dispositif source utilisé, un équipement interconnecté au dispositif d'acquisition ou intégrant ce dispositif d'acquisition, un utilisateur de l'un quelconque de ces dispositifs. L'opération de vérification et/ou certification de données est appliquée à des données d'observation et/ou de données de contexte, représentatives d'un contexte d'acquisition de données d'observations. Cette opération de vérification et/ou certification est par exemple : - une opération de certification d'une information d'horodatage de l'acquisition par le dispositif DACQ1, DACQ2 d'acquisition des données d'observation (par exemple, un service de certification d'un horodatage fourni par un service postal), - une opération de certification d'une information de géolocalisation du dispositif DACQ1, DACQ2 d'acquisition de données, cette information de géolocalisation étant obtenue par exemple par des modules de positionnement conformes au système GPS, et certifiée par un opérateur de réseau de téléphonie mobile par croisement avec une autre information de géolocalisation obtenue par localisation, au moyen de l'infrastructure réseau du réseau mobile, d'un terminal mobile incorporant le dispositif DACQ1, DACQ2 d'acquisition de données ou couplé à celui-ci; - une opération de certification de signatures numériques ou manuscrites identifiant une entité (équipement ou personne physique) intervenant dans le processus d'acquisition de données, qu'il s'agisse d'un équipement interconnecté au dispositif DACQ1, DACQ2 d'acquisition ou intégrant celui-ci et/ou d'un utilisateur d'un équipement interconnecté au dispositif DACQ1, DACQ2 d'acquisition ou intégrant celui-ci ; - une opération de vérification de l'exactitude ou de l'intégrité de tout ou partie des données d'observations et/ou des données de contexte ; - etc ; Dans le cas d'une opération de vérification et/ou certification, les données de certification comprennent par exemple : - une identification du dispositif de certification ayant procédé à une certification ou vérification de données d'observations et/ou de données de contexte; et/ou - une identification des données d'observation et/ou de contexte ayant fait l'objet de cette certification et/ou vérification ; par exemple, des images numériques peuvent être stockées concernant les données certifiées: signature manuscrite, empreinte digitale, photo d'un cachet de la poste, etc ; et/ou - un certificat numérique résultant de cette opération de certification. L'opération de génération d'une signature numérique (utilisant par exemple le standard XML DSIG du W3C par exemple), vise à obtenir une signature numérique, réputée authentique et infalsifiable, pour tout ou partie des données d'observation et/ou des données de contexte. Cette opération de signature est par exemple une opération de génération d'une signature, propre à une entité signataire intervenant dans l'acquisition des données, de tout ou partie des données d'observation et/ou des données de contexte. Cette entité signataire peut être l'utilisateur procédant à l'acquisition de données et/ou le dispositif DACQ1, DACQ2 d'acquisition et/ou le dispositif source, un terminal ou un équipement connecté au dispositif d'acquisition ou incorporant ce dispositif d'acquisition, un dispositif ou serveur intégré dans ou connecté à une des bases DST1, DST2 de données pour le stockage qui traitent les données d'observation à leur réception. Dans le cas d'une opération d'authentification, les données de certification comprennent une signature numérique d'une entité : cette entité pouvant être l'utilisateur procédant à l'acquisition de données et/ou le dispositif DACQ1, DACQ2 d'acquisition et/ou le dispositif source, un terminal ou un équipement connecté au dispositif d'acquisition ou incorporant ce dispositif d'acquisition, un dispositif ou serveur intégré dans ou connecté à une des bases DST1, DST2 de données pour le stockage qui traitent les données d'observation à leur réception. Ces opérations d'authentification et/ou de certification / de signature numérique de données peuvent être déclenchées automatiquement (sans intervention de l'utilisateur) ou sur demande de l'utilisateur. Ces opérations d'authentification et/ou de certification / de signature numérique de données peuvent être déclenchées par le dispositif d'acquisition lui-même ou par une application logicielle qui déclenchera à la fois les opérations d'acquisition de données d'observation et les opérations d'authentification et/ou de certification y relatives. Stockage des données et alimentation du serveur applicatif Les données d'observations, les données de contexte et les données de déclenchement de règle qui sont générées suite à une ou plusieurs acquisitions de données sont envoyées vers une ou plusieurs des bases DST1, DST2 de données pour y être stockées. Elles sont envoyées sous formes de messages applicatifs, envoyées par le dispositif d'acquisition, ou bien sous forme de données brutes, non structurées en messages. Chaque jeu de données d'observation est stocké dans une ou plusieurs des bases DST1, DST2 de données, en association avec les données de contexte et les données de déclenchement de règle associées. Chaque jeu de données d'observation ayant donné lieu à une ou plusieurs opérations d'authentification et/ou de certification / de signature numérique est stocké dans ces bases DST1, DST2 de données, en association avec des données de certification résultant de ces opérations d'authentification et/ou de certification / de signature numérique. L'ensemble de données ainsi stocké, incluant les données d'observations, les données de contexte et les données de déclenchement de règle, comprend au moins une information dans le groupe comprenant : - une information de localisation d'un dispositif d'acquisition ou d'un équipement interconnecté au dispositif d'acquisition ou intégrant ce dispositif d'acquisition ; - une information d'horodatage des données d'observations; - une identification du dispositif d'acquisition, - une identification d'un dispositif source ayant délivré au dispositif d'acquisition les données d'observations, - une identification d'un utilisateur du dispositif d'acquisition, d'un équipement interconnecté au dispositif d'acquisition ou intégrant ce dispositif d'acquisition, - une identification d'un produit, - une information sur une étape du cycle de vie d'un produit. En pratique, pour pouvoir générer des documents de certification relatifs au cycle de vie d'un produit, plusieurs ensembles de données seront successivement stockés dans la base de données, chaque ensemble de données étant relatif à au moins une étape du cycle de vie d'un produit et comprenant une identification de cet produit et une identification de la ou des étapes du cycle de vie concernées. Ainsi, un document de certification peut être généré pour un ou plusieurs jeux de données d'observation obtenus successivement pour un même produit, chaque jeu de données d'observation étant relatif à au moins une étape du cycle de vie de cet produit. Pour garantir la non altérité d'un ensemble de données, un checksum (empreinte ou somme de contrôle) sera calculé et sauvegardé avec cet ensemble de données en base de données : ce checksum sera vérifié par le serveur applicatif SRV afin de vérifier la non-altérité d'un ensemble de données stockées dans la base de données. Génération des documents de certification Le serveur SRV applicatif comprend un module d'interface M. pour obtenir des bases DST1, DST2 de données un ensemble de données comprenant tout ou partie des données d'observation, des données de contexte et/ou des données de certification selon différents modes : - soit par réception de messages envoyés par les dispositifs qui génèrent ces données (mode dit « push »), - soit par des mécanismes d'abonnement (mode dit « publish-subscribe »), ou - soit sur requête de la part du serveur applicatif vers les dispositifs qui génèrent ces données (mode dit « pull »). Le serveur applicatif SRV met en oeuvre un moteur d'exécution de règles de génération de document de certification. Le serveur applicatif SRV comprend en outre un module RL de stockage de données de définition de règles de génération de documents, sous forme de base de données RL. Le moteur de règle comprend - un module ID d'identification, sur la base des données de déclenchement de règle, parmi un ensemble de règles de génération de document, d'au moins une règle de génération de document à appliquer, - un module EXE d'exécution de règle, qui applique la ou les la règles de génération de document identifiées, en effectuant au moins une vérification de conformité d'au moins une partie de l'ensemble de données obtenues à partir d'une des bases de données DST1, DST2. - un module GEN de génération d'au moins un document de certification à partir de l'ensemble de données lorsque la vérification de conformité est positive. Pour simplifier la configuration, il peut être prévu une règle de génération de document par type de document de certification à générer. Chaque règle est définie par : - une ou des conditions de déclenchement de la règle, définies relativement aux données de déclenchement de règles associées à des données d'observations ; les données d'observation et/ou les données de contexte constituent également des données de déclenchement de règles lorsqu'elles sont codifiées de manière appropriée pour pouvoir y détecter la présence de mots clefs ou de codes particuliers; - quelles sont les données nécessaires à la génération du document de certification : données d'observations, données de contexte associées et/ou données de certification relatives à ces données d'observation et/ou de contexte; - un ensemble d'au moins une opération de vérification de conformité à effectuer sur les données d'observation et/ou sur les données de contexte associées et/ou sur les données de certification ; - le ou les types de documents de certification lorsque la vérification de conformité est positive. Les données de déclenchement de règle sont constituées par exemple par des mots clefs identifiant l'un des éléments suivants : - un type de document de certification (par exemple « douane », pour un document nécessaire au passage en douane) - un pays pour lequel le document de certification est à générer (par exemple « France » pour un document nécessaire au passage en douane en France) ; - une identification d'un type de produit concerné, par exemple une classe d'objet dans le standard EPC ; - une identification du type d'opération de certification / d'authentification / de signature réalisée ; - toute autre information pertinente pour sélectionner, de manière adaptée au cas d'usage, une règle de génération de document à appliquer. Ces données de déclenchement de règle permettent de définir des règles de génération de document générales (génération de certificat d'origine, d'authenticité, de contrôle de la chaîne du froid), mais aussi des règles de génération de document spécifiques, portant par exemple sur les produits d'un fabricant donné, les identifiants des produits intégrant l'identifiant du fabricant, une classe d'objets, les étapes clés associées à la certification, etc. On peut ainsi avoir à la fois une règle générique « certificat de contrôle de la chaîne du froid » et une règle spécifique « certificat de contrôle de la chaîne du froid pour les Lasagnes surgelées fabriquées en Italie entre 2012 et 2013 ». La règle de génération de document à appliquer est déterminée à partir des données de déclenchement de règle. Par exemple, si les mots clefs « douane » et « France » sont présents, la règle de génération de document sera celle pour la génération d'un document de certification pour les douanes françaises. Si en outre le mot clef « médicament » est présent, la règle de génération de document sera une règle spécifique pour la génération d'un document de certification pour les douanes françaises adapté au cas des médicaments. Le module ID d'identification de règles du serveur applicatif SRV recherche la ou les règles de génération de document à appliquer correspondant à un ou des mots clefs présents dans les données de déclenchement de règle. Les opérations de vérification de conformité effectuées sur un ensemble de données (incluant un jeu de données d'observation et des données associées à ce jeu: données de contexte, données de certification, données de déclenchement de règle) extrait de la base de données sont par exemple les suivantes: - vérification des données d'identification du dispositif de certification ayant procédé à une opération d'authentification et/ou de certification et/ou de signature numérique : ces données d'identification doivent se trouver dans une liste de dispositifs référencés comme autorisés dans une base DAN1, DAN2 de données ; - vérification des données d'identification d'une entité ayant été authentifiée : ces données d'identification doivent se trouver dans une liste d'entités référencées comme autorisées dans une base DAN1, DAN2 de données ; - vérification des données d'identification d'un utilisateur et d'un dispositif d'acquisition, et vérification du fait que l'utilisateur est bien autorisé à utiliser ce dispositif d'acquisition : l'utilisateur doit par exemple être enregistré en association avec le dispositif d'acquisition comme étant habilité à enregistrer ce dispositif d'acquisition; - vérification de la présence de données d'observation, données de contexte et/ou données de certification nécessaire à la génération du document de certification ; en cas d'absence de tout ou partie des données de certification, il peut être prévu que le document de certification soit néanmoins généré mais avec des mentions informant de l'absence de certification possible sur le ou les entités ou données n'ayant pas été certifiées et/ou authentifiées ; - vérification de cohérence de données d'observation nouvellement acquises par rapport à des données d'observation antérieurement traitées pour un même dispositif d'acquisition ou pour un même utilisateur ou pour un même processus métier ; - vérification de l'authenticité et de la non altérité de la ou des signatures numériques présentes dans les données de certification ou des données proprement dites au moyen du checksum stocké avec l'ensemble de données ; Lorsque les données d'identification du dispositif de certification sont stockées sous forme d'adresse de contact (par exemple une adresse IP, une URL ou un URN, Uniform Resource Name, par exemple de la forme http://@IP:port/sigma ou urn:w3c:dsig:checking:sigma), il est possible en outre de procéder à une opération de vérification par interrogation du dispositif d'authentification concerné et envoi d'une requête au moyen de cette adresse de contact. Le serveur applicatif SRV dispose dans ce but d'une interface 13 de communication pour envoyer une requête vers le ou les dispositifs de certification DAUTH1, DAUTH2. Cette requête est par exemple une demande de vérification d'une signature numérique, d'un certificat ou de données d'authentification / d'identification présentes dans l'ensemble de données reçu par le serveur applicatif SRV. En retour, le dispositif de certification interrogé fourni un résultat de cette vérification. Procédé de ciénération de document de certification Le procédé est maintenant décrit par référence à la figure 2 dans un exemple d'application. Constitution des bases de données - Etape E200 Les bases de données ANN1, ANN2 servant d'annuaire pour le référencement d'entités autorisées sont alimentées selon le besoin. - Listes d'utilisateurs et identifications associées, - Listes de dispositifs d'acquisitions - et identifications associées - éventuellement en association avec un ou plusieurs utilisateurs habilités à utiliser ces dispositifs d'acquisition, - Listes de produits - et identifications associées - pour lesquels des documents de certification sont à générer ; - Listes de dispositifs de certification - et identifications associées - référencés et habilités à procéder à une opération de certification, d'authentification, de siganture. Etc Cette étape E200 peut être répétée autant de fois que nécessaire pour modifier, mettre à jour les bases de données ANN1, ANN2. Configuration des règles de génération de document - Etape E205 Le serveur applicatif SRV comprend un module d'interface 12 pour la réception de données de définition de règles de génération de documents. Ce module d'interface 12 est conçu pour recevoir également des mises à jour de définitions de règles de génération de document, demandes de suppression de règle ou demande d'ajout de nouvelles règles. A réception de données de définition de règles, ces données sont stockées dans une base de données RL de stockage de règles de génération de document. Les données de définition comprennent au moins une définition des conditions de déclenchement de règle et une identification d'au moins un type de document de certification à générer. Cette étape E205 peut être répétée autant de fois que nécessaire pour modifier, mettre à jour, compléter les définitions des règles de génération de document ou ajouter de nouvelles 20 règles. Les étapes suivantes E210 à E240 peuvent être répétées autant de fois que de phase d'acquisition d'un jeu de données d'observation. Les étapes E250 et E260 effectuées par le serveur applicatif SRV peuvent en outre être exécutées une fois pour plusieurs jeux de données 25 d'observations, c'est-à-dire être exécutées une fois suite à plusieurs exécutions de la succession des étapes E210 à E240. Obtention des données d'observation - Etape E210 L'acquisition de données d'observation est effectuée de manière distribuée par une 30 pluralité de dispositifs d'acquisition DACQ1, DACQ2. Pour chaque phase d'acquisition, par exemple pour une opération de lecture d'une étiquette électronique, un jeu de données d'observation est obtenu. Ces données d'observation sont par exemple : - des données stockées dans un dispositif source, lues par le dispositif d'acquisition, 35 - des images numérisées d'un produit, - des données audio capturées par un enregistreur numérique, - des données numériques issues de la lecture d'un code-barres, ou encore - une séquence de caractères alphanumériques saisie par un utilisateur, - etc. Génération des données de contexte - Etape E220 Pour chaque ou au moins jeu de données d'observation acquises, sont générées, par un dispositif de marquage associé au dispositif d'acquisition, des données de contexte représentatives d'un contexte d'acquisition du jeu de données d'observations : date et heure d'acquisition, lieu d'acquisition, étape métier dans le cycle de vie du produit associé au dispositif source concerné, informations sur ce produit (identifiant, numéro d'expédition, livraison, informations techniques ou commerciales, etc), numéro ou type d'opération / de transaction dans le cadre de laquelle a lieu l'acquisition; etc. Optionnellement, lors d'une étape E225, des données de déclenchement de règle sont générées par le dispositif de marquage associé au dispositif d'acquisition. Génération des données de certification - Etape E230 Pour chaque ou au moins jeu de données d'observation acquises et les données de contexte associées, sont générées, par un dispositif de certification relié ou intégré au dispositif d'acquisition, suite à une opération de certification appliquée à tout ou partie des données d'observation et/ou des données de contexte, des données de certification: données d'identification / d'authentification d'une entité, données d'identification / d'authentification du dispositif de certification ayant produit les données de certification, signature numérique, certificat numérique etc. En outre, pour garantir la non altérité d'un ensemble de données, un checksum est calculé et sauvegardé avec cet ensemble de données en base de données. Stockage des données d'observation et données associées - Etape E240 Pour chaque ou au moins jeu de données d'observation acquises, un ensemble de données est transmis par le dispositif d'acquisition à une des bases de données DST1, DST2 pour y être stockée. Cet ensemble de données comprend : - le jeu de données d'observations, - des données de contexte associées à ce jeu de données d'observations, - des données de certification associées à ce jeu de données d'observations, - optionnellement, des données de déclenchement de règle. Avec chaque ensemble de données est stocké un checksum (empreinte ou somme de contrôle) ou toute autre donnée de contrôle permettant de vérifier la non altérité de l'ensemble de données. Exécution des règles de génération de document - Etape E250 Le serveur applicatif SRV obtient, selon une des modes (« push », « pull », « subscribe », etc...) décrits plus haut d'au moins une des bases de données DST1, DST2 un ensemble de données comprenant, - un jeu de données d'observations, et/ou - des données de contexte associées à ce jeu de données d'observations, et/ou - des données de certification associées à ce jeu de données d'observations, et/ou - des données de déclenchement de règle. Suite à l'obtention d'un ensemble de données, le serveur applicatif SRV détermine si les conditions de déclenchement d'au moins une règle sont remplies ou non, notamment en détectant dans l'ensemble de données la présence de données de déclenchement de règle répondant à des critères donnés. Dans l'affirmative, le serveur applicatif SRV identifie la ou les règles de génération de document à appliquer et l'exécute. La règle de génération de document à appliquer est celle qui correspond aux données de déclenchement de règles présentes dans l'ensemble de données. Lors de l'exécution de la règle de génération de document, le serveur applicatif SRV effectue au moins une opération de vérification de conformité, définie par la règle de génération de document identifiée, telle que décrite ci-dessus : vérification d'identité de l'utilisateur, du dispositif d'acquisition, etc. Au moins une opération de vérification de conformité consiste à effectuer une vérification des données de certification reçues. Des exemples de telles opérations de vérification ont été donnés plus haut. Si la vérification de conformité est positive, le serveur applicatif SRV génère le ou les documents de certification définis par la règle de génération de document identifiée puis les stocke dans le référentiel REF. Les documents de certification sont par exemple générés et stockés au format XML de manière à faciliter la recherche d'information dans les documents de certification. En supplément, une conversion dans un format adapté au besoin d'une impression ou d'une lecture par l'utilisateur peut être proposée : document imprimable, par exemple au format PDF. Les documents de certification sont complétés au fur et à mesure que le serveur applicatif SRV obtient un ou des ensembles de données comprenant - un jeu de données d'observations, et/ou - des données de contexte associées à ce jeu de données d'observations, et/ou - des données de certification associées à ce jeu de données d'observations, et/ou - des données de déclenchement de règle. En outre, le serveur applicatif SRV mémorise ainsi pour chaque document de certification un statut, représentatif de l'état de complétude de ce document de certification. Ainsi, lorsqu'une règle de génération de document est déclenchée pour la première fois, le statut du document de certification est par exemple « initié ». Puis, pendant l'exécution de la règle de génération de document, le statut est « en cours de traitement ». Lorsque la règle de génération du document de certification a terminé la mise à jour du document, le statut du document de certification devient « disponible ». Enregistrement du document de certification - Etape E260 Le document de certification est enregistré dans le référentiel REF. Il sera mis à jour suite à la réception par le serveur applicatif SRV d'un nouvel ensemble de données. Il peut être consulté à tout moment y compris pendant l'exécution d'une règle de génération de document, lorsque son statut est « initié » ou « en cours de traitement ». De par notamment l'utilisation de règles de génération de document de certification qui sont paramétrables et dont le déclenchement peut être effectué de manière adaptée aux besoins, par association aux données d'observation et/ou de contexte, de données de déclenchement, le système de génération de document de certification est à la fois souple et générique, s'adaptant aisément à de nombreux besoins. Applications de l'invention Quelques exemples d'application sont cités ici. Le système permet la génération d'un certificat d'authenticité d'un produit, lié aux étapes métier de la fabrication de ce produit. Le produit lui-même est authentifié, lors d'une lecture d'une étiquette électronique, associée au produit et porteuse de son identifiant unique sérialisé, par un organisme de contrôle ou par le propriétaire du produit, avec un dispositif d'authentification de produit pouvant être intégré dans l'équipement de lecture. L'étape de fabrication est authentifiée en introduisant par exemple une signature du fabricant du produit. Dans ce cas, le serveur applicatif effectue une vérification sur les données d'observation et les données de certification résultant de l'authentification et génère ou met à jour le certificat d'authenticité en fonction des événements reçus : état « produit authentique », « authenticité en cours de vérification », « l'authenticité du produit n'est pas assurée », en cas par exemple d'absence de signature du fabricant. Le système permet la génération d'un certificat d'origine d'un produit, relatif aux étapes métier de : fabrication, assemblage ou transformation. Dans ce cas, le serveur applicatif vérifie qu'il existe pour chaque donnée d'observation une information de géolocalisation certifiée (coordonnées GPS, identifiant du site de l'entreprise où a eu lieu l'observation) et détermine en conséquence le pays associé à l'étape métier a eu lieu en appelant des services tiers (le répertoire GEPIR de GS1 si le site est identifié par un code GLN, un service de géolocalisation inversée comme celui de Google Maps, etc). Le document de certification généré pourra ainsi indiquer « fabriqué en Italie », « assemblé en Espagne », « transformé en France ». Le système permet la génération d'un certificat de propriété d'un produit, lié aux étapes métier de : fabrication, livraison et vente en magasin. Dans ce cas, le serveur applicatif vérifie l'existence d'identifiant des acteurs métiers impliqués dans chaque étape métier et la présence de signatures associées, puis vérifie les identités de ces acteurs et les signatures auprès de dispositif de certification ayant généré ces signatures. Le document de certification généré indique ainsi les propriétaires successifs, c'est-à-dire les acteurs intervenus successivement sur le produit : fabricant, distributeur, commerçant, etc. Le système de génération de document de certification décrit dans ce document permet de générer des documents de certification de nature variée, tel que: - un pedigree pharmaceutique, certificat d'origine qui identifie les actes successifs (vente, achat, échange) effectué sur un produit pharmaceutique ainsi que les dates de ces actes, le nom et adresse des parties concernées par ces actes: d'un produit pharmaceutique selon les principes établis par la Food & Drug Administration et les lois en vigueur aux Etats-Unis en Californie et en Floride ; - un certificat d'origine, attestant du pays de fabrication d'un produit, selon la définition de la fédération mondiale des chambres de commerce ; - un certificat adapté pour la traçabilité alimentaire, conforme aux obligations européennes en matière d'hygiène, et en particulier pour la traçabilité des viandes, qui permette de certifier les lieux de naissance, d'élevage et d'abattage de bétail, selon les initiatives actuelles au Canada, en Nouvelle-Zélande et en France ; - un certificat de conformité, attestant par exemple que le produit a bien passé des étapes de contrôle automatisé (par exemple des mesures de température par capteurs, pour contrôler que la chaîne du froid a bien été respectée de manière continue) ; - un certificat d'authenticité, adapté pour une traçabilité de produits des secteurs du luxe ou de l'art, mais aussi pour des produits sensibles : défense, matériaux dangereux, tissus humains, pièces automobiles et aéronautiques. Ce système est utilisable pour la mise en oeuvre de rappels de produits ou de lots, lors d'alerte sanitaire par exemple, car il permet de retrouver plus rapidement et de manière agrégée un historique des opérations effectuées sur un produit ou lot donné. Ce système est utilisable pour générer des documents utilisables par un utilisateur pour détecter une fraude ou contrefaçon d'un produit, en ce qu'il permet de détecter un vice dans le cycle de vie du produit: origine de produit non conforme ou non garantie, étape du cycle de vie non certifiée, une information non conforme, une chaîne du froid rompue, etc. Elle permet de mettre en oeuvre de nombreux services de professionnels à professionnels ou de professionnels à particuliers. REVENDICATIONS1. Procédé de génération d'au moins un document électronique de certification de données numériques pour au moins un produit, le procédé comprenant - une étape d'obtention (E250) d'un ensemble de données comprenant - au moins un jeu de données numériques, acquises par au moins un dispositif d'acquisition (DACQ1, DACQ2) et relatives audit produit, - des données de contexte représentatives d'un contexte d'acquisition dudit jeu de données numériques et - des données de déclenchement de règle, - une étape d'identification (E250), sur la base des données de déclenchement de règle, parmi un ensemble de règles de génération de document, d'au moins une règle de génération de document à appliquer, - une étape d'exécution (E250), par application de la règle de génération de document identifiée, d'au moins une vérification de conformité d'au moins une partie de l'ensemble de données, - une étape de génération (E260) d'au moins un document de certification à partir dudit ensemble de données lorsque la vérification de conformité est positive. 2. Procédé selon la revendication 1, dans lequel l'ensemble de données obtenu est relatif à au moins une étape du cycle de vie d'un produit et comprend une identification dudit produit et une identification de ladite étape du cycle de vie. 3. Procédé selon l'une quelconque des revendications précédentes, dans lequel le document de certification est généré pour plusieurs jeux de données numériques acquis successivement pour un même produit, chaque jeu de données numériques étant relatif à au moins une étape du cycle de vie dudit produit. 4. Procédé selon l'une quelconque des revendications précédentes, dans lequel l'ensemble de données reçu comprend des données de certification résultant d'une opération de certification appliquée aux données numériques acquises et/ou aux données de contexte, ladite vérification de conformité comprenant une vérification des données de certification. 5. Procédé selon l'une quelconque des revendications précédentes, dans lequel les données de contexte reçues comprennent au moins une donnée d'identification d'une entité dans le groupe comprenant - le dispositif d'acquisition, - un dispositif source (DSRC1, DSRC2) conçu pour délivrer audit dispositif d'acquisition un jeu de données, - un utilisateur (U1, U2) du dispositif d'acquisition de données, le procédé comprend une étape de vérification consistant à vérifier à partir de la donnéed'identification que ladite entité est référencée dans une base de données. 6. Procédé selon l'une quelconque des revendications précédentes, dans lequel les données de contexte reçues comprennent au moins une donnée d'identification et/ou d'authentification d'un dispositif de certification (DAUTH1, DAUTH2) ayant procédé à une opération de certification sur les données numériques acquises et/ou les données de contexte, le procédé comprend une étape de vérification consistant à vérifier à partir de la donnée d'identification et/ou d'authentification que ledit dispositif d'authentification est référencé dans une base de données. Procédé selon l'une quelconque des revendications précédentes, dans lequel les données de contexte reçues comprennent une donnée d'identification d'un dispositif de certification intervenu préalablement à ladite réception pour authentifier, certifier ou signer au moins une partie des données dudit ensemble de données, le procédé comprend une étape d'interrogation du dispositif de certification pour effectuer une dite vérification de conformité. Procédé selon l'une quelconque des revendications précédentes, comprenant une étape de réception de données de définition d'une règle de génération de document et une étape de stockage desdites données dans une base de données de règles de génération de document, les données de définition comprenant des conditions de déclenchement de règle et une identification d'au moins un type de document de certification à générer lorsque ladite règle est exécutée. Support d'enregistrement lisible par un processeur de données sur lequel est enregistré un programme comprenant des instructions de code de programme pour l'exécution des étapes d'un procédé selon l'une des revendications 1 à 8. Serveur (SRV) de génération d'au moins un document électronique de certification de données numériques pour au moins un produit, le serveur comprenant - un module (I1) d'obtention d'un ensemble de données comprenant - au moins un jeu de données numériques, acquises par au moins un dispositif d'acquisition et relatives audit produit, - des données de contexte représentatives d'un contexte d'acquisition dudit jeu de données numériques et - des données de déclenchement de règle, - un module (ID) d'identification, sur la base des données de déclenchement de règle, parmi un ensemble de règles de génération de document, d'au moins une règle de génération de document à appliquer, - un module (ID 7. 15 8. 20 9. 25 10. 30 35de données, - un module (GEN) de génération d'au moins un document de certification à partir dudit ensemble de données lorsque la vérification de conformité est positive.