Modifier

Au lancement du projet du projet, on avait posé des questions auxquelles le projet Traceur FabMob devrait répondre. Les tests effectués au cours de l'année nous ont permis d'apporter les réponses que voici :

  • une application open source peut-elle répondre aux besoins d'un usager qui souhaite connaître ses déplacements?
    oui, le logiciel libre e-mission que nous avons choisi d'adapter pour ce projet Traceur permet à un utilisateur de tracer ses déplacements avec son smartphone, de visualiser des statistiques (par mode, distance, durée, nombre...), et de récupérer les données correspondant à ses trajets passés.
    La qualité des données recueillies est améliorable, loin d'être à 100 % exacte, mais c'est à notre connaissance le cas aussi des autres applications similaires non open source. Pour un usager qui souhaite connaitre ses déplacements, ou une collectivité ou un employeur qui souhaite permettre cela sur son territoire ou dans son entreprise, il faut comprendre néanmoins que le Traceur n'est pas un service mais un logiciel, et que ce logiciel n'est pas un produit maintenu et commercialisé par une entreprise en particulier. La version Traceur FabMob est utilisable pendant quelques mois, uniquement pour découvrir et tester l'application, mais le serveur n'est pas dimensionné pour une utilisation intensive (et l'application n'est d'ailleurs publique, il faut faire une demande pour être invité à l'installer).
    Si une collectivité (ou une entreprise, association, etc.) souhaite utiliser ce logiciel, il faut être capable de l'installer, de l'adapter à son besoin (par exemple changer la charte graphique, publier l'appli sur un store d'application mobile ou en tout cas la diffuser, etc.), de l'héberger, ou trouver un prestataire qui le fait : fournir le service à partir du logiciel n'est pas gratuit, il faudra au strict minimum quelques jours de travail (voir beaucoup plus selon les ambitions du service), mais évidemment c'est tout à fait possible et le but du projet est de rendre plus facile la fourniture de tels services par tous les acteurs qui le souhaitent.

  • cette application peut-elle répondre au besoin de protéger sa vie privée ?
    en l'état actuel du logiciel, les données en base ne sont pas cryptées, donc la protection des données de mobilité dépend de l'hébergeur de l'application, qui doit protéger correctement son serveur et s'engager à ne pas réutiliser les données ni les diffuser à des tiers, sauf consentement explicite de l'utilisateur (par exemple pour les fournir à la collectivité Autorité Organisatrice de Mobilité, sous certaines conditions).
    Il est possible néanmoins d'utiliser un système de gestion de fichiers qui crypte les données, comme cryptfs (https://e-mission.readthedocs.io/en/latest/install/deploying_your_own_server_to_production/#suggested-improvements) ou zfs, mais cela n'interdira pas à l'hébergeur d'avoir la possibilité d'accéder aux données historisées, et ne lui enlève donc aucune responsabilité.
    Une solution technique interdisant à l'hébergeur d'accéder aux données de e-mission serait beaucoup complexe à implémenter, et relève d'un projet de recherche et développement. Il serait en revanche relativement simple d'envoyer les données de e-mission dans un cloud personnel type cozy.io.

  • cette application peut-elle aussi répondre à certains besoins d’analyse de la mobilité d’acteurs opérationnels, à partir des informations partagées par plusieurs utilisateurs ?
    Oui, sur le principe, à condition d'avoir clairement défini les conditions d'utilisation des données par ces acteurs et les termes du consentement d'acceptation de ces conditions par les utilisateurs.
    Par ailleurs, le logiciel e-mission produit des données agrégées (statistiques journalières sur le nombre de total de déplacements, leur distance, leur durée, les modes utilisés) visibles par tous les utilisateurs, et donne accès de façon optionnelle à une "carte de chaleur" (heatmap) qui affiche les lieux les plus fréquentés en agrégeant toutes les positions historisées (avec possibilité de filtrer par jour et par mode)
    Enfin, le logiciel e-mission permet de demander à l'utilisateur de confirmer et préciser le mode et le motif de ses déplacements, et d'interroger les utilisateurs par des enquêtes en ligne définies par l'hébergeur (par ex. par la collectivité Autorité Organisatrice de Mobilité).

  • quels sont les composants clés d’un dispositif de d’analyse de la mobilité ?
    L'architecture générale de e-mission est similaire à celle de la plupart des autres logiciels : une partie embarquée sur le téléphone (https://drive.google.com/open?id=16tvZsuU2tgMkYLzJg4ayNT0ejRHl-d4T), et une partie serveur (https://drive.google.com/open?id=1UpuGNe8UUanOBrGCQaNZoA4106PGHq_k) qui comprend la communication avec l'application, l'analyse de données (pipeline de production des traces, et analyse offline), un serveur web et une base de données.
    Les composants sont a priori les mêmes pour des applications de traçage de la mobilité offrant des fonctionnalités similaires, même si les interfaces entre composants sont différentes (il n'existe pas de standard) et les choix techniques différents.

  • quels sont les composants existant sous licence open source ?
    Tous ces composants existent sous licence open source puisque e-mission est entièrement open source. Mais il existe aussi des logiciels open source qui implémentent une partie des fonctionnalités, par exemple des frameworks open-source IoT (internet of things), ou d'analyse de données, et peut être d'autres logiciels embarqués de traçage de déplacement et détection de mode, sur lesquels e-mission pourrait s'appuyer. Si une communauté d'intérêt technique se développe autour de ces questions, il faudrait plus systématiquement les recenser et les évaluer.
    E-mission est une application complète qui s'appuie sur des briques techniques open source (mongodb pour la base de données, cordova + Ionic pour le développement mobile, bottle pour le serveur web, pandas pour l'analyse de données, etc.) et s'interface avec des outils externes selon les besoins (enquêtes LimeSurvey, OTP pour la recherche d'itinéraire, Habiti.ca pour le gaming, overpass API OSM pour la recherche d'arrêts de transport, authentification openID, etc.).
    Néanmoins tous les composants "métier" sont développés spécifiquement pour e-mission. Même si la conception est modulaire, tous les composants de e-mission sont du code spécifique à e-mission, ce qui fait qu'au total c'est un gros logiciel, avec des qui demandent des compétences techniques différentes (développement mobile, développement web, communication temps réel, analyse de données...). Idéalement, le logiciel pourrait être encore plus modulaire et découpé en 3 ou 4 logiciels indépendants plus spécialisés et plus performants. Mais pour e-mission, envisager d'utiliser d'autres composants techniques demanderait un effort sur l'architecture important voir très important, c'est donc une perspective à moyen terme seulement. Par exemple, un projet de l'université de Washington consiste à adapter e-mission pour en faire un SDK Android qui fonctionne "au-dessus" du framework IoT Aware.
    Un point essentiel pour une véritable modularité de l'application est que les interfaces permettant de communiquer entre les modules soient le plus standard possibles. Notamment, il faudrait standardiser la donnée décrivant une trace de mobilité (découpée en déplacements, trajets, avec des arrêts, etc.). Cela permettrait de récupérer des traces issues d'autres applications pour les traiter avec le pipeline e-mission, ou réciproquement d'envoyer des traces e-missions dans d'autres outils d'analyse. La développeuse d(e-mission est en relation avec l'association Zephyr qui regroupe des chercheurs nords-américains qui veulent améliorer les outils de modélisation de la mobilité, et souhaitent aussi standardiser les données.

  • existe-t-il une communauté motivée pour les réutiliser et y contribuer ?
    E-mission a été réutilisée par une dizaine environ de projets de recherche universitaire aux Etats-Unis (Berkeley, Seattle...) et ailleurs (Sydney, Bangalore, Heidelberg, Suisse...), ainsi qu'en France par la FabMob. La développeuse du logiciel, qui va soutenir sa thèse fin 2019, cherche à organiser la maintenance collective du logiciel et l'inclusion du projet dans l'incubateur de la fondation Apache est envisagée pour 2020, en associant à cette initiative l'équipe du logiciel Itinerum de l'université Concordia à Montréal. Elle est aussi en contact avec la communauté des chercheurs en modélisation des déplacements (association Zehpyr) et souhaite promouvoir une méthode commune d'évaluation des applications de recueil de traces.
    En France, la FabMob se propose de réunir une communauté d'utilisateurs intéressée. Les tests effectués ont permis d'identifier une vingtaine d'organisations dont quelques-unes devraient réutiliser et adapter le logiciel dans les mois qui viennent. Il faudra confirmer en 2020 si on arrive à faire vivre une communauté d'intérêt technique autour du traçage de mobilité (indépendamment du logiciel e-mission), et/ou comment on arrive à fédérer des contributeurs francophones autour logiciel e-mission.

Posts en relation

Articles récents