FR 3154834 A1 20250502 FR 2311556 A 20231025 La présente invention concerne un procédé et un dispositif de traitement (DV1) pour la mise en partage d’un véhicule (2). Le procédé comprend : réception, en provenance d’un terminal client (T1), de données d’utilisateur (DT1) comprenant des données d’agenda (DT1a) d’un utilisateur (UR1), des données de localisation (DT1b) de l’utilisateur et des données de préférence (DT1c) de l’utilisateur ; détection, à partir des données d’utilisateur (DT1), d’un besoin de déplacement de l’utilisateur (UR1) pour effectuer un déplacement (10) ; réception, en provenance du véhicule (2) via une communication (L1) de type véhicule-vers-le-Cloud, dite V2C, de données de véhicule (DT2) comprenant des données de localisation (DT2a) et des données de capacité (DT2b) du véhicule ; si les données de véhicule (DT2) satisfont le besoin de l’utilisateur, génération d’une recommandation (DT3) de partage de véhicule, ladite recommandation identifiant le véhicule (2) comme candidat de mise en partage pour réaliser ledit déplacement (10) ; et envoi, au terminal client (T1), de la recommandation (DT3) de partage de véhicule. Figure pour l’abrégé : Figure 1 Procédé et dispositif de traitement pour la mise en partage de véhicule La présente invention concerne la mise en partage d’un véhicule, notamment mais pas exclusivement d’un véhicule automobile. L’invention vise en particulier des procédés et dispositifs de traitement pour permettre une mise en partage d’un véhicule à destination d’un utilisation souhaitant effectuer un déplacement. Arrière-plan technologique La mobilité urbaine est un enjeu majeur de notre époque, avec une augmentation constante du nombre de véhicules en circulation dans les zones urbaines. Cette croissance a entraîné une congestion du trafic, des émissions de gaz à effet de serre et des problèmes de stationnement. En réponse à ces défis, la promotion du partage de véhicule, comme le covoiturage, est devenue une solution largement acceptée pour réduire l'impact négatif de la mobilité urbaine sur l'environnement et améliorer l'utilisation des ressources. Le partage de véhicule offre de nombreux avantages. En effet, les zones urbaines sont souvent surchargées de véhicules, ce qui entraîne des embouteillages et des retards. Le partage de véhicule permet de réduire le nombre de véhicules sur les routes, contribuant ainsi à atténuer la congestion des zones urbaines. Les véhicules personnels sont en outre une source majeure d'émissions de gaz à effet de serre. En encourageant le partage de véhicule, on peut réduire les émissions et favoriser la durabilité environnementale. En outre, les véhicules personnels sont souvent inutilisés une grande partie de la journée. Le partage de véhicule permet de maximiser l'utilisation des ressources existantes. Bien que le covoiturage et d'autres formes de partage de véhicule soient déjà largement adoptés, ils présentent des problèmes et des limitations qui entravent leur adoption et leur efficacité. En particulier, les solutions actuelles, telles que les plateformes de covoiturage, présentent des contraintes et limitations qui ne permettent pas un véritable essor de ce mode de transport. Ainsi, les solutions actuelles de mise en partage de véhicules automobiles peuvent être complexes à utiliser pour certains utilisateurs et pas toujours être adaptés à leurs besoins. Résumé de la présente invention L’un des objets de la présente invention est de résoudre au moins l’un des problèmes ou déficiences de l’arrière-plan technologique décrit précédemment. Un autre objet de la présente invention est d’offrir une solution performante de mise en partage de véhicule à un utilisateur. Un autre objet de la présente invention est de fournir des recommandations pertinentes de partage de véhicule à un utilisateur qui a besoin de réaliser un déplacement. Selon un premier aspect, la présente invention concerne un procédé, mis en œuvre par un dispositif de traitement, pour la mise en partage d’un véhicule, ledit procédé comprenant : - réception, en provenance d’un terminal client, de données d’utilisateur comprenant des données d’agenda d’un utilisateur, des données de localisation de l’utilisateur et des données de préférence indiquant des préférences de déplacement de l’utilisateur ; - détection, à partir des données d’utilisateur, d’un besoin de déplacement de l’utilisateur pour effectuer un déplacement ; - réception, en provenance du véhicule via une communication de type véhicule-vers-le-Cloud, dite V2C, de données de véhicule comprenant des données de localisation du véhicule et des données de capacité indiquant une capacité d’accueil du véhicule ; - si les données de véhicule satisfont le besoin de l’utilisateur conformément aux données d’utilisateur, génération d’une recommandation de partage de véhicule, ladite recommandation identifiant le véhicule comme candidat de mise en partage pour réaliser ledit déplacement ; et - envoi, au terminal client, de la recommandation de partage de véhicule. Le procédé selon l’invention peut comporter d’autres caractéristiques qui peuvent être prises séparément ou en combinaison, notamment parmi les modes de réalisation qui suivent. Selon un mode de réalisation particulier, le procédé comprend : - détermination, à partir des données d’utilisateur, d’habitudes de déplacement de l’utilisateur ; le besoin de déplacement étant détecté à partir des habitudes de déplacement de l’utilisateur. Selon un mode de réalisation particulier, les habitudes de déplacement comprennent un déplacement régulier que l’utilisateur effectue régulièrement selon les données d’utilisateur. Selon un mode de réalisation particulier, les données de véhicule sont reçues via la communication V2C établie entre le dispositif de traitement et une unité de contrôle télématique embarquée dans le véhicule. Selon un mode de réalisation particulier, la recommandation de partage de véhicule est automatiquement générée, et envoyée, au terminal client indépendamment d’une quelconque requête de recommandation de partage de véhicule. Selon un mode de réalisation particulier, le procédé comprend : - détection, à partir des données de localisation de l’utilisateur, que ledit utilisateur est positionné dans une zone associée à un arrêt de transport en commun ; dans lequel la recommandation de partage de véhicule est généré sur détection d’un premier évènement lié au transport en commun. Selon un mode de réalisation particulier, le procédé comprend : - suivi des données d’utilisateur tandis que l’utilisateur est en cours de réalisation du déplacement à bord du véhicule ; - sur détection d’un deuxième évènement indiquant un problème lié au déplacement en cours, génération d’une nouvelle recommandation de partage à partir d’autres données de véhicule reçues par communication V2C depuis un autre véhicule pour proposer une solution alternative au besoin de déplacement de l’utilisateur, et envoi de la nouvelle recommandation de partage au terminal client. Selon un deuxième aspect, la présente invention concerne un dispositif de traitement pour la mise en partage d’un véhicule, ledit dispositif comprenant une mémoire associée à un processeur configuré pour la mise en œuvre des étapes du procédé de traitement selon le premier aspect de la présente invention. A noter que les différents modes de réalisation mentionnés ci-avant en relation avec le procédé de traitement selon le premier aspect de l’invention ainsi que les avantages associés s’appliquent de façon analogue au dispositif de traitement selon le deuxième aspect de l’invention. Selon un troisième aspect, la présente invention concerne un système de traitement comprenant le dispositif de traitement selon le deuxième aspect de l’invention et un dispositif embarqué dans un véhicule, par exemple de type automobile ou de type véhicule à moteur terrestre. Le dispositif de traitement et le dispositif embarqué sont configurés pour coopérer ensemble afin de permettre la mise en partage du véhicule. Selon un quatrième aspect, la présente invention concerne un programme d’ordinateur qui comporte des instructions adaptées pour l’exécution des étapes du procédé de traitement selon le premier aspect de la présente invention, ceci notamment lorsque le programme d’ordinateur est exécuté par au moins un processeur. Autrement dit, les différentes étapes du procédé de traitement sont déterminées par des instructions de programmes d’ordinateurs. Ce programme d’ordinateur est configuré pour être mis en œuvre dans un dispositif de traitement du deuxième aspect de l’invention, ou plus généralement dans un ordinateur. Un tel programme d’ordinateur peut utiliser n’importe quel langage de programmation, et être sous la forme d’un code source, d’un code objet, ou d’un code intermédiaire entre un code source et un code objet, tel que dans une forme partiellement compilée, ou dans n’importe quelle autre forme souhaitable. Selon un cinquième aspect, la présente invention concerne un support d’enregistrement (ou support d’informations), lisible par le dispositif de contrôle selon le deuxième aspect ou plus généralement par un ordinateur (ou un processeur), sur lequel est enregistré un programme d’ordinateur comprenant des instructions pour l’exécution des étapes du procédé de contrôle selon le premier aspect de la présente invention. D’une part, le support d’enregistrement peut être n'importe quel entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une mémoire ROM, un CD-ROM ou une mémoire ROM de type circuit microélectronique, ou encore un moyen d'enregistrement magnétique ou un disque dur. D'autre part, ce support d’enregistrement peut également être un support transmissible tel qu'un signal électrique ou optique, un tel signal pouvant être acheminé via un câble électrique ou optique, par radio classique ou hertzienne ou par faisceau laser autodirigé ou par d'autres moyens. Le programme d’ordinateur selon la présente invention peut être en particulier téléchargé sur un réseau de type Internet. Alternativement, le support d'enregistrement peut être un circuit intégré dans lequel le programme d’ordinateur est incorporé, le circuit intégré étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question. L’invention permet avantageusement d’offrir des recommandations pertinentes de mise en partage de véhicule à un utilisateur ayant un besoin de déplacement, et ce de façon aisée et dynamique pour l’utilisateur selon la situation dans laquelle il se trouve. L’invention permet en particulier d’anticiper les besoins de déplacement d’un utilisateur et d’adapter les recommandations proposées en fonction de l’environnement et des besoins de l’utilisateur. Pour ce faire, l’invention prend en compte des données de l’utilisateur, telles que des préférences individuelles, la localisation de l’utilisateur et des données d’agenda (ou de calendrier), afin de personnaliser l’expérience de partage de véhicule. L’invention permet notamment de palier de façon réactive à d’éventuels problèmes de transport en commun que l’utilisateur est susceptible de rencontrer. Grâce à l’invention, l’utilisateur peut ainsi rapidement adapter son mode de déplacement pour réaliser un trajet. Brève description des figures D’autres caractéristiques et avantages de la présente invention ressortiront de la description des exemples de réalisation particuliers et non limitatifs de la présente invention ci-après, en référence aux figures 1 à 3 annexées, sur lesquelles : FIG. 1 illustre schématiquement un environnement comprenant un dispositif de traitement ainsi qu’un véhicule embarquant un dispositif de contrôle, selon au moins un exemple de réalisation particulier et non limitatif de la présente invention ; FIG. 2 illustre schématiquement le dispositif de traitement de la FIG. 1 , selon au moins un exemple de réalisation particulier et non limitatif de la présente invention ; et FIG. 3 illustre un diagramme de différentes étapes d’un procédé de traitement mis en œuvre par le dispositif de traitement de la FIG. 1 , selon au moins un exemple de réalisation particulier et non limitatif de la présente invention. Description des exemples de réalisation Un procédé et un dispositif de traitement pour la mise en partage d’un véhicule vont maintenant être décrits dans ce qui va suivre en référence conjointement aux figures 1-3 selon des modes particuliers de réalisation. Sauf indications contraires, les éléments communs ou analogues à plusieurs figures portent les mêmes signes de référence et présentent des caractéristiques identiques ou analogues, de sorte que ces éléments communs ne sont généralement pas à nouveau décrits par souci de simplicité. Les termes « premier(s) » (ou première(s)), « deuxième(s) », etc.) sont utilisés dans ce document par convention arbitraire pour permettre d’identifier et de distinguer différents éléments (tels que des opérations, des moyens, etc.) mis en œuvre dans les modes de réalisation décrits ci-après. Comme précédemment indiqué, l’invention vise notamment un procédé de traitement pour la mise en partage d’un véhicule, tel qu’un véhicule de type automobile ou autre, ou plus généralement d’un véhicule de type véhicule terrestre motorisé. Ce procédé repose en particulier sur la prise en compte de données d’utilisateur pour déterminer un besoin de déplacement d’un utilisateur. Des données de véhicule sont également reçues par communication de type véhicule-vers-le-Cloud, dit V2C (pour Vehicule-to-Cloud » en anglais) depuis un véhicule. Si les données de véhicule satisfont le besoin de déplacement, une recommandation de partage dudit véhicule est générée et envoyée au terminal de l’utilisateur. Selon un exemple particulier et non limitatif de réalisation de la présente invention, ce procédé comprend : - réception, en provenance d’un terminal client, de données d’utilisateur comprenant des données d’agenda d’un utilisateur, des données de localisation de l’utilisateur et des données de préférence indiquant des préférences de déplacement de l’utilisateur ; - détection, à partir des données d’utilisateur, d’un besoin de déplacement de l’utilisateur pour effectuer un déplacement ; - réception, en provenance du véhicule via une communication de type véhicule-vers-le-Cloud, dite V2C, de données de véhicule comprenant des données de localisation du véhicule et des données de disponibilité indiquant une capacité d’accueil du véhicule ; - si les données de véhicule satisfont le besoin de l’utilisateur conformément aux données d’utilisateur, génération d’une recommandation de partage de véhicule, ladite recommandation identifiant le véhicule comme candidat de mise en partage pour réaliser ledit déplacement ; et - envoi, au terminal client, de la recommandation de partage de véhicule. D’autres aspects et avantages de la présente invention ressortiront des exemples de réalisation décrits ci-dessous en référence aux dessins mentionnés ci-avant. La FIG. 1 illustre schématiquement un dispositif de traitement DV1 et un terminal T1 aptes à coopérer ensemble pour permettre la mise en partage d’un véhicule 2 à destination d’un utilisateur UR1 qui a un besoin de déplacement. Le dispositif de traitement DV1 et le terminal T1 forment ensemble un système de traitement SY1. Comme illustré, on suppose à titre d’exemple qu’un utilisateur UR1 utilise un terminal client T1 pour déterminer un moyen (ou mode) de transport en vue de réaliser un déplacement 10 depuis une position de départ PS1 jusqu’à une position d’arrivée PS2. Dans cet exemple, les positions PS1 et PS2 correspondent par exemple respectivement au domicile et au lieu de travail PS2 de l’utilisateur UR1, d’autres exemples étant toutefois possibles. L’utilisateur UR1 peut par exemple opter pour l’usage d’un transport public (ou transport en commun, ou transport collectif) 4, tel qu’un train, tram, bus, car ou autre, pour réaliser son déplacement 10. Une solution alternative consiste à utiliser le véhicule 2 au cours d’une mise en partage. Ce véhicule 2 peut par exemple être un véhicule utilisé par un tiers, ce dernier proposant un service de covoiturage, ou de chauffeur, ou de taxi. A cet effet, le dispositif de traitement DV1 et le terminal T1 peuvent communiquer ensemble pour échanger des informations, par exemple par une liaison de 4G, 5G ou toute autre liaison de communication appropriée. Le dispositif de traitement DV1 peut être tout ou partie d’un serveur, ou un réseau de serveur, ou plus généralement une infrastructure informatique comprenant des moyens configurés pour réaliser les étapes du procédé de traitement selon un exemple de réalisation de l’invention. Un exemple de mise en œuvre du dispositif de traitement DV1 est décrit ultérieurement. On suppose par la suite à titre d’exemple que le dispositif de traitement DV1 est un serveur, bien que d’autres types d’infrastructure puissent être utilisés. Comme illustré, le serveur DV1 est configuré pour coopérer avec le terminal T1 et avec un véhicule 2 pour assister l’utilisateur UR1 dans son déplacement 10. Comme décrit ci-après, le serveur DV1 peut ainsi proposer à l’utilisateur UR1 une recommandation de partage du véhicule 2 en vue de réaliser le déplacement 10. Le type et les caractéristiques du véhicule 2 peuvent varier selon le cas. On suppose à titre d’exemple que le véhicule 2 est de type automobile ou équivalent. En variante, ce véhicule peut être un car, un bus, un camion, un véhicule utilitaire ou une motocyclette, ou plus généralement un véhicule de type véhicule terrestre motorisé. Selon un exemple particulier, le véhicule 2 peut être un véhicule autonome ou semi-autonome. Plus particulièrement, le serveur DV1 peut comprendre au moins un processeur et une mémoire non volatile. Le serveur DV1 est configuré pour mettre en œuvre un processus (ou procédé) de traitement comme décrit ci-après. A cet effet, le serveur DV1 peut comprendre un programme d’ordinateur PG1 stocké dans la mémoire non volatile (mémoire de type Flash ou ROM par exemple), ce programme d’ordinateur PG1 comprenant des instructions pour la mise en œuvre du procédé (ou processus) de traitement comme décrit ci-après. Le processeur est ainsi configuré pour exécuter notamment les instructions définies par le programme d’ordinateur PG1. Par ailleurs, le terminal client T1 peut être un téléphone intelligent de type « smartphone », une tablette, un ordinateur portable, ou plus généralement un quelconque terminal de communication approprié apte à coopérer avec le serveur DV1 pour permettre la mise en partage du véhicule 2 selon le procédé de traitement de l’invention. Le terminal T1 est par exemple un terminal mobile que porte ou utilise l’utilisateur UR1. Plus particulièrement, le terminal T1 peut comprendre au moins un processeur et une mémoire non volatile. Le terminal T1 peut comprendre un programme d’ordinateur PG2 (par exemple une application) stocké dans sa mémoire non volatile (mémoire de type Flash ou ROM par exemple), ce programme d’ordinateur PG2 comprenant des instructions pour coopérer avec le serveur DV1 comme décrit ci-après. Le processeur du terminal T1 est ainsi configuré pour exécuter notamment les instructions définies par le programme d’ordinateur PG2. Comme représenté en FIG. 1 , le serveur DV1 est apte à recevoir des données d’utilisateur DT1 en provenance du terminal T1. Ces données d’utilisateur DT1, associées à l’utilisateur UR1, comprennent des données d’agenda DT1 (ou données de calendrier), des données de localisation DT1b et des données de préférence DT1c. Selon un exemple, les données d’agenda DT1 définissent des activités attribuées à l’utilisateur UR1 au cours du temps. A cet effet, ces données d’agenda DT1 peuvent comprendre des entrées d’agenda (ou entrées de calendrier), chaque entrée d’agenda définissant une activité (ou une tâche) de l’utilisateur UR1 en association avec une donnée temporelle (par exemple une heure et/ou une date). Ces données d’agenda permettent ainsi de caractériser des occupations de l’utilisateur UR1 au cours du temps. Selon un exemple, les données de localisation DT1b définissent une localisation de l’utilisateur UR1 à un instant donné ou au cours du temps. Le serveur DV1 peut recevoir des données de localisation DT1b définissant une position courante de l’utilisateur UR1 (ou plus précisément du terminal T1), par exemple en temps réel ou de façon périodique. Ces données de localisation DT1b comprennent par exemple des coordonnées géographiques ou coordonnées GPS (pour « Global Positioning System ») du terminal T1. Selon un exemple, les données de préférence DT1c définissent comment l’utilisateur UR1 souhaite ou préfère réaliser ses déplacements, tel que le déplacement 10 par exemple. Ces données de préférence DT1c peuvent définir divers critères à respecter au cours du déplacement, notamment par le véhicule 2 mis en partage. A titre d’exemple, les données de préférences DT1c peuvent indiquer que l’utilisateur UR1 souhaite réaliser un déplacement en compagnie d’un animal de compagnie ou encore qu’il souhaite apporter des bagages. Ces données de préférence DT1c précisent les conditions selon lesquelles l’utilisateur UR1 doit être pris en charge par le véhicule 10 au cours de son déplacement 10. Comme représenté en FIG. 1 , le serveur DV1 est configuré dans cet exemple pour coopérer via une liaison de communication L1 avec le véhicule 2, ou plus précisément avec un dispositif de contrôle DV2 embarqué dans le véhicule 2. Ce dispositif de contrôle (dit aussi dispositif embarqué) DV2 peut par exemple prendre la forme d’un (ou comprendre un) calculateur, ou une combinaison de calculateurs. Le dispositif embarqué DV2 peut être équipement électronique embarqué tel qu’un ordinateur de bord d’un véhicule, un calculateur électronique tel qu’une UCE (« Unité de Commande Electronique »), un téléphone intelligent (de l’anglais « smartphone »), une tablette, ou un ordinateur portable. Les éléments du dispositif embarqué DV2, individuellement ou en combinaison, peuvent être intégrés dans un unique circuit intégré, dans plusieurs circuits intégrés, et/ou dans des composants discrets. Le dispositif embarqué DV2 peut être réalisé sous la forme de circuits électroniques ou de modules logiciels (ou informatiques) ou encore d’une combinaison de circuits électroniques et de modules logiciels. La liaison de communication L1 entre permet une communication de type véhicule-vers-le-Cloud, dite V2C. La technologie V2C permet la communication bidirectionnelle entre le véhicule 2 et le serveur distant DV1, ce dernier pouvant être hébergé dans le cloud (dit aussi nuage informatique). Pour ce faire, le dispositif de contrôle DV2 comprend des moyens de communication embarquée pour échanger des données en temps réel ou à intervalles réguliers entre le véhicule 2 et les serveur DV1. Comme illustré, le serveur DV1 est configuré pour recevoir, via la liaison de communication L1 de type V2C, des données d’utilisateur DT2 en provenance du dispositif embarqué DV2. Ces données d’utilisateur DT2 comprennent des données de localisation DT2a du véhicule 2 et des données de capacité DT2b du véhicule 2. Selon un exemple, les données de localisation DT2a définissent une localisation du véhicule 2 à un instant donné ou au cours du temps. Le serveur DV1 peut recevoir de telles données de localisation DT2a définissant une position courante du véhicule 2, par exemple en temps réel ou de façon périodique. Ces données de localisation DT2a comprennent par exemple des coordonnées géographiques ou coordonnées GPS (pour « Global Positioning System ») du véhicule 2. Selon un exemple, les données de capacité DT2b définissent une capacité d’accueil du véhicule 2, c’est-à-dire sa capacité à accueillir des passagers et/ou du matériel à bord lors d’une mise en partage du véhicule 2 pour réaliser un déplacement, tel que le déplacement 10. A titre d’exemple, les données de capacité DT2b peuvent définir un nombre de passagers acceptables à bord, un nombre de bagage et/ou un poids de bagage acceptable, un critère d’acceptabilité des animaux (animaux acceptables/pas acceptables, type d’animaux accepté, etc.), etc. Le serveur DV1 est configuré pour analyser les données d’utilisateur DT1 et les données de véhicule DT2 et pour proposer une mise en partage du véhicule 2 à partir d’un résultat de cet analyse. Pour ce faire, le serveur DV1 est en particulier configuré pour détecter, à partir des données d’utilisateur DT1, un besoin de déplacement de l’utilisateur UR1 pour effectuer un déplacement, à savoir le déplacement 10 dans cet exemple. Si les données de véhicule DT2 satisfont le besoin de l’utilisateur UR1 tel que détecté conformément aux données d’utilisateur DT1, le serveur DV1 génère une recommandation DT3 de partage de véhicule, cette recommandation DT3 identifiant le véhicule 2 comme candidat de mise en partage pour réaliser le déplacement 10. Autrement dit, le serveur DV1 propose à l’utilisateur UR1, par la voie de la recommandation DT3, d’utiliser le véhicule 2 mis en partage pour réaliser le déplacement 10. Le serveur DV1 peut ainsi envoyer, au terminal client T1, la recommandation DT3 de partage de véhicule afin de proposer comme mode de transport depuis PS1 jusqu’à PS2 le véhicule 2 disponible à la mise en partage (par exemple dans le cadre d’un covoiturage). Comme indiqué ci-avant, le serveur DV1 est configuré pour mettre en œuvre un processus de traitement. Ce processus est à présent décrit conjointement à la FIG. 1 selon des modes de réalisation particuliers. La description de l’environnement de la FIG. 1 tel que précédemment décrit peut s’appliquer aux opérations du processus de traitement. Dans une première opération, le serveur DV1 reçoit, en provenance du terminal client T1 (ou plus précisément depuis l’application PG2), des données d’utilisateur DT1 comprenant des données d’agenda DT1a de l’utilisateur UR1, des données de localisation DT1b de l’utilisateur UR1 et des données de préférence DT1c indiquant des préférences de déplacement de l’utilisateur UR1. Dans une deuxième opération, le serveur DV1 détecte, à partir des données d’utilisateur DT1, un besoin de déplacement de l’utilisateur UR1 pour effectuer un déplacement, à savoir dans cet exemple le déplacement 10 depuis la position de départ PS1 jusqu’à la position d’arrivée PS2. Pour ce faire, une prédiction d’un besoin de déplacement est par exemple réalisée à partir des données d’utilisateur UR1 pour estimer un déplacement 10 que doit réaliser l’utilisateur UR1 à un instant donné. Cette prédiction peut avantageusement permettre d’anticiper ou estimer un besoin de déplacement que rencontre, ou va rencontrer dans le futur, l’utilisateur UR1 au vu de son contexte tel que défini par les données d’utilisateur DT1. Selon un exemple, le serveur DV1 détermine, à partir des données d’utilisateur DT1, des habitudes de déplacement de l’utilisateur UR1 au cours du temps. Le besoin de déplacement de l’utilisateur UR1 est alors détecté (ou déterminé) à partir de ces habitudes de déplacement. Il est ainsi possible d’anticiper les besoins de déplacement de l’utilisateur UR1 afin de lui proposer une recommandation pertinente, et ce de manière proactive (ou non sollicitée) comme décrit ci-après. Selon un exemple, les habitudes de déplacement déterminées par le serveur DV1 comprennent un (ou au moins un) déplacement régulier que l’utilisateur UR1 effectue régulièrement selon les données d’utilisateur DT1. Le serveur DV1 peut ainsi détecter un déplacement quotidien ou répondant à des critères de répétitivité dans le temps (par exemple un déplacement réalisé au moins N fois sur une période de temps donnée, où N>1). Dans une troisième opération, le serveur DV1 reçoit, en provenance du véhicule 2 (ou plus particulièrement du dispositif embarqué DV2), via une communication de type V2C, des données de véhicule DT2 comprenant des données de localisation DT2a du véhicule 2 et des données de capacité DT2b indiquant une capacité d’accueil du véhicule 2. La troisième opération peut être réalisée avant, ou après, ou en parallèle des première et deuxième opérations décrites ci-dessus. Dans une quatrième opération, le serveur DV1 compare les données de véhicule DT2 avec le besoin de déplacement de l’utilisateur UR1. Si les données de véhicule DT2 satisfont le besoin de l’utilisateur conformément aux données d’utilisateur DT1, alors le serveur DV1 génère une recommandation DT3 de partage de véhicule DT3. Cette recommandation DT3 identifie le véhicule 2 comme candidat de mise en partage pour réaliser le déplacement 10. Autrement dit, il désigne le véhicule 2 comme solution possible de mode de transport pouvant être mis en partage pour réaliser le déplacement 10 conformément au besoin de déplacement de l’utilisateur UR1. Dans une cinquième opération, le serveur DV1 envoie au terminal client T1 la recommandation DT3 de partage de véhicule. En réponse à cet envoi, le terminal T1 peut ainsi restituer la recommandation DT3 à l’utilisateur UR1, par exemple par affichage et/ou restitution audio. L’application PG2 peut ainsi permettre à l’utilisateur d’accepter ou décliner la recommandation DT3 de partage et, en réponse à une acceptation de l’utilisateur UR1, envoyer un demande de partage au serveur DV1 pour demander à réaliser le déplacement 10 selon la recommandation DT3 de partage. L’invention permet avantageusement d’offrir des recommandations pertinentes de mise en partage de véhicule à l’utilisateur UR1 ayant un besoin de déplacement, et ce de façon aisée, dynamique et adaptative pour l’utilisateur selon la situation dans laquelle il se trouve. L’invention permet en particulier d’anticiper les besoins de déplacement de l’utilisateur UR1 et d’adapter les recommandations proposées au cours du temps en fonction de l’environnement et des besoins de l’utilisateur. Pour ce faire, l’invention prend en compte des données d’utilisateur, telles que des préférences individuelles, la localisation de l’utilisateur et des données d’agenda, afin de personnaliser l’expérience de partage de véhicule 2. L’invention permet notamment de palier de façon réactive à d’éventuels problèmes de transport en commun que l’utilisateur est susceptible de rencontrer. Grâce à l’invention, l’utilisateur UR1 peut ainsi rapidement adapter son mode de déplacement pour réaliser un trajet. Selon un exemple, les quatrième et cinquième opérations sont réalisées automatiquement par le serveur DV1 sans requête préalable de l’utilisateur UR1 (ou de son terminal T1). En d’autres termes, le serveur DV1 génère automatiquement, et envoie automatiquement au terminal client T1, la recommandation DT3 de partage, et ce indépendamment d’une quelconque requête de recommandation de partage de véhicule. Ainsi, il n’est pas nécessaire que le terminal T1 envoie une requête de recommandation de mise en partage de véhicule pour que le serveur génère et envoie la recommandation DT3 au terminal T1. Ce processus de génération et d’envoi peut être réalisé de façon proactive (sans sollicitation préalable du terminal T1), ce qui permet avantageusement d’anticiper les besoins de l’utilisateur UR1 et de lui proposer aux moments opportuns des solutions adaptées de transport en fonction d’une prédiction de son besoin de déplacement à un instant. Selon un exemple particulier, au cours du processus de traitement, le serveur DV1 détecte, à partir des données de localisation DT1b de l’utilisateur UR1, que ledit utilisateur est positionné dans une zone associée à un arrêt de transport en commun, par exemple dans la zone d’un arrêt du transport en commun 4 ( FIG. 1 ). Au cours de la quatrième opération, la recommandation DT3 de partage de véhicule est alors générée sur détection d’un premier évènement lié au transport en commun 4. Ce premier évènement peut être de diverses natures selon le cas et peut par exemple être un problème, un incident, un retard, une alerte, ou encore une annonce de l’opérateur du transport en commun 4. Le serveur DV1 peut ainsi analyser la situation ou le contexte de l’utilisateur UR1 à un instant courant et, s’il est détecté un problème lié au transport en commun alors que l’utilisateur UR1 attend, ou va probablement souhaiter utiliser, le transport public, alors la génération et l’envoi de la recommandation DT3 sont déclenchés. Cette recommandation DT3 peut ainsi proposer le recours au partage du véhicule 2 comme alternative au transport en commun 4 pour réaliser le déplacement 10. Selon un exemple particulier, une fois que la cinquième opération a été réalisée, le serveur DV1 suit (ou surveille, ou analyse en temps réel) les données d’utilisateur DT1 reçues du terminal T1 tandis que l’utilisateur UR1 est en cours de réalisation du déplacement 10 à bord du véhicule 2. Sur détection d’un deuxième évènement indiquant un problème (une alerte, un incident, un accident, un retard, etc.) lié au déplacement 10 en cours, le serveur DV1 génère une nouvelle recommandation de partage à partir d’autres données de véhicule reçues par communication V2C depuis un autre véhicule (non représenté) pour proposer une solution alternative au besoin de déplacement de l’utilisateur. Le serveur DV1 peut ainsi envoyer cette nouvelle recommandation de partage au terminal client T1. Des solutions alternatives peuvent ainsi être proposées à l’utilisateur UR1 de façon proactive et adaptée pour palier à des problèmes de transport en commun auquel l’utilisateur UR1 est susceptible de faire face. La FIG. 2 illustre schématiquement un dispositif de traitement DV1 configuré pour permettre le partage d’un véhicule, selon un exemple de réalisation particulier et non limitatif de la présente invention. Le dispositif de traitement DV1 est par exemple configuré pour la mise en œuvre des opérations du processus de contrôle tel que précédemment décrit en regard de la FIG. 1 et/ou des étapes du procédé décrit ci-après en regard de la FIG. 3 . Des exemples d’un tel dispositif de contrôle 10 comprennent, sans y être limités, un serveur ou un groupes de serveurs. Le dispositif de traitement DV1 comprend un (ou plusieurs) processeur(s) 40 configurés pour exécuter des instructions pour la réalisation des étapes du procédé (ou du processus) de traitement et/ou pour l’exécution des instructions du ou des logiciels embarqués dans le dispositif de traitement DV1. Le processeur 40 peut inclure de la mémoire intégrée, une interface d’entrée/sortie, et différents circuits connus de l’homme du métier. Le dispositif de contrôle 10 comprend en outre au moins une mémoire 41 correspondant par exemple à une mémoire volatile et/ou non volatile et/ou comprend un dispositif de stockage mémoire qui peut comprendre de la mémoire volatile et/ou non volatile, telle que EEPROM, ROM, PROM, RAM, DRAM, SRAM, flash, disque magnétique ou optique. Le code informatique du ou des logiciels embarqués comprenant les instructions à charger et exécuter par le processeur 40 est par exemple stocké sur la mémoire 41. La mémoire 41 peut constituer un support d’informations selon un mode de réalisation particulier en ce qu’elle comprend un programme d’ordinateur (par exemple PG1 en FIG. 1 ) comportant des instructions pour la réalisation des étapes du procédé (ou du processus) de traitement de l’invention. Selon différents exemples de réalisation particuliers et non limitatifs, le dispositif de traitement DV1 comprend des moyens de communication pour coopérer avec des dispositifs externes, tels que le terminal client T1 et le dispositif embarqué DV2 ( FIG. 1 ). Le dispositif embarqué DV2 est par exemple un calculateur ou une TCU (de l’anglais « Telematic Control Unit » ou en français « Unité de Contrôle Télématique »). A cet effet, le dispositif de traitement DV1 peut comprendre un bloc 42 d’éléments d’interface pour permettre de communiquer avec des dispositifs externes, tels que le terminal client T1 et dispositif embarqué DV2 ( FIG. 1 ). La FIG. 3 illustre un diagramme des différentes étapes d’un procédé de traitement pour la mise en partage d’un véhicule, par exemple du véhicule 2 comme précédemment décrit. Le procédé est par exemple mis en œuvre par le dispositif de traitement DV1 coopérant avec le terminal client T1 et le véhicule 2 comme précédemment décrit ( FIG. 1 ). Dans une première étape 51, des données d’utilisateur DT1 sont reçues en provenant d’un terminal client T1, ces données d’utilisateur DT1 comprenant des données d’agenda DT1a d’un utilisateur UR1, des données de localisation DT1b de l’utilisateur UR1 et des données de préférence DT1c indiquant des préférences de déplacement de l’utilisateur UR1. Dans une deuxième étape 52, un besoin de déplacement de l’utilisateur UR1 pour effectuer un déplacement 10 est détecté à partir des données d’utilisateur DT1. Dans une troisième étape 53, des données de véhicule DT2 sont reçues en provenance du véhicule 2 via une communication L1 de type véhicule-vers-le-Cloud, dite V2C. Ces données de véhicule DT2 comprennent des données de localisation DT2a du véhicule 2 et des données de capacité DT2b indiquant une capacité d’accueil du véhicule 2. Dans une quatrième étape 54, si les données de véhicule DT2 satisfont le besoin de l’utilisateur conformément aux données d’utilisateur DT1, une recommandation DT3 de partage de véhicule est générée, cette recommandation identifiant le véhicule 2 comme candidat de mise en partage pour réaliser ledit déplacement 10. A cet effet, la recommandation DT3 peut comprendre un identifiant du véhicule 2, voire le cas échéant aussi d’autres informations pertinentes associées au véhicule 2 et sa mise en partage. Dans une cinquième étape 55, la recommandation DT3 de partage de véhicule est envoyée au terminal client T1. Selon des variantes de réalisation, les variantes et exemples des opérations décrits ci-avant en relation avec les figures 1-2 s’appliquent aux étapes du procédé de traitement de la FIG. 3 . Comme le comprend l’homme du métier, tous les modes de réalisation et variantes décrits ci-avant dont certains ont été simplifiés à dessein pour faciliter les explications, ne constituent que des exemples non limitatifs de mise en œuvre de la présente divulgation. En particulier, l’homme du métier pourra envisager une quelconque adaptation ou combinaison des modes de réalisation et variantes décrits ci-avant, afin de répondre à un besoin particulier. La présente invention ne se limite donc pas aux exemples de réalisation décrits ci-avant mais s’étend notamment à un procédé de traitement qui inclurait des étapes secondaires sans pour cela sortir de la portée de la présente invention. Il en serait de même d’un dispositif configuré pour la mise en œuvre d’un tel procédé. La présente invention concerne également un système de traitement le dispositif de traitement DV1 et le dispositif embarqué DV2, voire plus largement aussi le véhicule 2, comme représenté en FIG. 1 . Procédé, mis en œuvre par un dispositif de traitement (DV1), pour la mise en partage d’un véhicule (2), ledit procédé comprenant : - réception (51), en provenance d’un terminal client (T1), de données d’utilisateur (DT1) comprenant des données d’agenda (DT1a) d’un utilisateur, des données de localisation (DT1b) de l’utilisateur et des données de préférence (DT1c) indiquant des préférences de déplacement de l’utilisateur ; - détection (52), à partir des données d’utilisateur, d’un besoin de déplacement de l’utilisateur pour effectuer un déplacement (10) ; - réception (53), en provenance du véhicule via une communication (L1) de type véhicule-vers-le-Cloud, dite V2C, de données de véhicule (DT2) comprenant des données de localisation (DT2a) du véhicule et des données de capacité (DT2b) indiquant une capacité d’accueil du véhicule ; - si les données de véhicule satisfont le besoin de l’utilisateur conformément aux données d’utilisateur, génération (54) d’une recommandation (DT3) de partage de véhicule, ladite recommandation identifiant le véhicule (2) comme candidat de mise en partage pour réaliser ledit déplacement ; et - envoi (55), au terminal client (T1), de la recommandation (DT3) de partage de véhicule. Procédé selon la revendication 1, le procédé comprenant : - détermination, à partir des données d’utilisateur (DT1), d’habitudes de déplacement de l’utilisateur ; le besoin de déplacement étant détecté à partir des habitudes de déplacement de l’utilisateur. Procédé selon la revendication 1 ou 2, dans lequel les habitudes de déplacement comprennent un déplacement régulier que l’utilisateur (UR1) effectue régulièrement selon les données d’utilisateur (DT1). Procédé selon l’une quelconque des revendications précédentes, dans lequel les données de véhicule (DT2) sont reçues via la communication V2C (L1) établie entre le dispositif de traitement (DV1) et une unité de contrôle télématique (DV2) embarquée dans le véhicule (2). Procédé selon l’une quelconque des revendications précédentes, dans lequel la recommandation (DT3) de partage de véhicule est automatiquement générée, et envoyée, au terminal client (T1) indépendamment d’une quelconque requête de recommandation de partage de véhicule. Procédé selon l’une quelconque des revendications précédentes, dans lequel le procédé comprend : - détection, à partir des données de localisation (DT1b) de l’utilisateur, que ledit utilisateur est positionné dans une zone associée à un arrêt de transport en commun (4) ; dans lequel la recommandation (DT3) de partage de véhicule est généré sur détection d’un premier évènement lié au transport en commun. Procédé selon l’une quelconque des revendications précédentes, dans lequel le procédé comprend : - suivi des données d’utilisateur (DT1) tandis que l’utilisateur (UR1° est en cours de réalisation du déplacement (10) à bord du véhicule (2) ; - sur détection d’un deuxième évènement indiquant un problème lié au déplacement en cours, génération d’une nouvelle recommandation de partage à partir d’autres données de véhicule reçues par communication V2C depuis un autre véhicule pour proposer une solution alternative au besoin de déplacement de l’utilisateur, et envoi de la nouvelle recommandation de partage au terminal client (T1). Programme d’ordinateur (PG1) comportant des instructions pour la mise en œuvre du procédé selon l’une quelconque des revendications précédentes, lorsque ces instructions sont exécutées par un processeur (40). Support d’enregistrement (41) lisible par un ordinateur sur lequel est enregistré un programme d’ordinateur (PG1) comprenant des instructions pour l’exécution des étapes du procédé selon l’une des revendications 1 à 7. Dispositif (DV1) de traitement pour la mise en partage d’un véhicule (2), ledit dispositif comprenant une mémoire (41) associée à au moins un processeur (40) configuré pour la mise en œuvre des étapes du procédé selon l’une quelconque des revendications 1 à 7.