Brevet FR3048530A1 — publié le 20170908

SYSTEME OUVERT ET SECURISE DE SIGNATURE ELECTRONIQUE ET PROCEDE ASSOCIE DOMAINE TECHNIQUE DE L'INVENTION [0001] L'invention se rapporte au domaine de la signature électronique. Plus particulièrement, l'invention concerne un système ouvert et sécurisé pour signer un document électronique. L'invention concerne en outre un procédé d'élaboration et de traitement d'une demande de signature. ETAT DE LA TECHNIQUE ANTERIEURE [0002] La signature électronique consiste principalement à permettre à un utilisateur humain de chiffrer l'empreinte d'un document à signer, avec une clé privée correspondant à une clé publique associée à son identité, cette clé privée étant généralement protégée par un dispositif cryptographique et un code secret, le résultat du chiffrement devant ensuite être incorporé ou associé au document à signer de manière à constituer une preuve. Au cours de cette opération, il est nécessaire de s'assurer que l'association entre la clé publique et l'identité du signataire soit certifiée par une autorité compatible avec les exigences de sécurité et de confiance associée à la signature électronique, que cette certification soit vérifiée comme étant toujours valide, et que le signataire soit bien d'accord avec le contenu à signer. [0003] Par ailleurs, l'enchainement des tâches de calcul, de gestion et de vérifications nécessaires à la réalisation d'une signature électronique est excessivement complexe. En effet, les algorithmes sur lesquels s'appuient les calculs doivent eux-mêmes être compatibles avec les exigences de sécurité et de confiance. De plus, les données à signer ne sont pas forcément accessibles directement par le processus de signature mais peuvent être distantes, que ces mêmes données à signer doivent pouvoir être encadrées par des éléments de contexte comme la date et l'heure de la signature, la chaîne de certification du signataire, son rôle, un lieu de signature, une politique de signature, etc. Par ailleurs, la clé privée peut être sur un dispositif cryptographique local ou distant de l'utilisateur, et l'environnement même de ces opérations est tantôt sur le poste de travail de l'utilisateur, mais peut être également distant ou s'exécuter en mode 3048530 2 client-serveur dans un navigateur Web, ou encore sur un smartphone ou une tablette. [0004] Document EP 1393144 B1 divulgue un procédé et un système basé sur le Web permettant la signature juridiquement exécutoire de documents dans un 5 environnement Web. Le système comprend un premier moyen d'accès pour accéder à l'environnement Web depuis un système électronique, et comprend également une pluralité de modules. Un module de rendu du document pour présenter à l'utilisateur une représentation Web du document, un module d'information juridique pour présenter à l'utilisateur, dans l'environnement Web, de 10 l'information juridique relative à la signature électronique du document, et pour obtenir l'accord de l'utilisateur de cette information juridique. Un module d'approbation des documents pour intégrer la signature de l'utilisateur au document, avec l'accord de l'utilisateur de l'information juridique. Le système comprend également un module de journalisation pour générer un journal des 15 processus de la signature du document en associant ce journal de processus avec le document signé. Enfin, un module de distribution de document pour rendre le document signé disponible. Ce document concerne la traçabilité du processus. Il y a un besoin particulier de rationaliser le processus de signature électronique et aussi de masquer la complexité du processus aux utilisateurs. 20 EXPOSE DE L'INVENTION [0005] L'invention a donc pour objet, d'une part, de rationaliser le processus de signature électronique, pour le décomposer en tâches indépendantes dont les interactions entre elles seront sécurisées par des protocoles d'échanges spécifiquement conçus à cet effet, et, d'autre part, de masquer cette complexité 25 aux utilisateurs de la signature électronique et aux applications métiers qui souhaitent la mettre en oeuvre. [0006] Pour ce faire, il est proposé un système ouvert et sécurisé de signature électronique comprenant une application métier, développée et exécutée dans des environnements variés, ladite application métier comportant une interface de 30 programmation apte à effectuer une demande de signature d'un document, auprès d'un gestionnaire de signature, pour un utilisateur. Le système est caractérisé en ce que ladite application métier définie un contenu à signer, des critères 3048530 3 d'identification et de sélection d'un utilisateur signataire, un type d'identité numérique à utiliser, et effectue une collecte des propriétés de signature et exige un format de signature. Ledit gestionnaire de signature est apte à coordonner les étapes de ladite demande de signature en vérifiant l'identité et l'habilitation de 5 l'application métier, en vérifiant l'identité de l'utilisateur signataire, en récupérant ledit document à signer, en préparant la demande de signature avec les calculs d'empreintes des données à signer, via des serveurs de signatures, en envoyant une notification de la demande de signature via un serveur de notification à des services de signatures de l'utilisateur. L'utilisateur, au moyen desdits services de 10 signatures, est apte à contrôler l'exécution du processus de signature en activant une clé privée correspondant à un certificat de l'utilisateur répondant aux critères de sélection envoyés audit gestionnaire de signature par l'application métier en vue du chiffrement de l'empreinte des données à signer. [0007] De préférence, le gestionnaire de signature est apte à vérifier l'identité de 15 l'utilisateur signataire au moyen d'un annuaire d'utilisateurs géré par ledit gestionnaire de signature. Les calculs d'empreintes des données sont effectués soit par un serveur de signature, soit par un serveur de signature inverse. Le gestionnaire de signature est, en outre, apte à récupérer les signatures effectuées et à mettre lesdites signatures à disposition de l'application métier après 20 notification par le serveur de notification. [0008] De préférence, le système comprend en outre des fichiers journaux horodatés et archivés, dans lesquels sont écrites les étapes de la transaction de signature, gérés par le gestionnaire de signature, de sorte à constituer un dossier de preuve pour chaque transaction de signature. 25 [0009] De préférence, le service de signature est un composant logiciel léger et téléchargeable sur un périphérique de l'utilisateur et en ce que ledit périphérique est un PC et/ou un Mac et/ou une tablette et/ou un smartphone dudit utilisateur. [0010] De préférence, l'application métier est apte à effectuer une demande de signature auprès d'un gestionnaire de signature personnel de l'utilisateur, ledit 30 gestionnaire de signature personnel s'exécutant sur le périphérique dudit utilisateur de sorte à permettre audit utilisateur de signer un document en mode local lorsqu'il n'y a pas de connexion Internet disponible ou que le gestionnaire de signature n'est pas utilisable dans ce contexte. 3048530 4 [0011] De préférence, l'utilisateur est apte à signer le document soit à l'aide d'un dispositif de création de signature local pouvant être un composant matériel, tel qu'un dispositif cryptographique, ou logiciel, tel qu'un certificat logiciel accessible sur le périphérique de l'utilisateur soit à l'aide d'un dispositif de création de 5 signature à distance étant apte à incorporer un certificat généré à la volée, lors d'un déplacement dudit utilisateur. [0012]Avantageusement, lesdits certificats générés à la volée ont un niveau de sécurité conforme aux exigences formulées dans la demande de signature envoyée par l'application métier et qu'ils sont apte à effectuer le chiffrement de 10 l'empreinte des données à signer par une clé privée associée. [0013] En outre, les données à signer sont, soit dans l'environnement local de l'application métier sur le périphérique de l'utilisateur, soit dans l'environnement réseau de ladite application métier, auquel accède ladite application métier. [0014] De préférence, le dispositif de création de signature local est sous la forme 15 d'une puce cryptographique ou d'un certificat logiciel accessible localement par l'utilisateur depuis son périphérique, ledit périphérique étant un poste de travail ou un smartphone ou une tablette. [0015] De préférence, le dispositif de création de signature à distance est situé dans l'environnement réseau du gestionnaire de signature et contient un certificat 20 généré à la volée de sorte que le gestionnaire de signature est apte à donner l'instruction à une infrastructure de gestion de clés de générer ledit certificat à la volée et que la clé privée associée audit certificat à la volée étant générée et conservée de manière sécurisée par les serveurs de signatures. [0016] De préférence, le serveur de notification est associé à un environnement 25 d'exécution du service de signature de l'utilisateur de sorte que le gestionnaire de signature au moyen dudit serveur de notification notifie la demande de signature du document auxdites services de signatures de l'utilisateur. [0017] De préférence, le service de signature est apte à s'enregistrer auprès du serveur de notification associé à son environnement d'exécution et communique 30 au gestionnaire de signature qu'il connait les informations qui permettront audit gestionnaire de signature de le notifier. 3048530 5 [0018] :invention concerne encore un procédé d'élaboration et de traitement d'une demande de signature par une application métier d'un document auprès d'un gestionnaire de signature pour un utilisateur, inscrit et identifié auprès dudit gestionnaire de signature, ledit procédé étant mis en oeuvre dans le système 5 décrit ci-dessus et comprend les étapes suivantes : - connexion d'un utilisateur à l'application métier pour signer un document ; - récupération par l'application métier du document à signer ; - interrogation du gestionnaire de signature par l'application métier 10 afin d'identifier l'utilisateur qui doit signer le document ; - envoi d'une demande de signature audit gestionnaire de signature par l'application métier, ladite demande comprend un contenu à signer, des critères d'identification et de sélection de l'utilisateur signataire, un type d'identité numérique à utiliser, elle effectue une 15 collecte des propriétés de signature et exige un format de signature ; - coordination des étapes de la transaction de la signature par le gestionnaire de signature comprenant les étapes suivantes : - vérification de l'identité et de l'habilitation de l'application métier ; 20 - vérification de l'identité de l'utilisateur signataire ; - récupération dudit document à signer auprès de l'application métier; - préparation de la demande de signature avec le calcul de l'empreinte des données à signer,via des serveurs de 25 signatures ; - envoi d'une notification de la demande de signature à un service de signature de l'utilisateur via un serveur de notification ; - contrôle de l'exécution du processus de signature par le 30 service de signature, en activant une clé privée correspondant à un certificat de l'utilisateur répondant aux 3048530 6 critères de sélection envoyés audit gestionnaire de signature par l'application métier ; - horodatage et sauvegarde des évènements de la transaction dans des journaux ; 5 - envoi à l'application métier du résultat des opérations après notification, ou des erreurs éventuellement rencontrées ; - récupération par l'application métier du résultat des opérations ; - mise à disposition de l'utilisateur par l'application métier du résultat. 10 BREVE DESCRIPTION DES FIGURES [0019] D'autres caractéristiques, détails et avantages de l'invention ressortiront à la lecture de la description qui suit, en référence aux figures annexées, qui illustrent : 15 la figure 1 illustre l'architecture générale du système selon la présente invention; la figure 2 illustre les étapes du procédé mis en oeuvre dans le système selon l'invention ; [0020] Pour plus de clarté, les éléments identiques ou similaires sont repérés par 20 des signes de référence identiques sur l'ensemble des figures. DESCRIPTION DETAILLEE [0021] La figure 1 représente l'architecture générale du système selon la présente invention. Cette architecture représente d'une part, l'environnement 1 d'un utilisateur 30 du système et d'autre part l'environnement internet 2 d'un 25 gestionnaire de signature 40. Un utilisateur 30 est une personne physique qui souhaite ou doit signer un ou plusieurs documents. [0022]La distinction entre une signature effectuée à l'initiative même de l'utilisateur ou bien sollicitée par un tiers (autre utilisateur) est essentielle. En effet, l'expérience utilisateur est très différente car, dans le premier cas, celle-ci implique 30 nécessairement une préparation liée au choix du document, à sa rédaction, à la sélection de l'identité numérique et à sa mise en place, à l'éventuelle politique de signature à appliquer, etc., alors que dans le deuxième cas, elle exige une facilité 3048530 7 d'action particulière quant à l'accès au document et à l'identité numérique du signataire pour se focaliser sur la valeur probatoire de la transaction, en contraignant éventuellement l'utilisateur, avant de pouvoir signer, à lire l'intégralité du document, à s'authentifier pour prouver son identité numérique, etc. 5 [0023] L'architecture du système telle que représentée sur la figure 1 comprend une application métier 10, ladite application métier peut être développée et exécutée dans des environnements variés tels que des serveurs Web, des navigateurs Internet, dans un environnement natif PC ou Mac, ou encore depuis un téléphone portable ou une tablette. L'application métier est à l'origine du 10 processus de signature, ainsi, toute demande de signature, qu'elle soit effectuée à l'initiative de l'utilisateur signataire 30 lui-même, ou qu'elle soit effectuée par un tiers en vue de faire signer un document, doit nécessairement passer par cette application métier 10. Ladite application 10 est conçue de sorte qu'elle est apte à effectuer une demande de signature d'un document 20 auprès d'un gestionnaire 15 de signature 40 pour un utilisateur 30. Pour ce faire, l'application métier 10 contient une interface de programmation 42, développée avec des librairies spécifiques, lui permettant de communiquer avec le gestionnaire de signature 40. L'application métier 10 selon l'invention a pour objectif de définir le cahier des charges de la ou des signatures à effectuer, soit définir un contenu à signer, des 20 critères d'identification et de sélection d'un utilisateur signataire 30, un type d'identité numérique à utiliser, effectuer une collecte des propriétés de signature, exiger un format de signature. [0024] L'application métier 10 soumet cette demande de signature au composant central du système, à savoir le gestionnaire de signature 40. Le rôle du 25 gestionnaire de signature 40 est de traiter une demande de signature de l'application métier 10 et de coordonner son exécution en suivant les étapes suivantes : vérification de l'identité et de l'habilitation de l'application métier 10, prise en compte de la demande, identification de l'utilisateur signataire 30, récupération du document 20 à signer indiqué par l'application métier, préparation 30 de la demande de signature avec le calcul d'empreinte des données à signer, via un serveur de signature 50 ou 51, notification de la demande de signature, via un serveur de notification 70 à tous les services de signatures 60 de l'utilisateur 30, et enfin mise à disposition du résultat des opérations auprès de l'application métier 3048530 8 10. Ledit gestionnaire de signature 40 vérifie l'identité de l'utilisateur signataire 30 au moyen d'un annuaire d'utilisateurs 41. Ledit annuaire d'utilisateurs 41 est associé et géré par un ensemble de gestionnaires de signatures 40. [0025] Le ou les documents 20 à signer peuvent être situés dans l'environnement 5 local de l'application métier 10 appelés « DTBS local » 21 (les données locales à signer) en général sur un périphérique de l'utilisateur, et accessibles localement par celui-ci ; dans ce cas il est du ressort de l'application métier 10 de récupérer ces données pour composer la demande de signature à envoyer au gestionnaire de signature 40. Les documents à signer peuvent aussi être situés dans 10 l'environnement réseau de l'application métier 10 appelés « DTBS remote »22 (les données à distance à signer), typiquement dans une GED (outil de gestion électronique de documents) à laquelle accède l'application métier 10 qui pourra ainsi téléverser ces données au gestionnaire de signature 40. [0026]Après la récupération du ou des document(s) 20 à signer par le 15 gestionnaire de signature 40, celui-ci prépare la ou les demande(s) de signature(s) avec les calculs d'empreintes des données à signer, à savoir le contenu du ou des document(s) ainsi que les propriétés. Ces calculs d'empreintes des données sont effectués soit par un serveur de signature 50, soit par un serveur de signature inverse 51. 20 [0027] Le système comprend un dispositif de création de signature 61, il s'agit d'un composant matériel ou logiciel qui permet d'effectuer le chiffrement de l'empreinte des données à signer par la clé privée associée au certificat de l'utilisateur signataire 30. Ledit dispositif de création de signature 61 peut être situé dans l'environnement local de l'utilisateur 30 et être accessible uniquement par celui-ci, 25 typiquement sous la forme d'un dispositif cryptographique (carte à puce, token USB cryptographique) ou d'un certificat logiciel accessibles localement depuis le poste de travail de l'utilisateur ou bien depuis son terminal nomade (smartphone, tablette). Le dispositif de création de signature 61 peut aussi être situé dans l'environnement réseau du gestionnaire de signature 40, référencé 62 sur la 30 figure, typiquement sous la forme d'un certificat généré à la volée par une infrastructure de gestion de clés. En effet, le gestionnaire de signature 40 peut donner l'instruction à ladite infrastructure de gestion de clés de générer ce certificat à la volée. En outre, la clé privée associée audit certificat à la volée de 3048530 9 l'utilisateur 30 étant générée et conservée de manière sécurisée par les serveurs de signatures. L'idée est donc, à chaque signature, de générer un « certificat à la volée » ou « à usage unique » valable pour une seule utilisation. [0028] Le serveur de signature 50 est un serveur de signature centralisé auquel le 5 gestionnaire de signature 40 adresse une demande de signature. Un exemple typique du serveur de signature 50 est le logiciel LP7SignBox développé par la société Lex Persona (demandeur), mais il pourrait être envisagé d'accéder à d'autres serveurs de signature respectant par exemple le protocole DSS d'OASIS (Service de signature digital). 10 [0029] Le serveur de signature inverse 51 est un serveur de signature décentralisé appelé par le gestionnaire de signature 40 pour composer la signature selon un format souhaité, par exemple, pour les signatures, selon les formats : CAdES, PAdES, XAdES, etc. Ledit serveur de signature inverse 51 est en outre apte à calculer l'empreinte de hachage des données à signer dans le cas d'une demande 15 de signature décentralisée. Cette empreinte sera envoyée par le gestionnaire de signature 40 au service de signature 60 de l'utilisateur 30. Le service de signature 60 utilise alors un dispositif de création de signature 61 pour chiffrer l'empreinte avec la clé privée et retourne le résultat de la signature générée au gestionnaire de signature 40 qui la transmet à son tour au serveur de signature inverse 51 qui 20 finalise alors la composition de la signature. Un exemple typique d'un serveur de signature inverse qui offre la fonctionnalité ci-dessus est le logiciel LP7SignBox développée par Lex Persona (Demandeur). Ce cas est particulièrement adapté à la signature décentralisée avec un dispositif de création de signature local 61 sous la forme d'un dispositif cryptographique réalisée depuis un terminal mobile de 25 l'utilisateur (smartphone ou tablette). [0030] Par ailleurs, le gestionnaire de signature 40 notifie les services de signatures 60 de l'utilisateur signataire 30 au moyen d'un serveur de notification 70 afin de notifier ledit utilisateur de signer le ou les documents 20. Pour cela, le gestionnaire de signature 40 envoie des notifications sur les serveurs de 30 notification (push) 70 associés aux services de signatures 60 de l'utilisateur 30. Il est donc nécessaire qu'un service de signature 60 puisse s'enregistrer, dès son lancement, auprès du serveur de notification (push) 70 associé à son environnement d'exécution par exemple : GCM pour Android, APN pour Apple, 3048530 10 WNS pour Windows, etc. Le service de signature 60, associé au périphérique de l'utilisateur, communique ensuite, aux gestionnaires de signatures 40 qu'il connait, les informations qui leurs permettront de le notifier. Un service de signature 60 dispose donc d'un fichier de configuration contenant la liste des gestionnaires de 5 signatures 40 auprès desquels il pourra se déclarer. [0031 ] Un service de signature 60 est une application personnelle universelle, qui permet à l'utilisateur 30 de contrôler l'exécution du processus de signature, à savoir l'activation de la clé privée correspondant à l'un des certificats de l'utilisateur 30 répondant aux critères de sélection envoyés au gestionnaire de 10 signature 40 par l'application métier 10, en vue du chiffrement de l'empreinte des données à signer. Du fait de la séparation entre l'application métier 10, à laquelle l'utilisateur signataire 30 a généralement accès, et le service de signature 60, on pourra qualifier ledit service de signature 60 du terme d'application compagnon. Le service de signature 60 est un composant logiciel qui est le plus léger possible 15 afin qu'il puisse être téléchargé rapidement et prendre le moins de place possible sur le périphérique de l'utilisateur 30. L'interface utilisateur du service de signature 60 est très simple et intuitive avec une identité graphique la plus générale possible. Le service de signature 60 est capable de signer en mode local. En effet dans un environnement Mobile, une connexion Internet peut être absente pendant 20 un instant plus ou moins long, dans ce cas, le service de signature 60 est capable de finaliser la signature sans connexion Internet, ou bien automatiquement dès que la connexion Internet sera de nouveau effective. [0032] Un utilisateur 30 peut posséder plusieurs services de signatures 60, ainsi il est par exemple possible pour l'utilisateur 30 de signer avec un dispositif de 25 création de signature local 61, depuis son poste de travail Windows ou Mac lorsqu'il est à son bureau, à l'aide d'un composant matériel (carte à puce) ou logiciel (certificat),ou bien de signer depuis son Smartphone lorsqu'il est en déplacement, avec un dispositif de création de signature à distance 62 sous la forme d'un certificat généré à la volée. A la seule condition que le niveau de 30 sécurité du certificat à la volée soit conforme aux exigences formulées dans la demande de signature envoyée par l'application métier 10 au gestionnaire de signature 40. 3048530 11 [0033]Le gestionnaire de signature 40 est capable de récupérer la ou des signatures une fois celle(s)-ci effectuée(s) et, dans le cas de signatures enveloppantes ou enveloppées, il procède à la mise en forme de la ou des signatures effectuées. Il est par ailleurs apte à mettre à disposition de l'application 5 métier 10 le résultat des opérations effectuées ou bien des erreurs éventuellement rencontrées. En effet, toutes les étapes des opérations de signatures gérées par le gestionnaire de signature 40 sont écrites dans des journaux. Lesdits journaux sont horodatés et archivés afin de constituer un fichier de preuve complet et sécurisé pour chaque transaction de signature. 10 [0034] Dans certain cas il peut être nécessaire pour un utilisateur de signer un ou plusieurs documents alors qu'aucune connexion Internet n'est disponible ou que le gestionnaire de signature n'est pas utilisable, on parlera dans ce cas de signature en mode local. De tels cas peuvent se présenter lorsqu'il est nécessaire de signer lors d'un déplacement ou bien dans le cas où il n'y a pas de connexion Internet ou 15 l'absence du réseau. Dans ce cas, selon la présente invention, l'application métier 10 pourra soumettre la demande de signature auprès d'un gestionnaire de signature personnel, non représenté sur la figure. Ledit gestionnaire de signature personnel est personnel en ce qu'il est dans l'environnement local de l'utilisateur et en ce qu'il s'exécute sur son poste de travail personnel, quelle que soit la 20 typologie dudit poste de travail, tablette, smartphone... Ledit gestionnaire de signature personnel est apte à effectuer et à coordonner toutes les étapes du processus de signature à l'instar du gestionnaire de signature. Il est à noter que le gestionnaire de signature personnel peut également être sollicité par l'application métier même si l'utilisateur dispose d'une connexion Internet afin de le faire signer 25 de manière directe sans passer par un gestionnaire de signature. [0035]L'annuaire des utilisateurs 41 est associé et géré par un ensemble de gestionnaires de signature 40. Les utilisateurs peuvent êtres de trois catégories. L'utilisateur « Anonyme » : Cet utilisateur est unique par gestionnaire de signature 40, il est non définie et non authentifié. 30 L'utilisateur « Virtuel » : Cet utilisateur est partiellement défini et non authentifié. L'utilisateur « Qualifié » : Cet utilisateur est complètement défini et authentifié par le gestionnaire de signature 40. 3048530 12 [0036]Dans le cas d'une application métier qui souhaite faire signer immédiatement l'utilisateur qui est en train de l'utiliser, il n'est pas nécessaire d'authentifier d'une quelconque manière ledit utilisateur, puisque celui-ci est déjà authentifié par l'application métier. Ainsi l'application métier va signifier au 5 gestionnaire de signature qu'elle connaît déjà l'utilisateur, qui est anonyme pour le gestionnaire de signature, mais pas pour l'application métier. Dans ce cas, l'application métier pourra se charger de lancer le service de signature de l'utilisateur et d'envoyer la demander de signature au gestionnaire de signature personnel qui pourra être packagé avec le service de signature. Eventuellement, 10 si l'utilisateur dispose déjà d'un compte sur un gestionnaire de signature de son choix, il pourra se connecter pour éventuellement récupérer différentes informations et créditer son compte de la signature qui sera effectuée. [0037]Dans le cas d'une application métier qui souhaite faire signer immédiatement l'utilisateur, sans qu'il soit nécessaire de bénéficier d'un utilisateur 15 déjà référencé par le gestionnaire de signature utilisé (« signature rapide » ), on fait confiance à priori à l'utilisateur qui répond à certains critères, alors l'application métier va signifier au gestionnaire de signature qu'elle se contentera d'un `utilisateur Virtuel' qui répondra à certains critères (email, numéro de téléphone portable, etc.). Eventuellement, si l'utilisateur dispose déjà d'un compte sur le 20 gestionnaire de signature spécifié par l'application métier, il pourra se connecter pour éventuellement récupérer différentes informations et créditer son compte de la signature qui sera effectuée. [0038]Dans le cas d'une application métier qui souhaite faire signer immédiatement un utilisateur qu'elle connait comme étant défini et authentifié par 25 le gestionnaire de signature, alors elle pourra spécifier un 'utilisateur Qualifié'. L'utilisateur devra alors s'authentifier sur le gestionnaire de signature sollicité par ladite application métier pour signer le ou les documents. [0039]A chaque utilisateur Qualifié correspond les données suivantes : Identifiant, Empreinte SHA256 du mot de passe de l'utilisateur, Nom et prénom et / ou alias, 30 Date de naissance, Numéro de téléphone sur lequel il est possible d'adresser des messages courts, Adresse Mail, pushTokenlDs correspondants aux dispositifs sur lequel il est possible de notifier l'utilisateur lorsqu'il fait l'objet d'une demande de signature, certificats de l'utilisateur et référence du dispositif de création de 3048530 13 signature associé. Certaines de ces données sont facultatives et peuvent ne pas figurer dans l'annuaire. Cet annuaire d'utilisateurs 41 va permettre à un gestionnaire de signature 40 d'identifier le signataire désigné par une demande de signature qui lui a été adressée par une application métier 10, de sélectionner le 5 certificat approprié correspondant à la demande de signature, d'accéder aux pushTokenlDsde l'utilisateur permettant de le notifier, de notifier cet utilisateur qu'il fait l'objet d'une demande de signaturesur les différents services de signature capables de traiter la demande de signature. [0040] Dans le système de l'invention, trois autres modules sont présents mais 10 n'apparaissent pas sur la figure 1 pour des raisons de lisibilité. Ainsi, le système comprend un annuaire de gestionnaires de signatures. En effet, à partir du moment où il est possible d'avoir différents gestionnaires de signature capables chacun de traiter des demandes de signatures en provenance de différentes applications métiers, il est possible de donner la possibilité à une application 15 métier d'envoyer une demande de signature non pas à un gestionnaire de signature déterminé, mais d'interroger un annuaire de gestionnaires de signature afin d'être en mesure d'identifier le gestionnaire de signature le plus approprié pour traiter la demande. Aussi, si par exemple une application métier permet à un utilisateur de déclarer l'impôt sur la société, il pourrait être pratique à l'application 20 métier d'interroger un annuaire de gestionnaires de signatures afin de sélectionner le gestionnaire de signature « national » qui permettra à l'entreprise de déclarer son impôt dans le pays de l'entreprise. [0041 ] Un autre module du système de l'invention est le serveur IGC. En effet, dans l'architecture de l'invention, le serveur IGC désigne un serveur 25 d'Infrastructure de Gestion de Clés publiques. Son rôle est de délivrer des certificats à la volée aux utilisateurs et dont les clés privées associées sont stockées de manière sécurisée par un serveur de signature qui réalisera les demandes de signature qui lui seront affectées. [0042] Enfin un dernier module concerne une autorité d'horodatage (TSA : Time 30 StampAuthority) délivrant des jetons d'horodatage. En effet, dans le système de l'invention, certains modules nécessitent la possibilité de faire appel à un horodatage, telle que l'écriture de toutes les étapes de la transaction de signature 3048530 14 dans des journaux horodatés ou encore l'horodatage des signatures électroniques générées. [0043] La figure 2 représente les différents étapes du procédé d'élaboration et de traitement d'une demande de signature, par une application métier 10, d'un 5 document 20 auprès d'un gestionnaire de signature 40 pour un utilisateur 30, inscrit et identifié auprès dudit gestionnaire de signature 40, mis en oeuvre dans le système de l'invention et comprenant les étapes ci-dessous. Chaque étape correspond à un ou plusieurs numéros représentés par des flèches. - Connexion d'un utilisateur 30 à l'application métier 10 pour signer un document 10 20 de son environnement local 21. (flèche n°1). - Récupération par l'application métier du document à signer. (flèche n°2 et 3). - Interrogation du gestionnaire de signature 40 par l'application métier 10 afin d'identifier l'utilisateur 30 qui doit signer le document 20. (flèche n°4). - Envoi d'une demande de signature audit gestionnaire de signature 40 par 15 l'application métier 10, ladite demande comprend un contenu à signer, des critères d'identification et de sélection de l'utilisateur signataire, un type d'identité numérique à utiliser, des propriétés de signature et un format de signature. (flèche n° 8). - Coordination des étapes de la transaction de la signature par le gestionnaire de 20 signature 40 comprenant les étapes suivantes : - Vérification de l'identité et de l'habilitation de l'application métier 10 et de l'utilisateur signataire 30 (flèches n°5, 6); - Récupération du document 20 à signer auprès de l'application métier 10 ( flèche n° 7). 25 - Préparation de la demande de signature avec le calcul de l'empreinte des données à signer, via des serveurs de signatures 50 ou 51. (flèches n° 9, 10 ou 11, 12). - Envoi d'une notification de la demande de signature à un service de signature 60 de l'utilisateur 30 au moyen du serveur de notification 70. (flèches n° 13 et 30 16). - Contrôle de l'exécution du processus de signature par le service de signature 60 (flèches n° 14 et 15) en activant une clé privée correspondant à un certificat 3048530 15 de l'utilisateur 30 répondant aux critères de sélection envoyés audit gestionnaire de signature 40 par l'application métier 10. - Horodatage et sauvegarde des évènements de la transaction dans des journaux ; 5 - Envoi à l'application métier 10 du résultat des opérations après notification, ou bien des erreurs éventuellement rencontrées. (flèche n° 17). - Récupération par l'application métier 10 du résultat des opérations ; - Mise à disposition de l'utilisateur 30 par l'application métier 10 du résultat (flèche n ° 18). 10 [0044] De nombreuses combinaisons peuvent être envisagées sans sortir du cadre de l'invention ; par exemple, le document à signer peut être accessible à l'utilisateur localement, sur son poste de travail, ou bien à distance, dans un environnement réseau. De même, le dispositif de création de signature peut être accessible localement, sous la forme d'une carte à puce par exemple, ou bien à 15 distance, dans l'environnement réseau du système, sous la forme d'un serveur de signature avec génération de certificat à la volée. Aussi, le gestionnaire de signature peut être accessible localement ou via le réseau. L'homme de métier choisira l'une ou l'autre des différentes possibilités en fonction des contraintes économiques, ergonomiques, dimensionnelles ou autres qu'il devra respecter. 20 REVENDICATIONS1. Système ouvert et sécurisé de signature électronique comprenant une application métier (10), développée et exécutée dans des environnements variés, ladite application métier (10) comportant une interface de programmation (42) configurée à effectuer une demande de signature d'un document (20) auprès d'un gestionnaire de signature (40) pour un utilisateur (30), caractérisé en ce que ladite application métier (10) est apte à définir un contenu à signer, à identifier des critères et à sélectionner un utilisateur signataire (30), à définir l'utilisation d'un type d'identité numérique, qu'elle est en outre apte à effectuer une collecte des propriétés de signature et à exiger un format de signature ; en ce que ledit gestionnaire de signature (40) est apte à coordonner les étapes de ladite demande de signature en vérifiant l'identité et l'habilitation de l'application métier (10), en vérifiant l'identité de l'utilisateur signataire (30), en récupérant ledit document (20) à signer, en préparant la demande de signature avec les calculs d'empreintes des données à signer, via des serveurs de signature (50, 51), en envoyant une notification de la demande de signature via un serveur de notification (70) à des services de signatures (60) de l'utilisateur (30) et en ce que l'utilisateur (30), au moyen desdits services de signatures (60), est apte à contrôler l'exécution du processus de signature en activant la clé privée correspondant à un certificat (61) de l'utilisateur (30) répondant aux critères de sélection envoyés audit gestionnaire de signature (40) par l'application métier (10) en vue du chiffrement de l'empreinte des données à signer. 2. Système selon la revendication 1 caractérisé en ce que le gestionnaire de signature (40) est apte à identifier l'identité de l'utilisateur signataire (30) au moyen d'un annuaire d'utilisateurs (41) géré par ledit gestionnaire de signature (40), en ce que les calculs d'empreintes des données sont effectués soit par un serveur de signature (50), soit par un serveur de signature inverse (51) et en ce que le gestionnaire de signature (40) est en outre apte à récupérer les signatures effectuées et à envoyer lesdites signatures à l'application métier (10), le serveur de notification (70) étant configuré pour notifier préalablement ledit application métier (10) de l'arrivé desdits signatures. 3048530 17 3. Système selon la revendication 1 caractérisé en ce qu'il comprend en outre des fichiers journaux horodatés et archivés, dans lesquels sont écrites les étapes de la transaction de signature, et en ce que le gestionnaire de signature (40) est configuré à gérer lesdits fichiers journaux de sorte à constituer un dossier de preuve pour chaque transaction de signature. 4. Système selon la revendication 1 dans lequel le service de signature (60) est un composant logiciel léger et téléchargeable sur un périphérique de l'utilisateur (30) et en ce que ledit périphérique est un PC et/ou un Mac et/ou une tablette et/ou un smartphone dudit utilisateur. 5. Système selon la revendication 1 caractérisé en ce qu'il comprend en outre un gestionnaire de signature personnel (41) appartenant de l'utilisateur (30), en ce que l'application métier (10) est apte à effectuer une demande de signature auprès dudit gestionnaire de signature personnel (41), et que ledit gestionnaire de signature personnel (41) s'exécute sur un périphérique dudit utilisateur (30) de sorte à permettre audit utilisateur de signer un document en mode local lorsqu'il n'y a pas de connexion internet disponible ou que le gestionnaire de signature (40) n'est pas utilisable dans ce contexte. 6. Système selon l'une quelconque des revendications précédentes caractérisé en ce qu'il comprend en outre un dispositif de création de signature local (61), sous forme d'un composant matériel ou logiciel, et/ou un dispositif de création de signature à distance (62), l'utilisateur (30) est capable à signer le document (20) soit à l'aide dudit dispositif de création de signature local (61) en utilisant le composant matériel, tel qu'un dispositif cryptographique, ou le composant logiciel, tel qu'un certificat logiciel accessible sur le périphérique de l'utilisateur (30), soit à l'aide du dispositif de création de signature à distance (62), ledit dispositif de création de signature à distance (62) étant apte à incorporer un certificat généré à la volée, lors d'un déplacement dudit utilisateur (30). 7. Système selon la revendication 6 caractérisé en ce que lesdits certificats générés à la volée sont généré de sorte qu'ils ont un niveau de sécurité conforme aux exigences formulées dans la demande de signature envoyée par l'application métier (10). 8. Système selon l'une des revendications précédentes dans lequel l'application métier (10) accède aux données à signer, lesdites données à signer sont situés 3048530 18 soit dans l'environnement local de ladite l'application métier (10), soit dans l'environnement réseau de ladite application métier (10). 9. Système selon la revendication 6 dans lequel ledit dispositif de création de signature local (61) est sous la forme d'une puce cryptographique ou d'un certificat logiciel, l'utilisateur (30) accède localement audit dispositif de création de signature local (61) depuis son périphérique, ledit périphérique étant un poste de travail, ou un smartphone ou une tablette. 10. Système selon la revendication 6 caractérisé en ce que le dispositif de création de signature à distance (62) est situé dans l'environnement réseau du gestionnaire de signature (40) et contient un certificat généré à la volée, et que le système comprend une infrastructure de gestion de clés apte à générer ledit certificat à la volée, et en ce que la clé privée associée audit certificat à la volée étant générée et conservée de manière sécurisée par les serveurs de signatures (50, 51). 11. Système selon l'une quelconque des revendications précédente dans lequel le gestionnaire de signature (40) au moyen du serveur de notification (70) est apte à notifier la demande de signature du document (20) aux services de signatures (60) de l'utilisateur (30), le serveurs de notifications (70) est associé à un environnement d'exécution desdits services de signatures (60). 12. Système selon la revendication précédente dans lequel le service de signature (60) est configuré à s'enregistrer auprès du serveur de notification (70) associé à son environnement d'exécution et à communiquer avec le gestionnaire de signature (40). 13. Procédé d'élaboration et de traitement d'une demande de signature, par une application métier (10), d'un document (20) auprès d'un gestionnaire de signature (40) pour un utilisateur (30), inscrit et identifié auprès dudit gestionnaire de signature (40), mis en oeuvre dans le système selon l'une des revendications 1 à 12 comprenant les étapes suivantes : - connexion de l'utilisateur (30) à l'application métier (10) pour signer le document (20) ; - récupération par l'application métier (10) du document (20) à signer ; - interrogation du gestionnaire de signature (40) par l'application métier (10) afin d'identifier l'utilisateur (30) qui doit signer le document (20) ; 3048530 19 - envoi d'une demande de signature audit gestionnaire de signature (40) par l'application métier (10), ladite demande comprend un contenu à signer, des critères d'identification et de sélection de l'utilisateur signataire, un type d'identité numérique à utiliser, elle effectue une collecte des propriétés de signature et exige un format de signature ; - coordination des étapes de la transaction de la signature par le gestionnaire de signature (40) comprenant les étapes suivantes : - vérification de l'identité et de l'habilitation de l'application métier (10) ; - vérification de l'identité de l'utilisateur signataire (30) ; - récupération dudit document (20) à signer auprès de l'application métier (10) ; - préparation de la demande de signature avec le calcul de l'empreinte des données à signer via des serveurs de signatures (50, 51) ; - envoi d'une notification de la demande de signature à des services de signatures (60) de l'utilisateur (30) via un serveur de notification (70) ; - contrôle de l'exécution du processus de signature par les services de signatures (60), en activant une clé privée correspondant à un certificat de l'utilisateur (30) répondant aux critères de sélection envoyés audit gestionnaire de signature (40) par l'application métier (10) ; - horodatage et sauvegarde des évènements de la transaction dans des journaux ; - envoi à l'application métier (10) du résultat des opérations après notification, ou des erreurs éventuellement rencontrées ; - récupération par l'application métier (10) du résultat des opérations ; - mise à disposition de l'utilisateur (30) par l'application métier (10) du résultat des opérations.