Brevet FR2848689A1 — publié le 20040618

L'invention concerne un procédé d'acquisition informatique d'une donnée fournie par un utilisateur. La capacité d'échange d'informations avec une machine est souvent déterminante pour l'acceptation de cette machine par son utilisateur. Avec 5 l'informatique, des interfaces homme-machine très élaborées ont été mises au point. Par exemple, les échanges d'informations peuvent se faire par l'intermédiaire d'un écran affichant des pages adaptées en permanence non seulement en fonction des réponses de l'utilisateur déjà saisies, mais aussi en fonction de l'identité de l'utilisateur ou d'un groupe d'utilisateurs auquel il appartient. On dit alors 10 que l'interface est personnalisée. La personnalisation des interfaces permet d'adapter les images, les questions, ou les informations affichées sur la page en fonction des données relatives à l'utilisateur, par exemple en fonction de ses droits d'accès, de l'historique de ses utilisations de la machine, de son âge, de sa catégorie socioprofessionnelle, 15 etc. La personnalisation des interfaces est donc une activité de large portée, concernant aussi bien les machines-outils, les appareils "grand public", que des applications fonctionnant au moyen de réseaux comme Intranet ou Internet. Dans le cas de ces dernières applications, le nombre d'utilisateurs, appelés "clients", peut être très élevé. En outre les interfaces personnalisées peuvent être 20 amenées à évoluer régulièrement en nombre ou en contenu. Considérons par exemple le cas d'une plate-forme de transaction numérique, sur Intemet, destinée à mettre en relation commerciale des utilisateurs susceptibles de souscrire une assurance automobile et un ou plusieurs assureurs. Si l'utilisateur est un distributeur de voitures souhaitant assurer un de ses clients, 25 l'écran devra faire apparaître le logo de ce distributeur et les seules offres d'assurance des assureurs avec lesquels ce distributeur a passé un contrat de partenariat. Si l'utilisateur est un particulier, l'interface devra lui permettre de visualiser les offres de tous les assureurs raccordés à la plate-forme, sans affichage d'aucun 30 logo de distributeur. Que l'utilisateur soit un distributeur ou un particulier, l'interface devra évoluer par exemple en cas d'ajout ou de suppression d'un assureur ou de modification des accords passés par le distributeur avec les assureurs. Selon la technique actuelle, un développeur conçoit, avant toute utilisation de la machine, toutes les pages susceptibles d'être affichées sur l'écran. La structure des pages est alors sensiblement figée. Par exemple, le nombre des composants d'une page, c'est-à-dire des zones d'image, des zones de 5 saisie, des zones de libellé, etc., et leurs positions sur cette page doivent être prédéfinis. Si, par exemple, une page affichée doit présenter une, deux ou trois colonnes selon que l'utilisateur a préalablement déclaré avoir 0, 1, ou 2 enfants, respectivement, il est nécessaire de concevoir avant toute utilisation de la machine 10 trois pages différentes correspondant à ces trois situations. Il en est de même si un critère d'acceptation d'une réponse ou un libellé doit être personnalisé. La séquence des pages successivement affichées à l'écran est déterminée par les réponses apportées successivement par l'utilisateur aux questions qui lui sont posées. Les pages affichables sont donc classiquement classées dans une structure arborescente dont le tronc est constitué de la première page affichée, les branches principales par l'ensemble des deuxièmes pages susceptibles d'être affichées après la première page; les branches secondaires par l'ensemble des troisièmes pages susceptibles d'être affichées après l'affichage d'une deuxième 20 page, etc. Une séquence de pages successivement affichées lors d'une session d'utilisation correspond ainsi à un trajet sur cette structure arborescente, depuis le tronc jusqu'aux branches terminales. Si la structure arborescente est fortement ramifiée, le développement d'une interface personnalisée implique un développement long et coteux d'un très 25 grand nombre de pages. Par ailleurs, classiquement, chaque page est associée à une base de règles de navigation qui, en fonction des saisies effectuées par l'utilisateur, permettent de déterminer l'identification de la page suivante à afficher. Si une question est supprimée d'une page, toutes les bases de règles de 30 navigation qui utilisent la valeur que cette question permettait d'acquérir doivent être modifiées. De même, si une nouvelle saisie permet d'acquérir une valeur utile dans plusieurs bases de règles de navigation, toutes ces bases doivent être modifiées. Dans la technique antérieure, l'ajout, la modification, ou la suppression de questions peut donc conduire à des modifications de nombreuses bases de règles de navigation. Enfin, classiquement, pour que les données saisies soient transférées et mises en mémoire, le développeur affecte à chaque zone de saisie de chaque page un emplacement de stockage. Le lien entre zones de saisie et emplacements de stockage est prédéterminé. Lors de la modification d'une page, par exemple 10 pour pouvoir y saisir la réponse à une nouvelle question, le développeur doit donc non seulement modifier la page o doit être insérée la zone de saisie de cette réponse et la mémoire afin d'y réserver un emplacement de stockage pour cette réponse, mais aussi établir et stocker le lien entre cet emplacement de stockage et cette zone de saisie. Selon la technique antérieure, le développement et la maintenance de dispositifs d'acquisition de données pourvus d'interfaces personnalisées sont donc complexes et coteux. Le but de la présente invention et de fournir un dispositif d'acquisition de données dont la maintenance est simplifiée et qui est donc plus évolutif. On atteint ce but au moyen d'un procédé d'acquisition informatique d'une donnée fournie par un utilisateur, comportant les étapes suivantes: a) sélection, en fonction de règles de navigation, et de données dites " données métier' préalablement acquises, d'une page de formulaire comportant au moins une zone de saisie de ladite donnée, 25 b) affichage de ladite page de formulaire sélectionnée, c) saisie, par ledit utilisateur, d'au moins ladite donnée au moyen de ladite zone de saisie, d) validation de ladite saisie par ledit utilisateur, e) stockage de ladite donnée saisie, ce procédé étant remarquable en ce qu'il comporte en outre une étape intermédiaire entre les étapes a) et b), pendant laquelle on détermine, en fonction de règles de navigation et, au moins, desdites données métier, une configuration de ladite page de formulaire sélectionnée puis on applique ladite configuration à ladite page de formulaire sélectionnée. Comme on le verra plus en détail dans la suite de la description, la configuration des pages sélectionnées permet de réduire le nombre de pages à 5 stocker et à maintenir. La maintenance et l'évolution du dispositif d'acquisition en sont simplifiées. Selon d'autres caractéristiques avantageuses de ce procédé, l'application de ladite configuration comporte au moins une duplication d'au moins un composant de ladite page de formulaire; - l'application de ladite configuration comporte au moins une affectation à un jeu de paramètres de ladite page de formulaire, d'un jeu de valeurs propre à ladite configuration; - des jeux de valeurs correspondant à une pluralité de configurations de ladite page de formulaire sont regroupés dans un même base de configurations; - on regroupe des règles de navigation propres à une pluralité de pages de formulaire dans une même base de règles de navigation; - on applique ladite configuration en temps réel avant d'afficher ladite page de formulaire; - on détermine, pour au moins une zone de saisie de ladite page de formulaire 20 configurée, une clé comportant toutes les informations nécessaires pour identifier un emplacement de stockage d'une donnée saisie dans ladite zone de saisie, puis on affecte ladite clé à ladite zone de saisie; - on code ladite clé dans un langage autodescriptif; - on code ladite clé dans un langage du type pointé; - on stocke ladite donnée saisie dans un objet logiciel temporaire, dit " objet métier ". L'invention concerne également un dispositif pour la mise en oeuvre du procédé suivant l'invention, comportant - des moyens d'interfaçage adaptés pour sélectionner et afficher une page 30 de formulaire comportant au moins une zone de saisie de ladite donnée, - des moyens de stockage de ladite donnée saisie au moyen de ladite page de formulaire, - un parseur adapté pour recevoir au moins ladite donnée saisie depuis lesdits moyens d'interfaçage, identifier un emplacement de stockage dans 5 lesdits moyens de stockage et stocker ladite donnée saisie audit emplacement, et - des moyens de supervision, ce dispositif étant remarquable en ce que lesdits moyens d'interfaçage comportent des moyens d'adaptation aptes à déterminer, préalablement audit affichage, une 10 configuration de ladite page de formulaire sélectionnée en fonction de règles de navigation et au moins de données métier préalablement acquises, puis à appliquer ladite configuration à ladite page de formulaire sélectionnée. Selon d'autres caractéristiques avantageuses de ce dispositif, - lesdits moyens d'adaptation sont aptes à déterminer, pour au moins une zone de 15 saisie de ladite page de formulaire configurée, une clé comportant toutes les informations nécessaires pour identifier un emplacement de stockage d'une donnée saisie dans ladite zone de saisie, puis à affecter ladite clé à ladite zone de saisie; - ladite page de formulaire configurée est de type JSP, ASP ou PHP. D'autres caractéristiques et avantages de la présente invention apparaîtront à la lecture de la description qui va suivre et à l'examen du dessin annexé dans lequel: - la figure 1 représente une vue schématique d'un dispositif selon l'invention, dans le mode de réalisation préféré de l'invention; - la figure 2 représente une vue schématique de moyens d'interfaçage du dispositif selon l'invention, dans le mode de réalisation préféré de l'invention. Les blocs fonctionnels des architectures représentées sur les figures 1 et 2 ne correspondent pas nécessairement à des modules logiciels. La programmation d'un dispositif d'acquisition peut en effet conduire l'homme de l'art à attribuer à des 30 modules logiciels des fonctions de plusieurs blocs fonctionnels ou à faire exécuter la fonction d'un bloc fonctionnel par plusieurs modules logiciels. Le dispositif d'acquisition de données 1 selon l'invention représenté sur la figure 1 est destiné à la saisie de données en provenance d'un utilisateur U, par l'intermédiaire de moyens d'interfaçage 3, et à leur stockage dans des moyens de stockage 5 ou dans une base de contexte 6, selon que les données sont relatives aux besoins de l'utilisateur ou au fonctionnement du dispositif 1, respectivement. On appelle respectivement ces données "données métier" et "données de contexte". Les données de contexte sont les données techniques utiles pour le fonctionnement du dispositif selon l'invention, mais qui ne concernent pas directement les besoins exprimés par l'utilisateur. Par "acquisition", on entend l'ensemble des étapes d'un processus consistant à poser une pluralité de questions à un utilisateur, à saisir ses réponses, et à les mémoriser. Les moyens d'interfaçage 3, décrits plus en détail dans la suite de la description (figure 2), opèrent un dialogue avec l'utilisateur U puis envoient à un 15 analyseur syntaxique ou "parseur" 7 (de l'anglais "parser") les données saisies par l'utilisateur U. Le parseur 7 est destiné à déterminer un emplacement de stockage dans les moyens de stockage 5 et à y stocker les données saisies. Le dispositif d'acquisition 1 comporte également des moyens de 20 supervision 9 destinés à coordonner la mise en oeuvre des moyens d'interfaçage 3 et du parseur 7. Les moyens de stockage 5, encore appelés "objet métier', peuvent être une base de données permanente ou, de préférence, un objet temporaire dont la durée de vie correspond à celle de la session d'utilisation. L'objet métier 5 est de préférence structuré hiérarchiquement à la manière d'une base de données relationnelle. L'objet métier 5 comporte classiquement une pluralité de sous-objets, correspondant chacune à une entité logique, par exemple des sous-objets "conducteurs", "véhicules" ou "sinistres". Chaque sous-objet est constitué d'enregistrements correspondant chacun à une instance de l'entité 30 logique, chaque enregistrement étant identifié par un identifiant. Par exemple, l'enregistrement du sous-objet "conducteurs" identifié par "DUPONT" contient les informations relatives au conducteur appelé "DUPONT". Tous les enregistrements d'un sous-objet comportent les mêmes champs, par exemple pour le sous-objet "conducteurs", des champs "NOM", "PRENOM", "VILLE". Dans les champs d'un enregistrement sont entrées les valeurs correspondant à des attributs d'une occurrence particulière de l'entité logique, par 5 exemple "DUPONT", "PIERRE", "PARIS", respectivement. Les valeurs d'un ou plusieurs champs servent d'identifiant de l'enregistrement. Certains champs d'un ou plusieurs enregistrements "fils" peuvent contenir des identifiants d'un enregistrement "père" d'un sous-objet. Par exemple, chaque enregistrement du sous-objet "sinistres" peut contenir un champ identifiant un 10 véhicule du sous-objet "véhicules" et chaque enregistrement du sous-objet "véhicules" peut contenir un champ identifiant un conducteur du sous- objet "conducteurs". Les enregistrements "fils" "pointés" héritent ainsi des valeurs des champs de l'enregistrement "père". On évite ainsi de devoir dupliquer inutilement les valeurs des attributs d'un enregistrement "père" dans chacun des 15 enregistrements "fils". Comme représenté sur la figure 2, les moyens d'interfaçage 3 comportent des moyens de saisie 10 et des moyens de sélection 12 et d'adaptation 14 d'une page de formulaire avant son affichage par des moyens d'affichage 18. Les moyens de saisie 10 sont adaptés à la nature de l'information à saisir 20 et à l'environnement dans lequel est placé l'utilisateur U. Ces moyens 10 comportent par exemple un clavier, un lecteur de codes à barres ou de cartes à puce, une souris ou des moyens d'identification biométrique. Les moyens de sélection 12, ou "navigateur", sont destinés à sélectionner dans une base de pages 20, une page de formulaire 21 à afficher. Cette sélection 25 s'effectue en fonction de données stockées dans la base de contexte 6 et dans l'objet métier 5, selon des règles de navigation stockées dans une base de règles 24. Les règles de navigation relatives à une pluralité de pages 21 sont de préférence regroupées dans une base de règles 24 centralisée. En cas de 30 modification, d'ajout ou de suppression de questions dans une page de formulaire, il n'est donc pas nécessaire de modifier plusieurs bases de règles. Avantageusement, la maintenance en est simplifiée. Les pages 21 sont par exemple de type JSP, ASP ou PHP, selon une terminologie couramment utilisée. Une page destinée à être affichée comporte classiquement des composants de présentation, comme des images ou des zones de libellés, et des 5 composants de formulaire utilisés pour la saisie des données, appelés globalement "zones de saisie". Par zone de saisie, on entend un composant quelconque de la page permettant à l'utilisateur de saisir une donnée, par exemple une zone de texte, une case à cocher, un menu déroulant ou un bouton. A chaque zone de saisie peuvent être associées des règles locales telles que des "javascripts" (selon 10 la terminologie anglo-saxonne couramment utilisée) pour les pages JSP, propres à cette zone et permettant par exemple de filtrer les saisies et éventuellement d'informer l'utilisateur. Ces règles locales peuvent concerner par exemple un seuil maximal à ne pas dépasser, une condition d'appartenance à une liste prédéfinie, etc. Quand une page comporte au moins un composant de formulaire, elle est appelée "page de formulaire". Chacun des composants d'une page est associé à des paramètres de configuration, par exemple à des paramètres permettant de déterminer son style graphique, par exemple sa couleur, ses dimensions ou la police de ses caractères, 20 sa position dans la page, les règles locales auxquelles il est soumis, et des valeurs utilisées par ces règles, par exemple des valeurs de seuil. On appelle "jeu de paramètres" d'une page l'ensemble des paramètres de ses composants. Le "design" ou "configuration" d'une page dépend du jeu de valeurs de 25 configuration affecté à son jeu de paramètres. Les jeux de valeurs correspondant à une pluralité de configurations d'une page sont de préférence regroupés dans une même base de configurations 26. L'ajout d'un nouveau jeu de valeurs, la suppression ou la modification d'un jeu existant sont ainsi avantageusement simplifiés, le développeur pouvant facilement 30 retrouver l'emplacement o sont stockés tous les jeux de valeurs de configuration d'une page. De préférence, une console d'administration, non représentée, facilite la modification, par le développeur, des jeux de valeurs des pages, et leurs affectations "par défaut". Comme on le verra plus en détail dans la suite de la description, les 5 moyens d'adaptation 14 permettent préalablement à son affichage, de modifier la configuration d'une page 21, et de créer et d'affecter une clé d'identification à chacune de ses zones de saisie, transformant la page 21 en une page adaptée 27. De préférence, la clé d'une zone de saisie comporte toutes les informations nécessaires pour identifier l'emplacement de stockage, dans l'objet 10 métier 5, de la donnée saisie au moyen de la zone de saisie. De préférence encore, les clés sont codées dans un langage autodescriptif, par exemple un langage de type pointé. Par exemple pour identifier l'emplacement de stockage de la donnée saisie relative au nom d'un blessé N0 3, d'un sinistre N0 2 d'un véhicule N1 d'un 15 conducteur N0 1 2 3, la clé pourra être "conducteurs. 1 23.véhicules. I.sinistres.2.blessés.3. blessé-nom", "123", "1", "2" et "3" étant respectivement des identifiants d'enregistrements dans des sous-objets hiérarchisés "conducteurs", "véhicules", "sinistres" et "blessés", respectivement. Une page adaptée 27 est prête à être affichée à l'écran sous la forme 20 d'une page affichée 28. Le fonctionnement du dispositif selon l'invention est le suivant. Dans une première étape de démarrage, l'utilisateur U s'identifie et/ou identifie le bloc applicatif avec lequel il souhaite travailler. Par exemple dans le cas d'un dispositif d'acquisition de données relatives à des assurances, l'utilisateur 25 s'identifie, ou est automatiquement identifié, comme étant un utilisateur particulier. Il choisit alors un bloc applicatif parmi trois blocs correspondant respectivement à l'assurance d'un véhicule, à l'assurance d'une maison, ou à une assurance santé. Le parseur 7 mémorise dans la base de contexte 6 l'identification de l'utilisateur et celle d'une première page à afficher correspondant au bloc applicatif 30 sélectionné et à l'identification de l'utilisateur. De préférence, le dispositif d'acquisition 1 "réserve" et organise conformément au bloc applicatif sélectionné des emplacements de stockage pour y stocker les données saisies par l'utilisateur, c'est-à-dire les données métier. On dit que le dispositif d'acquisition "instancie" un objet métier 5. Le dispositif d'acquisition 1 affiche alors la première page. La première page peut se présenter sous sa configuration "par défaut", 5 c'est-à-dire telle que déterminée lors de sa conception. Le dispositif d'acquisition 1 peut également personnaliser la première page, préalablement à son affichage, par exemple en fonction de données acquises lors de la connexion de l'utilisateur. A chaque zone de saisie de cette première page est associée une clé d'identification de l'emplacement dans l'objet métier 5 o doit être stockée la valeur 10 saisie. Après que l'utilisateur U a terminé d'entrer des données dans une page affichée 28, c'est-à-dire initialement dans la première page, et que ces données ont été stockées, le processus d'acquisition se poursuit selon les étapes suivantes: 1) Sélection par le dispositif selon l'invention, dans la base de pages 20, 15 de la page de formulaire 21 à afficher en remplacement de la page en cours d'affichage 28. La sélection dépend des règles de navigation de la page affichée 28, de données métier préalablement acquises et, si nécessaire, de données de contexte. 2) Adaptation, par le dispositif selon l'invention, de la page à afficher 21, 20 c'est-à-dire en particulier configuration de la page 21 d'une part, et détermination et affectation des clés aux composants de cette page d'autre part; 3) Affichage, par le dispositif selon l'invention, de la page adaptée 27; 4) Saisie par l'utilisateur U de données au moyen des zones de saisie de 25 la page affichée 28; 5) Validation des saisies par l'utilisateur U; 6) Stockage par le dispositif selon l'invention, dans l'objet métier 5, des données saisies. A l'étape 1) le navigateur 12 détermine les identifiants de la page 21 à 30 afficher et de la configuration à lui appliquer. Pour cela, il met en oeuvre des règles de navigation propres à la page affichée 28 en fonction des données métier déjà saisies par l'utilisateur U et/ou des données de contexte. il Par exemple, les questions posées dans la page 21 à afficher et/ou le nombre d'occurrences de ces questions (voir ci-après) peuvent être déterminés en fonction des données saisies au moyen de la page 28. Le navigateur 12 transmet alors aux moyens d'adaptation 14 les identifiants ainsi déterminés. A l'étape 2, particulière à la présente invention, les moyens d'adaptation 14 affectent au jeu de paramètres de la page à afficher 21 le jeu de valeurs correspondant à la configuration que cette page doit adopter. Les composants d'une page 21 peuvent donc être configurés 10 dynamiquement. Avantageusement, le nombre de pages stockées dans la base de pages 20 en est donc réduit et la maintenance simplifiée. Le regroupement d'une pluralité de configurations d'une même page, voire d'une pluralité de pages, dans une même base de configuration 26 facilite encore la maintenance en évitant au développeur des recherches laborieuses. Des composants de la page 21 peuvent être regroupés dans des sousensembles duplicables appelés "sets dynamiques". Par exemple, un set dynamique "passager' pourrait regrouper toutes les zones de saisie correspondant aux questions à poser systématiquement pour chacun des passagers d'un véhicule accidenté: nom, prénom, etc. Un paramètre d'un composant permet le cas échéant de préciser l'identifiant du set auquel il appartient. Outre les valeurs que doivent prendre les paramètres des composants de la page 21, la configuration à appliquer à la page 21 peut préciser que les composants d'un set doivent être dupliqués, et indiquer le nombre d'occurrences. Les moyens d'adaptation 14 dupliquent alors autant que 25 nécessaire ces composants et les nomment. Au moyen d'un algorithme d'adaptation, les moyens d'adaptation 14 modifient alors l'aspect graphique de la page 21 de manière que les composants dupliqués s'y insèrent harmonieusement. Les règles d'adaptation pour l'insertion des éléments dupliqués dépendent de la page à afficher et sont déterminées par le 30 concepteur de la page lors de sa conception. Par exemple, une page 21 utilisée pour la saisie des données d'un sinistre automobile pourrait avoir n configurations possibles, en fonction du nombre de passagers dans le véhicule au moment du sinistre. Dans une configuration donnée, la page 27 comporterait, par exemple, autant de colonnes identiques qu'il y a de passagers. Ainsi, la base de configurations 26 comporterait au moins n jeux de paramètres correspondant à chacune des n configurations. Si au moyen de la page 5 affichée 28, l'utilisateur U précisait qu'il y avait, par exemple, trois passagers, ce nombre, enregistré dans l'objet métier 5, serait utilisé par les moyens d'adaptation 14 pour déterminer laquelle de ces n configurations il doit appliquer à la page 21, en l'occurrence la troisième. Les moyens d'adaptation 14 détermineraient alors la largeur des trois colonnes à prévoir dans la page adaptée 27, la nature et la 10 position de chacun des composants à insérer dans chaque colonne, leur identification, etc. Le nombre de pages à stocker dans la base de pages 20 est avantageusement fortement réduit par cette possibilité de dupliquer des composants lors de l'adaptation d'une page. En outre, la maintenance du dispositif 15 d'acquisition 1 selon l'invention en est facilitée. Par exemple pour ajouter une zone de saisie du numéro de sécurité sociale pour chacun des passagers, il suffit d'ajouter dans la page 21 une zone de saisie adaptée et de préciser qu'elle appartient au set dynamique "passager". Une page stockée dans la base de pages 20 est de préférence affichable 20 sans adaptation particulière de sa configuration. De préférence encore, la configuration de la page 21 telle que stockée dans la base de pages 20 est la configuration la plus fréquemment utilisée. Avantageusement, l'adaptation de la page 21 en est ainsi fréquemment accélérée. A chaque zone de saisie d'une page 21 est associé un emplacement de 25 stockage de l'objet métier 5. Lors de la déclinaison d'une zone de saisie, les moyens d'adaptation 14 réservent autant d'emplacements de stockage qu'il y a d'occurrences de la zone de saisie. En fonction des données métier déjà stockées dans l'objet métier 5, les moyens d'adaptation 14 génèrent alors, pour chaque zone de saisie dupliquée, une clé d'identification du chemin d'accès à l'emplacement de 30 stockage de la donnée saisie dans cette zone de saisie. La clé d'identification ainsi déterminée est associée à la zone de saisie. Par exemple, si une zone de saisie a été dupliquée de manière à permettre la saisie des noms des 2 passagers d'un sinistre no 1, les moyens d'adaptation 14 extrairont de l'objet métier 5 l'identifiant "1" du sinistre et généreront pour les deux zones de saisie des clés appropriées, à l'image de la structure hiérarchisée de l'objet métier 5. Par exemple, si les enregistrements du sous-objet "passagers" pointent vers des enregistrements du sous objet "sinistres", les clés des deux zones 5 de saisies pourraient être "sinistres. 1. passagers. i.nom" et "sinistres. 1. passagers.2.nom". Avantageusement à la réception d'une donnée saisie, le parseur 7 peut ainsi identifier l'emplacement de stockage de cette donnée sans connaître la structure de l'objet métier 5 ni celle de la page affichée 28. Comme cela apparaît 10 clairement à présent, la modification de l'interfaçage avec l'utilisateur U ne nécessite aucune modification ni du navigateur 12, ni des moyens d'adaptation 14, ni du parseur 7. Seules doivent être éventuellement modifiées les bases de configuration 26, de règles de navigation 24, de pages 20, et l'objet métier 5. Après sélection et adaptation de la page 21, le dispositif d'acquisition 15 efface la page en cours d'affichage 28 et affiche la page adaptée 27 (étape 3)). L'utilisateur peut alors procéder à la saisie des données (étape 4)). L'utilisateur U peut être guidé au moyen des règles "javascripts" localespropres à chaque zone de saisie qu'il utilise. Après remplissage de l'ensemble des zones de saisie de la page affichée 28, il valide ses saisies (étape 5), A l'étape 6), pour chaque donnée saisie, le parseur 7 décode la clé d'identification correspondante, en déduit un emplacement dans l'objet métier 5 et y stocke la donnée saisie. Avantageusement, le parseur 7 est donc utilisable quelle que soit la structure de l'objet métier 5. En cas de modification de la structure d'une page et, 25 en conséquence de l'objet métier 5, aucune modification du parseur 7 n'est donc nécessaire. La succession des étapes 1) à 6) se poursuit jusqu'à la fin de la session. Les données métier sont alors disponibles pour tout autre dispositif par exemple pour des ordinateurs de sociétés d'assurances souhaitant fournir à l'utilisateur un 30 devis en ligne, ou pour la mise en oeuvre de machines de chaînes de production. Bien entendu, la présente invention n'est pas limitée au mode de réalisation décrit et représenté, fourni à titre d'exemple illustratif et non limitatif. En particulier, les données saisies peuvent représenter des entités physiques ou des commandes de procédés industriels. REVENDICATIONS 1. Procédé d'acquisition informatique d'une donnée fournie par un utilisateur, comportant les étapes suivantes: a) sélection, en fonction de règles de navigation et de données dites 5 " données métier" préalablement acquises, d'une page de formulaire (21) comportant au moins une zone de saisie de ladite donnée, b) affichage de ladite page de formulaire sélectionnée, c) saisie, par ledit utilisateur, d'au moins ladite donnée au moyen de ladite zone de saisie, d) validation de ladite saisie par ledit utilisateur, e) stockage de ladite donnée saisie, caractérisé en ce qu'il comporte en outre une étape intermédiaire entre les étapes a) et b), pendant laquelle on détermine, en fonction de règles de navigation et, au moins, desdites données métier, une configuration de ladite 15 page de formulaire (21) sélectionnée puis on applique ladite configuration à ladite page de formulaire (21) sélectionnée. 2. Procédé selon la revendication 1, caractérisé en ce que l'application de ladite configuration comporte au moins une duplication d'au moins un composant de ladite page de formulaire (21). 3. Procédé selon l'une quelconque des revendications 1 et 2, caractérisé en ce que l'application de ladite configuration comporte au moins une affectation à un jeu de paramètres de ladite page de formulaire (21), d'un jeu de valeurs propre à ladite configuration. 4. Procédé selon l'une quelconque des revendications précédentes, caractérisé en 25 ce que des jeux de valeurs correspondant à une pluralité de configurations de ladite page de formulaire (21) sont regroupés dans un même base de configurations (26). 5. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce qu'on regroupe des règles de navigation propres à une pluralité de pages de 30 formulaire (21) dans une même base de règles de navigation (24). 6. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce qu'on applique ladite configuration en temps réel avant d'afficher ladite page de formulaire (21). 7. Procédé selon l'une quelconque des revendications précédentes, caractérisé en 5 ce qu'on détermine, pour au moins une zone de saisie de ladite page de formulaire configurée, une clé comportant toutes les informations nécessaires pour identifier un emplacement de stockage d'une donnée saisie dans ladite zone de saisie, puis on affecte ladite clé à ladite zone de saisie. 8. Procédé selon la revendication 7, caractérisé en ce qu'on code ladite clé dans 10 un langage autodescriptif. 9. Procédé selon la revendication 8, caractérisé en ce qu'on code ladite clé dans un langage du type pointé. 1O.Procédé selon l'une quelconque des revendications 7 à 9, caractérisé en ce qu'on stocke ladite donnée saisie dans un objet logiciel temporaire, dit " objet 15 métier " (5). 1 1.Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que ladite page de formulaire (21,27,28) est de type JSP, ASP ou PHP. 12.Dispositif pour la mise en oeuvre du procédé conformément à l'une quelconque des revendications 1 à 11, comportant - des moyens d'interfaçage (3) adaptés pour sélectionner et afficher une page de formulaire comportant au moins une zone de saisie de ladite donnée, - des moyens de stockage (5) de ladite donnée saisie au moyen de ladite page de formulaire (28), - un parseur (7) adapté pour recevoir au moins ladite donnée saisie depuis lesdits moyens d'interfaçage (3), identifier un emplacement de stockage dans lesdits moyens de stockage (5) et stocker ladite donnée saisie audit emplacement, et - des moyens de supervision (9), caractérisé en ce que lesdits moyens d'interfaçage comportent des moyens d'adaptation (14) aptes à déterminer, préalablement audit affichage, une configuration de ladite page de formulaire sélectionnée (21) en fonction de règles de navigation et, au moins, de données métier préalablement acquises, 5 puis à appliquer ladite configuration à ladite page de formulaire sélectionnée (21). 13.Dispositif selon la revendication 12, caractérisé en ce que lesdits moyens d'adaptation (9) sont aptes à déterminer, pour au moins une zone de saisie de ladite page de formulaire configurée (21), une clé comportant toutes les 10 informations nécessaires pour identifier un emplacement de stockage d'une donnée saisie dans ladite zone de saisie, puis à affecter ladite clé à ladite zone de saisie.