Discussion

La figure 5.5 montre la fréquence des activités utilisées dans le processus étudié. Nous pouvons voir que les activités de validation sont les plus fréquentes. Cependant, les décisions

Figure 5.6 – Extrait du modèle représentant l’enchaînement des décisions du jury

de validation des semestres deux et trois sont moins fréquentes que les première et quatrième. Cela signifie qu’il existe d’autres moyens d’obtenir le diplôme et signifie également qu’une attention particulière devrait être apportée au parcours d’apprentissage des étudiants au cours de ces deux semestres. Nous pouvons également observer les chemins défaillants les plus fréquents et le fait que les étudiants échouent principalement après le premier ou le deuxième semestre. Un accompagnement devra être fourni par le département d’informatique pour aider les étudiants faibles du premier semestre.

La figure 5.6 présente un extrait du modèle Workflow-Net obtenu. On peut y voir les règles de précédence entre les différents semestres ainsi que les retours en arrière dus aux redouble-ments. Cependant, la complexité structurelle du modèle fait qu’il est difficilement utilisable par un humain et rend une automatisation de son utilisation nécessaire.

Dans l’expérimentation, nous identifions automatiquement les déviations potentielles en vérifiant si l’exécution diffère du chemin recommandé. Si c’est le cas, nous effectuons une recommandation. Cette dernière décrit les décisions du jury que l’apprenant doit obtenir afin d’avoir son diplôme et ce malgré l’écart du chemin recommandé avec le chemin courant. L’exécution décrite dans la recommandation devient ensuite le chemin recommandé.

Chaque recommandation a été vérifiée afin de savoir si l’exécution décrite arrive toujours à :

— respecter les règles de l’IUT, et, — atteindre l’objectif.

Cependant, le modèle n’arrive pas à identifier l’absence totale de solutions. Il propose toujours une recommandation même si celle-ci est basée sur un cas atypique à partir du moment où il a été observé ne serait ce qu’une fois. Par exemple, quand nous cherchons une recommandation pour un étudiant ayant effectué N 2 puis N 3 et ayant déjà redoublé, notre méthode proposera un second redoublement car cela a déjà été observé alors que ce cas était une autorisation

5.5. CONCLUSION 81 exceptionnelle de redoubler une seconde fois pour une raison médicale. Ce système est donc limité par sa connaissance de l’organisation des règles ; il n’intègre que les règles observées et non pas les règles réelles. Par conséquent, il est nécessaire de considérer une étape supplé-mentaire à notre modèle qui interviendrait avant l’étape de recommandation et qui consisterait à enrichir le modèle en associant des connaissances supplémentaires. Cette étape permettrait de contextualiser le modèle obtenu pour le rendre plus précis. Cette étape sera expliquée en détails dans le paragraphe 6.3.3.

Il est à noter que dans cette expérimentation, nous nous sommes concentrés sur la mise en place de la méthode. Les données ont donc été transformées pour correspondre au format Event Log. Les traces ont été traitées par l’algorithme de fouille de processus Inductive Miner. Le Workflow-Net obtenu a été utilisé pour créer des recommandations. Il est possible par la suite de corréler les notes des étudiants avec le modèle pour donner des recommandations plus précises. La mise en place de la méthode dans le cadre des données de l’IUT de La Rochelle permet de montrer l’utilisabilité de la méthode sur un cas concret.

Nous sommes bien conscients que cette expérimentation, un peu naïve dans son analyse et éloignée des processus métiers d’entreprise, nous permet néanmoins de valider la faisabilité de notre méthodologie. Nous montrons qu’il est possible de construire une recommandation (choix de l’activité suivante à réaliser) à chaque fin d’activité en se basant sur un modèle de processus découvert à partir des traces d’exécutions passées.

5.5 Conclusion

Dans ce chapitre, nous avons proposé une méthodologie pour produire des recommanda-tions lors de l’exécution de processus. Nous nous plaçons dans le cas où l’utilisateur dispose de beaucoup de liberté pour réaliser un processus, en fonction de son objectif, en composant des sous-processus ou séquences définies par un expert. Nous proposons donc une démarche et une architecture logicielle qui permettent, à la fin de chaque activité, de proposer l’activité la plus pertinente, vis-à-vis d’un objectif donné, à réaliser.

Notre méthodologie se compose de trois étapes. La première consiste à collecter les don-nées des exécutions puis faire une transformation afin d’obtenir des traces modélisées au for-mat eXtensible Event Stream. La deuxième étape consiste à extraire des connaissances sur les processus passés réalisés par les autres utilisateurs. Pour cela, nous utilisons les algorithmes de la fouille de processus. Cela nous permet de construire un modèle des processus métier. Ces deux étapes se font en amont de l’exécution. La troisième étape se fait en cours d’exécution et consiste à déterminer, à partir du modèle des processus et de la séquence réalisée jusque là par l’utilisateur, quelle activité doit être réalisée pour finir le processus en optimisant des critères préalablement définis.

re-cueillies sur les jurys d’IUT Informatique, que la méthodologie permet de produire des recom-mandations après avoir réalisé les transformations et extractions de connaissances nécessaires. Toutefois, cette expérimentation ne nous permet pas de nous confronter à des processus où l’utilisateur dispose de beaucoup de liberté. De plus, nous souhaitons également que l’archi-tecture que nous proposons soit suffisamment générique pour permettre d’en substituer des éléments afin de les adapter à un autre contexte.

Dans le chapitre suivant, nous allons appliquer la méthodologie sur un cas d’étude pour le-quel aucun processus métier n’a été prédéfini par un expert. Nous allons devoir formuler notre recommandation à partir des informations extraites des exécutions passées. Nous montrons ainsi comment l’on peut adapter notre méthodologie à ce contexte.

CHAPITRE 6 | Application au cas d’étude

« Tamagotchi »

Sommaire

6.1 Introduction . . . 84 6.2 Description du cas d’étude Tamagotchi . . . 85 6.2.1 Motivations . . . 85 6.2.2 Principe du jeu . . . 86 6.2.3 Attributs du Tamagotchi . . . 86 6.2.4 Critères de vie du Tamagotchi . . . 87 6.2.5 Activités proposées au joueur . . . 90 6.2.6 Format des traces . . . 91 6.3 Adaptation de la méthode au cas d’étude Tamagotchi . . . 93 6.3.1 Formalisation de l’approche proposée . . . 93 6.3.2 Impact des activités sur l’évolution des critères . . . 95 6.3.3 Formalisation du contexte dans le modèle de processus . . . 96 6.3.4 Recommandation à partir du modèle de processus enrichi . . . 98 6.4 Expérimentation . . . 100 6.4.1 Paramètres et protocole expérimental . . . 101 6.4.2 Présentation des résultats expérimentaux . . . 102 6.5 Bilan . . . 104 6.6 Conclusion . . . 105

6.1 Introduction

Nous avons proposé une méthodologie pour la recommandation dans les processus métier dans le chapitre précédent. Nous avons terminé ce chapitre en mettant en place notre architec-ture sur un cas d’étude simple. Cette étude nous a permis de démontrer sa faisabilité. C’est-à-dire qu’à partir de traces, nous avons formulé une recommandation qui optimise un critère sur la réalisation du processus métier. Cette recommandation se base uniquement sur les aspects contrôle (l’ordre d’exécution des activités) et ne tient pas compte des données associées ni des données contextuelles.

Dans ce chapitre, nous traitons d’un exemple avec une complexité qui se rapproche des cas que nous souhaitons aborder, à savoir les processus « externalisés par les entreprises1

», les jeux vidéo et l’apprentissage. La particularité de ces applications est que les processus ne correspondent plus à l’exécution d’une procédure rigide, mais offrent de la souplesse à l’uti-lisateur. Par conséquent, les processus produits risquent de varier et de faire apparaître des boucles qui traduisent les hésitations ou méconnaissances de l’utilisateur. De tels processus présentent un caractère non-structuré. Nous allons donc voir comment adapter notre métho-dologie à ce type de processus à travers l’exemple d’un jeu, et présenter comment prendre en compte les données associées et/ou contextuelles.

Le cas d’étude que nous traitons porte sur un jeu inspiré du jeu Tamagotchi. Il s’agit de faire grandir un avatar et faire en sorte qu’il trouve un équilibre entre ses besoins primaires et ses interactions avec les autres. La section 6.2 détaille le fonctionnement de notre jeu, la dynamique associée aux attributs du Tamagotchi (santé, sociabilité et maturité) et le système de traces que nous mettons en place. Nous poursuivons par la présentation de l’expérience que nous allons développer. Le but de notre étude est de valider la robustesse de notre mé-thodologie dans le cas d’un système où l’utilisateur développe seul un/des processus métier. Nous nous plaçons donc dans une situation d’apprentissage où l’apprenant dispose d’un simu-lateur et met en œuvre des stratégies afin d’acquérir des connaissances. Dans la section 6.3, nous décrivons comment nous adaptons notre méthodologie à cette étude de cas. Nous ajou-tons des annotations au modèle, à partir des informations contextuelles, pour l’enrichir. Nous présentons, ensuite, comment nous adaptons le système de recommandation, section 6.3.4.

Nous concluons ce chapitre par la section 6.4 qui présente l’expérimentation que nous avons conduite. Nous y présentons les critères qui permettent de mesurer la qualité de l’exé-cution. Puis, nous présentons notre protocole expérimental. Nous présentons le jeu aux parti-cipants en leur donnant comme objectif d’arriver à cinq victoires en cherchant à minimiser le temps de jeu. Nous avons réalisé notre expérimentation en deux temps avec deux groupes de testeurs différents. Le premier groupe ne bénéficie pas de recommandations. Il constitue ainsi

1. Par processus externalisés, nous entendons des processus définis par morceaux par des applications Web, où l’utilisateur doit construire son processus en composant des sous-processus.

6.2. DESCRIPTION DU CAS D’ÉTUDE TAMAGOTCHI 85