Brevet FR2926375A1 — publié le 20090717

La présente invention se rapporte aux plateformes informatiques destinées aux fonctions de pilotage et de maintenance de véhicules, et intégrées dans ceux-ci. Plus particulièrement, l'invention concerne un procédé et un système pour l'exécution d'application sur de telles plateformes. Dans divers domaines tels que l'aéronautique ou l'automobile, un grand nombre d'applications d'aide au pilotage et/ou à la maintenance est proposé à l'équipage par le biais d'un système informatique embarqué mis en place par le constructeur du véhicule. Ce système délimite un environnement sur lequel le constructeur a la main mise. On le nomme par la suite "domaine constructeur", et notamment "domaine avionneur" dans le cadre spécifique de l'aviation. Ce système ou plateforme informatique interagit généralement avec des composants du véhicule au travers de serveurs et avec le pilote ou l'opérateur de maintenance au travers d'écrans et de périphériques de saisie. Certaines fonctions sensibles du véhicule sont ainsi accessibles depuis cette plateforme, par exemple le régulateur de vitesse ou le freinage antiblocage ABS pour l'automobile, le pilotage automatique et différents instruments électroniques de bord reliés au GPS pour l'aéronautique. On connaît un tel système d'information destiné aux pilotes et opérateurs de maintenance aéronautique sous l'appellation de système de serveur réseau (NSS ou "Network Server System" selon la terminologie anglo-saxonne) conformément à la norme Arinc 763. On trouve mention de telles plateformes aéronautiques dans, par exemple, les publications FR 2 895 793, FR 2 892 092, FR 2 831 871 ou EP 1 160 160. Force est de constater que des niveaux élevés de sécurité sont requis pour l'intégration et/ou la modification de ces plateformes à destination de l'équipage. Cette sécurité requise oppose cette plateforme dédiée au pilotage et/ou à la maintenance à toute autre plateforme informatique à destination des passagers, notamment une plateforme IFE de divertissement à bord ("In-Flight Entertainment" selon la terminologie anglo-saxonne). De telles plateformes IFE sont mentionnées dans des publications telles que WO 2007/093327 ou EP 1 367 683. En pratique, le constructeur garantit la sécurité du domaine constructeur en réalisant lui-même la validation et l'intégration de nouveaux équipements et/ou d'applications informatiques dans la plateforme dédiée à l'équipage. Il existe donc une difficulté pour tout détenteur du véhicule souhaitant ajouter librement de nouvelles applications et fonctions à cette plateforme. On définit ainsi un "domaine utilisateur" délimité par l'environnement dans lequel le détenteur du véhicule peut librement intervenir par l'ajout, la modification d'applications. On distingue donc les "domaine utilisateur" et "domaine constructeur" par le besoin de sécurité que ce dernier exige, par exemple par la mise en place de procédures de certification parfois coûteuses. Dans le domaine automobile, un tel détenteur peut être une compagnie de location, une société propriétaire d'une flotte de véhicules ou même un particulier. Dans le domaine aéronautique, autour duquel la suite de la description est recentrée sans pour autant exclure de l'invention d'autres domaines industriels présentant les mêmes problématiques, ce détenteur peut notamment être une compagnie aérienne qui affrète des aéronefs pour le transport de passagers. On parlera alors de "domaine compagnie" (ou "domaine airliner"). Il existe également un autre pré-requis pour un certain nombre d'applications à destination des pilotes et/ou opérateurs de maintenance, qui relève de la possibilité pour ceux-ci de pouvoir disposer de ces applications hors de l'aéronef, afin par exemple de préparer un vol (calculs de performances), une procédure d'intervention ou d'effectuer un rapport post-vol à partir de données enregistrées lors du vol. Il ressort de la pratique actuelle que les solutions connues s'appuient sur l'utilisation d'ordinateurs personnels portables ("Persona/ Computer" ou "PC" selon la terminologie anglo-saxonne) qui peuvent être reliés au réseau NSS de l'aéronef pendant le vol, par l'intermédiaire de stations d'accueil. Ces ordinateurs personnels remplacent avantageusement le lourd cartable du pilote historiquement utilisé et permettent au pilote d'être itinérant, en transportant ses données de missions et préparant ses calculs de performances avant le vol depuis son hôtel ou la salle de pré-embarquement. Parmi les applications largement utilisées de façon itinérante, on distingue les outils de calcul de performances, les manuels opérationnels comprenant par exemple les listes de vérification ("check lists" selon la terminologie anglo-saxonne), les manuels de maintenance. Ces ordinateurs personnels sont connus sous l'appellation de sac de vol électronique (EFB pour "Electronic Flight Bag"), normalisée dans la norme TGL36 (Temporary Guidance Leaflet) de la Joint Aviation Authority JAA et reprise dans le document Advisory Circular AC N°120-76A de la Federal Aviation Administration FAA. On distingue trois catégories de sacs EFB. Un EFB de classe I est composé d'un PC portable disponible sur étagère utilisable de manière autonome éventuellement alimenté par une prise de courant dans l'aéronef. L'affichage et le moyen de contrôle, par exemple clavier et souris, sont autonomes. Une grande indépendance entre le PC (domaine airliner) et le système embarqué NSS (domaine avionneur) est proposée permettant à la compagnie aérienne d'installer librement tout logiciel souhaité sur cet EFB classe I. Néanmoins, un tel EFB classe I n'est pas utilisable lors de certaines phases de vol, comme par exemple le décollage et l'atterrissage. En outre, aucun accès aux paramètres avioniques n'est possible par l'absence d'interfaçage avec la plateforme NSS. Un EFB de classe II s'apparente à celui de la classe I, pour lequel une possibilité d'affichage et de contrôles déportés sur des moyens cockpit est proposée afin de pouvoir être utilisé lors de toutes les phases de vol. Par exemple, on peut utiliser un écran intégré au cockpit, un clavier et un TrackBall cockpit, le PC étant connecté à ces interfaces déportées par l'intermédiaire d'une station d'accueil. Le PC portable n'est ainsi pas attaché à l'avion ce qui permet au pilote d'en disposer hors de l'aéronef. Cette classe II d'EFB permet l'accès aux paramètres avioniques en lecture seule. Une grande indépendance entre l'EFB et la plateforme NSS est conservée permettant à la compagnie aérienne d'installer toujours librement les logiciels qu'elle désire. Ces EFB de classe I et II sont généralement choisis par les compagnies aériennes. Ils peuvent être changés fréquemment voire être distincts entre deux pilotes opérants consécutivement sur l'aéronef. Ils présentent alors l'inconvénient majeur de nécessiter une intégration et une installation complexes dans le cockpit de l'aéronef, par exemple parce qu'il est difficile d'avoir un connecteur ou une station d'accueil suffisamment générique pour accueillir tous les ordinateurs portables disponibles sur le marché. En outre, l'avionneur n'a aucun contrôle sur ces ordinateurs du domaine airliner. De fait, ces ordinateurs peuvent ne pas répondre à toutes les normes de sécurité s'appliquant aux constructeurs, engendrant des risques de sécurité liés à l'exécution de ces ordinateurs. L'EFB de classe III est un équipement qui est attaché définitivement à l'avion, par exemple l'OIT ("Onboard Information Terminaf' selon la terminologie anglo-saxonne, correspondant à un dispositif de visualisation et d'interaction pour la consultation d'une version électronique de documents de vol tels que des manuels de maintenance) dans l'Airbus A340 (nom commercial) ou qui forme un part number (numéro d'identification dans le système NSS), du constructeur, par exemple l'EFB dans l'Airbus A380 (nom commercial). Ce type III d'EFB classe permet également l'accès aux paramètres avioniques en lecture seule du fait de son intégration au système. Néanmoins, dans le cas de l'EFB classe III, la compagnie aérienne ne peut pas déployer librement de logiciel sur cet EFB sans passer par le constructeur en tant qu'intégrateur. L'invention vise ainsi à résoudre les inconvénients de l'état de la technique. A cet effet, l'invention vise notamment un procédé d'exécution d'une application informatique d'interfaçage avec un équipage d'un véhicule, le procédé comprenant : - la lecture d'un média amovible, comprenant ladite application à 5 exécuter, au moyen d'un lecteur de média amovible équipant un système d'exécution embarqué dans le véhicule, - l'exécution de ladite application par des moyens d'exécution équipant ledit système d'exécution et reliés audit lecteur de média amovible, ladite exécution de l'application ne requerrant l'enregistrement 10 permanent de données nécessaires à son exécution que sur ledit média amovible. On entend ici par "permanent" le stockage ou l'enregistrement de données au-delà de l'exécution de l'application, c'est-à-dire des données qui perdurent dans les mémoires alors que l'application n'est plus en exécution. On 15 oppose ce stockage "permanent" au stockage "temporaire" qui concerne généralement la mémorisation des données dans une mémoire vive, type RAM, pour permettre à un microprocesseur de mener efficacement l'exécution de l'application. L'invention vise également un procédé d'exécution d'une application 20 informatique d'interfaçage avec un équipage d'un véhicule, ladite application mettant en oeuvre des données associées nécessaires à son exécution, le procédé comprenant : - la lecture d'un média amovible, comprenant ladite application à exécuter, au moyen d'un lecteur de média amovible équipant un système 25 d'exécution embarqué dans le véhicule, -l'exécution de ladite application par des moyens d'exécution équipant ledit système d'exécution et reliés audit lecteur de média amovible, ladite exécution de l'application étant réalisée sans le stockage permanent, dans ledit système d'exécution, desdites données associées. 30 Ce stockage permanent vise notamment les mémoires non volatiles telles les registres d'un système d'exploitation, toute mémoire réinscriptible (EEPROM, Flash, ...) ou les disques durs. On distingue les données nécessaires à l'exécution de l'application, par exemple la modification de registres pour que le système d'exploitation puisse procéder à cette exécution, des données utilisées lors de l'exécution, par exemple un fichier de l'utilisateur qui n'a aucun caractère essentiel pour ladite exécution. Selon l'invention, il résulte qu'aucune donnée d'application n'est enregistrée à long terme dans le système d'exécution embarqué. On comprend ainsi qu'au regard des données associées à une application et nécessaires pour son exécution, aucune de ces données n'est stockée de façon permanente autre part que sur le média amovible, afin de ne pas polluer le système d'exécution. A titre illustratif et tel que développé ci-après, on envisage les applications portables qui délimitent l'inscription de données nécessaires à son exécution au seul dossier qui les comportent, c'est-à-dire sur le média amovible lorsque ces applications sont prévues sur ce média. Un autre exemple envisagé est la présence d'un système d'exploitation installé sur le média amovible et sur lequel le système d'exécution boote; l'application alors exécutée dans ce système d'exploitation n'implique l'inscription de données nécessaires à son exécution que dans les registres ou autre mémoire non volatile qui sont délimités par l'installation du système d'exploitation, c'est-à-dire le média amovible. On conserve cependant la possibilité de manipuler plus librement des données de contenu telles que des données de mission qui peuvent être stockées sur le média amovible et des données attachées à l'avion (historique des pannes et réparation, par exemple) qui sont alors sauvegardées dans une mémoire embarquée de l'avion. Il faut entendre ici l'équipage par opposition aux passagers, c'est-à-dire au personnel ayant l'autorisation d'intervenir et d'interagir avec les paramètres fonctionnels du véhicule. L'équipage regroupe ainsi, notamment, le ou les pilotes, le personnel de bord et les opérateurs de maintenance. Selon l'invention, la compagnie se libère de l'ordinateur personnel portable par l'utilisation d'un média amovible qui comprend l'ensemble des applications utiles pour le personnel considéré. On évite ainsi tout problème lié à l'intégration et l'installation des ordinateurs portables eu égard à la pluralité d'interfaces existantes. Les médias amovibles suivent, en effet, des normes de connexion plus génériques. En outre, l'utilisation de médias amovibles constitue un gain économique comparé à celle d'ordinateurs portables équipant chacun des intervenants concernés. En effet, les médias amovibles sont traditionnellement vus comme des dispositifs passifs (sans alimentation autonome) et dépourvus de moyens d'exécution propres. En pratique, on a généralement recours à des moyens de stockage. Un tel média amovible est aisément utilisable par le pilote depuis son hôtel, à l'aide d'un ordinateur personnel portable comprenant un lecteur de média ad hoc. L'interconnexion du média amovible avec le système d'exécution embarqué (via le lecteur de média) permet également son utilisation en toute phase de vol, par exemple via des interfaces de visualisation et de saisie prévues dans le cockpit. Le système d'exécution peut prendre la forme d'un système informatique intégré dans le véhicule ou par exemple un équipement de type EFB classe III attaché à l'avion. Le déchargement de l'application depuis le média amovible se fait également sans problème ultérieur pour le système embarqué, grâce à la mise en place de mécanismes évitant que l'application, lors de son exécution, laisse des empreintes ou traces sur la plateforme informatique embarquée. Ainsi, on assure une forte indépendance entre l'EFB personnel et la plateforme, de sorte que la compagnie aérienne peut librement déployer, via les médias amovibles, les applications qu'elle souhaite sans affecter la sécurité du système embarqué. Dans ce contexte, les données associées à l'application pour son exécution peuvent par exemple être un pilote, une bibliothèque, un code source, un fichier exécutable, un fichier de configuration, un fichier de registre informatique. Ces dernières sont enregistrées dans le média amovible et ne sont donc pas déployées pour stockage vers le système d'exécution. Cette indépendance permet que la plateforme informatique ne soit pas configurée pour un environnement de média spécifique. Elle peut ainsi accueillir, via différents médias amovibles personnalisés, des environnements d'exécution différents, par exemple un environnement de vol attribué à un pilote et un environnement de tests et simulations attribué à un opérateur de maintenance. En outre, le système embarqué reste sûr car non pollué par des données spécifiques à une application non résidente. En pratique et comme décrit plus loin, le cockpit ou une baie avionique dédiée peut présenter une carte d'unité centrale de traitement (CPU) connectée à un écran dédié au système d'information, des moyens de saisie (clavier et/ou souris) ou désignateur dédié(s) au système d'information et le lecteur de média accessible dans le cockpit pour que le pilote ou l'opérateur puisse y connecter le média contenant l'application souhaitée. Dans la salle de pré-embarquement, par exemple, le pilote peut connecter son média amovible dans un lecteur ad hoc pourvu sur une borne PC ou sur un ordinateur personnel portable, et ainsi accéder aux applications souhaitées et à des données de mission depuis l'extérieur de l'aéronef. Dans un mode de réalisation de l'invention, ladite application est une application portable. Au sens connu, une "application portable" est un logiciel fonctionnant de manière autonome dans le dossier informatique stockant les données qui lui sont propres, sans installation préalable sur le disque dur de l'ordinateur hôte. Il est ainsi possible d'utiliser librement cette application et les données personnelles associées sans laisser de trace sur cet ordinateur hôte. On évite ainsi soit des dysfonctionnements soit des développements supplémentaires liés au besoin de cohabitation efficace de plusieurs applications laissant chacune des traces ou empreintes pouvant interférer sur l'ordinateur. De par la nature même des applications portables, aucune intégration de celles-ci dans le système d'exécution n'est nécessaire pour l'avionneur. Ce dernier évite un surplus de développement tandis que la compagnie peut, à loisir, ajouter, modifier librement ces applications. Ces traces ou empreintes sont, par exemple, dans les systèmes connus de l'état de la technique, des entrées en base de registre, des modifications de variables d'environnement, des installations ou mises à jour de librairies partagées, des créations de fichiers temporaires, des copies de binaires applicatifs et de fichiers de configuration sur le disque dur de la plateforme hôte. En particulier, le système d'exécution comprend un lanceur d'applications agencé pour détecter des applications portables contenues dans un média connecté audit lecteur, et ladite application portable est lancée à partir du lanceur d'applications. A l'aide des mécanismes prêt à tourner ("plug and play" selon la terminologie anglo-saxonne), on obtient ainsi un accès rapide et automatique, pour le pilote ou l'opérateur, à l'application contenue dans le média amovible, dès connexion de ce dernier dans le lecteur. Le lanceur d'applications peut, par exemple, détecter des fichiers U3, Framakey (normes pour le développement d'applications portables) ou tout format équivalent, et afficher les applications correspondantes pour sélection par l'utilisateur. Dans un mode de réalisation, ledit média amovible comprend un système d'exploitation, le procédé comprenant, préalablement à ladite exécution de l'application, une étape d'amorçage ("boot" selon la terminologie anglo-saxonne) dudit système d'exécution sur ledit système d'exploitation, ladite application étant exécutée dans l'environnement dudit système d'exploitation du média amovible. Les mécanismes de boot déporté sur le média amovible inséré dans le lecteur permettent d'éviter toute pollution de la plateforme hôte par le système d'exploitation ("Operating System" ou OS selon la terminologie anglo-saxonne) lancé et les applications exécutées dans ce système d'exploitation Grâce aux dispositions de ce mode de réalisation, le système d'exploitation utilisé par le pilote ou l'opérateur n'est pas lié au véhicule lui-même mais au média amovible. Cette solution permet de s'affranchir de certaines dispositions légales relatives à l'utilisation de système d'exploitation. Par exemple, il existe des licences applicables à des systèmes d'exploitation qui dépendent du territoire concerné pour l'exécution de ceux-ci. Il arrive ainsi que de tels systèmes d'exploitation ne sont pas introduits directement par le constructeur du véhicule, entraînant une impossibilité pour les acquéreurs d'utiliser des applications développées dans l'environnement de ces systèmes d'exploitation. Aussi, grâce au mode de réalisation ci-dessus, la compagnie aérienne peut choisir elle-même son système d'exploitation. En particulier, ledit système d'exécution comprend un système de base d'entrée/sortie (BIOS) configuré de sorte à amorcer ("booter" selon un anglicisme largement répandu) ledit système d'exécution à partir d'un système d'exploitation stocké sur le média amovible connecté audit lecteur. La configuration directe du BIOS permet d'automatiser la procédure de lancement du système d'exécution et des applications contenues dans le média amovible par un simple redémarrage du système d'exécution de la plateforme embarquée. Dans un mode de réalisation, ledit système d'exécution comprend une machine virtuelle exécutée au démarrage, ledit système d'exploitation étant exécuté dans ladite machine virtuelle. Grâce à ces dispositions, on s'affranchit des contraintes matérielles de la plateforme hôte. Ainsi, on évite l'utilisation de pilotes génériques stockés dans le média amovible qui doivent satisfaire à toutes les configurations matérielles de plateformes hôtes avec lesquelles le média amovible peut être utilisé. Au lieu de cela, on utilise des pilotes spécifiques à la machine virtuelle prévue sur le système d'exécution, notamment on peut prévoir la même machine virtuelle sur tout ou partie des véhicules/aéronefs construits. Avec ces pilotes spécifiques, on accède à plus de fonctionnalités. Il en résulte une amélioration des performances et des services fournis par le système d'exploitation. En particulier, on prévoit également que ledit système d'exécution comprend un système d'exploitation agencé pour être exécuté dans ladite machine virtuelle. Grâce à ces dispositions de virtualisation, on instancie au moins deux ordinateurs virtuels à partir d'un seul système d'exécution (CPU) matériel de sorte à fournir deux environnements distincts, par exemple l'un lié à l'avionneur et l'autre lié à la compagnie aérienne. On s'affranchit ainsi de l'utilisation de deux CPU dont le coût, la consommation et l'encombrement physique et thermique seraient plus importants. Dans un mode de réalisation, lesdits moyens d'exécution forment partie d'un module amovible dudit système d'exécution, en particulier il peut s'agir d'une carte CPU amovible. Selon cette configuration, il est possible d'adapter et de gérer efficacement l'évolution de la puissance des moyens de traitement/exécution tout au long de la vie du véhicule (plusieurs dizaines d'années pour un aéronef). On veillera cependant à assurer que cette carte CPU suivent les normes, par exemple ARINC 763, de compatibilité avec le reste de la plateforme hôte. Selon une caractéristique particulière de l'invention, ledit média amovible est l'un parmi l'ensemble comprenant une clé USB, une mémoire flash, une carte mémoire (SD card, compact flash, ...), un compact disque, un disque DVD. Selon ces exemples, on voit que le média amovible est un dispositif dépourvu de moyens d'exécution, notamment de CPU. Il s'agit en particulier d'un média amovible de stockage. A des fins d'encombrement minimum, le média amovible est également dépourvu d'alimentation électrique autonome, type batterie. L'invention vise également un procédé d'exécution d'une application informatique d'interfaçage avec un équipage d'un véhicule, le procédé comprenant : - la lecture d'un média amovible, comprenant une application portable, au moyen d'un lecteur de média amovible équipant un système d'exécution embarqué dans le véhicule, - l'exécution de ladite application portable par des moyens d'exécution équipant ledit système d'exécution et reliés audit lecteur de média amovible. L'invention vise également un procédé d'exécution d'une application informatique d'interfaçage avec un équipage d'un véhicule, le procédé comprenant : - la lecture d'un média amovible, comprenant un système d'exploitation et ladite application à exécuter, au moyen d'un lecteur de média amovible équipant un système d'exécution embarqué dans le véhicule, - l'amorçage dudit système d'exécution embarqué sur ledit système d'exploitation du média amovible, par des moyens d'exécution équipant ledit système d'exécution et reliés audit lecteur de média amovible, -l'exécution de ladite application dans ledit système d'exploitation. L'invention a également trait à un kit pour l'exécution d'une application informatique d'interfaçage avec un équipage d'un véhicule, le kit comprenant : - un média amovible comprenant ladite application à exécuter, - un système d'exécution embarqué dans le véhicule, comprenant un lecteur de média amovible agencé pour recevoir et lire ledit média amovible et, reliés audit lecteur, des moyens d'exécution agencés pour exécuter ladite application contenue dans ledit média amovible, ledit média amovible étant agencé de sorte que ladite exécution de l'application ne requiert l'enregistrement permanent de données nécessaires à son exécution que sur ledit média amovible. L'invention vise également un kit pour l'exécution d'une application informatique d'interfaçage avec un équipage d'un véhicule, ladite application mettant en oeuvre des données associées nécessaires à son exécution, le kit comprenant : - un média amovible comprenant ladite application à exécuter, - un système d'exécution embarqué dans le véhicule, comprenant un lecteur de média amovible agencé pour recevoir et lire ledit média amovible et, reliés audit lecteur, des moyens d'exécution agencés pour exécuter ladite application contenue dans ledit média amovible, ledit média amovible étant agencé de sorte que ladite exécution de l'application ne requiert pas le stockage permanent, dans ledit système d'exécution, desdites données associées. De façon optionnelle, l'un des kits peut comprendre des moyens se rapportant aux caractéristiques de procédé présentées ci-dessus. Notamment, ladite application peut être une application portable. En particulier, le système d'exécution comprend un lanceur d'application agencé pour détecter les applications contenues dans ledit média lorsque ce dernier est connecté audit lecteur, par exemple par des moyens plug and play. En alternative ou en combinaison à l'application portable, un système d'exploitation peut être prévu dans ledit média amovible et le système d'exécution est agencé pour s'amorcer (booter) sur ledit système d'exploitation, par exemple en paramétrant de façon adaptée le BIOS du système d'exécution. Selon une caractéristique particulière, les moyens d'exécution forment partie d'un module amovible dudit système d'exécution. L'invention vise également un kit pour l'exécution d'une application informatique d'interfaçage avec un équipage d'un véhicule, le kit comprenant : - un média amovible comprenant une application portable, - un système d'exécution embarqué dans le véhicule, comprenant un lecteur de média amovible agencé pour recevoir et lire ledit média amovible et, reliés audit lecteur, des moyens d'exécution agencés pour exécuter ladite application portable dans ledit média amovible. L'invention vise également un kit pour l'exécution d'une application informatique d'interfaçage avec un équipage d'un véhicule, le kit comprenant : - un média amovible comprenant un système d'exploitation et ladite application à exécuter, - un système d'exécution embarqué dans le véhicule, comprenant un lecteur de média amovible agencé pour recevoir et lire ledit média amovible et, reliés audit lecteur, des moyens d'exécution agencés pour amorcer ledit système d'exécution embarqué sur ledit système d'exploitation du média amovible et pour exécuter ladite application dans le système d'exploitation. L'invention vise également un aéronef comprenant un tel kit. Les avantages, buts et caractéristiques particulières de ce kit et de cet aéronef étant similaires à ceux du procédé objet de la présente invention, telle que succinctement exposé ci-dessus, ils ne sont pas rappelés ici. Les caractéristiques et avantages de la présente invention apparaîtront plus clairement à la lecture d'un mode préféré de réalisation illustré par les dessins joints, dans lesquels : - la figure 1 représente un exemple de système embarqué dans un aéronef, pour la mise en oeuvre de l'invention ; - la figure 2 illustre, schématiquement, un premier mode de réalisation de l'invention, par exemple dans le système de la figure 1 ; - la figure 3 représente, sous forme de logigramme, des étapes du premier mode de réalisation du procédé selon l'invention ; - la figure 4 illustre un exemple d'utilisation nomade d'applications en lien avec le premier mode de réalisation de l'invention ; - la figure 5 illustre, schématiquement, un deuxième mode de réalisation de l'invention, par exemple dans le système de la figure 1 ; - la figure 6 représente, sous forme de logigramme, des étapes du deuxième mode de réalisation du procédé selon l'invention ; - la figure 7 illustre, schématiquement, un troisième mode de réalisation de l'invention, par exemple dans le système de la figure 1 ; et - la figure 8 illustre, schématiquement, un quatrième mode de réalisation de l'invention. La présente invention a trait à l'exécution d'une application informatique destinée à un équipage d'un véhicule, ici un aéronef 1, au cours de laquelle on procède à la connexion pour lecture d'un média amovible, comprenant l'application à exécuter, à un lecteur de média amovible équipant un système d'exécution embarqué dans le véhicule 1, ce système d'exécution comprenant des moyens d'exécution. En référence à la figure 1, l'aéronef 1 présente un cockpit 10 à partir duquel les pilotes ou agents de maintenance peuvent accéder à un système embarqué 100 de type NSS ("Network Server System", système de serveur en réseau) présentant des outils et applications d'aide au pilotage et au fonctionnement de l'aéronef 1. Le système NSS 100 comprend un sous- système 110, éventuellement sécurisé, dit domaine constructeur ou domaine avionneur, présentant une unité de traitement CPU 111, une mémoire volatile RAM 112, un disque dur 113, des périphériques 114 et des périphériques de visualisation et saisies accessibles depuis le cockpit, par exemple un écran 115 et un clavier/souris 116. Ces équipements sont reliés par un bus de données 117. Le sous-système 110 peut contenir des applications sensibles pour la sécurité de l'avion 1. Par conséquent, l'avionneur souhaite isoler ce sous-système de tout autre sous-système où des tiers pourraient intervenir sans qualification appropriée. Dans une réalisation également envisagée, ces applications sensibles peuvent être prévues dans un autre sous-système, lui hautement sécurisé, séparé du sous-système 110 par une diode réseau unidirectionnelle. Dans ce cas, le sous-système 110 présente la simple particularité d'être intégré par le constructeur de l'avion. Par soucis de simplicité, on indique uniquement le sous-système 110 dans les deux cas ci-dessus, avec la spécificité que dans le deuxième cas, les certifications de matériels et d'applications portent principalement sur ceux prévus pour le sous- système hautement sécurisé. Le processeur 111 permet l'exécution d'applications stockées dans le disque dur 113. Ces applications sont certifiées puis intégrées dans le sous-système 110 par l'avionneur constructeur. Le système NSS 100 comprend également un deuxième sous-25 système 120, moins sécurisé que le sous-système 110, en ce sens que les conditions de certification et d'intégration sont moins fortes. Ce sous-système 120, ou domaine compagnie ou domaine airliner, comprend également, reliés par un bus de données 127, une unité de traitement CPU 121 pour l'exécution d'applications, une mémoire volatile RAM 30 122, un disque dur 123, des périphériques 124 et des périphériques de visualisation et saisies accessibles depuis le cockpit, par exemple un écran 125 et un clavier/souris 126. En vue d'un gain de place, les écrans et clavier/souris 115, 116, 125 et 126 peuvent être mutualisés en de mêmes dispositifs avec une commande permettant de passer d'un sous-système à l'autre. Les sous-systèmes 110 et 120 sont interconnectés par une passerelle 130, permettant notamment aux applications exécutés sur le processeur 121 de récupérer des paramètres et données avioniques générées par le sous système sécurisé 110. Cette récupération peut être réalisée par des droits en lecture sur des fichiers de données et/ou paramètres stockés, par exemple, dans le disque dur 113 ou émis par un périphérique 114. En particulier, la passerelle 130 contribue à la sûreté du système en assurant la protection du sous-système 110 par la limitation des droits des applications exécutées dans le sous-système 120, notamment les applications d'un média amovible comme introduit ci-après, d'accéder aux données du sous-système 110. Le sous-système 120 présente en outre un lecteur de média amovible 128, ici un lecteur de clé USB ("Un/versa/ Serial Bus" selon la terminologie anglo-saxonne). Le lecteur peut être vu ici comme l'interface qui permet la connexion entre le média amovible et le système afin de permettre la lecture du premier. Généralement, des programmes associés à cette interface (par exemple des pilotes ou équivalents) assurent cette fonction de lecture. Plusieurs lecteurs 128 peuvent être prévus, notamment pour permettre la connexion de médias amovibles présentant des formats d'interfaçage différents, par exemple USB, Firewire (nom déposé), etc. Ce lecteur 128 est accessible depuis le cockpit 10 des pilotes. D'autres lecteurs 128 peuvent être prévus dans le sous-système 120, par exemple extérieurs au cockpit afin que des agents de maintenance puissent se connecter audit sous-système 120. Les équipements de traitement sans interaction avec les pilotes ou autres agents, notamment les CPU 111, 121, les mémoires vives 112, 122, les disques durs 113, 123 et périphériques 114, 124, peuvent être intégrés dans un espace dédié, par exemple dans une baie informatique avionique 11, hors du cockpit 10. Des écrans et moyens de saisie supplémentaires peuvent être prévus hors du cockpit 10 à l'attention, par exemple, du personnel navigant en cabine passager. Egalement, des interfaces pour connecter des écrans et/ou moyens de saisie peuvent être prévus en plus ou en lieu et place desdits écrans 115 et moyens de saisie 116, éventuellement hors du cockpit, pour permettre à des agents de maintenance d'intervenir dans le système NSS 100 depuis l'extérieur du cockpit 10. En référence à la figure 2, on illustre un premier mode de réalisation de l'invention à l'aide d'une représentation simplifiée du sous-système 120 auquel est connecté une clé USB 200 d'un pilote. La clé USB 200 du pilote constitue une mémoire comprenant une ou plusieurs applications 210, 210', etc. qui ont été développées par la compagnie aérienne du pilote pour lui proposer des outils d'aide, par exemple de planification de vol ou de procédure, telle que les listes de vérification (checklists). Ces applications sont des applications d'interfaçage avec l'équipage de l'avion (le pilote, entre autres). Les applications 210, 210' sont développées dans un format d'application portable, par exemple U3 (norme Sandisk, nom déposé) ou Framakey (format logiciel libre). Ces applications portables ont la particularité d'être prêtes à l'emploi sur la clé USB 200, c'est-à-dire que leur utilisation se fait de manière sécurisée et sans laisser d'informations personnelles sur les machines hôtes, notamment sur les disques durs, sur lesquelles elles sont exécutées, ici sur le système 100. On note que ces applications ne modifient pas, pour leur exécution, le système d'exploitation dans lequel elles sont exécutées et qu'en outre, elles sont suffisantes en terme de librairies, c'est-à-dire qu'elles se suffisent des librairies intrinsèques du système d'exploitation, sans requérir l'installation de nouvelles librairies, ce qui constituerait une trace laissée sur la machine hôte. Le déploiement de ces applications nécessite uniquement la copie du dossier contenant les données associées à l'application, c'est-à-dire le fichier de l'application à proprement parler (au format U3 ou Framakey par exemple), ses librairies, ses fichiers de configuration et ses éventuelles données. Ainsi l'exécution de celles-ci est réalisée directement depuis ce dossier, donc en l'espèce depuis le média amovible dans lequel se situe le dossier. La clé USB 200 peut ainsi être connectée au lecteur USB 128 pour permettre l'exécution de l'application 210 par le CPU 121. La clé USB 200 est ainsi accessible en lecture et éventuellement en écriture pour stocker des données dans sa mémoire. Le disque dur 123 du sous-système 120 comprend un système d'exploitation OS (Operating System, par exemple Windows [nom déposé]) 123-1 qui est lancé au démarrage du sous-système 120, des applications 123-2 déjà intégrées par l'avionneur (et donc certifiées) et un lanceur d'applications 123-3. Ce lanceur d'applications 123-3 est lancé par les mécanismes de prêt à tourner (plug and play) lors de l'insertion de la clé USB 200 dans le lecteur 128. Le lanceur d'applications 123-3 est configuré pour détecter, dans la clé USB connectée, les applications établies selon une norme d'application portable, notamment U3 et Framakey. L'application présente alors à l'écran 125 du pilote ou autre personnel la liste des applications portables détectées pour sélection par ledit pilote ou autre personnel en vue de l'exécution de l'application sélectionnée. En détail, comme illustré par la figure 3, lorsque le pilote prend possession de l'avion 1 pour effectuer un vol, il met, à l'étape 300 sous alimentation le système embarqué 100 et de ses composants. A l'étape 302, le sous-système 120 démarre par l'exécution du système d'exploitation 123-1. A ce stade, le pilote peut utiliser de façon conventionnelle les applications 123-2 déjà intégrées par l'avionneur (étape 304). A l'étape 306, le pilote insert, dans le lecteur USB 128, la clé USB 200 contenant toutes ses données de mission, notamment les listes de vérification et la planification de vol. Ces données ont été préparées au préalable par le pilote, par exemple à son hôtel comme expliqué plus loin. Ces données sont accessibles au travers d'une application portable 210 développée par la compagnie aérienne pour tous ses pilotes. A l'étape 308, le sous-système 120 détecte, par les mécanismes plug and play, l'insertion de la clé 200 dans le lecteur 128 et démarre l'application lanceur 123-3. Cette dernière 123-3 scanne alors la mémoire de la clé USB pour déterminer la présence de fichiers d'application répondant à une norme d'application portable, par exemple les fichiers présentant une extension u3p pour la norme U3. Il peut être prévu de limiter le scannage de la clé USB dans le dossier racine ou dans un dossier spécifique afin de limiter le temps de détection pour des médias de grande capacité. En fin d'étape 308, l'application lanceur 123-3 a dressé l'ensemble des applications portables présentes dans la clé 200. A l'étape 310, l'application lanceur 123-3 affiche à l'écran 125 du pilote la liste des applications portables 210 détectées. A l'étape 312, le pilote sélectionne, avec la souris 126, l'application souhaitée 210 et demande son exécution, par exemple par un simple clic. L'application 210 est alors exécutée par le processeur 121 en utilisant la mémoire vive 122. Cependant aucune copie de fichiers ou configuration n'est effectuée sur le disque dur 123. Le pilote dispose ainsi des données pour son vol. Il peut également saisir des informations qui sont alors directement enregistrées dans la mémoire de la clé 200, pour une utilisation après vol par exemple. A titre d'exemple, l'application 210 exécutée peut invoquer des services du système d'exploitation 123-1 pour imprimer, par exemple, sur un périphérique 124 du sous-système 120. En pratique, l'application portable 210 voit apparaître une boite de dialogue commune de gestion des impressions déjà configurée avec les imprimantes connectées et configurée avec l'imprimante par défaut sélectionnée. Le système d'exploitation étant de préférence multi-tâches, le pilote peut accéder à plusieurs applications 123-2 et 123-3 en même temps. A la fin de l'utilisation de l'application 210, le pilote ferme l'application 210 à l'étape 314. De par la nature des applications portables 210, 210', aucune donnée associée à l'application exécutée ne demeure sur le disque dur du sous-système 120. Ainsi, grâce à l'invention, la compagnie aérienne peut développer ses propres applications et les utiliser dans les avions sans certification et intégration préalables par l'avionneur. On note qu'il est également envisageable qu'un pilote connecte sa clé USB 200 munie d'une application portable à un lecteur USB (non représenté) du sous-système sécurisé 110. Du coup, on peut envisager un unique sous-système 110 sans sortir du contexte de l'invention. On note également que l'invention s'applique en l'absence d'application lanceur 123-3, auquel cas le pilote doit accéder, au travers du système de fichiers ("FileSystem" selon la terminologie anglo-saxonne), au fichier de l'application portable 210 pour en demander l'exécution. En référence à la figure 4, on illustre maintenant l'utilisation nomade de la clé USB 200. Comme mentionné précédemment, il apparaît utile pour l'utilisateur du véhicule 1, ici le pilote ou l'agent de maintenance, de pouvoir préparer à l'avance des données d'intervention (données de mission, planning de vol, procédure d'intervention de maintenance, par exemple) et/ou d'utiliser des données enregistrées lors de cette intervention pour une exploitation ultérieure, par exemple un rapport de vol. En se limitant pour la description uniquement au pilote d'avion, ce dernier dispose d'un ordinateur personnel portable 400. Cet outil lui permet d'effectuer ces traitements pré ou post-vol en tout lieu, notamment à son hôtel ou en salle de pré-embarquement. A titre d'alternative, le pilote peut se connecter à une borne PC (non représentée) mise à sa disposition dans la salle de pré-embarquement ou sur un ordinateur de l'hôtel. Cet ordinateur personnel 400 est classique, présente un écran 402, un clavier 404, un processeur CPU 406 pour l'exécution d'applications, un disque dur 408 stockant des applications et un système d'exploitation, de la mémoire vive (non représentée) et un port USB associé à des moyens de lecture 410. Le système d'exploitation embarqué sur l'ordinateur 400 est notamment de même famille, c'est-à-dire présentant une compatibilité binaire, que celui 123-1 intégré dans l'avion 1 par l'avionneur. Le pilote connecte alors sa clé USB 200 sur le port 410 de l'ordinateur 400. Soit à l'aide d'une application lanceur prévue sur l'ordinateur 400 (et procédant de façon identique à celle expliquée ci-dessus), soit directement au travers du système de fichier embarqué dans l'ordinateur 400, le pilote accède à son application portable 210 stockée dans la clé 200. L'application portable 210 est ainsi exécutée. Le pilote effectue les traitements souhaités, par exemple modifie les données, les lit, en ajoute, etc. En fin d'utilisation, l'application 210 est fermée. Puisqu'il s'agit d'une application portable, aucune trace n'est également laissée sur l'ordinateur 400. On décrit maintenant, en référence à la figure 5, un deuxième mode de réalisation de l'invention. Dans ce deuxième mode de réalisation, le système d'exploitation pour l'exécution de l'application 210 n'est plus embarqué dans le sous-système 110 ou 120 mais dans la clé USB 200 sur laquelle le sous-système 120 s'amorce (au sens de l'anglicisme "booter' ). Les autres caractéristiques décrites ci-dessus en lien avec les figures 1 à 4 peuvent s'appliquer à ce mode de réalisation. Plus en détail, la figure 5 illustre ce deuxième mode de réalisation de l'invention à l'aide d'une représentation simplifiée du sous-système 120 auquel est connectée la clé USB 200 d'un pilote. Dans la figure 5, le disque dur 123 ne stocke aucune donnée particulière. Néanmoins, on peut prévoir qu'un système d'exploitation, des applications et données associées sont stockés sur celui-ci pour se lancer au démarrage du système 100 en l'absence de clé USB 200. Le processeur 121 (et la carte mère du sous-système 120 au sens large) comprend, en mémoire morte, un micrologiciel BIOS (Basic Input Output System) 121-1 qui précise la liste et l'ordre des périphériques à consulter pour le démarrage du système d'exploitation. Il s'agit, pour l'homme du métier, de l'ordre de boot du BIOS. Pour l'invention, le BIOS 121-1 précise de "booter" initialement sur le lecteur USB 128 et à défaut, de démarrer sur le disque dur 123. Il est entendu que le système peut présenter plusieurs lecteurs de médias amovibles 128 et que le BIOS correspondant peut indiquer respectivement chacun de ces lecteurs dans un ordre prédéterminer avant de consulter le disque dur 123. La clé USB 200 présente, en sus des applications 210 et 210', éventuellement mais non nécessairement portables, un système d'exploitation 212 et des pilotes 214. Le système d'exploitation 212 est non installé, c'est-à-dire dont la configuration n'est pas encore associée à une couche matérielle (ou hardware) spécifique. Les pilotes 214 (ou drivers selon la terminologie anglo-saxonne) sont certifiées au préalable par l'avionneur et fournis aux compagnies aériennes disposant d'avions de cet avionneur. Ces pilotes 214 sont de préférence génériques au sens où ils permettent au système d'exploitation 212 de reconnaître tout type de matériel quelque soit le sous-système 120 et l'avion 1 utilisé en association avec la clé 200 du pilote. Ainsi, il est possible d'utiliser la clé 200 sur d'autres ordinateurs. En pratique, l'avionneur fournit les pilotes pour un certain nombre de systèmes d'exploitation majeurs ainsi que pour des services accessibles en réseau fournis par le domaine avionneur (serveur d'impression, service d'accès aux paramètres avioniques, unité KCCU [pour "Keyboard Cursor Control Unit"]). Ainsi la compagnie aérienne est libre d'intégrer ou non ces fonctions sur la clé USB 200 pour permettre au pilote d'y accéder. En référence à la figure 6 qui illustre un exemple d'étapes mises en oeuvre dans ce deuxième mode de réalisation, le pilote alimente le système 100 et donc ses sous-systèmes 110 et 120, à l'étape 600. A l'étape 602, le processeur 121 accède et exécute le BIOS 121-1. A la première commande du BIOS, le système détermine, à l'étape 604, s'il existe un système d'exploitation accessible sur le port USB 128, c'est-à-dire si une clé USB 200 hébergeant un système d'exploitation est connectée. Dans la négative (étape 606), le sous-système 120 démarre sur un périphérique suivant listé dans le BIOS, par exemple sur le système d'exploitation du disque dur 123. Dans l'affirmative (étape 608), le sous-système 120 charge le système d'exploitation 212 en mémoire RAM pour son exécution par le processeur 121. Afin d'adapter le système d'exploitation 212 à la couche matérielle du sous-système 120, l'initialisation du système d'exploitation 212 comprend, à l'étape 610, le chargement des pilotes 214 génériques présents dans la clé 200. Seuls les pilotes 214 correspondants aux périphériques et composants matériels installés sont chargés par des mécanismes de plug and play. Ainsi, à chaque redémarrage dans un sous-système d'exécution 120, le système d'exploitation 212 découvre le BIOS, le chipset, le CPU, la carte vidéo, les autres périphériques du sous-système 120 et charge à nouveau les pilotes utiles pour ces différents composants présents. On remarque que l'exécution du système d'exploitation utilise uniquement la mémoire vive 122, le processeur 121 et les éventuels périphériques 124. Aucune donnée n'est écrite sur le disque dur 123. Ainsi, lorsqu'il sera mis fin à l'exécution du système d'exploitation, aucune donnée ne subsistera, ce qui permet l'accueil d'une nouvelle clé USB 200 sans problème d'inter-fonctionnement. Une fois le système d'exploitation 212 en exécution, soit une application dédiée s'exécutant automatiquement liste les applications 210, 210' présentes sur la clé USB 200 et les présente au pilote lors de l'étape 612, soit le pilote, lui-même, au travers du système de fichiers, accède à l'application 210, 210' de son choix, à l'étape 612. A l'étape 614, le pilote sélectionne et lance l'exécution de l'application souhaitée, par exemple l'application de listes de vérification. On note ici que, puisque le système d'exploitation 212 est sur la clé USB 200, les paramètres ou données associées aux applications 210, 210' sont également sur la clé 200. Ainsi, aucune pollution du disque dur 123 n'est réalisée pour l'exécution de ces applications. On peut bien sûr utiliser des applications portables comme exposées ci-dessus, qui garantissent qu'aucune donnée n'est copiée dans un autre fichier. L'utilisation de l'application 210 permet au pilote d'accéder aux données (lecture et/ou écriture) dans la clé 200. Une fois l'exploitation de l'application 210 terminée, il est mis fin, à l'étape 616, à l'exécution de ladite application 210. Aucune trace de cette exécution n'est stockée de façon permanente dans le sous-système 120, notamment sur le disque dur 213. En ce qui concerne l'utilisation nomade de la clé 200 par le pilote, l'ordinateur 400 est configuré dans son BIOS de la même façon que le sous-système 120 précédemment évoqué en lien avec les figures 5 et 6, à savoir booter sur le port USB 410. Le pilote est ainsi capable de démarrer son système d'exploitation 212 sur n'importe quel PC, portable ou non. Ainsi, le pilote se retrouve dans le même environnement de travail hors de l'avion et dans l'avion. Le PC portable 400 que lui fournit la compagnie aérienne pour accéder au portail et service d'entreprise est utilisé uniquement à partir de la clé USB après un redémarrage lors de l'insertion de la clé 200. Ainsi le disque dur 408 qui contient l'environnement bureautique entreprise n'est pas utilisé et aucune trace n'est laissée dessus lors de l'utilisation de l'environnement de travail avion à partir de la clé USB 200. On note ainsi que le même PC portable 400 présente deux environnements de travail indépendants l'un de l'autre et sans aucune porosité : bureautique entreprise et environnement avion (également appelé Flight Ops û système d'exploitation de vol). On décrit maintenant, en référence aux figures 7 et 8, un troisième mode de réalisation de l'invention. Ce troisième mode de réalisation est très semblable au deuxième mode de réalisation exposé ci-dessus à ceci près que le sous-système 120 présente une couche de virtualisation qui libère le système d'exploitation 212 de contraintes matérielles, notamment vis-à- vis des pilotes 214. Les caractéristiques décrites ci-dessus en lien avec les figures 1 à 6 peuvent s'appliquer à ce mode de réalisation. Plus en détail, la figure 7 illustre ce troisième mode de réalisation de l'invention à l'aide d'une représentation simplifiée du sous-système 120 auquel est connectée la clé USB 200 d'un pilote. Dans la figure 7, le disque dur 123 stocke un premier système d'exploitation hôte 123-4, par exemple un noyau linux ou une distribution linux, un machine virtuelle 123-5 agencée pour être exécutée dans ce premier système d'exploitation 123-4, un deuxième système d'exploitation 123-1, par exemple le même que celui évoqué ci-dessus en lien avec la figure 2, et des applications 123-2 exécutables dans le deuxième système d'exploitation. Ces différents composants logiciels sont intégrés par l'avionneur. La machine virtuelle peut être conforme à VMWare, QEmu ou XEN par exemple. Comme illustré par la figure 8, au démarrage du sous-système 120, le premier système d'exploitation 123-4 est exécuté directement sur la couche matérielle 800 spécifique de l'avion (par l'utilisation de pilotes adéquats). Ensuite, la machine virtuelle 123-5 est automatiquement lancée, suivie du système d'exploitation "traditionnel" 123-1 proposant au pilote les différentes applications 123-2. Par ailleurs, la clé USB 200 est similaire à celle décrite en lien avec la figure 5, à ceci près que, du fait de la couche de virtualisation 123-5, les pilotes 214' ne sont pas génériques pour satisfaire un maximum de couches matérielles 800 mais sont spécifiques à la couche de virtualisation ou machine virtuelle 123-5. En pratique, on précise l'ordre d'amorçage dans le BIOS simulé au niveau de la couche de virtualisation, en indiquant le port sur lequel on présente un médium disposant d'un système d'exploitation, par exemple un CD-ROM, et éventuellement d'autres ports par défaut. Ici, on peut spécifier le port USB comme port principal d'amorçage pour démarrer sur le système d'exploitation 212. On note que ce troisième mode de réalisation ne limite pas le nombre de systèmes d'exploitation exécutés en parallèle sur la machine virtuelle, à partir d'une même couche matérielle. Notamment, aucun système d'exploitation ne peut être prévu dans le disque dur 123. En outre, plusieurs lecteurs 128 peuvent être utilisés pour faire démarrer plusieurs systèmes d'exploitation. Enfin, la présence de la couche de virtualisation 123-5 permet d'utiliser un même processeur à la fois pour le domaine avionneur et le domaine airliner. La séparation entre ces deux domaines est alors réalisée par l'instanciation de chacun des systèmes d'exploitation correspondant dans la machine virtuelle. Il est ainsi possible d'avoir un seul processeur dans l'avion. Une utilisation nomade de la clé USB 200 (voir figure 4 également) est également envisageable, auquel cas l'ordinateur 400 disposera des mêmes moyens de noyau linux et de machine virtuelle que le sous-système 120 évoqué ci-dessus en lien avec le troisième mode de réalisation. On décrit maintenant une variante de chacun des modes de réalisation précédemment décrits, de préférence du deuxième mode de réalisation qui présuppose qu'aucune installation logicielle n'est prévue a priori dans le sous-système 120. Cette variante repose sur l'utilisation d'un module amovible du processeur 121, permettant à la compagnie aérienne de gérer elle-même l'obsolescence de la carte CPU 121. Ainsi, l'avionneur fournit un emplacement vide pour mettre une carte CPU 121 au libre choix de la compagnie aérienne. Cette dernière peut ainsi choisir la puissance de CPU dont elle a besoin. Elle peut aussi décider de son remplacement pour obsolescence. Ainsi, outre la liberté logicielle obtenue grâce au procédé objet de l'invention, la compagnie aérienne dispose également d'une liberté partielle matérielle sur le système embarqué 100, 110, 120. Selon une caractéristique favorisant la sécurité du système embarqué 100, les cartes CPU 121 utilisées sont conformes à des standards avioniques, portant par exemple sur l'enveloppe électrique et/ou thermique, afin de garantir une bonne disponibilité de la fonction et une bonne sûreté. Une certification STC ("Supplemental Type Certification" selon la terminologie anglo- saxonne) peut être prévue à cette fin. Grâce à l'invention, la compagnie aérienne peut développer librement les applications qu'elle souhaite et les utiliser dans ses avions sans nécessiter l'intervention, pour certification et intégration, des avionneurs. Les exemples qui précèdent ne sont que des modes de réalisation de l'invention qui ne s'y limite pas. Notamment, en lien avec le monde automobile tel qu'évoqué précédemment, un média amovible comprenant une application de navigation GPS peut être prévu. Le conducteur prépare, sur son ordinateur personnel à son domicile, son trajet et les différents points de passage. En voiture, ce même conducteur connecte sa clé à son ordinateur de bord (système embarqué) qui permet l'exécution de l'application de navigation selon l'un quelconque des modes de réalisation envisagés ci-dessus en lien avec l'aviation. On note que grâce à l'invention, l'exécution de cette application n'altère pas la sécurité du système embarqué automobile et le média amovible avec son application peut être utilisé dans plusieurs voitures. REVENDICATIONS 1. Procédé d'exécution d'une application informatique (210, 210') d'interfaçage avec un équipage d'un véhicule (1), caractérisé en ce que le procédé comprend: la lecture (306, 308, 604) d'un média amovible (200), comprenant ladite application à exécuter, au moyen d'un lecteur (128) de média amovible équipant un système d'exécution embarqué (110, 120) dans le véhicule, l'exécution (312, 614) de ladite application par des moyens d'exécution (111, 121) équipant ledit système d'exécution et reliés audit lecteur de média amovible, ladite exécution de l'application ne requerrant l'enregistrement permanent de données nécessaires à son exécution que sur ledit média amovible. 2. Procédé selon la revendication précédente, dans lequel ladite application est une application portable. 3. Procédé selon la revendication précédente, dans lequel le système d'exécution comprend un lanceur d'applications (123-3) agencé pour détecter des applications portables contenues dans un média connecté audit lecteur, et ladite application portable est lancée à partir du lanceur d'applications. 4. Procédé selon l'une quelconque des revendications précédentes, dans lequel ledit média amovible comprend un système d'exploitation (212), le procédé comprenant, préalablement à ladite exécution de l'application, une étape d'amorçage (608) dudit système d'exécution sur ledit système d'exploitation, ladite application étant exécutée dans l'environnement dudit système d'exploitation du média amovible. 5. Procédé selon la revendication précédente, dans lequel ledit système d'exécution comprend un système de base d'entrée/sortie (BIOS) (121-1) configuré de sorte à amorcer ledit système d'exécution à partir d'un système d'exploitation stocké sur le média amovible connecté audit lecteur. 6. Procédé selon la revendication 4 ou 5, dans lequel ledit système d'exécution comprend une machine virtuelle (123-5) exécutée au démarrage, ledit système d'exploitation (212) étant exécuté dans ladite machine virtuelle. 7. Procédé selon la revendication précédente, dans lequel ledit système d'exécution comprend un système d'exploitation (123-1) embarqué agencé pour être exécuté dans ladite machine virtuelle (123-5). 8. Procédé selon l'une quelconque des revendications précédentes, dans lequel lesdits moyens d'exécution forment partie d'un module amovible dudit système d'exécution. 9. Kit pour l'exécution d'une application informatique d'interfaçage avec un équipage d'un véhicule (1), caractérisé en ce que le kit comprend: un média amovible (200) comprenant ladite application à exécuter (210, 210'), un système d'exécution embarqué (110, 120) dans le véhicule, comprenant un lecteur (128) de média amovible agencé pour recevoir et lire ledit média amovible (200) et, reliés audit lecteur, des moyens d'exécution (111, 121) agencés pour exécuter ladite application contenue dans ledit média amovible, ledit média amovible étant agencé de sorte que ladite exécution de l'application 20 ne requiert l'enregistrement permanent de données nécessaires à son exécution que sur ledit média amovible. 10. Aéronef (1) comprenant un kit selon la revendication précédente.