Les chroniques de la traçabilité - Episode 1 : Comment les journaux peuvent vous aider à comprendre ce que font vos utilisateurs ?

Nous commençons ici une série d'articles expliquant certains de nos résultats les plus intéressants en matière de traçabilité des applications. Nous aborderons les questions de l'instrumentation automatique du code pour tracer le système par lui-même et les difficultés sous-jacentes. Nous discuterons également de ce qui constitue une bonne trace d'application, utile et utilisable. Nous discuterons également des utilisations possibles des traces logicielles, du débogage à l'UX, et pour automatiser les tests. Ce premier article d'introduction explique pourquoi l'utilisation des traces est importante et intéressante et quelles sont les difficultés lorsqu'on essaie de faire de la rétro-ingénierie d'une application pour reconstruire les graphiques de navigation de l'interface graphique à partir des traces.

Pour un instant, cessez de considérer votre logiciel quotidien comme un outil mais plutôt comme un labyrinthe d'écrans, de boutons, d'actions, de menus déroulants, de boîtes combo, de procédures, de traitements, de flux de travail, etc. La routine quotidienne de vos utilisateurs finit par naviguer dans ce labyrinthe de fonctionnalités, probablement parfois avec hésitation et incertitude et (espérons-le) pour les plus expérimentés avec confiance et autonomie.

En tant qu'éditeur de logiciels, il est évident pour nous (propriétaire du produit, développeurs, chefs de projet, etc.) que nous voulons tous réaliser le meilleur produit, le plus facile à apprendre, à comprendre et à naviguer. On peut y parvenir en suivant scrupuleusement les heuristique de conception de Jakob Nielsen ou le célèbre Critères ergonomiques du logiciel Bastien-Scapin. Si le respect de ces règles élémentaires de l'UX doit se faire de manière systématique (et sans compromis), nous savons que, dans la pratique, il est EXTREMELY difficile. C'est particulièrement le cas lors du développement d'un produit destiné à être utilisé par un panel très hétérogène d'utilisateurs, chacun venant avec ses exigences et sa liste de fonctionnalités de Noël. En conséquence, votre interface utilisateur devient un compromis entre la conformité réglementaire, les retours d'expérience d'utilisateurs hétérogènes et les possibilités offertes par votre framework frontal et les widgets disponibles.

Cette image a un attribut alt vide ; son nom de fichier est 1*MTpmiI05jspy3IJNSKiehQ.png
Les utilisateurs finaux n'utilisent pas toujours la voie prescriptive...

Compte tenu du fait que nous avons des milliers d'utilisateurs, provenant de diverses administrations avec leurs propres pratiques et habitudes, vous pouvez avoir une idée très limitée de ce que vos utilisateurs font avec votre logiciel. Dès lors, comment avoir une meilleure idée de ce qui se passe avec votre logiciel dans la nature ? C'est là que les journaux d'application deviennent intéressants. 🧐

Si le code pouvait nous parler...

Recommençons avec une autre métaphore anthropomorphique. Imaginez un instant que votre logiciel soit une entité vivante, dotée de capacités cognitives, et que vous puissiez l'interroger sur sa vie et son expérience. Le logiciel vous parlera probablement de choses qui ont de l'importance pour lui, comme les bugs, ses fonctionnalités les plus célèbres, le nombre de clics, les temps d'écriture dans la base de données, la latence du réseau, la taille des écrans des utilisateurs, etc. (Sujets intéressants pour un logiciel, mais probablement un peu moins pour un être humain, ceci dit).

Cette discussion avec le logiciel (ndlr : qui est évidemment au sens figuré), peut en fait être réalisée en analysant les journaux d'application du logiciel. Dans une application web classique, la journalisation de l'activité des utilisateurs peut être réalisée par :

  • Tracer les événements de l'interface utilisateur sur la page web tels que les clics, les glissements, les déplacements, les défilements, sur les boutons, les étiquettes, les formulaires, les onglets, etc.
  • Traçage des appels à distance du côté serveur, tels que les appels à Webservice, les procédures de lecture ou d'écriture de données.

Des deux côtés (i.e. serveur et front), tracer la bonne quantité d'information peut être extrêmement délicat. Suite aux travaux et résultats de recherches antérieures et en particulier de la thèse de Florent Mouysset, nous consacrerons un autre billet entier sur BL.Research sur la manière de réaliser un bon système de traçabilité des logiciels et d'éviter les pièges qui pourraient rendre vos traces totalement inutilisables par la suite.

Néanmoins, le suivi de l'activité des utilisateurs peut s'avérer extrêmement instructif :

  • Statistiques descriptives de base telles que le nombre de clics, les pages les plus visitées. Ceci pourrait être facilement réalisé en utilisant des piles d'analyse de traces modernes telles que Elastic+LogStash+Kibana
  • Rétro-ingénieur graphiques de navigation dans les interfaces utilisateur en fonction des traces frontales
  • Mettre en évidence les chemins les plus empruntés dans le graphe de navigation et des raccourcis potentiels
  • Rétro-ingénieur flux de travail en analysant les appels de procédure du serveur
  • Mettre en évidence flux de travail goulots d'étranglementet les chemins non utilisés

Le phénomène des spaghettis ou le cauchemar des événements entrecroisés

Nous avons travaillé sur un jeu de données provenant d'eGRC, une de nos solutions dédiée à la gestion de l'état civil, des élections, des cimetières, du recensement, de la bibliothèque de formulaires. Notre objectif était d'extraire un modèle de navigation à partir de traces "primaires" présentes dans les fichiers de logs. Comme le montre l'extrait ci-dessous, le format du log est assez simple et facile à lire. Chaque <Liste d'exportation> Le balisage concerne l'ouverture ou la fermeture d'un volet ou d'une fenêtre. Seuls deux types d'événements sont enregistrés.

 fMétrologie>.
        Exportation des données métrologie.
        USER178
        2016-08-29T14:40:39.
    
    
        FBuDG.
        Informations Collectives.
        USER178
        2016-08-29T14:40:37.
    
    
        FBuDG.
        Informations Collectives.
        USER178
        2016-08-29T14:40:25.
        2016-08-29T14:40:29
    
    
        FBuAccueil.
        Bureau d'accueil
        USER178
        2016-08-29T14:40:19.
{
    "agentName" : "TraceAgent",
    "softwareName" : "SeditEGrh",
    "softwareRelease" : null,
    "softwareVersion" : null,
    "userName" : "$SYS$",
    "sessionId" : "C866715C9591DE72D375108AC4D59254",
    "remoteAdress" : "192.168.246.47",
    "type" : "AFTER",
    "className" : "fr.sedit.saas.main.dao.IDaoUtilisateur",
    "methodName" : "findByCode",
    "data" : {
        "param0" : "java.lang.String",
        "returnType" : "classe fr.sedit.saas.main.model.UtilisateurSaas"
    },
    "timeStamp" : "2020-05-04 02:52:17.430 PM"
},
{
    "agentName" : "TraceAgent",
    "softwareName" : "200504.1230",
    "softwareRelease" : "N/A",
    "softwareVersion" : "2020.3-SNAPSHOT",
    "userName" : "ADMIN",
    "sessionId" : "5E897D8432F2E599047911FE39C64120",
    "remoteAdress" : "192.168.246.47",
    "traceType" : null,
    "event" : "ON_CLICK",
    "action" : "SELECT",
    "actionTarget" : "BUTTON",
    "actionTargetClass" : "fr.bl.client.core.refui.base.components.BLImageButton",
    "actionDetail" : "Clic sur un bouton (image)",
    "data" : {
        "title" : "Valider",
        "isEnable" : "true",
        "counter" : "0"
    },
    "timeStamp" : "2020-05-04 02:52:32.501 PM"
}

Cependant, comme les activités humaines ne sont pas linéaires et que les logiciels modernes sont construits avec des comportements asynchrones, la séquence d'ouverture et de fermeture n'est pas parfaite. Une grande majorité d'événements sont entrelacés, certains événements de fermeture sont manquants. Il est également presque impossible de faire des hypothèses temporelles sur la base des horodatages, car nous n'avons aucune idée de la façon dont l'activité est réalisée du côté de l'utilisateur.

Construire des graphes de navigation : un voyage algorithmique

L'analyse des traces a été largement utilisée dans l'industrie pour optimiser les lignes de production dans les entreprises. Cela a conduit à la science de Processus d'exploitation minière qui consiste en l'analyse de la gestion des processus d'affaires basée sur l'utilisation des logs. Nous pouvons faire tout à fait la même chose avec les logs fournis par le logiciel. Au cours de l'année dernière, nous avons travaillé avec le L'équipe SIG dans le laboratoire de l'IRIT à Toulouse pour trouver la meilleure façon de reconstruire le graphe de navigation en analysant uniquement les journaux d'événements des utilisateurs.

Idéalement, le modèle de navigation devrait nous permettre de comprendre la navigation en fonction de ces trois dimensions :

  • La dimension "Modèle" : L'objectif est de construire un modèle permettant de représenter de la manière la plus adaptée le modèle de navigation attendu. Ce modèle de navigation pourrait inclure une dimension d'incertitude liée au fait que seules les traces des fichiers de logs sont disponibles dans un premier temps. Il est attendu que ce modèle puisse autant que possible généraliser les différents fichiers de logs qui pourraient être extraits dans les différentes applications étudiées de Berger-Levrault.
  • La dimension "Volumétrie" : Cet aspect est principalement lié à l'optimisation et à la gestion des " Big-data " auxquelles nous répondons en tant qu'équipe spécialisée dans la gestion des données : parallélisation des traitements sur des plateformes differentes, et si nécessaire, mise en œuvre d'approches de deep learning en fonction des objectifs. Nous adapterons et configurerons les méthodes d'analyse ou d'apprentissage à la structure et au volume des fichiers de logs fournis par Berger-Levrault.
  • La dimension "Interprétabilité" : Dans ce travail, un élément important est la restitution du modèle de navigation à l'utilisateur final. Nous proposons d'associer au modèle d'interaction une visualisation adaptée aux besoins décisionnels. Au-delà de ces éléments tangibles, les résultats attendus se trouvent dans la proposition d'une méthodologie d'analyse des fichiers de logs afin d'extraire un modèle de navigation.

Pour atteindre cet objectif, nous devons identifier les méthodes les plus appropriées pour identifier les scénarios suivis par les utilisateurs dans les deux interfaces logicielles. Nous avons affaire à des journaux côté client (base de données EGRC et événements de type 1 dans SEDIT RH) et à des journaux côté serveur (événements de type 2 dans SEDIT RH). Si nous considérons notre problématique comme un problème d'exploration de processus, nous sommes dans l'aspect de découverte de processus (voir figure 1.1). Comme les journaux ne sont pas étiquetés, des méthodes comme les algorithmes génétiques ou les LSTM (voir figure 1.1) ne conviennent pas.

Si nous considérons notre problème du point de vue du web mining, nous pouvons nous référer aux techniques de web usage mining. En effet, nous ne disposons pas de données relatives à la structure ou au contenu des applications que nous avons analysées (logs). Nous avons donc suivi le schéma classique du processus de Web usage mining, à savoir les phases de (i) prétraitement, (ii) découverte de motifs, et (iii) analyse de motifs. On peut considérer la question comme une "caractérisation de l'usage" plutôt qu'une "amélioration du système", une "personnalisation" ou une "modification". Après avoir étudié notre problématique et comparé les différentes méthodes identifiées dans la littérature dans nos expériences, nous avons convenu d'identifier les méthodes suivantes comme pertinentes pour les logs disponibles :

  1. Extraction d'éléments fréquents
  2. Incorporation de mots
  3. Algorithme de fourmis
  4. Réseaux de pointeurs

Outre ces méthodes, nous avons testé d'autres stratégies et heuristiques pour générer le graphe de navigation à partir des journaux. Par exemple, nous avons combiné le graphe généré par les différentes méthodes en appliquant les stratégies d'union et d'intersection. Cela nous permet de renforcer notre confiance dans les graphes de navigation générés, étant donné que si plusieurs techniques fournissent les mêmes liens entre les nœuds, cela augmente la probabilité que ces liens existent réellement.

Graphiques de navigation générés pour eGRC/

Au final, comme le montre la figure ci-dessus, nous obtenons des graphes de navigation très intéressants, dont la forme et l'allure avaient du sens. Notre prochaine étape consiste à valider une quantité statistiquement significative de liens pour évaluer les différents algorithmes et choisir l'approche fournissant les meilleurs résultats. Ces techniques seront également appliquées sur tout frais traces générées par les dernières campagnes de test de SEDIT-RH.

La suite dans notre prochain épisode...

Plus ...

Retour en haut