OpenFoodFacts est à la base une base de données collaborative de produits alimentaires qui répertorie les ingrédients, les allergènes, la composition nutritionnelle et toutes les informations présentes sur les étiquettes des aliments. Cette base de donnée est collaborative, Open Source et est rempli par une multitude de personne. Elle a pour but d’informer le public sur leur consommation et la valeur nutritionnelle de leurs aliments. Elle utilise une donnée particulière : le Nutriscore, qui classe les aliments de A (sain) à E (beaucoup moins sain).
Cette base de données présente pourtant différents problèmes que nous avons dû résoudre pour pouvoir les utiliser correctement. Tout d’abord, la taille. Avec plus d’une centaine de colonne et plus de 400 000 lignes, elle fait 1,8Go au format csv. Notre objectif étant d’avoir un jeu de donnée d’environ 8-9Mo, un gros travail de filtrage devait donc être fait. Ensuite, la plupart des champs du jeu de données sont vides (par exemple, sur les étiquettes des produits, il n’y a pas du tout les mêmes champs pour une bouteille d’eau que pour des chips). Enfin, les données sont beaucoup trop larges (beaucoup trop d’attributs pour un produit), et elles ne sont pas toutes pertinentes pour ce que nous voulons présenter.
Un de nos objectifs est de permettre de visualiser les qualités nutritives des produits en fonction des régimes, restrictions et allergies alimentaires. Nous avons donc sélectionné 8 attributs assez classiques qui nous permettront d’obtenir ces informations. Ces 8 attributs sont :
Ensuite, pour avoir des données viables, nous avons supprimé tous les produits pour lesquels un attribut n’était pas renseigné. Le jeu de données étant encore trop important, nous avons dû appliquer des filtres un peu moins pertinents : les produits vendu uniquement en France, puis nous avons gardé 4 lignes sur 5.
Notre premier objectif est de représenter les Nutriscores des aliments accessibles en fonctions des restrictions alimentaires. Ensuite, nous voulions faire d’autres graphiques utilisant ces données pour extraire des informations pertinentes : Nombre d’ingrédients dans les produits et Nutriscore. Un graphique regroupant nutriscore, énergie et 2 taux (sel, sucre, graisse, protéines)
Tout d’abord, nous avons sélectionné une liste de restrictions, régimes et allergies alimentaires communes:
Cela a par contre une limite. Certains noms d’ingrédients peuvent contenir une sous chaine faisant partie de la restriction alors que l’ingrédient n’en fait pas partie. Par exemple : pour un régime végétalien, le mot “beurre” fait partie de la restriction. Hors le “beurre de cacao” est autorisé. Mais ces cas sont assez anecdotiques par rapport à la taille des données et l’utilisation que nous voulions en faire. En effet, rajouter toutes ces exceptions ralentirait considérablement notre filtrage des données, ce qui impacte négativement l’aspect “User-Friendly” recherché dans ce genre de visualisation de données. De plus, notre travail sur les données ne se concentre pas sur des produits en particulier mais sur un ensemble global de données. Enfin la contrainte de temps est aussi à prendre en compte, car s’occuper de cet aspect nous aurait pris un temps considérable que nous n’avions pas. Nous avons donc jugé que cette solution était la meilleure dans notre situation.
Couleur et valeur ont été sélectionnées pour représenter le Nutriscore. Nous n’avons pas choisi instinctivement la palette de couleurs proposées par défaut, cette décision est le résultat d’une réflexion et de concertations. En effet, le Nutriscore (ou tel qu’il est présent dans les données qui nous sont disponibles, on peut supposer qu’il soit quantitatif en réalité) est une quantité ordonnée. De ce fait, le choix de le représenter à l’aide de la valeur tombe sous le sens (la couleur seule ne suffisant pas à donner une impression d’ordre à la visualisation). Restait à choisir le jeu de couleurs sur lequel appliquer la variation de valeur. Nous aurions pu rester en niveaux de gris ou niveau d’une couleur quelconque mais il nous a semblé plus cohérent de conserver le jeu de couleurs vert-rouge originel et ceci pour deux raisons. Si, dans le futur, le Nutriscore est finalement adopté, il n’y aura pas besoin de modifier les couleurs pour conserver la cohérence. Qui plus est, les personnes sont habituées à associer le vert au positif et le rouge au négatif et le jeu de couleurs ainsi obtenu rend très bien l’ordonnancement des couleurs.
La page d’accueil affiche par défaut différents graphes disposés dans un slider. Le premier graphique correspond à la répartition selon le Nutriscore des produits constituant notre base de données sous forme de graphique circulaire aux couleurs originelles du nutriscore. Un passage de la souris sur une tranche fera apparaître son pourcentage. Le second graphique correspond à la valeur en énergie et nutriscore des ingrédients en fonction de leur taux de sucre et de sel. Enfin, le dernier graphique met en évidence le nutriscore en fonction du nombre de produit présent dans l'aliment. Sur chaque graphique il est possible de sélectionner des filtres correspondant à certaines restrictions alimentaires par un simple clic. Plusieurs sont sélectionnables ou déselectionnables simultanément, mettant à jour les graphiques avec les produits qui ont passé les filtres relatifs aux restrictions. Une barre horizontale montrant le pourcentage de produits disponibles dans ce régime est également mise à jour. Le choix du graphique circulaire vient aisément avec la représentation proportionnelle d’éléments d’un attribut. De plus, avec les couleurs, les modifications sont bien visibles et rendent ce que nous avions voulu montrer plus visibles. Le choix d’une barre horizontale, à l’image d’une barre d’avancée de téléchargement par exemple, convient bien pour montrer une proportion, même sans lire le chiffre. Le graphique à bulle permet de mettre en évidence 4 données simulatanément et le dernier graphique en batons permet de tirer rapidement la conclusion mise en évidence par celui-ci.
Nous comptions utiliser D3.js mais nous avons rencontré des difficultés car nous n’arrivions pas à l’utiliser sans mettre en place une partie serveur. Nous avons donc opté pour Chart.js qui correspondait très bien à nos attentes. Pour le reste du projet nous avons utilisé JavaScript et JQuery pour les interactions, et BootStrap pour la vue.
Nous avons utilisé une architecture Modèle Vue Contrôleur. Le modèle regroupe les données et les fonctions de traitement de données, la vue permet de cibler les éléments html modifiés dynamiquement grâce au contrôleur qui, lui, gère les interactions utilisateurs.