FR 2841998 A1 20040109 FR 0208374 A 20020704 La présente invention concerne un procédé d'exécution sur une station d'un réseau de communication d'un programme informatique. Ce programme informatique est représenté dans un langage de balisage, en utilisant par exemple la syntaxe du langage de balisage XML (en anglais, "eXtented Markup Language"). Les réseaux de communication prennent une place sans cesse croissante dans l'utilisation des ordinateurs de telle sorte que, de plus en plus, les programmes informatiques eux-mêmes ont besoin pour fonctionner d'être reliés à d'autres ordinateurs via un réseau de communication. Ainsi il n'est pas rare qu'un programme informatique soit réparti dans le réseau de communication, en utilisant au mieux les fonctionnalités et les capacités de traitement de chaque serveur du réseau de communication. Aussi, l'exécution d'un tel programme sur un ordinateur local, sans connexion au réseau de communication, ne peut plus être mise en oeuvre ou sinon dans un mode dégradé. Il devient donc de plus en plus important de pouvoir accéder aux fonctionnalités offertes par les différents programmes stockés sur les différents serveurs d'un réseau de communication. Il existe aujourd'hui plusieurs techniques d'accès et de mise en oeuvre des programmes informatiques distants. Une première technique dite de RPC (en anglais, "Remote Procedure Calf'), permet à un programme local d'envoyer une requête de demande d'exécution de fonction à un programme distant, ce dernier exécutant la fonction et retournant le résultat demandé. Toutefois, cette technique RPC présente un certain nombre d'inconvénients. Premièrement, elle nécessite de connaître précisément à l'avance la définition de la fonction à exécuter à distance. En outre, elle oblige le programmeur à modifier considérablement le code de son programme pour lui permettre d'accéder à des fonctions distantes. Enfin, le programmeur doit traiter différemment les appels de fonction locale et les appels de fonction distante. Il existe également une deuxième technique consistant à télécharger à la demande une fonction. Cette technique consiste à télécharger un premier élément d'un programme depuis un serveur distant, puis, au fur et à mesure que l'exécution de ce programme fait appel à des fonctions contenues dans d'autres éléments du programme, on télécharge ces autres éléments depuis un serveur distant. Cette technique est mise en ceuvre grâce au langage de programmation Java , utilisée par certains navigateurs (en anglais "Browser") sur le Web. Bien que simple à utiliser, cette technique nécessite que la totalité du programme à exécuter soit initialement stockée sur le serveur distant, ce qui empêche l'utilisation de modèles distribués dans lequel le programme est découpé en plusieurs sous-programmes répartis sur différents ordinateurs du réseau de communication. Par ailleurs, cette technique ne permet pas le téléchargement à partir de plusieurs ordinateurs du réseau des différents sous-programmes constituant un programme. Parallèlement à cette technique de traitement d'un programme réparti sur un réseau de communication, il existe la technique des "hypertiens" (en anglais, "hyperlinks"). Cette technique permet à un document dit "hypertexte" (en anglais, "hypertext') de référencer des documents stockés sur des serveurs distants. Dans son principe, ces liens hypertextes consistent à encadrer un mot ou une phrase d'un document électronique par une balise (en anglais, "tag") contenant l'adresse du document électronique correspondant au mot ou à la phrase du document traité. En pratique, les mots ou phrases ainsi encadrés par une balise sont affichés à l'écran dans une couleur particulière de telle sorte que l'utilisateur peut cliquer sur l'un d'entre eux. Le document courant est alors remplacé à l'écran par le document référencé grâce à un logiciel du type navigateur permettant de rechercher sur le réseau de communication le document associé à cette balise. Cette technique est d'une grande simplicité d'emploi pour le référencement de documents électroniques répartis sur plusieurs serveurs d'un réseau de communication. L'invention a pour but de proposer un nouveau procédé d'exécution sur un réseau de communication d'un programme informatique réparti sur plusieurs serveurs dans un réseau de communication, sans les inconvénients de l'état de la technique. A cet effet, un procédé d'exécution sur une station d'un réseau de communication d'un programme informatique représenté dans un langage de balisage comprend les étapes suivantes: - lecture d'une balise comprenant l'identification d'une instruction; - identification d'une adresse électronique associée à ladite balise comprenant l'identification d'une instruction; - comparaison de ladite adresse électronique avec l'adresse locale de ladite station; et - envoi si ladite adresse électronique est différente de ladite adresse locale, d'une requête à une station serveur du réseau correspondant à ladite adresse électronique en vue d'obtenir l'exécution de ladite instruction. Ainsi, grâce à l'introduction dans un programme informatique de balise incluant une adresse électronique référençant un sous-programme, du type d'un lien hypertexte, l'exécution d'un tel programme est grandement facilitée à partir d'une station d'un réseau de communication. En outre, que cette adresse électronique référence l'adresse locale de la station sur laquelle est exécuté le programme ou l'adresse d'une station distante du réseau de communication, le même modèle de référencement peut être utilisé pour les deux types d'appel d'instruction. Cela facilite considérablement la tâche du programmeur et permet sans inconvénient de passer, pour certaines parties du programme informatique de l'exécution d'instruction locale à l'exécution d'instruction distante et vice versa. Le même modèle de référencement peut être utilisé tant pour l'exécution de fonctions hébergées sur des stations distantes que pour la mise à jour ou la lecture de variables mémorisées sur des stations distantes. En outre, l'exécution d'un tel programme informatique peut être tout à fait réalisée lorsque les différents sous-programmes ou fonctions sont répartis sur différents serveurs dans un réseau de communication. En particulier, des fonctions peuvent être réalisées de manière optimale par les serveurs ayant des caractéristiques ou capacités de traitement adaptées à ces fonctions. L'invention permet ainsi de manière générale d'exécuter des programmes informatiques référençant d'autres programmes informatiques par le biais de liens de type hypertexte. Selon une caractéristique préférée de l'invention, à l'étape d'envoi, une requête de demande d'exécution de la fonction à distance est envoyée à la station serveur du réseau de communication. Ainsi, la fonction peut être exécutée à distance sur le serveur hébergeant cette fonction, en utilisant les capacités de traitement de ce serveur. De manière pratique, le procédé d'exécution comprend alors une étape de réception du résultat d'exécution de cette fonction. Selon une caractéristique alternative de l'invention, à l'étape d'envoi, une requête de demande d'obtention du code de la fonction à exécuter est envoyée à la station serveur du réseau de communication. Ainsi, l'exécution de la fonction est réalisée directement sur la station mettant en oeuvre le programme informatique, à partir du code d'exécution réceptionné. De préférence, ce procédé comprend en outre une étape de mémorisation dudit code de la fonction réceptionnée, afin de permettre l'utilisation ultérieure de ce code en cas d'appels successifs de la fonction dans un même programme informatique. Selon une autre caractéristique alternative de l'invention, à l'étape d'envoi, une requête d'obtention d'une valeur variable est envoyée à la station serveur du réseau de communication. Ainsi, une valeur variable peut être obtenue directement lors de l'exécution du programme à partir d'une station serveur du réseau conservant et mettant à jour régulièrement cette valeur variable. Selon une autre caractéristique alternative de l'invention, à l'étape d'envoi, une requête de mise à jour d'une variable est envoyée à la station serveur du réseau de communication. La mise à jour d'une valeur variable peut ainsi être exécutée à distance, puis une réponse envoyée à la station du serveur sur lequel est exécuté le programme informatique principal. De préférence, ce procédé comprend en outre une étape de mémorisation de ladite valeur variable extraite ou mise à jour. Ceci permet l'utilisation ultérieure de cette variable en cas d'utilisations successives de cette variable dans un même programme informatique. Cette mémorisation permet en outre de mettre à jour ultérieurement à distance la variable localisée sur une station serveur du réseau de communication. Corrélativement, la présente invention concerne un dispositif d'exécution sur une station d'un réseau de communication d'un programme informatique représenté dans un langage de balisage. Ce dispositif d'exécution comprend: - des moyens de lecture d'une balise comprenant l'identification d'une instruction; - des moyens d'identification d'une adresse électronique associée à la balise comprenant l'identification d'une instruction; - des moyens de comparaison de ladite adresse électronique avec l'adresse locale de la station; et - des moyens d'envoi adaptés à envoyer une requête à une station serveur du réseau correspondant à ladite adresse électronique en vue d'obtenir l'exécution de l'instruction, si ladite adresse électronique est différente de ladite adresse locale. Ce dispositif d'exécution présente des caractéristiques et avantages analogues à ceux du procédé d'exécution conforme à l'invention. La présente invention concerne également un programme d'ordinateur comprenant des portions de codes logiciels adaptées à mettre en oeuvre le procédé d'exécution conforme à l'invention lorsque ledit programme est chargé sur un ordinateur. Elle concerne enfin des moyens de stockage d'informations, fixes ou partiellement ou totalement amovibles, adaptés à mémoriser des séquences d'instructions dudit programme d'exécution conforme à l'invention. Dans son application pratique, la présente invention concerne enfin un ordinateur et un réseau de communication comprenant des moyens adaptés à mettre en oeuvre le procédé d'exécution conforme à l'invention. D'autres particularités et avantages de l'invention apparaîtront encore dans la description ci-après. Aux dessins annexés, donnés à titre d'exemples non limitatifs: - la figure la illustre un premier réseau de communication adapté à mettre en oeuvre le procédé d'exécution conforme à l'invention; - la figure lb illustre un second réseau de communication adapté à mettre en oeuvre le procédé d'exécution conforme à l'invention; - la figure 2 est un algorithme illustrant un procédé d'exécution d'un programme conforme à l'invention; la figure 3 est un algorithme illustrant l'évaluation des instructions dudit programme de la figure 2; - la figure 3a est un algorithme illustrant l'étape d'exécution d'une hyper-fonction de la figure 3; - la figure 3b est un algorithme illustrant l'étape de lecture d'une hyper-variable de la figure 3; - la figure 3c est un algorithme illustrant l'étape de mise à jour d'une hyper-variable de la figure 3; et - la figure 4 est un schéma-bloc d'un ordinateur adapté à incorporer un dispositif d'exécution conforme à l'invention. On va décrire tout d'abord le principe du procédé d'exécution conforme à l'invention en référence à la figure la illustrant un réseau de communication adapté à mettre en oeuvre ce procédé. Ici, ce réseau de communication comporte trois ordinateurs C, 1, R. Un ordinateur client C ne dispose ni d'une imprimante ni d'une puissance de calcul intensive. En revanche, un deuxième ordinateur I est spécialisé dans l'impression d'images haute résolution, alors qu'un troisième ordinateur R est spécialisé dans les opérations de calculs intensifs. Dans un tel réseau de communication, on a intérêt à déporter une ou plusieurs sous-parties d'un programme informatique afin d'utiliser au mieux les capacités de traitement de chacun des ordinateurs C, 1, R. On va donner ci-après un exemple non limitatif de programme d'ordinateur adapté à être réparti au mieux dans un tel réseau de communication. Dans la suite, on fera référence au langage de programmation XPL (en anglais "eXtended Program Language'). Ce langage de programmation est adapté à présenter des programmes informatiques en utilisant la syntaxe du langage de balisage XML (en anglais "eXtended Markup Language'). Bien entendu, la présente invention n'est pas limitée à un tel langage de programmation XPL mais peut être adaptée à tout autre type de langage de programmation utilisant un langage de balisage. On considère à titre d'exemple un programme de rotation et d'impression d'une image. De manière classique, un tel programme pourrait se présenter de la façon suivante: Le programme ci-dessus est ainsi composé de trois fonctions distinctes: - une fonction d'impression d'une image ("printlmage'), - une fonction de rotation d'image ("rotatelmage'}, et - une fonction principale ("main') qui enchaîne les deux opérations précédentes. En revenant à la figure la, il est intéressant de pouvoir découper le programme précédent en trois sous-programmes indépendants, stockés respectivement dans des fichiers print.xpl, rotate.xpl et main.xpl. Le fichier print.xpl, correspondant au programme d'impression d'une image, est stocké sur le deuxième ordinateur I spécialisé dans l'impression d'images haute résolution, alors que le fichier rotate.xpl, mémorisant le programme de rotation d'une image, est stocké sur le troisième ordinateur R spécialisé dans les opérations de calculs intensifs. Ainsi, les fonctions "printimage" et "rotatelmage" ne sont-elles plus connues par le programme principal main.xpl. On modifie alors le programme main.xpl de la manière suivante: Ainsi, on indique pour chaque instruction référençant une fonction non disponible localement, l'adresse électronique à laquelle se trouve la définition de cette fonction. Ici, l'instruction contient l'adresse électronique "http://l/print.xpl" de la fonction "printimage" hébergée sur le deuxième ordinateur I spécialisé dans l'impression d'image. De même, l'instruction contient l'adresse électronique "http://R/rotate.xpl" correspondant à l'adresse du troisième ordinateur R hébergeant la fonction "rotatelmage". On peut, grâce à une modification minimale du programme, déporter facilement le traitement d'une fonction vers un ordinateur distant du réseau de communication. Une instruction annotée par l'attribut "href" sera appelée dans la suite de la description une "hyper-instruction" (en anglais "hyper-statement'). Ainsi, l'adresse électronique du serveur hébergeant la fonction est mémorisée grâce à un attribut de la balise définissant la fonction. Comme cela sera décrit en détail ultérieurement en référence aux figures 2 et suivantes, l'exécution d'une telle instruction génère automatiquement une demande de requête d'exécution à distance de la fonction associée à l'adresse électronique. Ainsi, une demande de requête d'exécution à distance de la fonction "rotatelmage" est envoyée à destination du troisième ordinateur R. En retour, l'ordinateur client C reçoit une image transformée. De même, l'évaluation de l'instruction , permet de générer automatiquement une requête de demande d'exécution à distance pour la fonction "printimage", adressée au deuxième ordinateur I spécialisé dans les techniques d'impression. On montrera en particulier qu'il n'est pas nécessaire de répéter la notation "hre' tsur chaque hyper-instruction du même nom. Par exemple, si la fonction "rotatelmage" est appelée plusieurs fois à différents endroits du même programme informatique, il suffit de la noter une seule fois avec l'attribut "href' pour que le programme informatique sache traiter ces hyper-instructions, en requérant l'exécution de la fonction sur l'ordinateur distant. A titre de variante, les fonctions distantes pourraient être déclarées en en-tête d'un programme. Les programmes précédents pourraient ainsi être écrits de la manière suivante de telle sorte que les fonctions "rotatelmage" et "printimage" soient toutes deux considérées comme des hyper-instructions: il On va décrire à présent un deuxième mode de réalisation en référence à la figure 1 b. A la différence du réseau de communication illustré à la figure la, les deuxième et troisième ordinateurs R et I sont des simples serveurs de programme, c'est-à-dire qu'ils mettent à la disposition des utilisateurs, le code source ou l'exécutable de certains programmes particulièrement intéressants. Ces deuxième et troisième ordinateurs R et I ne sont pas dotés de moyens de calcul et d'impression suffisants pour mettre en oeuvre les programmes qu'ils hébergent. Ainsi, à titre d'exemple, le deuxième ordinateur I propose le code de la fonction "printimage" alors que le troisième ordinateur R propose le code de la fonction "rotatelmage". Ainsi le fichier print.xpl et le fichier rotate.xpl sont hébergés respectivement sur le deuxième et le troisième ordinateur I et R. Ici, contrairement à l'exemple de réalisation précédent, l'ordinateur client C est doté de moyens suffisants pour permettre des calculs intensifs et l'impression d'images. Dans ce type de réseau, l'évaluation d'une hyper-instruction telle que décrite précédemment génère automatiquement une requête de demande d'obtention du code de la fonction à exécuter. Ainsi, lors de l'évaluation de l'hyper-instruction dans le programme principal main.xpl, I'interpréteur génère et envoi automatiquement une demande d'obtention du fichier au troisième ordinateur R. En retour, l'ordinateur client C reçoit le code de la fonction "rotatelmage" de manière à pouvoir l'exécuter localement. Comme cela sera décrit en référence aux figures suivantes, le code ainsi obtenu peut être mémorisé dans un cache pour une durée prédéterminée, afin d'utiliser successivement cette fonction lors de l'exécution du programme. La génération et l'envoi automatique d'une demande d'obtention du fichier "printxpl" est également adressée de manière analogue au deuxième ordinateur 1. On a décrit précédemment un procédé d'exécution de fonctions hébergées sur des stations distantes. Ce procédé d'exécution peut s'appliquer de manière analogue à des hypervariables. De manière similaire, une hyper-variable est une variable xpl à laquelle on a ajouté un attribut "href" dans lequel l'adresse du serveur sur lequel réside le contenu de la variable peut être mémorisée. Une hyper-variable permet notamment de partager facilement des variables entre plusieurs programmes informatiques. En outre, une hyper20 variable permet de préserver des informations en les déportant sur un serveur, généralement mieux surveillé et entretenu qu'un ordinateur client. On donne à titre d'exemple ci-dessous l'utilisation d'une hypervariable dans la fonction "printimage": Dans cet exemple, la fonction "printimage" s'exécute localement mais, à chaque itération, une requête est envoyée à un serveur du réseau de communication à l'adresse "http://R/pixels.xv", afin d'obtenir le contenu d'une case (i, j) d'un tableau "pixels". On va décrire à présent, en référence à la figure 2, le procédé d'exécution d'un programme conforme à l'invention, dans lequel le programme informatique comprend des hyper-instructions, c'est-à-dire soit des hyperfonctions, soit des hyper-variables, dont le contenu ou le code est hébergé à distance sur un réseau de communication. Le procédé d'exécution comporte d'abord une étape de test E20 dans laquelle on vérifie s'il existe ou non un cache, dans l'espace mémoire de l'ordinateur client sur lequel est exécuté le programme. Dans l'affirmative, on initialise ce cache dans une étape d'initialisation E21. A l'issue de cette initialisation ou lorsqu'il n'existe pas de cache, on procède à une étape d'analyse classique E22 du code du programme de manière à construire un arbre. Cette étape d'analyse E22 permet ainsi de parser et de construire un arbre syntaxique qui correspond à l'emboîtement des fonctions et des instructions. Une étape d'obtention E23 permet de constituer ensuite la liste des fonctions qui sont dans cet arbre. Ces fonctions sont ensuite ajoutées dans une étape d'ajout E24 dans une table de fonctions classique dans lequel toutes les fonctions peuvent être mémorisées en association avec leur code d'exécution. En pratique, on mémorise le nom de chaque fonction en association avec l'adresse du noeud dans l'arbre auquel est situé le code d'exécution de la fonction. On obtient ensuite dans une étape d'obtention E25 une fonction principale, c'est-à-dire la fonction "main" de plus haut niveau dans l'arbre afin d'exécuter le programme. L'ensemble de ces étapes E20 à E25 sont des étapes classiques mises en oeuvre lors de l'exécution d'un programme représenté dans un langage xpl et n'ont pas besoin d'être décrites plus en détail ici. Une étape d'exécution E26 proprement dite permet d'exécuter cette fonction principale. Cette étape d'exécution E26 va être décrite en référence à la figure 3. On obtient dans une étape d'obtention E30 la première instruction I à exécuter dans cette fonction principale. Une étape de test E31 permet de vérifier si cette instruction est une hyper-fonction. En pratique, on vérifie s'il s'agit d'une balise incorporant le nom d'une fonction, associée à une adresse électronique par exemple sous la forme d'un attribut via la référence "href'. Dans l'affirmative, on exécute cette hyper-fonction dans une étape E32 qui sera décrite ultérieurement en référence à la figure 3a. Sinon, une étape de test E33 permet de vérifier si cette instruction I est une hyper-variable. Là encore, on vérifie si il s'agit d'une variable dont la valeur est associée à une adresse électronique via l'attribut "href". Dans l'affirmative, une autre étape de test E34 permet de vérifier s'il s'agit d'une mise à jour ou non de la valeur de la variable. En pratique, les variables peuvent être utilisées soit par la lecture d'une valeur, soit par une mise à jour de cette valeur. La distinction peut être réalisée suivant la présence ou non d'une valeur dans la balise. Par exemple, lorsqu'il s'agit d'un compteur, une balise seule signifiera qu'il s'agit de lire la valeur du compteur, alors que la balise 10 signifiera qu'il s'agit de mettre à jour la valeur 10 du compteur. A l'issue de cette étape de test E34, dans la négative, une étape de lecture E35 de la valeur d'une hyper-variable sera mise en oeuvre comme cela sera décrit plus en détail en référence à la figure 3b. Dans l'affirmative à l'issue de l'étape de test E34, lorsque la variable doit être mise à jour, une étape de mise à jour E36 sera mise en oeuvre telle que cela sera décrit ultérieurement en référence à la figure 3c. Si à l'issue de l'étape de test E33, la première instruction n'est pas une hyper-variable, une étape d'évaluation E37 est adaptée à évaluer l'instruction de manière classique, en exécutant celle-ci localement. A l'issue de cette étape d'évaluation E37 ou encore des étapes d'exécution E32, de lecture E35 ou de mise à jour E36, on vérifie si la fonction principale comporte une autre instruction dans une étape de test E38. Dans l'affirmative, on considère l'instruction suivante dans une étape d'obtention E39 et l'ensemble des étapes E31 à E38 sont réitérées pour cette instruction suivante. Lorsque toutes les instructions de la fonction principale ont été traitées, le programme d'évaluation prend fin. On va décrire à présent en référence à la figure 3a l'exécution d'une hyper-fonction conformément au premier mode de réalisation de l'invention. Dans une étape de lecture E40, la valeur de l'attribut "href' est lue. En pratique, cet attribut comporte une adresse sous la forme d'une adresse électronique d'un serveur sur le réseau de communication. Dans une étape de comparaison E41, cette adresse électronique est comparée à l'adresse locale du serveur exécutant le programme. Si ces adresses sont différentes, le procédé d'exécution comprend une étape d'envoi pour permettre d'obtenir l'exécution de la fonction hébergée à distance sur un autre serveur du réseau de communication. En pratique, on vérifie dans une étape E42 si le mode d'exécution de la fonction est un mode d'exécution à distance ou non. Le mode d'exécution de chaque fonction peut être défini par un mode global associé au serveur local exécutant le programme, par exemple défini par l'utilisateur. L'utilisateur peut ainsi prévoir que toutes les fonctions sont exécutées à distance, sur différents serveurs du réseau de communication. Alternativement, ce mode d'exécution de chaque fonction peut être spécifique à chaque programme, un attribut associé au programme informatique devant être exécuté définissant un mode d'exécution àdistance ou non de chaque fonction. Enfin, un troisième mode de réalisation consisterait à définir pour chaque fonction son mode d'exécution propre. Ainsi, dans le programme informatique écrit en langage xpl, un attribut supplémentaire pourrait être associé à chaque fonction afin de définir un mode d'exécution à distance ou un mode d'exécution locale pour chacune de ces fonctions. Si le mode d'exécution est un mode d'exécution à distance, une étape d'envoi E43 est mise en èuvre afin d'envoyer automatiquement une requête d'exécution de la fonction à distance au serveur référencé par l'adresse électronique. Ce serveur à distance, après réception de cette requête, exécute localement la fonction, puis envoie une réponse au serveur client. Cette réponse, correspondant ainsi à l'exécution de la fonction, est réceptionnée dans une étape de réception E44. La requête et la réponse peuvent être au format xpl. Si à l'issue du test E42, le mode d'exécution de la fonction n'est pas un mode d'exécution à distance, une étape d'envoi E45 est adaptée à envoyer automatiquement une demande d'obtention du code de la fonction. Le serveur à distance envoie alors le code de la fonction demandée de telle sorte que cette réponse est réceptionnée dans une étape de réception E46 sur la station client. Une fois le code ainsi réceptionné, cette fonction peut être exécutée de manière classique sur la station client, après une étape d'extraction E48 du code de la fonction. Cette exécution locale est identique à celle qui est mise en oeuvre par le serveur lorsqu'à l'issue de l'étape E41, l'adresse électronique mémorisée dans l'attribut "href" associé à la fonction n'est autre que l'adresse locale du serveur exécutant le programme. Dans l'affirmative, une étape de lecture F47 du fichier mémorisé localement est suivie de l'étape d'extraction E48 du code de la fonction. A l'issue de cette étape d'extraction E48, une étape d'analyse E49 permet comme précédemment de construire un arbre à partir du code de la fonction et une étape d'obtention E50 permet d'obtenir la liste des fonctions contenues dans ce nouvel arbre. Lors d'une étape d'ajout E51, ces fonctions sont mémorisées dans la table des fonctions. Ces étapes E49 à E51 correspondent ainsi à une étape de mémorisation du code de la fonction. Une étape d'évaluation E52 permet ensuite d'évaluer et d'exécuter la fonction à partir des fonctions mémorisées dans la table. On va décrire à présent en référence à la figure 3b l'étape de lecture E35 de la valeur d'une hyper-variable. On vérifie dans une étape de test E60 si l'adresse électronique mémorisée dans l'attribut "href" correspond à l'adresse locale du serveur exécutant le programme ou non. Dans l'affirmative, une étape de lecture E61 peut être mise en oeuvre localement directement sur la station exécutant le programme. Sinon, on vérifie dans une étape de test E62 si cette valeur est mémorisée ou non dans une mémoire cache de l'ordinateur exécutant le programme. Dans l'affirmative, l'étape de lecture E61 est mise en oeuvre afin de lire localement cette valeur, dans la mémoire cache du serveur exécutant le programme. Sinon, une étape d'envoi E63 est adaptée à envoyer une demande d'obtention de la valeur variable. Cette demande est envoyée à l'adresse électronique de la station référencée par l'attribut "href". Une étape de réception E64 permet de réceptionner en réponse la valeur de la variable adressée par le serveur distant. Une étape d'extraction E65 permet d'extraire cette valeur de la réponse. On vérifie dans une étape de test E66 s'il convient de cacher ou non cette valeur. En pratique il peut être intéressant de mémoriser dans un cache la valeur variable lorsque celle-ci est utilisée successivement dans le même programme informatique. * Dans l'affirmative, une étape de mémorisation E67 permet de mémoriser la valeur variable dans le cache. Cette étape de lecture E35 d'une hyper-variable est ainsi achevée. De manière alternative, l'étape de mise à jour E36 de la figure 2, permettant de mettre à jour une valeur variable, est illustrée à la figure 3c. Comme précédemment, on vérifie dans une étape de test E70 si l'adresse électronique mémorisée dans l'attribut "href' correspond à l'adresse locale du serveur mettant en oeuvre le procédé d'exécution du programme. Dans l'affirmative, une étape de mise à jour E71 est mise en oeuvre afin de mettre à jour la valeur de la variable à partir des éléments mémorisés sur le serveur local. Sinon, une étape de test E72 permet de vérifier si cette variable à mettre à jour est déjà mémorisée dans une mémoire cache. Dans l'affirmative, on met à jour comme précédemment, dans l'étape de mise à jour E71, la valeur de la variable. Sinon, une étape d'envoi E73 permet d'envoyer une demande de mise à jour de la valeur variable à un serveur distant situé sur le réseau de communication à l'adresse électronique mémorisée dans l'attribut "hret' associé à cette hyper-variable. Une étape de réception E74 permet de réceptionner une réponse intégrant la mise à jour de cette valeur variable. Cette valeur variable mise à jour est extraite dans une étape d'extraction E75. Dans une étape de test E76, on vérifie si la valeur variable mise à jour doit être mémorisée ou non. Dans l'affirmative, une étape de mémorisation E77 permet la mémorisation de la valeur variable dans la mémoire cache en vue de son utilisation ultérieure dans l'exécution du programme informatique. Ces procédés de traitement d'une hyper-fonction ou d'une hypervariable tels que décrits précédemment en référence aux figures 3a, 3b et 3c permettent ainsi, grâce à l'attribut "href", de traiter de manière analogue les fonctions ou variables accessibles sur des serveurs distants du réseau ou accessibles localement. En revenant à la figure 2, à l'issue de cette étape d'exécution d'une fonction principale E26, on vérifie dans une étape de test E27 s'il existe une mémoire cache ou non sur le serveur local. Dans l'affirmative, une étape de mise à jour E28 permet de mettre à jour à distance les hyper-variables. Ainsi, lors de la mise à jour successive d'une variable sur un serveur local exécutant un programme, lorsque cette variable est mémorisée dans le cache de l'ordinateur, cette étape de mise à jour E28 permet de retourner à un serveur du réseau de communication la valeur mise à jour de la variable, en vue d'une utilisation ultérieure par la même station locale ou une autre station du réseau de communication. Ce procédé d'exécution permet ainsi d'exécuter de manière relativement simple un programme informatique réparti sur un réseau de communication, en utilisant au mieux les capacités de traitement ou les caractéristiques des différents serveurs du réseau. Afin de mettre en oeuvre ce procédé d'exécution, un dispositif d'exécution comporte des moyens de lecture de chaque balise constituant le programme informatique afin d'identifier les instructions référencées dans cette balise. Il comporte également des moyens d'identification d'une adresse électronique associée à cette balise, de préférence sous la forme d'un attribut (noté "hrefT. Des moyens de comparaison sont adaptés à comparer cette adresse électronique avec l'adresse locale du serveur hébergeant le dispositif d'exécution. Conformément à l'invention, ce dispositif d'exécution comporte des moyens d'envoi adaptés à envoyer une requête à une station serveur du réseau correspondant à l'adresse électronique lue en vue d'obtenir l'exécution de l'instruction lorsque cette adresse électronique est différente de l'adresse locale du serveur hébergeant le dispositif d'exécution. Ce dispositif d'exécution comprend également des moyens de réception d'un résultat d'exécution d'une fonction ou d'un code d'une fonction à exécuter ainsi que des moyens de mémorisation du code d'une fonction à exécuter. Il comprend également des moyens de mémorisation d'une valeur variable extraite ou mise à jour à distance. L'ensemble de ces moyens sont incorporés de préférence dans un ordinateur tel qu'illustré à la figure 4. En particulier, les différents moyens peuvent être incorporés dans un microprocesseur 100, une mémoire morte 101 (en anglais "Read OnIy Memory" ou ROM) étant adaptée à mémoriser un programme d'exécution d'un programme informatique. Ainsi, le dispositif d'exécution peut être mis en oeuvre dans un ordinateur relié à d'autres stations serveurs d'un réseau de communication 1. Une mémoire vive 102 (en anglais "Random Access Memory" ou RAM) est adaptée à mémoriser dans des registres les variables modifiées lors de l'exécution du programme d'exécution. En particulier, la mémoire vive 102 est adaptée à mémoriser la table des fonctions et les différents arbres réalisés à partir de la structure du programme. Ce microprocesseur 100 est intégré à un ordinateur client C qui peut être connecté à différents périphériques, telle qu'une imprimante, ou à d'autres ordinateurs du réseau de communication 1. Cet ordinateur C comporte une interface de communication 110 reliée au réseau de communication pour recevoir ou transmettre des messages ou des requêtes. Ici, dans ce mode de réalisation, les requêtes peuvent être établies selon le protocole de communication HTTP bien connu de l'homme du métier. L'ordinateur C comporte en outre des moyens de stockage de documents, tel qu'un disque dur 106 ou est adapté à coopérer au moyen d'un lecteur de disque 107 (disquettes, disques compacts ou cartes informatiques) avec des moyens de stockage de documents amovibles, tels que des disques 7. Ces moyens de stockage fixes ou amovibles peuvent comporter en outre le code du procédé d'exécution conforme à l'invention, qui, une fois lu par le microprocesseur 100 sera stocké dans le disque dur 106. A titre de variante, le programme permettant au dispositif d'exécution de mettre en oeuvre l'invention pourrait être stocké dans la mémoire morte 1 01. En seconde variante, le programme pourrait reçu pour être stocké comme décrit précédemment par l'intermédiaire du réseau de communication 1. L'ordinateur C possède également un écran 103 permettant par exemple de servir d'interface avec un opérateur à l'aide du clavier 104 ou de la souris 105 ou de tout autre moyen et d'afficher des données, par exemple le résultat du programme informatique après son exécution. L'unité centrale 100 (CPU) va exécuter des instructions relatives à la mise en oeuvre de l'invention. Lors de la mise sous tension, les programmes et méthodes relatives à l'invention stockés dans une mémoire non volatile, par exemple la mémoire morte 101, sont transférés dans la mémoire vive 102 qui contiendra alors le code exécutable de l'invention ainsi que les variables nécessaires à la mise en oeuvre de l'invention. Un bus de communication 112 permet la communication entre les différents sous-éléments de l'ordinateur C ou liés à lui. La représentation du bus 112 n'est pas limitative et notamment le microprocesseur 100 est susceptible de communiquer des instructions à tous sous-éléments, directement ou par l'intermédiaire d'un autre sous-élément. Bien entendu, de nombreuses modifications peuvent être apportées aux exemples de réalisation décrits précédemment sans sortir du cadre de l'invention. REVENDICATIONS 1. Procédé d'exécution sur une station (C) d'un réseau de communication d'un programme informatique représenté dans un langage de balisage, caractérisé en ce qu'il comprend les étapes suivantes: - lecture (E30-E36) d'une balise comprenant l'identification d'une instruction; identification (E40) d'une adresse électronique associée à ladite balise comprenant l'identification d'une instruction; - comparaison (E41, E60, E70) de ladite adresse électronique avec l'adresse locale de la station; et - envoi (E43, E45, E63, E73) si ladite adresse électronique est différente de ladite adresse locale, d'une requête à une station serveur du réseau correspondant à ladite adresse électronique en vue d'obtenir l'exécution de ladite instruction. 2. Procédé d'exécution conforme à la revendication 1, caractérisé en ce que l'adresse électronique est inscrite comme attribut de ladite balise comprenant l'identification d'une instruction. 3. Procédé d'exécution conforme à l'une des revendications 1 ou 2, caractérisé en ce qu'à l'étape d'envoi (E43), une requête de demande d'exécution d'une fonction à distance est envoyée à ladite station serveur du réseau de communication. 4. Procédé d'exécution conforme à la revendication 3, caractérisé en ce qu'il comprend en outre une étape de réception (E44) d'un résultat d'exécution de ladite fonction. 5. Procédé d'exécution conforme à l'une des revendications 1 ou 2, caractérisé en ce qu'à l'étape d'envoi (E45), une requête de demande d'obtention du code d'une fonction à exécuter est envoyée à ladite station serveur du réseau de communication. 6. Procédé d'exécution conforme à la revendication 5, caractérisé en ce qu'il comprend en outre une étape de réception (E46) dudit code de la fonction à exécuter et une étape d'exécution (E48-E52) de la fonction par ladite station (C). 7. Procédé d'exécution conforme à la revendication 6, caractérisé en ce qu'il comprend en outre une étape de mémorisation dudit code de la fonction réceptionnée. 8. Procédé d'exécution conforme à l'une des revendications 1 ou 2, caractérisé en ce qu'à l'étape d'envoi (E63), une requête d'obtention d'une valeur variable est envoyée à ladite station serveur du réseau de communication. 9. Procédé d'exécution conforme à la revendication 8, caractérisé en ce qu'il comprend en outre une étape de réception (E64) d'une réponse et d'extraction (E65) de ladite valeur variable. 10. Procédé d'exécution conforme à l'une des revendications 1 ou 2, caractérisé en ce qu'à l'étape d'envoi (E73), une requête de mise à jour d'une variable est envoyée à ladite station serveur du réseau de communication. 11. Procédé d'exécution conforme à l'une des revendications 8 à 10, caractérisé en ce qu'il comprend une étape de mémorisation (E67, E77) de ladite valeur variable extraite ou mise à jour. 12. Procédé d'exécution conforme à la revendication 11, caractérisé en ce qu'il comprend une étape de mise à jour à distance (E28) d'une variable d'une station serveur du réseau de communication à partir de ladite valeur variable mémorisée. 13. Procédé d'exécution conforme à l'une des revendications 1 à 12, caractérisé en ce que ledit programme informatique est représenté dans un langage utilisant la syntaxe du langage de balisage XML. 14. Procédé d'exécution conforme à l'une des revendications 1 à 13, caractérisé en ce que le réseau de communication met en oeuvre un procédé de communication de type HTTP entre les serveurs dudit réseau. 15. Dispositif d'exécution sur une station (C) d'un réseau de communication d'un programme informatique représenté dans un langage de balisage, caractérisé en ce qu'il comprend: - des moyens de lecture (100, 101, 102) d'une balise comprenant l'identification d'instructions; - des moyens d'identification (100, 101, 102) d'une adresse électronique associée à ladite balise comprenant l'identification d'une instruction; des moyens de comparaison (100, 101, 102) de ladite adresse électronique avec l'adresse locale de la station; et - des moyens d'envoi (100, 101, 102) adaptés à envoyer une requête à une station serveur du réseau correspondant à ladite adresse électronique en vue d'obtenir l'exécution de ladite instruction lorsque ladite adresse électronique est différente de ladite adresse locale. 16. Dispositif d'exécution conforme à la revendication 15, caractérisé en ce qu'il comprend des moyens de réception (100, 101, 102) d'un résultat d'exécution d'une fonction ou d'un code d'une fonction à exécuter. 17. Dispositif d'exécution conforme à la revendication 16, caractérisé en ce qu'il comprend des moyens de mémorisation (100, 101, 102) d'un code de fonctions à exécuter. 18. Dispositif d'exécution conforme à l'une des revendications 15 à 17, caractérisé en ce qu'il comprend des moyens de mémorisation (100, 101, 102) d'une valeur variable extraite ou mise à jour. 19. Dispositif d'exécution conforme à l'une des revendications 15 à 18, caractérisé en ce qu'il est incorporé dans: - un microprocesseur (100) ; - une mémoire morte (101) adaptée à mémoriser le procédé d'exécution d'un programme informatique; et - une mémoire vive (102) comprenant des registres adaptés à mémoriser des variables modifiées lors de l'exécution dudit programme. 20. Ordinateur, caractérisé en ce qu'il comprend des moyens adaptés à mettre en oeuvre le procédé d'exécution conforme à l'une des revendications 1 à 14. 21. Réseau de communication, caractérisé en ce qu'il comprend des moyens adaptés à mettre en oeuvre le procédé d'exécution conforme à l'une des revendications 1 à 14. 22. Programme d'ordinateur comprenant des portions de codes logiciels adaptés à mettre en oeuvre le procédé d'exécution conforme à l'une des revendications 1 à 14, lorsque ledit programme est chargé sur un ordinateur. 23. Moyens de stockage d'information, fixes ou partiellement ou totalement amovibles, adaptés à mémoriser des séquences d'instructions du procédé d'exécution conforme à l'une des revendications 1 à 14.