Bonjour à tous. Merci de me rejoindre aujourd'hui. Je vais vous présenter un exposé sur un projet auquel j'ai participé, intitulé « Du développement aux tests : le parcours de création et de validation d'un module complémentaire JMP ».
Quelques mots sur moi. Je suis doctorant en sciences mathématiques à l'université de Clemson, aux États-Unis. Mes recherches portent sur la conception expérimentale et l'apprentissage des préférences. Depuis l'été 2024, je suis stagiaire au sein de l'équipe DOE et fiabilité de JMP. J'y ai travaillé sur des projets liés à l'expérimentation sur les choix discrets et aux tests logiciels, deux domaines assez différents. Voilà pour ma présentation.
Je vais commencer par un aperçu de la présentation d'aujourd'hui. Dans un premier temps, je vais vous expliquer ce qui nous a motivés à créer cette extension que nous avons développée cet été. Nous menions des études d'utilisabilité pour le programme EasyDOE de JMP, afin de mieux comprendre les préférences d'interface utilisateur des différents groupes démographiques de notre base d'utilisateurs. Ensuite, je présenterai l'extension et vous en ferai une démonstration. Enfin, j'aborderai brièvement les tests effectués avec le framework de tests unitaires JSL pour valider l'application et l'extension que nous avons créées.
Voici la première section : la motivation derrière la création de notre module complémentaire. Comme certains d'entre vous le savent peut-être, JMP intègre un programme appelé Easy DOE. Ce programme est conçu pour accompagner les utilisateurs tout au long du processus de conception et d'analyse d'une expérience. Le flux de travail d'Easy DOE comprend plusieurs étapes. L'expérimentateur commence par définir les facteurs et les réponses qui l'intéressent. Il sélectionne ensuite le modèle qu'il souhaite utiliser pour analyser les données collectées. Enfin, il conçoit une expérience adaptée à ce modèle.
Une fois l'expérience conçue, ils peuvent la réaliser et saisir les données recueillies dans l'onglet « Saisie des données ». Après la collecte des données, ils peuvent analyser le modèle, l'ajuster et l'utiliser pour effectuer des prédictions et sélectionner les paramètres optimaux, s'ils le souhaitent. Enfin, ils peuvent consulter un rapport de synthèse du modèle.
Aujourd'hui, nous allons nous intéresser plus particulièrement à l'onglet « Analyser ». Comme certains d'entre vous qui utilisent Easy DOE le savent, cet onglet ressemble à ceci (voir figure 2). Cet été, nous avons cherché à identifier les modifications à apporter à certains éléments de cet onglet afin d'améliorer son ergonomie pour les expérimentateurs et les utilisateurs d'Easy DOE. Nous avons finalement proposé plusieurs versions de l'interface utilisateur, que les utilisateurs peuvent consulter, et nous souhaitions savoir laquelle était la plus appréciée.
L'interface utilisateur, telle que nous l'avions conçue, suivait une structure factorielle. L'élément qui nous intéressait particulièrement était l'infobulle. Celle-ci affichait différents messages informant l'utilisateur sur certaines propriétés statistiques de son modèle. Parmi ces messages, on trouvait notamment le message « Saisie », indiquant si un terme avait été saisi dans le modèle (nous avions deux versions différentes), le message « Signification », indiquant si le terme était significatif ou non, et le message « Hérédité », expliquant pourquoi un terme non significatif avait été inclus dans le modèle.
Souvent, il existe une propriété appelée hérédité : si un terme d'interaction est significatif, mais que l'effet principal ne l'est pas, on inclura tout de même l'effet principal. Enfin, un dernier facteur à prendre en compte pour le paramétrage de l'aide contextuelle est son emplacement : est-elle affichée au-dessus d'un intervalle de confiance ou au-dessus de la colonne d'aperçu ?
Nous souhaitions savoir lequel de ces paramètres les utilisateurs préféraient. Comme je le disais, nous avions quatre facteurs. Deux ou trois de ces facteurs comportaient deux niveaux, et le quatrième en comportait trois. Il y avait donc jusqu'à 24 versions différentes possibles de l'interface utilisateur pour les paramètres d'aide contextuelle.
Par ailleurs, EasyDOE est souvent utilisé par des personnes novices ou ayant une expérience modérée en conception d'expériences. Cependant, certains utilisateurs sont également expérimentés et l'utilisent à titre personnel ou pédagogique. Nous avons donc identifié différents groupes d'utilisateurs. Nous souhaitions connaître leurs préférences en matière d'aide contextuelle afin d'adapter cette aide à chacun.
Nous avons choisi d'aborder ce problème à travers le cadre de l'expérimentation contextuelle par choix discret. Je vais vous expliquer brièvement en quoi consiste ce cadre. Tout d'abord, parlons du processus de collecte des données. Dans ce type d'expérimentation, on dispose d'un groupe de participants et de certaines informations les concernant, appelées covariables ou informations contextuelles. Il peut s'agir, par exemple, de données démographiques sur les utilisateurs.
Dans ce cadre, nous soumettons les différents participants à un questionnaire où, pour chaque question, ils sont invités à comparer deux ou plusieurs modèles et à choisir celui qu'ils préfèrent. Le processus de collecte de données est assez intuitif et reflète la manière dont les gens font leurs choix dans la vie réelle.
Je vais maintenant aborder la modélisation et l'analyse dans le cadre d'expérimentations contextuelles à choix discret. Une fois les données collectées, vous pouvez ajuster un modèle d'utilité qui prend en compte non seulement les facteurs liés à l'objet d'étude (ici, les paramètres d'aide contextuelle), mais aussi les informations contextuelles fournies par les participants. La combinaison de ces deux éléments permet de cerner les préférences des différents utilisateurs, issus de divers groupes démographiques, concernant les différents paramètres d'aide contextuelle. Enfin, ce modèle d'utilité ajusté vous permettra de déterminer les interfaces d'aide contextuelle les plus appréciées par chaque groupe démographique.
Un élément essentiel des expériences de choix discret contextuelles réside dans leur conception. Comment sélectionner les questions à poser aux participants ? Si vous êtes familier avec les expériences de choix discret classiques, vous savez que, pour concevoir une expérience de choix discret efficace, il est souvent nécessaire de disposer d'informations préalables sur les préférences des utilisateurs.
Dans le cadre d'expérimentations contextuelles sur les choix discrets, nous commençons par une étude préliminaire. Nous sélectionnons un certain nombre de participants et recueillons leurs informations contextuelles et démographiques. Nous leur soumettons ensuite un questionnaire afin de recueillir leurs données de préférence. À partir de cette étude préliminaire, nous ajustons un modèle qui caractérise les préférences des utilisateurs. Ce modèle nous permet ensuite de comprendre les préférences au sein de différents groupes démographiques.
Ainsi, ce modèle nous permet de définir des distributions a priori bayésiennes, lesquelles peuvent servir à concevoir des plans d'expérience D-optimaux pour le questionnaire. Nous pouvons ensuite créer des questionnaires adaptés à chaque groupe démographique, afin d'obtenir plus d'informations statistiques de manière plus efficace. C'est la méthodologie que nous souhaitions adopter pour résoudre ce problème. Notre objectif était de concevoir des questionnaires statistiquement très performants à soumettre à nos participants, afin de recueillir plus efficacement des informations et de mieux comprendre les préférences des différents groupes démographiques.
Je vais vous parler brièvement de la création de ce module complémentaire. Tout d'abord, pour ceux qui ne le savent pas, JSL signifie JMP Scripting Language (langage de script JMP). Il permet d'étendre les fonctionnalités de JMP en offrant la possibilité d'effectuer de nombreuses opérations, comme l'exécution d'analyses multi-étapes de routine ou l'ajustement d'un modèle spécifique aux données générées quotidiennement. JSL permet donc d'étendre considérablement les fonctionnalités de JMP. Un module complémentaire JMP est un script JSL qui étend les fonctionnalités de JMP et que les autres utilisateurs de JMP peuvent télécharger et utiliser.
Pourquoi avons-nous créé un module complémentaire JMP pour résoudre notre problème spécifique ? Tout d’abord, nous menions plusieurs études d’utilisabilité. Nous réalisions la même étude, celle portant sur l’aide contextuelle, à différents moments. Nous recueillions de plus en plus de données au fil du temps, que nous utilisions pour affiner nos protocoles expérimentaux et les questionnaires envoyés aux utilisateurs. Nous menions également différentes études d’utilisabilité, par exemple en faisant varier divers éléments de l’interface utilisateur. Ainsi, l’une de ces études portait sur les couleurs et l’emplacement des notifications dans l’onglet Analyser.
Une autre raison de la création de ce module complémentaire était que la conception de ces expériences de choix discrets contextuelles pouvait s'avérer fastidieuse, car il était souvent nécessaire de calculer les moyennes a priori et les matrices de covariance pour créer les plans d'expérience bayésiens D-optimaux pour chaque groupe. Nous avons constaté que ce processus pouvait être automatisé grâce à des scripts JSL.
Enfin, ce cadre d'expérimentation contextuelle par choix discret peut être utilisé pour une très large gamme de tâches de choix. Il ne se limite pas aux études d'utilisabilité, mais s'applique à tout type d'étude nécessitant que les utilisateurs expriment leurs préférences parmi plusieurs options. Nous avons créé ce module complémentaire non seulement pour nous faciliter la tâche, mais aussi pour permettre à d'autres de l'utiliser pour résoudre leurs propres problèmes.
Je vais vous parler brièvement du fonctionnement de notre module complémentaire de choix discret contextuel. Tout d'abord, l'utilisateur ou l'expérimentateur doit recueillir des données à partir d'une étude préliminaire. Cette étude doit inclure des informations telles que : quelles questions avez-vous posées aux participants ? Quels étaient les attributs ? Les attributs du profil ? Les facteurs de l'objet d'étude, ainsi que les covariables des sujets ?
Une fois ces données recueillies, un modèle de sélection leur est appliqué. Dans ce modèle, l'expérimentateur doit spécifier les effets de profil (dans notre cas, les paramètres d'aide contextuelle) ainsi que les effets liés au sujet. Cela permet à l'expérimentateur de créer un modèle d'utilité, lequel est ensuite estimé à l'aide de la plateforme d'analyse des choix de JMP.
Une fois cette étape franchie, l'utilisateur sélectionne un groupe démographique pour une étude plus approfondie. Pour ce faire, il choisit les niveaux des effets ou facteurs contextuels propres à chaque sujet. La combinaison de ces niveaux définit le groupe à étudier. Une fois ce groupe sélectionné, un plan d'expérience bayésien D-optimal ou un questionnaire bayésien D-optimal est élaboré spécifiquement pour ce groupe, permettant ainsi à l'expérimentateur de l'étudier de manière statistiquement efficace.
Je vais maintenant vous présenter le module complémentaire d'expérience de choix discret contextuel. J'ouvre JMP et je me rends dans mes modules complémentaires. Je sélectionne le tableau de données. Ce tableau contient des informations… Je vais vous en montrer rapidement un aperçu. Ce tableau présente les résultats d'études d'utilisabilité réalisées précédemment pour l'aide contextuelle. Vous pouvez constater que nous avons des informations telles que : quelle option l'utilisateur a-t-il choisie ? Quelles options lui ont été proposées ? Nous disposons également d'informations contextuelles sur l'utilisateur, comme son niveau d'expérience en conception d'expériences, ainsi que la raison pour laquelle il utilise Easy DOE : pour un usage personnel ou pour former d'autres personnes ?
Ici… je vais ouvrir cette section. Nous allons d'abord saisir l'indicateur de réponse, c'est-à-dire le choix de l'utilisateur, puis définir l'identifiant de l'ensemble de choix et les identifiants du sujet. Ensuite, nous pouvons saisir les effets de profil, qui, dans notre configuration, correspondent aux trois messages affichés à l'emplacement de l'infobulle. Si besoin, nous pourrions ajouter des effets d'interaction. Mais pour l'instant, je vais me contenter d'un modèle d'effets principaux. Nous pouvons également ajouter des effets de sujet, comme le niveau d'expérience et le fait que les utilisateurs enseignent ou utilisent Easy DOE à titre personnel.
Vous pouvez constater que de nombreuses informations ici ressemblent à la configuration de la plateforme d'analyse des choix. Lorsque nous cliquons sur « Exécuter », la plateforme d'analyse des choix s'ouvre en arrière-plan et analyse le modèle de sélection pour l'étude. Bien entendu, nous pouvons interagir avec elle de la même manière qu'avec la plateforme d'analyse des choix. Par exemple, nous pouvons afficher un profil d'utilité et constater que les utilisateurs expérimentés, qui forment d'autres personnes, préfèrent nettement une certaine option pour le message sur l'hérédité, à savoir cette deuxième alternative.
Une fois cette étape franchie, nous pouvons accéder à ce composant qui nous invite à sélectionner un groupe démographique pour une étude plus approfondie. Imaginons que je mène des études sur les utilisateurs experts d'Easy DOE, c'est-à-dire ceux qui maîtrisent la conception d'expériences et qui m'intéressent particulièrement lorsqu'ils forment d'autres personnes. Je souhaite alors créer un questionnaire pour connaître les préférences de ces utilisateurs experts. En cliquant sur « Créer une conception », la plateforme « Conception par choix » s'affiche, important automatiquement les informations saisies lors de l'analyse des choix ou de l'étude de sélection.
Nous disposons de nos attributs et de notre modèle pour ce groupe spécifique ; il s’agit d’un modèle à effets principaux que nous avons défini. L’élément essentiel est que, grâce au modèle issu de l’étude de sélection, nous avons pu calculer les distributions a priori bayésiennes pour la moyenne et la variance a priori du groupe que nous souhaitions étudier.
Une fois cette information a priori créée, nous pouvons générer un plan d'expérience bayésien D-optimal en cliquant sur « Créer un plan ». Nous obtenons alors un plan adapté au groupe spécifique étudié. Sa construction a en effet pris en compte les informations a priori dont nous disposions sur les préférences de ce groupe. Ce plan est donc parfaitement adapté au groupe que nous souhaitons étudier plus en détail. Voilà pour ma démonstration du module complémentaire d'expérimentation contextuelle par choix discret. Je vais maintenant fermer ces fenêtres et revenir à nos diapositives.
Pour terminer, le dernier point que j'aborderai concerne les tests de l'extension à l'aide du framework de tests unitaires JSL. Pour ceux qui ne connaissent pas les tests unitaires, qu'est-ce que c'est ? Il s'agit de tester chaque composant d'une application logicielle afin d'identifier les erreurs. Plus précisément, les tests unitaires automatisés permettent d'exécuter régulièrement des tests unitaires sur une application logicielle afin de détecter et de corriger les erreurs introduites au cours du développement.
JMP dispose notamment d'un framework de tests unitaires appelé framework de tests unitaires JSL, spécialement conçu pour les applications JSL. La fonction principale de ce framework est `ut assert`, qui permet de tester certains composants d'une application JSL. L'utilisateur définit la sortie attendue, c'est-à-dire le résultat qu'il estime correct. Il compare cette sortie à la sortie réelle de son application. Si les résultats correspondent, le test est réussi ; dans le cas contraire, il a échoué. Lorsqu'un script contenant ces fonctions `ut assert` est écrit et exécuté, un rapport est généré, indiquant si tous les tests ont réussi ou lesquels ont échoué, afin de permettre une analyse plus approfondie.
Nous avons testé plusieurs éléments du module complémentaire d'expérimentation de choix discrets contextuels. Par exemple, nous avons testé le bouton en forme de croix permettant d'ajouter des effets d'interaction. Fonctionnait-il correctement ? Nous pensions que si l'on sélectionne deux options et que l'on clique sur le bouton en forme de croix, on sait à quoi cela devrait ressembler. Nous pouvons donc comparer ce résultat avec la sortie réelle afin de nous assurer du bon fonctionnement du système.
Un autre point important que nous avons testé concernait l'affichage d'un message d'erreur lors de la sélection d'un groupe démographique pour une étude plus approfondie. Nous voulions nous assurer que ce message s'affichait si l'expérimentateur laissait une option vide. Nos tests ont confirmé que ce message d'erreur s'affichait correctement.
Enfin, et c'est un point important, nous voulions nous assurer de l'exactitude des informations préalables chargées dans l'outil de conception des choix. Nous avons donc effectué des tests en les comparant aux résultats de la plateforme d'analyse des choix. Si les deux concordaient, nous savions que les informations préalables étaient correctement importées dans l'outil de conception des choix ; en cas de discordance, nous savions qu'il y avait un problème. Heureusement, nous avons constaté que les informations préalables importées étaient correctes.
L'un des aspects les plus importants des tests unitaires automatisés réside dans leur utilisation lors de la refactorisation du code. Les tests unitaires automatisés permettent de refactoriser le code et de vérifier l'absence d'erreurs. Refactoriser le code signifie y apporter des modifications au cours du processus de développement. Comment savoir, lors d'une modification, si vous n'avez pas introduit d'autres problèmes sans lien avec la modification initiale ?
Un exemple concret : lors des tests de ce module complémentaire, un utilisateur a constaté que lorsqu’un facteur contextuel comportait une étiquette de valeur, la liste associée à ce facteur contextuel ne s’affichait pas correctement, voire pas du tout.
Nous avons corrigé cette erreur. Mais nous voulions nous assurer que cette correction n'avait pas engendré d'autres problèmes. Nous avons pu le faire en réexécutant notre script de tests unitaires. Heureusement, après cette exécution, nous avons constaté qu'aucune nouvelle erreur n'était apparue, ce qui a confirmé que nous n'avions rien cassé d'autre. La correction que nous avons proposée pour ce problème d'étiquette de valeur a bien fonctionné, comme vous pouvez le voir à droite de cette image.
Ces tests unitaires sont importants car, premièrement, ils permettent de détecter les erreurs dans votre code. Deuxièmement, ils vous permettent de le refactoriser et de vous assurer de n'avoir introduit aucune autre erreur. Troisièmement, lors des mises à jour de JMP, certains éléments internes et certaines plateformes peuvent évoluer. Grâce à ce script de tests unitaires, vous pouvez toujours tester votre extension lors des mises à jour de JMP afin de vérifier si les modifications apportées à JMP ont eu un impact sur votre extension.
Pour conclure cet exposé, j'ai présenté la problématique de la conception d'expériences de choix discrets contextuelles afin de mieux comprendre les préférences d'interface utilisateur d'Easy DOE auprès de différents groupes démographiques de notre base d'utilisateurs. J'ai ensuite démontré comment le script JSL permet de créer un module complémentaire JMP très pratique pour la construction de ces expériences. Enfin, j'ai souligné l'importance des tests unitaires, que ce soit pendant ou après la création du module complémentaire, pour détecter les erreurs durant et après le développement.
Voilà qui conclut mon intervention d'aujourd'hui. Avez-vous des questions ?
