FR 2828951 A1 20030228 FR 0110983 A 20010822 disque compact. Système informatique et procédé dé gestion de documents La présente invention relève du domaine des systèmes informatiques, notamment des serveurs aptes à la gestion de documents. Dans le cadre d'un réseau informatique avec communication de données à distance, par exemple le réseau Internet, les documents que l'on souhaite mettre à disposition d'autres utilisateurs sont présentés selon une forme particulière généralement appelée langage de balisage. Le langage de balisage HTML définit un jeu de balises fixes qui dépend de la version l O du lang age et qui est orienté vers une présentati on donnce. Il a permi s le développement de l'échange de données hypertextuelles au travers d'Internet. Les différentes normes HTML ont défini comment les butineurs (browsers) doivent représenter des données HTML. Pour plus de renseignements sur HTML on peut se référer au site lS http://www.w3.org. Plus récemment, a été développé le langage XML qui est un langage de constitution de donnces adaptées pour représenter de la documentation structurée. Un document dit structuré est un document qui contient à la fois du texte, des images mais aussi des indications du rôle joué par chaque élément de texte: le titre d'un paragraphe, la légende d'une image, le contenu d'une marque de bas de page. Le langage XML ou Langage extensible de balisage (eXtensible Markup Language en langue anglaise) permet de matérialiser la structure du document et de se focaliser sur le rôle des éléments, la sémantique, plus que sur la forme de représentation. Le langage XML ne fixe ni la sémantique, ni le jeu de balises utilisé. L'affichage ou l'impression d'un document XML impose de définir comment les donnéès s'affichent ou s'impriment, par programme ou soit utilisant des feuilles de style. Dans le langage XML, les informations doivent être soit encadrées par des balises ouvrantes et fermantes avec imbrication possible, soit incluses à l'intérieur même des balises par exemple: . Ici l'attribut SUJET de l'élément LIVRE a la valeur " XML >. La norme XML peut se trouver à l'adresse.http://www.w3.ora/TR/REC - OXML Le langage XML permet de saisir ou de mettre à jour une seule fois un contenu sans se soucier de la présentation ou du traitement futur et sans avoir à saisir des libellés tels que " auteur ", " année de parution ", etc. sans avoir à mettre les titres en italique, en d'autres termes exactement à la manière dont on alimenterait une base de données. Le langage XML permet également de générer ensuite automatiquement de multiples présentations avec éventuellement des tris, sélection, réorganisation, génération automatique de libellé, table des matières, index, etc; et ce sur de multiples mediasj écrans, papiers, terminaux braille, etc. Les serveurs existants en langage XML sont essentiellement conçus en vue de faciliter la recherche d'informations sur la base de critères quelconques. Les langages de requête associés à XML, par exemple de type XQL, SXQL, XUPDATE, etc désignent les balises à partir d'une description de chemin dans l'arborescence XML. Or, ce mode de fonctionnement est mal adapté à une gestion fiable et fine de droits d'accès à des documents ou à des parties de documents. En effet, l'arborescence est en constante évolution dans un contexte multintilisateur avec ajout ou effacement de sous arbres par les différents utilisateurs, et dépend des droits d'accès. A titre d'exemple soit une balise comprenant deux sous balises de rang inférieur auquel trois utilisateurs accèdent simultanément à un instant donné ou à tout le moins dans un état donné à des instants proches. Supposons que le premier utilisateur ajoute une troisième sous balise à la balise et renvoie la balise au serveur au moyen d'une requête . adaptée, puis que le deuxième utilisateur supprime la première sous balise de la balise et renvoie la balise au serveur au moyen d'une requête adaptée à un instant ultérieur à l'ajout de la troisième sous balise. Puis qu'enfin, le troisième utilisateur envoie une requete de modification de la deuxième sous balise. Le serveur prendra en compte la requête du troisième utilisateur en l'appliquant à la troisième sous balise et non pas à la deuxième en raison du classement relatif des sous balises. Ce - -. - '-- ' - _.. _ _ _ A _ ' 0'. _: _: _ _ ':. _ _ -.. - - _ ': . _ _: .: _ _ _ _.. _ _ _ 4. _ _ _ _ _. _ _. _. _. __ _ _, _ _ _ _ _ _ _,,, _,,. _ classement relatif des sous balises pose également des difficultés dans le . - cadre du filtrage des utilisateurs selon leur droit d'accès. L' invention propose un système de partage de documents adapté à un contexte multiutilisateurs et à la gestion des droits d'accès. L' invention propose un système qui permet de résoudre les problèmes évoqués ci-dessus, de réaliser sans ambiguïté les mises à jour effectuées par différents utilisateurs et ainsi de leur permettre de travailler simultanément sur des balises différentes d'un même document. Le système informatique apte à la gestion de documents selon un aspect de l' invention, comprend au moins un serveur, au moins un poste client apte à échanger des données avec le serveur, au moins un document stocké par le serveur et susceptible d'être envoyé par le serveur à un poste client déterminé, et un moyen de désignation absolue du document, de façon que l'accès audit document soit sûr. Le poste client peut être un autre serveur, un ordinateur, par exemple de type PC, un ordinateur de poche, du genre organiseur personnel, un poste de téléphone équipé de moyens de communications Internet, un radiotéléphone, par exemple de type WAP et plus - généralement tout moyen de traitement de l' information équipé de moyens de communication avec un réseau. Dans un mode de réalisation, le système comprend un moyen de désignation absolue de balise ou partie du document, chaque balise étant associce à une étiquette, une étiquette étant associce à une seule balise. Avantageusement, le système comprend un moyen pour générer une requête de document ou de balise d'un document. Les requêtes peuvent être indépendantes les unes des autres. Dans un mode de réalisation, le système comprend un réseau de communication entre le serveur et le poste client. Avantageusement, au moins une étiquette est attribuée à au moins un document. Avantageusement, au moins une balise est identifiée de façon unique par une étiquette. Toutes les balises peuvent être identifices par une étiquette. -..-' 'À... _ _! _._ _ __....,,. _.... _..,_ _.. _ _ _... _ -,__ -,,, - -. -.., _ _ _ _ L' invention propose également un serveur informatique apte à la - gestion de documents et comprenant un moyen pour échanger des données avec au moins un poste client, un moyen pour stocker au moins un document, un moyen pour envoyer un document à un poste client déterminé, et un moyen de désignation absolue du document, de façon que l'accès audit document soit sûr. Avantageusement, le serveur comprend un moyen pour attribuer une étiquette unique à chaque balise ou partie de document. L,invention propose également un programme d'ordinateur comprenant des moyens de code programme pour faire fonctionner le serveur tel que décrit ci-dessus, lorsque ledit programme fonctionne sur un moyen de traitement ou un ordinateur. L'invention propose encore un procédé de gestion de documents, dans lequel on échange des donnces entre au moins un serveur et au moins n poste client, le serveur stockant au moins un document et l'envoyant à un poste client déterminé, le document étant désigné de façon absolue de façon que l'accès audit document soit sur. Dans un mode de réalisation, un document est mis simultanément à la disposition de plusieurs postes clients. Avantageusement, un document est divisé en balises ou parties, chaque balise étant associce à une étiquette et une étiquette étant associce à une seule balise de document. Une étiquette est associce à une balise de document de façon stable dans le temps. L'invention propose encore un programme d'ordinateur comprenant des moyens de code programme pour mettre en _uvre les étapes du procédé ci- dessus, lorsque ledit programme fonctionne dans un moyen de traitement de serveur ou sur un ordinateur. L' invention permet un partage efficace de document grâce à l'étiquetage unique et systématique par le serveur de toutes les balises des documents. L'étiquetage rend les documents un peu plus volumineux mais conduit à une expression concise et non ambiguë des requetes de modifications. (n supprime ainsi d'éventuels conflits ou incertitudes lors de requêtes de modification ou de requêtes d'accès. :: s En outre, il est particulièrement avantageux d'associer cet étiquetage systématique à un procédé de gestion des versions d'un document. Chaque utilisateur peut indiquer la version de la balise du document dont il dispose, ce qui permet au serveur par comparaison avec des numéros de versions associés à chaque balise sur le document commun, d'arbitrer les concurrences d' accès. L' invention propose d'exprimer les droits d'accès sous la forme d'attributs. Les différents modes de réalisation de l'invention s'intègrent de façon efficace au format XML et permettent d' assurer de nombreuses fonctionnalités utiles sur un serveur de document tel que association de fichiers ou de documents, administration de comptes, notions de domaines, application de feuilles de style... A titre d'exemple, l'invention s' applique de façon intéressante aux applications de télémédecine visant à partager les dossiers médicaux de patients entre un ensemble de professionnels de la santé. Dans ce domaine, les fonctionnalités de gestion des droits d'accès se révèlent extrêmement uti les et le partage de l' information médicale répond à un besoin tant des organismes de santé que des praticiens eux-mêmes. La présente invention sera mieux comprise à l'étude de la description détaillée d'un mode de réalisation pris à titre d'exemple nullement limitatif illustré par les dessins annexés, sur lesquels: - la figure 1 est un schéma de l' architecture du système; - - la figure 2 est un schéma de fonctionnement d'un logiciel selon un aspect de l'invention; - la figure 3 est un schéma du système selon les différents types de client; - la figure 4 est un schéma d'organisation des docoments; et - la figure 5 est un organigramme montrant l'enchaînement retenu pour la consultation d'un dossier client de type médical à partir d'un téléphone portable WAP. Comme on peut le voir sur la figure 1, un serveur 1 est associé à .. - un stockage de donnces 2 à grande capacité, par exemple un disque dur qui a été représenté ici de façon externe mais qui pourrait être intégré au serveur 1. Le serveur 1 est également associé à un serveur http 3, à un serveur de messagerie électronique 4 et à un autre serveur 5 de standard non précisé. Le serveur http 3 est relié à une passerelle WAP 6. Ces différents serveurs ou passerelles 3 à 6 sont chacun prévus pour communiquer avec des postes client dont l'un référencé 7 a été représenté, par l'intermédiaire d'un réscau de communication 8 de type filaire, par fibre optique, ou encore hertzien. Le serveur 1 comprend une mémoire-9, un bus de communication , une interface de communication 11 avec des serveurs extérieurs, notamment les serveurs 3 à 5, une interface 12 avec le stockage de données 2, une unité de calcul et de traitement 13 comprenant au moins un microprocesseur et une mémoire 14 qui peut être de taille inférieure à la mémoire 9 mais à temps d'accès réduit. Le serveur 1 est équipé d'une pluralité de logiciels stockés dans la mémoire 9 et pouvant également être stockés dans la mémoire 14 pour être exécutés par l'unité 13. Les mémoires 9 et 14, les interfaces 11 et 12 et l'unité 13 communiquent au moyen du bus de communication 10. L'interface 11 peut être de type CGI. Un document, par exemple sous format XML, de l'utilisateur est stocké sous forme de fichier. L'organisation du stockage est illustrée sur la figure 2. Le logiciel 15 stocké dans la mémoire 9 et/ou 14 et exécuté par l'unité 13 permet de traiter de tels documents. Un document 16 est susceptible d'être émis ou reçu par le logiciel 15 et stocké sous la forme de fichier, dans le stockage de données 2. Certaines informations issues du document 16 doivent être stockées dans une base de données relationnelle 18 par l'intermédiaire d'un système de gestion de base de données 19, afin d'en faciliter l'accès. Il s'agit essentiellement des valeurs des éléments susceptibles d'apparaître dans les listes de documents. Ces éléments sont préalablement déclarés au serveur par l'intermédiaire d'un méta-document tel que décrit plus loin. Un fichier 17 associé au document 16 peut également être rangé dans un répertoire sans traitement particulier. A la création d'un méta-document, les tables utiles à la gestion des documents XML correspondants sont générées dans la base de données relationnelle 18. En l'absence de balise " Ref " parmi les éléments à lister, il n'y a qu'une table, avec autant de colonnes que d'éléments. S'il faut gérer des balises " Ref " dans les listes, des tables additionnelles sont créées puisque la balise peut prendre des valeurs différentes en fonction des domaines. Après chaque opération sur un document XML, les valeurs des éléments des listes sont à la fois mises à jour dans le fichier 16 et dans la base de données relationnelle 18. Le tableau ci-dessous montre le principe de stockage d'un document XML possédant des champs " Ref ". Documents X&1L (cRef I="O">AO 1 _ 1 | ( A1 l J I Elelncllsa. lirc R=f I="O">BO 1 ,> apparaitre dans CRéf I="1">B1 1 _ _ ' I lalistodes _ 3 | (1octnients - _ 4) EO 1 . cPef I="] ">-1 1 BO 2 C 2 D 2 <> EO 2 E1 2 F 2 Basc rclationnelle list 20 I c 1 D ref 20 1 I | co: .e ref 0 1l 1 A0_1 I 1 Tables acllitionnc:lcs ref.0_ p>urgererlesr;lércn.ces J cr; is les li; rcs Un même document ou dossier peut être accédé simultanément en lecture ou en écriture par plusieurs utilisateurs. Pour éviter les problèmes classiques d'écrasement de données ou d'incohérence, un mécanisme de gestion de version est prévu dans le logiciel lS. Le serveur l attribue un compteur de version à chaque document XML et marque chaque balise modifiée ou créée avec la valeur courante du compteur, sous la forme d'un attribut noté " V ". Chaque utilisateur qui demande un dossier au serveur est informé de la valeur courante du compteur, attribut " V " au niveau de la racine. Il doit restituer cette valeur lors d'une opération de modification. Le serveur compare la valeur indiquée avec la valeur dont il dispose pour les balises concernces par les modifications ou les créations. Pour une balise donnée, le serveur contrôle en fait les versions de toutes les balises pères et de toutes les balises fils. Si l'une des versions est supérieure à la version de l'utilisateur, la requête de modification est rejetée. En d'autres termes, on ne peut modifier un champ que si la valeur dont on disposait lors de la lecture du champ n'a pas été modifiée entre temps. Le tableau ci- dessous illustre l'algorithme de gestion des versions. ffZ' r />r /;S ^ _.. \:/B, *. /C> {E>_ /Z> + ' _ v-z,,^ v-> ModiOcallon de la : +: (moilOcnCon de :; É:: et out da) _ _ À-, " v l, odiÈcslon de la 7'/":) bal [se - - _ + <>._ /,/ /A,,, Tentatl\ e de R Els m oil E c all o n de _ ReLls ReRls6 car l'tln des gls (solt ) 6[! modLh C s Il convient de remarquer que l'utilisateur n'est pas informé de la !version de chaque balise. I1 ne connaît que la version de l'ensemble du dossier. L'algorithme prévu effectue un verrouillage optimiste. La technique du verrouillage pessimiste c'est-à-dire du verrouillage initial des parties du document destiné à être modifié peut être réalisé par l'utilisateur en jouant sur les droits d'accès, par exemple en plaçant un droit exclusif d'écriture sur les parties concernées du dossier avant de procéder à leurs modifications, puis en restituant les droits initiaux après l'opération. La mémorisation des versions permet également au serveur 1 de repérer les balises modifiées par rapport à une version intérieure du document. Ceci permet d'indiquer à l'utilisateur les balises " fichiers " modifiées par rapport à une version locale sur un poste client. Il n'est pas possible, en revanche, de reconstituer sur le serveur la liste des balises èffacces. Mais cette information peut être aisément déduite par le client lui-même. Ainsi, I'invention propose un serveur de document au format XML ou équivalent destiné à permettre le partage de ces documents par un ensemble d'utilisateurs. Ce serveur se place au centre d'une architecture client serveur et rend des services comparables à ceux d'un système de gestion de base de données relationnelle, mais avec des documents XML. Ces services peuvent comprendre la définition de compte d'utilisateur, le stockage de documents de manière transparente pour l'utilisateur, la gestion des accès aux documents suivant des règles précises, la recherche de documents sur la base de certains critères, 1'exécution de requêtes transactionnelles... Par rapport à une base de données relationnelle, l' adoption du format XML pour représenter les données permet en outre d'arbitrer efficacement les accès en écriture aux différentes parties d'un document, de fixer très finement les droits d'accès, à un niveau quelconque de l'arborescence XML, d'associer des fichiers binaires aux docaments, ou encore de donner un accès direct au serveur à un large éventail de plateformes et de logiciels clients. Bien entendu, l' invention réduit au strict minimum les contraintes imposces aux documents XML hébergés tout en rendant l' architecture du serveur indépendante des données - traitées. Pour permettre l'accès au serveur à une grande variété de clients ou d'utilisateurs, le protocole d'invocation des fonctions du serveur est le plus simple possible. Il est donc prévu des requêtes indépendantes les unes des autres, en l' absence de notion de session, un fonctionnement transactionnel, c'est à dire qu'une requête est soit annulée, soit exécutée en totalité et si l' on excepte la description des fichiers joints qui peuvent être de format varié, un format purement ASCII pour les requêtes, et, qui plus est. de type XML, comme pour les documents manipulés. L'invention de fonctions à travers des requêtes XML rejoint le principe du protocole SOAP (SIMPLE OBJECT ACCESS PROTOCOLE en langue anglaise). Une formulation plus simple et spécifique au traitement de documents XML peut être choisie. Sanf demande par le client ou l'utilisateur d'un fichier binaire associé à un document, le serveur répond également par un message XML. Tout logiciel capable de dialoguer sous format XML avec le serveur, selon le protocole de communication adéquat (http, ou autre), peut a priori jouer le rôle de client. Pour permettre un accès direct au serveur, c'est à dire sans logiciel intermédiaire, à partir de clients de type navigateur html ou wml, un mécanisme de transformation de la réponse XML à l'aide de feuilles de style peut être intégré au serveur. La simplicité de l'accès au serveur et les possibilités d' application de feuilles de style conduisent à une large variété de clients potentiels qui peuvent être un autre serveur, un ordinateur, un ordinateur de poche, un téléphone Web, un radio téléphone Wap, etc. Le rôle du serveur est de permettre le partage de documents XML entre plusieurs utilisateurs. On se fixe également pour objectif d' assurer une sécurité de fonctionnement élevée, de gérer avec rigueur les accès et notamment les questions de droits d'accès et de concurrences d'accès, d'ouvrir le système à un éventail aussi large que possible de plateformes et de logiciels clients ainsi que de réduire au strict minimum les contraintes imposées aux documents XML hébergés. Le serveur assure entre autre le service de gestion de comptes d'utilisateurs avec des fonctions d' administration (création, modification, effacement, liste...), - profil d'utilisateur, domaine d'appartenance et authentification par cartes à puce, et la gestion de documents XML avec les fonctions d'administration, d'arbitrage des accès concurrents, de contrôle des droits d'accès avec filtrage des données, de gestion des fichiers joints et d' application de feuilles de style au document. Pour des raisons lices au principe de fonctionnement du serveur et à la sécurité, on introduit deux exigences de syntaxe. Tout d'abord, chaque donnée doit être comprise entre une balise ouvrante et la balise fermante correspondante. On exclut donc le cas de figure suivant: Ceci n'est pas autorisé. et l'ordre d'écriture des balises n'a pas d'importance. Tous les documents ou objets gérés par le serveur sont désignés de manière unique par des identifiants générés par le serveur lui-même. Le format des identifiants est celui d-'un nombre en base 36 (composé des chiffres de 0 à 9 et des lettres de A à Z). Les identifiants de fichiers comprennent, en plus, une extension alphanumérique qui en indique le type, par exemple ".doc ". L' application hébergée sur le serveur est accessible avec les protocoles HTTP ou HTTPS. La nature du protocole n'a pas d'incidence sur le fonctionnement, de sorte que d'autres sites d'accès peuvent être envisagés, par exemple avec un protocole SMTP pour un accès en différé, par messagerie électronique... Tout logiciel capable de générer une requête au format XML, d'interpréter la réponse au même format, sauf en cas de lecture d'un fichier associé à un document, et de communiquer via le réscau avec le protocole adéquat (HTTP, HTTPS, WAP, SMTP...) est susceptible de . jouer le rôle de client lorsqu'il est exécuté par une unité de calcul et de trai temen t. Afin de donner également un accès direct, sans logiciel intermédiaire, au serveur à des clients légers de type navigateur HTML ou WML, on associe au serveur un processeur de feuilles de style XSL qui peut réaliser une transformation de la réponse XML vers HTML ou WML. La feuille de style à utiliser est indiquée dans la requête, sous la l:: forme d'une adresse URL ou d'un nom de fichier local au serveur. Pour - formuler des requêtes XML dans l'environnement des navigateurs, on s'appuie sur les langages de script disponible tels que JAVAscript, VBscript, WMLscript Le recours aux feuilles de style se justifie essentiellement pour les clients logers, c'est-à-dire téléchargés. Les clients dits lourds, c'est-à dire les applications installées sur le poste client, généralement écrits dans un langage de haut niveau, pourront généralement interpréter directement une réponse XML du serveur. Les différents flux lO d'informations, au format XML ou dérivé, sont présentés sur la figure 3. Les données relatives à l'administration du système sont représentées sous la forme de documents XML de structure imposée, contrairement à celle des documents utilisateurs décrits plus loin. Un attribut " D " caractérise le type de document. D = 0 indique un méta document, D = l indique un compte d'utilisateur, D = 2 indique un profil de compte, D = 3 indique un domaine. Ainsi, en considérant par exemple un document décrivant un domaine, sa valeur sera toujours égale à 3. Un domaine (D = 3) désigne un ensemble d'utilisateurs qui partagent un même système d'indexation des informations, par exemple les numéros de référence de dossiers. Un domaine est caractérisé par un nom unique selon la syntaxe suivante: nom de domaine (nom unique) Par exemple: . Clinique du X 3 0 La noti on de do mai ne permet de ré ali ser une gesti on au tom ati que des numéros de référence par le serveur, quelque soit le document considéré. Chaque référence sera délimitée par une balise réservée "Ref", avec la syntaxe suivante référence - Considérons un document qui contient, à un endroit quelconque de l'arborescence XML, les lignes suivantes: altai N 77 a8364 Un utilisateur du domaine I="9" qui accède au document ne verra en fait que la ligne suivante: lO alt-nic-77. 3 Un compte permet à un utilisateur de se connecter au serveur. Il est identifié par le couple (nom de comte; domaine), par son identifiant interne (attribut I à la racine) ou par un numéro de clef. ..:'.'.', toPtionnel) nom d'utilisateur prénom civilité cSexe> M Ou F nom du do.aine toptionnel) nom du compte (uniaue sur le domaine) fo,otionnelJ .. (répétition éveneuelle de 1e balise ) (optionnel, non accessJble en lecture) .ot de passe brcuillé 0UI o' NO.'I (dé'eut) nom du profil (optior,nel si non ectif) :oi ret ion> foptionnel) ac.resse e-..ail (lecture seule) prénom + nom d'utilisateur préno. + no.m a'utilisater action (en c*s d'erreur) _ La valeur de la balise correspond à f(P), c'est- à dire à une fonction de brouillage appliquée au mot de passe. La longueur de cette valeur peut être comprise entre 10 et 25 caractères. Ce champ n'est pas renvoyé par le serveur. Il est créé par le logiciel client pour modifier le mot de passe du compte. Tous les champs du bloc sont générés par le serveur et ne peuvent être modifiés. Les balises et rappellent certains paramètres du dernier accès au serveur avec le compte considéré.Cette information peut s'avérer utile pour gérer une reprise après rupture de liaison au cours d'une requête. La requete s d' identification du compte n' est volontairement pas tracée. En écriture, le domaine et le profil peuvent être désignés par leur nom ou l'attribut . Tout utili sateur d' un compte est autorisé à vi suali ser son propre dossier et à modifier son mot de passe. La notion de clef a été introduite afin de permettre des identifications rapides de comptes à partir d'un identifiant unique et dans certains cas une authentification de l'utilisateur. Une clef est caractérisée par un type, un identifiant unique pour un type donné (numéro de série, numéro du porteur,...), et, éventuellement, un protocole cryptographique d'authentification. Une clef est décrite avec la synthaxe suivante: La présence d'une clef au niveau d'un compte (balise ) n'impose pas l'utilisation de cette clef pour l'accès au compte. C' est dans la description du profil de compte que l'imposition de ce type de contrainte est défini. Le profil d'utilisateur permet d'associer un certain nombre de droits, tels que l' accès aux documents, l' administration de comptes, etc et de contraintes telle que l'authentification à chaque compte. Le profil d'utilisateur peut être définit comme suit: nom du profil (no.m unicue) 0UI fdéfaut) cu NON - 0UI {detaut) OU NC'I 0UI ou NON (défaut) 0UI ou l.5:1 (défaut) r.o. du profil 3,.... (répétition éventuelle de la b=lise ) v :;-': flecture seule) no:" c'.é.r7-douinent 0UI ou NON (détaut) CAuthentification> 0UI ou NO;] (défart) lU - U.\ (éÉ=ut) 0-! P=RSOA!./EL ot! TOUS AUCU.V fdéfaL'tJ ou P^RSO,V,'L ou lOUS ! CVI ou l}ON (df2,tJ OUr ou NOH {c-faut) 0UI ou llO.V féfaut) CBlocChemin> chen:in accesslble dns le cacr!me..t ... (répétition de " Che.in ") 10.... (ré,oétition de " Doc "J Soit à titre d'exemple: Patient ,. Dossier patient ERSO;4NL - 10N NON NON NOM Patient/A-ninistratif Pa tient Gene ra 1 Dossier professionnel PERSONN- L NON NON NO; , iOt!c/Archivags> Professio:nnelC/Cr, emin> r Plus particulièrement, le bloc définit les - paramètres obligatoires pour l'authentification des comptes possédant ce profil. Ainsi, une valeur pour la balise indique, par exemple, la nécessité de présenter un mot de passe non vide pour l'accès au compte. Pour la balise , le type doit correspondre à une clef d'authentification. En l'absence de l'attribut n'importe quelle clef du type indiqué ouvre l'accès au compte. Mais cette clef ne permet pas, à elle seule, d' identifier le compte car il faut préciser un nom de compte et un nom de domaine. Si l'attribut est présent (avec une l0 valeur vide) cela signifie qu'un numéro de clef précis est requis au niveau du compte. Dans ce cas, la clef permet à la fois l' identification et l'authentification du compte. Le bloc décrit les possibilités d' administration de comptes liées au profil. Dans le bloc la valeur lS restreint les droits d' administration au domaine d'appartenance du compte. Le bloc conditionne l'accès à la liste des comptes. Le bloc permet d' imposer une authentification des utilisateurs des comptes administrés. Les profils administrables sont précisés au bloc . Un profil avec une valeur pour la balise " Domaine " ne peut administrer un profil avec une valeur permet d'interdire l'accès à ce type de document en l' absence d'une balise correspondant à un type de document. Le bloc précise si la liste des documents est accessible à l'utilisateur. Le bloc indique en cas de valeur que l'accès au document n'est possible que si un compte a été associé au document (attribut au niveau de la racine du document). Il convient d'indiquer dans la requête les donnces d'identification et d'authentification requises pour ce compte. Les blocs et permettent de définir les accès. En cas de valeur , aucun accès n' est autorisé, en cas de valeur " ", l' accès est autorisé aux parties accessibles des dossiers personnels tei que défini par les droits d'accès définis dans les documents. En cas de valeur l'accès aux parties accessibles de tous les documents est autorisé. En l' absence de balise ou , tous les chemins sont accessibles en lecture et en écriture, c'est à dire en modification. Les chemins avec A="W" sont accessibles en lecture et en écriture. Les autres le sont uniquement en lecture. S'il y a des chemins A="R" sans aucun chemin A= "W", aucune modification n'est autorisée. Tout type de document XML hébergé par le serveur doit être décrit au préalable par un document qualifié de " méta-document ". Cette exigence est liée à la nécessité de pouvoir gérer efficacement des listes de documents. Un méta-document décrit en fait les éléments des documents que l'on désire voir figurer dans les listes et sur la base desquelles on effectue les sélections. La structure d'un méta-document est illustrée ci-dessous. ..... CNom> no. du mata-document (nom unigue) C/Nom> (optionnel) escription de l'élément chemin (sans la racine) ae l'élé.. ent dans le docament cnemin de l'élément dans la liste de docaments _ (optionnel) taille (nb de caract.) usue?le de l'élé.-.ent taille maxinale da l'élément 25. .. (répéti ti?n de " Elem ") Y X M M s .... À .... Y2 X2 F Y X M Y3 X3 M Si le chemin d'accès à l'élément dans le document est vide, le nom de la balise racine apparat dans la liste. La taille usuelle des éléments de méme que le champ de description ne sont pas utilisés par le serveur. Ces informations, optionnelles, sont simplement destinces à faciliter le formatage de liste de documents quelconques par les postes clients. Si la tai lle maximale est dépassce, l' information est tronquce dan s la li ste mais pas dans le document. I1 est possible de lister des valeurs d'attribut ou de placer des valeurs d'attribut dans la liste. I1 suffit d'indiquer le . nom de l'attribut et la suite du chemin, avec la syntaxe suivante: Chemin/@ nom de l'Attribut Une liste peut inclure plusieurs balises . Les accès aux éléments des listes dans les documents ne tiennent pas compte des éventuels droits d'accès spécifiés dans ces documents. Les utilisateurs possèdent une grande latitude pour structurer leur document XML. Seuls quelques attributs et balises sont interprétés par le serveur. Au niveau de la racine, l'utilisateur doit toujours préciser le type de document dont il s'agit, c'est-à-dire indiquer, avec l'attribut " D " l'identifiant du méta-document correspondant. Les attributs " I " et "V " sont quant à eux générés par le serveur. Il convient de les rappeler au serveur lors d'une modification ultérieure du document. Le compteur de version permet au serveur de gérer les concurrences d'accès. L'attribut " C " permet éventuellement d'associer le document à un compte. Pour l'utilisateur de ce compte, il s'agira d'un dossier personnel auquel il pourra avoir un accès privilégié. Chaque balise d'un document est automatiquement marquce par le serveur par un identifiant unique, sous la forme d'un attribut " B " qui permet ensuite au logiciel client de désigner efficacement une balise quelconque du document pour réaliser une modification. On a par exemple: ... L'attribut "A " permet à l'utilisateur de spécifier les droits d'accès sur une partie du document. Les utilisateurs autorisés à accéder à cette balise peuvent être décrits par leur compte, leur profil ou leur domaine, plus précisément par leur compte pour un utilisateur précis, par leur profil pour des utilisateurs ayant un profil déterminé et particulier et par un domaine pour tous les utilisateurs d'un domaine. On peut spécifier toute une liste d'utilisateurs. On peut avoir par exemple: A="R: c9A" Lecture: compte " 9A " A="R:cR52+p4E/W:c67" Lecture: compte > ou profil " 9A " Les restrictions d'accès se corabinent en parcourant les chenins dans le document à partir de la racine. Les restrictions d'accès se combinent en parcourant les chemins dans le document à partir de la racine. Le principe de l'utilisation de la balise a déjà été décrit ci dessus. Un utilisateur d'un domaine donné ne peut crcer ou modifier de référence sur un autre domaine. Par contre, l' effacement est autorisé pour i Le princpe de l'utilisation de la balise a déjà été décrit ci dessus. Un utilisateur d'un domaine donné ne peut créer ou modifier de référence sur un autre domaine. Par contre, l' effacement est autorisé pour éviter des situations d'interblocage. La balise constitue une feuille dans l'arborescence XML. La balise permet de faire référence à un fichier externe au document géré en bloc par le serveur. La balise fichier utilise des attributs et "I "et" S" générés par le serveur, voir ci-dessous. La balise ne contient généralement pas de valeur. Les balises des chemins déclarés dans le méta-document doivent étre respectées si l'on désire voir apparaître leur valeur dans la liste des documents. Lors du dialogue entre le client et le serveur, le format général d'une requête est le suivant: LIRE ou LIR FICHIE.R ou LIST=R ou l:ODIFIE.x Oil CREER ou ARCHIVER ou SUPPRIl'--R ou AUTRENTIFIER À.. tchaps spécifiques à chaque action) _ .. (éventuellement: données relatives aux fichiersJ La réponse du Se7,eUI suit la trame cidessous (saUf si n ficlier a été demandé): .. (connées >:.:_) E' cas d'crrer, le messac idique au mininun ui code d'eTetr: g cSer-ice V=" " T=" "> CErreur I="id de l'erreur"> description de l'erreur C/Erreur> cInfo> L'attribut de version " V " exige du client qu'il indique pour quelle version du serveur il a été conçu. Cela permet au serveur de rejeter des requêtes obsolètes, en invitant l'utilisateur à réaliser une mise à jour de ses moyens informatiques. Si un identificateur est attribué à la requête par le client, sa valeur sera rappelée dans la réponse du serveur sous l'attribut " I ". Les attributs " StyleSheet ", " StyleErr " et " StyleProcess " sont utiles pour effectuer une transformation des documents XML à l' aide de feuilles de style XSL, à l'URL " StyleSheet " si le traitement se passe correctement et, à l' URL " StyleError " en cas d' erreur. Si " StyleProcess " est égal à " NON " et qu'une URL de feuille de style est spécifiée, ladite URL est recopiée en tête des données XML renvoyées: Si " StyleProcess " est égal à "OUI ", le serveur réalise lui même la transformation du résultat XML de la requête avec les feuilles de style spécifiées (qui, dans ce cas, doivent être locales au serveur) L'attribut de date " T " n'est pas vérifié par le serveur. Si l'on ne dispose pas aisément de cette information, par exemple sur un téléphone mobile, en WML script, il suffit d'initialiser l'attribut à une valeur quelconque. L'attribut " Requête/Compte/K " correspond à un code calculé dépendant du mot de passe de l'utilisateur. Il peut prendre différentes formes selon les capacités de calcul du poste client. Il s'agit d'un mécanisme de précaution pour dissuader les velléités d'accès non autorisé. Un compte peut étre désigné de plusieurs manières, par son identifiant unique par Ie nom du compte et le nom de domaine ou encore par un identifiant unique de clef. La première requête adressée au serveur par un utilisateur est en S général celle qui permet d'obtenir la description du compte de l' utilisateur ce qui est intéressant pour utiliser directement l' identifiant du compte dans les requêtes ultérieures et pour vérifier d'emblée l'exactitude des paramètres d'accès. La requête et la réponse du serveur peuvent prendre la forme suivante .. (parametres d'identification et d'=uthentification du comote) LIRE - nom d'utilisateur prénom c/Compte> La requête de liste permet d'obtenir la liste des documents d'un type donné. Il est possible de filtrer cette liste en indiquant des valeurs pour les éléments à lister. Un filtre est constitué par les mêmes chemins que ceux indiqués pour la liste dans le méta-document. Une valeur de filtre terminée par " * " désigne une suite de caractères quelconque. Une requête de liste de documents et la réponse du serveur peuvent se présenter sous la forme suivante: LISTER .. (tiltre sur les éléents listés) .. (élé.ments à lister pour ce docament) .. (r=oétition de " Doc ") En réponse à une requête de lecture d'un document, le fichier envoie les données binaires du fichier sauf en cas d'erreur ou il envoie un message d'erreur XML. La suppression ou l'archivage d'un document entraîne la suppression de l'archivage des fichiers associés à ce document. Si l'opération de suppression ou d'archivage s'est bien passée, la réponse du serveur est réduite au minimum. La requête de suppression ou d'archivage et la réponse du serveur peuvent se présenter comme su-it: SUDPRIMR ou ARCH] VER Pour créer un document, il faut en envoyer le contenu XML au serveur, avec le contenu des éventuels fichiers joints. En réponse, le serveur renvoie la totalité du document XML, complété par les attributs - " I " et " V " à la racine et les attributs " B " au niveau de chaque balise. La requête de création et la réponse du serveur peuvent se présenter comme suit: CREER .. (contenu du docament) J Les données relatives au fichier sont ajoutées à la suite de la lS requête de création, en utilisant une séquence de caractères quelconque comme séparateur, par exemple. On retrouve autant de blocs de données que de balises " Fichier " dans le document XML. De plus, le ième bloc est supposé correspondre à la ième balise " fichier ". Chacune de ces balises doit posséder un attribut " I " qui indique au serveur l'extension ( à trois lettres) à donner au fichier. Dans la réponse du serveur, l'attribut " I " est complété par un nom pour constituer un identificateur unique de fichier. De plus, la taille du fichier transmis est indiquée dans un attribut " S ": Si le logiciel client conserve une copie locale des fichiers, par exemple pour permettre un travail sans connexion au serveur, il lui est nécessaire de renommer ces fichiers avec les nouveaux noms attribués par le serveur. Pour faciliter cette opération, le client peut indiquer, dans le requete de création, les noms de fichiers utilisés localement. Dans sa réponse, le serveur fournit alors également une liste de renommage, qui donne directement la correspondance entre les anciens noms, ceux du client, et les nouveaux noms, ceux attribués par le serveur. Le format de cette liste peut être le suivant: C,.E,:S,.E | etc avec C et suivants les noms donnés par le client, S et suivants les noms donnés par le serveur, et E et suivants les noms d' extensions. La modification d'un document s'effectue en envoyant au serveur la séquence des ordres élémentaires de modification à réaliser. Si les fichiers sont modifiés ou créés, il convient également d' en envoyer le contenu au serveur. Le principe est le même que pour la création de documents. Les données sont classées à la suite de la requête, dans l'ordre défini par les balises "Fichier " de la partie XML. A la place du contenu du document on envoie une liste d'ordres élémentaires de modifications à réaliser. En l' absence d' erreur, le serveur répond en renvoyant le contenu du document XML modifié. On retrouve également la liste de renommage des fichiers, dont le principe est conservé. On prévoit également que la réponse du serveur contienne une liste de fichiers modifiée qui contient les noms des fichiers qui ont été créés ou modifiés entre la version de document indiquée par le serveur (Requête/doc/Arobase V) et celle du document renvoyé par le serveur (Service/balise/racine/@ V). L' information est intéressante dans le cas d'un client qui permet le travail en local, puisqu'il connaît ainsi quels sont les fichiers à réactualiser. La liste peut faire abstraction de la dernière modification, effectuce par le client lui-même. Il n'y a pas de liste de fichier effacés dans la mesure o le client peut facilement la constituer lui-même, notamment par comparaison des balises " Fichier " avant et après modification du document. Les opérations élémentaires de modification peuvent être prévues au nombre de quatre: I'effacement d'une balise existante notée D, la modification du sous arbre d'une balise ou de la valeur s'il s'agit d'une feuille et modification éventuelle des attributs, notée M, la création d'un nouveau sous arbre noté C, la modification des attributs de la balise et éventuellement des droits d'accès notée A. Un ordre élémentaire de modification comprendra généralement l'identificateur de la balise et de façon optionnelle le nom de la balise ce qui est une information redondante mais qui peut s'avérer utile. Les opérations de modifications s'effectuent de la façon suivante: :Effacencnt Modification dc balise l?OIll'eaU 502fSCfrtre (sans ilentificaterrs cle balises) 02r 1'ale2rr s 'il. s'ogit fl'?{ne,fe?tiiIe Création C B= "iclentificateu cle la balise père" > noirvear so2rs-arore fsans idel?tificate2rr S (le bali.ses) 02 l alerr s 'il s 'agit d'''e fe2rille ' ilodification d'attributs Dans un mode de réalisation de l' invention, il conviendra d'indiquer la totalité des attributs pour leur modification. En effet, pour la balise désignée, la nouvelle liste des attributs peut être intégralement recopice dans le document, à la place de l'ancienne. Le tableau suivant donne un exemple d'un document avant modification, d'une requête de modification et de la réponse du serveur avec le document après modification. - Docent avant modifications: CPrenom B="10">Albert DUBOIS M. :I Electricien 0 19/10/2000 . 20/10/2000 20/10/2000 - Req,cc le morlifications: cCc"?te I="65" K="40Klbho4PS;; m.3=jIDcJ"> :ODIFIER Electrotechnicien 20/10/2000 Pi2> l tete -- " nextpart " y0iàqsd3éunhacàçolzrc3la2n... (donnses hinaires du fichier " 17.rtf) -- " nextpart " 8)a&éeçabQdYEdArRú p23ZAst... (c'onnces binaires du flchier " 5. j? ") -- " nextpart " - ' 2828951 - Réponse avec document après modifcations: cService V="l.O" T=''20/lO/2000 17:25:01"> Albert D0BOIS M. tI Elect rotechnicien 20/lO/2000 2G/lO/2000 - 20/10/2000 20/lO/2000 .oJ;?1 tete 'D /Sarg> c/Petien > _5. jpg: 18. j?g 15.tx. On notera qu'entre la première lecture du document par l'utilisateur et l'envoi de la requete de modification, le document a été modifié par un autre utilisateur (et, en particulier, le fichier " 15.txt " indiqué dans la liste de modifications " Service/Info/Modif "). Ceci explique que la version passe de la valeur " 0 >> (" Requete/Param/Doc/@V ") à la valeur " 2 " (" Service/ Patient/@V "). Une erreur est générce par le serveur si un utilisateur essaie de modifier la valeur d'une balise, alors que la valeur initiale de cette balise n'est déjà plus valide, suite à une modification effectuée entre temps sur le serveur par un autre utilisateur. Autrement dit, il faut que la valeur de balise que voit l'utilisateur corresponde bien à celle sur le serveur pour que la modification soit autorisée. En reprenant le tableau précédent, si dans la requête, on avait également tenté de modifier le fichier " 15.txt " avec l'ordre: . Le serveur aurait renvoyé un message d'erreur indiquant une concurrence d'accès: Docuent modifie entre temps par un au.re utilisateur La balise à l'ongine de l'erreur est précisée dals le message d'errer SOUS]a forne: Le système comprend également un mécanisme d'authentification du compte à l'aide de clefs. On entend ici, de manière générale, un mécanisme d'authentification à l' aide de clefs asymétriques, basces sur la résolution de défis: certificat, cartes à puce L'utilisateur dispose des informations suivantes: un identifiant unique également appelé identifiant de clefs notées Kid, une clef publique Kpub, une clef privée Kpriv et des données d'accréditation Daccrd. Lors d'une première requête particulière, l'utilisateur envoie au serveur les valeurs de l'identifiant de clef, de la clef publique et des données d'accréditation. La redondance contenue dans ces données permet au serveur d'en vérifier la validité. Le serveur génère une séquence aléatoire notée D qu'il renvoie en retour au client. Le triplet de - de valeur identifiant de clef, clef publique et séquence aléatoire est mémorisé par le serveur. Chaque réponse du serveur à une requête du client contient une nouvelle valeur de séquence aléatoire. L'utilisateur crypte cette valeur avec sa clef privée et en renvoie le résultat dans la requete suivante pour que celle-ci soit acceptée. Avec la valeur de clef publique mémorisée, le serveur peut décrypter le résultat et vérifier qu'il retrouve bien la valeur de la séquerce aléatoire, également mémorisée, voir le tableau ci dessous: Clicii; | 5"; Cl!; I Relu;e I > - Véliticacio:1 d i. a: li:. dc:, d.o:::uc, - G.nératioii clu rRn D' -11émotisation r.'c (1;!, Kt'ul,. D') Réponse I {3 ,4 Reponse n- I - Cr>T>;age de 1)" à laide rle Kpiiv (soit C, le rcsuli;;;) 1 Recu=;e n p - Rcclerclc r'.c rJ'n e: D,!,ui L: corresponlcn; i K l - Dcrp.age d C,! à l aine r'i Kp::c,: i i tau t retro'J\ er D, ! - Gcuération da ("i-! D. L1cnorisation dc D, à l:!,!acc ẻ 3, $ Réponse r _ _. La première requête de l'utilisateur est construite comme suit: .t,T?iENTI FIER (clef publique et donnses d'accrédi te tio,) Si ces données sont jugées valides, le serveur renvoie le premier défi sous la forme d'un attribut " K " (la valeur du défi est exprimoe en base 64), ainsi que l'identifiant du compte: Pour les requêtes suivantes, le client indique à chaque fois sa réponse (en base 64) au défi de la requête précédente dans un attribut K au niveau de la balise " Requete/Compte/Cle ": Fec:Jte v= ' T=" "> ... Dans le cas d'unc lecture de fichier, les donnécs binaires du fichier sont précédées d'un en-têtc XML. Le logiciel clicnt est supposc analyser cet en-tête puis l'éliminer pour ne conserver que les données du fichier. donnces binaires du, fichier Si l'identification et l'authentification du compte se déroulent correctement, le serveur renvoie toujours un nouveau défi, méme en cas d'erreur sur le traitement demandé (exemple ci-après). E X emple: Privi lèe ins uffi sa nt 1 5 Si l'erreur concerne l'identification ou l'authentification du compte, le serveur ne génère pas de no,uveau défi et il convient de reprendre le protocole d'authentification à son début. Exerlple: r.ccès refusé Comme il a été indiqué plus haut, il est possible d'associer un compte à un document et d'imposer, au niveau du profil, de présenter les paramètres d'accès à ce compte pour pouvoir obtenir un accès au document. Dans ce cas, pour toutes les requetes relatives à un document de ce type, les paramètres du compte sont indiquées dans le bloc de la requête. L' identification du propriétaire du document peut servir à l'identification du document dans la mesure o il n'est possible de mettre en relation qu'un seul compte et qu'un seul document. On dispose ainsi en définitive de trois possibilités pour désigner un document: l'identifiant du document du type I = "Id du document", l'identifiant du compte du propriétaire du document du type C="Id du compte du propriétaire", et les paramètres du compte du propriétaire du document. Si les deux comptes de l'utilisateur et du l0 propriétaire du document font intervenir une clef d'authentification, la valeur de la séquence aléatoire est la même pour les deux comptes et correspond à la valeur renvoyée lors de l'authentification du compte de l'utilisateur. Pour la gestion des droits d'accès pour une balise isolée, on lS applique deux règles: en l'absence de restriction de droit de lecture, le droit est considéré comme acquis, en l'absence de restriction de droit en écriture, le droit est acquis pour les utilisateurs autorisés en lecture. * L'algorithme d'évaluation des droits d'accès au niveau d'une balise tel qu'exécuté par le serveur peut être, de fac,on simplifiée, le suivant: Fonction AccesBal Oper:,tR'' ou itW.'; B: Balise; Util: Utilisateur), booleer Lire l'attribut des clroits d'accès de la balise B. soit: r. = " R: ListeUtilR / [,r: ListeUtilW '' (s'il n' bal i ses. For:ction AccesS-o ( O2er: ''?.. O'J "'i"; B B-lise i Util: U;ilisatcJr); bol'en s'il e>:ite un- balise E' paren.te de B (à un r.ive_u c elconc:e) t=,le q_e Acces3al (Ope, B', Util) = r au Alors AccesSu? = Faux Sir.o AccesSuo = Vrai . Fonction p._cesInf ( Oper: ''R.' ou ";,'; B: Balise; Util: U.ilsate r}. boclern S'il e::iste une balise B' fille de B (à un niveau quelconce) telle que AccesSal (Oper, B', Util) = Fau:; Alors - AccesInt = Faux Sinon. ' 7.ccesInt = Vrai Une balise n'est visible pour un utilisateur que si ladte balise, ainsi que toutes les balises parentes, donnent un droit en lecture à cet utilisateur. L'opération de filtrage en lecture peut se traduire par la procédure suivante: Procédure Filtrage t Doc: doc=.ent; Util: Utilisateur) Effacer toutes les balises B de Doc telles que: (AccesSal("R", B. Util) = F2ux) ou (AccesSuo(éR", B. Util) = Faux) Pour effectuer des modifications élémentaires, par exemplc pour effacer (opération D) ou modifier une balise (opération M), il faut disposer du droit en écriture pour la balise concernée, pour les baliscs parentes et pour le balises filles. Pour modifier les attributs d'une balisc (opération A) ou ajouter une balise fille (opération C), il faut disposcr du droit en écriture pour la balise concernce et pour les balises parcntes. Ainsi l'opération de l'un des quatre types décrit ci-dessus ct notée " 0per " demandée par un utilisatcur > et relative à unc balise un serveur principal et une pluralité de serveurs secondaires. On prévoit que tous les utilisateurs quelque soit leur logiciel accèdent aux mêmes documents sur le serveur. Le dossier du patient constitue le document principal de cette application de l'invention. Deux documents d' importance moindre intitulés dossier professionnel et dossier établissement peuvent contenir des informations sommaires relatives aux professionnels de la santé et aux établissements de soins. Ces dossiers secondaires permettent d'éviter la répétition d'informations dans chaque dossier patient avec les difficultés de mise à jour que cela impliquerait. Quel que soit le logiciel client, la procédure d'accès à l' information susceptible d' être délivrce par le serveur reste sensiblement la même. L'utilisateur est d'abord invité à s'identifier puis accède ensuite à la liste des patients, filtrés selon des critères tels que nom, prénom, sexe, date de naissance...Cette liste lui permet de sélectionner le dossier patient qui l'intéresse en particulier. Un tel dossier peut ensuite contenir des liens vers d'autres dossiers de typc professionnel ou établissement. Des balises et peuvent être prévues mais dont la gestion relèvc exclusivement de l'utilisateur et non du serveur de façon qu'une grande liberté soit laissée à l'utilisateur pour structurer les données. Sur la figure 4, est illustrce l'organisation retenue pour les documents. Les documents intitulés "compte", "profil" et "domaine" ont une forme imposée tandis que l'utilisateur bénéficie d'une grande latitude pour les autres documents, par exemple les documents "patient", "professionnel ", "établissement". On entend par poste client dit " Lourd " un poste client équipé d'une application nécessitant une étape d'installation sur le poste. Ce type de poste client offre de nombreuses possibilités de traitement tel que le travail en mode non connecté suite à une recopie locale des documents, une interface homme machine plus riche qui facilite les interactions parfois complexes pour modifier les dossiers (spécifications des droits d'accès) éditions de tableaux...) administrer les comptes et les profils, etc. Même en cas de téléchargement du logiciel, le volume à télécharger reste tout à fait raisonnable de l'ordre de quelques mégaoctets. De plus, les mises à jour sont moins volumineuses. Un poste client accédant au serveur à travers un navigateur HTML est dit " Léger " et bénéficie de moins de possibilités de traitements. Toutefois, aucune installation ni mise à jour n'est nécessaire. Il suffit d'indiquer l'URL de la page d'accucil dans le navigateur. Le poste client est ouvert à tous les systèmes et ses interfaces sont familières aux utilisateurs d'Internet. De manière générale, un poste client " Léger " est bien adapté à la consultation rapide d'un dossier à partir d'un poste quelconque. Dans le cas d'un client " Léger " sous protocole WML, l'objectif est essentiellement de pouvoir visualiser rapidement quelques éléments importants des dossiers. Toutefois, rien n'empêche de prévoir des fonctionnalités plus étendues comme la modification de donnces y compri s à parti r d'un télophone mobi le. Sur la figure 5 a été représenté l'enchanement des interfaces ou écrans qui a été prévu pour la consultation d'un dossier patient à partir d'un organiseur ou d'un téléphone mobile. L'invention permet donc de partager des docaments, en particulier des documents XML, tout en gérant efficacement la concurrence d'accès et les droits d'accès à un niveau quelconque de l'arborescence. On permet ainsi à des utilisateurs de travailler simultanément sur des parties différentes d'un méme document. REVENDICATIONS 1. Système informatique apte à la gestion de documents, caractérisé par le fait qu'il comprend au moins un serveur (1), au moins un poste-client (7) apte à échanger des données avec ledit serveur, au moins un document stocké par le serveur et susceptible d'être envoyé par le serveur à un poste client déterminé, et un moyen de désignation absolue du document, de façon que l'accès audit document soit sûr. 2. Système selon la revendication 1, caractérisé par le fait qu'il comprend un moyen de désignation absolue de balises ou parties du document, chaque balise de document étant associée à une étiquette, une étiquette étant associce à une seule balise de document. 3. Système selon la revendication 1 ou 2, caractérisé par le fait qu'il comprend un moyen pour générer une requête de document ou de partie d'un docament. 4. Système selon la revendication 3, caractérisé par le fait que les requêtes sont indépendantes les unes des autres. 5. Système selon l'une quelconque des revendications précédentes, caractérisé par le fait que les documents sont de format XML. 6. Système selon l'une quelconque des revendications précédentes, caractérisé par le fait qu'il comprend un réseau de communication entre le serveur et le poste-client. 7. Système selon l'une quelconque des revendications précédentes, caractérisé par le fait qu'au moins une étiquette est attribuée à au moins un document. 8. Système selon la revendication 7, caractérisé par le fait qu'au moins une balise est identifiée de façon unique par une étiquette. 9. Serveur informatique (1) apte à la gestion de documents, comprenant un moyen pour échanger des données avec au moi ns un poste-client, un moyen pour stocker au moins un document, un moyen ' 2828951 pour envoyer un document à un poste client déterminé, caractérisé par le fait qu'il comprend un moyen de désignation absolue du document, de façon que l'accès audit document soit sur. 10. Serveur selon la revendication 9, caractérisé par le fait qu'il comprend un moyen pour attribuer une étiquette unique à chaque balise ou partie de document. 11. Programme d'ordinateur comprenant des moyens de code programme pour faire fonctionner le serveur selon la revendication 9 ou 10, lorsque ledit programme fonctionne sur un ordinateur. 12. Procédé de gestion de documents, dans lequel on échange des données entre au moins un serveur et au moins un poste-client, le serveur stockant au moins un document et l'envoyant à un poste client déterminé, le document étant désigné de façon absolue de façon que l'accès audit document soit sûr. 13. Procédé selon la revendication précédente, dans lequel un document est mis simultanément à la disposition de plusieurs poste clients. 14. Procédé selon la revendication 12 ou 13, dans lequel un document est divisé en balises ou parties, chaque balise étant associée à une étiquette, une étiquette étant associée à une seule balise de document. 15. Programme d'ordinateur comprenant des moyens de code programme pour mettre en _uvre les étapes du procédé selon l'une quelconque des revendications 2 à 14, lorsque ledit programme fonctionne sur un ordinateur.