Le mini projet

L’objectif

L’objectif du mini projet est d’éclairer un sujet d’intérêt public (météo, environnement, politique, vie publique, finance, transports, culture, santé, sport, économie, agriculture, écologie, etc…) que vous choisissez librement. Vous utiliserez des données publiques Open Data, accessibles et non modifiées.

l’open data (ou donnée ouverte) est une donnée numérique d’origine publique ou privée. Elle peut être notamment produite par une collectivité, un service public (éventuellement délégué) ou une entreprise. Elle est diffusée de manière structurée selon une méthode et une licence ouverte garantissant son libre accès et sa réutilisation par tous, sans restriction technique, juridique ou financière. Wikipedia.

Le choix du sujet est libre mais doit satisfaire les livrables ci dessous. Il est soumis à validation de l’enseignant.

Remise du travail

Votre travail doit être déposé sur une plateforme de dépôt delon les modalités précisées sur la page de l’unité.

Les livrables

Votre travail sera accessible sous la forme d’un dépôt Git public.

Vous devez produire du code R, structuré en plusieurs fichiers, permettant d’exécuter votre dashboard dans un navigateur standard. Le dashboard contiendra a minima un histogramme et une représentation géolocalisée. Au moins un des graphiques doit être dynamique.

Le code devra recueillir et nettoyer les données, les sélectionner et les organiser pour les représentations graphiques interactives illustrant votre point de vue sur le sujet.

Le code devra être documenté. Il devra être accompagné d’un rapport d’analyse qui met en avant les principales conclusions extraites des données.

A minima, le dépôt contiendra donc les éléments ci dessous.

  • L’ensemble des fichiers nécessaires à son exécution, structurés dans différents répertoires avec les contraintes suivantes :

    • un fichier app.R à la racine du dépôt tel que l’exécution de ce seul fichier construise le dashboard ;

    • les données nécessaires à l’exécution du dashboard stockées localement ;

  • Un fichier README formatté en Markdown renseigné avec :

    • une section « User Guide » qui permet de déployer et d’utiliser votre dashboard sur une autre machine ;

    • une section « Data » qui renseigne sur les données utilisées ;

    • une section « Developer Guide » qui renseigne sur l’architecture du code et qui permet en particulier d’ajouter simplement une page ou un graphique ;

    • une section « Rapport d’analyse » qui met en avant les principales conclusions extraites des données ;

    • une section « Copyright » qui atteste de l’originalité du code fourni. Par exemple :

      • je déclare sur l’honneur que le code fourni a été produit par moi/nous même, à l’exception des lignes ci dessous ;

      • pour chaque ligne (ou groupe de lignes) empruntée, donner la référence de la source et une explication de la syntaxe utilisée ;

      • toute ligne non déclarée ci dessus est réputée être produite par l’auteur (ou les auteurs) du projet. L’absence ou l’omission de déclaration sera considéré comme du plagiat.

    Astuce

    Pour la section « Developper Guide », utiliser mermaid pour fournir l’architecture du code sous forme de graphique. Le graphique est décrit par du texte.

    Pour la programmation impérative (le code est structuré en fonctions appelées depuis le programme principal), fournir un organigramme selon cette syntaxe.

    Pour la programmation orientée objet, (le code est structuré en classes), fournir un diagramme de classes selon cette syntaxe.

    Cet éditeur en ligne permet une visualisation rapide.

  • Un fichier requirements.txt doit contenir la liste des seuls packages additionnels requis tel que la commande ci dessous installe l’ensemble des dépendances nécessaires (et uniquement celles là):

    > install.packages("package_name")

  • une vidéo de démonstration de votre dashboard (3 minutes max, OBS Studio est une solution open source performante). La vidéo doit montrer l’ensemble des fonctionnalités et des interactions du dashboard.

Avertissement

Gardez à l’esprit que votre travail sera déployé dans un contexte différent de celui de votre machine de développement. Après clonage du dépôt et à l’exécution de app.R :

  • le code ne doit pas produire de warnings dans la console ;

  • le dashboard ne doit pas comporter pas d’erreur de call back.

La structure du projet

Au moment du rendu, les fichiers du projet devront être structurés dans différents répertoires. Par exemple:

my_shiny_app/
├── R/
│   ├── global.R
│   ├── server.R
│   ├── ui.R
│   ├── helpers.R
│   └── (additional scripts)
├── data/
│   ├── raw/
│   │   └── raw_data.csv
│   └── processed/
│       └── processed_data.csv
├── app.R
├── README.md
└── .gitignore

Contexte du développement

Le dashboard sera développé avec les versions les plus récentes disponibles au 1er septembre de l’année universitaire :

Les données

Accès

Les données doivent être accessibles publiquement, de façon reproductible, via une ressource statique ou une API publique. Dans tous les cas, le(s) pointeur(s) vers les ressources doi(ven)t être fourni(s) dans la section « Data » du fichier README.md.

Astuce

Il est autorisé d’utiliser Python pour récupérer/nettoyer les données si nécessaire. Dans ce cas, le script de récupération des données devra être fourni dans le répertoire src/utils/ du projet.

Les données brutes seront récupérées sur le web et stockées dans le répertoire data/raw/ du projet.

Les données seront dites « statiques » si elles sont stockées à distance sous la forme d’un fichier au format quelconque (CSV, Excel, JSON, etc.)

Les données seront dites « dynamiques » si :

  • elles sont accessibles sur une page web statique via un processus de scraping ;

  • elles sont accessibles sur une page web dynamique (les données sont générées à la volée par un serveur) ;

  • elles sont accessibles via une API.

Dans le cas de données dynamiques, le dashboard mettra en cache une partie des données avec un mécanisme de rafraichissement.

Si besoin, les données brutes recueillies, pourront être nettoyées et stockées dans le répertoire data/cleaned/ du projet. Dans ce répertoire, les données seront stockées dans un format exploitable par le dashboard.

Structure

Dans la très grande majorité des cas, l’ensemble des données (dataset) est présenté sous la forme d’une (ou plusieurs) page de tableur, dont les lignes sont les OBS observations et les colonnes, les VAR variables (numériques, ordinales ou catégorielles) de ces observations.

Ce dataset doit impérativement posséder les propriétés suivantes:

  • il doit posséder un nombre suffisamment grand d’observations OBS pour que le tracé d’un histogramme ait du sens (typiquement plusieurs centaines). Ainsi les statistiques sur les communes françaises sont éligibles (OBS > 36000), celles concernant les pays conviennent (~ 200, variable selon les sources) mais celles concernant les département français ne conviennent pas (OBS < 100) ;

  • parmi l’ensemble des données VAR disponibles sur chacune des lignes, l’une au moins doit être numérique et non catégorielle. Une donnée non catégorielle posséde une relation d’ordonnancement (plus petit que, plus grand que). Exemple : la pression atmosphérique, le poids, le coût, le nombre, etc… Attention à l’utilisation de l’année comme donnée numérique, le plus souvent cette dernière est utilisée comme donnée catégorielle ;

  • les observations devront pouvoir être géolocalisées. Exemple : la température mesurée pour plusieurs stations météo, la taille relevée dans des zones géographiques différentes, le point de chute de météorites, etc.. Soit directement si les coordonnées géographiques sont incluses dans les observations, soit indirectement en faisant appel à une autre ressource.

Si le nombre OBS d’observations est très grand, les observations peuvent être sous catégorisées pour donner du sens à l’analyse. Exemple : la température mesurée pour différentes heures du jour et de la nuit, la taille relevée pour chacun des deux sexes, les dépenses de fonctionnement des villes de moins de 5000 habitants, etc…

En résumé, pour vérifier que le jeu de données choisi convient, vous devrez donc vous assurer que:

  • le nombre OBS d’observations est suffisamment grand ;

  • la donnée à représenter sous forme d’histogramme n’est pas catégorielle ;

  • une géolocalisation est possible.

Pour la géolocalisation, il est accepté qu’elle soit construite à partir d’un dataset différent de celui utilisé pour l’histogramme, du moment que le contexte des deux jeux de données est le même.

Evaluation du travail

Le projet à évaluer sera copié sur la machine de l’enseignant avec la commande:

$ git clone adresse_publique_de_votre_projet

Le dashboard sera lancé avec le fichier app.R depuis RStudio.

Avertissement

Il est indispensable de reproduire les 2 étapes ci dessus sur une machine différente de la machine de développement avant de soumettre votre travail.

Après clonage du dépôt et à l’exécution de app.R :

  • le code ne doit pas produire de warnings dans la console ;

  • le dashboard ne doit pas comporter pas d’erreur de call back.

Le dashboard doit être fonctionnel à la première tentative. Chaque interaction supplémentaire avec l’évaluateur sera assortie d’un point de pénalité. Les causes les plus fréquentes :

  • référence à un fichier local à la machine de développement ;

  • utilisation d’un package obsolète ;

  • utilisation d’un package non recensé dans requirements.txt.

Votre code doit être structuré en fonctions, classes, modules et packages.

Il doit être documenté :

  • par des noms de variables explicites ;

  • des commentaires précisant pourquoi on exécute les principales instructions.

Les structures de données doivent être adaptées et les « bonnes pratiques » du langage mises en oeuvre. L’utilisation d’un linter tel que lintr est fortement recommandée.

Grille évaluation

Ci dessous, une liste non limitative des critères pouvant être utilisés pour l’évaluation. Ces critères ne sont pas d’égale importance.

  • Le dépôt

    • montre une utilisation régulière de git ;

    • le README est renseigné ;

    • contient un User Guide correctement renseigné ;

    • contient des informations sur les données utilisées ;

    • contient un Developer Guide correctement renseigné.

    • contient les principales conclusions de l’étude ;

  • Le dashboard

    • l’instruction pour le produire est présente dans le README et il se lance sans erreur ;

    • contient les représentations graphiques demandées ;

    • les graphiques sont correctement documentés (titre, label des axes, etc.) ;

    • est dynamique et fluide ;

    • est de façon générale de bonne qualité.

  • Le code

    • est structuré en packages, modules, classes, fonctions ;

    • est lisible et commenté ;

    • met en œuvre les bonnes pratiques du langage ;

    • utilise des structures de données et des packages/modules adaptés.

  • Les données

    • les données adressent un problème d’intérêt général ;

    • le script de récupération des données est présent ;

    • les données sont riches et abondantes.

A chaque item, un grade est attribué:

  • 4 : tout à fait d’accord

  • 3 : plutôt d’accord

  • 2 : ni vraiment d’accord, ni vraiment en désaccord

  • 1 : plutôt en désaccord

  • 0 : tout à fait en désaccord

Ces critères garantissent un projet complet, structuré et développé selon les bonnes pratiques.