Brevet FR3156224A1 — publié le 20250606

La présente divulgation propose un procédé de gestion d’un service de mobilité, comportant une mise en relation entre une plateforme d’utilisateurs et au moins une plateforme d’acteurs de mobilité, par échange de jetons d’utilisateur et d’acteur de mobilité, dans lequel au moins le jeton d’utilisateur est établi à partir de données de l’utilisateur par tokenisation irréversible Figure de l’abrégé : Figure 1 Procédé de gestion d’un service de mobilité La présente divulgation relève du domaine du traitement de données dans le cadre de la gestion d’un service de mobilité, en particulier la gestion d’un service de déplacement collectif et/ou partagé. La limitation de l'utilisation des énergies fossiles, susceptibles de produire des gaz à effet de serre, devient un enjeu majeur dans le secteur de l'automobile. Une forte croissance du recours à l’énergie électrique dans ce secteur, en remplacement des énergies fossiles, est déjà observée. Toutefois, les prévisions des besoins en matière d’énergie électrique pour les déplacements montrent que les déplacements collectifs en véhicule devront être la norme tandis que les déplacements individuels seront proscrits. Par ailleurs, le nombre croissant de véhicules sature déjà les infrastructures routières sur les grands axes. Les problèmes de mobilités individuelles et de groupes des personnes s’accentuent au fil des ans, avec de graves impacts sur la consommation énergétique et sur l’environnement. C’est pourquoi les initiatives de covoiturage et déplacements collectifs, notamment, rencontrent beaucoup de succès et sont encouragées afin de réduire autant que possible le nombre de véhicules sur les routes, et réduire ainsi l’énergie sollicitée par l’ensemble de ces véhicules. Pour organiser de telles solutions de covoiturage, il existe des applications connues pour mettre en relation un automobiliste utilisateur d’un véhicule, d’une part, et un ou plusieurs passagers occasionnels de ce véhicule, d’autre part. De vastes opportunités ne sont pas encore exploitées aujourd’hui, par exemple les faits que : - des sociétés organisatrices d’évènements souhaitent favoriser la mobilité verte pour leurs clients ; - des sociétés souhaitent trouver des solutions pour minimiser l’empreinte carbone des employés, notamment lors de déplacements de groupes de leurs employés ; - des plateformes fédératrices B2B2C et B2B2B fournissent des applications dédiées, qui s’adressent à des clients particuliers ou des entreprises, mais ces plateformes ne sont pas interconnectées notamment avec des sociétés événementielles par exemple ; - le grand public souhaite se déplacer pour prendre part à un évènement, tel qu’un concert ou une épreuve des jeux olympiques, mais plusieurs facteurs limitants rentrent en jeu : le budget, les aléas des transports en commun (grève, horaires, incidents…), les embouteillages dans le cas de la voiture individuelle. Les particuliers peuvent s’adresser aux plateformes de mobilité connues, mais c’est à eux d’être proactifs et de chercher, plateforme par plateforme, une solution de covoiturage par leurs propres moyens. Ainsi, les utilisateurs doivent s’inscrire dans chaque plateforme. Par ailleurs, les données renseignées par les utilisateurs sont alors accessibles à des acteurs de mobilité alors que ces derniers n’ont même pas encore confirmé qu’ils pouvaient prendre en charge ces utilisateurs. Résumé La présente divulgation vient améliorer la situation. Elle propose à cet effet un procédé de gestion d’un service de mobilité, comportant une mise en relation entre une plateforme d’utilisateurs et au moins une plateforme d’acteurs de mobilité, par échange de jetons d'utilisateur et d’acteur de mobilité, dans lequel au moins le jeton d’un utilisateur est établi à partir de données de l’utilisateur par tokenisation irréversible. Par « tokenisation irréversible », on entend l’action d’un intermédiaire entre la plateforme d’utilisateurs et la plateforme d’acteurs de mobilité pour venir s’interfacer entre ces deux plateformes afin de pouvoir accéder aux données des utilisateurs tout en interdisant l’accès aux données d’utilisateurs pour la plateforme des acteurs de mobilité. Ainsi, dans un mode de réalisation, la mise en relation est mise en œuvre par une plateforme de gestion de service de mobilité s’interfaçant entre la plateforme d’utilisateurs et l’au moins une plateforme d’acteurs de mobilité, la plateforme de gestion interdisant, par ladite tokenisation irréversible, une visibilité des données d’utilisateurs par la plateforme des acteurs de mobilité. Les utilisateurs sont inscrits à la plateforme d’utilisateurs et n’ont pas besoin de s’inscrire dans des plateformes d’acteurs de mobilité directement. En effet, la plateforme de gestion de service de mobilité effectue l’identification de la solution de transport parmi les plateformes d’acteurs de mobilité disponibles. La solution proposée permet donc de mettre en relation de manière sécurisée des utilisateurs, particuliers ou via une entreprise (par exemple une société évènementielle), qui souhaitent se déplacer, avec des acteurs de mobilité, sans dévoiler directement l’identité des utilisateurs aux acteurs de mobilité (au moins tant que l’accord entre l’utilisateur et l’acteur de mobilité pour la prestation n’est pas définitivement établie). Selon un mode de réalisation, la plateforme d’utilisateurs comprend des données de plusieurs utilisateurs et l’au moins une plateforme de mobilité comprend des données de plusieurs acteurs de mobilité ayant chacun au moins un premier paramètre de mobilité. Des premiers paramètres de mobilité comprennent par exemple le trajet à parcourir, les horaires prévus du déplacement, le nombre de passagers qu’il est possible de transporter, l’assistance à un événement, etc. Les données des acteurs de mobilité peuvent comprendre un premier paramètre de mobilité ou plusieurs premiers paramètres de mobilité. Ainsi, dans l’une des applications possibles de la mise en relation au sens de la présente divulgation, la plateforme d’acteurs de mobilité peut comprendre (stocker par exemple) des données de plusieurs acteurs de mobilité comprenant, pour chaque acteur de mobilité, des données d’identité et au moins un premier paramètre de mobilité. La plateforme d’utilisateurs peut comprendre (stocker par exemple) des données de plusieurs utilisateurs comprenant, pour chaque utilisateur, des données d’identité. Le procédé peut alors comporter : - sur réception d’une requête de mobilité d’un utilisateur comprenant au moins un deuxième paramètre de mobilité en provenance de la plateforme d’utilisateurs, identifier, parmi lesdits plusieurs acteurs de mobilité, au moins un acteur de mobilité ayant l’au moins un premier paramètre de mobilité similaire à l’au moins un deuxième paramètre de mobilité de la requête de mobilité, selon un critère de similarité donné, - établir un jeton de l’utilisateur en fonction de données d’identité de l’utilisateur, et transmettre le jeton d’utilisateur avec l’au moins un deuxième paramètre de mobilité audit au moins un acteur de mobilité identifié ayant l’au moins un premier paramètre de mobilité similaire à l’au moins un deuxième paramètre de mobilité ; - sur réception d’au moins une première réponse d’acceptation d’un acteur de mobilité identifié indiquant qu’il souhaite établir une connexion avec l’utilisateur selon l’au moins un premier paramètre de mobilité, établir, en fonction de données d’identité de l’acteur de mobilité identifié, un jeton de l’acteur de mobilité identifié, et transmettre à l’utilisateur le jeton de l’acteur de mobilité identifié avec l’au moins un premier paramètre de mobilité. Les données d’identité précitées peuvent comporter, par exemple pour l’utilisateur, ses données personnelles (nom, adresse, numéro de téléphone, adresse numérique ou compte de réseau social, etc.), ainsi que des données de préférence (par exemple privilégier plutôt les voyages en train qu’en avion, etc.). Dans une réalisation, le procédé peut comporter en outre, après réception d’une première réponse d’acception de l’acteur de mobilité, adresser à l’utilisateur une requête de vérification destinée à vérifier s’il veut établir une connexion avec l’acteur de mobilité identifié. Des deuxièmes paramètres de mobilité peuvent comprendre par exemple le trajet à parcourir souhaité, l’heure de départ, le nombre de personnes qui souhaitent se déplacer vers un événement. La requête de mobilité peut comprendre un ou plusieurs deuxièmes paramètres de mobilité. Le critère de similarité précité peut être par exemple une correspondance exacte entre les premiers et deuxièmes paramètres, ou alternativement une correspondance la plus proche entre les deuxièmes paramètres et les premiers paramètres proposés (par exemple quant à une destination précise de départ ou d’arrivée, ou encore un horaire de départ ou d’arrivée). Typiquement, dans ce cas, l’opération d’adresser à l’utilisateur une requête de vérification comporte l’envoi à l’utilisateur d’une requête d’acceptation d’une connexion avec l’acteur de mobilité identifié et la réception d’une deuxième réponse d’acceptation de l’utilisateur souhaitant établir une connexion avec l’acteur de mobilité identifié. Dans une réalisation, plusieurs acteurs de mobilité sont identifiés selon un critère de priorité et une requête de vérification est adressée à l’utilisateur pour vérifier s’il veut établir une connexion avec lesdits acteur de mobilité identifié suivant cette priorité. Ainsi, un recrutement desdits plusieurs acteurs de mobilité est effectué par inscription de nouveaux acteurs de mobilité ou suppression d’anciens acteurs de mobilité. La mise en relation entre la plateforme d’utilisateurs et l’au moins une plateforme d’acteurs de mobilité est effectuée par exemple à travers des API respectives sécurisées. Dans une réalisation, le procédé peut comporter en outre présenter une interface homme machine pour saisir une note d’évaluation, au moins pour l’utilisateur, d’une qualité d’un voyage réalisé avec l’acteur de mobilité identifié. Dans une réalisation complémentaire ou alternative, le procédé peut comporter en outre présenter une interface homme machine à disposition d’un utilisateur pour organiser un paiement de l’utilisateur à l’acteur de mobilité identifié, pour un voyage effectué ensemble. Selon un autre aspect, il est proposé un programme informatique comportant des instructions pour la mise en œuvre de tout ou partie d’un procédé tel que défini dans les présentes lorsque ce programme est exécuté par un processeur. La présente divulgation vise aussi un dispositif de gestion d’un service de mobilité. Ce dispositif peut comporter un serveur avec une interface de communication avec un réseau étendu et un circuit de traitement pour la mise en relation entre une plateforme d’utilisateurs et au moins une plateforme d’acteurs de mobilité, par échange de jetons, dans lequel au moins le jeton d’un utilisateur est établi à partir de données de l’utilisateur par tokenisation irréversible. La présente divulgation vise aussi un système de gestion d’un service de mobilité comportant un dispositif tel que défini ci-dessus, une plateforme d’utilisateurs et au moins une plateforme d’acteurs de mobilité, le dispositif étant interconnecté auxdites plateformes pour agir en tant que plateforme de gestion d’un service de mobilité pour la mise en relation entre la plateforme d’utilisateurs et l’au moins une plateforme d’acteurs de mobilité. D’autres caractéristiques, détails et avantages apparaîtront à la lecture de la description détaillée ci-après, et à l’analyse des dessins annexés, sur lesquels : Fig. 1 FIG. 1 illustre un mode de réalisation dans lequel une plateforme d’utilisateurs et des plateformes des acteurs de mobilité sont connectées à une plateforme de gestion. Figs. 2 à 5 FIG. 2 , FIG. 3 , FIG. 4 , FIG. 5 illustrent un schéma fonctionnel d’un procédé de gestion d’un service de mobilité selon la présente divulgation. Fig. 6 FIG. 6 illustre un mode de réalisation dans lequel un acteur intermédiaire met en œuvre un procédé de gestion d’un service de mobilité selon la présente divulgation. Fig. 7 FIG. 7 illustre un mode de réalisation dans lequel des messages sont échangés entre la plateforme de gestion, l’utilisateur et l’acteur de mobilité identifié pour établir des interconnexions. Fig. 8 FIG. 8 illustre un mode de réalisation dans lequel des messages sont échangés entre la plateforme de gestion, l’utilisateur et l’acteur de mobilité identifié pour les mettre en relation. Fig. 9 FIG. 9 illustre la tokenisation irréversible des données de l’utilisateur et de l’acteur de mobilité identifié. Il est maintenant fait référence à la FIG. 1 , sur laquelle une plateforme d’utilisateurs 2 (par exemple une société organisatrice d’événements tel qu’un club de rugby) est en connexion avec des terminaux respectifs d’utilisateurs A1, …, An (base de membres). Des plateformes d’acteurs de mobilité 4a, 4b, …, 4n (par exemple des sociétés de covoiturage, des compagnies de train, de transporteurs privés, etc.) peuvent aussi être en relation avec des terminaux ou des serveurs dédiés chacun à un acteur de mobilité B1, …, Bn, C1, …, Cn, …, T1, …, Tn (base de clients et prospects). Dans certain cas, les utilisateurs A1, …, An de la plateforme d’utilisateurs 2 peuvent correspondre à des acteurs de mobilité en relation avec une plateforme d’acteurs de mobilité telle qu’une plateforme utilisée par une société de covoiturage. Les plateformes des acteurs de mobilité 4a, 4b, …, 4n comprennent, pour chaque acteur de mobilité B1, …, Bn, C1, …, Cn, …, T1, …, Tn, des données d’identité et au moins un premier paramètre de mobilité défini plus loin. La plateforme d’utilisateurs 2 comprend des données d’identité des utilisateurs A1, …, An défini plus loin. Une plateforme de gestion 6 d'un service de mobilité est connectée, de manière préférée à travers un réseau privé 8, auxdites plateforme des utilisateurs 2 et plateformes des acteurs de mobilité 4a, 4b, …, 4n. La plateforme de gestion 6 peut comporter, ou être mise en œuvre par un dispositif de gestion d’un service de mobilité. Ce dispositif de gestion peur comporter un serveur. Dans un mode de réalisation des particuliers X1, …, Xn peuvent aussi se connecter à une interface 10 du serveur 6 à travers un réseau étendu 12 tel que l’internet. Sur la FIG. 1 , un utilisateur A2 de la société organisatrice d’événements 2 souhaite se déplacer en covoiturage avec d’autres personnes, pas forcément pour assister au même évènement (par exemple aller voir ensemble le même match de rugby) mais simplement pour se rendre dans la même ville au même moment. L’acteur de mobilité C1 (ou plusieurs acteurs de mobilité C1, Bp, X1 comme détaillé ci-dessous) est identifié, parmi plusieurs acteurs de mobilité B1, …, Bn, C1, …, Cn, …, T1, …, Tn, comme pertinent pour le déplacement en covoiturage, comme décrit ci-dessous. La solution de la présente description peut par exemple trouver application dans le cadre d’une organisation d’une manifestation sportive, par exemple les jeux olympiques où une société organisatrice, par exemple le comité olympique, veut favoriser le déplacement vers et depuis ses évènements pour un plus grand nombre de billets vendus. Pour chaque réservation d’une épreuve, une demande de covoiturage peut apparaitre sur une page de la billetterie en ligne. Les utilisateurs rentrent leurs informations (alias et choix conducteur / passager, les informations de l’évènement étant déjà connues) et un covoiturage leur est proposé. Cette proposition peut être revue, fournie juste avant l’évènement, ou autres. La présente divulgation est particulièrement avantageuse pour cette application. En effet, la solution de mobilité recherchée étant liée à l’événement que l’utilisateur a prévue, l’utilisateur n’est pas contraint à fournir un grand nombre d’informations. La présente divulgation s’applique à toute société évènementielle : - évènements sportifs de tout type (toutes les fédérations de sport) ; - évènements culturels de tout type (musées, opéras, théâtres, fondations, médiathèques, associations, etc.), - évènements ponctuels. Les Figures 2 à 5 montrent un schéma fonctionnel d’un procédé de gestion d’un service de mobilité selon la présente divulgation. Dans une première étape 500, la plateforme de gestion 6 reçoit, par au moins une des plateformes des acteurs de mobilité 4a, 4b, …, 4n, un message d’inscription des acteurs de mobilité B1, …, Bn, C1, …, Cn, …, T1, …, Tn qui souhaitent s’inscrire auprès la plateforme de gestion 6. Dans l’étape 500, la plateforme de gestion 6 reçoit en outre, par la plateforme d’utilisateurs 2, un message d’inscription de l’utilisateur A2. Les messages d’inscription comprennent, pour l’utilisateur A2, au moins les données d’identité de l’utilisateur (par exemple ses données personnelles). Pour un acteur de mobilité B1, …, Bn, C1, …, Cn, …, T1, …, Tn, les messages d’inscription peuvent comprendre des données d’identité des acteurs (des données personnelles par exemple s’il s’agit de personnes physiques proposant par exemple du covoiturage). Ces messages d’inscription des acteurs de mobilité peuvent comprendre aussi au moins un premier paramètre de mobilité. En particulier, les acteurs de mobilité B1, …, Bn, C1, …, Cn, …, T1, …, Tn ont chacun associé au moins un premier paramètre de mobilité, comme par exemple : le trajet à parcourir, les horaires prévus du déplacement, le nombre de passagers qu’il est possible de transporter, l’évènement à participer, qui est utilisé dans un mode de réalisation particulièrement avantageux, etc. Dans une étape 502, la plateforme de gestion 6 effectue une négociation pour la connexion avec les acteurs de mobilité B1, …, Bn, C1, …, Cn, …, T1, …, Tn et l’utilisateur A2. La négociation, décrite plus en détail ci-dessous en référence à la FIG. 7 , est une étape dans laquelle la plateforme de gestion 6 évalue l’acceptation (ou le refus d’acceptation) des acteurs de mobilité B1, …, Bn, C1, …, Cn, …, T1, …, Tn et de l’utilisateur A2 qui ont fait la sollicitation d'inscription et enregistre leurs données d’identité dans une base de données sécurisée. La plateforme de gestion 6 peut par exemple décider, dans l'étape 502, de ne pas accepter certains acteurs de mobilité B1, …, Bn, C1, …, Cn, …, T1, …, Tn en raison de conditions d’acceptation prédéfinies liée à une qualité du service offert pas les acteurs de mobilité B1, …, Bn, C1, …, Cn, …, T1, …, Tn, par exemple un niveau de fiabilité ou ponctualité du service de déplacement ou une vétusté des moyens de transports utilisés. La plateforme de gestion 6 effectue, dans une étape 504 et de manière concurrente à l’étape 500, une étape de recrutement éventuel de nouveaux acteurs de mobilité B1, …, Bn, C1, …, Cn, …, T1, …, Tn, L’étape de recrutement 504 comprend la réception de messages d’inscription de nouveaux acteurs de mobilité B1, …, Bn, C1, …, Cn, …, T1, …, Tn qui souhaitent s’inscrire sur la plateforme de gestion 6 et j’ajout de ces nouveaux acteurs de mobilité B1, …, Bn, C1, …, Cn, …, T1, …, Tn, dans une étape de curation systémique 506, dans la base de données sécurisée. L’étape de curation systémique 506 est donc effectuée par la plateforme de gestion 6 pour mettre à jour la liste des acteurs se mobilité B1, …, Bn, C1, …, Cn, …, T1, …, Tn avec les inscriptions de nouveaux acteurs de mobilité ou suppression d’anciens acteurs de mobilité dans la base de données sécurisée tenue à jour par la plateforme de gestion 6. Après l’étape de recrutement 504 la plateforme de gestion 6 effectue l’étape de négociation 502. Ensuite, dans une étape 508, la plateforme de gestion 6 obtient un accord pour la connexion avec au moins un des acteurs de mobilité B1, …, Bn, C1, …, Cn, …, T1, …, Tn et l’utilisateur A2. Dans une étape 510, la plateforme de gestion 6 établit les interconnexions entre la plateforme des utilisateurs 2 et les plateformes des acteurs de mobilité 4a, 4b, …, 4n. Dans un mode de réalisation, les interconnexions entre les plateformes est sont mises en œuvre à travers des API (pour « Application Program interface ») sécurisées entre les plateformes. La FIG. 2 illustre les étapes visant à recevoir les sollicitations (messages d’inscriptions) de l’utilisateur, ainsi que celles des acteurs de mobilité, avec notamment un filtrage possible des acteurs de mobilité, afin d’établir les canaux de connexion de la plateforme de gestion 6 avec l’utilisateur, d’une part, et avec les acteurs de mobilité, d’autre part. Les Figures 3 à 5 suivantes illustrent les étapes visant à mettre en relation l’utilisateur A2 avec un acteur de mobilité, notamment l’acteur de mobilité identifié C1 mentionné ci-dessus. En référence à la FIG. 3 , la plateforme de gestion 6 reçoit, à l’étape 512, une requête de mobilité de l’utilisateur A2. Après, à l’étape de vérification 514, la plateforme de gestion 6 vérifie si l’utilisateur A2 est connu (car, par exemple, il a utilisé le service précédemment et ses données sont présentes dans la base de données sécurisée tenue à jour par la plateforme de gestion 6). Dans le cas négatif, une étape de profilage 516 de l’utilisateur A2 est effectuée pour collecter les données de l’utilisateur A2 et les enregistrer dans la base de données sécurisée. Après, le procède poursuit à l’étape d’identification 518 décrite ci-dessous. Dans le cas positif, une étape d’identification 518 est effectuée dans laquelle la plateforme de gestion 6 identifie l’acteur de mobilité C1 pertinent pour la mise en relation avec l’utilisateur A2, comme détaillé ci-dessous. L’étape d’identification 518 comprend contacter l’ensemble des acteurs de mobilité B1, …, Bn, C1, …, Cn, …, T1, …, Tn qui sont pertinents selon un critère de similarité donné, pour rechercher et qualifier les acteurs de mobilité B1, …, Bn, C1, …, Cn, …, T1, …, Tn intéressants. Dans la présente description, le terme « contacter » se réfère à l'envoi de données sous la forme d’un message de requête, attendant le plus souvent une réponse du destinataire du message, comme précisé ci-dessous avec référence au Figures 7 à 9. En particulier, comme mentionné ci-dessus, les acteurs de mobilité B1, …, Bn, C1, …, Cn, …, T1, …, Tn ont chacun défini précédemment de premiers paramètres de mobilité. Les utilisateurs A1, …, An ont aussi chacun défini respectivement de deuxièmes paramètres de mobilité qui leurs sont propres, par exemple via des interfaces homme-machine connectées à des terminaux respectivement à disposition des utilisateurs. Des données de ces « deuxièmes paramètres » peuvent être par exemple : le trajet à parcourir souhaité, l’heure de départ, le nombre de personnes qui souhaitent se déplacer, l’évènement à participer, etc. Ces deuxièmes paramètres de mobilité sont contenus dans la requête de mobilité. Dans l’étape d’identification 518 l’acteur de mobilité C1 est identifié comme pertinent car ses premiers paramètres de mobilité sont identifiés comme similaires aux deuxièmes paramètres de mobilité de l’utilisateur A2. Ainsi, dans une telle réalisation, la plateforme de gestion 6 dispose de ces premiers et deuxièmes paramètres provenant des terminaux des utilisateurs et des acteurs de mobilité et peut déterminer les premiers paramètres d’un acteur de mobilité qui sont les plus proches des deuxièmes paramètres d’un utilisateur. Le critère de similarité utilisé pour déterminer cette proximité des paramètres peut être basé sur des règles prédéfinies telles que les villes de départ et de destination doivent être identiques, mais les adresses de destination notamment peuvent différer, ou encore l’heure prévue d’arrivée peut être différente mais rester inférieure à une heure prévue d’arrivée de l’utilisateur (par exemple pour assister à un évènement qui commence à une heure donnée). Dans une alternative de réalisation de la solution, plusieurs acteurs de mobilité Bp, C1, X1 (voir FIG. 1 ) peuvent être identifiés comme pertinents selon un critère de priorité. Dans cette alternative, ces plusieurs acteurs de mobilité identifiés sont présentés à l’utilisateur A2 dans une liste ordonnée de plusieurs candidats, pour une sélection multiple. L’utilisateur A2 est donc interrogé pour vérifier s’il veut établir une connexion avec les acteurs de mobilité Bp, C1, X1 identifiés suivant cette priorité. Dans cette réalisation encore, l’ordre de priorité peut être fixé selon le critère précité de similarité (les premières données les plus proches étant en tête de liste). La plateforme de gestion 6, à l’étape 520, contacte l’acteur de mobilité identifié C1. Dans une étape suivante 522, la plateforme de gestion 6 vérifie l’accord de l’acteur de mobilité identifié C1 pour cet utilisateur A2. Le procédé continue alors comme illustré sur la FIG. 4 et la plateforme de gestion 6, dans une étape 524, propose l’acteur de mobilité identifié C1 à l’utilisateur A2, par exemple par une notification sur son terminal. Ensuite, dans une étape 526, la plateforme de gestion 6 vérifie une réception de l’accord de l’utilisateur A2 pour la mise en relation avec l’acteur de mobilité C1 choisi. Dans le cas positif, la plateforme de gestion 6, à l’étape 528, met en relation l’utilisateur A2 avec l’acteur de mobilité identifié C1 en échangeant entre eux des jetons d’utilisateur et d’acteur de mobilité, comme détaillé en référence aux Figures 8 et 9. Après, l’utilisateur A2 et l’acteur de mobilité identifié C1 effectuent un voyage ensemble. Si aucun accord intervient entre l’utilisateur A2 et l’acteur de mobilité identifié C1, les étapes 518 à 528 sont répétées pour d’autres acteurs de mobilité B1, …, Bn, C1, …, Cn, …, T1, …, Tn, sélectionnés selon l’ordre de priorité mentionné ci-dessus. Le procédé peut se poursuivre comme illustré sur la FIG. 5 avec une étape 530 de réception d'un message en provenance du terminal d'utilisateur, ce message étant indicatif d'aléas éventuels pendant le voyage (retards, embouteillages, pannes, etc.). Les aléas éventuels sont saisis par l'utilisateur sur son terminal Dans une étape 532, il est proposé à l’utilisateur A2 de noter éventuellement l’efficacité de la gestion des aléas, par l’acteur de mobilité identifié C1, jusqu’à la fin du parcours (par exemple au titre d’une évaluation à chaud). Quand le voyage est terminé, le procédé selon la présente divulgation comprend en outre une étape de paiement 534 du voyage effectué et, dans certains modes de réalisation, ensuite, une étape d’évaluation 536 du voyage. L’étape de paiement 534 peut aussi être mise en œuvre avant que le voyage soit effectué, par exemple en versant de l'argent vers la plateforme de gestion 6, puis la plateforme de gestion 6 effectue un paiement vers l'acteur de mobilité C1 une fois le voyage effectué. En particulier, comme mentionné ci-dessus, l’étape de paiement 534 peut être effectuée à travers l’animation d’une interface homme-machine, sur le terminal au moins d’utilisateur, pour organiser un paiement de l’utilisateur A2 à l’acteur de mobilité identifié C1, pour le voyage effectué ensemble. L’utilisateur A2 envoie un message de paiement à la plateforme des utilisateurs 2 qui transfert ce message vers la plateforme de gestion 6. La plateforme de gestion 6 effectue le paiement et envoie ensuite une confirmation du paiement à la plateforme des utilisateurs 2. La plateforme des utilisateur 2 transfert cette confirmation vers l’utilisateur A2. De manière symétrique, l’acteur de mobilité identifié C1 envoie un message d’attente de paiement à la plateforme des acteurs de mobilité 4b qui transfert ce message vers la plateforme de gestion 6. La plateforme de gestion 6 effectue le paiement et envoie ensuite une confirmation du paiement effectué à la plateforme des acteurs de mobilité 4b. La plateforme des acteurs de mobilité 4b transfert cette confirmation vers l’acteur de mobilité identifié C1. Eventuellement, des messages d’inscription peuvent en outre être échangés entre la plateforme de gestion 6 et les plateformes d’utilisateurs 2 et d’acteurs de mobilité 4b pour des services de souscriptions supplémentaires. L’étape d’évaluation 536 peut être effectuée à travers l’animation d’une interface homme machine, sur le terminal à disposition de l’utilisateur A2 et sur un terminal de l’acteur de mobilité identifié C1, pour saisir une note d’évaluation (à froid typiquement) d’une qualité de voyage réalisé avec l’acteur de mobilité identifié. Selon un mode de réalisation, une application s’exécute sur le terminal de l’utilisateur A2 pour présenter une interface homme machine afin que l’utilisateur A2 puisse saisir un score ou un commentaire d’évaluation et envoyer, via son terminal, un message d’évaluation du voyage à la plateforme des utilisateurs 2. La plateforme 2 transfert ce message vers la plateforme de gestion 6, qui termine les échanges avec la plateforme des utilisateurs 2 et met à jour la plateforme des acteurs de mobilité 4b qui, à son tour, met à jour l’acteur de mobilité identifié C1 avec les données de cette évaluation saisies par l’utilisateur A2 (par exemple un score d’évaluation noté sur cinq étoiles). De manière symétrique, l’acteur de mobilité identifié C1 peut envoyer un message d’évaluation du voyage à la plateforme des acteurs de mobilité 4b qui le transfert vers la plateforme de gestion 6. La plateforme de gestion 6 termine les échanges avec la plateforme des acteurs de mobilité 4b et met à jour la plateforme des utilisateurs 2 qui, à son tour, met à jour l’utilisateur A2 avec cette évaluation. Des informations d’évaluations contenues dans les messages d’évaluation du voyage sont mémorisées dans une mémoire. La FIG. 6 illustre le cas d’un acteur intermédiaire 14, par exemple d’une ville ou collectivité locale, qui souhaite exécuter un procédé de gestion d’un service de mobilité selon la présente description sous sa propre marque 14, en utilisant sa propre interface 10’ personnalisé par la plateforme de gestion 6. Les bénéfices du procédé de gestion d’un service de mobilité selon la présente divulgation sont multiples : - pour les sociétés évènementielles, pouvoir proposer activement à leur clientèle une solution de covoiturage. Elles pourraient donc proposer une solution qui renforce leur image auprès de leur clientèle ; - pour les utilisateurs, bénéficier de la facilité de covoiturer avec des personnes ayant les mêmes centres d’intérêt qu’eux, avec une notion de praticité car dans ce cas l’aller et le retour sont proposés. Bien entendu, la confidentialité des données des utilisateurs ( privacy ) est protégée, via le système de jetons précité. Sur la FIG. 7 est illustrée une représentation schématique des messages échangés, pendant l'étape de négociation 502 mentionnée ci-dessus, pour établir de multiples interconnexions qui sont faites commercialement sur la base de négociations partenariales et techniquement via les API. Une première flèche 100 indique l’établissement d’une connexion entre l’utilisateur A2 et la plateforme de gestion 6, une deuxième flèche 102 indique l’établissement d’une connexion entre un premier acteur de mobilité B1, …, Bn, C1, …, Cn, …, T1, …, Tn (notamment l’acteur C1) et la plateforme de gestion 6 et une troisième flèche 104 indique l’établissement d’une connexion entre la plateforme de gestion 6 et un deuxième acteur de mobilité B1, …, Bn, C1, …, Cn, …, T1, …,Tn (notamment l’acteur T1). Aucune connexion directe entre l’utilisateur A2 et les acteurs de mobilité B1, …, Bn, C1, …, Cn, …, T1, …, Tn, ni entre les acteurs de mobilité T1 n’est effectuée. Sur la FIG. 8 est illustrée une représentation schématique des messages échangés entre la plateforme de gestion 6 et l’utilisateur A2 et entre la plateforme de gestion 6 et l’acteur de mobilité identifié C1 pour les mettre en relation pendant les étapes allant de l’étape 512 jusqu’à l’étape 528 mentionnées ci-dessus. Une flèche 106 représente l’envoi d’une requête de mobilité de l’utilisateur A2, qui souhaite se déplacer selon les contenues des deuxièmes paramètres de mobilité, à la plateforme des utilisateurs 2, cette requête de mobilité étant transférée vers la plateforme de gestion 6 (flèche 106’). Les flèches 106 et 106’ correspondent ensemble à l’étape 512 de réception de la requête de mobilité mentionné ci-dessous. Après la réception de la requête de mobilité, la plateforme de gestion 6 effectue l’étape d’identification 518 mentionnée ci-dessus. A l’issue de ces premières connexions 100, 102, 104, 106, la plateforme de gestion 6 peut exécuter une tokenisation 18 visant à créer un jeton (ou « token » en anglais) d’utilisateur et un jeton d’acteur de mobilité identifié. Ces jetons sont générés pour une transaction donnée (par exemple à chaque nouvelle requête d’un utilisateur et à chaque réponse positive à cette requête émise par un acteur de mobilité) et sont sauvegardés dans la base de données sécurisée que peut utiliser la plateforme de gestion 6 pour gérer cette transaction. La tokenisation 18, décrite en détail en référence à la FIG. 9 ci-dessous, consiste à établir un jeton au moins pour chaque nouvelle entité se déclarant auprès de la plateforme de gestion 6. Ces jetons peuvent alors être utilisés lors de la transmission de cette requête de mobilité de l’utilisateur A2 (avec le jeton d’utilisateur) à l’acteur de mobilité identifié C1 et réciproquement lors d’une proposition de l’acteur de mobilité identifié C1 (avec le jeton d’acteur de mobilité) faite à l’utilisateur A2 en réponse à sa requête. Pour la mise en œuvre de l’étape 18 de la FIG. 8 commentée ici, les jetons respectifs d’utilisateur et d’acteur de mobilité sont établis à partir des données d’identité de l’utilisateur A2 et des données d’identité de l’acteur de mobilité identifié C1. Typiquement, le jeton d’utilisateur représente une identité propre à l’utilisateur A2 (son nom, son adresse, une donnée de contact numérique telle que par exemple le numéro IMSI du téléphone de l’utilisateur et/ou son compte de réseau social et/ou une adresse email). Le jeton d’utilisateur peut être par exemple une signature numérique de ces données (par exemple un hash ou un cryptage avec une clé de sécurité) que seule la plateforme de gestion 6 peut utiliser afin de retrouver toutes les données initiales de l’utilisateur A2. Ainsi, la tokenisation est « irréversible » en ce sens que seule la plateforme de gestion 6 peut accéder aux données de l’utilisateur A2 à partir de son jeton. Le jeton d’acteur de mobilité identifié C1 peut comporter des données d’identité (nom, adresse physique et numérique) de l’acteur C1, personne physique ou société de transport. Ces données sont acquises à l’issue des étapes d’inscription 500 et de négociation 502 de la FIG. 2 . Dans un mode de réalisation alternatif de l’invention, la tokenisation 18 peut être effectuée avant-même la réception de la requête de mobilité, par exemple lors de l’étape de négociation 502 ou, en référence à la FIG. 3 , si l’utilisateur A2 n’est pas connu à l’étape 514, lors de l’étape de profilage 516, qui peut être accompagné de la création du jeton propre à l’utilisateur A2 et du jeton d’acteur de mobilité de tous les acteurs de mobilité qui se sont inscrits lors de l’étape l’inscription 500, avec enregistrement des jetons dans la base de données sécurisée. Dans ce mode de réalisation, dans l’étape de négociation 502 (ou de profilage 516), des souhaits habituels de l’utilisateur A2 peuvent être collectés parmi les données d’identité précitées afin d’affiner son profil. En effet, ces données d’identité peuvent comporter typiquement des données personnelles comme le nom, l’adresse de l’utilisateur, etc., ainsi que d’autres données de préférences d’utilisateur, comme par exemple la préférence de privilégier autant que possible les voyages en train plutôt qu’en avion, ou autre. Par exemple, une page web peut être proposée à l’utilisateur A2 pour cliquer sur ses options préférées. En outre, il peut être collecté des données d’identité sur des contraintes du transport (personne en fauteuil roulant, présence d’enfants, etc.), ou autres. Ces données d’identité sont utilisées pour établir le jeton d’utilisateur. Dans ce mode de réalisation, la plateforme de gestion 6 dispose alors soit du jeton d’utilisateur soit du jeton d’acteur de mobilité de tous les acteurs de mobilité qui se sont inscrits lors de l’étape l’inscription 500. Ces données de jeton peuvent permettre à la plateforme de gestion 6 de choisir efficacement l’acteur de mobilité C1 répondant le mieux aux souhaits habituels de l’utilisateur A2, à l’étape d’identification 518 de la FIG. 3 . La plateforme 6 peut par exemple réaliser un premier tri des acteurs de mobilité en fonction de ces données de jeton et ensuite sélectionner finalement l’un au moins des acteurs de mobilité identifié C1 sur la base de la demande spécifique de l’utilisateur A2 (destination particulière et/ou horaire de voyage et/ou mode de transport, souhaités, etc., selon les deuxièmes paramètres de la requête de mobilité). Alternativement à une tokenisation préalable 18 avant toute transmission de requête d’un utilisateur (avec stockage en base de données sécurisée), la tokenisation peut être réalisée au fil de l’eau (au moment de transmettre la requête d’utilisateur et/ou au moment de transmettre la proposition de l’acteur de mobilité identifié C1 en réponse à une telle requête). Ainsi, on comprendra que le terme « tokenisation » désigne aussi bien : - l’affectation d’un jeton unique à un utilisateur donné ou à un acteur de mobilité donné (pour une ou plusieurs transactions subséquentes), - que l’affectation d’un jeton unique par transaction, par exemple à un utilisateur donné, un jeton étant établi pour cet utilisateur à chacun de ses projets de voyage par exemple. En se référant à nouveau à la FIG. 8 , une flèche 108 indique l’envoie, par la plateforme de gestion 6 vers la plateforme des acteurs de mobilité 4b, d’une proposition, pour l’acteur de mobilité identifié C1, de connexion avec l’utilisateur A2, cette proposition étant transférée vers l’acteur de mobilité identifié C1 (flèche 108’). La plateforme des acteurs de mobilité 4b obtient un accord (flèche 110) de l’acteur de mobilité identifié C1 et envoie (flèche 110’) à la plateforme de gestion 6 une réponse d’acceptation de l’acteur de mobilité identifié C1 souhaitant établir une connexion avec l’utilisateur A2. Les flèches 108, 108’, 110 et 110’ correspondent ensemble aux étapes 520 et 522 de contact de l’acteur de mobilité identifié C1 et de réception de son accord mentionnés ci-dessus. Une flèche 112 indique l’envoi, par la plateforme de gestion 6 vers la plateforme des utilisateurs 2, d’une proposition, pour l’utilisateur A2, de connexion avec l’acteur de mobilité identifié C1, cette proposition étant transférée vers l’utilisateur A2 (flèche 112’). La plateforme des utilisateurs 2 obtient un accord (flèche 114) de l’utilisateur A2 et envoie (flèche 114’) à la plateforme de gestion 6 une réponse d’acceptation de l’utilisateur A2 souhaitant établir une connexion avec l’acteur de mobilité identifié C. Les flèches 112, 112’, 114 et 114’ correspondent ensemble aux étapes 524 et 526 de proposition de l’acteur de mobilité identifié C1 à l’utilisateur A2 et d’obtention de son accord mentionnées ci-dessus. Après la réception des accords (flèches 110 et 110’, 114 et 114’), la plateforme de gestion 6 met en connexion l’utilisateur A2 avec l’acteur de mobilité identifié C1 (étape 528) en échangeant entre eux le jeton d’utilisateur et le jeton d’acteur de mobilité, comme détaillée ci-dessous en référence à la FIG. 9 . L’utilisateur A2 et l’acteur de mobilité identifié C1 effectuent alors le voyage ensemble, après échange des informations mutuelles à travers les jetons. Dans un exemple, une société souhaite organiser le déplacement de ses salariés vers un évènement privé. Elle s’adresse donc à une plateforme d’organisation de transports en commun, définit la date et l’heure des voyages aller et retour, et le nombre de personnes à transporter. La plateforme d’organisation de transports en commun adresse la requête, via le système selon la présente description, à diverses sociétés de transports en commun en fournissant les détails du service demandé. Ici interviendrait la valeur ajoutée de la plateforme de gestion 6 en tant que tiers de confiance, qui fournirait à la plateforme d’organisation de transports en commun un service d’orchestrateur, son expérience sur un historique de demandes et de qualité de services avec diverses sociétés de transport, et renverrait les diverses possibilités de mobilité à la société demandeuse. Cette société peut donc faire son choix, parmi un certain nombre de sociétés, en s’appuyant sur des données fiables de qualité de service, mises à jour dans la base de données précitée. La tokenisation 18 de la FIG. 8 est illustrée en détail sur la FIG. 9 , à partir des données de l’utilisateur A2 pour le jeton d’utilisateur et des données de l’acteur de mobilité identifié C1 pour le jeton d’acteur de mobilité, pour une mise en relation entre l’utilisateur A2 et l’acteur de mobilité identifié C1 par échange de jetons. Des données d’identité d’utilisateur 700 de l’utilisateur A2 sont connues par la plateforme de gestion 6, par exemple récupérées lors de l’étape d’inscription 500 ou de profilage 516 mentionnées ci-dessus. Les données d’identité d’utilisateur 700 sont alors transformées, lors d’une première tokenisation 701 avec un premier code secret unique, en données d’identité d’utilisateur sécurisées 702 (pour former un jeton d’utilisateur). Les données d’identité sécurisées d’utilisateur 702 (ou « jeton d’utilisateur ») sont associées ensuite aux deuxièmes paramètres de mobilité 702a contenus dans la requête de mobilité pour former la proposition à l’acteur de mobilité identifié C1 (flèche 108). Ainsi, on comprendra que si la tokenisation 18 est faite avant-même la réception de la requête de mobilité, le jeton d’utilisateur peut être mémorisé dans la base de données sécurisées (par exemple, lors de l’étape de négociation 502) et peut être récupéré par la plateforme de gestion 6 pour être associé, après la réception de la requête de mobilité, aux deuxièmes paramètres de mobilité 702a, afin d’être envoyés ensemble (flèche 108) à l’acteur de mobilité identifié C1. La plateforme de gestion 6 connait aussi les données d’identité des acteurs de mobilité 704 et notamment celles de l’acteur de mobilité identifié C1, récupérées lors de l’étape d’inscription 500 (ou de recrutement 504) mentionnée ci-dessus. Les données d’identité d’acteurs de mobilité 704 sont alors transformées, lors d’une deuxième tokenisation 705 avec un deuxième code secret unique, en données d’identité d’acteur de mobilité sécurisées 706 (jeton d’acteur de mobilité). Les données sécurisées d’identité d’acteur de mobilité 706 (ou « jeton d’acteur de mobilité ») sont associées ensuite aux premiers paramètres de mobilité 706a pour être partagées avec l’utilisateur A2 (flèche 112). Les premier et deuxième codes précités peuvent être différents ou identiques. Ainsi, le jeton d’acteur de mobilité peut être mémorisé dans la base de données sécurisées (par exemple, lors de l’étape de négociation 502) et il est récupéré par la plateforme de gestion 6 pour être associé aux premiers paramètres de mobilité 706a, pour être envoyés ensemble (flèche 112) à l’utilisateur A2. Quand la plateforme des acteurs de mobilité 4b envoie la réponse d’acceptation de l’acteur de mobilité identifié C1 (flèche 110’) à la plateforme de gestion 6, elle (la plateforme des acteurs de mobilité 4b) renvoie aussi le jeton d’utilisateur reçu lors de la proposition de connexion à la plateforme de gestion 6, de sorte que la plateforme de gestion 6 peut utiliser ce jeton afin d’identifier l’utilisateur A2 vers lequel cette réponse d’acceptation de l’acteur de mobilité identifié C1 doit être transférée. La plateforme de gestion 6, après réception de la réponse d’acceptation de l’acteur de mobilité identifié C1 (‘flèche 110’), envoie à l’utilisateur A2 le jeton d’acteur de mobilité avec les premiers paramètres de mobilité 706a (flèche 112), et attend la réponse d’acceptation de l’utilisateur A2 (flèche 114’). Seule la plateforme de gestion 6 dispose des clés de réversibilité afin d’accéder à nouveau en clair aux données d’identité de l’utilisateur et de l’acteur de mobilité. Ainsi, les échanges de données d’identité entre l’utilisateur A2 et l’acteur de mobilité identifié C1 ne sont pas accessibles respectivement à l’acteur de mobilité identifié C1 et à l’utilisateur A2. Il s’agit alors d’une « tokenisation irréversible » en ce qu’elle permet à l’utilisateur A2 et à l’acteur de mobilité identifié C1 de se mettre en relation, tout en interdisant l’accès aux données d’utilisateurs A2 par l’acteur de mobilité identifié C1 (et éventuellement en interdisant aussi l’accès par l’utilisateur A2 aux données l’acteur de mobilité identifié C1). La tokenisation empêche ainsi l’acteur de mobilité identifié C1 de voir les données de l’utilisateur A2 et de les reconstruire, néanmoins sans l’aide de donnée tierces. Les bénéfices de la solution de la présente solution sont multiples : - pour la société demandeuse, la confiance dans la plateforme à laquelle elle s’adresse pour organiser le transport de ses salariés, mais aussi dans la dimension vertueuse des déplacements ; - pour les salariés, la satisfaction d’être pris en charge avec une solution complète et « verte ». - pour les plateformes organisatrices de transports en commun, l’assurance d’être en contact, pour les transactions, avec une plateforme de gestion 6 de confiance. La présente solution est pleinement multimodale : - elle simplifie la vie du grand public, mais aussi des sociétés organisatrices d’évènements, récurrents ou ponctuels ; - elle permet la mise en relation de plateformes fédératrices B2B2C et B2B2B avec les personnes physiques ou morales, dans un climat de confiance, établi avec le système de jetons ; - elle permet à la plateforme de gestion 6 de se positionner comme référent de confiance dans une chaîne de mise en relation de différents acteurs et clients de solutions de mobilité vertueuse. La présente solution est évolutive : la plateforme de gestion 6 engrange toutes les transactions qui ont eu lieu et « apprend » l’historique des transactions (succès, aléas, évaluations, …) pour affiner ses modèles et constamment améliorer ses propositions aux différents acteurs mais aussi pour mieux mener la gestion des aléas. L’objet de la présente description offre de nombreux avantages, en proposant typiquement une plateforme fédératrice s’interfaçant entre des entités B2B2C et B2B2B (la « plateforme de gestion d’un service de mobilité » telle que définie précédemment), laquelle gère alors l’interconnexion la plus pertinente entre les utilisateurs et les acteurs de mobilité, grâce à une gestion de jetons qui permet le rapprochement de profils, contextes, souhaits et contraintes, tout en préservant la confidentialité des données de l’ensemble des utilisateurs. La plateforme peut préserver éventuellement la confidentialité des données des acteurs de mobilité également, notamment dans des mécanismes d’enchères entre acteurs de mobilité proposant une même prestation. Cette plateforme fédératrice peut ainsi se présenter comme un tiers de confiance pour l’ensemble des acteurs, tant pour le recrutement, la mise en relation, la vérification des identités, que pour le paiement du service. Le serveur de la plateforme de gestion 6 comporte un circuit de traitement de données pour la mise en œuvre d’un procédé de gestion d’un service de mobilité (recrutement, profiling, mise en relation, gestion des trajets, etc.) comme détaillé ci-dessus. Le serveur est apte à exécuter le procédé présenté ci-avant. Typiquement, le serveur peut stocker notamment les données de code d’instructions d'un programme informatique au sens de la présente divulgation. Le procédé de gestion d’un service de mobilité selon la présente divulgation assure la tokenisation des informations traitées afin qu’elles restent confidentielles et sécurisées. Procédé de gestion d’un service de mobilité, comportant une mise en relation entre une plateforme d’utilisateurs (2) et au moins une plateforme d’acteurs de mobilité (4a, 4b, …, 4n), par échange de jetons d’utilisateur et d’acteur de mobilité, dans lequel au moins le jeton d’utilisateur est établi à partir de données de l’utilisateur par tokenisation irréversible. Procédé selon la revendication 1, dans lequel la mise en relation est mise en œuvre par une plateforme de gestion d’un service de mobilité (6) s’interfaçant entre la plateforme d’utilisateurs (2) et l’au moins une plateforme d’acteurs de mobilité (4a, 4b, …, 4n), la plateforme de gestion (6) interdisant, par ladite tokenisation irréversible, une visibilité des données d’utilisateurs pour la plateforme des acteurs de mobilité. Procédé de gestion d’un service de mobilité selon la revendication 1 ou 2, dans lequel l’au moins une plateforme d’acteurs de mobilité (4a, 4b, …, 4n) comprend des données de plusieurs acteurs de mobilité (B1, …, Bn, C1, …, Cn, …, T1, …, Tn) comprenant, pour chaque acteurs de mobilité (B1, …, Bn, C1, …, Cn, …, T1, …, Tn), de données d’identité et au moins un premier paramètre de mobilité et la plateforme d’utilisateurs (2) comprend des données de plusieurs utilisateurs (A1, A2, … , An) comprenant, pour chaque utilisateur, de données d’identité, le procédé comportant : - sur réception d’une requête de mobilité d’un utilisateur (A2) comprenant au moins un deuxième paramètre de mobilité, en provenance de la plateforme d’utilisateurs (2), identifier, parmi lesdits plusieurs acteurs de mobilité (B1, …, Bn, C1, …, Cn, …, T1, …, Tn), au moins un acteur de mobilité (C1) ayant l’au moins un premier paramètre de mobilité similaire à l’au moins un deuxième paramètre de mobilité de la requête de mobilité, selon un critère de similarité donné, - établir un jeton de l’utilisateur en fonction de données d’identité de l’utilisateur (A2), et transmettre le jeton d’utilisateur avec l’au moins un deuxième paramètre de mobilité audit au moins un acteur de mobilité identifié (C1) ayant l’au moins un premier paramètre de mobilité similaire à l’au moins un deuxième paramètre de mobilité ; - sur réception d’au moins une première réponse d’acceptation d’un acteur de mobilité identifié (C1) indiquant qu’il souhaite établir une connexion avec l’utilisateur (A2) selon l’au moins un premier paramètre de mobilité, établir, en fonction de données d’identité de l’acteur de mobilité identifié (C1), un jeton de l’acteur de mobilité identifié, et transmettre à l’utilisateur (A2) le jeton de l’acteur de mobilité identifié (C1) avec l’au moins un premier paramètre de mobilité. Procédé de gestion d’un service de mobilité selon la revendication 3, comportant en outre, après réception de la première réponse d’acceptation de l’acteur de mobilité identifié (C1), adresser à l’utilisateur (A2) une requête de vérification destinée à vérifier s’il veut établir une connexion avec l’acteur de mobilité identifiée (C1). Procédé de gestion d’un service de mobilité selon la revendication 4, dans lequel adresser à l’utilisateur (A2) une requête de vérification comporte : - envoyer à l’utilisateur (A2) une requête d’acceptation d’une connexion avec l’acteur de mobilité identifié (C1); - recevoir une deuxième réponse d’acceptation de l’utilisateur (A2) souhaitant établir une connexion avec l’acteur de mobilité identifié (C1). Procédé de gestion d’un service de mobilité selon l'une des revendications de 3 à 5, dans lequel plusieurs acteurs de mobilité (B1, …, Bn, C1, …, Cn, …, T1, …, Tn) sont identifiés selon un critère de priorité et une requête de vérification est adressée à l’utilisateur (A2) pour vérifier s’il veut établir une connexion avec lesdits acteurs de mobilité identifié suivant cette priorité. Procédé de gestion d’un service de mobilité selon l'une des revendications de 3 à 6, dans lequel un recrutement desdits plusieurs acteurs de mobilité (B1, …, Bn, C1, …, Cn, …, T1, …, Tn) est effectué par inscription de nouveaux acteurs de mobilité (B1, …, Bn, C1, …, Cn, …, T1, …, Tn) ou suppression d’anciens acteurs de mobilité (B1, …, Bn, C1, …, Cn, …, T1, …, Tn). Procédé de gestion d’un service de mobilité selon l’une des revendications précédentes, dans lequel la mise en relation entre la plateforme d’utilisateurs et l’au moins une plateforme d’acteurs de mobilité est effectuée à travers des API respectives sécurisées. Programme informatique comportant des instructions pour la mise en œuvre du procédé selon l’une des revendications précédentes lorsque ce programme est exécuté par un processeur. Dispositif de gestion d’un service de mobilité comportant un serveur avec une interface de communication avec un réseau étendu pour la mise en relation entre une plateforme d’utilisateurs et au moins une plateforme d’acteurs de mobilité, le serveur comportant un circuit de traitement pour la mise en œuvre du procédé selon l’une des revendications 1 à 8. Système de gestion d’un service de mobilité comportant un dispositif selon la revendication 10, une plateforme d’utilisateurs et au moins une plateforme d’acteurs de mobilité, le dispositif étant interconnecté auxdites plateformes pour agir en tant que plateforme de gestion d’un service de mobilité pour la mise en relation entre la plateforme d’utilisateurs et l’au moins une plateforme d’acteurs de mobilité.