Applications utilisant le Crowdsourcing

RÉALISATION DE LA BASE DE L’API

Calcul des facteurs de motivation

Dans le document « Task Design, Motivation, and Participation in Crowdsourcing Contests », il a été mis en évidence les différents moyens de motivation et leur influence sur la population. Préliminairement à l’étude, neuf hypothèses ont été formulées.
1. L’intention de participer est étroitement liée à la réelle participation. (H1)
2. La motivation extrinsèque afin d’obtenir une récompense monétaire est associée positivement au fait de vouloir participer. (H2a)
3. La motivation extrinsèque afin d’obtenir une reconnaissance est associée positivement au fait de vouloir participer. (H2b)
4. La motivation intrinsèque est liée positivement au fait de vouloir participer. (H3)
5. L’autonomie (liberté des horaires pour la collecte d’informations) est associée positivement à la motivation intrinsèque. (H4)
6. La variété (tâche non répétitive) est associée positivement à la motivation intrinsèque. (H5)
7. Partager et récolter des informations tacites a un effet négatif sur la motivation intrinsèque. (H6)
8. La capacité d’analyse (disponibilité des connaissances concrète afin de réaliser la tâche) a un effet positif sur la motivation intrinsèque. (H7a)
9. La variabilité (fréquence d’événement inattendu lors de la collecte) a un effet positif sur la motivation intrinsèque. (H7b)
En plus de ces hypothèses, une analyse portant sur la confiance et sur plusieurs facteurs démographiques a été réalisée.

Application de base

Il s’agit ici d’une application qui permet de collecter des points où il y a des barrières architecturales. Ces données sont envoyées sur un serveur distant depuis le smartphone des utilisateurs. Avec ces données, une carte digitale est mise à jour et affiche les différents points.
Nous pouvons voir que cette application ressemble à la première version de We-Map, la version qui ne contenait pas encore le calcul d’itinéraire. Pour ce cas, l’étude ne compte que sur la bonne volonté et la compassion des gens afin de recenser les points.

Application récompense

Cette application va mettre en place un système de récompense. Vu que cette expérience a eu lieu dans l’université de Bologne, la récompense était la réussite d’un cours enseigné dans cette même école. Pour obtenir la récompense, il fallait remplir un minimum de 5 points dans l’application.
Il est clair que pour le cas de WE-MAP, il faudra trouver une récompense pouvant être utile à l’utilisateur et vu qu’il n’y a pas de budget, il n’est pas possible de rémunérer les utilisateurs.

Application jeu

Pour ce cas, l’application va engager les gens en transformant une application en jeu afin d’augmenter l’attrait des gens. L’université de Bologne a décidé de faire une application ou des zombies apparaissent et pourchassent le joueur. Le seul moyen que possède le joueur pour se défendre est de renseigner des obstacles architecturaux afin de pouvoir acheter des munitions pour son arme.

mPASS

mPass (mobile Pervasive Accessibility Social Sensing) est un système de collecte de données de l’environnement urbain. Il va se baser sur deux moyens de collecte.
Le premier est la récolte de données lorsque l’utilisateur se déplace dans l’environnement urbain. Elle ne demande aucune interaction. Cette méthode correspond donc à l’application breadcrumb de IBM, c’est pourquoi elle ne sera pas plus détaillée. Cette méthode va générer des S-reports (sensing report).
La seconde est la récolte de données à l’aide d’un formulaire rempli par l’utilisateur. Elle est semblable à l’application Citizen Sensing d’IBM cependant elle sera divisée en deux groupes d’utilisateurs. Des utilisateurs lambdas qui vont générer des U-reports (user report) et des administrateurs qui vont créer des A-reports (administrator report). Ces administrateurs sont des personnes travaillant dans des organisations qui visent à contrôler l’architecture urbaine. Ils seront plus fiables que des novices et pourront donc corriger leur rapport. Il y aura 2 moyens de collecter les données. Soit l’utilisateur ou l’administrateur va prendre l’initiative de lui-même afin de collecter un point, soit l’application va notifier l’utilisateur afin que ce dernier confirme ou corrige un point.
La correction va s’effectuer de la manière suivante. Un rapport généré automatiquement sera corrigé par un utilisateur du groupe U-reporter et un rapport d’utilisateur sera corrigé par un administrateur. Il n’y a cependant aucun mélange de données entre les groupes. En effet, lors du calcul du chemin le plus court, l’application va simplement prendre le rapport dans la base de données le plus élevée. Dans le tableau, nous pouvons voir un récapitulatif des moyens utiliser afin d’obtenir des données.

Recherche préliminaire de la HES-SO

Lors d’une précédente recherche sur le Crowdsourcing, la Haute Ecole Spécialisé de Suisse Occidentale (HES-SO) a publié un article sur la motivation et la validation des données. Le point qui nous intéresse est la proposition de validation de données. Dans cet article, il n’y a aucune trace de rapport automatique, car tous se basent sur l’interaction humaine.
En effet, chaque utilisateur doit avoir un compte au sein de l’application afin de pouvoir l’utiliser. Lors de l’inscription, ce dernier va devoir passer un test avec des données déjà validées au préalable. Cela va permettre de lui attribuer une note de base. Cette phase se nomme le test de qualification. Il permet d’écarter dès l’inscription les mauvais collecteurs qui viendraient polluer la base de données. Si l’utilisateur n’est pas qualifié, il peut retenter le test jusqu’à un maximum de trois fois, à la suite duquel il se fera définitivement exclure de l’application.
Une fois inscrit, il devra ajouter des points ou valider des points tout comme dans l’application mPASS. Lorsque le système juge que le rapport est bon et prêt à être utilisé, il va recalculer la note de chaque personne ayant participé à la collecte de ce point. En fonction des réponses de l’utilisateur et de la valeur acceptée par le système, la note donnée au collecteur va augmenter ou diminuer. Cette phase s’appelle le système de réputation.
Afin de valider un point, le système va tenir compte de la note courante de chaque participant. Si nous fixons la limite à 5 utilisateurs afin de valider le point, l’application va additionner la note des personnes pour et la note des personnes contre. Le total le plus haut l’emportera et sera donc jugé comme accepté par le logiciel. Cela s’appelle la phase d’agrégation.

Le rapport de stage ou le pfe est un document d’analyse, de synthèse et d’évaluation de votre apprentissage, c’est pour cela chatpfe.com propose le téléchargement des modèles complet de projet de fin d’étude, rapport de stage, mémoire, pfe, thèse, pour connaître la méthodologie à avoir et savoir comment construire les parties d’un projet de fin d’étude.

Table des matières

INTRODUCTION
1. ÉTAT DE L’ART
1.1. PROBLÉMATIQUE
1.2. CROWDSOURCING
1.2.1. Généralités
1.3. ATTRAIT DE LA POPULATION
1.3.1. Calcul des facteurs de motivation
1.3.2. Étude pratique de la motivation
1.3.3. Application de base
1.3.4. Application récompense
1.3.5. Application jeu
1.3.6. Résultat de l’expérience
1.3.7. Autres méthodes proposées
1.3.8. Synthèse des méthodes de motivation
1.4. VALIDATION DES DONNÉES
1.4.1. Citizen Sensing et Breadcrumb
1.4.2. mPASS
1.4.3. Recherche préliminaire de la HES-SO
1.4.4. Synthèse des moyens de validation
2. APPLICATIONS UTILISANT LE CROWDSOURCING
2.1. TRIPADVISOR
2.1.1. Descriptif de l’application
2.1.2. Moyen de motivation
2.1.3. Validation des données
2.2. AIRBNB
2.2.1. Descriptif de l’application
2.2.2. Moyen de motivation
2.2.3. Validation des données
2.3. WHEELMAP
2.3.1. Descriptif de l’application
2.3.2. Moyen de motivation
2.3.3. Validation des données
2.4. ROUTE4U
2.4.1. Descriptif de l’application
2.4.2. Moyen de motivation
2.4.3. Validation des données
2.5. PRODUITS GOOGLE
2.5.1. Descriptif de l’application
2.5.2. Moyen de motivation
2.5.3. Validation des données
2.6. SYNTHÈSE DES APPLICATIONS
3. SYNTHÈSE DE LA THÉORIE ET DE LA PRATIQUE
3.1. RÉSULTATS
3.2. CHOIX DE L’IMPLÉMENTATION
4. CHOIX TECHNOLOGIQUES
4.1. SCHÉMA DE L’ARCHITECTURE
4.2. BACKEND
4.3. LOGIQUE FRONTEND
4.3.1. Cordova
4.3.2. Ionic
4.3.3. React Native
4.3.4. Xamarin
4.3.5. Conclusion
4.4. USER INTERFACE
5. ÉTAPE DE DÉVELOPPEMENT
5.1. MISE EN PLACE DE L’ESPACE DE TRAVAIL
5.2. DESIGN DE LA BASE DE DONNÉES
5.3. RÉALISATION DE LA BASE DE L’API
5.3.1. Création des fichiers
5.3.2. Fonctionnement
5.4. CRÉATION DES FONCTIONNALITÉS
5.4.1. Connexion
5.4.2. Navigation
5.4.3. Carte
5.4.4. Ajout d’un POI
5.4.5. Points à proximité
5.4.6. GPS
5.4.7. Inscription
6. ÉVOLUTION POSSIBLE
7. GESTION DU PROJET
7.1. PRÉPARATION ET PLANIFICATION
7.2. RÉSULTAT ET COMPARAISON
8. BILAN
9. CONCLUSION
10. RÉFÉRENCES
11. ANNEXES
11.1. ANNEXE 1 : ALGORITHME DE VALIDATION DES DONNÉES
11.2. ANNEXE 2 : CAHIER DES CHARGES
11.3. ANNEXE 3 : STRUCTURE DES SOLUTIONS
11.3.1. Le serveur PHP
11.3.2. L’application mobile
12. DÉCLARATION DE L’AUTEUR