Brevet FR2943871A1 — publié le 20101001

Procédé de partage à distance de bureau(x) informatique(s) Domaine technique de l'invention La présente invention concerne un procédé de partage à distance de bureau(x) informatique(s), notamment via un protocole de partage graphique du type RUI. Arrière-plan technologique de l'invention Un nombre croissant d'applications permettent à un utilisateur, muni d'un terminal, de mettre en oeuvre des applications informatiques hébergées par un serveur distant du terminal. Typiquement, il est connu d'utiliser le réseau Internet pour permettre à un particulier de se connecter depuis un terminal, par exemple un ordinateur situé à son domicile, à un serveur distant, par exemple situé sur son lieu de travail afin d'accéder à des applications professionnelles telles que son courriel ou sa comptabilité. Selon une première approche, cet accès à distance via le réseau Internet est effectué à l'aide d'un terminal 10 (figure 1) comprenant un système opératif léger et minimal, voire inexistant. De fait, un tel terminal 10 n'a pour fonction dans cette première approche que de permettre, d'une part, l'affichage sur un moniteur 12 d'images générées à partir de données reçues d'un serveur 16 hébergeant les applications requises par l'utilisateur 11 et, d'autre part, de transmettre des commandes, saisies à l'aide d'un clavier et/ou d'une souris 14 par l'utilisateur 11, vers ce serveur 16. Pour sa part, le serveur 16 reçoit donc ces commandes, via le réseau 15 du type Internet, et utilise un système opératif 18 pour appliquer les commandes issues des outils 14 de saisie aux applications hébergées. En résumé, la gestion des moyens applicative est entièrement effectuée au niveau du serveur hébergeur 18 déporté tandis que le terminal 10 a un rôle d'interface homme/machine distante entre l'utilisateur final 11 et le serveur 18 pour, notamment, générer les images affichées. Cette première approche est décrite par exemple dans le document � 14.2 : Net2displaytm : a proposed VESA standard for remoting diplays and I/O devices over networks � deK.Ocheltree, S.millman, M.Macdonnell, D.Hobbs, J.Nieh et R.Baratto. Elle présente l'inconvénient de ne pas permettre le partage commun d'un bureau hébergé au niveau du serveur distant entre plusieurs utilisateurs, ce partage commun étant tel qu'un même bureau et/ou des applications associées sont identiquement affichés pour tous les utilisateurs partageant ce bureau. Dans un tel partage commun, chaque modification du bureau, et/ou de ses applications associées, commandées par un utilisateur sont affichées au niveau de tous les utilisateurs communs. En outre, un tel procédé ne permet pas d'implémenter aisément un partage personnel, dénommé partage virtuel, du bureau et de ses applica- tions, ce partage virtuel étant tel que différents bureaux personnels sont affi- chés au niveau de chaque utilisateur conformément à ces commandes. Dans un tel partage virtuel, les modifications du bureau, et/ou de ses applications associées, commandées par un utilisateur ne sont affichées qu'au niveau des utilisateurs de ce bureau virtuel. De fait, le partage de bureaux entre plusieurs utilisateurs n'a pas été prévu dans l'approche Net2Display où seule l'utilisation de plusieurs bureaux par un même client (pour une session donnée) est prévue. Selon une seconde approche, l'accès à distance est effectué à l'aide d'un terminal comprenant un système opératif suffisamment développé pour permettre à plusieurs utilisateurs de partager un même bureau de façon so- lidaire. Par exemple, une telle approche est implémentée dans le système opératif RDP 6 sous WindowsTM 2008, de la société Microsoft Inc, USA implémenté au niveau du terminal. Toutefois, cette seconde approche est basée sur des outils dont les caractéristiques techniques ù par exemple en termes de protocoles de communication, de capacités de mémoire et/ou de fréquence de travail ù sont inadaptées et distinctes vis-à-vis des caractéristiques du domaine de l'accès à Internet haut débit grand public. En effet un tel domaine se caractérise par l'utilisation de décodeurs de télévision numériques présentant des ressources limitées et des protoco- les propriétaires spécialement développées pour la mise en oeuvre de ses applications limitées. Dès lors, le partage d'un bureau via de tels décodeurs numériques requiert une adaptation coûteuse et complexe des décodeurs et de leurs applications afin qu'ils soient compatibles avec les protocoles et le langage des applications à partager. Description générale de l'invention Dans ce contexte, la présente invention vise à résoudre au moins un de ces inconvénients en proposant un procédé pour partager un bureau in- formatique à distance à l'aide d'un protocole simple, public et facile à implémenter, notamment avec des décodeurs numériques d'accès haut débit à Internet. Elle résulte de la constatation qu'un protocole de partage graphique, du type RUI pour � Remote User Interface �, se révèle compatible pour permettre un partage de bureaux, tant commun que virtuel, via un décodeur numérique compte tenu, d'une part, de la simplicité de sa mise en oeuvre permettant de développer de nouvelles fonctions et, d'autre part, de sa nature basée sur le stockage à distance des interfaces graphiques et la transmission d'images, décrite en détail dans la description ultérieure. C'est pourquoi, l'invention concerne un procédé de partage à distance d'un bureau informatique généré par une application exécutée dans un serveur en réponse à des commandes émises par des terminaux clients accédant à ce serveur via un réseau de télécommunication, caractérisé en ce que les terminaux clients transmettent au serveur des commandes, dédiées au partage de bureau et conformes à un protocole de transmission d'interfaces graphiques du type RUI, pour � Remote User Interface �, tel que le serveur transmet en réponse aux terminaux une interface graphique représentative de ce bureau du serveur au moyen d'indications de l'état des pixels dans cette interface graphique conformément à ce protocole du type RUI. Grâce à l'invention, un utilisateur peut aisément mettre en oeuvre un partage de bureau(x) informatique distant, au moyen d'un protocole léger et simple à mettre en oeuvre dans des décodeurs vidéo numériques existants. De fait, un protocole du type RUI transmet des signaux visant à indiquer l'affichage devant être effectué par un pixel de telle sorte que, pour un décodeur numérique généralement associé à un écran de télévision ou d'ordinateur, la transmission de cette information à cet écran s'avère simple à mettre en oeuvre. Par ailleurs, un protocole du type RUI permet de développer des fonctions simples pour le partage d'un écran, comme montré ultérieurement. Dès lors, les commandes nécessaires au partage d'un écran, selon un mode commun ou virtuel, sont aisément réalisables. Dans une réalisation, le serveur transmet à des terminaux clients, effectuant un partage commun d'un même bureau, une même interface graphique. Dans ce cas, les commandes transmises par chacun des terminaux clients effectuant un partage commun d'une même interface graphique peu- vent être exécutées, par leur serveur, dans leur ordre de réception, l'interface graphique générée par le serveur pour ce bureau commun suite à l'exécution d'une commande étant transmise à l'ensemble des terminaux clients effectuant le partage commun. Selon une réalisation, le serveur transmet à des terminaux clients ef- fectuant un partage virtuel de bureaux distincts des interfaces graphiques distinctes. Dans ce cas, les commandes transmises par un des terminaux clients effectuant un partage virtuel de différentes interfaces graphiques peuvent être exécutées, par leur serveur, uniquement vis-à-vis de l'interface graphi- que distincte du bureau associé à ce terminal. Selon une réalisation, le protocole du type RUI est le protocole RFB pour � Remote Frame Buffer � en anglais. Dans ce cas, le procédé peut prendre en compte au moins une des commandes du type RFB suivantes : - � GetVirtualDesktopList � : pour envoyer un message d'un terminal client vers le serveur afin de demander les éventuels bureaux disponibles sur le serveur, - � VirtualDesktopList � : pour que le serveur réponde à la requête du terminal client en transmettant la liste des bureaux disponibles, - � VirtualDesktopAuthentication � pour qu'un terminal client puisse choisir de se connecter sur un bureau virtuel déjà existant via la fonction, - � NotifyClientConnection � pour informer un terminal client de la demande de connexion de l'autre terminal client, û � VirtualDesktopAuthenticationAllowance � : pour accepter ou refuser le partage d'un bureau en mode commun, cette acceptation ou ce refus étant notifié par l'envoi d'un message du serveur vers un terminal client requérant ce partage. Dans une réalisation, le serveur associe un identifiant de chaque terminal, issu d'un focus ou d'une zone de saisie, avec un bureau commun et/ou virtuel. L'invention concerne également un serveur destiné à effectuer un partage à distance d'un bureau informatique généré par une application exécutée localement en réponse à des commandes émises par des terminaux clients accédant à ce serveur via un réseau de télécommunication, caractérisé en ce qu'il comprend : - des moyens pour recevoir, des terminaux clients, des commandes dédiées au partage de bureau et conformes à un protocole de transmission d'interfaces graphiques du type RUI, et - des moyens pour transmettre en réponse aux terminaux une interface graphique représentative du bureau au moyen d'indications de l'état des pixels dans cette interface graphique conformément au protocole du type RUI, Conformément à un procédé selon l'une des réalisations précédentes. Finalement, l'invention concerne un terminal destiné à partager à dis-tance un bureau informatique généré par une application exécutée dans un serveur en réponse à des commandes émises par ce terminal via un réseau de télécommunication, caractérisé en ce qu'il comprend : - des moyens pour transmettre au serveur des commandes, dédiées au partage de bureau et conformes à un protocole de transmission d'interfaces graphiques du type RUI, et - des moyens pour recevoir du serveur une interface graphique représentative du bureau au moyen d'indications de l'état des pixels dans cette inter-face graphique conformément au protocole du type RUI, Selon un procédé conforme à l'une des réalisations précédentes. 10 Brève description des figures D'autres caractéristiques et avantages de l'invention ressortiront clairement de la description qui en est donnée ci-dessous, à titre indicatif et nullement limitatif, en référence aux figures ci-jointes sur lesquelles : 15 - A la figure 1, déjà décrite, est représenté schématiquement un système d'accès à distance d'un terminal à un serveur selon l'art antérieur, - A la figure 2 est illustré schématiquement le fonctionnement d'un protocole du type RFB, - A la figure 3 est représenté un diagramme fonctionnel décrivant 20 l'accès à distance de deux terminaux clients à un serveur selon l'invention, - A la figure 4 et représenté un organigramme des opérations effec- tuées par un serveur RFB implémentant l'invention. Description des formes de réalisation préférées de l'invention: 25 La description de l'invention effectuée ci-dessous met en oeuvre un protocole du type RUI tel que le protocole RFB décrit, par exemple, dans le document � The RFB Protocol �, de Tristan Richardson, Real VNC Ltd, version 3.8, mise à jour le 26 février 2009 (http:// www.realvnc.com). Selon un tel protocole, un terminal utilisateur 20, dénommé terminal 30 RFB ou terminal client, affiche une interface graphique 22 générée par un serveur RFB 28 distant qui héberge les moyens hardwares û composants - et software û logiciels - pour déterminer les caractéristiques de cette inter- face graphique 22 en fonction de commandes émises par ce terminal 20 via ses outils de saisie 24. De fait, le protocole RFB se caractérise par l'utilisation d'instructions graphiques simples telles qu'une commande pour afficher un rectangle de pixels de données à une position (x, y) donnée de l'écran. Chaque image formée par le serveur RFB est stockée dans une mémoire tampon - dite � framebuffer � - du serveur 28, généralement codée en format RGB (� Red Green Blue � en anglais), qui constitue la manière la plus directe de coder les images, les trois plans correspondant aux trois cou- leurs élémentaires rouge, vert et bleu. De par sa spécificité graphique, un protocole RUI tel que le protocole RFB ne semble pas permettre la réalisation d'applications complexes telles qu'un partage de bureau informatique à distance. Toutefois, selon une constatation propre à l'invention, le protocole RFB permet aisément tant de partager un même bureau - partage commun û que de partager les moyens applicatif pour gérer différents bureaux - partage individuel ou virtuelû propres à plusieurs utilisateurs. Dans le premier cas, un partage commun d'un bureau résulte directement de la nature d'un protocole du type RUI qui, générant à distance l'image de l'interface et/ou de ses applications, peut partager ses images créées in situ avec différents terminaux. En d'autres termes, un tel protocole du type RUI permet un partage simple et aisé d'un même bureau puisque la gestion de ce dernier n'est pas directement effectuée par un terminal RFB mais centralisé au niveau du ser- veur RFB. Dès lors, un serveur du type RUI doit simplement implémenter des moyens, telles qu'une pile d'instruction, pour gérer le bureau commun, et/ou ses applications, selon des instructions provenant de différents terminaux, les modifications de l'interface graphique étant partagées avec tous ces ter- minaux RFB. Dans le second cas û partage virtuel û il convient de noter que le protocole du type RUI met en oeuvre un codage de données associées aux pixels de l'interface graphique qui permet de développer simplement de nouvelles fonctions. Par exemple, le protocole RFB met en oeuvre des échanges entre le serveur RFB et ses terminaux RFB pour déterminer le format et l'encodage des données de pixels, étant entendu que le format se réfère la couleur des pixels û par exemple 24-bits ou 16-bits, tandis que l'encodage se réfère à la façon dont un rectangle de pixels est identifié sur l'écran. Dès lors de nouvelles fonctions peuvent être générées pour associer des bureaux virtuels à des terminaux RFB distincts de telle sorte que des commandes émises par chaque terminal RFB puissent être implémentées spécifiquement vis-à-vis d'un bureau virtuel associé à ce terminal RFB. A titre d'exemple, les fonctions suivantes ont été développées pour permettre la gestion de tels bureaux virtuels via le standard, ou norme, RFB dont les désignations usuelles sont reprises ci-dessous: - Fonction d'envoi d'un message du terminal client vers le serveur RFB pour la demande des bureaux disponibles sur un serveur don-né dénommée � GetVirtualDesktopList � Nombre Type Description d'octets [Value] 1 U8 10 message-type - Fonction d'envoi d'un message en réponse, du serveur RFB vers le client RFB, pour donner la liste des bureaux disponibles dénommée � VirtualDesktopList � No. of bytes Type Description [Value] 1 U 8 message-type 10 2 U16 number_of virtual_desktops N (=N) N*sizeof(VIRTUAL_DESKTOP) VIR- List of available virtual TUAL_DESKTOP desktops on the server array 25 A cet effet, la structure d'un bureau virtuel, ou � VIRTUAL_DESKTOP �, peut être formée de la façon suivante: No. of bytes Type [Value] Description 4 U32 virtual_desktop_id 4 U32 N number_of users N*sizeof(USER) USER array Nomes of current users con- nected to this virtual desktop Tandis que la structure USER est la suivante: No. of bytes Type [Value] Description 4 U32 user id 32 U8 array user nome - Fonction d'envoi d'un message du client RFB au serveur pour 10 l'authentification sur un bureau virtuel déjà existant, dénommée � Virtual-DesktopAuthentication � No. of Type Description bytes [Value] 1 U8 11 message-type 4 U32 virtual_desktop_id 4 U32 user_id (id of the client whishing to con- nect on the virtual desktop identified by vir- tual_dekstop_id) 15 - Fonction d'envoi d'un message du serveur RFB vers le terminal client pour la notification à un terminal client (CLIENT1) de la demande de connexion d'un autre terminal client (CLIENT2) sur bureau virtuel utilisé par CLIENT1, dénommée � NotifyClientConnection �. No. of bytes Type Description [Value] 1 U8 11 message-type sizeof(USER) USER new_user - Fonction d'envoi d'un message du terminal client RFB vers le serveur pour l'acceptation ou rejet de connexion d'un autre client sur bureau virtuel donné dénommée � VirtualDesktopAuthenticationAllowance �. No. of Type Description 20 bytes [Value] 1 U8 12 message-type 4 U32 user id (identifies the user giving the permission) 4 U32 new_user_id (identifies the user who avants to connect) 4 U32 virtual_desktop_id (identifies the queried virtual desktop) 1 U8 0 acceptjlag => accept 1 => reject - Fonction d'envoi d'un message serveur RFB vers le client RFB pour notifier du succès ou de l'échec de la connexion à un bureau virtuel donné. � VirtualDesktopAuthenticationResult �. No. of by- Type [Va- Description tes lue] 1 U8 12 message-type 4 U32 virtual_desktop_id 1 U8 0 acceptjlag => accept 1 => reject - Fonction d'envoi d'un message client RFB vers le serveur RFB pour se déconnecter d'un bureau virtuel, dénommée � VirtualDesktopDiscon-10 nect �. No. of Type Description bytes [Value] 1 U8 13 message-type 4 U32 virtual_desktop_id 1 U8 0 acceptjlag => accept 1 => reject - Fonction d'envoi d'un message du client RFB vers le serveur RFB 15 pour notifier le changement de bureau virtuel côté client dénommée � VirtualDesktopSwitch �.5 No. of Type Description bytes [Value] 1 U8 14 message-type 4 U8 user id 4 U32 new_virtual_desktop_id Dans ce cas, le client doit être déjà connecté au bureau virtuel, identi- fié par � new_virtual_desktop_id �, pour établir la connection. - Fonction d'envoi d'un message du client RFB vers le serveur RFB pour les événements d'un clavier, d'une souris, ou de tout autre périphérique d'entrée, accompagné de l'identifiant du client, ainsi que d'un indicateur di- sant si l'événement est exclusif ou non exclusif à un bureau dénommé � VirtualDesktopinputEvent �. No. of Type Description bytes [Value] 1 U8 14 message-type 4 U8 user id 4 U32 virtual_desktop_id 4 U32 event_type 1 U 0 => non exclusive J'lag exclusive 1 => exclusive Il apparaît ainsi que le protocole RFB, enrichi avec de telles fonctions, permet d'associer une pluralité de terminaux 20 à un serveur 24 RFB afin générer des bureaux virtuels spécifiques à chaque terminal 20. Une telle mise en oeuvre est illustrée à la figure 3 qui représente deux terminaux clients 40 et 50 comprenant des pilotes respectives 41 et 51 pou- vant transmettre des commandes à un serveur 32 VNC, pour Virtual Network Connection en anglais, hébergeant un bureau informatique et des applications logicielles associées à ce dernier. Des moyens de communication 43 et 53 des terminaux RFB communiquent avec des moyens 33 du serveur 32 RFB à l'aide, par exemple, d'un protocole I P. Typiquement, ces communications mettent en oeuvre les fonctions � GetVirtualDesktopList �, pour envoyer un message des terminaux clients vers le serveur RFB afin de demander les bureaux disponibles sur le serveur 32, et � VirtualDesktopList � pour que le serveur RFB réponde aux requêtes des clients RFB en transmettant la liste des bureaux disponibles. A partir de cette liste, un terminal 40 ou 50 peut choisir de se connec- ter sur un bureau virtuel déjà existant via la fonction � VirtualDesktopAuthen- tication �. Toutefois, ce bureau virtuel peut déjà être utilisé par un terminal client (CLIENT1) qui est alors informé de la demande de connexion de l'autre terminal client (CLIENT2) û fonction � NotifyClientConnection �. Ce dernier peut, via la fonction � VirtualDesktopAuthenticationAllowance �, accepter ou refuser le partage de son bureau en mode commun, cette acceptation ou ce refus étant notifié par l'envoi d'un message du serveur RFB vers le client RFB - fonction � VirtualDesktopAuthenticationResult �. Il convient de noter que ces opérations sont mises en oeuvre au ni-veau opératif 34 du serveur 32 qui effectue, également, un tri des commandes propres à chaque bureau commun ou partage. De fait, les différentes commandes reçues par le serveur 32 sont compilées au niveau d'une pile 60 (figure 4) de commandes à partir de la- quelle une opération de sélection 62 sépare les opérations 64 propres à tous les bureaux, par exemple le déclenchement du gestionnaire de programmes avec l'appui simultanée des touches du clavier � CTRL � � ALT � et � DEL �, des opérations 63 propres à un bureau virtuel. Dans ce dernier cas, des moyens applicatifs 36 (figure 3) transmet- tent chaque instruction au bureau concerné 37 ou 38 (figure 3 et 4) ou 67 et 68 (figure 4). Une fois que les instructions sont traitées, le client RFB peut se dé-connecter du serveur RFB avec la commande � VirtualDesktopDisconnect � ou pour changer de bureau virtuel côté client û commande � VirtualDesktopSwitch �. Il convient de noter que, pour transmettre des commandes, un utilisateur peut mettre en oeuvre tout type d'outil de saisie tel qu'un clavier, une souris, ou tout autre périphérique d'entrée, accompagné de l'identifiant du client, ainsi que d'un indicateur disant si l'événement est exclusif ou non exclusif à un bureau dénommé � VirtualDesktopinputEvent �. Dans cette réalisation, cet identifiant permet de générer, au niveau du serveur RFB, un tableau de correspondance entre un focus i, à savoir une zone de saisie, et un bureau virtuel. Ainsi un client RFB, qui transmet toutes ses requêtes au moyen d'un focus, est automatiquement associé à un bureau virtuel û après ouverture de la session comme indiqué ci-dessus. La présente invention est susceptible de nombreuses variantes. Par exemple, un terminal RFB peut présenter plusieurs outils de saisies - claviers ou souris par exemple û associés à un ou plusieurs moniteurs qui peu-vent être locaux û directement relié au serveur û ou distant û indirectement relié au serveur via un réseau du type Internet. En outre, le serveur RFB peut également être un terminal RFB de telle sorte qu'il partage, en commun ou en virtuel, ses ressources avec d'autres terminaux. Finalement, un terminal client peut avoir accès à plusieurs bureaux simultanément, par exemple un bureau commun û partagé - et un bureau virtuel û non partagé ou partagé avec un nombre limité d'autres terminaux clients. REVENDICATIONS1. Procédé de partage à distance d'un bureau informatique (37, 38) généré par une application (34, 36) exécutée dans un serveur (28, 32) en réponse à des commandes émises par des terminaux (40, 50) clients accédant à ce serveur via un réseau de télécommunication, caractérisé en ce que les terminaux clients (40, 50) transmettent au serveur (28, 32) des commandes, dédiées au partage de bureau (37, 38) et conformes à un protocole de transmission d'interfaces graphiques du type RUI, pour � Remote User Inter- face � en anglais, tel que le serveur (28, 32) transmet en réponse aux terminaux (40, 50) une interface graphique (22) représentative de ce bureau (37, 38) du serveur (28, 32) au moyen d'indications de l'état des pixels dans cette interface graphique conformément à ce protocole du type RUI. 2. Procédé selon la revendication 1 caractérisé en ce que le serveur (32) transmet à des terminaux clients effectuant un partage commun d'un même bureau une même interface graphique (22). 3. Procédé selon la revendication 2 caractérisé en ce que les commandes transmises par chacun des terminaux clients effectuant un partage commun d'une même interface graphique (22) sont exécutées, par leur serveur (32), dans leur ordre de réception, l'interface graphique (22) générée par le serveur (28) pour ce bureau commun suite à l'exécution d'une commande étant transmise à l'ensemble des terminaux clients effectuant le partage commun. 4. Procédé selon l'une des revendications précédentes caractérisé en ce que le serveur (32) transmet à des terminaux clients (40, 50) effectuant un partage virtuel de bureaux distincts (37, 38) des interfaces graphiques distinctes. 5. Procédé selon la revendication 4 caractérisé en ce que les commandes transmises par un des terminaux clients (40, 50) effectuant un partage virtuel de différentes interfaces graphiques sont exécutées, par leur serveur (32), uniquement vis-à-vis de l'interface graphique distincte du bureau associé à ce terminal. 6. Procédé selon l'une des revendications précédentes caractérisé en ce que le protocole du type RUI est le protocole RFB pour � Remote Frame Buffer � en anglais. 7. Procédé selon la revendication 6 caractérisé en ce qu'il prend en compte au moins une des commandes du type RFB suivantes : - � GetVirtualDesktopList � : pour envoyer un message d'un terminal client vers le serveur afin de demander les éventuels bureaux disponibles sur le serveur, - � VirtualDesktopList � : pour que le serveur réponde à la requête du termi- nal client en transmettant la liste des bureaux disponibles, - � VirtualDesktopAuthentication � pour qu'un terminal client puisse choisir de se connecter sur un bureau virtuel déjà existant via la fonction, - � NotifyClientConnection � pour informer un terminal client de la demande de connexion de l'autre terminal client, û � VirtualDesktopAuthenticationAllowance � : pour accepter ou refuser le partage d'un bureau en mode commun, cette acceptation ou ce refus étant notifié par l'envoi d'un message du serveur vers un terminal client requérant ce partage. 12. Procédé selon l'une des revendications précédentes caractérisé en ce que le serveur (32) associe un identifiant de chaque terminal (40, 50), issu d'un focus ou d'une zone de saisie, avec un bureau commun et/ou virtuel. 13. Serveur (28, 32) destiné à effectuer un partage à distance d'un bureau informatique (37, 38) généré par une application (34, 36) exécutée locale-ment en réponse à des commandes émises par des terminaux clients (40, 50) accédant à ce serveur via un réseau de télécommunication, caractérisé en ce qu'il comprend : - des moyens (33) pour recevoir, des terminaux clients, des commandes dédiées au partage de bureau et conformes à un protocole de transmission d'interfaces graphiques du type RUI, et - des moyens pour transmettre en réponse aux terminaux une interface graphique (22) représentative du bureau (37, 38) au moyen d'indications de l'état des pixels dans cette interface graphique conformément au protocole du type RUI,Conformément à un procédé selon l'une des revendications précédentes. 10. Terminal (40, 50) destiné à partager à distance un bureau informatique (22, 37, 38) généré par une application exécutée dans un serveur en réponse à des commandes émises par ce terminal via un réseau de télécom- munication, caractérisé en ce qu'il comprend : - des moyens pour transmettre au serveur des commandes, dédiées au partage de bureau et conformes à un protocole de transmission d'interfaces graphiques du type RUI, et - des moyens pour recevoir du serveur une interface graphique représenta- tive du bureau au moyen d'indications de l'état des pixels dans cette inter-face graphique conformément au protocole du type RUI, Selon un procédé conforme à l'une des revendications 1 à 9.