Brevet FR3097675A1 — publié le 20201225

Description Titre de l'invention : Procédé et système de gestion de places de sta- tionnement Domaine technique. [0001] L'invention concerne un procédé et un système de gestion de place de stationnement. [0002] Le domaine de l'invention concerne le domaine technique de la transmission d'instructions pour contrôler des places de stationnement. Etat de la technique. [0003] Généralement, l'utilisation de places de stationnement - où places de parking - publiques ou privées, est basée sur le principe du premier arrivé, premier servi. Les embouteillages sont fréquents lorsque toutes les places de stationnement sont occupées dans une zone géographique et que des conducteurs sont obligés d'attendre que des places se libèrent. De plus, les conducteurs peuvent être frustrés par la recherche d'une place de stationnement et découragés de se rendre dans des zones géographiques où il est difficile de stationner. [0004] Les documents brevets US2014/0249742, US2018/0137439, US7834778, US2014/0236645, W02016/6084041 ou W02018/232889 décrivent différents systèmes et procédés pour gérer des réservations de places de stationnement de sorte que le conducteur soit orienté efficacement vers des places de stationnement disponibles et identifiées. Ces systèmes permettent généralement à un conducteur de réserver à l'avance une place stationnement disponible. Toutefois, si aucune place de stationnement n'est disponible au moment de la réservation, aucune réservation ne peut être effectuée. 100051 Le document US2012/0095812 permet de résoudre en partie cet inconvénient. Ce document décrit un procédé de gestion de places de stationnement. Ces places sont associées à indicateur de temps de stationnement pilotés par un contrôleur configuré pour allouer un temps de stationnement autorisé. Ce système permet de moduler le temps de stationnement autorisé en fonction d'une réservation d'une place de stationnement. Par exemple, un conducteur souhaite réserver une place à une heure déterminée. L'indicateur peut alors afficher le temps restant jusqu'à l'heure de réservation (par exemple décompte de 60 minutes 1 heure avant la réservation), de sorte que les autres conducteurs savent le temps pendant lequel ils peuvent garer leur véhicule sur ladite place et l'heure à laquelle ils devront la libérer. Le processus permettant de moduler le temps de stationnement autorisé est ici initié par une action volontaire du conducteur, à savoir la réservation effective d'une place de stationnement. Cette réservation préalable est l'élément déclencheur du processus de mo- 2 dulation. Un conducteur n'ayant pas fait de réservation préalable, ne peut donc pas être assuré de trouver une place de stationnement. [0006] Un objectif de l'invention est de remédier à cet état des choses. Un autre objectif de l'invention est de permettre à des conducteurs de trouver efficacement des places de stationnement disponibles, même en l'absence de toute réservation préalable. Encore un autre objectif de l'invention est de rendre des places de stationnement disponibles afin de réduire les embouteillages dans les rues et d'améliorer l'expérience de conducteurs souhaitant se garer. Présentation de l'invention. [0007] La solution proposée par l'invention est un procédé de gestion de places de sta- tionnement pour véhicules, lesquelles places sont localisées dans une zone géographique et sont associées à un contrôleur configure pour allouer une ou plusieurs caractéristiques de stationnement auxdites places. Le procédé comporte les étapes suivantes: - récolte et stockage de données historiques de navigation de véhicules identifiés et/ ou de conducteurs identifiés, - analyse statistique desdites données stockées pour prédire l'utilisation des places par les véhicules identifiés et/ou les conducteurs identifiés, - modification d'une ou plusieurs caractéristiques de stationnement allouées par le contrôleur en fonction de la prédiction d'utilisation des places. [0008] La modification des caractéristiques de stationnement des places intervient au moment où un conducteur/véhicule identifié est potentiellement censé arriver dans une zone géographique. Le processus n'est plus initié par une action préalable du conducteur, mais par le résultat d'une analyse statistique. Cette dernière est basée sur des observations de navigation à partir desquelles est établit des hypothèses plausibles permettant de prédire l'utilisation de places, par des véhicules identifiés et/ou des conducteurs identifiés, à partir d'une heure d'arrivée, et dans une zone géographique déterminée. Cette gestion dynamique des places permet d'augmenter l'offre de sorte qu'un conducteur n'a plus besoin de faire une réservation préalable d'une place de stationnement pour trouver à se garer. Tl est quasiment assuré de trouver une place libre à son arriver dans la zone géographique. Les embouteillages dans les rues sont de fait réduit et l'expérience du conducteur améliorée. [0009] D'autres caractéristiques avantageuses de l'invention sont listées ci-dessous. Chacune de ces caractéristiques peut être considérée seule ou en combinaison avec les caractéristiques remarquables définies ci-dessus, et faire l'objet, le cas échéant, d'une ou plusieurs demandes de brevet divisionnaires: - Selon un mode de réalisation, le procédé comprend les étapes suivantes : - récolte et stockage de données historiques d'occupation des places ; - détermination d'un nombre 3 de places libres faisant suite à la prédiction d'utilisation des places ; - calcul d'un taux d'occupation desdites places libres, lequel calcul est basé sur une analyse statistique desdites données historiques stockées. - Selon un mode de réalisation, le procédé comprend une étape de sélection d'au moins une caractéristique de stationnement à modifier parmi plusieurs caractéristiques de stationnement allouée par le contrôleur, laquelle sélection dépend du taux d'occupation calculé. - Selon un mode de réalisation, le procédé consiste à ne modifier la ou les caractéristiques de stationnement que si le taux d'occupation calculé est supérieur ou égal à une valeur seuil. - Selon un mode de réalisation, le procédé comprend une étape de nouvelle modification d'au moins une caractéristique de stationnement allouée à une place de stationnement lorsque ladite place est utilisée par un véhicule identifié et/ou un conducteur identifié. - Selon un mode de réalisation, le procédé consiste à moduler la durée du temps de stationnement autorisé alloué par le contrôleur aux places et/ou à moduler la tarification appliquée par le contrôleur lors de l'utilisation des places et/ou à placer les places dans un statut « réservé ». - Selon un mode de réalisation, le procédé comprend une étape d'estimation d'une heure d'arrivée d'au moins un des véhicules identifiés et/ou d'au moins un des conducteurs identifiés, dans la zone géographique, la ou les caractéristiques de stationnement étant modifiées avant ladite heure d'arrivée estimée. - Selon un mode de réalisation, le procédé comprend les étapes suivantes : - modification d'une ou plusieurs caractéristiques de stationnement avant l'heure d'arrivée estimée ;- modification d'une autre ou plusieurs autres caractéristiques de stationnement à partir de l'heure d'arrivée estimée. - Selon un mode de réalisation, le procédé comprend les étapes suivantes : - modification d'une ou plusieurs caractéristiques de stationnement si, avant l'heure d'arrivée estimée, une place est occupée par un véhicule non identifiés et/ou un conducteur non identifiés ; - modification différente de ladite ou lesdites caractéristiques si, à partir de l'heure d'arrivée estimée, ladite place est occupée par un véhicule identifiés et/ou un conducteur identifiés. [0010] Un autre aspect de l'invention concerne un système de gestion de places de sta- tionnement pour véhicules, lesquelles places sont localisées dans une zone géographique et sont associées à un contrôleur configuré pour allouer des caractéristiques de stationnement auxdites places, le système comportant : - une base de données dans laquelle sont identifiées des véhicules et/ou des conducteurs, - un moyen pour récolter des données historiques de navigation des véhicules identifiés et/ou des conducteurs identifiés, - une base de données dans laquelle lesdites données récoltées sont stockées, - un serveur informatique adapté pour : -- faire une analyse statistique desdites données stockées pour prédire l'utilisation des places par les véhicules identifiés et/ou les conducteurs identifiés, -- générer et transmettre au contrôleur des instructions pour modifier les caractéristiques dc stationnement allouées par ledit contrôleur, en fonction des prédictions d'utilisation des places. [0011] Encore un autre aspect de l'invention concerne un système comprenant un serveur in- formatique (SERV) configurés pour mettre en oeuvre le procédé selon l'une des caractéristiques précédentes. [0012] Encore un autre aspect de l'invention concerne un produit programme d'ordinateur comprenant des instructions de code pour l'exécution d'un procédé selon l'une des caractéristiques précédentes, lorsqu'il est exécuté par une unité de traitement d'un serveur informatique. Brève description des figures. [0013] D'autres avantages et caractéristiques de l' invention apparaîtront mieux à la lecture de la description d'un mode de réalisation préféré qui va suivre, en référence aux dessins annexés, réalisés à titre d'exemples indicatifs et non limitatifs et sur lesquels : [fig.1] illustre un exemple dc réalisation d'un système pour la mise en oeuvre de l' invention, [fig.2] illustre un exemple dc résultat d'une analyse statistique des données historiques de navigation, [fig.3] est un logigramme illustrant des étapes d'un processus informatique peimettant au serveur de définir des zones géographiques, [fig.4] est un logigramme illustrant des étapes d'un processus informatique peimettant au serveur d'estimer une heure d'arrivée, [fig.5] est un logigramme illustrant des étapes du procédé selon l'invention, selon un mode de réalisation, [fig.6] est un logigramme illustrant des étapes du procédé selon l'invention, selon un autre mode de réalisation. Description des modes de réalisation. [0014] Le procédé et le système objets de l'invention engendrent des manipulations d'éléments physiques, notamment des signaux (électriques ou magnétiques) et des données numériques, capables d'être stockés, transférés, combinés, comparés, et permettant d'aboutir à un résultat souhaité. [0015] L'invention met en oeuvre une ou plusieurs applications informatiques exécutées par des équipements ou serveurs informatiques. Par souci de clarté, il faut comprendre au sens de l'invention que « un équipement ou serveur fait quelque chose » signifie « l'application informatique exécutée par une unité de traitement de l'équipement ou du serveur fait quelque chose ». Tout comme « l'application informatique fait quelque chose » signifie « l'application informatique exécutée par l'unité de traitement de l'équipement ou du serveur fait quelque chose ». [0016] Encore par souci de clarté, la présente invention est susceptible de faire référence à un ou plusieurs « processus informatiques logiques ». Ces derniers correspondent aux actions ou résultats obtenus par l'exécution d'instructions de différentes applications informatiques. Aussi, il faut également comprendre au sens de l'invention que « un processus informatique logique est adapté pour faire quelque chose » signifie « les instructions d'une application informatique exécutées par une unité de traitement font quelque chose ». [0017] Encore par souci de clarté, les précisions suivantes sont apportées à certains termes utilisés dans la description et les revendications : - « Ressource informatique » peut être compris de façon non limitative comme : composant, matériel, logiciel, fichier, connexion à un réseau informatique, quantité de mémoire RAM, espace de disque dur, bande passante, vitesse de processeur, nombre de CPU, etc. - « Serveur informatique » peut être compris de façon non limitative comme : dispositif informatique (matériel ou logiciel) comportant des ressources informatiques pour réaliser les fonctions d'un serveur et qui offre des services, ordinateur, pluralité d'ordinateurs, serveur virtuel sur intemet, serveur virtuel sur Cloud, serveur virtuel sur une plate-forme, serveur virtuel sur une infrastructure locale, réseaux de serveurs, cluster, noeud, ferme de serveurs, ferme de noeuds, etc. - « Service » peut être compris de façon non limitative comme l'ensemble des fonctionnalités proposé et assuré par un serveur et/ou par au moins un équipement connecté audit serveur par l'intermédiaire d'un réseau. Le service peut comprendre par exemple, les fonctionnalités suivantes : la mise à disposition automatique de places de stationnement, la réservation d'un véhicule, la localisation d'un véhicule, le verrouillage/ déverrouillage à distance d'un véhicule partagé, etc. - « Requête » désigne un ordre d'exécution pouvant suivre un protocole de communication et comprenant des paramètres en entrée (question, informations, ...) et éventuellement des paramètres en retour (réponse, information, ...), pouvant se présenter dans un format lié au protocole employé. - « Unité de traitement » peut être compris de façon non limitative comme : processeur, microprocesseurs, CPU (pour Central Processing Unit). 6 - « Matériel itennatique » représente une ou plusieurs pièces détachées d'un équipement informatique et peut être compris de façon non limitative comme hardware. - « Application informatique » peut être comprise comme : logiciel, programme informatique, software, etc. - « Réseau informatique » peut être compris de façon non limitative comme : bus informatique, réseau personnel (PAN), réseau local (LAN, WLAN, ..), réseau étendu (WAN), réseau internet, réseau intranet, réseau extranct. Le réseau informatique est un ensemble d'équipements informatiques reliés entre eux pour échanger, de manière sécurisée ou non, des informations et/ou des données selon un protocole de communication (ISDN, Ethernet, ATM, IP, CLNP, TCP, HTTP, ...). - « Base de données » peut être comprise de façon non limitative comme un ensemble structuré et organisé de données enregistrées sur des supports accessibles par des équipements informatiques et pouvant être interrogées, lues et mises à jour. Des données peuvent y être insérées, récupérées, modifiées et/ou détruites. La gestion et l'accès à la base de données peuvent être assurés par un ensemble d'applications informatiques qui constituent un système de gestion de base de données (SGBD). - « Véhicule partagé » ou véhicules en libre-service (en anglais « car sharitzg ») est un véhicule mis à la disposition de « clients » ou membres. Le véhicule peut être : une voiture autonome, une voiture (moteur thermique et/ou électrique), un deux-roues motorisé (moteur thermique et/ou électrique), un vélo (classique ou avec assistance électrique), une trottinette (classique ou avec assistance électrique), une planche a roulette, un monocycle électrique, un gyropode, un bateau, etc. - « Floue » ou «parc » peut être compris comme une pluralité de véhicules appartenant ou gérés ou affiliés à une société, une agence publique, une coopérative, une association, un groupe d'individus, etc. - Tel qu'utilisé ici, sauf indication contraire, l'utilisation des adjectifs ordinaux « premier», «deuxième», etc., pour décrire un objet indique simplement que différentes occurrences d'objets similaires sont mentionnées et n'implique pas que les objets ainsi décrits doivent être dans une séquence donnée, que ce soit dans le temps, dans l'espace, dans un classement ou de toute autre manière. Architecture. [0018] Un service de véhicules partagé est un système dans lequel une société, une agence publique, une coopérative, une association, ou un groupe d'individus, met à la disposition de clients ou membres du service une flotte e véhicule Plutôt que de disposer d'un véhicule personnel, l'utilisateur du service dispose d'un véhicule qu'il ne paye que pour la durée de son besoin. En d'autres termes, lorsqu'un utilisateur utilise un véhicule partagé, il est facturé d'un certain montant. Le montant facturé dépendant gé- 7 néralement du nombre de kilomètres parcourus et/ou du temps d'utilisation du véhicule et/ou du modèle ou type de véhicule. Le reste du temps, le véhicule est destiné à être utilisé par d'autres membres. Un des avantages des véhicules partagés réside dans le fait qu'un utilisateur peut libérer son véhicule où il le souhaite. La position de ces véhicules n'est donc pas figée dans le temps, mais mouvante (en anglais freefloating), de sorte qu'il est généralement difficile de prédire à l'avance leur emplacement. [0019] Sur la figure 1, le système pour la mise du procédé objet de l'invention comprend un serveur informatique SERV connecté à une base de données BAS, des véhicules de transport CARI, CAR2, des équipements informatiques EQ1, EQ), des places de stationnement PLI-PL4 localisées dans une zone géographique GEO déterminée, des indicateurs de temps de stationnement autorisé TPS1-TPS4 associés à chacune des places PL1-PL4. Les indicateurs TPS1-TPS4 sont pilotés par un contrôleur CONT. [0020] Les équipements informatiques EQi appartiennent à des conducteurs. Ils comportent chacun une interface de communication, par exemple GSM, 3G, 4G ou Wifi, pour établir une liaison de communication sans fil avec le serveur SERV au travers d'un réseau informatique, par exemple un réseau internet, s'appuyant sur une infrastructure permettant d'acheminer des communications sans fil provenant de l'équipement EQ. Ce dernier est préférentiellement un téléphone intelligent (Smartphone), une tablette numérique, un ordinateur portable, etc. Il comprend les ressources informatiques, par exemple un code exécutable d'une application informatique téléchargeable, permettant de réaliser des fonctions du procédé de l'invention. [0021] Selon un mode de réalisation, chaque conducteur est identifié auprès d'un serveur de gestion de droits qui peut être ou non le serveur distant SERV. Pour simplifier la suite de la description, on considère que le serveur de gestion de droits est le serveur SERV. Un conducteur identifié auprès du serveur SERV peut alors accéder à un service correspondant à la réservation automatique de place de stationnement. L'identification d'un conducteur passe par son enregistrement auprès du serveur. Cet enregistrement peut être réalisé auprès d'un service web d'un serveur distant associé au service. L'enregistrement comporte par exemple l'enregistrement d'un identifiant conducteur et d'une adresse réseau de l'équipement conducteur EQ. El peut s'agir d'un port, d'une adresse IP, d'une adresse MAC ou toute autre adresse ou combinaisons d'éléments constituants des adresses permettant d'identifier un équipement conducteur EQi. Selon un mode de réalisation, un conducteur est préinscrit à partir d'un logiciel et est connus du fait que son identifiant est enregistré dans la base de données BAS. Selon un mode de réalisation, la base de données BAS associe un véhicule CAR à un conducteur lorsque ce dernier utilise ledit véhicule. Selon un mode de réalisation, le serveur SERV comporte une fonction permettant de réaliser les associations. 8 [0022] Les véhicules CAR1-CAR2 peuvent être des voitures autonomes, des voitures électriques, des voitures en covoituragc, des deux-roues motorisés, des vélos, des trottinettes, des planches à roulettes, des monocycles électriques, des gyropodcs, etc. Les véhicules CARI-CAR2appartiennent préférentiellement à une flotte de véhicules partagés. Chaque véhicule CAR; est associé à un numéro d'identification unique. Chaque véhicule CAR; dispose avantageusement d'au moins un équipement VEQ; comportant une interface de communication, par exemple GSM, 3G, 4G ou Wifi, pour établir une liaison de communication sans fil avec le serveur SERV au travers d'un réseau informatique. Les équipements VEQ; sont préférentiellement des ordinateurs embarqués comprenant les ressources informatiques permettant de réaliser des fonctions du procédé de l'invention. Le serveur SERV attribut des statuts à chaque véhicule CAR: - statut dit « Disponible à la réservation » : le véhicule est stationné (garé) et non réservé, - statut dit « Indisponible à la réservation » : soit le véhicule est stationné mais déjà réservé par un utilisateur (statut «Indisponible-Réservé »), soit le véhicule est en cours de fonctionnement (statut « Indisponible-en fonctionnement »). D'autres types de statuts similaires peuvent être prévus. [0023] Le serveur SERV met régulièrement à jour, préférentiellement en temps réel, la base de données des véhicules CAR,-CAR,. Cette base de données BAS regroupe notamment : l'identifiant de chaque véhicule, leur statut (« Disponible à la réservation » ou « Indisponible à la réservation »), et leur position géographique. D'autres informations et/ou données peuvent être regroupées dans la base de données BAS, le cas échéant. [0024] L'information sur le statut d'un véhicule CARi est transmise au serveur SERV en temps réel ou a des intervalles de temps prédéfinis (par exemple toutes les 5 minutes). Cette information peut être transmise au serveur SERV : - par l'équipement embarqué VEQ; du véhicule CARi suite à une détection d'un évènement. Cet évènement est par exemple généré automatiquement dès le démarrage du véhicule CAR; ou par une action du conducteur sur une commande spécifique aménagé sur ledit véhicule. Cette commande peut être actionnée lorsque le conducteur a libéré le véhicule après un trajet. Le statut passe alors de « Indisponible à la réservation » à « Disponible à la réservation », - par l'équipement EQ; du conducteur du véhicule CAR;, consécutivement à une action dudit conducteur sur son équipement. Le conducteur peut par exemple actionner une touche dédiée affichée sur un écran tactile de son équipement, après avoir stationné et libéré son véhicule. Le statut passe alors de « Indisponible à la réservation » à « Disponible à la réservation ». 9 Lorsque le serveur SERV reçoit une requête de réservation de la part d'un conducteur abonné à un service de partage de véhicules, et qu'il peut faire droit à cette requête (c'est-à-dire qu'un véhicule est disponible à la réservation), ledit serveur fait passer le statut d'un véhicule de « Disponible à la réservation » à « Indisponible à la réservation ». Cette requête de réservation peut par exemple être générée via un équipement électronique ou via une application informatique auquel le conducteur est abonné. [0025] La position géographique de chaque véhicule CAR; peut être obtenue par satellite (système GPS ou Gal ilco) ou par un système de triangulation (par exemple, un système utilisant les cellules d'un réseau 4G) ou par une combinaison des deux systèmes de localisation. L'équipement VEQ, d'un véhicule CAR, comporte avantageusement un composant, par exemple un composant GPS, permettant d'obtenir une information de géo-localisation qui peut être récupérée par le serveur SERV. Le serveur SERV peut récupérer automatiquement cette information en interrogeant en temps réel ou a intervalles de temps régulier (par exemple toutes les 5 minutes), les équipements VEQi des véhicules CARi. Les équipements VEQi peuvent également transmettre automatiquement cette information au serveur SERV (sans répondre à une requête d'interrogation), en temps réel ou a intervalles de temps régulier (par exemple toutes les 5 minutes). [0026] Selon une alternative, la position géographique d'un véhicule CARi peut cor- respondre à une position définie à partir d'une interface de saisie d'un équipement EQ; d'un conducteur utilisant ledit véhicule. Par exemple, le conducteur peut évaluer une position à partir d'une carte interactive affichée sur une interface graphique de son équipement EQ;. Cette position est ensuite transmise au serveur SERV. [0027] Selon une autre alternative, la position géographique d'un véhicule CAR; peut cor- respondre à la position de l'équipement EQ; du conducteur utilisant ledit véhicule. Ce dernier peut donc être dépourvu d'équipement VEQ;. L'équipement EQ; comporte avantageusement un composant, par exemple un composant GPS, permettant d'obtenir une information de géo-localisation qui est transmise au serveur SERV. Le serveur SERV peut récupérer automatiquement cette information en interrogeant en temps réel ou a intervalles de temps régulier, les équipements EQ; des conducteurs. Les équipements EQi peuvent également transmettre automatiquement cette information au serveur SERV (sans répondre à une requête d'interrogation), en temps réel ou a intervalles de temps régulier. Cette information de géo-localisation provenant d'un équipement EQ;, permet également au serveur SERV de connaître la position géographique d'un conducteur abonné au service, mais n'utilisant pas un véhicule CARi. [0028] Les places de stationnement PL; sont des places situées dans des rues, sur des trottoirs, dans des parkings publics ou privés, ou dans n'importe quel lieu physique. Ces places PL, sont localisées dans la zone géographique GEO. Cette zone géographique peut correspondre à une rue, en regroupement de rue, un quartier, un lieu précis tel qu'un parking, etc. La position géographique de chaque place PL est avantageusement connue du serveur SERV et enregistrée dans la base de données BAS. Chaque place PL est avantageusement associée à un numéro d'identification unique enregistré dans la base de données BAS. [0029] Chaque place PLI-PLI est également avantageusement équipée d'un capteur CP1-CP4 pour déterminer si ladite place est occupée par un véhicule. Chaque capteur CP; peut être connecté à un indicateur de temps de stationnement autorisé TPS' au contrôleur CONT, ou au serveur SERV. Les capteurs CP1-CP4 peuvent être mis en réseau via une connexion filaire ou sans fil. La détermination de l'occupation ou de la disponibilité d'une place PL est transmise en temps réel au contrôleur CONT et/ou au serveur SERV. [0030] Les capteurs CP,-CP4 peuvent être des capteurs optiques (ex : caméras, détecteurs photoélectriques), des capteurs de présence inductifs (ex : à boucle inductive), des capteurs de présence capacitifs, des capteurs de présence magnétiques (ex : magnétomètres), des capteurs de présence à ultrason, etc. On prévoit avantageusement un capteur par place de stationnement, mais un capteur (par exemple une caméra) pourrait être positionné pour surveiller simultanément plusieurs places. [0031] en fonction de l'état des capteurs CP1-CP4, le serveur SERV peut attribuer des statuts à chaque place PLI-PL4, et notamment les statuts suivants : - statut dit «11011 occupée » : le capteur ne détecte aucun véhicule stationné sur la place, - statut dit « occupée » : le capteur détecte un véhicule stationné sur la place. [0032] Chaque place PLI-PL peut être équipée d'un indicateur TPS1-TPS4 de temps de sta- tionnement autorisé et/ou de la tarification appliquée lors de l'utilisation desdites places. Chaque indicateur TPS; est connecté de manière filaire ou sans fil au contrôleur CONT. Ils peuvent également être mis en réseau, un seul indicateur étant connecté au contrôleur CONT et jouant le rôle de maître, les autres indicateurs étant des esclaves. Les indicateurs TPS1-TPS4 indiquent pendant quelle durée et/ou à quel tarif les véhicules peuvent utiliser les places PLI-PLt. [0033] Chaque indicateur TPSi peut comporter une interface physique (par exemple un écran LCD et/ou une enceinte) indiquant de manière visuelle et/ou sonore le statut d'une place PL et/ou le temps de stationnement autorisé et/ou le tarif appliqué. Par exemple, une place PL peut avoir les statuts suivants : - statut dit « disponible » : aucun véhicule n'est stationné sur la place, n'importe quel véhicule (identifié ou non identifié par le serveur SERV) pouvant se garer sur ladite place, 11 - statut dit « indisponible» : un véhicule est stationné sur la place, aucun autre véhicule (identifié ou non identifié par le serveur SERV) pouvant se garer sur ladite place ; ou la place est temporairement condamnée. - statut dit « réservé » : aucun véhicule n'est stationné sur la place, mais seul un véhicule identifié ou un type de véhicule identifié (ex : un véhicule partagé), ou un conducteur identifié (ex : un conducteur abonné à un service de véhicule partagé), est autorisé à se garer sur ladite place. Chaque statut peut être clairement affiché sur l'interface des indicateurs TPS1-TPS4 et/ ou être associé à un code couleur. Par exemple bleu pour un statut « disponible », rouge pour un statut « indisponible » et jaune pour un statut « réservé ». Ces codes couleur peuvent être mis en oeuvre à l'aide de sources lumineuses intégrées dans les indicateurs TPSI-TPS4. [0034] Le serveur SERV met régulièrement à jour, préférentiellement en temps réel, la base de données des places PLi. La base de données BAS regroupe notamment : l'identifiant de chaque place, leur position géographique, l'historique de leur statut (« non occupée » ou « occupée », « disponibles », « indisponible » « réservée », à quelle date, quelle heure, pendant combien de temps, ...). D'autres informations et/ou données relatives aux places PLi peuvent être regroupées dans la base de données BAS, le cas échéant. [0035] Le temps de stationnement autorisé est également clairement indiqué sur l'interface des indicateurs TPS1-TPS4. Par exemple 2 heures, 1 heures, 10 minutes, 5 minutes, etc. L'affichage du temps peut se présenter sous la forme d'un compte à rebours démarrant dès qu'un véhicule est détecté sur une place PLi et indiquant le temps alloué restant. [0036] La tarification appliquée peut également être indiquée sur l'interface des indicateurs TPS1-TPS4. Par exemple 0,2 f/minute, 10f/heure, etc. [0037] Dans un autre mode de réalisation, l'interface indiquant le temps de stationnement autorisé et/ou le statut d'une place et/ou la tarification appliquée, peut être virtuelle et s'afficher sur un écran de l'équipement EQ; d'un conducteur ou sur un écran de l'équipement VEQi d'un véhicule CAR; stationné sur une place. [0038] Dans un autre mode de réalisation, un seul indicateur TPS; peut être prévu pour plusieurs places PLI-PL, avec des indications indiquant le statut de chacune desdites places et/ou le temps de stationnement autorisé et/ou la tarification appliquée. [0039] Le contrôleur CONT se présente sous la forme d'un ordinateur ou d'une unité de traitement comportant toutes les ressources et matériels informatiques permettant de réalisées les fonctionnalités décrites dans la présente description. Le contrôleur CONT peut être intégré dans un des indicateur TPS, ou être disposé dans un caisson dédié situé à proximité desdits indicateurs. Le contrôleur CONT est configuré pour allouer des caractéristiques de stationnement aux places PLI-PL4, ces caractéristiques pouvant 12 être modifiées en réponse à la réception d'instructions provenant du serveur SERV. Sur la heure 1, le contrôleur permet notamment de piloter les indicateurs TPS1-TPS4. Il reçoit des instructions provenant du serveur SERV et transmet des instructions aux indicateurs TPSI-TPS4, notamment des instructions leur permettant d'indiquer le statut d'une place PL; et/ou le temps de stationnement autorisé et/ou la tarification à appliquer (i.e. les caractéristiques de stationnement). [0040] Le contrôleur CONT comporte une interface de communication, par exemple GSM, 3G, 4G ou Wifi, pour établir une liaison de communication sans fil avec le serveur SERV au travers d'un réseau informatique, par exemple un réseau internet. Le contrôleur peut ainsi faire remonter vers le serveur SERV, en temps réel ou à intervalles de temps réguliers, diverses informations telles que : l'état des capteurs CP, - CP4 et donc le statut de chacune des places PL1-PL4 (« occupée » ou « non occupée ») ; le temps alloué à chacune desdites places ; le temps alloué restant pour chaque place occupée ; un dépassement du temps alloué ; la tarification appliquée, etc. Procédé. [0041] Selon une caractéristique de l'invention, on construit un modèle prédictif basé sur une analyse statistique de données d'observation, dans le but de prédire l'utilisation des places PL1-PL4, à une heure donnée, par des conducteurs/véhicules identifiés. L'objectif est que des places PLI-PL, soient disponibles lorsque les véhicules CARI - CAR2arrivent dans la zone géographique GEO. Des places peuvent ainsi être rendues libres pour des conducteurs et/ou des véhicules « prioritaires » afin de réduire les embouteillages et la pollution. Ces conducteurs/véhicules prioritaires sont par exemple des conducteurs ayant adhérés à un service de véhicules partagés, des véhicules électriques, des véhicules en covoituragc, etc. Il peut également s'agir de livreurs et/ou de camions dont on souhaite qu'ils puissent être déchargés à une heure déterminée en étant garé sur des places de stationnement, plutôt qu'au milieu d'une voie de circulation. Les conducteurs/véhicules prioritaires qu'il est souhaitable de privilégié, sont ici ceux identifiés par le serveur SERV. [0042] Les données d'observation sont des données historiques de navigation de véhicules identifiés et/ou de conducteurs identifiés. La base de données BAS regroupant notamment l'identifiant de chaque véhicule identifié CAR; et/ou de chaque conducteur identifié et leur position géographique respective, le serveur SERV peut aisément déterminer, à partir de ces données récoltées, leurs parcours respectifs au cours d'une journée, d'une semaine, d'un mois, d'une année, etc. L'analyse statistique de ces données va permettre au serveur SERV d'anticiper le parcours des véhicules identifiés CAR1-CAR2 et/ou des conducteurs identifiés et d'estimer un nombre de véhicules susceptibles de se garer sur les places de stationnement PLI-PL,, à partir d'une heure d'arrivée dans une zone géographique dé- 13 terminée. [0043] L'analyse statistique repose sur un raisonnement automatisé du serveur SERV qui conduit à des déterminations probabilistes et/ou des déterminations fondées sur des statistiques. Le serveur SERV peut ainsi définir des actions à partir d'un ensemble d'événements observées et/ou à partir de données d'événements observées. L'analyse statistique des données peut être basée sur diverses techniques connues de modélisation de données, et préférentiellement un réseau bayésien. Un réseau bayésien est un modèle probabiliste représentant des variables aléatoires et leurs dépendances conditionnelles via un DAG (Directed Acyclic Graph) et des tables de probabilités. Il sert principalement à représenter une connaissance, donner une règle de décision, prévoir, et déterminer des hypothèses de causalité. L'homme du métier peut notamment se référer aux publications suivantes concernant les réseaux bayésiens : BRIDE, « Méthodes de construction de réseaux bayésietzs », Université de Strasbourg, Aout 2016, pages 1-34; HECKERMAN, «A bayesian approach ta lemming causal network », MSR-TR-95-04, MicrosoftResearch, 1995 ; PEARL, « Probabilistic Reasotzing in Intelligent Systems : Networks of Plausible Inference », Morgan Kaufmann Publishers, 1988). [0044] D'autres types d'analyse statistique peuvent être mise en oeuvre par le serveur SERV telles que : modèle de Markov, réseaux de neurones, modèles probabilistes, raisonnement fondés sur la logique et logique floue, échantillonnage de Gibbs, etc. [0045] La figure 2 illustre un exemple de résultat de cette analyse statistique. Les différentes zones géographiques A, 3, B13, C13, DI 3 représentent, par exemple, des quartiers ou un agencement de rues d'une ville. Ce découpage en zones géographiques peut être réalisé automatiquement par le serveur SERV. Ce dernier est par exemple adapté pour se connecter à une ou plusieurs bases de données d'un ou plusieurs sites intemet dédiés, notamment des sites de cartographie numérique (ex : https://fi-.mappy.com, hfips://www.viamichelin.ti-) pour récupérer un plan et le subdivisé en zones géographiques. Les zones A, et A sont dites « zones de départ » et les zones BI, DI, D2 et DI sont dites « zones d'arrivée ». [0046] La figure 3 est un logigramme illustrant des étapes d'un processus informatique permettant au serveur SERV de définir des zones géographiques. A l'étape E10, le serveur SERV sélectionne une aire géographique (ex: une ville) en récupérant une cartographie numérique auprès d'un site internet dédié par exemple. A l'étape El I, le serveur SERV segmente cette ah-e géographique en plusieurs zones géographiques (ex : un agencement de rues). A l'étape E12, le serveur SERV interroge la base de données BAS pour connaitre le nombre de place de stationnement dans chaque zone géographique. Selon un mode de réalisation, pour chaque zone géographique, le serveur SERV inten-oge la base BAS pour connaitre les places dont les coordonnées 14 géographiques sont incluses dans celles de ladite zone concernée. [0047] Par souci de clarté et de concision, la suite de la description fait seulement référence à l'observation du comportement de conducteurs identifiés par le serveur SERV. L'invention s'applique de manière identique à l'observation du comportement de véhicules identifiés par le serveur SERV. [0048] A un instant TO (par exemple un lundi à 18h, à la sortie des bureaux) le serveur SERV sait qu'il y a 6 conducteurs identifiés COND dans la zone de départ AI (ex : première zone de bureaux) et 5 conducteurs identifiés COND dans la zone de départ A3 (ex : seconde zone de bureaux). Ces informations proviennent notamment des positions géographiques des équipements EQ des conducteurs récupérées en temps réel par le serveur SERV. Ces informations peuvent également être prédites suite à une analyse statistique des positions géographiques historiques desdits équipements à l'instant TO. [0049] Grâce à l'analyse statistique des données historiques de navigation précitées, le serveur SERV prédit que pour les conducteurs COND situés dans la zone de départ A, : 17 % vont se diriger vers la zone d'arrivée D, (ex : zone commerciale), 50% vont se diriger vers la zone d'arrivée D2 (ex : zone d'habitation) et les 33% restant vont se diriger dans la zone d'arrivée DI (ex : centre-ville). Dans l'exemple de la figure 2, le serveur SERV prédit donc que : 1 conducteur va se diriger vers la zone d'arrivée DI, 3 conducteurs vont se diriger vers la zone d'arrivée D2 et 2 conducteurs vont se diriger vers la zone d'arrivée Di. [0050] Le serveur SERV peut également prédire que pour les conducteurs COND situés dans la zone de départ AI : 60 % vont se diriger vers la zone d'arrivée l31 (ex : zone d'habitation), et 40% vont se diriger dans la zone d'arrivée D. Dans l'exemple de la figure 2, le serveur SERV estime donc que : 3 conducteurs vont se diriger vers la zone d'arrivée B' et 2 conducteurs vont se diriger vers la zone d'arrivée D. [0051] De manière alternative ou complémentaire, au lieu d'anticiper le départ des conducteurs depuis les zones de départ Al et A' à l'instant TO, le SERV prédit leur arrivée dans les zones d'arrivée BI, D,. D2 et D. Ainsi, le serveur SERV peut prédire, qu'à un instant Ti (par exemple un lundi à 19h) : 3 conducteurs vont arriver dans la zone d'arrivée 131, 1 conducteur va ai-river dans la zone d'arrivée DI, 3 conducteurs vont arriver dans la zone d'arrivée D2 et 4 conducteurs vont arriver dans la zone d'arrivée D. Le nombre estimé de véhicules susceptibles d'atteindre chaque zone d'arrivée B', DI, D2 et II peut correspondre aux prédictions d'utilisation des places PL dans chacune desdites zones à l'instant Tl. [0052] L'heure d'arrivée T1 peut être estimée à partir d'une analyse statistique des positions géographiques historiques des conducteurs par le serveur SERV et/ou des données historiques des statuts des places PL. L'heure d'arrivée Ti peut également être calculée à partir de l'heure de départ TO et de la distance à parcourir entre les zones de départ et d'arrivée. La valeur de Tl calculée peut être pondérée par des données contextuelles telles que le jour de la semaine, le mois de la semaine, l'état réel du trafic ou des prédictions de trafic entre les zones de départ et d'arrivée et diverses autres variables aléatoires. Le serveur SERV peut notamment récupérer, auprès de sites internet dédiés, des données relatives au trafic routier entre une zone de départ et une zone d'arrivée. Ces données de trafic sont par exemple : trafic dense dans telle zone, ou trafic fluide dans telle autre zone, circulation fermée dans telle rue, travaux dans telle autre rue, etc. Le serveur SERV va alors prendre en compte ces données pour le calcul de la valeur de Ti. [0053] La figure 4 est un logigramme illustrant des étapes d'un processus informatique permettant au serveur SERV d'estimer une heure d'arrivée Tl . A l'étape E20, le serveur SERV détermine une heure de départ TO d'une zone de départ (ex : A1). A l'étape E21, le serveur SERV calcul la durée du trajet entre la zone de départ et une zone d'arrivée (ex : D3). A l'étape E22, le serveur SERV analyse l'état du trafic routier entre Ai et D3. En fonction du résultat de cette analyse, le serveur SERV ajuste la durée du trajet (étape E23) pour estimer l'heure d'arrivée Tl (étape E24). Les étapes E22 à E24 peuvent être réitérées en temps réel pour estimer au mieux, et de manière dynamique, l'heure d'arrivée Tl. [0054] En tout état de cause, l'heure d'arrivée Ti estimée par le serveur SERV peut différer d'une zone d'arrivée à l'autre, par exemple : 18h30 dans la zone B3, 18h45 dans la zone D1, 19h clans la zone D2, 19h30 dans la zone D. En outre, l'heure d'arrivée T 1 peut être une heure précise ou un seuil, par exemple de 18h30 à 19h dans la zone B', de 18h45 à 20h30 dans la zone DI, de 19h à 19h30 dans la zone D2, et de 19h30 à 21h dans la zone D. Un seuil d'heure d'arrivée est notamment déterminé par une analyse statistique des données historiques enregistrées dans la base de données BAS. [0055] Le serveur SERV détermine qu'il y a 4 places de stationnement PL dans la zone d'arrivée DI, 4 places de stationnement PL dans la zone d'arrivée D2 et 4 places de stationnement PL dans la zone d'arrivée DI. Ces informations proviennent notamment des différentes positions géographiques des places enregistrées dans la base de données BAS. De la même façon, le serveur SERV connaît, à un instant donné (TO et/ou : le statut de chacune de ces places (« non occupée », « occupée », « disponibles », indisponible », « réservée ») ; le temps initialement alloué à chacune desdites places ; le temps alloué restant pour chaque place occupée ; un éventuel dépassement du temps alloué ; etc. [0056] Selon un objectif de l'invention, les conducteurs COND doivent pouvoir facilement se garer sur des places de stationnement PL lorsqu'ils atteignent les zones d'arrivée 133, DI, D, et D3, sans qu'ils n'aient à faire une réservation préalable de place comme dans 16 les solutions connues de l'art antérieur. Les conducteurs doivent aisément pouvoir trouver des places disponibles dans les zones d'arrivée concernées, au moment où ils atteignent ladite zone ou avec un temps d'attente minimum. [0057] Une façon d'atteindre cet objectif consiste à modifier les caractéristiques de sta- tionnement allouées par les contrôleurs CONT,,,, CONT',, CONT2. CONT113cn fonction des prédictions d'utilisation des places PL dans chaque zone géographique BI, DI, D2, D3. Les caractéristiques de stationnement modifiées sont préférentiellement : le temps de stationnement alloué par les contrôleurs CONTB1, CONT,' CONT112, CONT '3 et/ou la tarification appliquée par lesdits contrôleurs auxdites et/ou le statut desdites places. [0058] En reprenant l'exemple de la figure 2, par analyse statistique, le serveur SERV prédit que 3 conducteurs vont arriver dans la zone d'arrivée B3 à partir d'une heure d'arrivée estimée Tl B3 (ex : entre 18h30 et 19h), que 1 conducteur/véhicule va arriver dans la zone d'arrivée DI à une heure d'arrivée estimée Tipi (ex : entre 18h45 à 20h30), que 3 conducteurs/véhicules vont arriver dans la zone d'arrivée D, à une heure d'arrivée estimée T1 '2 (CX : entre 19h à 19h30) et que 4 conducteurs/véhicules vont arriver dans la zone d'arrivée DI à une heure d'arrivée estimée T1 (ex : entre 19h30 à 21h). [0059] Le processus informatique logique conduisant à la modification des caractéristiques de stationnement est initié par le serveur SERV avant l'heure d'arrivée estimée, par exemple 30 minutes ou 60 minutes avant cette heure. Le processus peut être lancé à la même heure TO pour toutes les zones d'arrivée (par exemple 18h) ou à une heure spécifique pour chaque zone d'arrivée. [0060] Pour la zone d'arrivée DI, le serveur SERV lance le processus à 18h15 par exemple (TOD,). Il interroge la base de données BAS et analyse que sur les 4 places PL de la zone DI, une seule place est actuellement occupée ou indisponible (marquée par une croix sur la figure 2), les trois autres places étant libres, c'est-à-dire non occupées et disponibles. L'analyse statistique permet de prédire qu'un seul véhicule est susceptible de se garer sur les places de la zone d'arrivée D, entre 18h45 à 20h30. Le nombre de places libres (= 3) est ici supérieur au nombre de véhicules estimés (= 1). [0061] Selon un mode de réalisation, le serveur SERV ne fait rien dans ce cas. Il peut notamment calculer que le risque est faible de voire les trois places libres de la zone d'arrivée DI, occupées entre 18h15 (TOD,) et 20h30 (fin de TID1). Ce calcul de risque est par exemple basé sur une analyse statistique des données historiques d'occupation des places PL dans la zone DI enregistrées dans la base BAS (données relatives aux statuts « non occupée » ou « occupée », à quelle date, quelle heure, pendant combien de temps, ...). Le serveur SERV peut par exemple calculer la moyenne du temps où les places PL ont un statut « occupée » entre TODI et fin de TID1. Le taux d'occupation est alors facilement déduit du ratio : {temps d'occupation moyen calculé} / {temps entre 17 TO', et fin de T11111. Le serveur SERV peut notamment déduire de ces données que les places PL, dans la zone DH ont un taux d'occupation inférieure à 10% les lundis entre 18h15 et 20h30. Il y a donc une forte probabilité qu'au moins une place reste libre lorsque le conducteur arrivera dans la zone DI entre 18h45 et 20h30. [0062] Pour la zone d'arrivée B3, le serveur SERV lance le processus à 18h par exemple (TO B3). En interrogeant la base de données BAS, il analyse que les 4 places PL de la zone B3 sont toutes libres. Le serveur SERV a estimé que trois véhicules sont susceptibles de se garer sur les places de la zone d'arrivée B3. Le nombre de places libres (=4) est ici supérieur au nombre de véhicule estimé (=3), mais dans une moindre mesure que pour la zone DI. [0063] Selon une première hypothèse, le serveur SERV ne fait rien. Il calcule que le risque est faible de voire trois des quatre places libres de la zone d'arrivée B3, occupées entre 18h (TOB3) et 19h (fin de T] Bi). Ce calcul de risque est similaire à celui décrit au paragraphe précédent. Le serveur SERV fait préférentiellement une analyse statistique des données historiques enregistrées dans la base BAS, pour déterminer que les places PL de la zone B3, ont un taux d'occupation inférieure à 2 % les lundis entre 18h et 19h. Il y a donc une forte probabilité qu'au moins trois places restent libres lorsque les conducteurs/véhicules arriveront dans la zone -13,-; entre 18h30 et 19h. [0064] Selon une autre hypothèse, le serveur SERV analyse que les places PL de la zone B', ont un taux d'occupation élevée, par exemple égal ou supérieur à 50 %, tous les lundis entre 18h et 19h. Il y a donc un risque important que les conducteurs arrivant dans la zone B3 entre 18h30 et 19h ne trouvent pas tous une place libre. Le serveur SERV va dans ce cas moduler le temps de stationnement autorisé alloué par le contrôleur CONTR'. Par exemple, si le temps maximal de stationnement normalement alloué est de 120 minutes, le serveur SERV va abaisser ce temps à 10 minutes à partir de 18h. Le serveur SERV peut également initier un compte-à-rebours à partir de 18h pour que les places soient disponibles à partir de 18h30 (début de T1E3): un véhicule se garant sur une place libre à 18h aura un temps alloué de 30 minutes, un autre véhicule se garant sur une place libre à 18h20 aura une temps alloué de 10 minutes, un autre véhicule se garant sur une place libre à 18h25 aura une temps alloué de 5 minutes, etc. De manière alternative ou complémentaire, le serveur SERV peut également moduler la tarification appliquée par le contrôleur CONTE. Par exemple, si le tarif normalement appliqué est de 0,2 E/minute, le serveur SERV va augmenter ce tarif à 2E/minute à partir de 18h, de manière à rendre ce tarif prohibitif pour inciter les conducteurs à libérer les places le plus rapidement possible. Cette augmentation tarifaire peut être fixe ou progressive, pour être de plus en plus forte au fur et à mesure qu'on se rapproche de l'heure d'arrivée estimée. 18 Les instructions pour moduler le temps de stationnement et/ou la tarification sont générées par le serveur SERV et transmises au contrôleur CONT,33. Le contrôleur CONTE; pilote alors les indicateurs associés aux places libres PL pour qu'ils affichent le nouveau temps de stationnement autorisé maintenant alloué et/ou le nouveau tarif appliqué. Cet abaissement du temps de stationnement autorisé et/ou l'augmentation de la tarification permet d'accélérer le turn-over des places de stationnement. D'autres véhicules et/ou conducteurs non identifié par le serveur SERV sont autorisés à se garer sur les places PL de la zone B3, mais ils sont incités à libérer lesdites places plus rapidement, de sorte que les trois conducteurs identifiés COND arrivant dans la zone B3 entre 18h30 (début de T1,3) et 19h (fin de T1,33), auront une forte probabilité de trouver une place disponible, ou à tout le moins, avec un temps d'attente limité. [0065] Selon un autre mode de réalisation, au lieu de moduler le temps de stationnement et/ ou la tarification, le serveur SERV modifie le statut des trois places libres PL de la zone B3 pour les placer dans un statut « réservé ». Les instructions pour changer le statut sont générées par le serveur SERV et transmises au contrôleur CONTE-,., qui pilote les indicateurs. Ces derniers vont afficher sur leur interface ce statut : seuls les conducteurs identifiés par le serveur SERV sont autorisés à se garer sur les places PL de la zone [0066] Selon un autre mode de réalisation, le serveur SERV module le temps de sta- tionnement et/ou la tarification, et modifie également le statut des trois places libres PL de la zone B3. Par exemple, le serveur SERV abaisse le temps de stationnement et/ ou augmente la tarification entre 18h (TOB3) et 18h30 (début de T13). Et à partir de 18h30 et jusqu'à 19h (fin de T1E3), chaque place libre est automatiquement placée dans un statut « réservé » et/ou soumise à plus forte augmentation de la tarification. [0067] Selon un autre mode de réalisation, le serveur SERV module le temps de sta- tionnement et/ou la tarification et/ou modifie le statut des places libres de la zone B3, automatiquement, sans calcul préalable du taux d'occupation des places PL. [0068] Le serveur SERV peut transmettre automatiquement une notification aux équipements VEQ des véhicules CAR identifiés (et/ou aux équipements EQ des conducteurs identifiés), informant que des places leur sont réservées et/ou que des places seront disponibles dans la zone B' lorsqu'ils y pénétreront. Cette notification s'affiche préférentiellement sur une interface des équipements VEQ et/ou EQ et/ou est communiquée de manière vocale à l'intérieur des véhicules CAR. Cette notification peut être accompagnée d'une demande de confirmation du type « Pourriez vous nous confirmer que êtes vous intéressés par cette mise à disposition de place dans la zone B 3 ». En cas de confirmation, le serveur SERV maintient le processus peut transmettre aux équipements VEQ et/ou EQ des instructions pour se rendre aux places mise à dis- 19 position. En cas d'infirmation, le serveur SERV ajuste le processus en diminuant le nombre estimé de véhicules. [0069] Pour la zone d'arrivée D,, le serveur SERV lance le processus à 18h30 par exemple (Ton,). En interrogeant la base de données BAS, il analyse que deux des 4 places PL de la zone D, sont occupées ou indisponibles. Le serveur SERV a estimé que trois conducteurs/véhicules sont susceptibles de se garer sur les places de la zone d'arrivée D,. Le nombre de places libres (=2) est ici inférieur au nombre de véhicule estimé (=3). Le serveur SERV agit en modifiant les caractéristiques de stationnement allouées par le contrôleur CON.ID2. Par exemple, le serveur SERV va moduler le temps de stationnement et/ou la tarification à partir de 18h30 (abaissement du temps ou compteà-rebours et/ou augmentation de la tarification) de sorte que les places qui sont libres à 18h30 puissent être utilisées par d'autres véhicules mais soient à nouveau libérées des 19h (début de TID,). Il en est de même pour les places qui sont occupées ou indisponibles à 18h30 mais qui sont à nouveau libres entre 18h30 et 19h. A partir de 19h et jusqu'à 19h30 (fin de T,,,2), chaque place libre est automatiquement placée dans un statut « réservé ». [0070] Pour la zone d'arrivée Di, le serveur SERV lance le processus à 19h par exemple (TO DI). En interrogeant la base de données BAS, il analyse que les 4 places PL de la zone DI sont occupées ou indisponibles. Le serveur SERV a estimé que quatre conducteurs/ véhicules sont susceptibles de se garer sur les places de la zone d'arrivée D3. Le nombre de places libres (=0) est ici bien inférieur au nombre de véhicule estimé (=4). Le serveur SERV agit et module le temps de stationnement autorisé alloué et/ou la tarification appliquée par le contrôleur CONTD3 de sorte que les places qui sont occupées ou indisponibles à 19h et qui se libèrent entre 19h et 19h30 (début de Tlf,3), puissent être occupées par d'autres véhicules, mais soient à nouveau libérées dès 19h30. A partir de 19h30 et jusqu'à 21h (fin de Tlf,'), chaque place libre est automatiquement placée dans un statut « réservé ». [0071] Différentes manières permettent au serveur SERV de savoir qu'un conducteur identifié utilise une des places dans une zone géographique d'arrivée. Par exemple, le serveur SERV peut constater que la position géographique de l'équipement EQ du conducteur (ou du véhicule) coïncide avec la position géographique de ladite place. Le capteur associé à ladite place peut également détecter la présence dudit conducteur/ véhicule, notamment lorsque ledit capteur est une caméra. Ce type de capteur peut alors transmettre au serveur SERV une photo du conducteur ou de la plaque d'immatriculation du véhicule qu'il conduit. L'équipement EQ du conducteur ou l'équipement VEQ du véhicule qu'il conduit peut également transmettre (de manière automatique ou suite à l'activation (l'une touche dédiée) son identifiant au contrôleur CONT qui le transfère au serveur SERV. [0072] Lorsque le serveur SERV a reçu une information lui permettant de déterminer qu'un conducteur identifié utilise une des places dans une zone géographique d'arrivée, ledit serveur peut à nouveau modifier une ou plusieurs des caractéristiques de stationnement allouées à ladite place par le contrôleur concerné. Il peut notamment augmenter le temps de stationnement autorisé. Par exemple, si le temps alloué avant son arrivée était de 5 minutes, le serveur SERV peut augmenter ce temps à 120 minutes voire 12 heures, dès que le conducteur utilise la place. Dc manière alternative ou complémentaire, le serveur SERV peut également moduler à nouveau la tarification appliquée par le contrôleur concerné, par exemple en abaissant le tarif à 0,1 f/tninute et/ou en rendant gratuit le stationnement pendant une période déterminée. C'est une autre manière de privilégier l'utilisation de véhicules permettant de réduire les embouteillages et la pollution et/ou de récompenser des conducteurs utilisant cc type de véhicule. [0073] Différents exemples du procédé conforme à l'invention vont être maintenant décrits en références aux logigrammes des figures 5 et 6. [0074] Sur la figure S. le serveur SERV prend comme référence un conducteur identifié - ou un véhicule identifié - pour la mise en oeuvre du processus (E30). Le processus est par initié à TO, exemple dès que le conducteur utilise un véhicule d'une flotte de véhicule partagé et que ce dernier passe d'un statut « Indisponible à la réservation » à « Disponible à la réservation » (E31). Le serveur SERV fait une analyse statistique (E32) des données historiques de navigation du conducteur pour prédire la zone géographique vers laquelle il va se diriger (E33). Le serveur SERV détermine l'heure d'arrivée estimée du conducteur dans cette zone géographique d'arrivée (E34). Le serveur SERV interroge la base de données BAS pour savoir si au moins une place est libre (non occupée et disponible) dans la zone d'arrivée (E35). Si aucune place n'est libre (E36), le serveur SERV pilote le contrôleur pour que la première place qui se libère soit placée dans un statut « réservé » (mode #1). Si au moins une place est libre, le serveur SERV détermine le taux d'occupation de cette place (E37). Ce taux découle de l'analyse statistique des données historiques enregistrées dans la base BAS et qui sont relatives au statut de ladite place. Si le taux d'occupation est inférieur à une valeur seuil (par exemple 50%), le serveur SERV peut reboucler le processus sur l'étape E35 d'interrogation de la base de données BAS pour connaître le nombre de places libres. Si le taux d'occupation est supérieur ou égal à la valeur seuil, le serveur SERV pilote le contrôleur (E38) pour moduler le temps de stationnement autorisé alloué à la place libre (mode #2) et/ou moduler la tarification appliquée à ladite place (mode #3) et/ou 21 mettre ladite place dans un statut « réservé » (mode #1). [0075] Sur la figure 6, le serveur SERV prend comme référence une zone géographique d'arrivée identifiée (E40). Le processus est initié à TO (E41), par exemple à une heure d'affluence caractéristique, notamment tous les jours ouvrés de la semaine, à 18h, à la sortie des bureaux. Il peut également s'agir d'un événement particulier, par exemple un concert, dans une salle de spectacle identifiée, un samedi soir à 21h. Le serveur SERV fait une analyse statistique (E42) des données historiques de navigation de véhicules identifiés et/ou de conducteurs identifiés, de façon à prédire - estimer - un nombre de véhicules (E43) susceptibles de se rendre dans la zone d'arrivée à partir d'une heure d'arrivée Tl, par exemple à partir de 18h30. Le serveur SERV interroge la base de données BAS (E44) pour savoir si des places sont libres (non occupées et disponibles) dans la zone d'arrivée. Si aucune place n'est libre (E45), le serveur SERV pilote le contrôleur pour que chaque place qui se libère soit placée dans un statut « réservé » (mode #1). Cette modification du statut des places est réalisée jusqu'à ce que le nombre de places placées dans un statut « réservé » soit égal au nombre estimé de véhicules. Si des places sont libres, le serveur SERV compare le nombre estimé de véhicules au nombre de places libres (E46). Si le nombre de places libres est inférieur au nombre estimé de véhicules, le serveur SERV pilote le contrôleur (E47) pour moduler le temps de stationnement autorisé alloué auxdites places libres (mode #2) et/ou moduler la tarification appliquée auxdites places libres (mode #3) et/ou mettre lesdites places libres dans un statut « réservé » (mode #1). Le serveur SERV pilote également le contrôleur pour que chaque place qui se libère soit placée dans un statut « réservé » (mode #1). Si le nombre de places libres est supérieur ou égal au nombre estimé de véhicules, le serveur SERV détermine le taux d'occupation de ces places libres (E48). Ce taux découle de l'analyse statistique des données historiques enregistrées dans la base BAS et qui sont relatives au statut desdites places. Si le taux d'occupation est inférieur à une valeur seuil (par exemple 50%), le serveur SERV peut reboucler le processus sur l'étape E44 d'interrogation de la base de données BAS pour connaître le nombre de places libres. Si le taux d'occupation est supérieur ou égal à la valeur seuil, le serveur SERV pilote le contrôleur (E49) pour moduler le temps de stationnement autorisé alloué aux places libres (mode #2) et/ou moduler la tarification appliquée auxdites places libres (mode #3) et/ou mettre lesdites places libres dans un statut « réservé » (mode #1). Système [0076] Selon un autre aspect, l'invention concerne en particulier un système composé d'au moins le serveur SERV configuré pour mettre en oeuvre le procédé de gestion de places de stationnement selon l'invention. Produit programme d'ordinateur 100771 Selon encore un autre aspect, l'invention concerne un produit programme d'ordinateur comprenant des instructions de code pour l'exécution du procédé de gestion de places de stationnement selon l'invention, lorsqu'il est exécuté par une unité de traitement du serveur informatique SERV. [0078] L'agencement des différents éléments et/ou moyens et/ou étapes de l'invention, dans les modes de réalisation décrits ci-dessus, ne doit pas être compris comme exigeant un tel agencement dans toutes les implémentations. Notamment, une ou plusieurs caractéristiques exposées seulement dans un mode de réalisation peuvent être combinées avec une ou plusieurs autres caractéristiques exposées seulement dans un autre mode de réalisation. 23 [Revendication 1] [Revendication 2] [Revendication 3] [Revendication 4] [Revendication 5] [Revendication 6] REVENDICATIONSProcédé de gestion de places de stationnement (PL, PL1-PL4) pour véhicules, lesquelles places sont localisées dans une zone géographique (GEO, 133, DI, D2, et sont associées à un contrôleur (CONT, CONTHI CONTD1, CONTD2, CONTD3) configure pour allouer une ou plusieurs caractéristiques de stationnement auxdites places, se caractérisant par le fait que le procédé comporte les étapes suivantes: - récolte et stockage de données historiques de navigation de véhicules (CAR, CAR,-CA R2) identifiés et/ou de conducteurs identifiés, - analyse statistique desdites données stockées pour prédire l'utilisation des places (PL, PL1-PL4) par les véhicules (CAR, CARI-CAR2) identifiés et/ou les conducteurs identifiés, - modification d'une ou plusieurs caractéristiques de stationnement allouées par le contrôleur (CONT, CONTKI, CONT,,,, CONTD2, CONT ,)3) en fonction de la prédiction d'utilisation des places (PL, PLI-PI-4). Procédé selon la revendication 1, comprenant les étapes suivantes : - récolte et stockage de données historiques d'occupation des places (PL, PLI-PL4), - détermination d'un nombre de places libres faisant suite à la prédiction d'utilisation des places (PL, PLI-PUT, - calcul d'un taux d'occupation desdites places libres, lequel calcul est basé sur une analyse statistique desdites données historiques stockées. Procédé selon la revendication 2, comprenant une étape de sélection d'au moins une caractéristique de stationnement à modifier parmi plusieurs caractéristiques de stationnement allouée par le contrôleur (CONT, CONTB1, CONTD1, CONTD2, CONTD2), laquelle sélection dépend du taux d'occupation calculé. Procédé selon l'une des revendications 2 ou 3, consistant à ne modifier la ou les caractéristiques de stationnement que si le taux d'occupation calculé est supérieur ou égal à une valeur seuil. Procédé selon l'une des revendications précédentes, comprenant une étape de nouvelle modification d'au moins une caractéristique de stationnement allouée à une place de stationnement lorsque ladite place est utilisée par un véhicule (CAR, CARI-CAL) identifié et/ou un conducteur identifié. Procédé selon l'une des revendications précédentes, dans lequel la modification de la caractéristique de stationnement consiste à moduler la 24 [Revendication 7] [Revendication 8] [Revendication 9] [Revendication 10] [Revendication 11] [Revendication 12] durée du temps de stationnement autorisé alloué par le contrôleur (CONT, CONT,', CONT',, CONT112, CONT'3) aux places (P, PLI-PL4). Procédé selon l'une des revendications précédentes, dans lequel la modification de la caractéristique de stationnement consiste à moduler la tarification appliquée par le contrôleur (CONT, CONT,', CONT',, CONT,. CONT113) lors de l'utilisation des places (P, PLI-PL4). Procédé selon l'une des revendications précédentes, dans lequel la modification de la caractéristique de stationnement consiste à placer les places (P, PLI-PL4) dans un statut « réservé ». Procédé selon l'une des revendications précédentes, comprenant une étape d'estimation d'une heure d'arrivée d'au moins un des véhicules (CAR1-CAR2) identifiés et/ou d'au moins un des conducteurs identifiés, dans la zone géographique (GEO, B3, DI, D2, D3), la ou les caractéristiques de stationnement étant modifiées avant ladite heure d'arrivée estimée. Procédé selon la revendication 9, comprenant les étapes suivantes : - modification d'une ou plusieurs caractéristiques de stationnement avant l'heure d'arrivée estimée, - modification d'une autre ou plusieurs autres caractéristiques de stationnement à partir de l'heure d'arrivée estimée. Procédé selon l'une des revendications 9 ou 10 , comprenant les étapes suivantes : - modification d'une ou plusieurs caractéristiques de stationnement si, avant l'heure d'arrivée estimée, une place (PL, PLI-PL4) est occupée par un véhicule non identifiés et/ou un conducteur non identifiés, - modification différente de ladite ou lesdites caractéristiques si, à partir de l'heure d'arrivée estimée, ladite place (PL, PLI-PL4) est occupée par un véhicule identifiés (CAR, CAR1-CAR,) et/ou un conducteur identifiés. Système de gestion de places de stationnement (PL, PLI-PL4) pour véhicules, lesquelles places sont localisées dans une zone géographique (GEO, B2, DI, D2, DI) et sont associées à un contrôleur (CONT, CONTEI , CONTD1, CONTD2, CONTD1) configuré pour allouer des caractéristiques de stationnement auxdites places, se caractérisant par le fait que le système comporte : - une base de données (BAS) dans laquelle sont identifiées des véhicules (CAR, CARI-CAR2) et/ou des conducteurs, - un moyen pour récolter des données historiques de navigation des 25 [Revendication 13] [Revendication 14] véhicules (CAR, CAR1-CAR2) identifiés et/ou des conducteurs identifiés, - une hase de données (BAS) dans laquelle lesdites données récoltées sont stockées, - un serveur informatique (SERV) adapté pour : -- faire une analyse statistique desdites données stockées pour prédire l'utilisation des places (PL, PL1-PL4) par les véhicules (CAR, CARI - CAR2) identifiés et/ou les conducteurs identifiés, -- générer et transmettre au contrôleur (CONT, CONTE', CONT,, CONTy, CONT,,) des instructions pour modifier les caractéristiques de stationnement allouées par ledit contrôleur, en fonction des prédictions d'utilisation des places (PL, PLI-PL.,). Système comprenant un serveur informatique (SERV) configurés pour mettre en oeuvre le procédé selon la revendication 1. Produit programme d'ordinateur comprenant des instructions de code pour l'exécution d'un procédé selon la revendication 1, lorsqu'il est exécuté par une unité de traitement d'un serveur informatique (SERV).