FR 3110269 A1 20211119 FR 2004781 A 20200514 Dans un procédé d’analyse de l’interaction d’un utilisateur avec une application informatique comportant un module serveur s’exécutant sur un serveur d’application (1) et un navigateur Internet s’exécutant sur un terminal (3, 4, 5) à disposition de l’utilisateur pour afficher un document, le module serveur et le navigateur est en communication par un réseau numérique (2). Le navigateur capte au moins un changement de la structure du document affiché dans le navigateur. On construit un arbre de contexte (AC 0 , AC 2 , AC 3 ) lié au document juste avant le changement et on transmet l’arbre de contexte à un serveur d’analyse (6) associé à une datation du changement sur une échelle temporelle, l’arbre de contexte (AC 0 , AC 2 , AC 3 ) caractérisant au moins une partie de la géométrie du document. On construit l’arbre de contexte (AC 0 , AC 2 , AC 3 ) sous la forme d’un arbre de zones, chaque zone étant caractérisée au moins par une position (x l , y l ) et une taille (w, h) dans un espace d’affichage (Za) du document, le procédé comprenant en outre une analyse de la collection d’arbres de contexte (AC 0 , AC 2 , AC 3 ). Figure pour l’abrégé : Fig. 1 Procédé et système d’analyse de l’interaction d’un utilisateur avec une application informatique L’invention concerne un procédé d’analyse de l’interaction d’un utilisateur avec une application informatique, en particulier dans un mode client serveur lorsque le client est exécuté par un navigateur Internet. Elle concerne également un système mettant en œuvre un tel procédé. Les concepteurs d’applications informatiques ont besoin d’avoir un retour sur le fonctionnement des applications afin de déterminer la manière dont les utilisateurs interagissent avec les applications et d’en déduire des pistes d’améliorations et d’optimisation. Dans le cas d’une application autonome, il n’est pas difficile d’ajouter des observateurs pour récolter des informations, les synthétiser et les restituer ensuite. Dans le domaine d’Internet, un serveur fournit des informations d’un site qui sont reçues par un ordinateur client distant, lequel exécute un navigateur qui permet d’afficher les informations sous forme de pages. La codification des informations est effectuée selon le format HTML, qui continue d’évoluer, notamment avec la version 5 du format. Dans les premières versions de la norme, le navigateur fait une requête au serveur par l’intermédiaire d’une adresse URL, pour « Uniform Resource Locator », qui codifie la localisation de la page demandée. Le code reçu est analysé et transformé en une structure arborescente d’objets qui modélise le document à afficher par le navigateur. Cette structure arborescente est appelé « Document Object Model » abrégé en « DOM ». Un objet racine représente le document complet. Chaque objet est un nœud rattaché à un nœud parent ou à l’objet racine. Parmi les différents types de nœuds possibles, on trouve : - un nœud de type « Element », ou plus simplement élément, correspondant à une balise HTML (exemple , , , , …) ; - un nœud de type « Attribute » correspondant à un attribut dans un élément (exemples « class », « id », « style », « href », …) ; - un nœud de type « Text » correspondant au texte contenu dans un élément. Seuls les nœuds éléments peuvent être des parents. Les nœuds de type « Attribute » et « Text » sont considérés comme des nœuds distaux, ou feuilles, c’est-à-dire ne pouvant pas être parents d’autres nœuds. Les éléments peuvent aussi être des nœuds distaux. La page fournie au navigateur peut intégrer elle-même des liens hypertextes qui permettent un renvoi vers d’autres pages désignées par d’autres URLs. Le serveur est alors en mesure de suivre l’interaction de l’utilisateur avec le site en enregistrant la succession des URLs qu’il reçoit. Le document WO 2002/08903 A1 montre une méthode d’analyse d’un site Internet en collectant des chemins de clics réalisés par différents utilisateurs qui parcourent les différentes pages d’un site. Ceci permet de vérifier que le site est compréhensible et que son utilisation correspond à la logique attendue par le concepteur. Les différentes pages sont identifiées par comparaison d’empreintes partielles de leurs contenus. Cette manière de suivre l’interaction de l’utilisateur avec le site montre ses limites avec les pages dynamiques qui sont permises avec les navigateurs modernes et la version 5 de la codification HTML. On peut ainsi développer des applications complètes avec cette technique qui permet par exemple de remodeler les informations affichées en masquant ou en développant certaines parties, en remplaçant des informations soit élaborées par le navigateur, soit obtenues par des requêtes vers le serveur ou vers d’autres sources. Ces modifications sont réalisées par exemple à l’aide d’un programme client en Javascript qui interagit avec la structure arborescente du document. Il est alors insuffisant de collecter les URLs pour comprendre la manière dont un utilisateur interagit avec une telle application. Dans le document WO 2010/102165 A1, il est proposé une méthode d’analyse de l’interaction d’utilisateurs avec un document en représentant le document à l’affichage et en y superposant une image contenant des points associés aux actions de clic réalisées par une collection d’utilisateurs. On parle ainsi de cartes de chaleur, les zones dans lesquels les utilisateurs cliquent le plus fréquemment apparaissant plus densément colorées sur cette carte. La collecte des informations de clics comprend les coordonnées de celui-ci dans la page affichée. Les zones denses sont attendues sur les lieux correspondant à des actions comme des boutons ou des liens hypertextes. Si des zones sans action associée apparaissaient denses, ceci révèlerait un défaut de représentation qui induirait une action inappropriée des utilisateurs sur cette zone. Même si la carte est divisée en zones pour permettre l’analyse globale, cette méthode n’est pas adaptée à l’analyse d’une application dont la représentation est changeante, y compris en fonction des caractéristiques du terminal sur lequel le navigateur est exécuté, ou en fonction des données saisies préalablement par l’utilisateur ou qui dépendent de celui-ci. L’utilisateur peut par exemple avoir fourni des préférences de présentation ou demander l’affichage de données personnalisées. C’est donc un objectif de fournir une méthode d’analyse de l’interaction d’un utilisateur avec une application permettant de tenir compte du rendu réel à l’écran de l’utilisateur dans un navigateur Internet. C’est également un objectif de rendre cette analyse respectueuse des données des utilisateurs. Avec ces objectifs en vue, l’invention a pour objet un procédé d’analyse de l’interaction d’un utilisateur avec une application informatique, l’application comportant un module serveur s’exécutant sur un serveur d’application et un navigateur Internet s’exécutant sur un terminal à disposition de l’utilisateur pour afficher un document, le module serveur et le navigateur étant en communication par un réseau numérique, procédé selon lequel le navigateur capte au moins un changement de la structure du document affiché dans le navigateur, on construit un arbre de contexte lié au document juste avant le changement et on transmet l’arbre de contexte à un serveur d’analyse associé à une datation du changement sur une échelle temporelle, l’arbre de contexte caractérisant au moins une partie de la géométrie du document, on construit l’arbre de contexte sous la forme d’un arbre de zones, chaque zone étant caractérisée au moins par une position et une taille dans un espace d’affichage du document, le procédé comprenant en outre une analyse de la collection d’arbres de contexte. Le serveur d’analyse permet de collecter des informations sur la structure des pages telles qu’elles s’affichent sur le navigateur de l’utilisateur. Ces informations sont collectées à chaque changement de la structure, ce qui fait qu’elles ne sont pas liées simplement au contenu d’une adresse. La capture est effectuée sur le document tel qu’il apparaît avant le changement, ce qui permet de lier une action au contexte qui prévalait lorsque l’action a été réalisée. L’arbre de contexte permet de subdiviser l’espace occupé par un document à l’affichage dans un navigateur en différentes zones organisées en arborescence. Le serveur d’analyse dispose alors d’informations qui sont liées à l’interaction de l’utilisateur avec le document. Les adaptations du format du document en fonction de la taille de l’écran par exemple sont automatiquement prises en compte et restituées. L’arbre de contexte contient moins d’informations que le document rendu complet, ce qui permet d’éliminer les données personnelles, lesquelles ne sont pas utiles à l’analyse, et d’alléger les informations à transmettre au serveur d’analyse et à y stocker. L’arbre de contexte peut ne concerner qu’une partie du document, quand cette partie représente par exemple une fenêtre modale en surimpression d’une partie de document qui reste en arrière plan. L’analyse permet par exemple de suivre l’évolution de la structure du document pour un même utilisateur et de vérifier qu’elle correspond à ce que le concepteur attendait. Elle permet aussi de comparer des sessions d’utilisateurs distincts, en particulier sur du matériel différent ou des navigateurs différents, et de gommer ces différences de rendu entre ces sessions et faire porter l’analyse sur le contexte réel et non hypothétique. L’échelle temporelle peut être une datation absolue mesurée par exemple par une horloge de l’ordinateur qui anime le navigateur, ou une datation relative telle qu’un compteur qui s’incrémente à chaque fois qu’une datation est fournie. Selon un perfectionnement, on capte au moins un évènement dans le navigateur, on transmet au serveur d’analyse une information d’évènement comprenant au moins la localisation et une datation de l’évènement sur l’échelle temporelle. On ajoute ainsi aux informations collectées par le serveur d’analyse un retour sur l’interaction entre le navigateur et son environnement, en particulier avec l’utilisateur, afin d’associer les évènements à une position sur le document et à un éventuel changement dans la structure du document. Le serveur d’analyse peut ainsi par exemple classer les évènements générés par l’utilisateur en évènements perdus, s’ils sont sans effet sur la structure du document. Selon un mode de réalisation, l’arbre de contexte est construit à partir d’une structure arborescente d’objets modélisant le document, les nœuds étant des nœuds de type élément, de type attribut ou de type texte. La structure arborescente d’objets modélisant le document est par exemple celle qui est normalisée sous le nom de « Document Objet Model ». Cette structure existe déjà au niveau du navigateur et est accessible, il n’est donc pas nécessaire d’effectuer d’opérations complexes avant d’en extraire des informations utiles. De plus, on est certain que la structure arborescente, calculée par le navigateur, reflète le rendu à l’affichage effectué par ledit navigateur. Selon une disposition, on parcourt la structure arborescente d’objets modélisant le document pour définir l’empreinte géographique de chaque zone de l’arbre de contexte à partir de l’empreinte géographique des objets de la structure. Ainsi chaque élément ayant une empreinte géographique dans le document est reflété par une zone dans l’arbre de contexte incluant ladite empreinte géographique. De manière particulière, on supprime de la structure arborescente des nœuds dont l’empreinte géographique est nulle, en particulier des nœuds de type élément ou de type attribut dans une liste prédéfinie pour obtenir l’arbre de contexte. L’arbre à contexte est construit par étapes, en partant de la structure arborescente, qui est modifiée progressivement. En particulier, on sait que certains nœuds ont une empreinte géographique nulle, et qu’il n’est pas utile de les conserver dans l’arbre de contexte. La construction de l’arbre de contexte est ainsi rapide et ne nécessite pas de lourds calculs. Selon un perfectionnement, on simplifie l’arbre de contexte en remplaçant au moins une série de nœuds ayant une structure identique par le premier des nœuds et une indication du nombre de nœuds remplacés. Il est fréquent de rencontrer des structures répétitives dans un document, comme les lignes d’un tableau, ou les éléments d’une liste. Il est alors pertinent de simplifier la représentation dans l’arbre de contexte en ne conservant que le premier élément, avec l’indication du nombre d’éléments remplacés. L’empreinte géographique associée à la zone sera l’union de l’empreinte de tous les éléments de la série. On limite ainsi la quantité d’infirmation à transmettre et à stocker par le serveur d’analyse. Par ailleurs, Ceci permet de rendre comparables des arbres de contexte qui ne diffèrent que par le nombre d’éléments répétés. De manière particulière, on crée un duplicata de la structure arborescente d’objets modélisant le document avant le changement et on modifie le duplicata pour aboutir à l’arbre de contexte. On réalise ainsi une sorte de photographie à un instant donné qui ne prend pas en compte le changement qui intervient ensuite. L’arbre de contexte sera le reflet du document avant l’application du changement. L’arbre de contexte est alors construit par simplification du duplicata. Selon un perfectionnement, lors de l’analyse de la collection d’arbres de contexte par le serveur d’analyse, on regroupe les arbres de contexte en partitions et on construit un graphe orienté de relations entre les partitions, chaque relation du graphe représentant l’existence d’au moins une transition entre l’un des arbres de contexte de l’une et l’autre des partitions. Une transition est l’enregistrement d’une action de navigation entre un arbre de contexte et un autre, notamment suite à un évènement utilisateur. Le partitionnement permet de regrouper en une partition les arbres de contexte qui sont proches, et qui correspondent logiquement à des variations peu significatives d’une même page. Le graphe orienté permet ensuite de représenter le fonctionnement d’une application en représentant les transitions d’une page à une autre. Le parcours de ce graphe permet par exemple de détecter des impasses dans l’application, lorsqu’une partition n’a aucune relation qui part d’elle, donc aucune action permettant de quitter la page. On peut détecter également les pages que l’on qualifiera d’abandon lorsque les relations partantes de la partition sont inférieures à un seuil prédéterminé, ou lorsque la proportion ou la différence entre les relations entrantes et les relations sortantes sont supérieures à des seuils prédéterminés, indiquant que les relations entrantes sont majoritaires. On pourra vérifier que ces pages d’abandon sont attendues, par exemple à la fin d’un processus, ou anormales, ce qui peut révéler une difficulté présentée par l’application auprès de l’utilisateur. Ces détections peuvent être conduites de manière automatique par le serveur d’analyse. On peut aussi mesurer la distance entre deux partitions données, en particulier entre une page dite d’accueil et l’ensemble des autres partitions. Pour détecter les chemins et leur longueur, on peut utiliser des algorithmes de parcours de graphe, tel que l’algorithme de Dijkstra. Ceci permet de donner une alerte si certaines pages sont accessibles par un chemin dont la longueur est supérieure à un seuil prédéterminé. Ceci rend compte de pages qui seraient difficilement accessibles. On peut aussi vérifier que les pages considérées comme importantes par les concepteurs de l’application sont accessibles par des chemins courts. L’analyse peut aussi mesurer la répartition des relations sortantes à partir de chaque partition, en particulier à partir de la page d’accueil. Ceci permet également de voir les chemins de navigation empruntés préférentiellement pour atteindre une page donnée, qui n’est pas nécessairement le plus court. En faisant ressortir les chemins préférentiels qui ne sont pas les plus courts, l’analyse permet de mettre l’accent sur des problèmes de l’interface, en particulier si des orientations ne sont pas facilement perceptibles par les utilisateurs. En appliquant une différentiation par classe d’utilisateurs, on peut mettre en évidence une différence d’utilisation, avec par exemple des chemins préférentiels distincts, ce qui peut signifier que certaines classes d’utilisateurs n’ont pas été suffisamment informés de fonctionnalités de l’application, ou que l’application elle-même ne met pas ces fonctionnalités en évidence. L’analyse permet aussi de comparer deux graphes établis pour deux versions d’une même application. La comparaison par superposition permet de facilement vérifier que tous les nœuds du premier graphe ont un équivalent dans le deuxième, et que les transitions majoritairement utilisées sont les mêmes dans les deux graphes. Si tel n’est pas le cas, cela signifie que des modifications importantes ont été apportées et les concepteurs doivent vérifier que ceci est attendu. De la même manière, on peut comparer deux graphes établis sur deux catégories de dispositifs de navigation, par exemple sur des tablettes et sur des smartphones. Cette comparaison permet de vérifier si la différence de type d’appareils induit une différence de perception de l’application que le développeur pourrait rectifier. Selon un mode de réalisation, le programme d’analyse calcule un nombre réel selon une fonction de distance entre les arbres de contexte pour chaque couple d’arbres de contexte et, à partir de ces nombres réels, le programme d’analyse applique un algorithme de partitionnement pour regrouper les arbres de contexte en partitions. La fonction de distance peut prendre différentes formes, mais à partir du moment où elle fournit une valeur unique de sortie, à savoir le nombre réel, on peut appliquer divers algorithmes de détermination de partitions, comme on le verra mieux par la suite. Selon une application pratique du procédé, on associe une fonction de captation à chacun des nœuds de type élément distaux de la structure arborescente, la fonction de captation identifiant la nature d’un évènement associé audit nœud distal et la datation de l’évènement, puis transmettant ces informations au serveur d’analyse. Les pages d’une application qui sont fournies à un navigateur contiennent des parties de programme écrites en Javascript qui sont associées à des évènements. Ces parties de programme sont dites fonction de gestion d’évènement. Lors de la restitution de la page par le navigateur et de l’interaction de l’utilisateur avec celle-ci, le navigateur capte des évènements. Chaque évènement de ce type est contextualisé dans un nœud élément de la structure arborescente, en fonction du focus, de l’emplacement du pointeur de la souris ou du lieu de contact au moment de l’évènement. De manière connue, le navigateur va progresser dans la structure arborescence à partir du nœud élément de contexte vers la racine jusqu’à trouver un nœud élément ayant une fonction de gestion d’évènement pour le type d’événement considéré. Si aucune fonction n’est trouvée, l’événement est ignoré. Selon la manière dont la fonction de gestion d’évènement est écrite, l’événement est consommé ou non, c’est-à-dire que le processus de parcours de l’arborescence vers la racine est stoppé ou sinon il continue jusqu’à rencontrer une autre fonction de gestion d’évènement, et ainsi de suite. En plaçant la fonction de captation sur les nœuds distaux, on s’assure de voir passer tous les évènements et pouvoir les reporter vers le serveur d’analyse, avant même que ceux-ci soient interceptés ou non par une fonction de gestion d’évènement applicative. La fonction de captation sera du genre qui ne consomme pas l’évènement, afin de ne pas interférer avec le fonctionnement normal de l’application. La datation de l’évènement permet de connaître à quel arbre de contexte l’évènement est associé. De manière complémentaire, on associe une fonction de collecte à un nœud racine duquel tous les autres nœuds de la structure arborescente sont descendants, la fonction de collecte recevant les évènements remontant une chaîne depuis l’un des éléments distaux jusqu’au nœud racine en passant par les nœuds parents successifs sans être interceptés et arrêté par une fonction de gestion d’évènement rattachée aux nœuds de la chaîne, la fonction de collecte transmettant des informations des évènements reçus au serveur d’analyse. La fonction de collecte permet de rendre compte des actions de l’utilisateur qui ne correspondent à aucune fonction de gestion d’évènement, en particulier on peut capter de cette manière les clics perdus, ou savoir quelles zones ont été survolées par la souris. Selon une réalisation particulière, le serveur d’analyse construit une représentation graphique de l’arbre de contexte ou d’une partition regroupant des arbres de contexte et y superpose un élément graphique pour chaque information d’évènement lié à l’arbre de contexte représenté ou à la partition représentée. Une telle représentation est connue sous le nom de carte de chaleur et permet d’obtenir une représentation graphique des lieux où les évènements ont eu lieu. À partir des coordonnées du lieu de l’évènement dans un repère relatif à la zone où il a eu lieu, on place sa représentation graphique par rapport à la représentation de la zone. L’élément graphique est par exemple un simple pixel ou un disque d’un rayon de plusieurs pixels. L’élément graphique peut avoir également une part de transparence, de telle sorte que la superposition d’éléments graphiques apparaisse de manière plus dense. Ainsi, même si un document a été représenté de manière distincte sur des sessions différentes, si l’arbre de contexte ou la partition est la même, la représentation de l’évènement reste cohérente par rapport à la position des zones du document. On peut ainsi regrouper des sessions d’utilisateur qui auraient dû être distinctes avec une représentation identique à celle du document de la session. Les lieux où les évènements sont les plus nombreux apparaissent avec une densité plus importante, ils sont associés à une représentation qui est perçue comme étant active par l’utilisateur. Les représentations d’évènement situées dans des zones non actives sont des évènements perdus et leur analyse permet de comprendre ce qui dans le document serait perçu de manière erronée par l’utilisateur, de manière à y apporter des corrections.Selon un mode de réalisation, pour représenter une partition, le programme d’analyse sélectionne l’un des arbres de contexte parmi l’ensemble des arbres de contexte de la partition qui minimise sa distance moyenne avec les autres arbres de contexte de la partition. Selon un autre mode de réalisation, pour représenter de l’une des partitions, le programme d’analyse construit un arbre de contexte d’intersection, tel que tout arbre de contexte de la partition possède des branches en plus par rapport à l’arbre de contexte d’intersection, mais aucune branche en moins, et l’empreinte géographique des éléments de cet arbre de contexte d’intersection est l’intersection spatiale des empreintes de l’ensemble des membres. L’invention a aussi pour objet un système d’analyse de l’interaction d’un utilisateur avec une application informatique, le système comportant un serveur d’application sur lequel un module serveur de l’application s’exécute, au moins un terminal à disposition de l’utilisateur sur lequel s’exécute un navigateur Internet pour afficher un document, le module serveur et le navigateur étant en communication par un réseau numérique, un serveur d’analyse connecté au réseau numérique, le terminal étant configuré pour que le navigateur capte au moins un changement de la structure du document affiché dans le navigateur, construire un arbre de contexte lié au document juste avant le changement et transmettre l’arbre de contexte au serveur d’analyse en association à une datation du changement sur une échelle temporelle, l’arbre de contexte caractérisant au moins une partie de la géométrie du document et étant construit sous la forme d’un arbre de zones, chaque zone étant caractérisée au moins par une position et une taille dans un espace d’affichage du document, le serveur d’analyse étant configuré pour réaliser en outre une analyse de la collection d’arbres de contexte, le système mettant en œuvre le procédé tel que décrit précédemment. Brève description des figures L’invention sera mieux comprise et d’autres particularités et avantages apparaîtront à la lecture de la description qui va suivre, la description faisant référence aux dessins annexés parmi lesquels : : la figure 1 est une vue schématique d’un système mettant en œuvre un procédé selon l’invention ; : la figure 2 est un ordinogramme représentant le procédé d’acquisition des informations selon l’invention ; : la figure 3 est un ordinogramme représentant le procédé de capture d’un arbre de contexte par le navigateur ; : la figure 4 est un ordinogramme représentant une étape de l’ordinogramme de la figure 3 ; : la figure 5 est une représentation schématique de l’affichage d’un document ; : la figure 6 est un ordinogramme représentant le procédé de capture d’un arbre de contexte par un serveur d’analyse ; : la figure 7 est une représentation schématique temporelle d’une succession d’actions et de contextes résultant ; : la figure 8 est un graphe issu de la succession d’actions de la figure 7 ; : la figure 9 est une représentation d’un document affiché par un navigateur sur un dispositif client du système de la figure 1 ; : la figure 10 est une vue du même document de la figure 9, affiché par un navigateur avec une largeur plus étroite ; : la figure 11 est un diagramme représentant une structure arborescente du document des figures 9 et 10 ; : la figure 12 est un diagramme représentant un arbre de contexte construit à partir de la structure arborescente de la figure 11 ; : la figure 13 est un diagramme représentant l’arbre de contexte de la figure 12 après une étape supplémentaire de réduction. Description détaillée Un système mettant en œuvre un procédé d’analyse de l’interaction d’un utilisateur avec une application informatique selon l’invention est montré de manière schématique sur la figure 1. Le système comporte un serveur d’application 1, un réseau 2 numérique tel que le réseau Internet, un premier terminal 3, un deuxième terminal 4, un troisième terminal 5 et un serveur d’analyse 6. L’application comporte un module serveur s’exécutant sur le serveur d’application 1 et un navigateur Internet s’exécutant sur le terminal 3, 4, 5 à disposition de l’utilisateur pour afficher un document. Le module serveur et le navigateur sont en communication à travers le réseau 2 dont le détail n’est pas fourni ici puisque bien connu de l’homme du métier. Le module serveur est un programme qui exécute du code écrit par exemple en PHP, en Python ou en Node.js, pour recevoir des requêtes du navigateur du terminal et fournir des réponses comprenant notamment des pages au format HTML au terminal. Le navigateur envoie les requêtes au serveur et reçoit ses réponses, puis affiche le document reçu. Le document comprend également un programme client, codé par exemple en Javascript, qui est interprété par le navigateur et qui reçoit des évènements reçus par le navigateur pour générer des actions d’envoi éventuel de requêtes au serveur et de modification du document en réaction à l’évènement ou à la réponse reçue du serveur d’application 1. Le programme client inclut des instructions pour mettre en œuvre une partie du procédé selon l’invention. Ainsi, le programme client fourni au navigateur est prévu pour communiquer avec le serveur d’analyse 6 et lui fournir des éléments d’information relatifs au fonctionnement de l’application dans le navigateur. Lors du fonctionnement de l’application, l’utilisateur initie une session en fournissant dans le navigateur du terminal 3, 4, 5 une adresse URL correspondant au serveur d’application 1. Le serveur d’application 1 reçoit cette requête et fournit un document servant de page d’accueil qui est affiché par le navigateur du terminal 3, 4, 5. Le navigateur reçoit le document et construit une structure arborescente d’objets modélisant le document, d’une manière connue en soi. La structure arborescente est composée de nœuds de type élément, de type attribut ou de type texte, avec un nœud racine dont tous les autres nœuds sont des descendants. L’utilisateur interagit avec ce document, par exemple avec un clavier 38, une souris 39 ou un dispositif d’entrée tactile, non représenté. De nouvelles requêtes sont envoyées au serveur d’application 1 qui répond en prenant en compte l’état de la session en cours. En référence à la figure 2, le procédé d’acquisition des informations sur le fonctionnement de l’application est décrit. Une première fonction 10 est de capturer la session qui se déroule sur le navigateur et de transmettre des arbres de contexte successifs de cette session en direct vers le serveur d’analyse 6 afin que celui-ci traite les arbres de contexte et les stocke. Une deuxième fonction 20, qui peut être faite directement à la réception des arbres de contexte ou de manière différée par le serveur d’analyse 6 est de simplifier les arbres de contexte. Après la collecte d’une collection d’arbres de contexte, ceux-ci peuvent être regroupés quand ils sont identiques par une troisième fonction 30, et un graphe construit avec des arbres de contexte distincts comme sommets et des évènements d’interaction comme transitions orientées entre les sommets. Enfin, une quatrième fonction 40 analyse les différentes sessions en effectuant un partitionnement entre les arbres de contexte et formant un deuxième graphe avec des partitions d’arbres de contexte ainsi constituées comme sommets et des relations synthétisant les relations des arbres de contexte d’une partition vers des arbres de contexte d’une autre partition. La première fonction 10 est maintenant décrite plus en détail, en référence aux figures 3 à 5. Le programme client exécute le procédé de construction d’un arbre de contexte au cours d’une session. Pour cela, en référence à la figure 3, il vérifie à l’étape 101 d’abord que le navigateur stocke un identifiant de session d’analyse fourni par le serveur d’analyse 6. Si tel n’est pas le cas, dans une étape 102, il envoie une requête auprès du serveur d’analyse 6 pour recevoir un tel identifiant et le stocker localement tant que la page reste ouverte dans le navigateur . Il initialise également un compteur d’horodatage qui sert d’échelle temporelle. Quand le programme client dispose de l’identifiant de session d’analyse, il procède à l’étape 103 à une construction de l’arbre de contexte selon le procédé exposé sur la figure 4. Une fois cette construction effectuée, il se met, à l’étape 104, en attente d’un changement dans la structure arborescente qui déclenche une nouvelle construction d’arbre de contexte vers l’étape 103. En référence à la figure 4, qui détaille l’étape 103 de construction d’un arbre de contexte, le programme client crée un duplicata de la structure arborescente d’objets modélisant le document avant le changement à l’étape 104. Il crée une datation pour cet arbre de contexte. Pour cela, à chaque opération de datation, le compteur d’horodatage est augmenté de un et sa nouvelle valeur est relevée et sert de datation. Elle est ainsi associée à l’arbre de contexte en construction. À l’étape 105, le programme client parcourt l’ensemble des nœuds du duplicata, élimine ceux qui ne sont pas affichables et convertit les autres en zones auxquelles il associe les informations d’une empreinte géographique du nœud correspondant. Le programme client supprime de la structure arborescente en particulier des nœuds de type élément ou de type attribut dans une liste prédéfinie. En effet certains nœuds sont connus pour ne pas avoir d’empreinte géographique, tels que des nœuds définis par des balises HTML « head », « script », « link », « meta », et « base » pour les nœuds éléments, ou « alt », « style », « align », « placeholder », « title » et ceux qui commencent par « data- ». Chaque zone est caractérisée par une position dans le document et une taille, c’est-à-dire l’empreinte géographique, dans un espace d’affichage du document et conserve comme enfants les nœuds également convertis en zones. En se référant à la figure 5, l’affichage de l’application sur un écran S est représenté par une zone rectangulaire Za. Cette zone est subdivisée en différentes zones rectangulaires. A l’intérieur de l’une de ces zones on a représenté une zone rectangulaire Ze plus petite d’un élément enfant de sa zone parent Zp. La zone Ze a une taille avec une largeur w et une hauteur h et est placée à une distance X l du bord gauche de sa zone parent Zp et une distance Yl du bord supérieur de ladite zone parent Zp. Ces informations permettent de caractériser l’empreinte géographique de la zone enfant Ze. À l’étape 106, les zones dont la taille est nulle sont également supprimées. À l’étape 107, le programme client fusionne également les zones imbriquées confondues, c’est-à-dire les zones ayant un unique enfant de même empreinte géographique. À l’étape 108, le programme client procède à une linéarisation des éléments non structurants, c’est-à-dire au fil du texte, comme les nœuds définis par des balises définissant un style de texte, par exemple les balises « strong », « em », « span », « code », « b », et « i ». Ainsi les nœuds non structurants sont supprimés. Finalement, à l’étape 109 le texte est supprimé, hormis celui qui correspond à des mots préétablis, comme les libellés d’actions. Après modification du duplicata, on aboutit à un objet de contexte qui peut être transmis au serveur d’analyse 6 à l’étape 110. Le cumul des empreintes géographiques permet que l’arbre de contexte caractérise la géométrie du document complet ou d’une partie du document au moins. La figure 5 montre la manière dont le procédé se passe sur le serveur d’analyse 6 pour la collecte des arbres de contexte. Un processus 120 s’y exécute et est à l’écoute des requêtes de transmission des arbres de contexte par le navigateur. Chaque arbre de contexte reçu en 121 depuis l’étape 110 déclenche une étape de stockage 122 dans laquelle l’arbre de contexte reçu est associé à l’identifiant de session et à la datation, puis stocké dans un historique qui peut être trié en fonction de sa datation. D’autres traitements peuvent ensuite être conduits à l’étape 123. Chaque arbre de contexte est d’abord traité individuellement par le serveur d’analyse 6, de manière à réduire l’arbre de contexte en remplaçant au moins une série de nœuds ayant une structure répétitive par le premier des nœuds et une indication du nombre de nœuds remplacés. Pour cela, le programme qui s’exécute sur le serveur d’analyse 6 parcourt de manière récursive l’arbre de contexte tel que transmis par le programme client. Les zones distales sont conservées. Pour les zones non distales, mais en commençant par les plus éloignées de la racine, le programme établit une liste de l’ensemble des zones sœurs ayant une même zone comme parent. Il compare ces zones sœurs entre elles pour déterminer si elles ont la même structure. On considère dans ce cas qu’elles sont superposables. Deux zones de l’arbre de contexte sont localement superposables s’ils ont le même parent et une série de zones ayant la même succession de noms (c’est-à-dire définis par la même succession de balises). Quand plusieurs zones sont superposables, elles sont remplacées par la première zone de la liste avec l’indication du nombre de zones remplacées. L’empreinte géographique de la zone parente reste la même, c’est-à-dire celle déterminée par la présence de l’ensemble de zones sœurs. Le remplacement peut être conditionné à l’existence d’un seuil prédéfini de zones superposables, par exemple plus de quatre. Le programme client est prévu pour capter des évènements dans le navigateur. Dans l’exemple avec le programme client, on inclut dans le programme une fonction de captation, avec la fonction de captation attachée à chacun des nœuds de type élément distaux de la structure arborescente. La fonction de captation identifie la nature d’un évènement associé audit nœud distal et la datation de l’évènement, puis transmet ces informations au serveur d’analyse 6, comme représenté à l’étape 124 de la figure 6. Le programme client transmet au serveur d’analyse 6 une information d’évènement comprenant la localisation en coordonnées absolue dans la page et en coordonnées relatives dans le nœud associé et une datation de l’évènement sur l’échelle temporelle. La transmission des coordonnées relatives serait suffisantes, mais l’ajout des coordonnées absolues est une commodité. On distingue différents types d’évènements, par exemple un évènement utilisateur qui correspond à une interaction initiée par l’utilisateur du navigateur. Ces événements utilisateurs sont par exemple des événements souris, tels qu’une action sur un bouton, autrement dit un clic (gauche, droit, molette), un survol d’un élément de la structure arborescente, un déplacement du curseur à l’écran, un défilement à l'aide de la molette, un glisser-déposer ou un survol d’un élément pendant une durée supérieure à une durée prédéterminée, par exemple deux secondes. Un événement souris est caractérisé par un certain nombre de propriétés, parmi lesquelles les coordonnées absolues de la souris dans la fenêtre du navigateur, les coordonnées relatives de la souris dans le nœud élément se trouvant sous le pointeur au moment de l’événement, la liste des boutons de souris enfoncés au moment de l’événement, la liste des touches du clavier modificatrices (Ctrl, Alt, Maj...) enfoncées au moment de l’événement. On distingue également parmi les évènements utilisateur des événements clavier : changement de l’état, enfoncé ou relâché, d’une ou plusieurs touches du clavier (y compris touches modificatrices). En général, un événement clavier est contextualisé à un nœud élément particulier qui doit avoir le focus pour être pris en compte. On distingue également parmi les évènements utilisateur des événements de toucher pour les actions réalisées sur un écran tactile. On peut donner comme exemple d’événements toucher le simple toucher, simulant un clic de souris, le pincement (pour zoomer), le toucher long, simulant un clic droit, le défilement à trois doigts… En règle générale, tout événement de toucher peut être caractérisé par une trajectoire spatiale et temporelle d’un ensemble de points (un point par doigt), certaines trajectoires étant interprétées directement par le navigateur comme des actions prédéfinies. Enfin, en dehors des événements utilisateur, on distingue des événements système, qui correspondent à des évènements déclenchés automatiquement lors de certains changements d’états internes du navigateur. À titre d’exemple, on distingue la fin de chargement du document courant, l’arrivée asynchrone de la réponse à une requête réseau lancée précédemment, le changement des dimensions de la fenêtre du navigateur, la fermeture du navigateur ou de l’onglet courant, ou tout événement spécifique à la logique de l’application, tel que le changement de valeur de certaines variables clés. À chaque évènement peut être attachée une fonction d’événement, soit prédéfinie dans le navigateur, soit fournie par le programme client, et appelée lors du déclenchement du ou des événements auxquels elle est attachée. Lorsqu’une collection importante d’arbres de contexte a été enregistrée dans l’historique, par exemple lorsque le nombre d’arbres de contexte dépasse un seuil prédéterminé, le serveur d’analyse 6 exécute un ou plusieurs programmes d’analyse sur la collection d’arbres de contexte. Les résultats sont mis à disposition d’un chargé d’analyse qui reçoit une alerte sur cette mise à disposition. L’analyse peut aussi être déclenchée manuellement. Le serveur d’analyse relance par exemple l’analyse lorsque qu’un nombre significatif d’arbres de contexte ont été ajoutés depuis la dernière analyse. Le programme d’analyse peut commencer par comparer l’ensemble des arbres de contexte entre eux, pour identifier ceux qui sont identiques, c’est à dire parfaitement superposables. Si deux arbres de contexte sont identiques, un seul est conservé et l’autre est remplacé par une référence au contenu du premier. Le programme d’analyse réalise, pour chaque arbre de contexte, une association entre un évènement qui a déclenché le passage vers l’arbre de contexte, sur la base de la datation. Cet évènement est appelé une transition. La figure 7 montre une frise chronologique qui permet de comprendre comment le serveur d’analyse reconstitue les transitions entre les arbres de contexte. On considère qu’une page est affichée initialement et qu’elle correspond à un arbre de contexte AC 0 . Une action A 1 de l’utilisateur produisant un évènement ne donne lieu à aucun changement de l’affichage. Une action suivante A 2 de l’utilisateur provoque une modification de l’affichage en même temps qu’un appel asynchrone dit « REST » envoyé au serveur d’application 1. Le navigateur affiche alors une page correspondant à un arbre de contexte AC 1 en réponse à l’action de l’utilisateur, puis une page correspondant à un arbre de contexte AC 2 en réponse au retour du serveur d’application après l’appel « REST ». De la même manière une action A 3 est suivie de l’arbre de contexte initial AC 0 et une action A 4 est suivie d’un arbre de contexte AC 3 . Les arbres de contexte et les actions sont tous datés sur l’échelle temporelle de telle sorte que le serveur d’analyse 6 est en mesure de déterminer l’ordonnancement des actions et des arbres de contexte. En se référent à la figure 8, à partir de cet ordonnancement, le serveur d’analyse 6 construit un graphe orienté dont les nœuds sont les arbres de contexte AC 0 , AC 2 , AC 3 et des transitions les reliant : l’action A 2 part de AC 0 vers AC 2 , l’action A 3 part de AC 2 vers AC 0 et l’action A 4 va de AC 0 vers AC 3 . De manière optionnelle, le serveur d’analyse 6 effectue un traitement de chaque arbre de contexte pour le découper en plusieurs arbres de contexte. Pour cela il applique des règles qui peuvent être adaptées à chaque application. Par exemple, un nœud élément défini par une balise « iframe » peut être détaché en arbre indépendant avec sa descendance. Un tel nœud correspond en général à une structure sensiblement indépendante, qui permet par exemple la distinction entre un menu, un bandeau d’entête ou de pied de page, récurrents entre différentes pages, et une zone de contenu plus spécifique. D’autres balises peuvent être caractéristiques de fenêtres modales qui s’affichent en surimposition et à partir desquelles on peut détacher un arbre de contexte. Le programme d’analyse regroupe les arbres de contexte en partitions et construit un graphe orienté de relations entre les partitions, chaque relation du graphe représentant l’existence d’au moins une transition entre l’un des arbres de contexte de l’une et l’autre des partitions. Malgré les étapes de simplifications précédentes, deux arbres de contexte similaires mais en provenance d’utilisateurs différents peuvent encore ne pas être parfaitement superposables. Avec des applications potentiellement hautement dynamiques, on ne peut pas exclure par exemple la présence de zones de notification temporaires spécifiques à l’utilisateur, d’éléments de personnalisation de l’interface par l’utilisateur ou d’état d’affichage adaptés. Dans le but de dégager une représentation synthétique exploitable de la topologie de l’application, on propose de regrouper ces arbres de contexte similaires en partitions, et de construire un arbre de contexte représentatif pour chaque partition et chargé de représenter significativement l’ensemble des arbres de contexte de ladite partition. Pour regrouper les arbres de contexte en partitions, on définit une fonction de distance entre les arbres de contexte qui fournit un nombre réel. À partir de cette fonction de distance, le programme d’analyse applique un algorithme de partitionnement tel qu’un algorithme de K-moyennes ou un algorithme de classification hiérarchique tel que la méthode de Ward. Pour calculer la distance, à titre d’exemple, on peut construire un arbre différentiel représentant la différence topologique entre les deux arbres de contexte à comparer. Un nœud dans cet arbre peut avoir trois statuts : - nœud commun aux deux arbres : pas de différence ; - nœud retrait : ce nœud et la branche qu’il porte est présent dans le premier arbre de contexte, mais pas dans le deuxième ; - nœud ajout : ce nœud et la branche qu’il porte est présent dans le deuxième arbre de contexte, mais pas dans le premier. Dans cette définition de la distance, on ne s’intéresse qu’aux différences topologiques, c’est-à-dire qu’on ne tient pas compte des différences d’empreinte géographique ou de style. On définit la distance comme étant le score de l’arbre différentiel évalué selon la formule suivante : avec B nc l’ensemble des branches non communes entre les deux arbres de contexte, P une fonction donnant le poids d’une branche. Plusieurs méthodes peuvent être utilisées pour calculer le poids d’une branche. Les paramètres pouvant entrer en ligne de compte dans le poids d’une branche sont : Hb : Hauteur de la branche, c’est-à-dire la distance maximale entre la base de la branche et le nœud distal le plus éloigné ; P nc : Profondeur du dernier nœud commun, c’est-à-dire la distance entre la racine de l’arbre différentiel et le nœud racine de la branche divergente ; N n : Nombre de nœuds total dans la branche. Des exemples de fonction de poids sont : Ces paramètres peuvent aussi être combinées entre eux avec des coefficients de pondération. Une fois les arbres de contexte regroupés en partitions, il est nécessaire d’associer un arbre de contexte représentatif à chaque partition. Selon une première option, on choisit un arbre de contexte parmi l’ensemble des arbres de contexte de la partition. Par exemple, on choisit celui qui minimise sa distance moyenne avec les autres membres. Selon une deuxième option, on construit un arbre de contexte d’intersection, tel qu’il a la propriété suivante : tout arbre de contexte de la partition possède des branches en plus par rapport à l’arbre de contexte d’intersection, mais aucune branche en moins. Pour l’empreinte géographique des éléments de cet arbre de contexte d’intersection, on peut également prendre l’intersection spatiale des empreintes de l’ensemble des membres. À partir des partitions, on construit un graphe orienté avec les partitions comme sommets et des transitions entre les partitions. Chaque transition entre une première et une deuxième partition représente le fait qu’au moins un arbre de contexte de la première partition a une transition vers au moins un arbre de contexte de la deuxième partition. En représentant un tel graphe, il est possible visualiser les différentes pages d’une application avec les transitions entre elles. Le serveur d’analyse 6 construit, à la demande, en exécutant l’un des programmes d’analyse, une représentation graphique de l’un des arbres de contexte et y superpose un élément graphique pour chaque information d’évènement lié à l’arbre de contexte représenté. On peut demander également la construction graphique de l’arbre de contexte représentatif d’une partition et y ajouter un élément graphique pour chaque information d’évènement lié à l’ensemble des arbres de contexte de la partition. Pour représenter un arbre de contexte, on peut représenter les zones par des rectangles correspondant à leur empreinte géographique, avec une bordure de couleur selon une légende. On peut également représenter les zones par des rectangles dont le fond est coloré par une mosaïque d’images issues d’écrans rendus flous, pour faciliter le lien visuel entre l’arbre de contexte et la page correspondante. L’élément graphique est par exemple un rond en couleur. Sa position est réalisée par ses coordonnées relatives dans la zone à laquelle l’évènement est attaché, ce qui fiabilise le rendu en le rendant insensible au défilement de la page, aux changements de résolution, aux changements de contenu dynamique créant un décalage dans la page, etc. La représentation graphique pour une partition permet d’agréger des données en provenance de plusieurs sessions d’un utilisateur ou de plusieurs utilisateurs, ce qui augmente le poids statistique. Avec la précision augmentée par rapport à l’art antérieur, on peut par exemple repérer plus facilement les erreurs de clic, à savoir les actions dans les zones inactives. Le programme d’analyse effectue un traitement optionnel de marquage des nœuds, par un mot étiquette ou par une couleur. Le marquage est par exemple réalisé sur la base de l’adresse URL ou d’une partie de celle-ci. Ainsi, le rendu graphique du graphe orienté est enrichi, que ce soit un rendu en deux dimensions ou trois dimensions, en permettant une segmentation visuelle des nœuds. Plutôt qu’un marquage automatique, le programme d’analyse peut donner la possibilité à un analyste de réaliser manuellement le marquage. Le serveur d’analyse 6 construit, à la demande, en exécutant l’un des programmes d’analyse, un sous-graphe orienté acyclique, dans lequel le sous-graphe a les mêmes nœuds que le graphe orienté mais pas toutes les transitions. En prenant la page d’accueil comme racine de ce sous-graphe, on obtient alors une structure montrant la hiérarchie des pages de l’application, ce qui est bien plus facile à représenter et à appréhender pour en faire l’analyse. En particulier, il sera bien plus simple de marquer les nœuds du graphe en se basant sur le sous-graphe, soit manuellement, soit de manière automatique. Le programme d’analyse donne la possibilité à l’analyste de fournir une classification des utilisateurs en différentes catégories par une source extérieure, selon par exemple leur expérience ou les missions qu’ils ont reçues. L’analyse permet alors de visualiser sur une représentation du graphe orienté les différences entre les transitions choisies par les différentes catégories. Les résultats d’une telle analyse permettent d’identifier des besoins d’explication, de formation ou de modification de l’application pour rendre par exemple certaines transitions mieux perceptibles. Dans un exemple d’application sur laquelle le procédé d’analyse peut être mise en œuvre, une page d’accueil est fournie comme montrée sur la figure 9. Cette page comporte une bannière, un menu latéral, une zone de contenu et un bandeau de pied. Le menu contient une liste avec plusieurs entrées. La zone de contenu contient du texte. Le bandeau de pied contient un bouton composé d’une icône et d’un libellé. La même page peut être rendue comme montrée sur la figure 10 sur un appareil ayant un écran de plus petite largeur. Les informations de la page sont les mêmes que sur la figure 9, mais la bannière, le menu latéral, la zone de contenu et le bandeau de pied sont empilés verticalement. La page est représentée par une structure arborescente telle que représentée sur la figure 11. La structure comporte un nœud élément « document » duquel descend un nœud élément « html » lequel a quatre nœuds éléments « div » comme enfants, correspondant respectivement à la bannière, au menu latéral, à la zone de contenu et au bandeau de pied. Chaque nœud élément div a un descendant qui est un nœud attribut « class » dont le contenu n’est pas détaillé ici, mais détermine la position et l’aspect en association avec une feuille de style CSS. Le premier nœud élément « div » a en outre pour enfant un nœud texte contenant le titre de l’application. Le deuxième nœud élément « div » a en outre pour enfant un nœud élément « ul » qui a trois nœuds élément « li », lesquels contiennent chacun un élément texte. Le troisième nœud élément « div » a pour enfant un nœud texte avec le contenu. Le quatrième nœud élément« div » a pour enfant un nœud « button » ayant lui-même un nœud élément « img », lequel a un nœud attribut « src » définissant un lien vers l’icône et un nœud élément « label », lequel a un nœud texte avec « Valider ». Le programme client construit l’arbre de contexte tel que montré sur la figure 12, à partir de la structure arborescente. Par rapport à cette dernière, on a supprimé les nœuds attribut « class » et « style » et tous les nœuds texte, sauf le texte du nœud « label » du bouton qui correspond à un mot prédéfini à ne pas supprimer. La figure 13 montre le résultat du traitement de l’arbre de contexte par le serveur d’analyse 6 pour simplifier les zones répétitives. Par rapport à l’arbre de la figure 12, les trois zones « li » ont été remplacées par une seule zone et l’indication qu’elle est répétée trois fois. Le procédé d’analyse selon l’invention peut être utilisé par exemple pour détecter un plagiat de site. On indique au départ un site de référence et un deuxième site. La récolte des arbres de contexte est effectuée sur les deux sites, et quand un nombre suffisant de données a été récolté, le programme d’analyse déclenche une comparaison en construisant les graphes orientés et en les superposant. Si la superposition coïncide pour un taux de nœuds supérieur à un seuil prédéterminé, le programme d’analyse conclut à une similitude assimilable à un plagiat. Procédé d’analyse de l’interaction d’un utilisateur avec une application informatique, l’application comportant un module serveur s’exécutant sur un serveur d’application (1) et un navigateur Internet s’exécutant sur un terminal (3, 4, 5) à disposition de l’utilisateur pour afficher un document, le module serveur et le navigateur étant en communication par un réseau numérique (2), procédé selon lequel le navigateur capte au moins un changement de la structure du document affiché dans le navigateur, on construit un arbre de contexte (AC 0 , AC 2 , AC 3 ) lié au document juste avant le changement et on transmet l’arbre de contexte à un serveur d’analyse (6) associé à une datation du changement sur une échelle temporelle, l’arbre de contexte (AC 0 , AC 2 , AC 3 ) caractérisant au moins une partie de la géométrie du document, on construit l’arbre de contexte (AC 0 , AC 2 , AC 3 ) sous la forme d’un arbre de zones, chaque zone étant caractérisée au moins par une position (x l , y l ) et une taille (w, h) dans un espace d’affichage (Za) du document, le procédé comprenant en outre une analyse de la collection d’arbres de contexte (AC 0 , AC 2 , AC 3 ). Procédé selon la revendication 1, selon lequel on capte au moins un évènement dans le navigateur, on associe l’évènement à l’arbre de contexte (AC 0 , AC 2 , AC 3 ) valide juste avant l’évènement et on transmet au serveur d’analyse (6) une information d’évènement comprenant au moins l’identification de l’arbre de contexte (AC 0 , AC 2 , AC 3 ), la localisation et une datation de l’évènement sur l’échelle temporelle. Procédé selon l’une des revendications 1 ou 2, selon lequel l’arbre de contexte (AC 0 , AC 2 , AC 3 ) est construit à partir d’une structure arborescente d’objets modélisant le document, les nœuds étant des nœuds de type élément, de type attribut ou de type texte. Procédé selon la revendication 3, selon lequel on parcourt la structure arborescente d’objets modélisant le document pour définir l’empreinte géographique (x l , y l , w, h) de chaque zone de l’arbre de contexte (AC 0 , AC 2 , AC 3 ) à partir de l’empreinte géographique des objets de la structure. Procédé selon la revendication 3 ou 4, selon lequel on supprime de la structure arborescente des nœuds dont l’empreinte géographique est nulle, en particulier des nœuds de type élément ou de type attribut dans une liste prédéfinie pour obtenir l’arbre de contexte (AC 0 , AC 2 , AC 3 ). Procédé selon la revendication 5, selon lequel on simplifie l’arbre de contexte (AC 0 , AC 2 , AC 3 ) en remplaçant au moins une série de nœuds ayant une structure identique par le premier des nœuds et une indication du nombre de nœuds remplacés. Procédé selon l’une des revendications 3 à 6, selon lequel on crée un duplicata de la structure arborescente d’objets modélisant le document avant le changement et on modifie le duplicata pour aboutir à l’arbre de contexte (AC 0 , AC 2 , AC 3 ) . Procédé selon l’une des revendications précédentes, selon lequel, lors de l’analyse de la collection d’arbres de contexte par le serveur d’analyse (6), on regroupe les arbres de contexte en partitions et on construit un graphe orienté de relations entre les partitions, chaque relation du graphe représentant l’existence d’au moins une transition entre l’un des arbres de contexte de l’une et l’autre des partitions. Procédé selon la revendication 8, selon lequel le programme d’analyse calcule un nombre réel selon une fonction de distance entre les arbres de contexte pour chaque couple d’arbres de contexte (AC 0 , AC 2 , AC 3 ) et, à partir de ces nombres réels, le programme d’analyse applique un algorithme de partitionnement pour regrouper les arbres de contexte (AC0, AC 2 , AC 3 ) en partitions. Procédé selon la revendication 3 en combinaison avec l’une des revendications précédentes, selon lequel on associe une fonction de captation à chacun des nœuds de type élément distaux de la structure arborescente, la fonction de captation identifiant la nature d’un évènement associé audit nœud distal et la datation de l’évènement, puis transmettant ces informations au serveur d’analyse (6). Procédé selon la revendication 9, selon lequel on associe une fonction de collecte à un nœud racine duquel tous les autres nœuds de la structure arborescente sont descendants, la fonction de collecte recevant les évènements remontant une chaîne depuis l’un des éléments distaux jusqu’au nœud racine en passant par les nœuds parents successifs sans être interceptés et arrêté par une fonction de gestion d’évènement rattachée aux nœuds de la chaîne, la fonction de collecte transmettant des informations des évènements reçus au serveur d’analyse (6). Procédé selon la revendication 2 en combinaison avec l’une des revendications précédentes, selon lequel le serveur d’analyse (6) construit une représentation graphique de l’arbre de contexte (AC 0 , AC 2 , AC 3 ) ou d’une partition regroupant des arbres de contexte et y superpose un élément graphique pour chaque information d’évènement lié à l’arbre de contexte (AC 0 , AC 2 , AC 3 ) représenté ou à la partition représentée. Procédé selon la revendication 12, selon lequel, pour représenter une partition, le programme d’analyse sélectionne l’un des arbres de contexte parmi l’ensemble des arbres de contexte de la partition qui minimise sa distance moyenne avec les autres arbres de contexte de la partition. Procédé selon la revendication 12, selon lequel, pour représenter de l’une des partitions, le programme d’analyse construit un arbre de contexte d’intersection, tel que tout arbre de contexte de la partition possède des branches en plus par rapport à l’arbre de contexte d’intersection, mais aucune branche en moins, et l’empreinte géographique des éléments de cet arbre de contexte d’intersection est l’intersection spatiale des empreintes de l’ensemble des membres. Système d’analyse de l’interaction d’un utilisateur avec une application informatique, le système comportant un serveur d’application (1) sur lequel un module serveur de l’application s’exécute, au moins un terminal (3, 4, 5) à disposition de l’utilisateur sur lequel s’exécute un navigateur Internet pour afficher un document, le module serveur et le navigateur étant en communication par un réseau numérique (2), un serveur d’analyse (6) connecté au réseau numérique, le terminal étant configuré pour que le navigateur capte au moins un changement de la structure du document affiché dans le navigateur, construire un arbre de contexte (AC 0 , AC 2 , AC 3 ) lié au document juste avant le changement et transmettre l’arbre de contexte au serveur d’analyse (6) en association à une datation du changement sur une échelle temporelle, l’arbre de contexte (AC 0 , AC 2 , AC 3 ) caractérisant au moins une partie de la géométrie du document et étant construit sous la forme d’un arbre de zones, chaque zone étant caractérisée au moins par une position et une taille dans un espace d’affichage du document, le serveur d’analyse (6) étant configuré pour réaliser en outre une analyse de la collection d’arbres de contexte ( AC0, AC 2 , AC 3 ) , le système mettant en œuvre le procédé selon l’une des revendications 1 à 14.