FR 2888443 A1 20070112 FR 0507404 A 20050711 La présente invention concerne un procédé, un serveur et un système de divulgation différée de données, permettant de rendre ces données accessibles à un utilisateur uniquement à partir d'une certaine date, dite date de divulgation des données. Par date de divulgation , on entend le jour prévu de divulgation, associé généralement à l'heure prévue de divulgation. On connaît déjà plusieurs types de procédés permettant de divulguer des informations numériques à des utilisateurs uniquement à partir d'une certaine date. Par exemple, les données sont stockées par un serveur d'hébergement et, au moment de la date de divulgation, leur divulgation est assurée par une publication de l'URL de ce serveur. Un autre exemple consiste à publier l'URL du serveur avant la date de divulgation, et à faire une opération au moment de la date de divulgation: soit stocker les données dans le serveur, soit les rendre accessibles en autorisant leur accès ou en les décryptant. Le problème consiste en ce que chacun de ces procédés nécessite le déroulement d'une opération spécifique pour divulguer les données, cette opération devant être exécutée à la date exacte de divulgation, ce qui nécessite un certain nombre de programmations. En outre, pour que les opérations soient exécutées exactement à la bonne date, il est nécessaire que le serveur connaisse une heure sûre, ce qui nécessite un équipement particulier. La présente invention vise à résoudre ces inconvénients en fournissant un procédé de divulgation différée des données qui n'est pas contraint à exécuter une opération précisément à la date exacte de divulgation. A cet effet, l'invention a pour objet un procédé de divulgation différée de données, permettant de rendre ces données accessibles à un utilisateur uniquement à partir d'une certaine date, dite date de divulgation des données, les données étant stockées en association avec leur date de divulgation, caractérisé en ce qu'il comprend les étapes suivantes: réception d'une requête d'accès aux données, émise par un utilisateur, attribution d'une date à la requête, dite date de la requête, comparaison de la date de la requête avec la date de divulgation, - si la date de la requête est postérieure à la date de divulgation, établissement de l'accès aux données pour l'utilisateur. Grâce à ce procédé, il n'y a pas d'opération à prévoir, de la part du serveur d'hébergement ou d'un administrateur de la divulgation, à la date exacte de divulgation des données. Ce n'est qu'au moment où un utilisateur demande à accéder aux données que l'on vérifie si cette demande a lieu ou non après la date de divulgation stockée avec les données. Ainsi, le serveur de divulgation répond à des requêtes des utilisateurs, il n'a pas besoin d'être actif au moment précis de la divulgation. Dans un mode de mise en oeuvre particulier, l'attribution de la date est réalisée par un module d'horodatage. De préférence, la date de la requête est attribuée de la façon suivante: génération d'un aléa, envoi de l'aléa au module d'horodatage, horodatage de l'aléa par le module d'horodatage, - utilisation de la date fournie par l'horodatage en tant que date de la requête. Selon un mode de mise en oeuvre particulier, l'envoi de l'aléa au module d'horodatage comprend une première étape d'envoi de l'aléa à l'utilisateur, et une seconde étape d'envoi de l'aléa au module d'horodatage, par l'utilisateur. Ainsi, ce n'est pas le serveur qui doit gérer les opérations d'horodatage, il demande à l'utilisateur de le faire, le serveur n'a plus qu'à recevoir la date de la requête et la comparer à la date de divulgation. Eventuellement, les données sont stockées également en association avec une date de fin de divulgation, et le procédé comprend une étape de comparaison de ladite date de la requête avec la date de fin de divulgation, et une étape d'établissement de l'accès si la date de la requête est antérieure à la date de fin de divulgation. Ceci est particulièrement avantageux par rapport aux procédés de l'état de la technique, selon lesquels il était nécessaire de prévoir d'autres opérations spécifiques pour ne plus rendre accessibles les données à partir de la date précise de fin de divulgation. Grâce à ce mode de mise en oeuvre, aucune opération spécifique n'est prévue à la date de fin de divulgation, il suffit que le serveur stocke cette date et qu'il vérifie qu'elle n'est pas dépassée lorsqu'un utilisateur demande à accéder aux données. Selon un mode de mise en oeuvre particulier de l'invention, permettant de s'assurer que l'horodatage a été effectué sans fraude, le procédé comporte également les étapes suivantes: - réception, avec la date de la requête, d'un certificat d'horodatage authentifiant un module d'horodatage ayant fourni la date de la requête, et - refus de l'accès aux données si le certificat d'horodatage n'appartient pas à une liste prédéfinie de certificats d'autorités de confiance. Selon un autre mode de mise en oeuvre de l'invention, permettant de gérer des droits d'accès aux données, le procédé comprend les étapes suivantes: - extraction, à partir de la requête d'accès, d'un certificat d'authentification de l'utilisateur, refus de l'accès aux données si le certificat d'authentification de l'utilisateur n'appartient pas à une liste de certificats authentifiant des personnes autorisées à accéder aux données. Eventuellement, les données stockées ayant été émises par un émetteur, le stockage est précédé par une authentification mutuelle de l'émetteur et des moyens de stockage. Cette authentification assure la confidentialité de l'échange et l'intégrité des données envoyées au serveur. L'invention a également pour objet un serveur de divulgation différée de données, apte à rendre les données accessibles à un utilisateur uniquement à partir d'une certaine date, dite date de divulgation des données, les données étant associées à leur date de divulgation, comportant des moyens d'établissement de l'accès aux données pour l'utilisateur, caractérisé en ce qu'il comporte en outre: - des moyens de réception d'une requête d'accès aux données, - des moyens d'attribution d'une date à la requête, dite date de la requête, - des moyens de comparaison de la date de la requête avec la date de divulgation, - des moyens d'activation des moyens d'établissement d'accès lorsque ladite date de la requête est postérieure à la date de divulgation. De préférence, le serveur comporte des moyens de stockage des données en association avec leur date de divulgation. Selon un mode particulier de réalisation, le serveur comporte un module d'horodatage, apte à attribuer la date de la requête. Dans ce cas, l'horodatage de la requête est effectué directement par le serveur de divulgation différée, et sans intervention de l'utilisateur, ce n'est pas un serveur d'horodatage distinct qui le fait. L'invention a enfin pour objet un système de divulgation différée de ces données, comportant un serveur de divulgation différée tel que décrit cidessus, connecté à un serveur d'horodatage et/ou un serveur d'hébergement des données en association avec leur date de divulgation. L'invention sera mieux comprise à la lecture de la description qui va suivre, donnée uniquement à titre d'exemple et faite en se référant aux dessins dans lesquels: la figure 1 est un schéma d'un système de divulgation différée de données selon un premier mode de réalisation de l'invention; - la figure 2 est un schéma de fonctionnement du système de la figure; et - la figure 3 est un schéma d'un système de divulgation différée de données selon un second mode de réalisation de l'invention. Comme on peut le voir sur la figure 1, un système selon l'invention comporte un serveur 10 de divulgation différée, relié à un réseau de communication tel que le réseau Internet 12. Le serveur de divulgation 10 est apte à rendre des données accessibles à un utilisateur à partir d'une certaine date, dite date de divulgation des données. A cet effet, il comprend des moyens 14 de stockage de données que l'on souhaite divulguer, constitués d'une base de données. Les moyens 14 sont capables de stocker les données en association avec leur date de divulgation. Les données stockées dans les moyens 14 ont été fournies, via le réseau Internet 12, par un terminal émetteur 16. Selon un mode de réalisation non représenté, les moyens de stockage 14 sont dans un serveur d'hébergement extérieur, connecté au serveur 10, éventuellement par le réseau 12. L'utilisateur souhaitant accéder aux données se sert d'un terminal utilisateur 18, connecté, par le réseau Internet 12, au serveur 10, ainsi qu'à un module d'horodatage, constitué d'un serveur d'horodatage 20. Le serveur de divulgation 10 comporte des moyens 22 de réception d'une requête, des moyens 24 d'attribution d'une date à la requête, et des moyens 26 de comparaison de la date de requête attribuée par les moyens 24 à une date de divulgation stockée dans les moyens 14. Les moyens de réception 22 sont aptes à extraire de la requête un certificat d'authentification de l'utilisateur. Les moyens 24 d'attribution d'une date de requête comportent des moyens 30 de génération d'un aléa, des moyens 32 d'envoi de cet aléa au terminal utilisateur 18, des moyens 34 de réception de l'aléa horodaté et des moyens 36 d'extraction de la date de l'aléa et d'un certificat d'authentification de l'autorité ayant horodaté l'aléa. Le serveur 10 comporte également des moyens 37 de contrôle que la date de requête a été émise par une autorité de confiance, des moyens 38 de contrôle d'autorisation de l'utilisateur à accéder aux données et des moyens 39 d'établissement de l'accès aux données stockées dans les moyens 14. Les moyens de comparaison 26 comprennent des moyens d'activation des moyens 39 d'établissement d'accès. Le procédé de divulgation différée de données, illustré sur la figure 2, est mis en oeuvre de la façon suivante. Au cours d'une étape préalable 40, le terminal émetteur 16 se connecte au serveur de divulgation différée 10 dans le but de lui envoyer des données 44 à stocker. L'étape 40 consiste en l'authentification mutuelle du terminal émetteur 16 et du serveur 10. Cette authentification comprend par exemple l'envoi au serveur 10 d'un certificat d'authentification du terminal émetteur 16 et l'envoi au terminal 16 d'un certificat d'authentification du serveur 10, en utilisant le protocole HTTPS SSL V3. L'étape 40 est suivie d'une étape 42 de transmission des données 44, et de stockage par les moyens 14, ces données étant associées à une date de divulgation D, et à une date de fin de divulgation D2. Selon un autre mode de réalisation, les données ne sont associées qu'à la date de divulgation D,. Au cours de l'étape 42, le terminal émetteur 16 transmet également au serveur 10 une liste 46 de certificats d'authentification d'autorités dites de confiance, correspondant à des certificats de serveurs d'horodatage en qui l'émetteur utilisant le terminal 16 a confiance. L'émetteur transmet enfin une liste 48 de certificats d'authentification des personnes autorisées à accéder aux données 44. Selon un autre mode de mise en oeuvre non représenté, les listes 46, 48 ne sont pas transmises au cours de l'étape 42 mais ont été préalablement stockées dans le serveur 10. Lorsqu'un utilisateur du terminal 18 souhaite accéder aux données 44, il émet une requête d'accès vers le serveur 10, au cours d'une étape 49. Après réception 50 de la requête, on passe à une étape 52 de vérification des droits d'accès de l'utilisateur. Au cours de cette étape, les moyens 22 extraient de la requête le certificat d'authentification de l'utilisateur et vérifient, à l'aide des moyens 38, que ce certificat fait partie de la liste 48, c'est-à-dire que l'utilisateur du terminal 18 est autorisé à accéder aux données. Si ce n'est pas le cas, on passe à une étape 53 selon laquelle le terminal 18 reçoit, de la part du serveur 10, un message de refus de l'accès. Si la vérification 52 est positive, elle est suivie d'une étape 54 de génération d'un aléa par les moyens 30, puis d'une étape 56 d'envoi de cet aléa au terminal utilisateur 18. Cet aléa est constitué de données aléatoires. L'étape 56 est suivie d'une étape 58 de réception de l'aléa par le terminal utilisateur 18, suivie d'une étape 60 d'envoi de l'aléa au serveur d'horodatage 20. Le serveur d'horodatage 20 reçoit cet aléa et l'horodate au cours d'une étape 62, c'est-à-dire qu'il signe numériquement cet aléa en conjonction avec la date d de réception de l'aléa, plus précisément le jour et l'heure, donnés par une source sûre. Le serveur d'horodatage 20 associe également à l'aléa horodaté, son certificat d'authentification. On passe ensuite à une étape 64 au cours de laquelle le serveur 20 envoie l'aléa horodaté au terminal utilisateur 18. A la réception de l'aléa horodaté, le terminal 18 transmet l'aléa horodaté au serveur de divulgation 10 au cours d'une étape 66. A la suite de la réception 68 de l'aléa horodaté par les moyens 34, on passe à une étape 69 d'extraction du certificat d'authentification du serveur 20. L'extraction 69 est suivie d'une vérification 70, par les moyens 37, que le certificat d'horodatage du serveur 20 appartient à la liste 46 des certificats des autorités de confiance. Si ce n'est pas le cas, on passe à une étape 71 selon laquelle le terminal 18 reçoit, de la part du serveur 10, un message de refus de l'accès. Ainsi, il n'est pas possible que l'utilisateur fournisse une date de façon frauduleuse au serveur de divulgation, celui-ci étant capable de détecter que le certificat d'horodatage n'est pas celui d'une autorité prédéfinie comme autorité de confiance. Si la vérification est positive, elle est suivie d'une étape 72 d'attribution d'une date à la requête. L'étape 72 consiste à extraire, grâce aux moyens 34, la date d de l'aléa, cette date étant définie comme la date de la requête d. On passe ensuite à une étape 74 de comparaison, par les moyens 26, de la date de requête d à la date de divulgation D, stockée dans les moyens 14. L'étape 74 est suivie d'une étape de test 76 sur le résultat de cette comparaison. Si la date de la requête d est antérieure à la date de divulgation D, stockée dans les moyens 14, cela signifie que la requête d'accès a été émise avant la date D,, on passe donc à une étape 78 de réception, par le terminal utilisateur 18, d'un message de refus de l'accès de la part du serveur 10. Si la date de la requête d est postérieure ou égale à la date de divulgation D,, cela signifie que le terminal utilisateur a émis sa requête après la date de divulgation, on passe à une étape 82 de comparaison de la date de la requête d à la date de fin de divulgation DÉ L'étape 82 est suivie d'une étape 84 de test sur le résultat de la comparaison. Si la date de la requête d est postérieure ou égale à la date de fin de divulgation Dg, le procédé est ramené à une étape 85 de réception, par le terminal utilisateur 18, d'un message de refus de l'accès de la part du serveur 10. Si la date de la requête d est antérieure à la date de fin de divulgation D2, cela signifie que l'utilisateur a émis la requête d'accès avant la date de fin de divulgation, et l'on passe à une étape 86 d'activation des moyens 39 par les moyens 26. A la suite de cette étape, le serveur de divulgation différée 10 envoie les données 44 au terminal utilisateur 18. L'étape est suivie d'une étape 88 de réception de ces données par l'utilisateur. Selon un mode de mise en oeuvre particulier de l'invention, non représenté, le serveur de divulgation 10 interroge directement le serveur d'horodatage 20, sans passer par le terminal utilisateur 18. Selon un autre mode de réalisation du système de divulgation selon l'invention, visible sur la figure 3, le serveur de divulgation 10 comporte un module d'horodatage 90, jouant le rôle du serveur d'horodatage 20 pour attribuer une date à la requête émise par le terminal utilisateur 18. De préférence, l'ensemble des échanges entre le terminal utilisateur 18 et le serveur de divulgation 10 est sécurisé, en utilisant par exemple le protocole HTTPS SSL V3. Selon un autre mode de réalisation du système selon l'invention, les moyens de stockage 14 ne sont pas hébergés par le serveur 10, mais par un serveur d'hébergement extérieur, éventuellement relié au serveur 10 par le réseau Internet 12. Le procédé reste dans le cadre de l'invention si les données ne sont associées qu'à une date de divulgation D, et pas à une date de fin de divulgation D2. Dans ce cas, l'activation des moyens 39 est effectuée à la suite du test 76. REVENDICATIONS 1. Procédé de divulgation différée de données, permettant de rendre ces données accessibles à un utilisateur (18) uniquement à partir d'une certaine date (D,), dite date de divulgation des données, les données étant stockées en association avec leur date de divulgation, caractérisé en ce qu'il comprend les étapes suivantes: - réception (50) d'une requête d'accès aux données, émise (49) par un utilisateur, -attribution (72) d'une date (d) à la requête, dite date de la requête, 10 comparaison (74) de la date de la requête (d) avec la date de divulgation (pi), - si la date de la requête (d) est postérieure à la date de divulgation (D,), établissement (86) de l'accès aux données pour l'utilisateur. 2. Procédé selon la revendication 1, selon lequel l'attribution de la date de la 15 requête (d) est réalisée par un module d'horodatage (20). 3. Procédé selon la revendication 2, au cours duquel la date de la requête (d) est attribuée de la façon suivante: - génération (54) d'un aléa, envoi (56, 60) de l'aléa au module d'horodatage (20), horodatage (62) de l'aléa par le module (20) d'horodatage, utilisation (64, 66) de la date fournie par l'horodatage en tant que date de la requête (d). 6. Procédé selon la revendication 3, dans lequel l'envoi de l'aléa au module d'horodatage comprend une première étape (56) d'envoi de l'aléa à l'utilisateur, et une 25 seconde étape (60) d'envoi de l'aléa au module d'horodatage, par l'utilisateur. 7. Procédé selon l'une quelconque des revendications 1 à 4, dans lequel les données sont stockées également en association avec une date de fin de divulgation (D), et le procédé comprend une étape (82) de comparaison de ladite date de la requête (d) avec la date de fin de divulgation (W, et une étape (86) d'établissement de l'accès si la 30 date de la requête est antérieure à la date de fin de divulgation. 8. Procédé selon l'une quelconque des revendications 1 à 5, comportant également les étapes suivantes: réception (68), avec la date de la requête, d'un certificat d'horodatage authentifiant un module d'horodatage ayant fourni la date de la requête, et refus (71) de l'accès aux données si le certificat d'horodatage n'appartient pas à une liste prédéfinie (46) de certificats d'autorités de confiance. 7. Procédé selon l'une quelconque des revendications 1 à 6, comprenant les étapes suivantes: extraction (52), à partir de la requête d'accès, d'un certificat d'authentification de l'utilisateur, - refus (53) de l'accès aux données si le certificat d'authentification de l'utilisateur n'appartient pas à une liste prédéfinie de certificats authentifiant des personnes autorisées à accéder aux données. 8. Serveur de divulgation différée de données, apte à rendre les données accessibles à un utilisateur uniquement à partir d'une certaine date, dite date de divulgation (D) des données, les données étant associées à leur date de divulgation, comportant des moyens (39) d'établissement de l'accès aux données pour l'utilisateur, caractérisé en ce qu'il comporte en outre: - des moyens de réception (22) d'une requête d'accès aux données, - des moyens d'attribution (24) d'une date à la requête, dite date de la requête, - des moyens (26) de comparaison de la date de la requête (d) avec la date de divulgation (D,), des moyens d'activation (26) des moyens (39) d'établissement d'accès lorsque ladite date de la requête (d) est postérieure à la date de divulgation (D,). 11. Serveur selon la revendication 8, comportant en outre des moyens (14) de stockage des données en association avec leur date de divulgation (D,). 12. Serveur selon la revendication 8 ou 9, comportant un module d'horodatage (20), apte à attribuer la date de la requête. 13. Système de divulgation différée de données, comportant un serveur de divulgation différée selon l'une quelconque des revendications 8 à 10, connecté à un serveur d'horodatage et/ou un serveur d'hébergement des données en association avec leur date de divulgation.