FR 2822563 A1 20020927 FR 0104047 A 20010321 La présente invention a pour objet un procédé de sauvegarde et de restauration de l'ensemble des paramètres de configuration d'une plateforme informatique par exemple un ordinateur individuel ou d'un parc d'ordinateurs, par l'intermédiaire d'un serveur par exemple un serveur Intranet ou Internet. Elle concerne aussi bien la configuration du système d'exploitation de la plateforme que celle des logiciels spécialisés (traitements de texte, tableurs, navigateurs Internet, gestionnaires de courrier électronique, etc...) installés sur cette plateforme. Le procédé objet de l'invention possède la propriété d'être indépendant du système d'exploitation utilisé par la plateforme dont on sauvegarde la configuration, cette configuration pouvant être restaurée sur des machines équipées d'un système d'exploitation différent. De façon analogue, les paramètres de configuration des logiciels peuvent être rétablis sur des logiciels différents pouvant présenter des fonctionnalités similaires. Le procédé offre en outre la possibilité d'effectuer toutes les opérations de modification, insertion ou suppression des configurations sauvegardées et de protéger leur confidentialité. L'invention s'applique notamment, mais non exclusivement, à la récupération de sa configuration par un utilisateur contraint de changer de plateforme, à la standardisation des configurations sur un parc d'ordinateurs ou encore à la réinstallation après un remplacement de matériel. On connaît déjà certaines solutions partielles au problème de l'enregistrement et de la répétition des configurations d'ordinateurs, soit par le choix des matériels, soit par des outils logiciels. Parmi les solutions matérielles, on peut citer l'ordinateur portable, qui répond au besoin de transport d'une configuration, mais non à celui de sa répétition. Il présente de plus les inconvénients connus d'un coût relativement élevé et d'une ergonomie limitée. L'ordinateur de réseau ("Network computer") apporte quant à lui une standardisation par nature à l'intérieur du réseau, la configuration du système et des logiciels étant centralisée dans le serveur principal. Mais on sait les limites de débit des réseaux, peu utilisables par exemple pour l'animation d'objets graphiques complexes. De nombreux logiciels présents sur le marché apportent par ailleurs des facilités partielles pour la sauvegarde et la reproduction des configurations des utilisateurs. Une première famille de logiciels [réf :"Webshot","Stardock"] ne font que faciliter la personnalisation de l'ordinateur, seulement au niveau de la configuration du fond d'écran. Dans une seconde catégorie, on trouve les logiciels qui permettent de créer et sauvegarder localement les seuls paramètres d'ergonomie du bureau [réf : "Desktop Architect"]. Un autre groupe de logiciels propose le déploiement vers l'ensemble des ordinateurs d'un même parc d'une seule configuration du système [réf : "RapidDeploy"]. On trouve encore des logiciels [réf :"User Roaming Profile"] dont la fonction est de reporter le profil de configuration des utilisateurs sur un serveur local. Une telle solution ne gère pas le cas d'un parc d'ordinateurs non homogène, ni celui d'un changement de système d'exploitation ou d'une réinstallation. D'autres solutions proposent la sauvegarde des fichiers sur un site Internet [réf :"Visto. com"]. Dans cette approche, de même que pour les logiciels précédemment évoqués, il est clair que la configuration du système elle-même n'est pas sauvegardée et ne peut donc être restaurée. Un autre type de services proposé sur Internet fait appel à la procédure dénommée"Application Service Provider" (ASP) dans laquelle les logiciels d'application sont déportés sur le site serveur [réf :"webos. com"]. Dans cette solution, la configuration des logiciels déportés est bien standardisée pour l'ensemble des utilisateurs, mais les possibilités de personnalisation sont très limitées. On peut enfin citer les logiciels spécialisés dans la sauvegarde sur Internet de la configuration complète d'un seul outil ou ensemble d'outils logiciel,"Office 2000"par exemple [réf :"Save My Settings Wizard"]. Ce service ne concerne évidemment pas la configuration du système ni celle des autres logiciels. La présente invention a donc pour but de supprimer ces inconvénients et limitations, et d'offrir un moyen général de sauvegarde et de restauration de l'ensemble des paramètres de configuration d'une plateforme informatique et des préférences de l'utilisateur, aussi bien au niveau du système d'exploitation que des logiciels spécialisés, avec la propriété essentielle de permettre la récupération de cette configuration sur un système ou des logiciels différents de ceux à partir desquels a été effectuée la sauvegarde. Elle propose, à cet effet, un procédé de sauvegarde et de restauration de la configuration d'une plateforme informatique telle que, par exemple, un ordinateur, par connexion sur un serveur par exemple un serveur Internet/Intranet, ce procédé comportant une phase de sauvegarde comprenant : la demande de sauvegarde de la plateforme sur un serveur, - l'acceptation de la demande par le serveur et la transmission par le serveur à la plateforme de données pour analyser la plateforme, - l'analyse interne de la plateforme à partir des données transmises par le serveur et la transmission au serveur des résultats de l'analyse, - la préparation par le serveur des données pour sauvegarder la configuration de la plateforme et la transmission à la plateforme des données pour sauvegarder la configuration de la plateforme, - la sauvegarde par la plateforme des données de configuration de la plateforme et la transmission de ces données au serveur, - la conversion des données de configuration de la plateforme puis la sauvegarde par le serveur de ces données. Ce procédé pourra en outre comprendre une phase de restauration des données de configuration sauvegardées par le site serveur sur la plateforme demandeur éventuellement distinct de la susdite plateforme, cette phase de restauration comprenant les étapes suivantes : - la demande de restauration émise par la plateforme demandeur à destination du serveur, - l'acceptation de la demande par le site serveur et la transmission par celui- ci à la plateforme demandeur, de données d'analyse, - l'analyse interne de la plateforme à l'aide des données d'analyse et la transmission par la plateforme au serveur des résultats de l'analyse, - la conversion par le serveur, en fonction de ces résultats, des données pour la restauration de la configuration de la plateforme et la transmission par le serveur de ces données à la plateforme, - la restauration de la configuration sur la plateforme. Avantageusement, l'application de sauvegarde et de restauration des configurations pourra être proposée aux utilisateurs sous la forme d'une procédure ASP sur Internet ou sur Intranet (définie précédemment). Un tel choix présente les avantages suivants : - suppression des opérations d'installation et de déploiement dans le cas de sites à plusieurs plateformes, puisqu'il n'y a pas de logiciel spécifique à mettre en place sur la machine de l'utilisateur ; - absence d'incompatibilité avec les logiciels déjà installés et absence de problèmes de puissance ou de capacité, l'application objet de l'invention étant exécutée sur le site serveur ; - mises à jour centralisées de l'application, nécessaires lors de l'apparition de nouvelles versions de logiciels sur le marché, sans aucune intervention de l'utilisateur ; - suppression des risques de copiage de l'application ; - économie pour le fournisseur de l'ASP des coûts de distribution et de support à l'installation. Dans cette solution, le procédé selon l'invention comprend au moins, de façon générale, les sous-ensembles suivants, qui sont donc tous installés sur le site du serveur : - une Base de Données, préférentiellement sur le modèle relationnel, dont les différentes parties sont : - une Base Applicative, contenant les données nécessaires au bon fonctionnement de l'application, - une Base Grand Public, relative aux informations sur les utilisateurs de l'application, - une Base Entreprise, fournissant les informations commerciales liées à son utilisation ; (Les deux bases de données Grand Public et Entreprise gèrent les configurations des utilisateurs, la Base Entreprise ayant un complément pour l'administration des configurations des employés des entreprises) ; - un Interface (serveur Web utilisant le protocole HTTP), gérant les interactions entre les différents sous-ensembles de l'application ; - un Serveur Applicatif, assurant l'ensemble des fonctions de connexion des utilisateurs, de sauvegarde et de restauration des configurations ; - une Appliquette ou applet (petit programme intégré dans une page HTML et qui accomplit une fonction), préférentiellement programmée en langage JAVA, téléchargée sur l'ordinateur de l'utilisateur lors de la connexion, qui sera dénommée AP par commodité dans la suite de la description. Le Serveur Applicatif et l'Appliquette utilisent un modèle arborescent, dans lequel chaque arbre est défini par une racine et peut contenir une liste d'arbres dépendants. A l'intérieur de chaque arbre, les données sont organisées en chaîne, un système de pointeurs permettant d'accéder à l'élément contenu dans un maillon de la chaîne, ou bien de se déplacer vers le maillon suivant ou le maillon précédent. Des fonctions associées permettent d'insérer ou de détruire des arbres ou des éléments. Le fonctionnement du Serveur Applicatif met en oeuvre une"socket" (canal) d'écoute qui reste en attente d'une demande de connexion. Il reçoit une requête du Serveur qui a précédemment identifié l'utilisateur (en vérifiant son mot de passe) et associe alors à cet utilisateur une de ses"sockets". Le processus de"Login"sur le serveur Web a en effet initialisé un Objet Utilisateur. Celui-ci effectue étape par étape le traitement demandé par la requête. Cet Objet est mis en action grâce à un ensemble d'Unités d'exécution ("threads") associées à la"socket". Ces Unités d'exécution sont normalement en sommeil et remis à l'état actif par les réponses aux opérations de lecture ou d'écriture demandés par l'Objet Utilisateur. Ils transmettent alors à celui-ci l'ordre de poursuivre le traitement jusqu'à obtention du résultat demandé. Des dispositifs de vérification des dépassements des durées limitées permettent d'éliminer les connexions qui n'ont pas abouti. Préférentiellement, les données seront cryptées en RSA. La partie non cryptée des requêtes (données) sera masquée. Le fonctionnement détaillé de l'Objet Utilisateur fait appel aux concepts généraux suivants : - un Module comprend l'ensemble des paramètres d'un système d'exploitation ou d'un logiciel spécialisé donné ; durant la phase préparatoire d'une procédure de sauvegarde ou de restauration, avant de recevoir les valeurs des paramètres concernés ; - un Pré-module est un ensemble de données minimales caractérisant le Module ; - un Paquet regroupe l'ensemble des Modules d'une même famille de logiciels (Traitement de Texte par exemple) ; - une Configuration est l'ensemble des Paquets pour un utilisateur. Dans le cas de la Sauvegarde, le mécanisme de fonctionnement de l'Objet Utilisateur selon l'invention comprend au moins les étapes suivantes : - Connexion * récupération de la requête en provenance de l'AP * récupération dans la Base des Paquets concernés et de l'Outil d'analyse * génération de l'Outil d'analyse * envoi de l'Outil d'analyse vers l'utilisateur par l'intermédiaire de l'AP - Analyse * récupération de l'Outil d'analyse renvoyé par l'AP * si l'Outil d'analyse indique la présence de deux Modules au moins appartenant au même Paquet : - génération du Choix de Modules (dont le rôle est la récupération des noms de Modules) - envoi du Choix de Modules vers l'AP * récupération dans la Base des Pré-modules correspondants avec les moyens de conversion associés * envoi de ces Pré-modules vers l'AP - Traitement * récupération d'un Pré-module à partir de l'AP * envoi d'un acquittement de cette réception vers l'AP * si tous les Modules ont été traités, passage à l'étape d'Envoi * génération du Module traité * reprise au début du Traitement - Envoi * récupération d'une demande de Module venant de l'AP * envoi vers l'AP de tous les Modules en attente - Réception * récupération d'un Module en provenance de l'AP * acquittement de cette réception * utilisation des moyens de conversion pour reformer un Paquet * envoi du Paquet reconstitué à la Base * reprise au début de la Réception jusqu'à ce que tous les Modules soient reçus - Fin de la procédure Un mécanisme similaire, selon l'invention, est mis en oeuvre pour la Restauration. Il comporte au moins les phases suivantes : - Connexion * récupération de la requête en provenance de l'AP * récupération dans la Base des Paquets concernés et de l'Outil d'analyse * génération de l'Outil d'analyse * envoi de l'Outil d'analyse vers l'utilisateur par l'intermédiaire de l'AP - Analyse * récupération de l'Outil d'analyse renvoyé par l'AP * récupération dans la Base des Pré-modules correspondants avec les moyens de conversion associés * envoi de ces Pré-modules vers l'AP - Traitement * récupération d'un Pré-module à partir de l'AP * envoi d'un acquittement de cette réception vers l'AP * si tous les Modules ont été traités, passage à l'étape d'Envoi * génération du Module traité * reprise au début du Traitement - Envoi * récupération d'une demande de Module venant de l'AP * envoi vers l'AP de tous les Modules en attente - Fin de la procédure Dans tous les transferts entre l'Utilisateur, le Serveur et la Base de données des informations nécessaires à la mise en oeuvre de l'invention, il est avantageux d'utiliser une méthode de sérialisation des différents objets, de façon à obtenir un flux de données aisément transmissible. Dans cette approche, chaque objet transmis est représenté par une suite d'octets formatée, qui comporte successivement : - un octet de début, - un identifiant de classe, qui définit la classe laquelle appartient l'objet, - la zone des données proprement dite, - un octet de fin. Les octets de début et de fin sont des redondances destinées à assurer l'intégrité des données. Les différentes classes d'objets peuvent être, de façon non exhaustive : - arbre, - arbre principal, - racine principale, - racine principale avec identifiant, - racine de paramètre absolu, - racine de paramètre de l'utilisateur, - racine de commande (dont le contenu correspond à des ordres à exécuter), - racine d'identifiant, - racine d'identifiant avec valeur, - racine externe, - racine d'action pour le Serveur, - racine d'action pour l'Utilisateur. La longueur et le format de la chaîne de données contenue dans l'objet sérialisé dépendent bien entendu de la classe à laquelle appartient l'objet. Après transmission, chaque objet est dé-sérialisé avant d'être utilisé, la lecture de l'identifiant de classe permettant l'interprétation de la zone des données. Selon l'invention, les échanges de données entre l'AP, qui assure la fonction d'interface avec l'Utilisateur, et le Serveur Applicatif, qui effectue les traitements demandés, seront préférentiellement réalisés en intégrant le flux de données dans un protocole HTTP. Ce choix présente entre autres l'avantage de permettre le franchissement des murs coupe-feu éventuellement installés sur le site du Serveur. Dans cette optique, les échanges entre l'AP et le Serveur prendront essentiellement la forme d'envois de requêtes par l'AP, auxquelles répondent des actions exécutées par le Serveur, qui en retourne les données résultantes. Les requêtes émises par l'AP répondront avantageusement à un format composé de quatre blocs : - l'en-tête HTTP, qui peut présenter une forme adaptée au format des blocs suivants ; - l'identifiant de l'utilisateur, crypté selon l'algorithme évoqué plus haut et qui comprend lui-même quatre parties : - l'identifiant de la clé à utiliser pour décrypter l'identité, - l'indication de la dimension de la partie cryptée, - l'identifiant proprement dit de l'utilisateur, - le nombre d'itérations, qui détermine le numéro des connexions simultanées pour un même utilisateur ; - l'en-tête de requête, qui contient l'indication du type (normal ou requête d'erreur) et de la nature de la requête ; - les données nécessaires pour effectuer la requête. La réponse du Serveur à une requête pourra comprendre de façon similaire : - l'en-tête HTTP ; - l'en-tête de réponse, qui contient l'indication du type (normal ou cas d'erreur) et de la nature de la réponse ; - les données de la réponse. A ce dialogue pourra avantageusement être associée la gestion d'un nombre maximal d'erreurs, au-delà duquel la réponse du Serveur signale une prochaine déconnexion. Le protocole de communication entre le Serveur Web et le Serveur Applicatif comprendra au moins des requêtes de connexion émises par le Serveur Web, qui ne nécessitent pas de cryptage, et leur réponse par le Serveur Applicatif. Le Serveur Web lui-même a pour fonction de recevoir la demande de connexion de l'utilisateur, avec son mot de passe. Après validation, une procédure Script (fichier de texte contenant un ensemble d'instructions destinées à être exécutées par un interpréteur de script, cette procédure faisant appel à une bibliothèque de fonction dynamique DAL) est exécutée, qui permet de : - authentifier l'utilisateur grâce au Serveur Applicatif, - lire dans la Base les données le concernant, - afficher ces informations sous forme arborescente, proposer à l'utilisateur une sélection dans cette arborescence et le choix de la fonction à exécuter (Sauvegarde ou Restauration). L'AP effectue une demande, les paramètres correspondants sont alors transmis à l'AP, qui effectue son traitement et gère ses échanges de données avec le Serveur Applicatif de façon autonome, seul l'état d'avancement du traitement étant visible pour l'utilisateur. L'AP elle-même a pour fonction de sauvegarder ou de restaurer des Modules sur le poste de l'utilisateur. Pour ce faire, son exécution est pilotée par deux Unités d'exécution (threads) : le principal assure le traitement des données, l'autre la connexion avec le Serveur. Le processus d'exécution principal, compte-tenu du fonctionnement selon l'invention de l'Objet Utilisateur décrit précédemment, comportera au moins dans le cas de la Sauvegarde les étapes suivantes : - génération et envoi au Serveur des options choisies par l'utilisateur ; - réception des Outils d'analyse ; - analyse de la plateforme et renvoi des Outils d'analyse ; - en cas de présence de plusieurs Modules dans un même Paquet, réception du Choix de Modules, acquisition des choix de l'utilisateur et renvoi au Serveur ; - réception des Pré-modules ; - Module par Module, lecture des paramètres actuels et renvoi au Serveur du Module évalué ; - lorsque tous les Modules sont renvoyés, requête auprès du Serveur pour s'assurer que la procédure s'est correctement terminée. Lors d'une Restauration, le déroulement du processus sera le suivant : - génération et envoi au Serveur des options choisies par l'utilisateur ; - réception des Outils d'analyse ; - lecture des paramètres actuels et renvoi des Outils d'analyse ; - réception des Pré-modules ; - Module par Module, lecture des paramètres actuels, renvoi au Serveur du Module valorisé, réception du Module à restaurer et restauration ; - signalisation de fin de tâche au Serveur et acquittement. Les fonctionnalités proposées à l'utilisateur sur le site Web pourront comprendre, de façon non limitative, à partir d'une page d'accueil : - les fonctions d'identification et d'enregistrement de l'utilisateur, qui peut donc, après avoir indiqué ses coordonnées personnelles, ouvrir un compte sur le site ; - l'accès aux Configurations déjà enregistrées dans le compte de l'utilisateur, sur lesquelles les manipulations possibles comprendront au moins : - la sauvegarde de la Configuration actuelle, - la restauration d'une Configuration sélectionnée, - la suppression d'une Configuration, - le partage d'une Configuration avec un ou plusieurs autres intemautes, - le changement de nom d'une Configuration, - l'envoi d'une Configuration vers une Communauté, dont les fonctionnalités sont décrites plus loin ; - les mêmes possibilités de manipulation au niveau d'un seul Paquet, seule la possibilité de renommer un Paquet étant exclue ; - la possibilité d'annuler la dernière restauration effectuée, et donc de rétablir la Configuration initiale ; - la constitution d'une Communauté de Configurations, au sein de laquelle l'utilisateur peut au moins : - restaurer sur son poste une Configuration de la Communauté, - se constituer un Panier de Configurations préférentielles, qui peuvent être restaurées sur son poste, - sauvegarder une Configuration de la Communauté vers son compte, - ajouter ou supprimer un partage avec un ou plusieurs autres intemautes de son choix ; - toutes les aides et explications nécessaires à l'emploi du procédé objet de l'invention, ainsi qu'à la création et la mise à jour des Configurations. Le procédé selon l'invention est illustré par les dessins annexés dans lesquels : La figure 1 donne l'architecture générale du procédé suivant l'invention ; La figure 2 est le schéma fonctionnel d'une procédure de Sauvegarde ; La figure 3 est le schéma fonctionnel d'une procédure de Restauration ; La figure 4 donne le principe de fonctionnement de l'Objet Utilisateur ; La figure 5 représente le diagramme d'états de l'Objet Utilisateur au cours d'une sauvegarde ; La figure 6 représente le même diagramme dans le cas de la restauration ; La figure 7 illustre le format général d'un objet sérialisé ; La figure 8 donne le format des requêtes adressées par l'AP au serveur ; La figure 9 indique le format des réponses aux requêtes retournées par le serveur. Sur la figure 1 sont représentés les principaux sous-ensembles formant l'architecture générale du procédé selon l'invention : la Base de Données 1 communique à travers l'Interface 2 avec le Serveur Web 3 et le Serveur Applicatif 4. Le Serveur Web 3 et le Serveur Applicatif 4 échange des informations avec l'Appliquette (AP) 5 téléchargée sur la plateforme, ici l'ordinateur de l'utilisateur. Le schéma fonctionnel de la figure 2 représente la circulation des Pré-modules et des Modules de configuration entre la Base de Données, le Serveur et l'Utilisateur au cours d'une procédure de Sauvegarde : les Pré-modules sont transmis à l'AP sur le poste de l'utilisateur, où s'opère le choix des Modules à sauvegarder ; les Pré-modules sélectionnés sont renvoyés au Serveur qui constitue le bloc des données des Modules à sauvegarder avant de les retourner à l'AP où sont intégrés aux Modules les paramètres de configuration actuels ; les Modules sont enfin adressés à nouveau au Serveur, qui effectue les opérations de reconversion nécessaires à la reconstitution des Paquets concernés, avant de replacer ceux-ci dans la Base de Données ; à chaque mouvement d'un Pré-module ou d'un Module, les données correspondantes sont sérialisées au départ et dé-sérialisées à l'arrivée. De façon similaire, est représenté sur le schéma fonctionnel de la figure 3 le traitement des Pré-modules et des Modules lors d'une procédure de Restauration : les Pré-modules sont extraits de la Base de Données et transmis à l'AP où s'opère la sélection ; les Pré-modules concernés sont retournés au Serveur, qui effectue les conversions nécessaires pour reformer le Paquet à restaurer avec les paramètres extraits de la Base de Données, avant de renvoyer ce Paquet à l'AP, qui procède à la restauration. La figure 4 illustre le fonctionnement de l'Objet Utilisateur sur le Serveur sous l'action des Unités d'exécution : à chaque fois que l'Objet Utilisateur 6 demande une opération d'entrée (lecture) ou de sortie (écriture) de données au port 7 correspondant à la socket d'entrée/sortie, le retour de l'acquittement de cette opération par le port est détecté par l'une des Unités d'exécution 8 en sommeil, qui entre alors en action pour donner à l'Objet Utilisateur l'ordre de poursuivre le traitement, et ainsi de suite jusqu'à l'achèvement de la procédure. Sur la diagramme d'états de la figure 5 sont représentés les états successifs de l'Objet Utilisateur lors d'une procédure de Sauvegarde : -l'état ES0 (Connexion) dure jusqu'à l'envoi des Outils d'analyse ; - l'état ES 1 (Analyse) qui suit se maintient jusqu'à l'envoi des Pré-modules ; - dans le cas où un choix de Modules est nécessaire, l'état ES1 prend fin avec l'envoi des Choix de Modules et laisse la place à un état intermédiaire ES l'jusqu'à l'envoi des Pré-modules ; - l'état suivant ES2 (Traitement) se termine lorsque le dernier Module a été traité et la procédure s'achève avec l'état ES3 (Fin). Lors d'une procédure de Restauration, les états successifs de l'Objet Utilisateur apparaissent sur la figure 6 : les états ERO (Connexion), ER1 (Analyse) et ER2 (Traitement) sont similaires aux états ESO, ES1 et ES2 respectivement dans le cas de la Sauvegarde ; l'état suivant ER3 (Envoi des Modules) se maintient jusqu'à la transmission du dernier Module, avant de laisser la place à l'état ER4 (Fin). La figure 7 représente le format général des objets sérialisés transmis entre le Serveur et l'AP. Chaque objet est formé successivement de : - un octet de début OD, - l'identifiant de la classe à laquelle appartient l'objet IC, - les données de l'objet, dont le format et la longueur dépendent de la classe, - un octet de fin OF. La figure 8 montre le format des requêtes adressées par l'AP au Serveur. Ce format comprend successivement : - l'en-tête HTTP ; - l'identifiant de l'utilisateur IU, crypté selon l'algorithme RSA et qui comporte lui-même quatre parties : l'identifiant de la clé à utiliser pour le décryptage IDC, la taille totale de la zone cryptée, l'identifiant de l'utilisateur lui-même IDU et le nombre d'itérations NBI ; - l'en-tête de requête ETR, qui comporte deux parties : le type TR (normal ou erreur) et la nature de la requête NR ; - les données nécessaires au traitement de la requête. Enfin la figure 9 donne le format de la réponse du Serveur à une requête, qui comprend : - l'en-tête HTTP ; - l'en-tête de réponse, dont le format est identique à celui de l'en-tête de requête ; - les données de la réponse. REVENDICATIONS 1. Procédé pour la sauvegarde et la restauration de la configuration d'une plateforme informatique par connexion sur un site Internet ou Intranet, ce procédé ne nécessitant aucune installation préalable sur la plateforme concernée d'un logiciel spécialisé dans ces tâches de sauvegarde ou de restauration, caractérisé en ce qu'il comprend une phase de sauvegarde comportant les phases opératoires suivantes : - la demande de sauvegarde de la plateforme sur un site serveur Internet ou Intranet, - l'acceptation de la demande par le serveur et la transmission par le serveur à la plateforme de données pour analyser la plateforme, - l'analyse interne de la plateforme à partir des données transmises par le serveur et la transmission au serveur des résultats de l'analyse, - la préparation par le serveur des données pour sauvegarder la configuration du poste et la transmission à la plateforme des données pour sauvegarder la configuration de la plateforme, - la sauvegarde par la plateforme des données de configuration de la plateforme et la transmission de ces données au serveur, - la conversion des données de configuration de la plateforme puis la sauvegarde par le serveur de ces données. 2. Procédé selon la revendication 1, caractérisé en ce qu'il comprend une phase de restauration des données de configuration sauvegardées par le site serveur sur la plateforme demandeur éventuellement distinct de la susdite plateforme, cette phase de restauration comprenant les étapes suivantes : la demande de restauration émise par la plateforme demandeur à destination du serveur, l'acceptation de la demande par le site serveur et la transmission par celui- ci à la plateforme demandeur, de données d'analyse, l'analyse interne de la plateforme à l'aide des données d'analyse et la transmission par la plateforme au serveur des résultats de l'analyse, la conversion par le serveur, en fonction de ces résultats, des données pour la restauration de la configuration de la plateforme et la transmission par le serveur de ces données à la plateforme, la restauration de la configuration sur la plateforme. 3. Procédé selon la revendication 1, caractérisé en ce qu'il comporte au moins les sous-ensembles suivants installés sur le site du serveur : - une Base de données, renfermant les configurations sauvegardées et les autres données nécessaires au fonctionnement de l'application ; - un Interface, assurant les liaisons entre les différents sous-ensembles ; - un Serveur Applicatif, qui pilote l'ensemble des opérations de sauvegarde et de restauration des configurations ; - un Serveur Web, gérant la connexion des utilisateurs et l'interface Utilisateur ; - une Appliquette, téléchargée sur la plateforme de l'utilisateur et réalisant les traitements internes d'acquisition ou de mise en place des paramètres de configuration. 4. Procédé selon l'une des revendications précédentes, caractérisé en ce que la configuration sauvegardée ou restaurée comprend la configuration du système d'exploitation utilisé par la plateforme et/ou la configuration des logiciels spécialisés installés sur cette plateforme. 5. Procédé selon la revendication 4, caractérisé en ce que les susdits logiciels spécialisés consistent en des Traitements de texte, des Tableurs, des Navigateurs Internet ou des Gestionnaires de courrier électronique. 6. Procédé selon la revendication 4, caractérisé en ce que, si l'on désigne par Module l'ensemble des paramètres d'un logiciel donné, les Modules d'une même famille de logiciels spécialisés et les Modules concernant les systèmes d'exploitation sont regroupés dans un Paquet affecté à cette famille, ce qui permet, grâce à une analyse préalable, de restaurer la configuration d'un logiciel sauvegardée à partir d'un autre logiciel de la même famille. 7. Procédé selon l'une des revendications précédentes, caractérisé en ce qu'une opération de sauvegarde préalable locale est effectuée préalablement à une opération de restauration, permettant ainsi d'annuler l'opération de restauration et de rétablir la configuration originale. 8. Procédé selon l'une des revendications 1 et 2, caractérisé en ce que toutes les informations circulant entre la plateforme utilisateur et le serveur sont codées dans un format sérialisé, de manière à pouvoir les transmettre à l'aide de protocoles standards. 9. Procédé selon l'une des revendications précédentes, caractérisé en ce qu'il comprend des facilités d'ajout, de suppression, de modification, de partage, et/ou de mise en communauté des configurations sauvegardées.