Sur quels facteurs se concentrer pour réduire de manière efficace la criminalité ?

Par Victoire BONAUD, Auriane BORDENAVE, Mathura CHANDRAKUMAR et Guillaume LE GOFF, étudiants en Data Science à IMT Atlantique.

Depuis quelques années, le taux de criminalité global à New York a décliné, contrairement à d’autres grandes villes des USA. Pour autant, le taux de “hate crimes” (meurtres, viols, assauts graves) a beaucoup augmenté ces dernières années : 3,3 millions de victimes en 2018 contre 2,7 en 2015.

A la suite de ces constatations, le maire de New York, Monsieur Bill de Blasio, a lancé “the office for the prevention of Hate Crimes”, ou aussi appelé le MOCJ (Mayor’s office of Criminal Justice), en été 2019 afin d’empêcher ce type de crimes.

Il y a une réelle problématique concernant les stratégies à mettre en place dans le cadre de prévention contre les crimes violents.

Quel outil pour le Maire de New York ?

Pour aider le maire de New York, nous voulons créer un outil d’aide à la décision. Ce dernier permettrait de prédire l’impact de la modification de certains éléments, ou couples d’éléments, sur la criminalité pour chaque quartier de New York.

Quelles données utiliser ?

Nous avons cherché des données Open Data qui pourraient être liées à la criminalité, suite à la lecture de documents scientifiques traitant du sujet. Nous nous sommes ainsi concentrés, en premier lieu, sur des données socio-démographiques. Nous avons trouvé 7 variables d’intérêt comprenant le nombre d’habitants, le taux de personnes nées à l’étranger, le taux de pauvreté, le taux de chômage, le taux de diversité ethnique et le taux de jeunes déconnectés, par quartier de New York et par année entre 2000 et 2018.

Cependant, il est difficile pour le maire de mener des actions qui auront un impact direct sur ces variables. Comment avoir un impact direct sur la pauvreté ou le taux de chômage ?

Nous avons donc cherché d’autres sources de données qui permettaient d’avoir des renseignements notamment sur le nombre de commissariats, sur les infrastructures présentes dans différents quartiers et sur les évènements sociaux. Ce sont sur ces critères que le maire de New-York pourra influer.

Que faire de toutes ces données ?

Dans un premier temps, il s’agissait d’effectuer une préparation des données, qui a pris beaucoup de temps. En effet, le défi était de fusionner 11 bases de donnés puis de les regrouper en un seul dataset qui nous permette de répondre à notre problématique.

Le dataset final regroupe les données par quartiers et par années entre 2006 et 2018.

Pour fusionner les différents datasets, nous disposions des coordonnées GPS des événements et infrastructures. Il fallait donc faire correspondre ces coordonnées GPS aux Community District auxquels elles appartenaient. Cela a été effectué à l’aide d’une librairie Python de traitement des données géospatiales : geopandas. La ville de New-York met également à disposition des fichiers contenant les formes de chaque Community District, ce qui a permis d’effectuer l’opération.

Suite à ce travail nous nous sommes retrouvés avec le dataset suivant:

Mais la préparation des données ne s’est pas arrêtée là. En effet, notre problématique étant d’observer l’impact de certaines actions sur la variation de crime dans un quartier, nous avons décidé de faire d’autres modifications au dataset afin que notre étude soit plus adaptée à nos besoins.

Dans un second temps, nous avons donc décidé d’ajouter des colonnes qui expriment les variations de données d’une année sur l’autre plutôt que seulement les chiffres de l’année en cours. Par exemple, à partir de la colonne “Commissariats” on ajoute la colonne “Différence de commissariats” qui correspond au nombre de commissariats sur l’année étudiée moins le nombre de commissariats de l’année précédente.

Une fois toute cette base de données regroupée et afin d’avoir une première idée des influences de certaines variables, nous avons fait une première étude de corrélation. Nous avons retrouvé des corrélations plutôt intuitives et cohérentes. En temps normal ces études de corrélations permettent de supprimer les variables redondantes. Mais dans le cadre de notre modèle nous n’avons pas jugé utile d’en retirer, permettant à notre client d’avoir plus de choix de modification de données lors de la simulation de l’évolution du nombre de crimes dans un quartier.

La base de donnée finale est donc de 767 lignes par 55 colonnes.

Un problème de classification …

Plutôt que de prédire le nombre de crimes d’un quartier d’une année sur l’autre nous avons décidé de prédire la variation de crimes et de la regrouper en 3 classes : Augmentation, Diminution ou Stagnation du nombre de crimes par rapport à l’année précédente. La stagnation correspond à une variation du nombre de crime inférieure, en valeur absolue à 200.

Deux algorithmes nous intéressent tout particulièrement : l’arbre de décision et la régression logistique. En effet, ces deux algorithmes ont la particularité d’être facilement lisibles, ils ne sont pas des boîtes noires. Il est donc possible d’extraire les règles permettant de mener à la décision de l’appartenance à une catégorie ou à une autre.

Evaluation de nos modèles

Algorithme	Temps d’exécution	Précision	Aire ROC
Arbre de décision	< 1 seconde	55%	0.61
Random Forest (50 arbres)	~ 1 seconde	75.9%	0.77
Régression Logistique	< 1 seconde	78.1%	0.51

Ainsi, l’algorithme de Random Forest est le plus performant dans notre étude (Aire ROC bien supérieur à 0.5, qui correspond à une classification faite au hasard).

De plus, il est toujours intéressant d’étudier l’arbre de décision sachant que cela nous permet d’identifier des associations de variables influençant la variation de crime dans le même sens pour aider à jouer sur les facteurs pour trouver les bonnes combinaisons de facteurs réduisant le crime.

Des scénarios prometteurs

Ainsi, nos modèles nous ont permis d’identifier des facteurs influençant la criminalité positivement et négativement. Nous avons donc simulé différents types de scénarios pour visualiser l’impact sur la criminalité.

Nous avons réalisé un premier scénario augmentant le nombre d’évènements sociaux de 30% : la criminalité diminuerait dans 3 quartiers.

Avec un deuxième scénario, nous avons cette fois augmenté le nombre d’événements sociaux de 10% et les infrastructures sociales de 2% : nous remarquons alors que la criminalité baisse dans 10 quartiers. Nous conseillons donc au maire de se concentrer en premier temps sur ces quartiers et d’y mettre en place d’avantage d’évènements sociaux.

Des améliorations sont tout à fait envisageables. Nous pourrions déterminer des associations de variables plus précis à l’avenir pour permettre la réalisation de scénarios encore plus efficaces pour la diminution du crime à New York. De plus, il serait intéressant de réaliser les modèles sur des groupes (clusters) de quartiers afin d’avoir des résultats encore plus précis selon le type de quartier. En effet, les variables n’influencent pas les quartiers de la même manière.

Les data au service de la médecine pour combattre le diabète

Par : Alice Calliger, Ahmed Krichene et Pierre-Yves Mousset, élèves du Parcours Data Science de l’IMT Atlantique.

Le diabète, maladie souvent sous-estimée, touche aujourd’hui plus de 400 millions de personnes dans le monde et l’OMS prévoit plus de 600 millions de cas d’ici 2040. Cette progression est une réalité encore trop peu connue à l’heure actuelle, qu’il ne faut pas négliger. En effet, plus de 5 millions de personnes sont décédées du diabète en 2015 ce qui place cette maladie comme forte cause de mortalité dans le monde. De plus, il y a une réelle problématique concernant la connaissance de la maladie car 1 personne diabétique sur 2 ne sait pas qu’elle est atteinte. C’est pourquoi, il y a un véritable besoin de sensibilisation et de prévention de cette maladie, encore trop ignorée à ce jour.

Quelques chiffres clés

Source : International Diabetes Federation

Qu’est-ce-que le diabète ?

Le diabète est une maladie liée au mauvais traitement du sucre par l’organisme, qui conduit à une hyperglycémie et donc à un taux élevé de glucose dans le sang. Lorsqu’on mange des glucides, ils sont transformés en glucose. Les cellules du pancréas détectent alors une augmentation de glycémie et sécrète en conséquence des hormones (de l’insuline) qui permettent de réguler le taux de glycémie. Chez les diabétiques, ce système de régulation n’est pas présent. On considère qu’une personne a du diabète si son taux de glycémie dépasse 1.26 g/l à deux reprises dans la journée ou est égale ou supérieure à 2 g/l à n’importe quel moment. Il existe deux types de diabètes : un type I, maladie auto-immune qui apparaît dans la jeunesse et un type II qui apparaît plus tardivement, souvent après 40 ans et qui peut être lié à une mauvaise hygiène de vie. Le premier type, beaucoup plus rare, est souvent très rapidement diagnostiqué dès le plus jeune âge. A l’inverse, le second type de diabète représente plus de 90% des diabétiques et il est souvent inconnu des personnes atteintes. C’est donc le diabète de type II qui sera le sujet de notre étude.

Mais quelles sont les causes de cette maladie ?

De nombreux facteurs de risque sont souvent cités quand on parle de diabète. Le tabac, l’alcool, le cholestérol, l’alimentation, la pratique de sport, la sédentarité constituent un panel d’exemples de déclencheurs probables du diabète.

Notre projet, d’où proviennent nos données ?

Pour palier à ce manque de prévention et sensibilisation, nous avons voulu créer un outil permettant d’évaluer le risque d’une personne de développer le diabète.

A l’aide d’un questionnaire d’une dizaine de questions, nous pouvons prédire votre risque de devenir diabétique. Cette campagne de prévention permettra ainsi de sensibiliser les gens afin qu’ils changent si besoin leurs habitudes alimentaires, sportives, ou qu’ils prennent rendez-vous pour vérifier leur état de santé. En effet, comme pour de nombreuses maladies, un dépistage précoce permettra un meilleur traitement.

Afin de suivre et de détecter tout type de maladie, l’organisme américain Centers for Disease Control and Prevention met en place tous les ans un sondage auprès de ses citoyens qui renseigne de leur état de santé, de leur suivi médical ou encore de leur hygiène de vie. Le BRFSS (Behavioral Risk Factor Surveillance System), l’entité responsable de ces travaux, recueille des données dans les 50 États ainsi que dans le District de Columbia et dans trois territoires américains. BRFSS réalise plus de 400 000 entrevues avec des adultes chaque année, ce qui en fait le plus important système d’enquête sur la santé mené de façon continue au monde. C’est cette base de donnée que nous avons utilisée durant ce projet.

Nous tenons à préciser que les données utilisées dans le cadre de cette étude sont anonymisées afin de préserver la vie privée des gens. De plus, toutes les données produites par les agences fédérales sont dans le domaine public (cf section 105 of the Copyright Act), ce qui nous a permis d’utiliser librement et légalement ces informations.

Description de notre dataset

Les individus interrogés ont été sélectionnés au hasard. On obtient un échantillon assez représentatif de la population américaine notamment vis à vis du nombre de diabétiques. Ces graphes présentent la répartition des individus par genre et âge.

Nous avons donc développé plusieurs algorithmes basés sur ce dataset permettant d’évaluer le risque d’un individu de développer du diabète.

Pour mener à bien ce projet, nous avons suivi une démarche rigoureuse, commençant par la compréhension du besoin métier jusqu’à la mise en place de notre solution.

Ce schéma présente ainsi les différentes étapes de ce projet :

Préparation des données et analyse des données

La compréhension et la préparation des données a sûrement été le plus gros challenge de notre projet. En effet, les données brutes récupérées comportaient environ 330 variables encodées qui correspondent aux différentes réponses recueillies lors du questionnaire. Nous avons choisi de travailler sur les données de différentes années soit de 2011 à 2016. En agrégeant les données, nous obtenons un unique fichier de 2.821.503 lignes.

Nous avons en premier lieu étudier chaque colonne en utilisant une documentation d’explication des résultats du sondage, fourni par le BFRSS. La compréhension des variables nous a permis de sélectionner 100 colonnes. Les deux critères de sélection sont : Le nombre de valeurs manquantes pour la colonne concernée et la pertinence de la question. En effet, certaines variables avaient très peu de données ou n’apportaient rien à notre étude. Nous avons donc pu faire un premier tri.

Ensuite, nous avons étudié de plus près les relations existantes entre les différentes variables en utilisant une matrice de corrélation. Cela nous a permis d’affiner notre sélection. Nous avons utilisé 28 colonnes afin de construire des attributs pertinents.

Quels algorithmes ?

Nous nous sommes attaqués ici à un problème de classification, il s’agit de déterminer à l’aide de différents paramètres (taille, poids, fréquence de sport, etc…) si un individu risque d’être diabétique ou non.

Il existe de nombreux algorithmes de machine learning pour résoudre ce genre de problématique. Nous avons décidé de nous pencher sur 4 algorithmes qui sont en général particulièrement efficace pour ce type de classification binaire : la régression logistique, l’arbre de décision, le random forest et le support machine vector.

Comment évaluer nos modèles ?

Il existe plusieurs manières d’évaluer ce type de modèle.

Dans le cadre du machine learning et des algorithmes de type supervisé, on sépare souvent le dataset en deux parties (70%-30%), un qui servira à créer notre modèle (entraînement) et un deuxième à tester notre modèle.

Une première manière simple et efficace d’évaluer notre modèle est de regarder la matrice de confusion et ses métriques :

La courbe de ROC prenant en argument la sensibilité et la spécificité permet également d’évaluer un modèle à sortie binaire. On réalise la courbe de ROC de notre algorithme et on calcule ensuite l’aire sous la courbe (valeurs comprises entre 1 et 0.5). Plus l’aire est proche de 1 plus le modèle est pertinent, une aire proche de 0.5 sera équivalente à la probabilité de lancer une pièce et de deviner si le résultat sera pile ou face, autrement le hasard.

Voici un tableau récapitulatif des résultats des algorithmes réalisés avec le langage de programmation R (temps d’exécution obtenus sur une machine bureautique basique en 2018).

Algorithme	Temps d’exécution	Précision	Aire ROC
Régression logistique	7 minutes	91,69%	0,91
Arbre de décision	3 secondes	90,59%	0,5
Random Forest (250 arbres)	37 minutes	94,31%	0,92
Support Vector Machine	5 heures	90,58%	0,5

On constate donc que le Random Forest est l’algorithme le plus adapté à notre projet.

Une solution fiable et efficace

Afin de constituer le questionnaire de notre outil, nous avons cherché les variables qui influent le plus notre prédiction. Ces facteurs de risque sont présentés par ordre d’importance, ordre trouvé grâce à nos algorithmes.

Améliorer les résultats grâce à des technologies Big Data

L’exécution de certains algorithmes comme le Random Forest est assez coûteuse en temps, comme on peut le voir sur dans le tableau précédent. C’est pourquoi, nous nous sommes intéressés à l’utilisation d’une plateforme Big data pour réduire ce temps d’éxécution.

L’Institut Mines-Télécom et le GENES ont mis en place une plateforme de traitement de données massives : “Teralab”. Elle a une capacité de traitement importante avec une mémoire vive de plusieurs teraoctets et permet un traitement distribué des données: notre algorithme ne tourne plus sur une seul machine mais sur plusieurs à la fois d’où une réduction de son temps d’exécution.

Nous avons donc décidé d’utiliser cette plateforme pour notre projet. Pour cela, nous avons réécrit nos algorithmes en un autre langage : PySpark. Et le résultat est sans appel, nous obtenons un gain d’apprentissage de 9 !

Notre algorithme permet de prédire le risque d’avoir du diabète. Cette solution peut être utilisée afin de sensibiliser des individus au sein d’une population. Nous avons pensé développer une interface web permettant de recueillir les habitudes de vie d’une personne grâce à un questionnaire. Notre algorithme va ainsi pouvoir évaluer les probabilités que cette personne soit atteinte de cette maladie. Dans une version ultérieure, l’algorithme pourrait aussi faire des recommandations pour diminuer ce risque.

D’autres améliorations sont possibles. Il est probablement intéressant d’utiliser un dataset plus adéquat au problème pour l’apprentissage de l’algorithme. En effet, des informations sur l’hérédité pourraient améliorer la précision des résultats. Il pourrait aussi être judicieux de faire la distinction entre les différents types de diabètes.

La guerre contre les guerres d’édition dans Wikipedia

Par Amine AKKI, Hicham EL HAREM, Saad EL MAHFOUDI et Anas IRHBOULA, élèves du Parcours Data Science de l’IMT Atlantique.

Wikipedia est non seulement l’un des sites Web les plus visités, mais aussi l’une des plus grandes plateformes collaboratives du Web 2.0. Des millions d’éditeurs participent librement à l’élaboration et l’amélioration du contenu. Cependant, comme beaucoup d’autres choses dans la vie, la collaboration n’aboutit pas toujours de façon normale, surtout dans des articles plus controversés qui sont sujets à ce qu’on appelle les “Edit wars”.

Pour un visiteur de Wikipedia, Il est évident que par rapport à des pages comme “Pumpkin” et “Rivière” qui sont paisiblement développées, ils en existent d’autres qui sont très controversées : “Homosexualité” ou “Première guerre mondiale” à titre d’exemple. Or par souci de neutralité ces pages nécessitent d’être suivies et gérées par les administrateurs.

Notre intérêt est d’optimiser la détection de ces pages controversées afin de réduire les temps d’interventions, en mettant en œuvre un processus d’analyse de données.

Pour ce faire, nous avons travaillé sur un dataset de wikipedia où sont stockées les traces de révisions (modifications) des pages.

Chaque trace correspond à la version d’une page à un instant donné et contient des informations sur l’éditeur (nom ou adresse ip), la page (identifiant, titre, longueur en bytes …) et la modification qui a été faite (i.e. un code caractérisant de façon unique le contenu de la page après la révision qu’on notera dorénavant sha1).

Deux types d’actions sont possibles pour éditer une page wikipedia : 1) Faire sa propre modification en ajoutant/modifiant des passages du document ; 2) Faire un revert, c’est-à-dire annuler une ou plusieurs modifications faites sur un article pour revenir à une version antérieure.

Préparation à la guerre

Avant de commencer à élaborer des algorithmes complexes pour identifier les pages en conflit d’édition, découvrir les données et les préparer pour le traitement était une étape indispensable du projet.

Après avoir pris connaissance de la structure des traces de révisions et identifié le sens de chaque variable, nous avons procédé à une étape de préparation et sélection de données nécessaires pour la réalisation des objectifs de notre projet. En effet, Wikipedia fournit une base de données assez complète au niveau d’édition de pages Wiki où on trouve toutes les métadonnées de chaque page, e.g : taille de la page après chaque édition, titre, auteur/ éditeur, identifiant de la page, … etc.

Comme les données sont collectées de façon automatique, elles peuvent présenter des valeurs aberrantes (par exemple : identifiant de la page = 0). Il s’avérait donc nécessaire de commencer par vérifier et nettoyer le jeu de données avant d’appliquer une procédure analytique, en commençant tout d’abord par la suppression des données incomplètes (par exemple : Valeurs N/A ou NULL) et ensuite la création de nouvelles variables/indicateurs permettant de détecter les conflits éditoriaux sur une page Wiki.

Armes et munitions

La guerre éditoriale sur les articles de Wikipédia reste un sujet pour le moins… controversé et très subjectif. Une page sujette à une guerre éditoriale est difficile à définir et à identifier. Les avis diffèrent et les méthodes de détection se complètent comme s’opposent les unes aux autres.

Un choix doit être fait : quels signes pourraient nous permettre de reconnaître la présence de la guerre sur une page ?

Nous avons choisi six caractéristiques, en nous basant sur ce qui nous paraissait révélateur d’un conflit éditorial, et bien sûr, ce qu’on pouvait obtenir à partir des métadonnées à notre disposition, tout en nous appuyant sur les études publiées sur cette problématique (ici ou là).

Deux principaux indicateurs de la guerre éditoriale étaient bien sûr le nombre d’éditions et d’éditeurs sur la page. Ces deux informations à la fois faciles d’accès et assez révélatrices étaient le point de départ de notre fouille des pages. Elles ont d’ailleurs été prises en compte par l’étude faite par l’université de technologie et d’économie de Budapest : Characterization and prediction of Wikipedia edit wars.

Comme mentionné avant, les reverts (annuler une ou plusieurs modifications faites sur un article pour revenir à une version antérieure) ont leur importance. Quand le contenu d’une page est remis sans cesse à un état antérieur, l’avancement de l’écriture de celle-ci est clairement freiné par son caractère controversé ou par le fait qu’elle soit ciblée par des vandales, ce qui nous fait une transition directe à l’indice suivant : le degré de polémique. Le degré de polémique (measure of controversy) est un indice créé de toutes pièces et fortement inspiré de la recherche académique mentionnée un peu plus haut. On procède au calcul du nombre d’éditions confirmées (éditions ayant survécu pendant au moins 24 heures aux reverts) des utilisateurs impliqués dans les reverts et on l’utilise comme poids éliminant ainsi les vandales qui ont tendance à ne pas avoir d’éditions constructives.

Dans un niveau moindre, le temps qui s’écoule entre les éditions d’une page est important, si celui-ci est court, cela indique une activité dense et dynamique sur la page qui d’après nous peut indiquer qu’elle est en conflit. Ainsi nous avons rajouté la médiane de temps d’inter-éditions à nos indices.

Finalement, chaque article de Wikipédia peut contenir une page de Talk associée. Celle-ci regroupe les différentes discussions que peuvent avoir les utilisateurs sur le contenu de la page. Une page sous conflit éditorial est une page sur laquelle la discussion fait rage. La taille de la page Talk associée est quelque chose qu’on peut obtenir et qui renforcera notre pouvoir de détection de la guerre éditoriale.

Une fois ces indicateurs définis, il s’agit de sélectionner les pages qui se positionnent en tête selon un seuil défini en s’appuyant sur les histogrammes. À chaque page est donc attribué un score traduisant le nombre de critères validés (autrement dit l’indicateur vérifie le seuil prédéfini).

Et la guerre est déclarée à…

Le tableau suivant montre le top 15 des pages jugées en conflit.

Ce processus d’analyse est plus ou moins subjectif et dépend de la façon de choisir le seuil de chaque indicateur. Il était donc nécessaire de vérifier l’exactitude des résultats avant de valider l’ensemble de seuils.

Avoir un jeu de données de référence contenant la labellisation des pages « page en conflit » ou « page sans conflit » aurait été le meilleur moyen pour valider nos résultats. Malheureusement, le dataset fourni ne contient pas cette information vitale.

Nous avons donc proposé de vérifier manuellement les résultats en jetant un œil sur l’historique des éditions de ces pages, ainsi que le contenu de la page de discussion. Une méthode, qui certes, se base entièrement sur le jugement humain, mais qui nous a permis de nous assurer de l’efficacité de notre modèle.

Dans l’exemple ci-dessus, nous voyons clairement que les reverts sont systématiques et immédiats après chaque révision. Ceci étant, sur cet exemple, nous avons mis en lumière probablement l’action de robots. Une étude plus poussée doit être menée pour identifier si les actions sont bienvenues ou pas.

L’implémentation de notre algorithme pour la détection des conflits au sein de Wikipédia peut donc réduire les temps d’intervention des administrateurs, voire améliorer la détection elle même (mais cela demande à être validé !!!). De plus, le fait qu’une grande partie du code est écrite en Pyspark (langage de parallélisation d’exécution) permettra le passage à l’échelle en l’appliquant sur les jeux de données des autres versions de Wikipedia (English Wikipedia à titre d’exemple).

Yelp CityHeartbeat, quelles sont les tendances dans mon quartier ?

Par Arthur Bourgeois, Lucie Crucq, Célia Hocine et Jonathan Pathmanathan, élèves du Parcours Data Science de l’IMT Atlantique.

Permettre à ses utilisateurs de trouver le meilleur restaurant, coiffeur ou garagiste dans une ville, c’est la mission de Yelp. Créé en 2004, Yelp rassemble aujourd’hui plus de 115 millions d’avis sur son site et attire toujours plus de visiteurs par mois, principalement aux Etats-Unis où il se positionne en leader en matière de recommandations.

Comme d’autres avant eux, Yelp fait aujourd’hui appel à des personnes extérieures à son équipe pour développer de nouvelles idées afin de mieux répondre aux besoins de ses utilisateurs. L’entreprise a lancé le “Dataset Challenge” : un échantillon des données collectées par Yelp est mis à disposition des internautes, qui ont pour défi de trouver une façon innovante de les utiliser.

Dans le cadre de notre parcours “Data Science” à l’IMT Atlantique, nous avons eu pour mission de proposer un projet innovant basé sur les données du Dataset Challenge. Encadré par une équipe de professeurs experts dans les domaines de l’informatique, de l’analyse des données et de l’économie, nous nous sommes donc lancés dans la valorisation des données de Yelp.

CityHeartbeat : vers un nouveau service B2B

Très tôt dans notre réflexion, nous avons décidé de nous orienter vers un service à destination non pas des consommateurs, mais plutôt des commerçants. En effet, Yelp propose déjà de nombreux services aux consommateurs : recherche d’un business avec plusieurs filtres, écriture d’avis, système de notations sur de nombreux aspects du commerce…

En ce qui concerne les commerçants, Yelp offre des services pour attirer plus de clients : mise en avant du business sur le site (Yelp Ads) et proposition de bons de réductions type Groupon (Yelp Deals). Mais il manque selon nous des services pour aider les commerçants qui ne sont pas encore installés.

Elèves rigoureux et bien organisés que nous sommes, nous avons appliqué la méthode CRISP-DM pour structurer notre projet. Cette méthode est un pilier indispensable pour la réussite d’un projet de fouilles de données. Pour rappel, la méthode CRISP consiste en plusieurs phases :

La compréhension du business qui permet de fixer les objectifs du projet en se posant les questions métiers
La compréhension des données qui consiste en la découverte des données à notre disposition ainsi qu’à leur exploration
La préparation des données qui est une phase de nettoyage et réorganisation des données, et si nécessaire de création de nouvelles valeurs calculées à partir d’autres données
La modélisation pour la sélection du modèle de fouille de données ainsi que ses paramètres
L’évaluation qui consiste à juger les performances du modèle et comparer les résultats produits avec les objectifs à atteindre
Le déploiement à la fin du projet, phase pendant laquelle la solution est installée et de nouvelles pratiques sont mises en place suite aux conclusions tirées du projet.

En utilisant cette méthodologie, nous avons ainsi abandonné notre idée initiale : aider des commerçants à trouver la “recette” d’un business qui fonctionne était certes une belle idée, mais la phase de compréhension des données nous a permis de nous rendre compte que nous ne disposions pas des bonnes informations pour répondre à cette problématique. De plus, il était assez complexe de définir ce qu’était un commerce qui “fonctionne”, un critère trop subjectif.

Aidés par nos tuteurs, nous avons finalement pivoter et fait émerger une problématique un peu différente. Nous cherchons à exploiter les données pour répondre à une demande centrée sur le gérant d’un commerce. Un nouvel entrant qui souhaite s’installer dans un quartier a besoin d’informations sur les commerces de ce quartier, la fréquentation de ceux-ci, leur type, leurs notes et commentaires ainsi que leur catégorie de prix.

Notre future solution permettrait donc l’exploration d’un quartier pour permettre à un gérant de prendre mesure de la concurrence et d’observer les caractéristiques des business avec le plus de succès sur Yelp. Notre produit CityHeartbeat est né.

Nous avons passé un long moment à réfléchir sur les questions auxquelles devait répondre notre produit. Selon nous, deux questions principales intéressent un business qui souhaite s’installer : qui sont les concurrents déjà installés et qui sont les consommateurs qui viennent dans ce quartier ?

Quelles données pour une étude de marché ?

Après avoir défini nos objectifs, nous sommes passés à la phase 2 de la méthode : la compréhension des données.

Nous avions à notre disposition plusieurs tables regroupant des données par thème : la table business qui regroupe de très nombreuses données sur les commerces : leurs horaires d’ouverture, leur localisation, leur catégorie, leur note et des informations sur les services proposés ; la table checkin qui regroupe le nombre de visiteurs par période de temps pour chaque business ; la table reviews qui regroupe les avis des visiteurs ; la table users qui regroupe des informations sur les visiteurs.

Une première exploration de ces données nous a permis de nous rendre compte de plusieurs choses.

Premièrement, la table users n’est pas très utile dans notre cas car elle ne regroupe que des informations relatives à la communauté Yelp (nombre d’amis, commentaires des autres Yelpers…) et non pas des informations démographiques qui nous aideraient à qualifier les visiteurs d’un quartier… mais c’est un peu normal, non ?

Deuxièmement, la table des reviews nous paraît difficilement exploitable dans un premier temps, mis à part pour calculer le nombre d’avis par business. De plus, la date de l’avis ne veut pas dire grand chose car un utilisateur peut donner son avis plusieurs jours après sa visite.

Troisièmement, la table business, mise à plat, contient plus de 1000 informations différentes pour caractériser un business, ce qui rend sa manipulation difficile.

Enfin, nous remarquons que beaucoup d’informations, car non obligatoires, ne sont pas remplies : par exemple tous les restaurants n’ont pas rempli le champ “drive-thru” pour indiquer s’ils offrent ou non ce service. “Seulement 1% des business renseignent la case restrictions diététiques, ce qui la rend impossible à analyser” nous confie Célia, Data Quality Manager.

Suite à cette exploration, nous prenons deux décisions : utiliser uniquement les informations avec un taux de remplissage élevé pour garantir des informations pertinentes et partitionner la table business en sous-tables ne contenant que quelques colonnes pour faciliter et accélérer la manipulation des données.

Nous pouvons maintenant établir la liste des indicateurs que nous souhaitons suivre dans notre outil. CityHeartbeat permettra de visualiser :

la répartition des business en fonction de leurs coordonnées GPS sur une carte ;
leur nombre de checkins, leur nombre de reviews et leur note moyenne pour comprendre si ces business sont “performants” au sens de Yelp ;
des données sur les catégories de business et leur gamme de prix ;
des données sur les services proposés par les business (par exemple la livraison) et leurs horaires d’ouverture .

En ce qui concerne les consommateurs, nous ne pouvons rien afficher pour le moment mis à part leur nombre (grâce aux checkins).

Un POC interactif

Afin de réaliser notre tableau de bord, nous avons choisi l’outil Tableau Software, d’une part car nous connaissions déjà cet outil et d’autre part car c’est un outil puissant qui permet d’effectuer des calculs et d’en visualiser les résultats en temps réel. Il permet également une grande liberté dans la manipulation des données, les différents types de graphiques ainsi que les filtres. Dans un premier temps, par souci de simplification, notre première version de CityHeartbeat ne permet que d’observer les restaurants de la ville de Phoenix.

Le tableau de bord est très facile à prendre en main et la navigation y est intuitive. Il permet de répondre aux objectifs métiers que nous nous étions fixés et toute l’information capitale est synthétisée et présentée de la façon la plus parlante possible.

L’utilisateur peut rapidement visualiser où se trouvent les restaurants grâce à une carte de la ville observée. En fonction de la taille du point représentant le restaurant, l’utilisateur peut connaître sa fréquentation, et en fonction de la couleur allant du rouge au vert, il peut connaître la note donnée par les Yelpers. Un panel de filtres sur le côté de la carte permet de filtrer les restaurants de la zone : par leur catégorie, leurs horaires d’ouvertures et leur distance au point central de la zone étudiée.

L’outil permet également à l’utilisateur d’avoir une description globale des restaurants présents dans la zone choisie : comment sont réparties les enseignes en fonction de leur prix et de leur catégorie, combien de restaurants proposent certains services.

L’utilisateur peut aussi évaluer le poids du quartier par rapport à la ville entière : en effet, il peut voir quel pourcentage des checkins et des avis de la ville sont contenus dans la zone étudiée.

L’outil n’en est pour l’instant qu’à un stade de premier prototype. Nous avons plusieurs idées pour l’améliorer.

Premièrement, nous ne sommes pas totalement satisfaits de la façon dont la zone à explorer est définie. Aujourd’hui, nous utilisons une ville, un point de cette ville et nous calculons la distance entre chaque business de la ville et ce point central. L’utilisateur peut ensuite décider de réduire le rayon de la zone à explorer en diminuant la distance maximum au point choisi. Ce n’est pas la solution la plus pratique d’un point de vue utilisateur. La solution idéale serait de choisir une ville, puis un quartier de cette ville. Cela pose cependant plusieurs problèmes : les quartiers sont de taille très différente selon les villes (un “zoom” à l’intérieur du quartier serait alors nécessaire), de forme peu pratique à manier, et l’information du quartier n’est pas toujours disponible dans les données de Yelp.

Ensuite, comme cet outil est destiné à un commerçant qui cherche à s’installer, nous pourrions proposer plus d’options visant à lui permettre de comprendre pourquoi un business attire plus de personnes qu’un autre, en plus des checkins et de sa note. Entre autres, nous pourrions afficher une sélection d’avis : par exemple ceux qui sont notés les plus utiles, cools et drôles.

Nous pensions également indiquer quels sont les business qui ont souscrit à Yelp Ads ou Yelp Deals dans la zone observée, l’idée étant que de tels business devraient avoir une plus grande fréquentation, grâce à l’augmentation de leur visibilité. Cela pourrait idéalement inciter l’utilisateur de CityHeartbeat à souscrire lui-même à ces offres.

Dans tous les cas, nous sommes limités par les données en notre possession : certaines informations qui nous paraîtraient intéressantes ne sont pas assez remplies pour être exploitables, nous manquons d’informations sur la démographie des consommateurs… Nous devons également faire attention à ne pas montrer trop d’informations différentes sur notre tableau de bord, ce qui gênerait la lisibilité de l’outil.

Comment garantir nos revenus

En tant que membres de l’équipe Dynamic Solutions and Optimization de Yelp, notre mission n’est pas seulement d’améliorer le produit Yelp mais également de garantir des revenus. C’est la raison pour laquelle il est important de trouver un bon business model à notre projet.

Nous avons adopté un mode de vente en mensualités, avec une période d’essai où les interactions avec le tableau de bord seraient limitées pour donner envie à l’utilisateur d’acheter la version complète.

Notre produit pourrait en fait intéresser à la fois les commerçants qui souhaitent s’installer mais également des commerçants déjà implantés qui aimeraient se comparer facilement à leurs concurrents. Cela représente un nombre conséquent d’utilisateurs potentiels, sachant que rien qu’à Paris, 3 restaurants ouvrent chaque jour !

Ce que nous retenons de ce projet

Ce projet nous a permis de nous rendre compte de plusieurs choses.

Premièrement, ce n’est pas une légende : dans un projet de manipulation de données, ce n’est pas la modélisation ou la visualisation qui prennent le plus de temps.

Ici nous avons passé la majorité de notre temps à définir les objectifs de notre projet, puis à préparer les données. Une fois ces étapes passées, visualiser les données avec Tableau nous a semblé presque facile !

Ensuite, nous avons été confrontés au problème du big data, et là non plus, ce n’est pas une légende : la solution classique, mono serveur, que nous avions choisie pour la manipulation des données en Python, s’est heurtée à la quantité des données à manipuler (surtout le nombre de colonnes dans les datasets). En effet, nous n’avons pas utilisé d’architecture Big Data, et nous avons vite compris que le nombre important de calculs demandés nécessitait de changer de paradigme ! Faute de temps, nous avons donc contourné le problème en divisant les tables en sous-tables plus petites et donc faciles à manipuler, mais nous aurions cependant pu nous tourner vers des outils dédiés au Big Data comme Spark sur la plateforme Big Data TeraLab mise à notre disposition.

En conclusion, notre première version de CityHeartbeat s’est avérée fonctionnelle, facile à utiliser et pertinente. Pour évaluer sa performance, nous soumettrons un questionnaire de satisfaction à nos clients qui participeront bien entendu à l’évolution continuelle de la solution.

Affaire à suivre…