En deux mots

Choisissez des données, n’importe lesquelles, et faites quelque chose avec !

Consignes détaillées

Le but de ce projet est de démontrer les compétences que vous avez acquis durant l’UE en les appliquant à un nouveau jeu de données. Ce dataset sera un jeu de données préexistant que vous aurez sélectionné, il peut correspondre à un sujet qui vous tient à coeur, qui a été abordé dans d’autres cours ou qui vous semble simplement intéressant à analyser.

L’objectif de ce projet n’est pas d’effectuer une analyse statistique appronfondie en appliquant aveuglément chaque méthode et visualisation étudiée à chaque donnée du dataset ! Je souhaite plutôt que vous me montriez que vous êtes à l’aise avec les techniques et méthodes que nous avons découvertes ensemble, et que vous vous posiez des questions pertinentes pour ensuite y apporter les réponses adaptées grâce à la visualisation de données.

Pour cela il faut que vous formuliez un ensemble de questions auxquelles vous souhaitez répondre grâce au jeu de donnée. Pour chaque question :

• Formulez la question
• Trouvez les meilleures méthodes/visualisations/graphiques pour y répondre
• Expliquez et argumentez pourquoi cette solution est adaptée
• Appliquez-là et commentez les résultats de votre visualisation. N’hésitez pas à critiquer ces résultats, ce qui pourra donner un nouveau cycle : choix de méthode > application > commentaire du résultat

N’hésitez pas à être critique vis-à-vis des résultats obtenus, il n’y a aucun mal à dire que “les données ne permettent finalement pas de répondre à cette question” si vous argumentez ! Votre recul sera au contraire valorisé dans la note du projet.

Outils

Le projet est très ouvert sur les outils utilisés, toutefois vous êtes limités à l’utilisation de R, et je dois pouvoir compiler moi-même votre projet sur ma machine personnelle. Vous pouvez utiliser tout les packages que vous souhaitez, par contre il est impératif que les packages vus en cours (tibble, dplyr, ggplot2, shiny, shiny_dashboard) soient utilisés.

Il est important que votre code ET vos visualisations soient : clairs, cohérents, compréhensibles et lisibles. Pour cela, commentez le code là où il est complexe et utilisez tous les outils utiles pour un graphe (titre, légende, échelles…).

Données

Le choix du dataset sera crucial pour la bonne conduite de ce projet. Dans cette optique, il est absolument essentiel que votre jeu de données soit facilement manipulable et assez grand pour permettre des analyses intéressantes. Il devra être composé d’un grand minimum de 50 observations et de 10 à 20 variables. Si vous souhaitez déroger à ces minimums/maximums, contactez-moi d’abord afin que nous en discutions. Enfin les données peuvent être discrètes, continues ou catégorielles. Aucun des jeux de données utilisés durant le cours ne pourra être sélectionné pour le projet.

Ci-dessous quelques sources qui peuvent vous permettre de trouver des datasets. N’hésitez pas à chercher ailleurs, ce ne sont que des suggestions et je vous encourage à chercher vous-même des données intéressantes (on peut en trouver partout !) :

• TidyTuesday
• Kaggle
• Data.gouv
• OpenIntro datasets
• Awesome public datasets
• UCI ML repository
• Harvard Dataverse

Livrables

1. Proposition
2. Présentation
3. Rapport écrit

Les livrables seront tous à rendre via votre repository Github, selon l’organisaiton suivante :

• /data/ : Le dossier qui doit comprendre toutes vos données
• /shiny/ : Le dossier incluant tout le code de votre Shiny app
• README.md : La proposition de projet décrivant les données
• rapport.Rmd + rapport.html : Le résumé écrit de votre travail
• presentation.pdf : Les slides utilisées lors de la présentation

Proposition

La proposition est à formuler dans le fichier README.md de votre repository de projet. Utilisez la syntaxe Markdown pour rajouter de la mise en forme (gras, italique, liens, …) et des sections et sous-sections. Vous créerez une section Introduction, composée de deux sous-sections avec ce contenu :

• Données : Vos données décrites en détails avec le nombre d’observations et de variables, et le type des variables. D’où viennent-elles, pourquoi les avez-vous choisies, dans quel contexte s’intègre-elles ? Quel est leur format ? Y a-t-il des catégories ou des sous-groupes au sein des données ?
• Plan d’analyse : Sans écrire la moindre ligne de code, élaborez sur les questions que vous souhaitez vous poser sur les données. Quelles sont vos interrogations ? Quelles informations pensez-vous obtenir ? Quelles variables souhaitez-vous comparer ? Qu’est-ce qui pourrait poser problème ? Autrement dit : comment comptez-vous analyser ces données ?

N’oubliez pas de mettre vos données dans le dossier prévu à cet effet.

Rapport écrit

Afin de laisser une trace écrite de vos travaux, vous devrez rendre pour la fin du semestre un rapport écrit de votre analyse exploratoire de données. Le rapport s’articulera selon les parties suivantes :

• Introduction : Cette partie a déjà été rédigée lors de votre proposition (données et plan d’analyse), et il s’agit juste de la remettre ici en la mettant en page.

• Exploration : La partie principale du rapport. Ici vous répondez aux questions émises durant la phase de proposition et vous en formulez de nouvelles afin d’explorer les données. Cette partie est détaillée juste en dessous.

• Conclusion : Un résumé bref (une page grand maximum) comprenant ce que vous avez pu apprendre sur le jeu de données, les difficultés éventuelles et des pistes pour étendre ou élargir le travail effectué. Vous terminerez avec une à deux phrases par membre du groupe, où chacun exprimera la compétence qu’il a retenu de ce projet et un aspect qu’il aurait été intéressant d’aborder dans ce projet mais qu’il n’a pas été possible d’effectuer (par manque de temps, de données, de technologie non vue en cours etc…).

• Annexe : Une annexe d’une page précisera quel membre a effectué quelle partie du travail, en expliquant la répartition au sein du groupe. La temporalité n’est pas obligatoire, l’important est de documenter le travail effectué par chacun : en cas de désaccord les commits Github permettront de vérifier la répartition réelle.

Partie exploration

Le gros de votre rapport sera composé par la partie exploratoire. Ici vous allez dérouler votre raisonnement vis-à-vis de l’exploration des données. Vous commencerez, si vous avez eu besoin de cette étape, par expliquer les traitements qui ont été nécessaires pour nettoyer les données et fusionner différentes sources de données. Ensuite vous répondrez aux questions que vous avez soulevées dans votre proposition, et à toute nouvelle question qui se poserait durant votre analyse.

Pour y répondre, suivez toujours le modèle suivant :

1. Exposer la question que l’on se pose ou le problème étudié et l’éventuelle réponse que l’on imagine trouver.
2. Insérer la ou les visualisations adaptées, en prenant soin de mettre sur chaque graphique les informations nécessaires pour le comprendre (légende, titre, labels des axes etc).
3. Interpréter les graphiques : répondent-ils à la question ? Si oui par quelle réponse ? Si non pourquoi ? Cela amène-t-il à d’autres questions ? Dans le dernier cas, on recommence le processus.

Un exemple très bref à partir du jeu de données diamonds étudié en TD :

…Nous pouvons ensuite imaginer qu’il y a une corrélation entre le prix des diamants et leur carat, l’un étant probablement facteur de l’autre. [insérer un scatter plot de ces deux variables] On constate une corrélation très forte, avec toutefois une trend qui plafonne à partir du carat X. Visiblement d’autres critères entrent en jeu pour ces diamants les plus chers, nous pouvons donc les sélectionner et analyser les autres variables…

L’exemple est un cas très simple, mais il donne idée de la manière dont doit se structurer une question : le rapport est une suite de question > graphique > réponse > question… Il doit s’organiser comme une enquête, et se lire selon un fil conducteur logique. Pensez donc à le séparer en différentes parties si vos questions portent sur plusieurs thèmes différents, ou plusieurs types d’analyses.

Application Shiny

Afin de démontrer votre capacité à utiliser le framework Shiny ainsi que shinydashboard, il vous est demandé de rendre une application shiny, dans un dossier du même nom. Cette application shiny sera similaire en envergure à celle vue lors du cours d’introduction au package Shiny, et elle devra contenir des éléments interactifs (et non juste des graphiques qui auraient pu être intégrés dans le rapport directement).

Dans votre rapport, vous intégrerez des screenshots des graphiques de cette application et les commenterez comme tous les autres graphiques du rapport : en résumé, il s’agit simplement de remplacer dans votre rapport quelques graphiques faits avec ggplot2 par des graphiques créés avec shiny et screenshotés puis insérés. Vous n’oublierez donc pas de les commenter et analyser au même titre que les autres, en précisant bien que ces figures n’ont pas été générés directement dans le rapport mais dans l’application Shiny, permettant ainsi au lecteur d’aller voir l’application Shiny pour pouvoir interagir avec ces graphiques.

Format du rendu

Le rendu est à effectuer au format Rmarkdown. Un unique fichier .Rmd comprendra tout votre rapport et devra être compilable en HTML. Le Rmarkdown doit être autonome et pouvoir être compilé entièrement sans erreurs, la seule chose à ne pas inclure dedans est l’installation des packages. Ce fichier Rmarkdown sera commit sur votre repository git.

Présentation

Le projet se conclue par une présentation orale de 15 minutes, suivie de 5 minutes de questions. Cette présentation peut être effectuée par un seul des membres ou par le groupe entier, au choix, et elle aura lieu durant la dernière semaine de CM+TD.

Le but de cette présentation est de résumer, en un quart d’heure, le travail effectué et les découvertes les plus intéressantes lors de l’exploration des données. La présentation doit agir comme un résumé donnant envie de se plonger dans le rapport si l’on souhaite en découvrir plus, il ne s’agit pas de faire une présentation exhaustive. Sélectionnez donc les visualisations les plus pertinentes, celles contenant le plus d’informations, les informations les plus intéressantes ou les visualisations les plus techniques.

La présentation se fait en respectant les contraintes suivantes :

• Il est important de consacrer quelques slides à l’introduction du sujet, le contexte et le dataset choisi afin de permettre une compréhension aisée du reste de la présentation.
• 15 slides maximum, pas de slides de transition ni de plan de la présentation.
• 1 slide devra être consacrée aux réalisations faites avec Tableau et aux avantages/inconvénients de l’outil dans votre cas d’utilisation.
• Les slides sont à commit, au format PDF, sur votre repository git.

En deux mots

Afin de pouvoir suivre votre progression durant le semestre et vous accompagner plus facilement, un système d’évaluation par les pairs est utilisé dans l’UE. Il comprend plusieurs phases chronologiques qui sont détaillées ci-dessous.

La plateforme ChallengeMe est utilisée pour l’évaluation par les pairs, le lien est disponible sur Moodle. Les dates clés sont résumées en haut de cette page.

Phase 1 - Dépôt du livrable

Fin le 05 mai.

Durant cette première phase, vous devez avancer en groupe sur les premiers éléments de votre analyse de données afin de constituer un premier livrables avec vos analyses. Voici les étapes attendues ce livrable :

1. Créez un fichier rapport.Rmd.
2. Copiez dedans, comme introduction, la présentation du jeu de données que vous avez réalisé dans le fichier README de votre repository Github.
3. Dans votre rapport, commencez l’analyse du dataset en répondant à au moins 4 questions. Référez-vous à la section “Partie exploration” de ce site (ci-dessus) pour savoir quelle structure utiliser pour vos analyses.
4. Uploadez au format PDF sur ChallengeMe votre rapport contenant les premières questions. Vous pouvez générer un PDF directement depuis RMarkdown ou (plus simple) exporter la version HTML de votre rapport en PDF. Le lien pour ChallengeMe est diponible sur Moodle.

Phase 2 - Évaluation des membres de votre groupe

Début le 06 mai et fin le 19 mai.

Cette phase est divisée en deux grandes étapes, il est important de les réaliser dans l’ordre :

1. Séparément, chaque membre du groupe doit évaluer (anonymement) les autres membres de son équipe afin que chacun d’entre vous ai un retour sur sa participation au projet et son implication. Cette évaluation se fait via ChallengeMe.
2. Vous devez, avant la fin de cette période, prendre rendez-vous (environ 20 minutes) avec votre chargé.e de TD pour faire un bilan de votre avancée sur le projet. Certains CM et TD d’IF36 seront annulés pour vous libérer des créneaux afin d’effectuer ce suivi, mais vous pouvez faire votre suivi en dehors des créneaux habituels de l’UE. C’est à vous de contacter pour chargé.e de TD pour trouver un créneau de rendez-vous durant cette période.

Veillez bien à ce que chaque membre, individuellement et séparément, ai terminé l’évaluation anonyme des pairs avant votre rendez-vous de suivi.

Phase 3 - Évaluation des travaux des autres groupes

Début le 20 mai et fin le 02 juin.

Dans cette courte étape, votre livrable est partagé aux autres groupes afin d’être évalué, et vous devez évaluer les livrables des autres équipes.

1. Séparément, chaque membre doit se connecter sur ChallengeMe et évaluer le livrable d’une autre équipe.

Phase 4 - Évaluation des feedbacks reçu

Début le 03 juin et fin le 16 juin.

Cette étape finale permet d’évaluer les feedbacks reçus : sont-ils pertinents ? Adaptés et clairs ? Ont-ils été utiles pour vous ?

1. Vous devez vous connecter sur ChallengeMe pour évaluer les feedbacks reçus.

Félicitations, vous avez terminé la phase d’évaluation par les pairs !

Enseignement

Semaine type

• Mardi matin : Cours magistral pour aborder un nouveau sujet
• Mardi et mercredi aprèm : Travaux dirigés pour mettre en pratique les notions du CM
• Mercredi et vendredi midi : Créneau pour le tutorat pour les questions sur le CM/TD

Voir les heures en haut de la page.

Tutorat

Le mercredi et vendredi midi de chaque semaine de cours, un créneau de tutorat est ouvert de 13h à 14h. Vous pouvez réserver un créneau directement sur mon site via le bouton “Book an appointment”, ou par email auprès de votre chargé de TD.

Ce créneau permet d’échanger de vive voix, à l’UTT ou à distance selon le contexte, afin d’évoquer les sujets trop complexes pour être discutés à l’écrit ou trop longs pour être discutés à la fin des séances de cours. C’est le moment idéal pour aborder les questions complexes ou les difficultés que vous rencontrez dans le suivi du cours ou dans la réalisation de votre projet. N’hésitez pas à solliciter votre encadrant de TD sur ces créneaux pour toute question, pensez juste à bien prendre rendez-vous d’abord.

Travaux dirigés

Les travaux dirigés ont lieu chaque semaine, le mardi ou mercredi, en groupe de 20 étudiants. Ils portent sur le sujet évoqué durant le CM de la semaine et il sera toujours considéré que vous avez suivi le CM avant de venir en TD. Si vous deviez manquer le CM, merci de me tenir informé afin que je puisse vous transmettre les éléments et supports éventuels vous permettant d’être prêts au moment de votre TD.

Concernant l’environnement de travail, la plupart des séances nécessiteront un environnement de développement R fonctionnel. Il est conseillé d’avoir une installation à jour de R et RStudio sur sa machine, ainsi qu’avoir déjà installé les éventuels packages mentionnés durant le CM. Si votre environnement est défaillant, il existe une alternative en ligne, RStudio Cloud, qui est un peu moins pratique mais permettra de suivre les TDs dans la plupart des cas.

Git et Github sont aussi utilisés pour tous les TDs ainsi que pour le projet, et il donc impératif que vous ayez un client Git fonctionnel et un compte sur Github. N’oubliez pas que vous pouvez bénéficier du pack Github Education avec un accès gratuit à Github Pro et d’excellents logiciels (client git GitKraken, IDE Jetbrains, crédits AWS ou DigitalOcean…).

Notes

Votre participation et votre implication dans cette UE seront évaluées sur 100, selon les critères de notation suivants :

L’évaluation est principalement basée sur la conduite d’un projet durant tout le semestre, dont les consignes détaillées sont disponibles sur cette page. Il y a un médian (avec note éliminatoire à 8) mais pas de final. La participation sera évaluée par des activités durant les CM, lors de l’évaluation par les pairs ainsi que selon votre assiduité.

Divers

Réutilisation et partage de code

Le web dispose de grands volumes de code partagé librement et il est important de savoir tirer parti des ressources déjà disponibles. Ainsi la règle générale de cette UE est que vous êtes libres, à part mention contraire, de réutiliser du code trouvé sur Internet à condition d’explicitement citer la source en commentaire avec le code (e.g. “Code extrait du sujet Stackoverflow URL"). Tout code qui est recyclé sans que ce soit clair sera considéré comme du plagiat et traité en tant que tel. Vous devez citer la source du code quel que soit le contexte (projet ou TD). Il en va de même pour les informations utilisées dans votre rapport : utiliser des ressources extérieures est valorisé dans la note de rapport, à condition que les sources soient citées dans le rapport.

En TD vous ête invités à collaborer et vous entraider afin de résoudre les exercices, vous pouvez donc librement partager entre vous du code que vous avez rédigé. Pour le projet par contre, vous ne pouvez pas échanger de code entre vous même en le citant, là aussi cela sera considéré comme du plagiat. Le travail de projet est propre à chaque groupe.

Lectures

Documentations

• Tidyverse (GGplot2 et autres)
• Rmarkdown
• Shiny

Livres

• W3 School R tutorial
• R for Data Science
• Datascience in a box

Outils

• R
• RStudio
• Github
• RStudio.cloud

Cheatsheets

• RStudio
• Readr
• Dplyr
• GGplot2
• Rmarkdown
• Shiny