FR 3160028 A1 20250912 FR 2402345 A 20240308 La présente invention concerne un procédé et un dispositif de contrôle d’un ensemble d’applications embarquées dans un véhicule, une pluralité de modes d’exécution étant associés à chaque application, des besoins en ressources et des notes locales étant associées à chaque mode d’exécution. A cet effet, une requête de configuration de l’ensemble d’applications est reçue (61). Des notes globales associées à chaque mode d’exécution sont déterminées (62) à partir des notes locales et de poids permettant de hiérarchiser les modes d’exécution. Un ou plusieurs modes d’exécution sont déterminés (63) pour chaque application en fonction des besoins en ressources et des ressources disponibles. Un niveau d’acceptation utilisateur associé à chaque mode d’exécution est en outre déterminé à partir des notes globales. Un mode d’exécution est sélectionné (64) en fonction des niveaux d’acceptation utilisateur. L’exécution de l’ensemble d’applications est contrôlée (65) en fonction des modes d’exécution sélectionnés. Figure pour l’abrégé : Figure 6 Procédé et dispositif de contrôle d’applications embarquées dans un véhicule La présente invention concerne les procédés et dispositifs ou systèmes de contrôle d’un ensemble d’applications embarquées dans un véhicule, notamment un véhicule automobile. La présente invention concerne également un procédé et un dispositif de contrôle du mode d’exécution selon lequel chaque application est mise en œuvre dans le véhicule. Arrière-plan technologique Les véhicules contemporains embarquent nombre de calculateurs assurant chacun une ou plusieurs fonctions, telles que par exemple la gestion de l’aide à la conduite, de l’antipatinage, de la répartition électronique du freinage, la commande d’actionneurs pour assurer le fonctionnement optimal d’un moteur, le pilotage et le contrôle du système d’infodivertissement, aussi appelé système IVI (de l’anglais « In-Vehicle Infotainment » ou en français « Infodivertissement embarqué ») et/ou d’autres systèmes embarqués dans le véhicule tels que par exemple le système de climatisation et le système de navigation du véhicule. Ces calculateurs sont aussi appelés UCE (« Unité de Commande Electronique » ou en anglais ECU « Electronic Control Unit »). Ces calculateurs embarquent des logiciels qui sont exécutés pour assurer les fonctions dont ils ont la charge. A titre d’exemple, un calculateur moteur, aussi appelé « boîtier de servitude moteur » ou « unité de commande moteur », est configuré pour collecter des données d’entrée (de capteurs ou autres), traiter ces données et envoyer des signaux de commande à divers composants (actionneurs) du moteur. Ces applications correspondent à des modules logiciels mis en œuvre par un ou plusieurs calculateurs du véhicule, certaines de ces applications correspondant à des applications interactives, également appelées vignette interactive (de l’anglais « widget »). Ces applications embarquées sont prévues pour être mises à jour, par exemple pour améliorer le fonctionnement de ces applications ou pour offrir plus de services aux utilisateurs du véhicule, via le téléchargement de données de mises à jour selon un mode de communication dit OTA (de l’anglais « Over The Air » ou en français « par voie aérienne ») ou FOTA (de l’anglais « Firmware Over-The-Air » ou en français « firmware par liaison radio »), les véhicules disposant d’un système de communication configuré pour communiquer via un réseau sans fil avec un ou plusieurs dispositifs distants du « cloud » (ou « nuage » en français) par exemple. Les applications embarquées peuvent en outre être complétées par l’installation de nouvelles applications, enrichissant ainsi l’offre de services embarqués proposés aux utilisateurs du véhicule. Un des problèmes qui se pose est que l’évolution logicielle du véhicule, avec l’accroissement des besoins en ressources (en termes de puissance de calcul, d’empreinte mémoire, de bande passante, etc.) qui en découle, se fait avec une architecture matérielle prévue lors de la conception du véhicule, laquelle peut se révéler parfois insuffisante pour assurer la mise en œuvre de plusieurs applications en parallèle. L’exécution simultanée de plusieurs applications peut ainsi générer des problèmes avec un fonctionnement dégradé d’une ou plusieurs applications, une interruption de la mise en œuvre d’une ou plusieurs applications, ce qui dégrade l’expérience utilisateur. De plus, une telle situation dépend de l’écosystème d’applications embarquées dans le véhicule, c’est-à-dire de l’ensemble des applications présentes ou installées dans le système ou dans un sous-système embarqué du véhicule. Un autre problème qui se pose est de gérer les applications embarquées lorsque les ressources machine sont insuffisantes de manière à acceptable du point de vue de l’utilisateur alors que les attentes d’un utilisateur à un autre peuvent être différentes. Résumé de la présente invention Un objet de la présente invention est de résoudre au moins l’un des problèmes de l’arrière-plan technologique décrit précédemment. Un autre objet de la présente invention est d’améliorer le fonctionnement des applications embarquées dans un véhicule en fonction de leur écosystème. Un autre objet de la présente invention est, par exemple, d’améliorer l’expérience utilisateur vis-à-vis de l’exécution des applications embarquées dans le véhicule. Selon un premier aspect, la présente invention concerne un procédé de contrôle d’un ensemble d’applications embarquées dans un véhicule, une pluralité de modes d’exécution étant associée à chaque application de l’ensemble d’application, des premières données représentatives de besoins en ressources étant associées à chaque mode d’exécution de la pluralité de modes d’exécution et des deuxièmes données représentatives d’au moins une note locale attribuée à une expérience utilisateur étant associées à chaque mode d’exécution de la pluralité de modes d’exécution, le procédé étant mis en œuvre par au moins un processeur et comprenant les étapes suivantes : - réception d’une requête de configuration de l’ensemble d’applications, la requête comprenant des troisièmes données représentatives de ressources courantes disponibles associées au véhicule ; - détermination de quatrièmes données représentatives d’au moins une note globale associée à chaque mode d’exécution dans la pluralité de modes d’exécution à partir des deuxièmes données et de données représentatives d’un ensemble d’au moins un poids ; - détermination, pour chaque application de l’ensemble d’applications, de : ● un ensemble de modes d’exécution dans la pluralité de modes d’exécution en fonction des premières et troisièmes données, l’ensemble de modes d’exécution comprenant au moins un mode d’exécution, et ● une information représentative de niveau d’acceptation utilisateur associé à chaque mode d’exécution de l’ensemble de modes d’exécution, dit niveau AXIL, en fonction des quatrièmes données ; - sélection, pour chaque application de l’ensemble d’applications, d’un mode d’exécution dans l’ensemble de modes d’exécution en fonction des niveaux AXIL ; - contrôle d’exécution de l’ensemble d’applications en fonction des modes d’exécution sélectionnés. Un tel procédé permet de sélectionner un ou plusieurs modes d’exécution pour chaque application à mettre en œuvre par le véhicule en fonctions de l’ensemble d’applications, des besoins en ressources associées à ce ou ces modes d’exécution et en fonction des ressources disponibles au niveau du véhicule. La prise en compte d’un niveau d’acceptation de chaque mode d’exécution par un utilisateur permet de choisir les modes d’exécution les plus adaptés pour améliorer l’expérience utilisateur. L’introduction d’un critère relatif à l’expérience utilisateur pour la sélection du mode de fonctionnement ou d’exécution de l’ensemble d’applications permet d’améliorer la satisfaction des utilisateurs, tout en prenant en compte la réalité physique (ressources disponibles et ressources nécessaires) pour la mise en œuvre ou l’exécution des applications dans un contexte donné tandis que l’introduction de poids permet de hiérarchiser l’importance relative de chaque application par rapport à l’ensemble d’applications. Selon une variante, l’ensemble d’au moins un poids est déterminé pour chaque mode d’exécution de chaque application par rapport à l’ensemble d'applications. Selon une autre variante, l’ensemble d’au moins un poids est associé à un profil utilisateur. Selon encore une variante, le procédé comprend en outre une étape de réception de données représentatives d’une évaluation utilisateur, l’ensemble d’au moins un poids étant déterminé par un modèle de prédiction de poids à partir des données représentatives d’une évaluation utilisateur. Selon une variante supplémentaire du procédé, l’au moins une note locale et l’au moins une note globale comprennent chacune un ensemble de critères d’évaluation comprenant : - un premier critère représentatif d’un niveau de facilité à assurer une fonction sans assistance de chaque application ; - un deuxième critère représentatif d’un taux d’utilisation de chaque application ; et - un troisième critère représentatif d’un niveau de qualité de service perçue pour chaque mode d’exécution de chaque application. Selon encore une autre variante du procédé, l’étape de détermination est mise en œuvre par un serveur distant, les quatrièmes données étant émises par le serveur distant à destination d’un calculateur embarqué dans le véhicule. Selon un deuxième aspect, la présente invention concerne un dispositif de contrôle d’un ensemble d’applications embarquées dans un véhicule, le dispositif comprenant une mémoire associée à un processeur configuré pour la mise en œuvre des étapes du procédé selon le premier aspect de la présente invention. Selon un troisième aspect, la présente invention concerne un véhicule, par exemple de type automobile, comprenant un dispositif tel que décrit ci-dessus selon le deuxième aspect de la présente invention. Selon un quatrième aspect, la présente invention concerne un système comprenant un véhicule tel que décrit ci-dessus selon le troisième aspect de la présente invention et un serveur, le système étant configuré pour la mise en œuvre des étapes du procédé selon le premier aspect de la présente invention. Selon un cinquième aspect, la présente invention concerne un programme d’ordinateur qui comporte des instructions adaptées pour l’exécution des étapes du procédé selon le premier aspect de la présente invention, ceci notamment lorsque le programme d’ordinateur est exécuté par au moins un processeur. Un tel programme d’ordinateur peut utiliser n’importe quel langage de programmation, et être sous la forme d’un code source, d’un code objet, ou d’un code intermédiaire entre un code source et un code objet, tel que dans une forme partiellement compilée, ou dans n’importe quelle autre forme souhaitable. Selon un sixième aspect, la présente invention concerne un support d’enregistrement lisible par un ordinateur sur lequel est enregistré un programme d’ordinateur comprenant des instructions pour l’exécution des étapes du procédé selon le premier aspect de la présente invention. D’une part, le support d’enregistrement peut être n'importe quel entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une mémoire ROM, une mémoire RAM, un CD-ROM ou une mémoire ROM de type circuit microélectronique, ou encore un moyen d'enregistrement magnétique ou un disque dur. D'autre part, ce support d’enregistrement peut également être un support transmissible tel qu'un signal électrique ou optique, un tel signal pouvant être acheminé via un câble électrique ou optique, par radio classique ou hertzienne ou par faisceau laser autodirigé ou par d'autres moyens. Le programme d’ordinateur selon la présente invention peut être en particulier téléchargé sur un réseau de type Internet. Alternativement, le support d'enregistrement peut être un circuit intégré dans lequel le programme d’ordinateur est incorporé, le circuit intégré étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question. Brève description des figures D’autres caractéristiques et avantages de la présente invention ressortiront de la description des exemples de réalisation particuliers et non limitatifs de la présente invention ci-après, en référence aux figures 1 à 7 annexées, sur lesquelles : FIG. 1 illustre schématiquement un système embarqué de véhicule, selon un exemple de réalisation particulier et non limitatif de la présente invention ; FIG. 2 illustre schématiquement une table définissant un ensemble de niveaux d’acceptation utilisateur de modes d’exécution pour des applications mises en œuvre par le système embarqué du véhicule de la FIG. 1 , selon un exemple de réalisation particulier et non limitatif de la présente invention ; FIG. 3 illustre schématiquement un processus de détermination de niveau d’acceptation utilisateur pour chaque mode d’exécution d’un ensemble d’applications mises en œuvre par le système embarqué du véhicule de la FIG. 1 , selon un exemple de réalisation particulier et non limitatif de la présente invention ; FIG. 4 illustre schématiquement un processus d’optimisation de niveau d’acceptation utilisateur pour chaque mode d’exécution d’un ensemble d’applications mises en œuvre par le système embarqué du véhicule de la FIG. 1 , selon un exemple de réalisation particulier et non limitatif de la présente invention ; FIG. 5 illustre schématiquement un dispositif de contrôle d’un ensemble d’applications embarquées dans le véhicule de la FIG. 1 , selon des exemples de réalisation particuliers et non limitatifs de la présente invention ; FIG. 6 illustre un organigramme des différentes étapes d’un procédé de contrôle d’un ensemble d’applications embarquées dans le véhicule de la FIG. 1 , selon un exemple de réalisation particulier et non limitatif de la présente invention ; et FIG. 7 illustre schématiquement un processus de génération de la table de la FIG. 2 , selon des exemples de réalisation particuliers et non limitatifs de la présente invention. Description des exemples de réalisation Un procédé et un dispositif de contrôle d’un ensemble d’applications embarquées dans un véhicule vont maintenant être décrits dans ce qui va suivre en référence conjointement aux figures 1 à 7. Des mêmes éléments sont identifiés avec des mêmes signes de référence tout au long de la description qui va suivre. Les termes « premier(s) », « deuxième(s) » (ou « première(s) », « deuxième(s) »), etc. sont utilisés dans ce document par convention arbitraire pour permettre d’identifier et de distinguer différents éléments (tels que des opérations, des moyens, etc.) mis en œuvre dans les modes de réalisation décrits ci-après. De tels éléments peuvent être distincts ou correspondre à un seul et unique élément, selon le mode de réalisation. Selon un exemple particulier et non limitatif de réalisation de la présente invention, le contrôle de l’exécution ou de la mise en œuvre d’un ensemble d’applications embarquées dans un véhicule, par exemple par un ou plusieurs calculateurs du système embarqué du véhicule, comprend la réception d’une requête de configuration de l’ensemble d’applications. Une telle requête est par exemple reçue par un calculateur du système embarqué lorsqu’une ou plusieurs conditions d’un contexte courant de mise en œuvre des applications varient (par exemple avec la réception d’une requête pour exécuter une nouvelle application, lorsque des ressources du véhicule sont mobilisées pour le déclenchement d’un nouveau service, lorsque la bande passante disponible au niveau du réseau auquel est connecté lé véhicule varie, etc.). Une telle requête comprend des troisièmes données représentatives de ressources courantes disponibles associées au véhicule, par exemple des ressources de calcul, de mémoire ou des ressources réseau. Il est déterminé pour chaque application de l’ensemble d’applications un ensemble de modes d’exécution parmi une pluralité de modes d’exécution associées à chaque application de l’ensemble en fonction de premières données représentatives des besoins en ressources associés à chaque mode d’exécution et en fonction des troisièmes données. Il est également déterminé une information représentative d’un niveau d’acceptation utilisateur associé à chaque mode d’exécution de l’ensemble de modes d’exécution, dit niveau AXIL (de l’anglais « Automotive eXperience Integrity Level » ou en français « niveau d’intégrité d’expérience automobile »). Ce niveau AXIL est déterminé en fonction de quatrièmes données représentatives de notes globales associées à chaque mode d’exécution déterminées à partir de deuxièmes données représentatives d’au moins une note locale attribuée à une expérience utilisateur associée à chaque mode d’exécution et de poids, aussi appelés facteurs de pondération, les poids permettant de relativiser les modes d’exécution des applications par rapport à l’ensemble des applications. Ce niveau AXIL est déterminé en fonction de règles prenant également comme critères d’entrée des paramètres d’un profil utilisateur et/ou d’un contexte d’exécution courant de l’ensemble d’applications. Le niveau AXIL est utilisé pour sélectionner, pour chaque application, un mode d’exécution parmi le ou les modes d’exécutions déterminés pour chaque application. L’exécution de l’ensemble d’applications est contrôlée selon les modes d’exécution sélectionnés pour l’ensemble d’applications. Un tel procédé permet ainsi de prendre en compte un critère relatif à l’expérience utilisateur et/ou à un écosystème d’applications embarquées dans le véhicule dans la gestion ou le contrôle de l’exécution d’un ensemble d’applications embarquées, permettant ainsi de maximiser l’expérience utilisateur en fonction des applications à faire fonctionner en parallèle selon les ressources disponibles au niveau du véhicule, dans un contexte d’exécution donné. Cela permet ainsi de d’assurer un certain niveau de qualité de service tel que défini par exemple dans un document de type SLA (de l’anglais « Service-Level Agreement » ou en français « accord de niveau de service ») fourni au fabricant ou au concepteur d’une application. Un tel procédé permet en outre d’adapter les conditions d’exécution (ou « runtime » en anglais) des applications sur la base des capacités réseau et matériel disponibles. L’utilisation du niveau AXIL permet par exemple d’optimiser l’expérience utilisateur générale en utilisant par exemple des modes d’exécution dégradés pour certaines des applications, plutôt que de désactiver totalement une ou plusieurs applications pour permettre aux autres applications de tourner pour assurer les services associés. De plus, le niveau AXIL est déterminé par pondération pour chaque application, par exemple en fonction des autres applications embarquées formant alors l’écosystème d’applications, et/ou en fonction d’un profil utilisateur. Le procédé permet ainsi d’exécuter plus d’applications en parallèle, quitte à faire fonctionner certaines de ces applications dans un mode dégradé acceptable par l’utilisateur, le niveau d’acceptation étant défini par le niveau AXIL. Cela permet ainsi de faire évoluer le véhicule d’un point de vue applicatif en autorisant la mise en œuvre de plus d’applications avec une même configuration matérielle du véhicule. La FIG. 1 illustre schématiquement l’architecture électronique et électrique, dite architecture E/E, d’un véhicule 10, selon un exemple de réalisation particulier et non limitatif de la présente invention. L’architecture E/E comprend un ensemble de calculateurs ou ECUs 101, 102, 103 reliés entre eux par des bus de données pour former un réseau mixant par exemple plusieurs technologies telles qu’Ethernet (selon la norme ISO/IEC 802-3) d’une part et CAN (de l’anglais « Controller Area Network » ou en français « Réseau de contrôleurs »), CAN FD (de l’anglais « Controller Area Network Flexible Data-Rate » ou en français « Réseau de contrôleurs à débit de données flexible »), LIN (de l’anglais « Local Interconnect Network », ou en français « Réseau interconnecté local ») ou FlexRay (selon la norme ISO 17458) d’autre part. Une telle architecture correspond par exemple à une architecture dite ZOA (de l’anglais « Zonal Oriented Architecture » ou en français « architecture orientée zones »), une telle architecture étant orienté service (ou SOA, de l’anglais « Service Oriented Architecture »). Une telle architecture est connue de l’homme du métier et est par exemple décrite dans le document intitulé « Making the Case for Centralized Automotive E/E Architectures » publié par Victir Bandur, Gehan Selim, Vera Pantelic at Mark Lawford le 02 février 2021. L’ensemble de calculateurs comprend par exemple des premiers calculateurs chacun illustré par un rectangle blanc 101 sur la FIG. 1 reliés entre eux par une dorsale (de l’anglais « backbone ») de type Ethernet. Ces premiers calculateurs correspondent par exemple à des ECUs de type HPC (de l’anglais « High Performance Computing » ou en français « Calcul haute performance »). L’ensemble de calculateurs comprend en outre des deuxièmes calculateurs chacun illustré par un rectangle gris 102 de dimensions inférieures au rectangle blanc 101 et des troisièmes calculateurs chacun illustré par un rectangle noir 103 de dimensions inférieures au rectangle gris 102. Ces deuxièmes et troisièmes calculateurs sont reliés entre eux et aux premiers calculateurs 101 pour former des réseaux de type CAN, CAN FD ou LIN par exemple, ces premiers et deuxièmes calculateurs correspondant à des calculateurs spécialisés et/ou contrôlant des actionneurs et/ou capteurs. Les services proposés à un utilisateur du véhicule et obtenus via la mise en œuvre ou l’exécution d’une ou plusieurs applications partagent la dorsale Ethernet malgré les besoins très variés en termes de QoS (de l’anglais « Quality-of-Service » ou en français « Qualité de service »). Une application de divertissement pour la diffusion en flux continu (de l’anglais « streaming ») de vidéo (application de type « au mieux » ou « best-effort application » en anglais) n’a ainsi pas les mêmes besoins en termes de ressources qu’une application de contrôle du moteur temps réel (application sensible au temps), par exemple en termes de bande passante, latence, gigue (de l’anglais « jitter »), taux de perte (de l’anglais « loss rate »), qualité de service, charge de calcul (CPU), empreinte mémoire, etc. Bien entendu, l’architecture E/E embarquée dans le véhicule 10 ne se limite pas à l’exemple ci-dessus mais s’étend à tout type d’architecture, par exemple une architecture orientée domaine ou encore une architecture centralisée (avec passerelle centralisée), de telles architectures étant également décrites dans le document intitulé « Making the Case for Centralized Automotive E/E Architectures ». Un processus de contrôle d’un ensemble d’applications embarquées dans le véhicule pour le véhicule 10 est avantageusement mis en œuvre par un ou plusieurs processeurs d’un ou plusieurs calculateurs du véhicule 10, par exemple un calculateur 101 de l’architecture E/E du véhicule 10 faisant office de contrôleur par exemple. Dans une première opération du processus, une requête de configuration ou de reconfiguration d’un ensemble d’applications est reçue. L’ensemble d’applications comprend par exemple une pluralité d’applications en cours de fonctionnement ou en cours d’exécution au moment de la réception de la requête. La requête est par exemple générée lors d’un changement de contexte au niveau du véhicule 10, par exemple un changement de contexte au niveau de l’architecture E/E. Un changement de contexte est par exemple détecté lors de la réception d’une requête d’exécution d’une ou plusieurs nouvelles applications en plus de la ou les applications déjà en cours d’exécution. Une requête d’exécution d’une nouvelle application est par exemple reçue d’une interface homme-machine du véhicule 10 lorsque la requête émane d’un utilisateur souhaitant la mise en œuvre d’un ou plusieurs services via cette nouvelle application. Selon un autre exemple, une requête d’exécution d’une nouvelle application est par exemple générée par un calculateur du véhicule 10 contrôlant un système ADAS (de l’anglais « Advanced Driver-Assistance System » ou en français « Système d’aide à la conduite avancé ») du véhicule 10. Par exemple, le véhicule 10 peut recevoir des données via un mode de communication de type V2X (de l’anglais « Vehicle-to-Everything » ou en français « Véhicule vers tout ») requérant la mise en œuvre d’un service particulier pour optimiser le trafic par exemple, la mise en œuvre de l’application associée étant par exemple prioritaire par rapport aux applications de type « au mieux ». Selon encore un exemple, un changement de contexte est détecté lorsqu’un composant de l’architecture E/E rencontre un problème réduisant par exemple les ressources disponibles pour la mise en œuvre des applications et services associés. La requête de configuration ou de reconfiguration comprend avantageusement des troisièmes données représentatives de ressources courantes disponibles au niveau du véhicule 10, par exemple en termes de puissance de calcul disponibles, de taille mémoire disponible, de périphériques disponibles ou encore en termes de ressources réseau (bande passante, latence, gigue). Dans une deuxième opération du processus, comme illustré dans la FIG. 7 , le calculateur en charge du processus détermine des quatrièmes données représentatives d’au moins une note globale 76 associée à chaque mode d’exécution dans une pluralité de modes d’exécution associés à chaque application 431 de l’ensemble d’applications à partir des deuxièmes données et de données représentatives d’un ensemble d’au moins un poids 74, aussi appelé facteur de pondération. Selon un exemple de réalisation particulier, l’ensemble d’au moins un poids 74 est déterminé pour chaque mode d’exécution de chaque application 431 par rapport à l’ensemble d'applications installées dans le système embarqué du véhicule 10 ou par rapport à un ensemble d’applications disponibles sur une plateforme de téléchargement ou d’obtention d’applications. L’ensemble d’applications installées dans le système embarqué du véhicule 10 ou disponibles sur une plateforme de téléchargement ou d’obtention d’applications est par la suite appelé écosystème. En effet, pour chaque mode d'exécution, le développeur d’une application 431 définit des notes locales 75, aussi appelées valeurs UX locales, pour décrire la priorité d'exécution de chaque mode par rapport aux autres modes. Ces notes locales 75 ne sont pas prises en compte dans l'écosystème et ne sont par conséquent pas directement utilisables car elles ne tiennent pas compte des interactions réelles entre plusieurs applications de l’écosystème dans les véhicules. C’est ensuite, par exemple, le constructeur du véhicule 10 qui définit les poids 74 à attribuer à chacune des notes locales 75. Ces poids 74 sont combinés, par exemple, multipliés ou combinés à l'aide d'une fonction définie par des experts en expérience utilisateur, appelés experts UX, avec les notes locales 75 pour obtenir des notes globales 76, aussi appelées valeurs UX globales. Les poids 74 sont représentatifs d’informations sur l'utilisation globale de chaque application 431 et ses modes d'exécution par rapport à l'écosystème. Par exemple, si une première application est utilisée deux fois plus souvent qu'une autre, les notes locales de cette première application sont pondérées avec un ou plusieurs poids supérieurs à celui ou ceux pondérant les notes locales de la deuxième application, permettant alors d’obtenir des notes globales associées à la première application supérieures à des notes globales associées à la deuxième application, la première application devenant ainsi prioritaire dans son exécution par rapport à la deuxième application. Diverses méthodes sont utilisables pour définir ces poids 74 ou facteurs de pondération : Une première méthode consiste en la modélisation par des experts tels que des ingénieurs, des spécialistes de la vente (en anglais « marketing ») et/ou des chercheurs en expérience utilisateur. Les poids 74 pour des applications individuelles, mais aussi pour des catégories entières d'applications, sont définis en fonction des attentes supposées des utilisateurs. Par exemple, les applications de navigation devraient avoir une priorité plus élevée que les applications d'infodivertissement. Une deuxième méthode consiste en l’établissement d’enquêtes auprès des utilisateurs et en l’utilisation de techniques traditionnelles de recherche expérience utilisateur, aussi appelée recherche UX, telles que des enquêtes régulières ciblées auprès d’un ensemble d’utilisateurs 71. Une telle deuxième méthode permet ainsi de construire différents profils utilisateurs formant alors un ensemble de profils utilisateurs 72, et de déterminer des poids pour chaque profil utilisateur de l’ensemble de profils utilisateurs 72. Ainsi, au moins un poids 74 est associé à un profil utilisateur 73. Le profil utilisateur 73 représente par exemple les préférences ou attentes du conducteur ou d’un passager du véhicule 10, les poids 74 associés à ce profil utilisateur 73 permettent alors de déterminer des notes globales associées à chaque mode d’exécution dans la pluralité de modes d’exécution associés à chaque application 431 de l’ensemble d’applications. Les passagers peuvent ainsi définir des préférences lors de l'élaboration de leur profil, par exemple sur une interface homme-machine, dite IHM, embarquée dans le véhicule 10 ou via un dispositif de communication mobile relié en communication avec le véhicule 10 comme un smartphone ou un ordinateur portable. Les préférences prennent, par exemple, la forme de questions créées par les constructeurs automobiles pour évaluer les préférences utilisateur. Ces questions peuvent prendre n'importe quelle forme. Par exemple, elles peuvent prendre la forme d'une note de 1 à 5 étoiles pour chaque catégorie d'applications, par exemple, navigation, infodivertissement, applications pour les enfants, fonctions ADAS, etc., 5 signifiant "extrêmement important pour moi" et 1 signifiant "pas important pour moi". En outre, l'utilisateur peut définir des applications ou des fonctions favorites qui doivent fonctionner au maximum de leurs possibilités, c'est-à-dire dans le mode d'exécution optimal de la pluralité de modes d’exécution, c’est-à-dire dans un mode d’exécution nominal ou augmenté tel que décrit ci-après. En utilisant, par exemple, les informations personnelles du conducteur ou du passager du véhicule 10 telles que l'âge, le sexe et les préférences définies précédemment, les utilisateurs sont représentés dans un espace à N dimensions, N étant le nombre de paramètres de données personnelles. La population est donc représentée sous la forme d'un nuage de points, les utilisateurs ayant des profils et des intérêts similaires étant placés plus près les uns des autres dans le nuage de points. Les utilisateurs sont ensuite divisés en groupes d'utilisateurs (en anglais « clusters ») à l'aide de techniques existantes telles que les K-Means ou les techniques d'intégration dans l'espace. Le nombre de grappes et les objectifs de regroupement sont laissés à la libre appréciation des constructeurs de véhicules ou intégrateurs d’applications dans le cadre de la présente invention. Il est également possible de combiner les première et deuxième méthodes. Pour chaque groupe d'utilisateurs, les constructeurs de véhicules ou intégrateurs d’applications réalisent des études séparées sur les utilisateurs afin de définir leurs propres paramètres d'utilisation globale. Le nombre de grappes est donc un compromis entre la personnalisation de l'utilisateur et la complexité logistique. Les poids générés à partir de mesures globales d'utilisation pour chaque groupe sont appliqués aux notes locales ou valeurs UX locales de chaque application. Les première et deuxième méthodes peuvent cependant être fastidieuses, nécessitant des efforts importants d'ingénierie et de recherche et, par conséquent, poser des problèmes d'évolutivité. Une troisième méthode est alors proposée. Cette troisième méthode consiste par exemple à déterminer des notes locales initiales suivant la première et/ou la deuxième méthode, ces notes locales initiales pouvant être approximatives. Occasionnellement, par exemple à des moments aléatoires, à la fin d'un trajet ou à tout autre moment décidé par le constructeur de véhicules ou intégrateur d’application, le conducteur ou passager d’un véhicule est invité à évaluer son expérience courante en attribuant une note de 1 à 5 étoiles représentative de son niveau de satisfaction, voire en attribuant une note à un aspect précis de son expérience courante. La note attribuée comprend ainsi des données représentatives d’une évaluation utilisateur qui sont envoyées à un serveur et associées à l'état courant du véhicule, c'est-à-dire les combinaisons d'applications actives, les modes d'exécution précédemment actifs, le type de trajet du véhicule, le contexte environnemental, etc., la note attribuée par l’utilisateur et l’état courant du véhicule associé étant alors représentés sous forme d’un point dans un nuage de points. Optionnellement, les constructeurs de véhicules ou intégrateur d’application peuvent poser d'autres questions à la suite de leur évaluation pour obtenir des détails supplémentaires tels que des suggestions d'amélioration, des préférences, etc. En conséquence, le nuage de points est enrichi en permanence via la collection de retour d'information de la part d’une population d'utilisateurs. Différents points du nuage de points sont alors regroupés par profils utilisateurs de l’ensemble de profils utilisateurs 72. A la suite de la réception de données représentatives d’une évaluation utilisateur, l’ensemble d’au moins un poids 74 est déterminé par un modèle de prédiction de poids à partir des données représentatives d’une évaluation utilisateur, c’est-à-dire à partir des points du nuage de points. Un algorithme mis en œuvre dans le modèle de prédiction de poids permet de prédire les meilleures poids 74 en fonction des nombreuses données associées à un profil utilisateur 73, les meilleurs poids 74 permettant statistiquement d’obtenir la meilleure évaluation par un utilisateur. Cette opération peut généralement être résolue à l'aide de modèles d'apprentissage automatique, d'algorithmes de classification ou d'une combinaison des deux. Ce modèle de prédiction de poids produit au moins un poids, voire une collection de poids pour différents états du véhicule et profils d'utilisateurs. Ces poids peuvent être personnalisés pour chaque utilisateur ou généralisés en groupes comme dans les méthodes précédemment présentées. Une ou plusieurs de ces méthodes sont utilisées pour créer des mesures d'utilisations globales afin d'évaluer les priorités relatives d’une application 431 par rapport à l’écosystème. Grâce à un format de description libre, les poids 74 peuvent être librement établis pour les applications ou les modes d'exécution, soit individuellement, soit par groupe d’applications, un groupe d’applications regroupant par exemple des applications par thème ou par usage. Selon un exemple de réalisation particulier, cette deuxième opération de détermination des quatrièmes données est mise en œuvre par un serveur distant, les quatrièmes données étant émises par le serveur distant à destination d’un calculateur embarqué dans le véhicule 10. Ainsi, le serveur distant est par exemple en communication via une liaison sans fil avec le véhicule 10. Cet exemple de réalisation particulier est notamment privilégié dans le cas de la troisième méthode, laquelle utilise le nuage de points généré à partir de données acquises auprès d’utilisateurs d’autres véhicules. En effet, le serveur distant joue un rôle central, il récolte ainsi les données et prédit les meilleurs poids à partir de ces données. Ces meilleurs poids sont appliqués aux notes locales initiales ou à des notes locales déterminées lors d’itérations précédentes pour obtenir des notes globales. Seules les notes globales sont émises à destination du véhicule 10, les données récoltées sont alors protégées car non transmises à différents véhicules. Selon un autre exemple de réalisation particulier, pour chaque application 431, au moins une note locale 75 et au moins une note globale 76 comprennent chacune un ensemble de critères d’évaluation comprenant : - un premier critère, S L pour une note locale, S G pour une note globale, représentatif d’un niveau de facilité pour l’utilisateur à assurer une fonction sans assistance de l’application 431 dans l’ensemble des modes d’exécution ou dans le mode d’exécution considéré, le premier critère S G étant aussi appelé ‘SUBSTITUTION’, c’est-à-dire la facilité selon laquelle l’utilisateur peut se passer du service offert par l’application tout en réussissant à mettre en œuvre la fonction, ce premier critère prenant par exemple 3 niveaux (niveaux S1 à S3, S1 signifiant que l’utilisateur peut se passer facilement de l’application, S2 moyennement et S3 difficilement) : par exemple pour une application d’aide au stationnement, l’indisponibilité de la caméra de recul n’empêche pas un utilisateur moyen d’effectuer la manœuvre de stationnement sans assistance de la caméra, ou encore, si la qualité de rendu de musique d’une application de diffusion en continu de contenus audios est mauvaise, l’utilisateur peut utiliser temporairement son téléphone intelligent (de l’anglais « Smartphone ») connecté en Bluetooth® au véhicule 10 pour écouter de la musique ; - un deuxième critère, E L pour une note locale, E G pour une note globale, représentatif d’un taux d’utilisation de l’application 431 dans l’ensemble des modes d’exécution ou dans le mode d’exécution considéré, aussi appelé ‘UTILISATION’ ou en anglais ‘EXPOSURE’, comportant par exemple 4 niveaux E1 à E4, avec E1 pour une fréquence d’utilisation minimale et faible et E4 une fréquence maximale et très élevée ; et - un troisième critère, Q L pour une note locale, Q G pour une note globale, représentatif d’un niveau de qualité de service perçue pour chaque mode d’exécution de l’application 431, aussi appelé ‘QUALITE DE SERVICE’, comportant par exemple 4 niveaux Q1 à Q4, avec le niveau Q1 correspondant à ‘frustrant’, le niveau Q2 correspondant à ‘ennuyeux’, le niveau Q3 correspondant à ‘acceptable’ et le niveau Q4 à ‘plaisant’. Dans une troisième opération du processus, le calculateur en charge du processus détermine pour chaque application de l’ensemble d’applications (application(s) en cours d’exécution lors de la réception de la requête ainsi que la ou les nouvelles applications et/ou nouveau(x) service(s) dont la mise en œuvre est requise) : - un ensemble de modes d’exécution parmi une pluralité de modes d’exécution disponibles pour chaque application en fonction des premières données représentatives des besoins en ressources associées à chaque mode d’exécution de la pluralité de modes d’exécution et des troisièmes données représentatives des ressources courantes disponibles associées au véhicule 10, et - une information représentative d’un niveau d’acceptation utilisateur associé à chaque mode d’exécution de l’ensemble de modes d’exécution, dit niveau AXIL. Chaque application est configurée pour être mise en œuvre ou exécutée selon une pluralité de modes d’exécutions (de l’anglais « runtime mode »), lesquels sont par exemple définis par le concepteur ou le développeur de l’application. Chaque mode d’exécution est par exemple identifié via un identifiant unique (par exemple codé sur 2 ou plus de bits), la requête d’exécution d’une application comprenant avantageusement l’information relative à l’identification du mode d’exécution selon lequel l’application doit fonctionner ou être mise en œuvre. Le nombre de modes d’exécution associés à ou disponibles pour une application dépend par exemple du type d’application et varie par exemple d’une application à une autre. La pluralité de modes d’exécution associés à une application donnée comprend au minimum 2 modes d’exécution, à savoir : - un premier mode correspondant à un mode d’exécution dite nominale ou standard, un tel premier mode étant représentatif d’un mode selon lequel l’application est exécutée pour fonctionner selon un niveau de performance de référence (tous les services obtenus par l’application sont mis en œuvre tels qu’attendu) ; et - un deuxième mode correspondant à un mode d’exécution dite désactivée selon lequel l’application n’est pas exécutée, c’est-à-dire que l’exécution de l’application est reportée ou tout simplement annulée. Pour au moins une partie des applications embarquées, la pluralité de modes d’exécution disponibles comprend en outre un ou plusieurs modes d’exécutions additionnels, avec par exemple : - un ou plusieurs modes d’exécution dégradés, c’est-à-dire que le niveau de performance obtenu dans un tel mode dégradé est inférieur au niveau de performance de référence, c’est-à-dire que seule une partie des services associés à l’application est mise en œuvre, la qualité de service est inférieure à la qualité de service attendue dans le premier mode d’exécution, etc. ; un mode d’exécution dégradé requiert moins de ressources que le mode d’exécution nominal ; et/ou - un ou plusieurs modes d’exécution augmentés, c’est-à-dire que le niveau de performance obtenu dans un tel mode augmenté est supérieur au niveau de performance de référence, c’est-à-dire que la qualité de service est supérieure à la qualité de service attendue dans le premier mode d’exécution ; un mode d’exécution augmenté requiert plus de ressources que le mode d’exécution nominal. En prenant comme exemple une application de diffusion de vidéo en continu, le mode d’exécution de référence prévoit par exemple une diffusion de vidéo avec une définition égale à 1080p, un premier mode dégradé prévoit une diffusion de vidéo avec une définition égale à 720p, un deuxième mode dégradé prévoit une définition égale à 360p, un quatrième mode dégradé prévoit une définition égale à 144p, un cinquième mode dégradé prévoit de mettre en pause la diffusion pendant une durée déterminée (par exemple 5 ou 10 secondes), etc. En prenant comme exemple une application de téléchargement de contenu, un mode d’exécution augmenté prévoit par exemple un téléchargement de données avec un débit plus important que le débit prévu dans le mode nominal, un tel mode augmenté étant par exemple mis en œuvre lorsque le contexte le permet (bande passante disponible) et dans des situations particulières (par exemple avant que le véhicule ne pénètre dans une zone sans couverture réseau (par exemple une zone blanche, un tunnel)) pour que l’application puisse continuer de fonctionner pendant que le véhicule traverse cette zone sans couverture réseau. Chaque mode d’exécution est accompagné de premières données décrivant les besoins en termes de ressources nécessaires (puissance de calcul, empreinte mémoire, bande passante, latence, gigue, etc.) pour la mise en œuvre du mode d’exécution concerné. Ainsi, à chaque application est associée une pluralité de modes d’exécution et à chaque mode d’exécution est associée une liste de ressources nécessaires (minimales) pour la mise en œuvre du mode d’exécution. Ces informations, correspondant aux premières données, sont par exemple stockées dans une mémoire du calculateur mettant en œuvre le processus ou dans une mémoire du calculateur mettant en œuvre l’application, par exemple sous la forme d’une ou plusieurs LUT (de l’anglais « Look-Up Table » ou en français « table de correspondance »). Ces informations sont par exemple enregistrées dans le véhicule 10 lors de l’installation de l’application associée. Il est ainsi déterminé, pour chaque application de l’ensemble d’applications à mettre en œuvre, une liste ou un ensemble de modes d’exécution compatibles (comprenant au moins un mode d’exécution) avec les ressources disponibles dans le véhicule 10, connaissant les troisièmes données fournissant les ressources disponibles selon le contexte courant d’exécution et les premières données décrivant les besoins en ressources pour chaque mode d’exécution de la pluralité de modes d’exécutions associée à chaque application embarquée. Il est en outre déterminé dans cette troisième opération un niveau AXIL pour chaque application et pour chaque mode d’exécution de l’ensemble de modes d’exécution compatibles avec le contexte courant de l’architecture E/E. Ce niveau AXIL est déterminé selon une règle de calcul associée à chaque mode d’exécution de la pluralité de modes d’exécution disponibles pour chaque application embarquée dans le véhicule 10. Ces règles de calcul sont chacune fonction de paramètres particuliers qui dépendent par exemple de chaque application et/ou du type de l’application. Le niveau AXIL correspond par exemple à un niveau d’acceptation par l’utilisateur d’un mode d’exécution dans un contexte particulier, ce niveau appartenant à un ensemble défini de niveaux comprenant par exemple 5 niveaux : • niveau ‘QM’ (un utilisateur n’attache pas d’importance à un tel mode d’exécution, même si ce dernier correspond à un mode dégradé), • niveau ‘A’ (un utilisateur peut ressentir une différence par rapport au mode nominal mais l’accepte sans problème), • niveau ‘B’ (quelques utilisateurs ressentent une frustration pour la mise en œuvre selon ce mode d’exécution), • niveau ‘C’ (de nombreux utilisateurs ressentent une frustration pour la mise en œuvre selon ce mode d’exécution), et • niveau ‘D’ (mode d’exécution inacceptable en terme d’expérience utilisateur). Le niveau AXIL est déterminé dynamiquement à partir de règles prenant en compte un ensemble de paramètres ou critères tels que des paramètres d’un profil utilisateur (par exemple l’âge de l’utilisateur, les centres d’intérêts de l’utilisateur, les habitudes de l’utilisateur, un historique d’utilisation de l’application comprenant notamment une fréquence d’utilisation de l’application, un historique d’utilisation de modes d’exécution dégradé, un niveau d’abonnement, etc.) et/ou des paramètres de contexte (par exemple des conditions pour accepter un mode d’exécution, un lien ou une dépendance avec d’autres applications, etc.). Selon l’exemple de réalisation particulier décrit précédemment dans lequel chaque application 431 comprend au moins une note locale 75 et au moins une note globale 76 comprenant chacune un ensemble de trois critères d’évaluation, le niveau d’AXIL global est par exemple déterminé en fonction : • du premier critère d’évaluations S G représentatif d’un niveau de facilité pour l’utilisateur à assurer une fonction sans assistance de chaque application dans le mode d’exécution considéré, • du deuxième critère E G représentatif d’un taux d’utilisation de chaque application dans le mode d’exécution considéré ; et • du troisième critère Q G représentatif d’un niveau de qualité de service perçue pour chaque mode d’exécution. La table 20 illustrée en FIG. 2 fournit un exemple d’assignation de niveaux AXIL à chaque mode d’exécution d’une application en fonction des 3 critères d’évaluation définis ci-dessus, la colonne ‘S G ’ correspondant au premier critère, la colonne ‘E G ’ correspondant au deuxième critère et la colonne ‘Q G ’ correspondant au troisième critère. Lorsque le niveau AXIL est déterminé selon des règles de calcul, les 3 critères définis ci-dessus sont par exemple déterminés dynamiquement à partir de règles définies pour chaque critère, le niveau AXIL étant alors calculé comme une fonction prenant en entrée la valeur obtenue pour chacun des 3 critères et fournissant en sortie une valeur d’AXIL par exemple comprise entre 0 et 1 (valeur flottante). Un exemple de processus de détermination de l’information ou du niveau AXIL est illustré sur la FIG. 3 , selon un exemple de réalisation particulier. Dans une opération 31, lorsqu’un changement de contexte est détecté au niveau de l’infrastructure E/E (demande d’exécution d’une nouvelle application, lancement d’un nouveau service, détection d’un évènement impactant les ressources disponibles), une requête est transmise à chaque application en cours d’exécution pour requérir les modes d’exécution disponibles, les besoins en ressources associés à chaque mode d’exécution et les niveaux AXIL associés. Dans une opération 32, les modes d’exécutions disponibles et les besoins en ressources associés sont reçus en réponse à la requête transmise à l’opération 31. Ces informations sont par exemple reçues d’un composant connexe associé à chaque application. Dans une opération 33, le niveau AXIL est déterminé. Les informations relatives au niveau AXIL reçues de l’application correspondent par exemple à des paramètres de règles (équations paramétriques par exemple) pour que soient calculés les niveaux AXIL, pour chaque mode d’exécution. Des informations 310 représentatives d’un contexte d’exécution pour chaque mode d’exécution ou de fonctionnement de l’application sont en outre reçues. Le niveau AXIL est ainsi défini en fonction des notes globales 76, des informations de contexte 310 et de paramètres 330 représentatifs d’un profil utilisateur et/ou de contexte d’utilisation de l’application. Selon une variante, des données 34 représentatives d’un historique de l’application (par exemple les modes d’exécution déjà utilisés) sont en outre pris en compte pour la détermination du niveau AXIL. Un niveau AXIL 331 est ainsi déterminé dynamiquement. Selon une variante, un ou plusieurs paramètres additionnels sont déterminés à l’opération 33, tel que : - un paramètre 332 représentatif d’une durée minimale de commutation pour changer de mode d’exécution, la durée minimale de commutation étant fonction du contexte courant d’exécution 310 de chaque application ; le contexte courant d’une application peut impacter un changement de mode d’exécution requis, par exemple lorsque des tâches sont en cours d’exécution et qu’elles ne doivent pas être interrompues (par exemple lorsque le téléchargement d’un fichier est en cours, lorsque le véhicule 10 effectue une manœuvre sous la supervision d’un module ADAS contrôlé par l’application (par exemple une insertion sur une voie d’autoroute), etc.) ;et/ou - un paramètre 333 représentatif d’une consommation d’énergie par chaque application dans le mode d’exécution sélectionné : une estimation des besoins en énergie est par exemple mise en œuvre pour les fournir à l’infrastructure, ces besoins étant fonction des besoins en ressources associés à chaque mode d’exécution (besoins en ressources réseau et/ou en puissance de calcul). L’information 333 relative aux besoins en consommation d’énergie de chaque mode d’exécution est par exemple utilisée pour sélectionner un mode d’exécution plutôt qu’un autre, par exemple lorsque le véhicule 10 a été configuré (via une IHM par exemple) pour circuler dans un mode d’économie d’énergie avec par exemple une consigne de consommation maximale d’énergie à ne pas dépasser. Les paramètres d’entrée 310, 330, 34 sont utiles pour fournir ou calculer un niveau AXIL dépendant du contexte et du profil de l’utilisateur. Par exemple, si une application doit s’interrompre pendant ‘t’ secondes à un instant temporel ‘T’ (en fonction des ressources disponibles sur cet intervalle) mais que l’application a déjà été interrompue il y a ‘n’ secondes (information obtenue de l’historique d’utilisation ou de l’historique des modes d’exécution utilisés), une nouvelle interruption impliquerait un niveau AXIL défini par une fonction ‘f’ prenant en considération les paramètres ‘t’, ‘T’ et ‘n’ (fonction f(t,T,n)). Dans une quatrième opération du processus, un mode d’exécution est sélectionné parmi l’ensemble de modes d’exécution répondant aux critères des ressources disponibles en fonction des informations AXIL obtenues à la troisième opération, pour chaque application de l’ensemble d’applications. La sélection des modes d’exécution pour l’ensemble d’application est mise en œuvre en prenant en compte les niveaux AXIL afin d’optimiser le niveau AXIL pour l’ensemble des applications et maximiser l’expérience utilisateur. Un tel processus est illustré selon un exemple de réalisation particulier sur la FIG. 4 . Les éléments 41 à 44 de la FIG. 4 correspondent par exemple à des modules ou briques matérielles ou fonctionnelles d’un ou plusieurs composants matériels, par exemple un ECU, de l’infrastructure du véhicule 10. Les contraintes de l’infrastructure E/E sont fournies dans par un ou plusieurs contrôleurs 41 de l’infrastructure E/E du véhicule 10 lorsqu’un changement d’état de l’infrastructure est requis. Ces contraintes de l’infrastructure E/E du véhicule 10 comprennent par exemple : - une description de la topologie physique de l’infrastructure du véhicule 10 (par exemple la liste des ECU, la topologie du réseau reliant les ECU, les capacités de chaque liaison du réseau, les capacités en termes de calcul (CPU) et mémoire, etc.) ; - une ou plusieurs listes de contraintes qui doivent être respectées lorsqu’une configuration est sélectionnée, par exemple : • une configuration réseau valide doit être trouvée avant changement d’état de l’infrastructure, • la consommation totale d’énergie d’une nouvelle configuration doit respecter une valeur maximale (seuil) fixé (par exemple par un utilisateur du véhicule 10), et • une partie de la bande passante doit rester disponible (par exemple 10 Mbit/s) dans toutes les liaisons du réseau. Un module 42 correspondant à un planificateur ou contrôleur des applications transmet une ou plusieurs requêtes à destination d’un module 43 configuré pour déterminer quels modes d’exécution répondent le mieux aux différentes contraintes. Une requête transmise par le module 42 au module 43 comprend par exemple une liste des applications à mettre en œuvre. Le module 43 contrôle la sélection des modes d’exécution pour la liste des applications à mettre en œuvre ou exécuter, en fonction notamment des contraintes reçues du module 41. Le module 43 comprend notamment une brique (logicielle) 433 configurée pour optimiser le niveau AXIL de la nouvelle configuration requise. Cette brique 433 requiert par exemple de chaque application 431 les modes d’exécutions disponibles avec les besoins en ressources associées et le niveau AXIL (ou les règles de calcul permettant de déterminer le niveau AXIL pour chaque mode d’exécution). Chaque application 431 transmet à une brique 432 les informations relatives au contexte d’exécution de l’application avec les règles de calcul, la brique 432 déterminant pour chaque application et chaque mode d’exécution un niveau AXIL (par exemple tel que décrit en regard de la FIG. 3 ). Ces niveaux AXIL sont fournis à la brique 433 pour sélectionner un mode d’exécution pour chaque application de manière à optimiser le niveau AXIL pour l’ensemble des applications. La brique 433 met en œuvre une optimisation pour trouver un compromis optimal entre les niveaux AXIL des modes d’exécution permettant de respecter les contraintes, ou décide de désactiver une ou plusieurs applications ayant un niveau AXIL inférieur (par exemple un niveau ‘QM’ ou ‘A’). La brique 433 transmet en sortie une liste de modes d’exécution pour l’ensemble d’applications (1 mode d’exécution par application) à un module 44 contrôlant la configuration des applications, lequel module 44 transmet à destination de chaque brique applicative 431 le mode d’exécution à activer ou exécuter. Si aucune solution n’est trouvée par la brique 433, un état d’erreur est retourné. Une nouvelle configuration est alors recherchée par le module 42, par exemple en réduisant le nombre d’application à exécuter (un message est par exemple rendu sur un écran du véhicule 10 pour demander à l’utilisateur de choisir un nombre réduit d’applications à mettre en œuvre). Une nouvelle configuration déterminée par la brique 433 prend par exemple la forme d’une matrice avec une colonne pour chaque application de l’ensemble d’application et une ligne pour chaque mode d’exécution disponible, la matrice comprenant les niveaux AXIL pour chaque application et chaque mode d’exécution, les modes d’exécutions sélectionnés étant identifiées dans la matrice (par exemple par un couple d’identifiants Numéro de colonne / Numéro de ligne). Dans une cinquième opération du processus, l’exécution de l’ensemble d’applications est contrôlée en fonction des modes d’exécution sélectionnés, tel que décrit ci-dessus en regard de la FIG. 4 . Chaque application de l’ensemble d’application reçoit une requête d’exécution selon le mode d’exécution sélectionné pour cette application (selon le mode d’exécution nominal, selon un mode dégradé ou augmenté ou encore selon le mode d’exécution désactivée). Pour illustrer le processus ci-dessous, il est considéré un exemple selon lequel le véhicule embarque les 4 applications suivantes : - une application de diffusion en continu de contenu vidéo (notée N) avec 5 modes d’exécution : mode 1080p, mode 720p, mode 360p, mode 144p, mode ‘interruption pour 5 secondes’ et mode arrêt ; - une application de diffusion en continu de contenu audio (notée M) avec 4 modes d’exécution : mode ‘haute qualité’, mode ‘basse qualité’, mode ‘interruption pour 5 secondes’ et mode arrêt ; - une application d’aide à la conduite, par exemple pour optimisation du trafic avec communication de données en V2X (notée V) avec 2 modes d’exécution : mode actif (application activée en mode nominal) et mode arrêt (application stoppée) ; et - une application de jeu (notée G) avec 3 modes d’exécution : mode actif, mode pause (ou interruption) et mode arrêt. Chaque mode d’exécution possède ses besoins en ressources de calcul (CPU, mémoire, périphériques) et ressources réseau (flux, utilisation de la bande passante, niveau de priorité). Lors du démarrage du véhicule 10, l’utilisateur requiert l’exécution de l’application M et un passager requiert l’exécution de l’application G. L’état courant ‘S’ du véhicule 10 défini par les applications à exécuter est ainsi S={M, G}. L’infrastructure requiert alors à la brique 433 de déterminer les modes d’exécutions optimaux pour S selon les contraintes courantes de l’infrastructure E/E. La brique 433 détermine par exemple que l’application M peut être exécutée selon le mode nominal (mode 1080p) et que l’application G peut également être exécutée selon mode nominal (mode actif). Lors du parcours du véhicule 10, une intersection est atteinte et le véhicule 10 détecte que l’intersection bénéficie d’un équipement de régulation du trafic utilisant un service V2X. Une requête d’exécution de l’application V est alors générée par le véhicule 10 (par exemple par le module 42) et la brique 433 reçoit une requête pour déterminer quels modes d’exécution pour l’état S = {M, G, V} sont possibles, selon les contraintes courantes et les niveaux AXIL déterminés pour chaque mode d’exécution. Cela aboutit par exemple à une exécution des applications M et V dans leur mode optimal et à une exécution de l’application G dans le mode dégradé dit de pause le temps que le véhicule 10 passe l’intersection et que l’application V ne soit plus nécessaire. La FIG. 5 illustre schématiquement un dispositif 5 configuré pour contrôler un ensemble d’applications embarquées dans un véhicule, par exemple le véhicule 10, selon un exemple de réalisation particulier et non limitatif de la présente invention. Le dispositif 5 correspond par exemple à un dispositif embarqué dans le véhicule 10, par exemple un calculateur. Le dispositif 5 est par exemple configuré pour la mise en œuvre des opérations décrites en regard des figures 1 à 4 et 7 et/ou des étapes du procédé décrit en regard de la FIG. 6 . Des exemples d’un tel dispositif 5 comprennent, sans y être limités, un équipement électronique embarqué tel qu’un ordinateur de bord d’un véhicule, un calculateur électronique tel qu’une UCE (« Unité de Commande Electronique »), une unité TCU (de l’anglais « Telematic Control Unit » ou en français « Unité de Contrôle Télématique ») ou tout dispositif de traitement de données d’un système embarqué de véhicule. Les éléments du dispositif 5, individuellement ou en combinaison, peuvent être intégrés dans un unique circuit intégré, dans plusieurs circuits intégrés, et/ou dans des composants discrets. Le dispositif 5 peut être réalisé sous la forme de circuits électroniques ou de modules logiciels (ou informatiques) ou encore d’une combinaison de circuits électroniques et de modules logiciels. Le dispositif 5 comprend un (ou plusieurs) processeur(s) 50 configurés pour exécuter des instructions pour la réalisation des étapes du procédé et/ou pour l’exécution des instructions du ou des logiciels embarqués dans le dispositif 5. Le processeur 50 peut inclure de la mémoire intégrée, une interface d’entrée/sortie, et différents circuits connus de l’homme du métier. Le dispositif 5 comprend en outre au moins une mémoire 51 correspondant par exemple à une mémoire volatile et/ou non volatile et/ou comprend un dispositif de stockage mémoire qui peut comprendre de la mémoire volatile et/ou non volatile, telle que EEPROM, ROM, PROM, RAM, DRAM, SRAM, flash, disque magnétique ou optique. Le code informatique du ou des logiciels embarqués comprenant les instructions à charger et exécuter par le processeur est par exemple stocké sur la mémoire 51. Selon différents exemples de réalisation particuliers et non limitatifs, le dispositif 5 est couplé en communication avec d’autres dispositifs ou systèmes similaires et/ou avec des dispositifs de communication, par exemple une TCU (de l’anglais « Telematic Control Unit » ou en français « Unité de Contrôle Télématique »), par exemple par l’intermédiaire d’un bus de communication ou au travers de ports d’entrée / sortie dédiés. Selon un exemple de réalisation particulier et non limitatif, le dispositif 5 comprend un bloc 52 d’éléments d’interface pour communiquer avec des dispositifs externes. Les éléments d’interface du bloc 52 comprennent une ou plusieurs des interfaces suivantes : - interface radiofréquence RF, par exemple de type Wi-Fi® (selon IEEE 802.11), par exemple dans les bandes de fréquence à 2,4 ou 5 GHz, ou de type Bluetooth® (selon IEEE 802.15.1), dans la bande de fréquence à 2,4 GHz, ou de type Sigfox utilisant une technologie radio UBN (de l’anglais Ultra Narrow Band, en français bande ultra étroite), ou LoRa dans la bande de fréquence 868 MHz, LTE (de l’anglais « Long-Term Evolution » ou en français « Evolution à long terme »), LTE-Advanced (ou en français LTE-avancé) ; - interface USB (de l’anglais « Universal Serial Bus » ou « Bus Universel en Série » en français) ; - interface HDMI (de l’anglais « High Definition Multimedia Interface », ou « Interface Multimedia Haute Definition » en français) ; - interface LIN (de l’anglais « Local Interconnect Network », ou en français « Réseau interconnecté local »). Selon un autre exemple de réalisation particulier et non limitatif, le dispositif 5 comprend une interface de communication 53 qui permet d’établir une communication avec d’autres dispositifs (tels que d’autres calculateurs du système embarqué) via un canal de communication 530. L’interface de communication 53 correspond par exemple à un transmetteur configuré pour transmettre et recevoir des informations et/ou des données via le canal de communication 530. L’interface de communication 53 correspond par exemple à un réseau filaire de type CAN (de l’anglais « Controller Area Network » ou en français « Réseau de contrôleurs »), CAN FD (de l’anglais « Controller Area Network Flexible Data-Rate » ou en français « Réseau de contrôleurs à débit de données flexible »), FlexRay (standardisé par la norme ISO 17458) ou Ethernet (standardisé par la norme ISO/IEC 802-3). Selon un exemple de réalisation particulier et non limitatif, le dispositif 5 peut fournir des signaux de sortie à un ou plusieurs dispositifs externes, tels qu’un écran d’affichage, tactile ou non, un ou des haut-parleurs et/ou d’autres périphériques via des interfaces de sortie respectives. La FIG. 6 illustre un organigramme des différentes étapes d’un procédé de contrôle d’un ensemble d’applications embarquées dans un véhicule, par exemple le véhicule 10, selon un exemple de réalisation particulier et non limitatif de la présente invention. Le procédé est par exemple mis en œuvre par un dispositif embarqué dans le véhicule 10 ou par le dispositif 5 de la FIG. 5 . Une pluralité de modes d’exécution est associée à chaque application 431 de l’ensemble d’applications, des premières données représentatives de besoins en ressources étant associées à chaque mode d’exécution de la pluralité de modes d’exécution et des deuxièmes données représentatives d’au moins une note locale 75 attribuée à une expérience utilisateur étant associées à chaque mode d’exécution de la pluralité de modes d’exécution. Le procédé comprend les étapes suivantes. Dans une première étape 61, une requête de configuration de l’ensemble d’applications est reçue, la requête comprenant des troisièmes données représentatives de ressources courantes disponibles associées au véhicule. Dans une deuxième étape 62, des quatrièmes données sont déterminées à partir des deuxièmes données et de données représentatives d’un ensemble d’au moins un poids 74. Les quatrièmes données sont représentatives d’au moins une note globale 76 associée à chaque mode d’exécution dans la pluralité de modes d’exécution. Dans une troisième étape 63, il est déterminé pour chaque application de l’ensemble d’applications : ● un ensemble de modes d’exécution dans ladite pluralité de modes d’exécution en fonction des premières et troisièmes données, l’ensemble de modes d’exécution comprenant au moins un mode d’exécution, et ● une information représentative de niveau d’acceptation utilisateur associé à chaque mode d’exécution de l’ensemble de modes d’exécution, dit niveau AXIL 331, en fonction des quatrièmes données. Dans une quatrième étape 64, pour chaque application de l’ensemble d’applications, un mode d’exécution est sélectionné dans l’ensemble de modes d’exécution en fonction des niveaux AXIL 331. Dans une cinquième étape 65, l’exécution de l’ensemble d’applications est contrôlée en fonction des modes d’exécution sélectionnés. Selon une variante, les variantes et exemples des opérations décrits en relation avec les figures 1 à 4 et 7 s’appliquent aux étapes du procédé de la FIG. 6 . Bien entendu, la présente invention ne se limite pas aux exemples de réalisation décrits ci-avant mais s’étend à un procédé d’optimisation de l’expérience utilisateur vis-à-vis de la mise en œuvre d’applications dans un véhicule qui inclurait des étapes secondaires sans pour cela sortir de la portée de la présente invention. Il en serait de même d’un dispositif configuré pour la mise en œuvre d’un tel procédé. La présente invention concerne également un véhicule, par exemple automobile ou plus généralement un véhicule autonome à moteur terrestre, comprenant le dispositif 5 de la FIG. 5 . La présente invention concerne également un système comprenant un véhicule comprenant le dispositif 5 de la FIG. 5 ainsi qu’un serveur distant. Procédé de contrôle d’un ensemble d’applications embarquées dans un véhicule (10), une pluralité de modes d’exécution étant associée à chaque application (431) dudit ensemble d’applications, des premières données représentatives de besoins en ressources étant associées à chaque mode d’exécution de ladite pluralité de modes d’exécution et des deuxièmes données représentatives d’au moins une note locale (75) attribuée à une expérience utilisateur étant associées à chaque mode d’exécution de ladite pluralité de modes d’exécution, ledit procédé étant mis en œuvre par au moins un processeur et comprenant les étapes suivantes : - réception (61) d’une requête de configuration dudit ensemble d’applications, ladite requête comprenant des troisièmes données représentatives de ressources courantes disponibles associées audit véhicule (10) ; - détermination (62) de quatrièmes données représentatives d’au moins une note globale (76) associée à chaque mode d’exécution dans ladite pluralité de modes d’exécution à partir des deuxièmes données et de données représentatives d’un ensemble d’au moins un poids (74) ; - détermination (63), pour chaque application dudit ensemble d’applications, de : ● un ensemble de modes d’exécution dans ladite pluralité de modes d’exécution en fonction desdites premières et troisièmes données, ledit ensemble de modes d’exécution comprenant au moins un mode d’exécution, et ● une information représentative de niveau d’acceptation utilisateur associé à chaque mode d’exécution dudit ensemble de modes d’exécution, dit niveau AXIL (331), en fonction des quatrièmes données ; - sélection (64), pour chaque application dudit ensemble d’applications, d’un mode d’exécution dans ledit ensemble de modes d’exécution en fonction des niveaux AXIL (331) ; - contrôle (65) d’exécution dudit ensemble d’applications en fonction des modes d’exécution sélectionnés. Procédé selon la revendication 1, pour lequel ledit ensemble d’au moins un poids (74) est déterminé pour chaque mode d’exécution de chaque application (431) par rapport audit ensemble d'applications. Procédé selon la revendication 1 ou 2, pour lequel ledit ensemble d’au moins un poids (74) est associé à un profil utilisateur (73). Procédé selon l’une des revendications 1 à 3, comprenant en outre une étape de réception de données représentatives d’une évaluation utilisateur, ledit ensemble d’au moins un poids (74) étant déterminé par un modèle de prédiction de poids à partir desdites données représentatives d’une évaluation utilisateur. Procédé selon l’une des revendications 1 à 4, pour lequel ladite au moins une note locale (75) et ladite au moins une note globale (76) comprennent chacune un ensemble de critères d’évaluation comprenant : - un premier critère représentatif d’un niveau de facilité à assurer une fonction sans assistance de ladite chaque application (431) ; - un deuxième critère représentatif d’un taux d’utilisation de ladite chaque application (431) ; et - un troisième critère représentatif d’un niveau de qualité de service perçue pour ledit chaque mode d’exécution de ladite chaque application (431). Procédé selon l’une des revendications 1 à 5, pour lequel l’étape de détermination (62) de quatrièmes données est mise en œuvre par un serveur distant, lesdites quatrièmes données étant émises par ledit serveur distant à destination d’un calculateur embarqué dans le véhicule (10). Programme d’ordinateur comportant des instructions pour la mise en œuvre du procédé selon l’une quelconque des revendications 1 à 6, lorsque ces instructions sont exécutées par un processeur. Dispositif (5) de contrôle d’un ensemble d’applications embarquées dans un véhicule, ledit dispositif (5) comprenant une mémoire (51) associée à au moins un processeur (50) configuré pour la mise en œuvre des étapes du procédé selon l’une quelconque des revendications 1 à 5. Véhicule (10) comprenant le dispositif (5) selon la revendication 8. Système comprenant le véhicule (10) selon la revendication 9 et un serveur distant, le système étant configuré pour la mise en œuvre des étapes du procédé selon l’une quelconque des revendications 1 à 6