FR 2961983 A1 20111230 FR 1002683 A 20100625 Le domaine technique de l'invention est celui des procédés permettant le transfert d'une application logicielle, via un réseau, d'un poste informatique vers un autre poste informatique. Le problème des transferts d'applications logicielles est connu notamment dans le domaine de la maintenance et de la mise à jour de ces applications, par exemple au travers d'un réseau interne ou par le réseau internet. Ces mises à jour interviennent de façon plus ou moins régulières lors des connexions des utilisateurs. Elles sont généralement pilotées par les postes clients dont le logiciel installé vérifie les mises à jour disponibles. On connaît également la possibilité pour des postes clients équipés d'un logiciel approprié de prise de contrôle à distance d'ouvrir une application sur un poste distant. Il n'y a alors cependant pas vraiment de transfert d'application mais plutôt l'utilisation de ressources distantes. Il est cependant possible pour le poste qui ouvre une session multipostes de transférer tout ou partie de fichiers ou applicatifs d'un poste vers l'autre. Cependant cette dernière solution nécessite le pilotage de deux postes à partir d'un seul poste et les traitements informatiques sont lents. Les solutions connues ainsi décrites ne sont pas facilement utilisables dans un contexte militaire, par exemple d'un réseau de postes clients à l'intérieur d'un véhicule de combat. La particularité des véhicules de combat est de comporter un équipage réduit (de 3 à 4 personnes) qui met en oeuvre de façon coordonnée différentes applications complexes, en particulier de surveillance vidéo, de cartographie du terrain et de poursuites d'objectifs. Cet équipage doit pouvoir transférer rapidement d'un utilisateur à l'autre une application, par exemple pour réaffecter des tâches suite à une défaillance humaine. De telles réaffectations peuvent résulter d'une évolution d'un contexte opérationnel lors d'une mission de combat. Une des particularités de ce besoin de transferts est qu'il n'est pas (comme dans les applications grand public connues) initié par un utilisateur ayant besoin d'une application donnée mais qu'il doit plutôt être commandé par un autre utilisateur (chef de véhicule par exemple) qui va réaffecter à son équipe certaines applications suite à des défaillances humaines ou des réattributions des tâches. Une autre particularité des besoins de transferts dans le domaine des véhicules militaires est qu'il ne suffit pas de transférer une application exécutable seule mais qu'il faut aussi transférer tout le contexte opérationnel de cette application, c'est à dire la configuration, les paramétrages (notamment d'affichage), les éventuelles autorisations d'utilisation d'un matériel tels qu'ils étaient présents sur un poste donné avant que le besoin de transfert n'apparaisse. Il n'est en effet pas possible matériellement à un des utilisateurs de quitter son poste pour venir paramétrer le poste d'un autre membre de l'équipage. Une telle opération est par ailleurs beaucoup trop longue. Le poste qui reçoit l'application (appelé par la suite poste récepteur) doit rapidement et sans réglages complémentaires pouvoir afficher la configuration fonctionnelle complète de l'application telle qu'elle lui est adressée par le poste qui la lui envoie (poste appelé par la suite poste émetteur). L'écran du poste récepteur doit quasi instantanément afficher l'application dans l'état où elle se trouvait au niveau du poste émetteur au moment du transfert (réglages, configuration et autorisations compris). Un chef de véhicule qui a observé une zone de terrain autour du véhicule doit ainsi pouvoir adresser immédiatement au tireur, non pas une image figée, mais son application de surveillance telle qu'elle est réglée pour montrer un point à viser afin qu'il soit traité par la conduite de tir. L'invention a pour but de proposer un procédé permettant de transférer rapidement une application logicielle et tous ses fichiers de contexte d'un poste émetteur vers un ou plusieurs postes récepteurs. Ceci permet à chaque poste du réseau de pouvoir se substituer à un autre poste du réseau sans qu'il soit pour autant nécessaire d'activer toutes les applications informatiques en même temps sur tous les postes. On gagne ainsi de l'efficacité sans pénaliser les capacités de calcul de chaque poste. L'invention est décrite avantageusement dans le cadre d'une mise en oeuvre dans un réseau interne à un véhicule de combat. Elle peut bien entendu être utilisée dans d'autres domaines, par exemple pour des réseaux de surveillance de sites ou d'installations industrielles ou pour des réseaux de pilotages de procédés chimiques ou de centrales électriques. Ainsi l'invention a pour objet un procédé permettant le transfert d'une application logicielle d'un premier poste informatique, dit poste émetteur, comprenant un ordinateur et un écran vers au moins un deuxième poste informatique, dit poste récepteur, lui aussi composé d'un ordinateur et d'un écran, ces deux postes informatiques étant tous deux raccordés à un même réseau, procédé caractérisé en ce que : on sélectionne une application en cours de fonctionnement sur le poste émetteur et à transférer à partir de ce dernier, on repère à partir du poste émetteur au moins un poste récepteur vers lequel cette application doit être transférée, on transfère vers le poste récepteur une identification d'un exécutable de l'application, on transfère vers le poste récepteur les fichiers de contexte relatifs à l'application sur le poste émetteur afin de permettre au poste récepteur de se positionner sur l'application et avec le contexte en cours tel qu'il existe sur le poste émetteur. Selon une caractéristique, après réception de l'identification de l'exécutable, le poste récepteur vérifie la présence chez lui de cet exécutable, si cette application est déjà présente il lance son ouverture avec les fichiers de contexte reçus, si l'application est absente, le poste récepteur le notifie au poste émetteur qui lui envoie alors le ou les fichiers exécutables d'installation de l'application, que le poste récepteur ouvre ensuite avec les fichiers de contexte déjà reçus. Selon un mode particulier de réalisation, si un poste récepteur reçoit simultanément plusieurs transferts provenant de différents autres postes du réseau, l'ordinateur de ce poste propose à son utilisateur la possibilité de choisir l'application transférée qu'il va effectivement exécuter. Dans ce cas, lorsqu'un poste récepteur accepte un transfert d'application, il le notifie automatiquement aux autres postes du réseau. Selon une autre caractéristique, le poste émetteur attend la notification d'acceptation d'un transfert pour transférer au poste récepteur les fichiers de contexte relatifs à l'application ainsi qu'éventuellement le ou les fichiers exécutables d'installation de l'application. Avantageusement, le repérage du deuxième poste informatique vers lequel une application doit être transférée est réalisé à partir d'une interface graphique qui est présente sur l'écran de chaque poste du réseau, interface graphique qui comprend : un premier moyen, dit de capture, permettant de repérer l'application à transférer, un second moyen dit moyen de localisation du transfert permettant de choisir un autre poste du réseau et d'initier le transfert de l'application vers ce poste. Le moyen de capture pourra comporter un dispositif de sélection de l'application à transférer par un bouton icône actionné par l'utilisateur lorsque l'application est ouverte. Le moyen de capture pourra comporter un écran tactile, 5 une action par l'utilisateur sur l'écran au niveau d'une zone de l'application ouverte permettant de la sélectionner. Le moyen de localisation du transfert pourra comprendre des symboles graphiques schématisant les écrans des autres postes du réseau. Chaque mise en oeuvre d'un moyen de capture par un poste émetteur pourra être notifiée automatiquement via le réseau aux autres postes. L'invention sera mieux comprise à la lecture de la description qui va suivre de différents modes de réalisation, description faite en référence aux dessins annexés et dans lesquels : - la figure 1 montre un exemple de bus raccordant plusieurs postes clients et différents équipements, - la figure 2 schématise l'organisation des ordinateurs 20 et écrans des différents postes clients. En se reportant à la figure 1, un réseau 1, formé par un bus de communication, permet de relier entre eux différents postes informatiques 2.1, 2.2, 2.3 et 2.4 ainsi que différents équipements ici on n'a représenté que deux 25 caméras numériques 3.1 et 3.2. D'autres équipements seront bien entendus présents, tels que des motorisations, des moyens de pointage de tourelles de système d'arme... Ce bus de communication 1 (représenté ici comme un bus bifilaire la,lb) est par exemple intégré à l'architecture 30 d'un véhicule militaire et les postes informatiques pourront être : 2.1 le poste de chef du véhicule (C), 2.2 le poste du tireur (T), 2.3 le poste du pilote (P) et 2.4 le poste d'un observateur (0) (rôle attribué par exemple à un des combattants embarqués dans le véhicule). 6 Les postes informatiques 2.i ainsi que les équipements 3.i seront raccordés au bus 1 d'une façon classique par l'intermédiaire d'interfaces de connexion 4.1, 4.2 ... 4.6. Ces interfaces pourront être constituées par des boîtiers d'interconnexion classique ou bien le plus souvent par une carte réseau incorporée au poste informatique ou à l'équipement. D'une façon classique les interfaces 4.i permettent d'émettre sur le bus les messages de commande destinés aux équipements 3.i ainsi que les messages de communication destinés aux postes informatiques 2.i. Les émissions se font en mettant en oeuvre un protocole de communication classique de type Ethernet par exemple. La figure 2 montre de façon plus précise l'architecture interne d'un poste informatique 2.i, ici celui 2.1 du chef de véhicule C. Ce poste comporte un ordinateur 5.1 et un écran 12.1 qui sont reliés l'un à l'autre. L'ordinateur 5.1 incorpore de façon classique une unité de calcul 6.1 et une unité de mémorisation 7.1 qui renferme des logiciels applicatifs Sa,Sb,Sc (appelés aussi par la suite applications). Ici seuls trois logiciels applicatifs (ou applications) sont représentés. On a figuré pour chaque application Si deux rectangles : un rectangle Si(exe) qui symbolise le ou les fichiers exécutables qui font fonctionner l'application en question et un rectangle Si(ctx) qui représente les fichiers de contexte relatifs à cette application. Bien entendu les fichiers exécutables sont en mémoire d'une façon permanente dans l'unité de mémorisation 7.1 que 30 l'application Si soit en cours d'exécution ou non. Par contre les fichiers de contexte sont des fichiers qui sont en mémoire de façon temporaire lorsque l'application est en cours d'exécution (fichiers en mémoire vive). Ces fichiers permettent en particulier de restaurer un contexte d'une application après un arrêt brutal d'un ordinateur. On n'a pas distingué sur la figure 2 le type de mémoire en jeu (mémoire de stockage ou mémoire vive) et, par souci de simplification du dessin, on a placé les fichiers exécutables et de contexte dans la même unité de mémorisation 7.1. D'une façon bien connue les fichiers de contexte renferment l'état d'une application logicielle (Si) donnée à un instant donné. Ces fichiers de contexte contiennent ainsi les informations donnant les modes de paramétrage de l'application Si qui ont été choisis par l'utilisateur considéré et qui sont mis en oeuvre par l'application Si à un instant donné (taille et localisation de la fenêtre de l'application sur l'écran, taille de caractères, polices utilisées, menu(s) en cours d'exécution...). On a représenté sur la figure 2 par le rectangle 8 un logiciel particulier qui pilote les différentes étapes du procédé selon l'invention, ce logiciel sera qualifié par la suite de logiciel de transfert d'application. Ce logiciel est incorporé dans une autre mémoire de l'unité de calcul 6.i de tous les postes 2.i du réseau ce qui permet de conduire le procédé à partir de n'importe quel poste. Les différents postes 2.i sont reliés les uns aux autres 25 par la ligne de bus de données 1. On va considérer dans le descriptif qui va suivre que c'est le poste 2.1 (poste chef) qui met en oeuvre le procédé. Ce poste est également dit poste émetteur, les autres postes 2.2, 2.3 et 2.4 du réseau étant des postes récepteurs 30 potentiels. Conformément à l'invention le logiciel 8 est codé de façon à accomplir différentes fonctions. Tout d'abord tous les logiciels 8 des différents postes permettent de faire apparaître sur les différents écrans 12.i une interface graphique qui comprend un premier moyen 9, dit de capture, permettant de repérer l'application à transférer. Ce moyen de capture est figuré ici par un bouton icône déplaçable et en forme de flèche 9 qui est manoeuvrable par l'utilisateur (soit par une interface de type souris soit par appui du doigt sur un écran de type tactile). L'interface graphique comprend aussi un second moyen 10, dit moyen de localisation du transfert, permettant de choisir un autre poste du réseau et d'initier le transfert de l'application vers ce poste. Le moyen de localisation du transfert 10 comprend ici des symboles graphiques (112.2,112.3,112.4) schématisant les écrans des autres postes du réseau. On notera que sur chaque poste 2.i on affiche trois symboles 112,E qui se rapportent aux écrans des trois autres postes du réseau. Le logiciel 8, qui est piloté à partir de l'interface graphique, est codé de façon à accomplir les étapes suivantes: On sélectionne tout d'abord une application (par exemple Sa) en cours de fonctionnement sur le poste émetteur 2.1 et que l'on souhaite transférer vers un poste récepteur (2.3 par exemple). Cette sélection de l'application est faite par exemple à l'aide du bouton icône 9 qui est positionné par l'utilisateur sur l'application Sa ouverte ("clic" sur une fenêtre 13a de l'application Sa). On repère ensuite à partir du poste émetteur au moins un poste récepteur vers lequel cette application doit être transférée, par exemple le poste 2.3 qui est associé au symbole 112.3. Ce repérage pourra se faire à l'aide du même bouton icône 9 qui sera positionné par l'utilisateur sur le symbole 112.3 correspondant au poste récepteur choisi ("clic" sur le symbole 112,3) . 9 Comme suite à ce repérage, le logiciel 8 va transférer vers le poste récepteur 2.3 ainsi choisi une identification de l'exécutable (Sa(exe)) de l'application (Sa) à exécuter. Cette identification comportera le nom du fichier exécutable de cette application (avec le suffixe .exe). Le logiciel de transfert qui est présent sur le poste récepteur 2.3 va être activé par ce transfert d'identification et va alors vérifier la présence chez lui de cet exécutable. Si cette application est déjà présente, le poste récepteur 2.3 va la lancer avec les fichiers de contexte (Sa(ctx)) que le poste émetteur 2.1 lui a également envoyé. Si l'application Sa est absente, le logiciel de transfert du poste récepteur 2.3 le notifie au poste émetteur 2.1 qui lui envoie alors en réponse, et via le bus 1, le ou les fichiers exécutables (Sa(exe)) permettant l'installation de l'application Sa. Le poste récepteur 2.3 commandera ensuite l'ouverture de ces exécutables. Comme cela a déjà été précisé ci-dessus, parallèlement à l'envoi de l'identification, le logiciel 8 va transférer vers le poste récepteur 2.3 les fichiers de contexte (Sa(ctx)) relatifs à l'application Sa. Ces fichiers de contexte contiennent ici notamment les dimensions du cadre de l'application 13a, les coordonnées de sa localisation sur l'écran 12.1, l'état en cours de l'application (à titre d'exemple illustratif : une étoile 14 en bas à gauche sur la fenêtre). Ceci a pour effet de commander l'affichage, sur l'écran 12.3 du poste récepteur 2.3, de la fenêtre 13a de l'application Sa, fenêtre qui s'affichera sur l'écran 12.3 à une place identique à celle occupée sur l'écran 12.1 avec les mêmes dimensions et avec la même étoile 14 disposée dans le coin en bas à gauche. Aucune opération de la part de l'utilisateur du poste 2.3 n'est nécessaire pour régler ou paramétrer l'application (Sa) qu'il récupère telle que le poste 2.1 la lui a transmise. A titre d'exemple comparatif, l'écran 12.4 du poste 2.4 affiche la même application Sa mais avec un contexte différent : une fenêtre localisée et dimensionnée de façon différente, fenêtre affichant une lune 15 en haut à droite. L'écran 12.2 du poste 2.2 affiche une fenêtre 13b d'une application Sb. Ainsi n'importe quel poste récepteur peut se trouver, pratiquement instantanément, sans réglage ni paramétrage, avec un affichage qui est celui d'un autre poste. Avec le procédé selon l'invention le logiciel de transfert 8 qui est installé sur un poste émetteur va dialoguer avec un logiciel de transfert 8 présent sur un poste récepteur et les ressources de calcul seront donc partagées entre les postes. Le poste récepteur chargera l'application si elle est présente chez lui tout en la configurant grâce aux fichiers de contexte transmis par le poste émetteur. Le poste émetteur transfèrera l'exécutable avec les fichiers de contexte si l'application est absente dans le poste récepteur. Ceci permet à un poste occupé à une tâche de pouvoir transférer cette tâche vers un autre poste en conservant tout 25 le contexte opérationnel. Pour la clarté de l'exposé, on a en effet décrit de façon très schématique les applications et leurs contextes. Une application opérationnelle pratique est par exemple, pour un chef de véhicule qui vient de localiser une cible 30 potentielle avec une application de vidéo surveillance, de pouvoir transférer à un autre poste son application de vidéo surveillance, avec le contexte opérationnel (réglages de contrastes vidéos, incrustation des repères pour la cible détectée...) pour permettre le traitement de la cible par un système d'arme. Le procédé selon l'invention permet également de transférer à un poste qui n'est pas un poste de tir, l'application permettant la commande de la tourelle et le tir de l'arme avec les indications de pointage recueillies par le chef et avec les autorisations de tir nécessaires. L'invention permet ainsi d'accroître les performances du réseau 1 ainsi que l'efficacité opérationnelle de l'équipage, puisque l'affectation des tâches et des postes peut être reconfigurée rapidement. Divers perfectionnements sont possibles sans sortir du cadre de l'invention. On a décrit ainsi le cas simple où un poste émetteur 15 transfère une application vers un poste récepteur bien défini. Il est possible, lorsque tous les postes peuvent ainsi transférer en parallèle des applications, de conditionner le transfert effectif d'une application à l'acceptation de ce 20 transfert par le poste récepteur pressenti. Le logiciel 8 sera alors modifié de façon à incorporer une toute première étape dans laquelle l'ordinateur du poste récepteur prévu proposera à son utilisateur la possibilité d'accepter ou non ce transfert. 25 Si le poste récepteur accepte, le procédé se déroule suivant les étapes décrites précédemment, s'il refuse, il n'y a pas de transfert. Ceci est particulièrement important quand plusieurs postes récepteurs peuvent recevoir simultanément des 30 applications provenant de plusieurs postes émetteurs. Dans ce cas, et préalablement à tout transfert, le logiciel 8 tournant sur l'ordinateur du poste récepteur prévu fera afficher sur l'écran de ce poste récepteur, la liste des différentes applications qui doivent lui être transférées. L'utilisateur pourra alors choisir l'application transférée qu'il va effectivement exécuter. Ce n'est qu'une fois ce choix effectué que le procédé se déroule suivant les étapes décrites précédemment. Lorsqu'un poste récepteur accepte un transfert d'application, il le notifie par ailleurs automatiquement aux autres postes du réseau, ceci permettra à chacun de connaître l'état des transferts en cours, acceptés ou non. Pour améliorer la connaissance par chaque utilisateur des transferts en cours, on modifiera le logiciel de telle sorte qu'à chaque mise en oeuvre d'un moyen de capture 9 par un poste émetteur, cette mise en oeuvre est également notifiée automatiquement via le bus 1 aux autres postes. Cette notification pourra avoir la forme de message brefs 15 tels que : "Poste 2.1 lance transfert d'application Sa vers poste 2.3 ou 2.4." Dans ce cas l'un ou l'autre des postes 2.3 ou 2.4 pourra accepter le transfert qui se fera effectivement vers le poste 20 qui est prêt à l'accepter. D'autres variantes sont possibles en particulier au niveau des interfaces graphiques utilisées. On a décrit précédemment un moyen de capture et un moyen de localisation constitués par une simple icône 9 qui est 25 positionnée par l'utilisateur sur l'application à transférer puis sur le symbole graphique schématisant l'écran du poste destinataire. On pourra utiliser comme interface (moyen de capture / moyen de localisation) un simple écran tactile. Une action par l'utilisateur sur l'écran au niveau d'une 30 zone de l'application ouverte permettant alors de la sélectionner. Une action sur le symbole de l'écran destinataire permettant de choisir le destinataire de l'application. D'une façon classique, un mouvement de glissement de l'application vers les symboles du ou des écrans souhaités pourra aussi être envisagé. REVENDICATIONS1- Procédé permettant le transfert d'une application logicielle (Sa,Sb,Sc) d'un premier poste informatique (2.1), dit poste émetteur, comprenant un ordinateur (5.1) et un écran (12.1) vers au moins un deuxième poste informatique (2.2,2.3,2.4), dit poste récepteur, lui aussi composé d'un ordinateur et d'un écran, ces deux postes informatiques étant tous deux raccordés à un même réseau (1), procédé caractérisé en ce que: on sélectionne une application (Sa) en cours de fonctionnement sur le poste émetteur (2.2) et à transférer à partir de ce dernier, on repère à partir du poste émetteur au moins un poste 15 récepteur (2.3) vers lequel cette application (Sa) doit être transférée, on transfère vers le poste récepteur (2.3) une identification d'un exécutable (Sa(exe)) de l'application, on transfère vers le poste récepteur (2.3) les fichiers 20 de contexte (Sa(ctx)) relatifs à l'application (Sa) sur le poste émetteur (2.1) afin de permettre au poste récepteur (2.3) de se positionner sur l'application et avec le contexte en cours tel qu'il existe sur le poste émetteur. 2- Procédé selon la revendication 1, caractérisé en ce 25 qu'après réception de l'identification de l'exécutable (Sa (exe)) , le poste récepteur (2.3) vérifie la présence chez lui de cet exécutable, si cette application est déjà présente il lance son ouverture avec les fichiers de contexte (Sa(ctx)) reçus, si l'application est absente, le poste 30 récepteur le notifie au poste émetteur (2.1) qui lui envoie alors le ou les fichiers exécutables d'installation de l'application (Sa), que le poste récepteur (2.3) ouvre ensuite avec les fichiers de contexte déjà reçus. 3- Procédé selon une des revendications 1 ou 2, caractérisé en ce que, si un poste récepteur (2.i) reçoit simultanément plusieurs transferts provenant de différents autres postes du réseau (1), l'ordinateur (5.i) de ce poste propose à son utilisateur la possibilité de choisir l'application transférée qu'il va effectivement exécuter. 4- Procédé selon la revendication 3, caractérisé en ce que lorsqu'un poste récepteur accepte un transfert d'application il le notifie automatiquement aux autres postes du réseau (1). 5- Procédé selon la revendication 4, caractérisé en ce que le poste émetteur (2.1) attend la notification d'acceptation d'un transfert pour transférer au poste récepteur (2.3) les fichiers de contexte (Sa(ctx)) relatifs à l'application (Sa) ainsi qu'éventuellement le ou les fichiers exécutables (Sa(exe)) d'installation de l'application. 6- Procédé selon une des revendications 1 à 5, caractérisé en ce que le repérage du deuxième poste informatique vers lequel une application (Sa) doit être transférée est réalisé à partir d'une interface graphique qui est présente sur l'écran de chaque poste du réseau, interface graphique qui comprend : un premier moyen (9), dit de capture, permettant de repérer l'application (Sa) à transférer, un second moyen (10) dit moyen de localisation du transfert permettant de choisir un autre poste du réseau et d'initier le transfert de l'application vers ce poste. 7- Procédé selon la revendication 6, caractérisé en ce que le moyen de capture (9) comporte un dispositif de sélection de l'application à transférer par un bouton icône actionné par l'utilisateur lorsque l'application est ouverte. 8- Procédé selon la revendication 6, caractérisé en ce que le moyen de capture (9) comporte un écran tactile, uneaction par l'utilisateur sur l'écran au niveau d'une zone de l'application ouverte permettant de la sélectionner. 9- Procédé selon la revendication 6, caractérisé en ce que le moyen (10) de localisation du transfert comprend des symboles graphiques (112.2,112.3,112.4) schématisant les écrans des autres postes du réseau (1). 10- Procédé selon une des revendications 6 à 9, caractérisé en ce que chaque mise en oeuvre d'un moyen de capture (9) par un poste émetteur est notifiée automatiquement via le réseau (1) aux autres postes.