FR2964484A1

FR2964484A1 - Procede de recueil de donnees a caracteres evenementiel de formulaires electroniques

Info

Publication number: FR2964484A1
Application number: FR1003511A
Authority: FR
Inventors: Benoit Ferlin
Original assignee: BANQUE ACCORD
Current assignee: ONEY BANK, FR
Priority date: 2010-09-02
Filing date: 2010-09-02
Publication date: 2012-03-09
Anticipated expiration: 2030-09-02
Also published as: RU2640715C1; BR112013006365A8; FR2964484B1; WO2012028817A1; US20130227386A1; EP2612236A1; BR112013006365A2; RU2013114686A; CN103262049A; CN103262049B

Abstract

Procédé de gestion d'un formulaire électronique accessible sur un serveur d'application (2) via un terminal utilisateur (10) pourvu d'au moins un périphérique d'entrée, ce procédé comprenant les étapes suivantes : - dés le chargement du formulaire électronique par le terminal utilisateur (10), identification (11) des champs du formulaire électronique susceptibles d'être concernés par des interactions utilisateur ; - détection et mémorisation de données concernant tout évènement produit sur chacun des champs identifiés ; - déchargement des données mémorisées lors de la soumission du formulaire électronique; - analyse des données déchargées.

Description

PROCEDE DE RECEUIL DE DONNEES A CARACTERES EVENEMENTIEL DE FORMULAIRES ELECTRONIQUES La présente invention se rapporte au domaine technique des services en ligne et plus particulièrement à l'étude des interactions utilisateur avec les formulaires électroniques en ligne. Avec l'utilisation généralisée d'Internet et/ou d'Intranet, le nombre des services en ligne ne cesse de progresser : citons à titre d'exemple les services de e-commerce, e-banking, e-learning, e-gouvernement. De fait, de plus en plus d'entreprises - notamment dans le domaine bancaire - tendent à proposer leurs services de manière électronique au moyen d'applications en ligne. Ainsi les transactions bancaires et financières peuvent désormais être accomplies en ligne, à distance. Afin de répondre à des perspectives économiques et commerciales, ces services en ligne utilisent des ressources informatiques diverses allant du plus simple, tels qu'un courriel « contactez-nous » ou un formulaire électronique, au plus complexe, tels que des outils communicationnels interfaçables sur le Web 2.0 (messagerie instantanée ou « chat », étiquetage social, blog, site web dynamique de type « Wiki »). Dans ce contexte, le formulaire électronique est considéré comme l'un des principaux promoteurs des services en ligne. Le formulaire permet, en effet : une forte réactivité : la saisie des données peut être accélérée - par comparaison, par exemple, avec une application de courrier électronique - à l'aide de menus déroulants ou de cases à cocher ; l'obtention de données pré-formatées qui peuvent être automatiquement intégrées à une base de données ; l'assistance de l'internaute lors de la saisie des informations requises : données obligatoires (identifiant, mot de passe par exemple) ou facultatives (adresse, profession, âge, adresse électronique par exemple), procédure à suivre (identification, paiement, vérification, confirmation par exemple) ; B015 8001 FR - TQD

l'économie de la retranscription des informations utilisateur (à la différence notamment du Chat ou du courrier électronique, dans lesquels les informations utilisateur doivent être extraites et retranscrites, avec un risque d'erreur dans la retranscription); l'obtention d'informations pertinentes, par exemple, en amenant l'utilisateur à effectuer un choix parmi une liste prédéfinie à la convenance de l'administrateur du service en ligne. C'est pourquoi le formulaire électronique est devenu une ressource informatique capitale pour les services en ligne, qu'ils soient informatifs, 10 consultatifs ou transactionnels. Toutefois, les administrateurs des services en ligne peinent à concevoir des formulaires performants et conviviaux, n'ayant pas de retour critique de la part des utilisateurs : il serait nécessaire de faire remplir à ces derniers des formulaires de satisfaction, ce qui serait un cercle vicieux. 15 De sorte que la qualité de l'ergonomie des formulaires électroniques, qui est fondamentale pour l'acceptation par les internautes de la souscription de services en ligne, n'est généralement appréciée que de manière incomplète en raison de l'absence d'étude statistique sur la manière dont les internautes remplissent les formulaires. 20 Il va de soi que le comportement des internautes lors du remplissage d'un formulaire varie selon l'âge, le sexe, la catégorie socio-professionnelle, le type de terminal, le navigateur utilisé. Il n'est toutefois pas envisageable, pour des raisons non seulement commerciales mais également éthiques, de subordonner l'accès à un service en ligne nécessitant le remplissage d'un 25 formulaire à l'identification préalable d'une catégorie à laquelle appartiendrait l'internaute : par principe, tout internaute doit pouvoir remplir un formulaire pour accéder au service. Pourtant les réactions des internautes face aux formulaires sont diverses et complexes. Ainsi si l'organisation des champs à remplir est fondamentale, 30 on note que les logiques varient selon les individus. Cette logique peut d'ailleurs s'opposer aux intérêts du fournisseur du service. Ainsi, si pour certains fournisseurs de services l'âge de l'utilisateur est une donnée B015 B001 FR - TQD

fondamentale conditionnant la fourniture du service (citons à titre d'exemple les services réservés aux adultes et interdits aux enfants), la présence du champ « âge » en tête du formulaire peut d'emblée rebuter l'utilisateur qui se détournera du service.

De même, la méthodologie de saisie est fondamentale et il existe à ce jour peu de données sur la manière dont, statistiquement, les internautes saisissent les informations qui leur sont demandées. Un objectif de la présente invention est d'améliorer l'ergonomie des formulaires électroniques afin de faciliter l'accès des internautes à des 10 services en ligne conditionnés par la soumission de ces formulaires. A cette fin, l'invention se rapporte, selon un premier aspect, à un procédé de gestion d'un formulaire électronique accessible sur un serveur d'application via un terminal utilisateur pourvu d'au moins un périphérique d'entrée, ce procédé comprenant les étapes suivantes : 15 dès le chargement du formulaire électronique par le terminal utilisateur, identification des champs du formulaire électronique susceptibles d'être concernés par des interactions utilisateur ; détection et mémorisation de données concernant tout évènement produit sur chacun des champs identifiés ; 20 déchargement des données mémorisées lors de la soumission du formulaire électronique; analyse des données déchargées. L'invention se rapporte, selon un deuxième aspect, à un enregistreur d'évènements pour la gestion d'un formulaire électronique accessible sur 25 un serveur d'application via un terminal utilisateur pourvu d'au moins un périphérique d'entrée, cet enregistreur d'évènement étant configuré pour: dès le chargement du formulaire électronique par le terminal utilisateur, identifier les champs du formulaire électronique susceptibles d'être concernés par des interactions utilisateur ; 30 détecter et mémoriser des données concernant tout évènement produit sur chacun des champs identifiés ; 8015 8001 FR - TQD

décharger les données mémorisées lors de la soumission du formulaire électronique. L'invention se rapporte, selon un troisième aspect, à un produit programme d'ordinateur implémenté sur un support mémoire, susceptible d'être mis en oeuvre au sein d'une unité de traitement informatique et comprenant des instructions pour la mise en oeuvre du procédé résumé ci-dessus. D'autres caractéristiques et avantages de l'invention apparaîtront plus clairement et de manière concrète à la lecture de la description ci-après de modes de réalisation préférés, laquelle est faite en référence aux dessins annexés dans lesquels : la figure 1 illustre schématiquement une représentation fonctionnelle non limitative d'un mode de réalisation; la figure 2 illustre schématiquement une variante de réalisation. Sur la figure 1 est représenté un utilisateur 1 requérant, via un terminal 15 utilisateur 10, l'accès à un contenu et/ou à un service en ligne auprès d'un serveur d'application 2. Le terminal utilisateur 10 (un ordinateur, une tablette numérique, un Smartphone, un téléphone portable, ou plus généralement tout dispositif permettant à l'utilisateur 1 d'interagir avec un serveur distant) est, 20 notamment, pourvu de périphériques d'entrée et d'un moyen d'affichage (un écran). On entend, ici, par périphérique d'entrée tout dispositif permettant d'envoyer des instructions (saisie de texte, pointage par exemple) au terminal utilisateur 10. Un clavier, un écran tactile, un digicode, une manette, une souris, un trackball, un pavé tactile, une tablette graphique ou 25 toute combinaison de ces derniers sont des exemples de périphériques d'entrée du terminal utilisateur 10. Le terminal utilisateur 10 est pourvu, en outre, d'un navigateur Web (FireFox ®, Fennec ®, Opera ®, Opera Mobile ®, Internet Explorer®, Google Chrome® par exemple) ou tout autre moyen permettant de consulter 30 un site Web mis en ligne via le serveur d'application 2. Ce navigateur Web est agencé pour transmettre une requête d'accès à un service et/ou un B015 B001 FR - TQD

contenu mis en ligne, ainsi que pour afficher la réponse à cette requête transmise depuis le serveur d'application 2. La communication entre le terminal utilisateur 10 et le serveur d'application 2 est établie selon un protocole de navigation simultanément supporté (http, https, WAP par exemple). Le serveur d'application 2 permet l'accès à (ou héberge) au moins un site Web (ou un site WAP) comprenant un formulaire électronique. A titre d'exemple non-limitatif, le serveur d'application 2 propose un service en ligne tel qu'une demande de prêt bancaire en ligne, nécessitant le remplissage d'un formulaire électronique par un utilisateur souhaitant bénéficier de ce service. Dans ses interactions avec le contenu mis en ligne via le serveur d'application 2, l'utilisateur 1 transmet une requête 120 d'accès à un formulaire électronique auprès du serveur d'application 2. En réponse, le serveur d'application 2 retourne à l'utilisateur 1 le formulaire électronique requis 121 incluant un enregistreur d'évènements. L'enregistreur d'évènements est un produit programme d'ordinateur (c.à.d. un ensemble de lignes de code représentant des instructions) joint au formulaire électronique requis par l'utilisateur 1. Selon une forme particulière de réalisation, l'enregistreur d'évènements est intégré dans le code source du formulaire électronique. Il est à noter que l'enregistreur d'évènements est toutefois indépendant du formulaire électronique requis par l'utilisateur 1, et peut être intégré à tout autre formulaire électronique.

L'enregistreur d'évènements vise à permettre la reconstitution dans le temps de la manière dont le formulaire électronique requis est rempli par l'utilisateur 1. A cet égard, on distingue trois phases : une phase d'initialisation permettant d'inventorier tous les champs du formulaire électronique susceptibles d'être concernés par des interactions utilisateur ; B015 B001 FR - TQD

une phase d'exécution au cours de laquelle l'enregistreur d'évènements détecte et mémorise tout évènement produit sur chacun des champs inventoriés du formulaire électronique ; une phase de déchargement permettant de joindre les données mémorisées au formulaire électronique lors de sa soumission par l'utilisateur. On entend, ici, par « champ » d'un formulaire électronique tout élément constitutif du formulaire électronique, ou plus généralement tout composant d'interface graphique compris dans le formulaire électronique (icône, bouton poussoir, case à cocher, bouton radio, menu de commande, menu contextuel, onglet, barre de défilement, zone de texte, bulle d'aide, boite de dialogue, fenêtre flottante, lien hypertexte par exemple). Par ailleurs, une « interaction utilisateur » désigne, ici, toute instruction (sélection, saisie, pointage par exemple) déclenchée par l'utilisateur 1 via un périphérique d'entrée du terminal utilisateur 10 ou par un produit programme d'ordinateur (un robot par exemple). Dès le chargement, par l'utilisateur 1, du formulaire électronique 121 incluant un enregistreur d'évènements, ce dernier, dans une phase d'initialisation, - effectue une exploration du formulaire électronique (étape 11 de la figure 1) afin d'y identifier tous les champs dont les valeurs peuvent être modifiées par l'utilisateur 1 (une zone de saisie, un menu déroulant, une case à cocher, un bouton radio, un bouton, un lien vers un autre document par exemple), et mémorise (étape 12 de la figure 1) les propriétés des champs identifiés ; i.e. pour chaque champ identifié, mémorise le nom, le type (bouton, checkbox, file, hidden, image, password, radio, reset, select-one, select-multiple, submit, texte, textarea par exemple), et la valeur initiale (vide, coché par exemple).

Ainsi, l'enregistreur d'évènements construit un référentiel détaillé caractérisant l'ensemble des champs présents dans le formulaire électronique chargé par l'utilisateur 1. B015 B001 FR - TQD

Dans une forme particulière de réalisation, l'enregistreur d'évènements parcourt le formulaire électronique pour en extraire la structure (c'est-à-dire, l'ensemble des champs présents dans le formulaire électronique) pour la mémoriser dans un tableau Structure[] dont la forme est la suivante : 11-1111111MI." 1k- Numéro du formulaire j Numéro d'apparition du champ dans la structure Idx Index du champ au format « i/j » type Type du champ : button A checkbox B file C hidden D image E password F radio G reset H select-one I select-multiple J submit K text L textarea M fenêtre X (au sens navigateur) non reconnu Z val_ini Valeur initiale du champ name Nom du champ au sens HTML id identifiant du champ au sens HTML Chaque champ du formulaire électronique est donc indexé par un numéro du formulaire électronique et son numéro d'apparition dans la structure de ce formulaire électronique. Durant la phase d'exécution, un auditeur (notamment, « listener » en anglais) est associé à chaque champ répertorié du formulaire électronique, à l'effet de détecter tout évènement produit sur ce champ, et déclencher, par conséquent, la mémorisation de cet évènement. A titre d'exemples non-limitatifs d'évènements, on cite : keydown Une touche est appuyée keypress Une touche est « pressée » keyup Une touche est relâchée focus Le champ attrape le focus Blur Le champ perd le focus select Un item d'une liste est sélectionné paste L'événement « coller » se produit sur le champ Cut L'événement « couper » se produit sur le champ B015 B001 FR - TQD copy L'événement « copier » se produit sur le champ change Le contenu d'un champ a changé de valeur click Le champ a été cliqué dblclick Le champ a été double cliqué contextmenu Un menu contextuel a été déclenché sur le champ mousedown Un bouton de la souris est appuyé sur le champ mouseup Un bouton de la souris est relâché sur le champ resize L'utilisateur redimensionne la fenêtre du formulaire électronique mouseover La souris arrive au dessus du champ mouseout la souris quitte le champ En particulier, l'évènement «focus» se produit lorsqu'un champ répertorié est sélectionné. Dès que ce champ perd le «focus», se produit l'évènement «blur». Ces deux évènements permettent, en particulier, de savoir que l'utilisateur 1 effectue un basculement («swap») depuis le formulaire électronique vers un autre document. Les deux évènements « focus » et « blur » renseignent, entre autres, sur l'attention de l'utilisateur 1 envers le formulaire électronique. Les auditeurs programmés pour détecter les évènements « focus » et « blur » sont implémentés sur l'objet « window » du DOM (Document Object Model) permettant de déclencher une fonction de mémorisation associée à l'objet « window ». L'événement « resize » résulte du redimensionnement de la fenêtre du formulaire électronique à l'aide de l'une des fonctions suivantes du navigateur : « poignée » (généralement accessible dans le coin inférieur droit du navigateur), « plein écran », « niveau inférieur » ou encore « agrandir » (ces trois dernières se trouvant généralement dans le coin supérieur droit du navigateur). La gestion du temps est effectuée au moyen d'une variable alimentée avec l'heure courante, permettant de calculer le temps (en millisecondes) écoulé entre deux évènements consécutifs et/ou la durée d'un évènement (également en millisecondes). Dans une mise en oeuvre particulière, tout évènement capté est mémorisé dans un tableau Trace[], comprenant les propriétés suivantes : B015 B001 FR - TQD Numéro de séquence de l'événement dh Nombre de millisecondes écoulées depuis le précédent événement ctrl Indice de l'objet sur lequel se produit l'événement keycode Keycode ou charcode sur un événement de type touche selTxt Texte sélectionné dans un champ de type « text ou « textarea » selDeb Offset dans le champ du début du texte sélectionné selFin Offset dans le champ de la fin du texte sélectionné new_va_vide Indicateur permettant de savoir que la nouvelle valeur du champ est vide ». special_key Permet de savoir qu'une touche spéciale a été appuyée lors de l'événement evenement Code de l'événement survenu new_val Nouvelle valeur du champ mouse Dernière position connue de la souris avant que ne se produise l'événement De préférence, les données mémorisées relatives à un évènement produit et capté par un auditeur comprennent : l'évènement, le champ dans lequel s'est produit l'évènement, le temps écoulé (en millisecondes) depuis l'évènement précédent, l'instruction transmise depuis le périphérique d'entrée au terminal utilisateur (c.à.d. la valeur de la touche du clavier appuyée, ou le bouton de la souris appuyé), le contenu du texte/item sélectionné, un indice de début et/ou de fin du texte sélectionné, la nouvelle valeur du champ, une modification de la valeur d'un champ, l'état des touches spéciales telles que « CTL », « ALT », «SHIFT » par exemple.

Par ailleurs, lorsqu'un évènement donné est généré par : un clic de souris, alors celui-ci est identifié (clic gauche, clic milieu, clic droit) ; l'appui sur une touche (évènement keydown - keypress et keyup), alors le « keycode » de la touche (pour les évènements keydown et keyup) ou le « charcode » (pour l'évènement keypress) est identifié. On mémorise, en outre, l'appui sur une ou plusieurs touches spéciales, à savoir les touches « Ctrl », « Alt », ou « Shift » par exemple, lorsque l'événement se produit dans la propriété « special_key ». La propriété « ctrl », par exemple, est donc associée au champ sur lequel se produit l'événement. Si l'événement concerne la fenêtre elle-même du formulaire électronique, on mémorise, alors, pour cette fenêtre (i=0, j=0, selon le tableau Structure[]) l'évènement «focus» ou «blur». Si l'événement concerne un type de champ inconnu (dont l'origine peut être un bogue du 8015 B001 FR - TQD

navigateur), on attribue à la propriété « ctrl » la valeur « none » afin que l'événement soit dépilé du tableau des évènements Trace[]. A titre d'exemple, si l'événement concerne un élément de type « text », « textarea » ou « password » et que du texte est sélectionné, les informations suivantes sont mémorisées : - selTxt :Texte sélectionné ; - selDeb : Offset dans l'élément du début de la sélection ; - selFin : Offset dans l'élément de la fin de la sélection. Si l'événement concerne un élément de type « select-one » ou « select- multiple », on alimente la propriété « new_val » qui va formater dans une chaine les éléments sélectionnés de la manière suivante Caractère '[' Pour chaque item sélectionné : Numéro d'ordre de l'item, Le texte de l'item dans lequel on remplace le caractère « I » par « &pipe » et le caractère « / » par « &slashe », Le caractère « / » Caractère « ] ». Si l'événement concerne un champ de type « radio » ou « checkbox », on alimente à « 1 » ou « 0 » la propriété « new_val » (1 : coché ou sélectionné, 0 l'inverse). Enfin, pour tous les autres champs pour lesquels la propriété « value » est définie (text, textarea, password), on alimente la propriété « new_val » avec la valeur de l'élément en remplaçant le caractère « ~ » par « &pipe ».

Notamment, si la nouvelle valeur est vide alors que la précédente était différente du vide, on met la propriété « new_val_vide » à 1. On alimente enfin la propriété « ex_val » du champ avec la nouvelle valeur. B015 8001 FR - TQD

Dans un mode de réalisation, on mémorise dans la propriété « événement » un caractère alphabétique associé à l'événement qui s'est déclenché en respectant une certaine nomenclature, comme par exemple la suivante : keydown A keyup B keypress C focus D blur E select F paste G cut H copy change J click K dblclick L contextmenu M mousedown N mouseup O resize P mouseover Q mouseout R Autre Z Il est à noter que les données mémorisées portent sur la manière dont l'utilisateur 1 interagit avec le formulaire électronique et non sur le contenu de ses interactions (c.à.d. le texte saisi). La soumission du formulaire électronique (étape 122 de la figure 1) par l'utilisateur 1 au serveur d'application 2, déclenche la phase de déchargement permettant de joindre les données mémorisées au formulaire électronique. En particulier, la phase de déchargement permet : - de formater les données mémorisées pendant la phase d'initialisation et d'exécution en une trace technique ; - de joindre, dans une zone créée dynamiquement, la trace technique au formulaire électronique à soumettre. Pour cela, tout d'abord, afin d'éviter tout problème d'interprétation de la trace technique avec certains caractères « spéciaux » (du type « < », « ? » par exemple), ceux-ci sont, de préférence, remplacés en respectant une certaine nomenclature telle que la suivante : B015 B001 FR - TQD < %3c _ %3d > %3e Et %26 ? %3f La trace technique est ensuite formatée pour comprendre un entête, une structure et la trace d'évènements déjà mémorisée. L'entête, délimité par une balise de type <entete> et </entete>, enrichit l'information comprise dans la trace d'évènements en comprenant, à titre 5 d'exemple non exhaustif, les éléments du tableau suivant. version Version du recorder (par exemple, 1.0) host Nom du host sur lequel a tourné l'enregistreur d'évènements (par exemple www.oney.fr) pathname Chemin de la page sur le site (par exemple, /ouverture/carte.php) search Chaîne des paramètres éventuels de l'url (par exemple ?mode=souscription) Date_Deb Date - heure de chargement du formulaire Date_Fin Date - heure au moment de l'exécution de la fonction appCodeName Nom de code du navigateur (par exemple, Mozilla) appMinorVersion Type de version mineure du navigateur appName Nom complet du navigateur (par exemple Netscape) appVersion Version du navigateur (par exemple 5.0 (Windows; U; Windows NT 6.1) cookieEnabled Booléen indiquant que le navigateur accepte ou non les cookies cpuClass Type du processeur language Langage du navigateur (par exemple fr) onLine Booléen indiquant que le navigateur est connecté à Internet ou non platform Nom du système d'exploitation (par exemple Win32) systemLanguage Code langue du système d'exploitation userAgent Concaténation de plusieurs informations du navigateur (par exemple, Mozilla/5.0 (Windows; U) userLanguage Code langue du navigateur availHeight Nombre de pixels utiles de la résolution verticale de l'écran availWidth Nombre de pixels utiles de la résolution horizontale de l'écran colorDepth Profondeur des couleurs en nombre de bits height Résolution verticale réelle de l'écran width Résolution horizontale réelle de l'écran innerHeight Hauteur en pixel de la zone de contenu visible du navigateur innerWidth Largeur en pixel de la zone de contenu visible du navigateur XOffset Position de la page dans le navigateur (ascenseur) dans le sens horizontal YOffset Position de la page dans le navigateur (ascenseur) dans le sens vertical On fournit ci-après un exemple d'entête d'une trace technique (le caractère « ~ » est remplacé par « &pipe » dans chaque propriété contenant du texte) : B015 8001 FR - TQD 13 <entete>1.01 www.pcaba.fr l /test- cagnotte/ lab_coordonnees. php 1 1126996502199911269965154646 I Mozi lla I ; SP3; I Microsoft Internet Explorerl4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; .NET CLR 1.1.4322) I true 1 x861 undefined I true I Win32 I fr I Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; .NET CLR 1.1.4322)1fr19961128013211024112801881112291010</entete> La structure d'une trace technique, délimitée par des balises de type <structure>, et </structure>, comprend un descriptif des champs répertoriés du formulaire électronique comme indiqué ci-après : Idx Index du champ, composé du numéro du formulaire puis de « / » puis du numéro du champ dans le formulaire narre Nom du champ au sens HTML id identifiant du champ au sens HTML Type du champ : type button A checkbox B file C hidden D image E password F radio G reset H select-one I select-multiple J submit K text L textarea M fenêtre X (au sens navigateur) non reconnu Z val_ini `` Valeur initiale du champ val_fin * Valeur finale du champ On fournit ci-après un exemple illustratif d'une structure d'une trace technique (le caractère « I » est remplacé par « &pipe » dans chaque propriété contenant du texte) : <structure>0/01 window 1 1 X 1 1 10/1 1 eventid I I D I I suivant 10/21 civilite I civilite I I I [0: ] I [1:Monsieur] 1 0 / 3 1 prenom 1 prenom I L I I Benoit 10/41 nom 'nom I L I I Ferlin 10/5 I nomJeuneFille 15 I nom-jeune-fille l L I 1 10/6 I dateNaissanceJour 1 I I I [0:-- ] I [22:221' 0/71dateNaissanceMois I III [0:--] I [6:06110/8 I dateNaissanceAnnee 1 111 [0:----] 1 [30:1963] 10/91 paysNaissance I pays- naissance I I 1 [1: France] I [1: France] 10/10 1 departementNaissance I departementnaissance 111 [0:Choisissez] 1 [69:Morbihan] 10/11 1 villeNaissance 1 ville- 20 naissance I L 1 I GUER I O/ 121 numeroRue I numero-rue I L 111 RUE NATIONALE 1 0 / 1 3 1 residenceBatiment I residence- batimentlL1110/141etageletage1LI 110/151codePostallcode- postal I L 115900010/ 1 6 1 lieuDit I lieuDit I L I 1 1 0 / 1 7 1 commune I commune l L 1 'LILLE' 0/181 teleph B015 8001 FR - TQD 14 oneFixe I telephone-fixe I L I 1 10/19 I telephoneMobile I telephone- mobile I L I 1 email I adresse-email I L I I bferlin@test.fr I</structure> 0/0 window X (window) 0/1 eventid D (hidden) suivant 0/2 civilite I (select-one) [0: ] [1:Monsieur] 0/3 prenom L (text) Benoit 0/4 nom L (text) Ferlin 0/5 nomJeuneFille L (text) 0/6 dateNaissanceJour I (select-one) [0:--] [22:22] 0/7 dateNaissanceMois I (select-one) [0:--] [6:06] 0/8 dateNaissanceAnnee I (select-one) [0:----] [30:1963] 0/9 paysNaissance I (select-one) [1:France] [1:France] 0/10 departementNaissance I (select-one) [0:Choisissez] [69:Morbihan] 0/11 villeNaissance L (text) GUER 0/12 numeroRue L (text) 1 RUE NATIONALE 0/13 residenceBatiment L (text) 0/14 etage L (text) 0/15 codePostal L (text) 59000 0/16 lieuDit L (text) 0/17 commune L (text) LILLE 0/18 telephoneFixe L (text) 0/19 telephoneMobile L (text) 0/20 email L (text) bferlin@test.fr La trace d'évènements comprend l'ensemble des événements survenus lors de la phase d'exécution sur le formulaire et qui peut être délimitée avec les 5 balises « <trace> » et « </trace> ». La trace est composée des éléments suivants séparés chacun par le caractère « » Dh Nombre de millisecondes écoulées depuis le précédent événement Ctrl Il s'agit de l'identifiant du champ, à savoir « l'Idx de la structure » Code événement evenement keydown A keyup B keypress C focus D blur E select F paste G cut H copy I change J click K dblclick L contextmenu M B015 B001 FR - TQD mousedown N mouseup 0 Autre Z keycode * Keycode ou charcode sur un événement de type touche selTxt * Texte sélectionné dans un champ de type « text » ou « textarea » selDeb Offset dans le champ du début du texte sélectionné selFin Offset dans le champ de la fin du texte sélectionné new_val * Nouvelle valeur du champ new_val_vide Indicateur permettant de savoir que la nouvelle valeur du champ est « vide ». spe_key Permet de savoir qu'une touche spéciale était appuyée lors de l'événement Pour des raisons de confidentialité, la trace d'évènements est, de préférence, cryptée. Notamment, le contenu de la structure de la trace technique peut être aussi crypté. Dans un mode de réalisation non-limitatif du cryptage de la trace d'événement, des clefs de cryptage sont calculées par l'enregistreur d'évènements d'une manière aléatoire et stockés dans la variable système « window.name ». Avantageusement, cette méthode de cryptage permet de conserver le même procédé de cryptage pour tous les formulaires électroniques chargés (c.à.d. ouverts) sur un même navigateur.

Pour cela, dans un mode préféré de réalisation, trois matrices de cryptage sont définies à partir de trois zones distinctes d'un périphérique d'entré du terminal utilisateur (un clavier) : - matrice A (mA) : les touches F1 à F12 ; - matrice B (mB) : les touches 1 à 0 du clavier principal et les mêmes du clavier numérique ; matrice C (mC) : les touches A à Z. Les touches numérotées selon un tableau de cryptage des touches permettent d'obtenir des matrices de cryptage composées des touches relatives à chaque zone.

Chaque matrice est initialisée avec ses numéros de touches correspondantes, par exemple : - mA : chiffres de 1 à 1l ; - m B :chiffres de 17 à 26 ; et B015 B001 FR - TQD - mC : chiffres de 31 à 40 + chiffres de 45 à 54 + chiffres de 59 à 64. Pour chaque matrice ainsi constituée, un grand nombre (par exemple 1000) de permutations deux à deux des éléments de chaque matrice est effectué. Ces matrices sont ensuite sauvegardées dans la variable « window.name ».

L'exemple suivant illustre le format de cette variable (les chiffres sont utilisés ici à des seules fins d'illustration) : [mA = new Array (2,12,8,1,6,3,10,9,7,5,4,11); mB = new Array (19,20,22,24,17,21,23,25,26,18); mC = new Array (48,60,64,31,39,47,45,50,63,54,40,46,49,62,35,36,38,53,61,59,37,32,51,33, 52,34);] Les matrices de cryptage mA, mB, et mC sont générées dès le chargement de l'enregistreur d'évènements. Si, lors d'un chargement ultérieur de l'enregistreur d'évènements, la présence des matrices est détectée dans la variable « window.name », la chaîne est retravaillée pour effacer les crochets ouvrants et fermants et une simple évaluation de la chaîne permet de charger les matrices en gardant les mêmes permutations. Afin de constituer un tableau de touches mélangées en respectant ces blocs, un tableau nommé tcp[] indexé de 0 à 105 reprend les matrices mA, 20 mBetmC: var tcp = new Array(); for (i = 0; i < 105; i++) { tcp[i] = i; if ((i > 0) && (i < 13)) tcp[i] = mA[i-1 ]; 25 if ((i > 16) && (i < 27)) tcp[i] = mB[i-17]; if ((i > 94) && (i < 105)) tcp[i] = mB[i-95]; if ((i > 30) && (i < 41)) tcp[i] = mC[i-31]; if ((i > 44) && (i < 55)) tcp[i] = mC[i-35]; if ((i > 58) && (i < 64)) tcp[i] = mC[i-39]; 30 } II est à noter que lors de l'appui sur une touche, trois évènements se produisent : - keydown : la touche est enfoncée, et le keycode de la touche est 35 intercepté ; B015 B001 FR - TQD

- keypress : la touche est appuyée, et le charcode de la touche est intercepté ; keyup : la touche est relâchée, et le keycode de la touche est intercepté. 11 convient, en particulier, de conserver une cohérence entre les valeurs de « keycode -charcode » et la valeur des caractères saisis, permettant de détecter, par exemple, que l'utilisateur 1 a corrigé son nom en inversant deux caractères d'une précédente saisie. On fournit ci-après un exemple illustrant le procédé de cryptage dans lequel deux touches, par exemple 53 (L) et 64 (N) selon un tableau de cryptage des touches, on été inversées lors de la création des matrices de cryptage : Les deux tableaux suivant, respectivement de correspondance entre un élément et son numéro de touche et la correspondance entre un numéro de touche et son élément, sont utilisés par le procédé de cryptage.

Le tableau de correspondance entre un élément et son numéro de touche peut se présenter ainsi : kd Correspondance entre un keyCode et un n° de touche kd[76]=53 kc Correspondance entre un charcode et un n° de touche kc[108]=53 kcm Correspondance entre un charcode « en majuscule » et un n° kcm[76]=53 de touche car Correspondance entre un caractère et son n° de touche car['l']=53 - car['L]=53 Le tableau de correspondance entre un numéro de touche et son élément peut se présenter ainsi : tkd Correspondance entre un n° de touche et un keycode tkd[64]=78 tkc Correspondance entre un n ° de touche et un charcode tkc[64]=110 tkcm Correspondance entre un n° de touche et un charcode « en tkcm[64] = 78 majuscule » tc Correspondance entre un n° de touche et un caractère en tc[64]='n' minuscule tcm Correspondance entre un n° de touche et un caractère en tcm[64]='N' majuscule 8015 8001 FR - TQD

Le cryptage d'un keycode à la suite des événements keydown et keyup, comprend les étapes suivantes : récupération, depuis le tableau kd, du numéro de la touche associé au keycode à crypter: dans cet exemple kd[76]=53 ; lecture de la permutation de la touche en question dans le tableau tcp : dans cet exemple, tcp[53]=64 ; recherche, dans le tableau tkd, du keycode associé au numéro de touche obtenu: dans cet exemple, tkd[64]=78. Le cryptage d'un charcode à la suite de l'événement keypress comprend les étapes suivantes : récupération, depuis le tableau kc, du numéro de touche associé au charcode à crypter (si cet élément n'est pas défini, on récupère alors ce numéro de touche dans le tableau kcm): dans cet exemple kcm[76]=53 - lecture de la permutation de la touche en question dans le tableau tcp : dans cet exemple, tcp[53]=64 ; recherche, dans le tableau tkc, du charcode associé au numéro de touche obtenu: dans cet exemple, tkd[64]=78. Une comparaison de la mise en majuscule d'un caractère avec le caractère lui-même permet de savoir si un caractère est en minuscule ou en majuscule (à l'exception des caractères spéciaux tels que, par exemple, « à », « ù » ou « ç »). A titre d'exemple, selon les exemples précités, car['L']= 53, alors que tcp[53]=64 correspond dans tcm à 'N' c.à.d. tcm[64]='N'.

Bien entendu, d'autres méthodes de cryptage de la trace d'évènement peuvent être utilisées. Dans un mode de réalisation et pour des raisons de sécurité, la trace technique formatée est jointe d'une manière cachée (un élément de type « hidden ») au formulaire électronique à soumettre par l'utilisateur 1 au serveur d'application 2.

B015 B001 FR - TQD

Dans un autre mode de réalisation, même si l'utilisateur 1 annule la soumission ou abandonne le formulaire électronique (retour arrière depuis le navigateur, fermeture de la page du formulaire électronique par exemple), la trace technique est envoyée au serveur d'application 2 (étape 122 de la figure 1) ou au serveur d'analyse 3 (étape 130 de la figure 1). Dans ce cas, la trace technique permet de repérer les zones du formulaire où s'est arrêté l'utilisateur 1. Ceci permet, par exemple, d'identifier les champs qui représentent un obstacle aux utilisateurs pour achever leurs transactions.

Dans un mode de réalisation, le serveur d'application 2 est pourvu d'un plugin 21 programmé pour extraire la trace technique du formulaire soumis et la transférer à un serveur d'analyse 3. Ce transfert vise, en particulier, à ne pas perturber le fonctionnement du serveur d'application 2 qui est dédié au traitement du contenu du formulaire soumis.

De ce fait, la gestion de la trace technique est réservée à un serveur d'analyse 3 afin de ne pas pénaliser le temps de traitement, par le serveur d'application 2, du contenu du formulaire soumis par l'utilisateur 1. En variante, la trace technique est directement transmise (étape 130 de la figure 1) au serveur d'analyse 3.

Le serveur d'analyse 3 est configuré pour : - vérifier la cohérence de la trace technique (étape 31 de la figure 1) : la structure de la trace, la présence des informations de l'entête par exemple analyser la trace d'évènements comprises dans la trace technique 25 (étape 32 de la figure 1); et - mémoriser (étape 33 de la figure 1) l'analyse de la trace technique dans une base de données 30. L'étape d'analyse 32 d'une trace d'évènements comprend notamment plusieurs étapes telles que : 30 - la normalisation de la trace d'évènements en y supprimant, par exemple, des évènements superflus dépendant du navigateur utilisé B015 B001 FR - TQD

par l'utilisateur 1 (par exemple, le fait de passer d'un champ à un autre génère sous Internet Explorer un événement de type « la fenêtre gagne le focus »); la distinction de chaînes d'évènements successifs traduisant des interactions utilisateur, par exemple la chaine d'évènements « mousedown - mouseup- contextmenu-paste » correspondant à l'action « coller dans une zone à l'aide du menu contextuel » ; - l'évaluation de la dynamique de frappe (frappe normale : keydownkeypress-keyup, frappe rapide : temps entre keyup et keydown successifs, frappe répétitive : durée du temps du keypress). La distinction de chaines d'événements successifs traduisant des interactions utilisateur peut être faite, selon un mode particulier de réalisation, en analysant la trace par une technique dite des « expressions régulières » : on associe une lettre de l'alphabet à chaque événement de la trace et on forme une chaîne de caractères constituée de tous les événements, les uns à la suite des autres. Chaque expression régulière est recherchée dans la chaîne des événements, et lorsqu'elle est trouvée, on associe alors un « flag d'analyse » permettant de savoir que les événements élémentaires correspondent à une action particulière.

A ce niveau d'analyse, la trace d'événements est décomposée en évènements compréhensibles, autrement dit en interactions utilisateur : une touche à été appuyée, un champ a subi une action « coller », ou une case à été coché par exemple. Avantageusement, la traduction de tous les évènements compris dans la trace d'évènements en interactions utilisateur permet de reconstituer dans le temps la manière dont le formulaire électronique a été rempli par l'internaute 1. Plus précisément, cette étape permet de reconstituer, par un traçage des interactions utilisateur (copier-coller, saisie de texte, sélection d'item, permutation de page par exemple) en tenant, notamment, compte de l'aspect temporel (durée/ordre des interactions utilisateur) ou du scénario suivant lequel le formulaire électronique est rempli. L'évaluation de la dynamique de frappe peut être effectuée en calculant, pour chaque évènement de la trace, la distance « Levenshtein » (ou selon B015 B001 FR - TQD

toute autre mesure de similarité entre deux chaines d'évènements) issue des changements de valeur de la zone sur laquelle s'est produit l'évènement. La distance « Levenshtein » quantifie le coût algorithmique permettant de passer d'un mot à un autre.

Cette étape d'évaluation de la dynamique de frappe permet d'identifier la manière dont les champs du formulaire électronique ont été remplis. En effet, on distingue trois types de frappes : frappe normale : Le champ est modifié suite aux événements « keydown + keypress + keyup » ; frappe rapide : cet événement se produit lorsque l'utilisateur 1 tape rapidement sur le clavier ; la séquence se caractérise par le fait que l'événement « keyup » de la 1 ére touche appuyée ne s'est pas encore produit alors même que s'est produit l'événement « keydown » de la touche suivante. Cette analyse tend à démontrer que l'utilisateur qui a effectué la saisie à l'habitude de saisir cette information au clavier ; frappe répétitive : cet événement se produit lorsque l'utilisateur appuie longtemps sur une touche et déclenche une alimentation répétitive du champ avec le même caractère.

Par ailleurs, l'analyse de la trace technique permet aussi d'identifier les champs qui ont été modifiés à l'aide de « copier/coller », de la technique « d'auto-complétion » offerte par certains navigateurs, ou à l'aide de robots par exemple. Cette étape d'analyse permet la reconstitution de la manière dont le 25 formulaire électronique à été rempli par l'utilisateur 1. Par exemple, l'utilisateur 1 : a cliqué sur le champ « nom », l'a rempli à l'aide des touches du clavier en effectuant X saisies normales, Y saisies rapides, Z corrections ; 30 a sauté du champ « nom » vers le champ « adresse » à l'aide de la touche de tabulation ; B015 B001 FR - TQD

a permuté vers une fenêtre autre que celle du formulaire électronique (la fenêtre du formulaire électronique a perdu le « focus », et un évènement « blur » a été subséquemment produit); a activé de nouveau le champ « adresse » du formulaire électronique (évènement « focus » produit sur le champ « adresse ») ; a collé un contenu dans le champ « adresse » à l'aide du menu contextuel (la chaîne des évènements suivants s'est produite sur le champ « adresse » : « mousedown - mouseup- contextmenu-paste »). En fonction des données récoltées lors de cette analyse, une décision humaine peut être prise (par exemple par un groupe 4 de personnes tel qu'une direction marketing) pour modifier le formulaire, par exemple si les statistiques démontrent des difficultés pour certains utilisateurs à remplir correctement ou suffisamment rapidement le formulaire. A cet effet, une personne autorisée à accéder au serveur d'analyse 3 peut consulter (étape 41 de la figure 1), par exemple quotidiennement, les analyses des traces techniques enregistrées dans la base de données 30 du serveur d'analyse 3 et définir (étape 42 de la figure 1), en conséquence, un plan d'action. Selon un autre mode de réalisation illustré sur la figure 2, le serveur d'application 2 peut requérir (étape 231 de la figure 2) l'analyse des traces techniques qui lui ont été transférées du serveur d'analyse 3 (étape 232 de la figure 2) pour la suite du traitement du formulaire soumis (par exemple, pour accepter ou refuser une transaction bancaire dans le cas d'un formulaire e-banking). Dans ce mode de réalisation, le serveur d'analyse 3 est configuré pour 25 appliquer lui-même des règles de traitement du formulaire (étape 34 de la figure 2). Le système et le procédé qui viennent d'être décrits ci-dessus permettent notamment, sur la base d'une analyse statistique comportementale (anonyme) des interactions utilisateur, de modifier l'architecture des 30 formulaires afin d'en améliorer l'ergonomie sans pour autant qu'il soit nécessaire de modifier les terminaux clients, tant en termes matériels que logiciels. B015 8001 FR - TQD

Les caractéristiques comportementales de l'utilisateur comprennent notamment la manière dont l'utilisateur utilise un périphérique d'entrée (le clavier et/ou la souris par exemple). Il est également envisageable de mettre en ligne plusieurs types de formulaires selon les performances supposées des utilisateurs. Les différents types de formulaires peuvent ainsi comporter des fonctionnalités différentes (notamment d'aide au remplissage, par exemple au moyen de menus déroulants au lieu de fenêtre de saisie libre). Il va de soi, par ailleurs, que des variantes de réalisation sont 10 'envisageables. Ainsi, le serveur d'application 2 peut assurer la fonction de serveur d'analyse 3. B015 8001 FR - TQD

Claims

REVENDICATIONS1. Procédé de gestion d'un formulaire électronique accessible sur un serveur d'application (2) via un terminal utilisateur (10) pourvu d'au moins un périphérique d'entrée, ce procédé caractérisé en ce qu'il comprend les étapes suivantes : dés le chargement du formulaire électronique par le terminal utilisateur (10), identification (11) des champs du formulaire électronique susceptibles d'être concernés par des interactions utilisateur ; détection et mémorisation de données concernant tout évènement produit sur chacun des champs identifiés ; déchargement des données mémorisées lors de la soumission du formulaire électronique; analyse des données déchargées.
2. Procédé selon la revendication 1, caractérisé en ce que l'étape d'identification comprend une étape de mémorisation des propriétés des champs identifiés.
3. Procédé selon l'une quelconque des revendications 1 ou 2, caractérisé en ce qu'il comprend en outre une étape d'association d'un auditeur à chaque champ identifié du formulaire électronique pour détecter tout évènement produit sur ce champ.
4. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que les évènements à détecter sont choisis parmi les évènements suivants : keydown, keypress, keyup, focus, blur, select, paste, cut, copy, change, click, dbclick, contextmenu, mousedown, mouseup, resize, mouseover, mouseout.
5. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que les données mémorisées concernant un évènement produit sur un champ identifié sont sélectionnées parmi l'évènement produit, le champ sur lequel s'est produit l'évènement, le temps écoulé depuis l'évènement précédent, l'instruction transmise depuis le périphérique d'entrée au terminal utilisateur, la nouvelle valeur du B015 B001 FR - TQD champ, une modification de la valeur d'un champ, l'état de touches spéciales du périphérique d'entrée.
6. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que l'étape de déchargement des données mémorisées comprend une opération de formatage des données mémorisées et une opération de jonction des données formatées au formulaire électronique.
7. Procédé selon la revendication 6, caractérisé en ce les données mémorisés sont formatées pour comprendre un entête, une structure et une trace des évènements produits.
8. Procédé selon la revendication 7, caractérisé en ce que la trace des évènements produits est cryptée.
9. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que l'étape d'analyse comprend une étape de distinction de chaînes d'évènements successifs traduisant des interactions utilisateur.
10. Enregistreur d'évènements pour gérer un formulaire électronique accessible sur un serveur d'application (2) via un terminal utilisateur (10) pourvu d'au moins un périphérique d'entrée, cet enregistreur d'évènement étant caractérisé en ce qu'il est configuré pour: dés le chargement du formulaire électronique par le terminal utilisateur (10), identifier (11) les champs du formulaire électronique susceptibles d'être concernés par des interactions utilisateur ; détecter et mémoriser des données concernant tout évènement produit sur chacun des champs identifiés ; décharger les données mémorisées lors de la soumission du formulaire électronique.
11. Enregistreur d'évènements selon la revendication 10, caractérisé en ce qu'il est joint au formulaire électronique requis par le terminal utilisateur (10), en réponse à une requête d'accès (120) à ce formulaire électronique, émise depuis le terminal utilisateur (10).
12. Enregistreur d'évènements selon la revendication 10, caractérisé en ce que le déchargement des données mémorisées est effectué à destination d'un serveur d'analyse (3). B015 8001 FR - TQD
13. Enregistreur d'évènements selon la revendication 12, caractérisé en ce que le serveur d'analyse (3) est configuré pour distinguer dans les données mémorisées au moins une chaine d'évènements successifs traduisant une interaction utilisateur.
14. Produit programme d'ordinateur implémenté sur un support mémoire, susceptible d'être mis en oeuvre au sein d'une unité de traitement informatique et comprenant des instructions pour la mise en oeuvre d'un procédé selon l'une des revendications 1 à 9. B015 B001 FR - TQD