Brevet FR3148484A1 — publié le 20241108

L’invention concerne un procédé de configuration d’un service automobile. Une première application est exécutée (302) pour mettre à disposition une première interface graphique indiquant des actions possibles et des données de véhicule d’un véhicule. Une première règle est créée (303) à partir d’au moins une entrée utilisateur. La première règle identifie une première condition et une première action. Un service automobile basé sur ladite première règle est configuré (304), de manière à ce qu’une mise en œuvre du service automobile comprenne l’obtention d’une première valeur courante pour la première donnée véhicule, une évaluation de la première condition à partir de la première valeur courante, et une exécution de la première action en fonction de l’évaluation de la première condition. FIG. 3 Configuration d’un service automobile par une première application La présente invention appartient au domaine des services connectés, notamment de services connectés pour véhicule automobile, dits services automobiles dans ce qui suit. Elle est particulièrement avantageuse dans le contexte de véhicules connectés mettant à disposition des données de véhicule, pour une exploitation de ces données dans la mise en œuvre de services. On entend par « véhicule » tout type de véhicule tel qu’un véhicule automobile, un cyclomoteur, une motocyclette, un robot de stockage dans un entrepôt, etc. La création de services automobiles exploitant des données de véhicule, dites données véhicule dans ce qui suit, repose généralement sur des interfaces de programmation d’application, ou API en anglais pour « Application Programming Interface », exposées par le véhicule automobile. Ainsi, plusieurs APIs peuvent être exposées par un véhicule automobile, par lesquelles des applications ou logiciels tiers peuvent accéder des données de véhicule, relatives au fonctionnement du véhicule et/ou de certains de ses équipements. La création de services automobiles connectés basés sur des données véhicule via les APIs exposés par le véhicule nécessitent cependant des compétences en développement. Le développement de services simples, à des coûts moindres, par des personnes non expertes du développement logiciel est ainsi impossible à l’heure actuelle. Le développement aisé de tels services automobiles connectés permettrait cependant : - la configuration de services personnalisés par l’utilisateur final lui-même ; - la réalisation rapide de test de services par le constructeur automobile ou un fournisseur de service tiers. Il existe ainsi un besoin de permettre une configuration aisée de services automobiles connectés tirant parti de données d’un véhicule automobile. La présente invention améliore la situation. A cet effet, un premier aspect de l’invention concerne un procédé de configuration d’un service automobile comprenant les étapes suivantes: - exécution d’une première application, comprenant la mise à disposition d’une première interface graphique utilisateur, ladite première interface graphique utilisateur indiquant des actions possibles et des données de véhicule d’un véhicule, la première application étant apte à configurer un accès à des valeurs courantes et/ou des états courants des données véhicule via au moins une interface de programmation d’application dudit véhicule; - création d’une première règle à partir d’au moins une entrée utilisateur, ladite première règle identifiant au moins une première condition définie à partir d’au moins une première donnée véhicule et identifiant au moins une première action parmi les actions possibles; - configuration d’un service automobile basé sur ladite première règle, de manière à ce qu’une mise en œuvre du service automobile comprenne l’obtention d’une première valeur courante pour la première donnée véhicule, une évaluation de la première condition à partir de la première valeur courante, et une exécution de la première action en fonction de l’évaluation de la première condition. La première application selon l’invention permet ainsi à un utilisateur de la première application, tel qu’un fournisseur de service ou l’utilisateur du véhicule, de configurer de manière simple un service automobile. En effet, l’accès aux API du véhicule est configurée par la première application à partir de la règle créée par l’utilisateur. Selon des modes de réalisation, l’exécution de la première action peut comprendre l’envoi d’une instruction d’exécuter la première action à un terminal d’un utilisateur du véhicule ou à un système d’info-divertissement du véhicule. Ainsi, le premier service peut exploiter des données véhicule pour déclencher une action destinée à l’utilisateur du véhicule, via son un terminal ou le système d’info-divertissement du véhicule. Il est ainsi rendu possible de configurer de manière simple un service véhicule, c’est-à-dire un service basé sur des données véhicule, pour l’utilisateur du véhicule automobile. En complément, une deuxième application peut être installée dans le terminal de l’utilisateur ou dans le système d’info-divertissement du véhicule, et l’exécution de la première action peut comprendre l’envoi de l’instruction au terminal de l’utilisateur ou au système d’info-divertissement du véhicule et l’exécution de la première action par la deuxième application installée dans le terminal de l’utilisateur ou dans le système d’info-divertissement du véhicule. Ainsi, l’action peut être exécutée par la deuxième application. De manière avantageuse, la deuxième application peut être une application compagnon de la première application, et la première application peut ainsi proposer des actions possibles qui sont exécutables par la deuxième application. En variante, l’exécution de la première action peut comprendre l’envoi d’une instruction d’exécuter la première action à une deuxième interface de programmation d’application du véhicule, ladite deuxième interface de programmation d’application étant apte à commander au moins un équipement du véhicule automobile. Ainsi, il est permis de configurer de manière simple un service automobile permettant un contrôle du véhicule ou d’un équipement du véhicule automobile. Selon des modes de réalisation, la première condition peut définir une première relation entre la première donnée véhicule et une première valeur ou entre la première donnée véhicule et un premier état, et la vérification de la première condition peut comprendre la comparaison de la valeur courante ou de l’état courant de la première donnée avec la première valeur ou avec le premier état, pour vérifier si la première relation est réalisée. Ainsi, l’exécution de l’action peut être conditionnée par une condition définie par l’utilisateur de la première application, qui peut notamment paramétrer le premier état ou la première valeur. Selon des modes de réalisation, la première règle peut comprendre au moins une deuxième condition définie à partir d’au moins une deuxième donnée véhicule, l’exécution du service automobile peut comprendre en outre l’obtention d’une deuxième valeur courante de la deuxième donnée véhicule via ladite au moins une interface de programmation d’application et une évaluation de la deuxième condition à partir de la deuxième valeur courante, et l’exécution de la première action peut être fonction de l’évaluation de la première condition et de l’évaluation de la deuxième condition. Ainsi, il est permis à l’utilisateur de la première application de configurer un service automobile plus complexe, sans avoir à paramétrer des accès aux API du véhicule. En complément, la première règle peut comprendre un opérateur logique entre la première condition et la deuxième condition, et l’exécution de la première action est fonction de l’évaluation de la première condition, de l’évaluation de la deuxième condition et de l’opérateur logique. Ainsi, il est permis à l’utilisateur de la première application de configurer un service automobile avec au moins une règle complexe, sans avoir à paramétrer des accès aux API du véhicule. Selon des modes de réalisation, chaque donnée véhicule peut être identifiée sur la première interface par un code mnémonique. Ainsi, la création d’une règle sur la base de laquelle est configuré un service, est facilitée et accélérée. Selon des modes de réalisation, le procédé peut comprendre en outre une étape de définition des actions possibles et/ou des données véhicule indiquées par la première interface par un administrateur de la première application. Ainsi, il est permis à un administrateur de définir les données véhicule et les actions qui peuvent être utilisées par l’utilisateur de la première application pour créer une règle. Il peut ainsi être assuré que les données véhicule sont effectivement disponibles et que les actions peuvent être exécutées. En cas d’erreur ou en cas de mise à jour, l’administrateur peut changer les actions possibles et/ou les données véhicule disponibles. Un deuxième aspect de l’invention concerne un programme informatique comportant des instructions pour la mise en œuvre du procédé selon le premier aspect de l’invention, lorsque ces instructions sont exécutées par un processeur. Un troisième aspect de l’invention concerne un dispositif de configuration de service comprenant un processeur apte à mettre en oeuvre les étapes suivantes : - exécution d’une première application, comprenant la mise à disposition d’une première interface graphique utilisateur, ladite première interface graphique utilisateur indiquant des actions possibles et des données de véhicule d’un véhicule, la première application étant apte à configurer un accès à des valeurs courantes et/ou des états courants des données du véhicule via au moins une interface de programmation d’application dudit véhicule; - création d’une première règle à partir d’au moins une entrée utilisateur, ladite première règle identifiant au moins une première condition définie à partir d’au moins une première donnée véhicule et identifiant au moins une première action parmi les actions possibles; - configuration d’un service automobile basé sur ladite première règle, de manière à ce qu’une mise en œuvre du service automobile comprenne l’obtention d’une première valeur courante pour la première donnée véhicule, une évaluation de la première condition à partir de la première valeur courante, et une exécution de la première action en fonction de l’évaluation de la première condition. D’autres caractéristiques et avantages de l’invention apparaîtront à l’examen de la description détaillée ci-après, et des dessins annexés sur lesquels : illustre un environnement de mise en œuvre de la configuration et la mise en œuvre d’un service automobile, selon des modes de réalisation de l’invention; illustre une première interface d’une première application pour configurer un service automobile, selon des modes de réalisation de l’invention ; illustre un procédé de configuration d’un service automobile selon des modes de réalisation de l’invention ; illustre un dispositif de configuration d’un service automobile selon des modes de réalisation de l’invention. La illustre un environnement de configuration et de mise en œuvre d’un service automobile, selon des modes de réalisation de l’invention. On entend par service automobile, tout service basé sur au moins une donnée de véhicule d’un véhicule 100, appelée donnée véhicule ci-après, aucune restriction n’étant attachée à la donnée véhicule considérée qui peut être : - un état du véhicule, - un état d’un équipement du véhicule, ou - une valeur numérique descriptive du fonctionnement du véhicule ou d’un équipement du véhicule 100. Le véhicule 100 peut comprendre une unité de commande centralisée 101, aussi appelée ECU en anglais, pour « Electronic Control Unit », apte à obtenir des valeurs courantes ou des états courants des données véhicule, et apte à commander un ou plusieurs équipements 105.1 et 105.2 du véhicule 100, tel qu’un dispositif d’éclairage, un dispositif de chauffage, un moteur, etc. Deux équipements 105.1 et 105.2 sont représentés à titre illustratif sur la . Toutefois, aucune restriction n’est attachée au nombre d’équipements du véhicule 100, ni au nombre d’équipements contrôlés par l’ECU 101. Dans ce qui suit, il est considéré à titre illustratif que le premier équipement 105.1 est un dispositif d’éclairage, et que le deuxième équipement 105.2 est un dispositif de chauffage. Toutefois, les équipements 105.1 et 105.2 peuvent désigner tout équipement automobile dont le fonctionnement ou l’état peut être contrôlé. Une donnée véhicule de type « état du véhicule 100 » peut être : - un état de mise en route du véhicule 100, qui peut être « hors contact » ou « en contact » ; - un état de mobilité du véhicule 100, qui peut être « à l’arrêt » ou « en mouvement » ; - tout autre état descriptif du fonctionnement du véhicule. Une donnée véhicule de type « état d’un équipement du véhicule » peut être : - l’état de fonctionnement du dispositif d’éclairage 105.1, pouvant être « activé » ou « désactivé » ; - l’état de fonctionnement du dispositif de chauffage 105.2, pouvant être « activé » ou « désactivé ». A noter qu’un état de fonctionnement n’est pas forcément un état binaire : par exemple, l’état de fonctionnement d’un dispositif d’éclairage peut comprendre trois états possibles, tels que « désactivé », « feu de croisement », « feu de route », ou plus de trois états possibles. Une donnée véhicule de type « valeur numérique » peut être : - la valeur numérique du compteur kilométrique du véhicule 100, exprimée en kilomètres par exemple ; - la vitesse instantanée du véhicule ou la vitesse moyenne sur une période donnée, exprimée en kilomètres par heures par exemple ; - la température intérieure à l’intérieur de l’habitacle du véhicule 100, exprimée en degrés Celsius par exemple ; - l’autonomie restante du véhicule, exprimée en pourcentages ou en kilomètres, par exemple. Le véhicule 100 peut comprendre en outre une interface homme machine, IHM, 102 apte à permettre au dispositif de contrôle 101, et à d’autres entités du véhicule 100, d’échanger des informations avec le conducteur ou avec des passagers du véhicule 100. Aucune restriction n’est attachée à l’IHM 102, qui comprend tout élément permettant de recevoir une commande de l’utilisateur, que cette commande soit relative au pilotage du véhicule ou au contrôle d’équipements intérieurs ou extérieurs, et/ou de transmettre des informations à l’utilisateur. A cet effet, l’IHM 102 peut comprendre un écran, tel qu’un écran tactile, un ensemble d’un ou de plusieurs boutons, un haut-parleur, un microphone, un tableau de bord apte à afficher un et/ou plusieurs pictogrammes lumineux de formes prédéfinies, un système de vibration du volant, etc. De manière préférentielle, l’IHM 102 est capable de transmettre des données visuelles et/ou sonores au conducteur du véhicule. De manière complémentaire, le conducteur ou les passagers peuvent en outre saisir des informations via l’IHM 102, pour transmission au dispositif de contrôle ECU 101, via un bouton, une commande tactile, une commande vocale, ou tout autre type d’entrée utilisateur. L’IHM 102 peut être intégrée dans un système d’info-divertissement 103 du véhicule, apte à commander l’IHM 102, et hébergeant une ou plusieurs fonctions d’info-divertissement. Des applications peuvent en outre être installées sur le système d’info-divertissement 103, pour la mise en œuvre de services automobiles auprès d’un utilisateur du véhicule 100. De telles applications peuvent être téléchargées par l’intermédiaire d’une interface 104 d’accès sans fil à un réseau étendu 110. En particulier, une deuxième application, ou application compagnon d’une première application, telle que décrite dans ce qui suit peut être téléchargée, installée sur le système d’info-divertissement 103, et exécutée sur le système d’info-divertissement 103 pour la mise en œuvre d’au moins un service véhicule selon l’invention. Aucune restriction n’est attachée à l’interface 104, qui peut être une interface d’accès à un réseau cellulaire relié à un réseau de télécommunications 110, tel qu’un réseau étendu IP, tel qu’une interface 3G, 4G, de préférence 5G ou toute génération suivante. L’interface 104 permet ainsi au véhicule 100 d’être « connecté », c’est-à-dire de pouvoir échanger, de manière bidirectionnelle, avec des entités ayant accès au réseau de télécommunications 110. Le véhicule 100 peut ainsi exposer une ou plusieurs interfaces de programmation d’application, ou API en anglais pour « Application Programming Interface », qui peuvent être hébergées sur un ou plusieurs serveurs 111.1 et 111.2. Par exemple, un premier serveur 111.1 peut héberger, c’est-à-dire stocke et exécute, au moins une première API, dite API d’accès, du véhicule 100 permettant l’accès à une donnée véhicule. De manière préférentielle, plusieurs premières API permettent l’accès à différentes données véhicule et sont stockées et exécutées dans le premier serveur 111.1. Chaque première API peut correspondre à une première adresse URL permettant d’accéder à la première API dans le réseau de télécommunications 110, notamment pour accéder au premier serveur 111.1. La première URL permet ainsi à la fois d’identifier le premier serveur 111.1 mais également d’identifier une première API parmi plusieurs dans le premier serveur 111.1. En variante, un premier serveur 111.1 est prévu pour chaque première API d’accès à une donnée véhicule. Un deuxième serveur d’API 111.2 peut stocker au moins une deuxième API, dite API de commande, permettant le contrôle d’une fonction du véhicule ou d’équipements du véhicule, tels que les équipements 105.1 et 105.2 détaillés précédemment. Une API de commande peut par exemple contrôler un état de fonctionnement du dispositif d’éclairage 105.1 tandis qu’une autre API de commande peut contrôler un état de fonctionnement du dispositif de chauffage 105.2. Une autre API de commande peut indiquer une destination au module ADAS pour l’assistance à la conduite du véhicule, ou la conduite autonome du véhicule, vers la destination. Chaque deuxième API peut correspondre à une deuxième adresse URL permettant d’accéder à la deuxième API dans le réseau de télécommunications 110, notamment pour accéder au deuxième serveur 111.2. La deuxième URL permet ainsi à la fois d’identifier le deuxième serveur 111.2 mais également d’identifier une deuxième API parmi plusieurs dans le deuxième serveur 111.2. En variante, un deuxième serveur 111.2 est prévu pour chaque deuxième API de commande d’une fonction du véhicule ou d’un équipement du véhicule. A noter qu’en variante, toutes les API, API de commande et API d’accès, du véhicule peuvent être hébergées dans un unique serveur. Le véhicule 100 peut comprendre un module d’assistance à la conduite, aussi appelé ADAS, pour « Advanced Driver Assistance Systems » en anglais, non représenté sur la et apte à réaliser au moins une fonction d’aide à la conduite voire une fonction entièrement automatisée de contrôle de la trajectoire latérale et/ou longitudinale du véhicule 100. Aucune restriction n’est attachée au niveau d’autonomie de conduite permis par le véhicule. Le module ADAS peut aider le conducteur dans le pilotage du véhicule, notamment pour la détermination ou le maintien de la vitesse ou de l’accélération, ou peut assurer le pilotage autonome du véhicule, sans la contribution du conducteur. L’aide à la conduite recouvre ainsi également le pilotage automatique du véhicule. Toutefois, selon l’invention, le véhicule 100 peut ne pas comprendre un tel module ADAS. Selon l’invention, un serveur applicatif 120 est apte à accéder au réseau de télécommunications 110. Le serveur applicatif 120 peut être dédié à une première application selon l’invention, la première application pouvant être téléchargée et installée sur des terminaux utilisateurs, tels que des ordinateurs fixes ou portables, des tablettes tactiles, des Smartphones, etc. Dans ce qui suit, il est considéré que la première application est installée sur un terminal de configuration de service 150. Le fonctionnement de la première application est détaillé dans ce qui suit, en référence aux figures 2 et 3. Un terminal administrateur 130 est apte à accéder au réseau de télécommunications 110, et notamment au serveur applicatif 120. Le terminal administrateur 130 est autorisé à configurer la première application, comme détaillé dans ce qui suit à la lecture de la description des figures 2 et 3. Un terminal utilisateur 140 peut également accéder au réseau de télécommunications, le terminal utilisateur 140 appartenant, dans le cadre de l’invention, à l’utilisateur du véhicule 100. Le terminal utilisateur 140 peut télécharger et stocker la deuxième application, ou application compagnon de la première application. L’application compagnon peut être téléchargée, tout comme la première application, depuis le premier serveur 120. En variante, l’application compagnon peut être téléchargée depuis un serveur dédié, non représenté sur la . La présente une première interface graphique utilisateur 200 obtenue par exécution de la première application. Par exemple, la première interface peut être affichée sur un écran du terminal de configuration de service 150. Comme décrit dans ce qui suit, la première interface graphique utilisateur 200 permet à un utilisateur du terminal de configuration de service 150 de configurer au moins un service automobile, sans nécessiter de connaissance en développement logiciel, notamment pour configurer l’accès aux premières API du premier serveur 111.1. La première interface graphique utilisateur 200 indique au moins une action possible 201. Dans l’exemple de la , trois actions possibles sont indiquées sur la première interface graphique utilisateur 200. Chaque action possible peut correspondre à l’exécution d’une action/opération par un équipement, par un terminal, pouvant être notamment un équipement du véhicule 100 ou le terminal utilisateur 140 décrit précédemment. Des exemples d’actions possibles sont données ci-après : - ajout d’un évènement dans un calendrier de l’utilisateur, par exemple sur le terminal utilisateur 140 ou dans le système d’info-divertissement 103 du véhicule 100. Cette action possible correspond au pictogramme « REMIND » dans l’exemple de la ; - appel téléphonique du terminal utilisateur 140 ou du système d’info-divertissement 103 vers un contact donné (paramètre de l’action). Cette action possible correspond au pictogramme « CALL » dans l’exemple de la ; - pilotage autonome du véhicule ou assistance à la conduite vers une destination donnée (paramètre de l’action). Cette action possible correspond au pictogramme « NAVIGATE » dans l’exemple de la . De manière préférentielle, lorsque l’action possible correspond à une action exécutée dans le système d’info-divertissement 103 du véhicule 100 et/ou sur le terminal utilisateur 140, l’action n’est possible que si la deuxième application, ou application compagnon, est installée sur le système d’info-divertissement 103 et/ou sur le terminal utilisateur 140. L’exécution de l’action peut ainsi être effectuée localement, avec l’assentiment de l’utilisateur du véhicule 100 qui a au préalable installé la deuxième application sur le système d’info-divertissement 103 et/ou sur le terminal utilisateur 140. Les trois actions possibles données ci-dessus sont données à titre illustratif. D’autres actions possibles peuvent comprendre l’activation/désactivation d’un équipement du véhicule, tel que le dispositif d’éclairage 105.1 ou le dispositif de chauffage 105.2 par exemple. La première interface graphique utilisateur 200 indique en outre au moins une donnée véhicule 202, qui peuvent être indiquées sous la forme d’un code mnémonique, c’est-à-dire une suite de quelques caractères alphanumériques permettant à l’utilisateur de la première application d’identifier aisément la donnée véhicule 202 correspondant au code mnémonique. Dans l’exemple de la , trois données véhicule sont indiquées par trois codes mnémoniques. Notamment : - le code mnémonique « MILEAGE » désigne une donnée véhicule qui est une valeur numérique correspondant au compteur kilométrique du véhicule 100, exprimée en kilomètres par exemple ; - le code mnémonique « AUTONOMY » désigne une donnée véhicule qui est une valeur numérique correspondant à l’autonomie du véhicule, exprimée en pourcentages ou en kilomètres, par exemple ; - le code mnémonique « MOVING » désigne une donnée véhicule qui est un état de mouvement du véhicule 100, tel que décrit précédemment. D’autres codes mnémoniques correspondant à d’autres données du véhicule 202 peuvent être prévues sur la première interface graphique utilisateur 200, selon l’invention. A noter que l’utilisateur de la première application peut être : - l’utilisateur du véhicule 100, qui est utilisateur du terminal utilisateur 140 également ; - le constructeur du véhicule automobile ; - un fournisseur de service tiers. L’utilisateur de la première application peut définir au moins une première règle 203.1 dans une zone configurable 204, à partir d’au moins une première donnée véhicule parmi les données véhicule disponibles 202, et à partir d’au moins une première action parmi les actions possibles 201. A cet effet, le terminal de configuration de service 150 peut comprendre une interface de commande utilisateur apte à recevoir des entrées utilisateur. Aucune restriction n’est attachée au type d’entrée utilisateur, qui peut être une commande vocale, une entrée tactile ou haptique, tel qu’un contact de type toucher, de type glissement de doigt, ou autre. De telles interfaces de commande sont bien connues et ne sont pas décrites davantage dans la présente description. Ainsi, par des entrées utilisateur saisies sur l’interface de commande, l’utilisateur de la première application sélectionne au moins une première action et au moins une première donnée véhicule, afin de définir la première règle 203.1. La définition de la première règle 203.1 comprend la définition d’au moins une première condition basée sur la première donnée véhicule. La première condition peut prendre la forme d’une première relation entre la première donnée véhicule et une première valeur ou entre la première donnée du véhicule et un premier état. Le premier état ou la première valeur peuvent être définie par l’utilisateur de la première application par une entrée utilisateur. La première règle prend ainsi la forme logique suivante : si la première condition est réalisée, alors mettre en œuvre de la première action. Dans l’exemple spécifique de la , la première règle est la suivante : si le compteur kilométrique du véhicule 100 (première donnée véhicule sélectionnée par l’utilisateur de la première application) a une valeur courante supérieure à 10 000 kilomètres (première valeur définie par l’utilisateur de la première application), alors création d’un évènement « maintenance ». Ainsi, la première action sélectionnée parmi les actions possibles 202 peut également être paramétrée par l’utilisateur, par exemple afin d’indiquer le nom « maintenance » pour l’évènement créé par la première action. Ainsi, selon la première règle, la première action est exécutée lorsque la première condition est réalisée. En variante, la première règle peut comprendre une condition additionnelle, en plus de la première condition, définie par l’utilisateur de la première application à partir d’une autre donnée véhicule parmi les données véhicule possibles. La condition additionnelle peut comprendre une deuxième relation entre la deuxième donnée véhicule et une deuxième valeur. L’utilisateur de la première application peut en outre définir un opérateur logique entre la première condition et la condition additionnelle. L’opérateur logique peut être de type «ou », « et », « ou exclusif » notamment. La première action de la première règle est dans ce cas exécutée en fonction de l’opérateur logique, d’une évaluation de la première condition et d’une évaluation de la condition additionnelle. Par exemple, si l’opérateur logique est « et », la première action est exécutée si la première condition est réalisée et la condition additionnelle est réalisée. Si l’une au moins des conditions n’est pas réalisée, la première action n’est pas exécutée. Un premier service automobile peut alors être configuré par la première application à partir de la première règle définie par l’utilisateur de la première application. La configuration du premier service automobile comprend l’implémentation de la première règle, comprenant notamment : - la configuration d’un accès à la première API permettant d’obtenir une valeur courante de la première donnée véhicule définie dans la première règle. L’accès à l’API peut être configuré de manière à être effectué à une fréquence donnée. Il est ainsi permis de mettre à jour régulièrement la valeur courante obtenue. Dans l’exemple de la première règle de la , la configuration de l’accès à la première API comprend l’identification de la première API exposée par le véhicule 100 apte à fournir la valeur courante du compteur kilométrique du véhicule, et l’obtention de l’URL de la première API identifiée ; - la création d’une instruction pour exécuter l’action et la configuration d’un destinataire de l’instruction. Le destinataire peut être la deuxième application installée sur le système d’info-divertissement du véhicule 100 ou sur le terminal utilisateur 140, ou peut être une API de commande stockée dans le deuxième serveur 111.2. Ainsi, il est permis la configuration d’un premier service automobile par un utilisateur du terminal de configuration de service 150, qui ne requiert pas de connaissances en développement, la configuration de l’accès aux API concernées étant effectuée en arrière plan par la première application, de manière transparente pour l’utilisateur. Le premier service automobile peut être configuré par le terminal de configuration de service 150 dans le premier serveur 120, ou localement dans le terminal de configuration de service 150. L’entité dans laquelle est configurée le service automobile est alors en charge de son exécution/mise en œuvre. Dans l’exemple de la , une deuxième règle 203.2 peut être définie par l’utilisateur de la première application. La deuxième règle 203.2 est définie par l’utilisateur de la première application en sélectionnant une deuxième action parmi les actions possibles 201, une deuxième donnée véhicule parmi les données véhicules disponibles 202, puis en définissant une deuxième relation entre la deuxième donnée véhicule sélectionnée et une deuxième valeur. La deuxième valeur peut être définie par l’utilisateur de la première application. L’utilisateur de la première application peut également paramétrer la deuxième action. Ainsi, la deuxième règle réalise la deuxième action, lorsque la deuxième condition est réalisée. A nouveau, une condition additionnelle peut être définie pour la deuxième règle, en plus de la deuxième condition. Dans l’exemple de la , la deuxième règle est la suivante : si l’autonomie restante (donnée véhicule) du véhicule est inférieure à 20 kilomètres (paramètre défini par l’utilisateur), alors diriger le véhicule 100 (action) vers la destination de latitude xx et de longitude yy (paramètre défini par l’utilisateur). Un deuxième service automobile peut être configuré par le terminal de configuration de service 150 à partir de la deuxième règle. Comme pour le premier service automobile, le deuxième service automobile peut être configuré par le terminal de configuration de service 150 dans le serveur applicatif 120, ou localement dans le terminal de configuration de service 150. En variante, la première règle et la deuxième règle peuvent être utilisées par le terminal de configuration de service 150 pour configurer le premier service automobile. Ainsi, des services automobiles complexes peuvent être configurés selon l’invention, de manière aisée pour un utilisateur de la première application. Dans l’exemple de la , chacune des première et deuxième règles 203.1 et 203.2 est définie à partir d’une unique action. Toutefois, en variante : - une règle peut comprendre plusieurs actions mises en œuvre lorsqu’une unique condition est réalisée ; ou - une règle peut comprendre plusieurs actions mises en œuvre en fonction de plusieurs conditions et d’un opérateur logique. Aucune restriction n’est attachée à l’aspect graphique ni à la répartition des différents éléments 201, 202, 203.1 et 203.4 sur la première interface, l’exemple de la étant donné à titre illustratif uniquement. Les actions possibles 201 et les données véhicule disponibles 202 peuvent être définies par un administrateur de la première application, via le terminal administrateur 130. L’administrateur peut consulter les API d’accès disponibles dans le premier serveur 111.1, et peut renseigner les URLs de certaines des API d’accès, dans la première application, et ajoute un code mnémonique pour chaque donnée véhicule accessible via l’une des API d’accès. L’administrateur peut en outre définir des paramètres d’utilisation et/ou des paramètres de sécurité pour l’accès via une API d’accès à chaque donnée véhicule accessible. De même, l’administrateur peut consulter les API de commande disponibles dans le deuxième serveur 111.2, peut renseigner les URLs de certaines des API de commande dans la première application, et ajoute une action possible 201 pour chaque commande permise par les API de commande. L’administrateur peut en outre définir des paramètres d’utilisation et/ou des paramètres de sécurité pour l’exécution d’une action via une API de commande. D’autres actions possibles 201 peuvent être ajoutées par l’administrateur en fonction d’actions autorisées par l’application compagnon installées sur le terminal utilisateur 140, ou sur le système d’info-divertissement 103. L’administrateur peut en outre définir des paramètres d’utilisation et/ou des paramètres de sécurité pour l’exécution d’une action via l’application compagnon. La définition des actions possibles 201 et des données véhicule disponibles 202 peut être réalisée par l’administrateur en amont de la mise à disposition de la première application. En outre, de nouvelles actions possibles 201 et/ou de nouvelles données véhicule disponibles 202 peuvent être définies ultérieurement par l’administrateur, lors de mises à jour ou de corrections d’erreurs de la première application. Lorsque la ou les nouvelles actions possibles sont exécutées dans l’application compagnon, une mise à jour de l’application compagnon peut être mise en œuvre sur le terminal utilisateur 140 et/ou sur le système d’info-divertissement 103 du véhicule 100. La est un diagramme illustrant les étapes d’un procédé de configuration d’un service automobile selon des modes de réalisation de l’invention. Le procédé de configuration de service automobile peut être mis en œuvre par le dispositif de configuration de service 150 décrit précédemment. A une étape 301, le dispositif de configuration de service 150 installe la première application. L’étape 301 peut être précédée d’une étape de téléchargement de la première application. En variante, la première application est accessible en ligne depuis le serveur applicatif 120, sans le besoin d’être téléchargée et installée dans le terminal de configuration de service 150. A une étape 302, le dispositif de configuration de service 150 exécute la première application, l’exécution comprenant la mise à disposition de la première interface graphique utilisateur 200 décrite précédemment, sur le terminal de configuration de service 150. A une étape 303, le dispositif de configuration de service 150 crée au moins une première règle à partir d’entrées utilisateur reçues sur une interface de commande du dispositif de configuration de service 150. A une étape 304, le dispositif de configuration de service 150 configure au moins un premier service automobile à partir de la première règle créée à l’étape 303. Le premier service automobile peut être configuré dans le dispositif de configuration de service 150, dans le serveur applicatif 120, ou dans tout autre entité ayant accès au réseau 110 et capable d’interpréter et d’exécuter le premier service automobile. Le premier service automobile peut prendre la forme d’un code informatique, dans un langage de programmation donné. Une routine d’exécution du programme peut être définie au moyen d’un programme de type « cron » . Suite à la configuration du premier service, une étape d’exécution du premier service peut être mise en œuvre. Une telle exécution peut être mise en œuvre par l’entité sur laquelle le premier service automobile a été configuré lors de l’étape 304. Une telle exécution peut être exécutée en arrière plan, c’est-à-dire sans intervention de l’utilisateur, via un programme de type « cron » par exemple. Il est considéré, par simplification, que le premier service comprend la première règle 203.1 décrite précédemment. La mise en œuvre du premier service peut comprendre les étapes suivantes : - interrogation de l’API d’accès du véhicule 100 associée à la première donnée véhicule de la première règle. Une telle interrogation est basée sur l’URL de l’API d’accès, des paramètres de sécurité et d’utilisation, définis au préalable par l’administrateur. Dans l’exemple considéré, l’API d’accès est celle qui est apte à accéder au compteur kilométrique du véhicule 100 ; - obtention d’une valeur courante de la première donnée véhicule via l’API interrogée. Dans l’exemple considéré, la valeur courante est une valeur numérique du compteur kilométrique du véhicule 100 ; - évaluation de la première condition en fonction de la valeur courante obtenue. L’évaluation peut comprendre la comparaison entre la valeur courante et la première valeur. La première condition est réalisée si le résultat de la comparaison est conforme à la première relation définie dans la première condition. Dans l’exemple ci-dessus, la première condition est réalisée si la valeur courante du compteur kilométrique est supérieure à 10 000 kilomètres ; - exécution de la première action en fonction de l’évaluation de la première condition. Comme indiqué précédemment, l’exécution de la première action peut comprendre l’envoi d’une instruction à l’application compagnon du terminal utilisateur 140 ou du système d’info-divertissement 103 du véhicule 100, ou à une API de commande du véhicule dans le deuxième serveur 111.2. L’instruction peut correspondre à une notification standard d’un système d’exploitation hébergeant la deuxième application ou peut être une notification selon le protocole de communication MQTT, soit « Message Queuing Telemetry Transport » en anglais. Comme expliqué précédemment, si la première règle comprend plusieurs conditions, plusieurs API d’accès sont interrogées, plusieurs valeurs courantes sont obtenues et les conditions sont toutes évaluées. L’exécution de la première action dépend alors de l’opérateur logique et des évaluations des différentes conditions. Le premier service peut être configuré de manière à ce que l’étape d’interrogation de l’API d’accès soit mise en œuvre à une fréquence donnée. La présente la structure d’un dispositif de configuration de service 150 selon un mode de réalisation de l’invention. Le dispositif de configuration de service 150 comprend un processeur 401 configuré pour communiquer de manière unidirectionnelle ou bidirectionnelle, via un ou des bus ou via une connexion filaire directe, avec une mémoire 402 telle qu’une mémoire de type « Random Access Memory », RAM, ou une mémoire de type « Read Only Memory », ROM, ou tout autre type de mémoire (Flash, EEPROM, etc). En variante, la mémoire 402 comprend plusieurs mémoires des types précités. La mémoire 402 est apte à stocker, de manière permanente ou temporaire, au moins certaines des données utilisées et/ou issues de la mise en œuvre des étapes du procédé de configuration de service selon l’invention illustré en référence à la . En particulier, la mémoire 402 peut être apte à stocker des fichiers d’exécution, et optionnellement un fichier d’installation, de la première application ainsi que les données utilisées par la première application, tels que les URL des API d’accès et des API de commande, les paramètres d’utilisation et de sécurité associés aux accès aux API d’accès et aux API de commande, les actions possibles 201, les données véhicule disponibles 202, les codes mnémoniques associés, et, au moins temporairement, les règles définies par l’utilisateur du dispositif de configuration de service 150. Le processeur 401 est apte à exécuter des instructions, stockées dans la mémoire 402, pour la mise en œuvre des étapes du procédé selon l’invention, décrites en référence à la . Le dispositif de configuration de service 150 comprend une interface réseau 403 apte à accéder au réseau 110, et donc aux entités accessibles via le réseau 110, tel que décrit précédemment. L’interface réseau 403 peut être filaire, tel qu’un port Ethernet ou peut être sans fil, tel qu’un module d’accès Wifi par exemple. Le dispositif de configuration de service 150 comprend en outre une interface de commande 404 apte à recevoir des entrées utilisateur par l’utilisateur de la première application. Aucune restriction n’est attachée à l’interface de commande 404 qui peut être une interface tactile ou haptique, ou une interface vocale comprenant un microphone. Le dispositif de configuration de service 150 comprend un écran 405 apte à afficher la première interface graphique 200 présentée précédemment. L’écran 405 et l’interface de commande 404 peuvent être une seule et même interface, lorsque l’écran 405 est tactile. La présente invention ne se limite pas aux formes de réalisation décrites ci-avant à titre d’exemples ; elle s’étend à d’autres variantes. Procédé de configuration d’un service automobile comprenant les étapes suivantes: - exécution (302) d’une première application, comprenant la mise à disposition d’une première interface graphique utilisateur (200), ladite première interface graphique utilisateur indiquant des actions possibles (201) et des données de véhicule (202) d’un véhicule (100), la première application étant apte à configurer un accès à des valeurs courantes et/ou des états courants des données véhicule via au moins une interface de programmation d’application dudit véhicule; - création (303) d’une première règle (203.1) à partir d’au moins une entrée utilisateur, ladite première règle identifiant au moins une première condition définie à partir d’au moins une première donnée véhicule et identifiant au moins une première action parmi les actions possibles; - configuration (304) d’un service automobile basé sur ladite première règle, de manière à ce qu’une mise en œuvre du service automobile comprenne l’obtention d’une première valeur courante pour la première donnée véhicule, une évaluation de la première condition à partir de la première valeur courante, et une exécution de la première action en fonction de l’évaluation de la première condition. Procédé selon la revendication 1, dans lequel l’exécution de la première action comprend l’envoi d’une instruction d’exécuter la première action à un terminal (140) d’un utilisateur du véhicule ou à un système d’info-divertissement (103) du véhicule (100). Procédé selon la revendication 2, dans lequel une deuxième application est installée dans le terminal (140) de l’utilisateur ou dans le système d’info-divertissement (103) du véhicule (100), et dans lequel l’exécution de la première action comprend l’envoi de l’instruction au terminal de l’utilisateur ou au système d’info-divertissement du véhicule, et l’exécution de la première action par la deuxième application installée dans le terminal de l’utilisateur ou dans le système d’info-divertissement du véhicule. Procédé selon la revendication 1, dans lequel l’exécution de la première action comprend l’envoi d’une instruction d’exécuter la première action à une deuxième interface de programmation d’application du véhicule (100), ladite deuxième interface de programmation d’application étant apte à commander au moins un équipement (105.1 ; 105.2) du véhicule. Procédé selon l’une des revendications précédentes, dans lequel la première condition définit une première relation entre la première donnée du véhicule et une première valeur ou entre la première donnée du véhicule et un premier état, et dans lequel la vérification de la première condition comprend la comparaison de la valeur courante ou de l’état courant de la première donnée avec la première valeur ou avec le premier état, pour vérifier si la première relation est réalisée. Procédé selon l’une des revendications précédentes, dans lequel la première règle (203.1) comprend au moins une deuxième condition définie à partir d’au moins une deuxième donnée véhicule, dans lequel l’exécution du service automobile comprend en outre l’obtention d’une deuxième valeur courante de la deuxième donnée véhicule via ladite au moins une interface de programmation d’application et une évaluation de la deuxième condition à partir de la deuxième valeur courante, dans lequel l’exécution de la première action est fonction de l’évaluation de la première condition et de l’évaluation de la deuxième condition. Procédé selon la revendication 6, dans lequel la première règle (203.1) comprend un opérateur logique entre la première condition et la deuxième condition, et dans lequel l’exécution de la première action est fonction de l’évaluation de la première condition, de l’évaluation de la deuxième condition et de l’opérateur logique. Procédé selon l’une des revendications précédentes, comprenant une étape de définition des actions possibles (201) et/ou des données véhicule (202) indiquées par la première interface graphique utilisateur (200) par un administrateur de la première application. Programme informatique comportant des instructions pour la mise en œuvre du procédé selon l’une des revendications précédentes, lorsque ces instructions sont exécutées par un processeur (401). Dispositif de configuration de service (150) comprenant un processeur (401) apte à mettre en oeuvre les étapes suivantes : - exécution d’une première application, comprenant la mise à disposition d’une première interface graphique utilisateur (200), ladite première interface graphique utilisateur indiquant des actions possibles (201) et des données de véhicule (202) d’un véhicule (100), la première application étant apte à configurer un accès à des valeurs courantes et/ou des états courants des données du véhicule via au moins une interface de programmation d’application dudit véhicule; - création d’une première règle (203.1) à partir d’au moins une entrée utilisateur, ladite première règle identifiant au moins une première condition définie à partir d’au moins une première donnée du véhicule et identifiant au moins une première action parmi les actions possibles; - configuration d’un service automobile basé sur ladite première règle, de manière à ce qu’une mise en œuvre du service automobile comprenne l’obtention d’une première valeur courante pour la première donnée du véhicule, une évaluation de la première condition à partir de la première valeur courante, et une exécution de la première action en fonction de l’évaluation de la première condition.