FR 2872607 A1 20060106 FR 0407313 A 20040701 PROCEDE D'ARCHIVAGE ELECTRONIQUE DE DOCUMENTS La présente invention se rapporte au domaine de l'archivage des documents électroniques La présente invention se rapporte plus particulièrement à un procédé de mise sous coffre électronique de documents électroniques garantissant l'intégrité des documents sur de très longues périodes. L'art antérieur connaît déjà des procédés d'archivage de documents électronique. Ces procédés permettent de conserver des documents, de les indexer et de gérer les modalités d'accès aux documents. Cependant, ces procédés ne permettent pas de garantir la restitution de l'information et son contexte au moment du stockage, ainsi que les évolutions contextuelles et l'historique de ces évolutions. La gestion de la pérennité des documents et des contextes peut être résolue par l'utilisation des métadonnées. En effet, dans ce cas, la lecture des documents est assurée non plus par une actualisation des versions d'un player, mais par une actualisation des règles de transformation. Le contenu du document ne dépend alors plus de la forme du document. Dans le domaine du stockage sous forme de métadonnées, l'art,antérieur connaît déjà la demande US 2003/0216983 (IBM) décrivant un procédé permettant de placer des reçus de 30 client dans un coffre-fort associé à un utilisateur en utilisant le schéma XML. L'art antérieur connaît également, par la demande de brevet Européen EP 1248996 un procédé d'archivage qui associe au document à archiver un ensemble de métadonnées servant au classement des archives ainsi qu'à la récupération des documents. L'art antérieur connaît également, par la demande de brevet US 2004/0002989 un système de gestion de l'archivage de données par un dispositif robotique. Le fichier à archiver est associé à un ensemble de métadonnées permettant la récupération et le stockage des fichiers à archiver. Cependant, aucun document de l'art antérieur ne garantit la pérennité du document puisque seul est stocké le fichier électronique lui-même. Or, dans le futur, ce fichier, hors des contextes de lecture et d'interprétation n'a pas de valeur. Cet inconvénient est alors particulièrement limitant dans le cadre du stockage de données légales, comme les signatures électroniques ou les factures. Aucun document de l'art antérieur ne permet également de garantir la traçabilité de ces données légales et des différentes évolutions des liens entre ces données. Dans tous les brevets cités de l'art antérieur, c'est donc une image statique du document qui est archivée et non pas une image dynamique du document lui-même et des différentes actions ou transactions appliquées à ce document. La présente invention entend remédier à cet inconvénient de l'art antérieur en proposant un procédé d'archivage électronique permettant de collecter les données environnementales avec le document ainsi que les différentes transactions associées au document. On comprendra mieux l'invention à l'aide de la description, faite ciaprès à titre purement explicatif, d'un mode de réalisation de l'invention, en référence aux figures annexées où : - la figure 1 représente le schéma d'envoi des méta-documents pour l'archivage; - la figure 2 représente un exemple de transaction réalisée sur une des fonctions d'archivage; - la figure 3 représente l'envoi des méta-documents 10 par bloc vers le centre d'archivage; - la figure 4 représente un exemple de système utilisé pour l'implémentation du procédé d'archivage selon l'invention; - la figure 5 illustre la représentation de 15 l'invention comme un ensemble de couches de transactions. La base de données (2) de la figure 4 comprend les différentes fonctions d'archivage. Afin de réaliser l'archivage dynamique de l'ensemble de l'historique d'un document et des données environnementales associées au document, un ensemble de fonction F= (F1, F2, ..., Fn) sont en effet utilisées. Ces fonctions représentent d'une part des données propres au fichier à archiver. Ces données peuvent être par exemple le format du fichier, la personne ayant réalisé l'archivage (identifiant des coordonnées de l'utilisateur), le lieu du stockage (identifiant du coffre où est stocké le fichier, d'un dossier de stockage) ou les autorisations d'accès attribuées au document sous forme de différents mandats (mandats d'accès à un coffre, mandat pour le stockage au sein du coffre, mandat pour la récupération de fichiers du coffre). Il est entendu que la liste des données associées à un 5 fichier à archiver ne doit pas limiter la portée de la présente invention. Ces données peuvent également être des données d'indexations attribuées au document par l'utilisateur du système lors de l'archivage. Cette indexation peut apparaître sous forme de mots clés pour la récupération du document. Par ailleurs, les fonctions (F1, F2, ..., Fn) 15 comprennent également des données correspondant non pas au fichier lui-même mais à son environnement d'utilisation. Ces données sont par exemple des liens vers d'autres fichiers ou tout autre information conservée, l'historique des modalités d'accès au document, l'historique des index de recherche ou un historique de l'interprétation du document. Toutes les fonctions sont applicables dans un environnement correspondant à une zone mémoire appelée salle des coffres . Cette salle des coffres constitue la zone mémoire où sont stockées toutes les données avant envoi vers le tiers archiveur. D'où le nom de salle des coffres comme mémoire tampon avant l'accès aux coffres forts électroniques connus. Ainsi, illustré figure 4, le système d'archivage selon l'invention est constitué d'une interface utilisateur (1). Cette interface est par exemple une interface http ou Web services de type Soap. Il est entendu que la technologie utilisée pour l'interface utilisateur n'est pas limitative et ne doit pas réduire la portée de la présente invention. Elle permet à l'utilisateur de sélectionner le fichier à archiver et de lui associer des mots clés de recherche. Elle lui permet également d'effectuer des opérations sur des archives pré-existantes. Ces informations sont reçues par la mémoire de stockage (3), qui transmet alors les informations à la base de données relationnelle (2). Cette base de données est de type connu, par exemple Oracle ou MySQL. Les informations reçues créent donc des modifications sur un certain nombre de champs de la base de données (2). 15 Ces modifications constituent des transactions. Ainsi, comme illustré figure 1, une transaction sur une fonction Fi va entraîner la modification d'une sous-base de données BDi. Cette interaction entre les fonctions élémentaires et la base de données relationnelle est connue de l'homme du métier dans le domaine des bases de données. L'idée originale de la présente invention est alors d'archiver une description de la présente sous-base BDi. La description de cette sous-base est par exemple réalisée dans un schéma XML. Un méta-document est donc crée pour toute transaction sur les fonctions prédéfinies. C'est ce méta-document qui sera envoyé vers le centre d'archivage, éventuellement accompagné d'un fichier à archiver. Par ailleurs, comme illustré figure 2, le fait même d'effectuer des modifications sur les fonctions Fi et donc sur les sous-bases BDi constitue lui-même une transaction spécifique au sens d'une modification de la base globale (2). Cette transaction est donc enregistrée en créant un nouvel ensemble de fonctions FF représenté par exemple par les fonctions FN+I à FN+PÉ Ainsi, la création de ces nouvelles fonctions correspondant aux actions réalisées permet d'établir la relation entre l'information à archiver et les actions réalisées sur l'information. Différentes couches de fonctions sont alors présentes dans la base de données relationnelle (2) après itération du procédé selon l'invention, comme illustré figure 5. La couche Fm permet de restituer l'ensemble des transactions de la base de données et donc de reconstituer l'historique des modifications sur une fonction initiale Fi. Par ailleurs, la description des transactions de façon sémantique, par exemple selon un schéma XML permet de ne plus distinguer l'information elle-même et son contenu. En effet, toute modification future du schéma sera enregistrée comme une transaction sur la fonction DTD XML (Définition du Type de Document), assurant ainsi la pérennité de l'archivage. Une fois la description des fonctions ayant subies une transaction réalisée, un ensemble de N méta-documents est alors créé. Le procédé d'archivage de ces documents peut alors varier selon les caractéristiques du tiers-archiveur. Il est de préférence défini par un contrat d'interchange avec celui-ci. Nous décrirons ici un mode de réalisation de cet envoi, étant entendu qu'il ne limite pas la portée de l'invention. Selon ce mode de réalisation, cet envoi est réalisé 5 par e-mail. Pour des raisons de capacité d'envoi et de gestion de documents, les métadocuments sont envoyés par blocs. Ces blocs possèdent: - une taille limite en Mo; - un nombre de méta-documents limite; un âge limite, le bloc ne pouvant pas rester plus d'un jour dans une mémoire tampon de la mémoire de stockage. Le sujet de l'e-mail contient alors d'une part: un identifiant du bloc envoyé contenant les méta-documents ou une partie d'un méta-document; un identifiant de propriété de la salle des coffres où sera stocké le bloc; un identifiant de la salle des coffres elle-même; - un identifiant de l'archive. Il contient également d'autre part: - la date d'expiration de l'archive; la version du format de l'archive liée à la DTD utilisée pour le métadocument. Notons que l'envoi du format de l'archive garantie l'interprétation du méta-document à archiver. La pièce jointe contient au format XML l'ensemble des méta-documents correspondant aux fonctions (F1, ..., Fn) de la figure 1, associés au bloc d'envoi. Ces méta-documents sont indexés et complétés éventuellement par des pièces jointes sous forme de fichier, par exemple.pdf ou.doc (le fichier qu'un utilisateur désire archiver). Le corps de l'e-mail contient la DTD nécessaire à l'interprétation du méta-document et une description complète des documents envoyés en pièce jointe constituant le bloc. La description complète des pièces jointes permet donc d'envoyer des métadocuments quelconques, sans forcement de liens entre eux et pouvant correspondre à un archivage issu de différents utilisateurs. Le contenu des blocs envoyés dépend donc des trois critères décrits précédemment (taille limite, nombre de méta-documents limite, âge limite), mais pas du contenu des méta-documents en tant que tel, ce contenu étant lui, décrit dans le corps de l'e-mail. Il est également important de noter que la pièce jointe ne comprend pas nécessairement de fichier à stocker, puisqu'une transaction telle que décrite plus haut ne correspond pas forcément à l'archivage d'un fichier, mais peut être de façon plus générale, l'attribution d'un accès à un ou plusieurs documents, une modification de l'organisation des fichiers, un changement d'adresse utilisateur. Toutes ces transactions sont envoyées dans la partie XML de la pièce jointe et décrites dans le corps de l'email. Avec ce mécanisme d'envoi, tous les documents sont donc envoyés avec l'ensemble des informations de traçabilité relatives au document et à l'utilisation même du système. Nous allons maintenant décrire un exemple d'interface utilisateur (1) permettant la collecte des fichiers ou des différentes transactions sur les fichiers afin de compléter la description de l'ensemble du système. Cette collecte s'effectue en 4 étapes: É Etape 1 sélection du type de transaction, par exemple 10 grâce à une liste déroulante; - sélection éventuelle du fichier à archiver par parcours du disque dur de l'utilisateur; sélection du dossier de destination; - contrôle des formats standardisés garantissant la 15 lisibilité sur 3, 10 ou 30 ans. É Etape 2 - désignation des index par clef de recherche, version ou format É Etape 3 - sélection des liens vers d'autres fichiers déjà archivés. É Etape 4 Validation finale entraînant la mise à jour de la mémoire de collecte et de la base de données (2). L'invention est décrite dans ce qui précède à titre d'exemple. Il est entendu que l'homme du métier est à même de réaliser différentes variantes de l'invention sans pour autant sortir du cadre du brevet. REVENDICATIONS 1. Procédé d'archivage utilisant une base de données relationnelle et un centre de stockage, caractérisé en ce 5 qu'il comprend les étapes consistant à : - générer au moins une fonction correspondant à au moins un attribut d'archivage; - générer au sein de ladite base de données relationnelle, au moins une sous-structure de base de données correspondant à une transaction associée à ladite au moins une fonction; générer au moins une description de ladite sous-structure de base de données; - envoyer ladite au moins une description sous forme 15 de méta-document au niveau dudit centre de stockage; - générer au moins une nouvelle fonction correspondant à ladite transaction. 2. Procédé d'archivage selon la revendication 1, caractérisé en ce que, dans le cas où ladite transaction correspond à la collecte d'un fichier, l'étape d'envoi de ladite description s'accompagne de l'envoi dudit fichier. 3. Procédé d'archivage selon la revendication 1, caractérisé en ce que ladite description de ladite sous-structure de base de données correspond à une description XML. 4. Procédé d'archivage selon la revendication 1, 30 caractérisé en ce que l'étape d'envoi de ladite au moins une description est réalisée par email. 5. Procédé d'archivage selon au moins une des revendications précédentes, caractérisé en ce que ledit fichier est placé en pièce jointe dudit email. 6. Procédé d'archivage selon au moins une des revendications précédentes, caractérisé en ce que ladite description est placée en pièce jointe dudit e-mail. 7. Procédé d'archivage selon la revendication 1, caractérisé en ce que ladite au moins une fonction correspond à au moins un identifiant de la localisation dudit archivage. 8. Procédé d'archivage selon la revendication 1, caractérisé en ce que ladite au moins une fonction correspond à un mandat d'accès à ladite localisation dudit archivage. 9. Procédé d'archivage selon au moins une des revendications précédentes, caractérisé en ce que le corps dudit e-mail comprend au moins une description du contenu de la pièce jointe dudit e-mail.