FR 3079328 A1 20190927 FR 1852362 A 20180320 Arrière-plan de l'invention L'invention se rapporte au domaine général de l'utilisation d'une application. Elle concerne plus particulièrement la construction d'une image d'une application. Parmi les solutions existantes permettant l'utilisation d'une application, on connaît les solutions s'exécutant dans une machine virtuelle, cette dernière s'exécutant sur une machine physique, par exemple un serveur distant. Ces solutions présentent l'inconvénient de consommer des ressources (mémoire, capacité de calcul, ...) importantes au niveau de la machine physique. En effet, l'utilisation d'une machine virtuelle nécessite en plus des ressources nécessaires à l'exécution de l'application elle- même, des ressources pour l'exécution d'un système d'exploitation complet, pour la gestion des bibliothèques logicielles et éventuellement pour l'ordonnancement (scheduling) des applications. On connaît également une solution consistant à installer et à exécuter (autrement dit à « déployer ») une application dans un conteneur d'application hébergé dans une machine physique. Le conteneur d'application comporte le code binaire de l'application et des bibliothèques logicielles. Cette solution permet d'optimiser les ressources système par rapport à l'installation d'une machine virtuelle puisque le conteneur ne comporte pas un système d'exploitation complet. Le conteneur d'application est autonome et auto-suffisant pour s'exécuter en s'appuyant sur un système d'exploitation s'exécutant sur la machine physique. On rappelle qu'un conteneur, exécuté par une machine, est un ensemble de processus isolés du reste des autres processus s'exécutant sur une même machine physique ou virtuelle. Un conteneur d'application s'exécute à partir d'une image qui fournit les fichiers nécessaires à la prise en charge de ses processus. Le conteneur d'une application doit être compatible avec le système d'exploitation de la machine physique ou virtuelle qui l'exécute, autrement dit, les bibliothèques logicielles comprises dans l'image de l'application doivent être compatibles avec le système d'exploitation de la machine physique ou virtuelle. Une méthode de création d'une image d'une application, de type généraliste, consiste à compiler le code binaire de l'application et toutes les bibliothèques logicielles requises par l'application pour qu'elle puisse être exécutée sur plusieurs systèmes d'exploitation. Le code et les bibliothèques logicielles sont compilés ensemble. Le résultat de la compilation est une image de l'application exécutable sur plusieurs systèmes d'exploitation. L'image créée par la méthode généraliste est portable en ce qu'elle peut être exécutée sur les différents systèmes d'exploitation précités. Cependant, cette méthode généraliste est consommatrice de ressources système. En effet, lorsque l'image est exécutée sur une machine ayant un système d'exploitation donné, les bibliothèques logicielles correspondantes aux autres systèmes d'exploitation ne sont pas utilisées et consomment de la mémoire. 2 Il existe également une méthode de création d'une image d'une application, dite de type « langage spécifique ». Selon cette méthode, le code de l'application est compatible uniquement avec un seul système d'exploitation de la machine physique ou virtuelle et seules les bibliothèques logicielles compatibles avec ce système d'exploitation sont sélectionnées. Le code de 5 l'application et les bibliothèques logicielles sélectionnées sont ensuite compilés ensemble pour former l'image de l'application. L'image de l'application créée de type « langage spécifique » consomme moins de ressources système qu'une image créée de type généraliste. Cependant, la portabilité de l'image créée de type « langage spécifique » n'est pas assurée. 10 Il existe alors un besoin en une solution de création d'une image d'une application qui ne présente pas les inconvénients des solutions existantes. Objet et résumé de l'invention 15 L'invention vise un procédé de création d'une image d'une application caractérisé en ce qu'il comporte les étapes de : obtention d'un premier objet obtenu par compilation du code de l'application; détermination d'un ensemble de bibliothèques logicielles requises par l'application à partir d'un ensemble des appels systèmes utilisés par l'application et identifiés dans le premier objet; 20 obtention d'un deuxième objet obtenu par compilation desdites bibliothèques logicielles pour un système d'exploitation personnalisé ; et assemblage du premier et du deuxième objet pour créer l'image de l'application. Corrélativement, l'invention vise un système de création d'une image d'une application, caractérisé en ce qu'il comporte: 25 un module d'obtention d'un premier objet obtenu par compilation du code de l'application; un module configuré pour déterminer un ensemble de bibliothèques logicielles requises par l'application à partir d'un ensemble des appels systèmes utilisés par l'application et identifiés dans le premier objet ; un module d'obtention d'un deuxième objet obtenu par compilation desdites bibliothèques 30 logicielles pour un système d'exploitation personnalisé ; et un module d'assemblage du premier et du deuxième objet pour créer l'image de l'application. Les caractéristiques et avantages du procédé selon l'invention présentés ci-après s'appliquent de la même façon au système selon l'invention. Le fait de compiler séparément le code de l'application des bibliothèques logicielles 35 permet la portabilité de l'application sur divers systèmes d'exploitation, et permet de fournir l'objet de l'application, dit premier objet, sans le code source, à un tiers souhaitant construire une image compatible avec un système d'exploitation donné. 3 La détermination des bibliothèques logicielles requises par l'application ne tient compte que des bibliothèques logicielles qui sont requises pour pouvoir exécuter l'application sur un système d'exploitation déterminé. L'invention permet d'optimiser les ressources système en comparaison avec une 5 méthode de type généraliste, car le deuxième objet est obtenu par compilation des bibliothèques logicielles requises par l'application, et uniquement celles-ci. Le premier objet étant indépendant d'un système d'exploitation, il est possible de le réassembler avec un autre deuxième objet pour créer une image de l'application compatible avec un autre système d'exploitation. 10 L'image créée peut être, par la suite, déployée dans un conteneur d'application. Nous désignons par les bibliothèques logicielles (autrement dit les librairies) requises par l'application, les dépendances de l'application. Nous désignons par « l'assemblage » du premier et du deuxième objet, l'édition de liens entre ces deux objets. 15 Au sens de l'invention, un ensemble de bibliothèques logicielles requises par l'application fait référence à toutes les bibliothèques logicielles requises par l'application. Pareillement, nous désignons par un ensemble des appels systèmes, l'intégralité des appels systèmes utilisés par l'application. Le premier et le deuxième objet obtenus par compilation sont des fichiers objets dans 20 un langage cible, par exemple dans des fichiers objets conformes à un langage machine tel qu'un langage assembleur. On rappelle qu'un fichier objet est un fichier intermédiaire obtenu au cours d'un processus de compilation. Ce fichier contient des données nécessaires à l'édition de liens. Ainsi, ce fichier objet est non exécutable directement. Dans un mode de réalisation, le premier et le deuxième objet sont binaires. 25 Dans un mode de réalisation, la détermination de l'ensemble des bibliothèques logicielles requises par l'application se fait à partir du premier objet compilé. Le code de l'application n'est pas divulgué pour la mise en oeuvre du procédé. Dans un mode de réalisation, il est possible de compiler le code source puis d'effectuer l'étape de détermination de l'ensemble des bibliothèques logicielles requises par l'application à 30 partir de l'objet compilé. La détermination, selon l'invention, de l'ensemble des bibliothèques logicielles est une détermination automatique. Dans un mode de réalisation, le procédé selon l'invention comporte en outre une étape de calcul d'une signature du premier objet et d'une signature du deuxième objet. 35 L'image créée est alors caractérisée par un couple de signatures, à savoir la signature du premier objet et la signature du deuxième objet, ce qui permet de détecter une image conforme à la présente invention. 4 Dans un mode de réalisation, l'étape de détermination de l'ensemble des bibliothèques logicielles comporte une recherche, dans le premier objet, d'une première séquence correspondant à un appel système, l'appel système utilisé par l'application étant identifié par une deuxième séquence connexe à la première séquence. 5 La première séquence et la deuxième séquence connexe à la première séquence sont conformes au langage du premier objet obtenu par compilation. Dans un mode de réalisation, la première séquence et la deuxième séquence connexe à la première séquence sont des instructions binaires conformes à une architecture externe du processeur, (ISA pour « Instruction Set Architecture »). 10 Dans un mode de réalisation, les appels systèmes utilisés par l'application sont de type Posix (Portable Operating System Interface, standard IEEE 1003) System Call contenus dans une liste. Dans ce mode, la deuxième séquence permet d'identifier un appel système de cette liste. Dans un mode de réalisation particulier, un dictionnaire associe un appel système ABI (pour « Application Binary Interface ») avec des bibliothèques logicielles les implémentant. La ou 15 les bibliothèques logicielles requises par chaque appel système sont ainsi identifiées. Dans un mode de réalisation particulier, des dépendances d'une bibliothèque logicielle identifiée avec une ou d'autres bibliothèques logicielles sont déterminées et cette ou ces dernières sont ajoutées à une liste de l'ensemble des bibliothèques logicielles requises par l'application. Les différents modules du système selon l'invention ne sont pas nécessairement 20 compris dans un même dispositif. L'invention vise également une image d'une application caractérisée en ce qu'elle comporte: un objet correspondant au premier objet obtenu par compilation du code de l'application, produit lors d'un assemblage avec un deuxième objet; et 25 le deuxième objet obtenu par compilation d'un ensemble de bibliothèques logicielles requises par l'application pour un système d'exploitation personnalisé. Le procédé de l'invention permet de créer une image d'une application selon l'invention. Dans un mode de réalisation, un conteneur d'application est exécuté à partir de 30 l'image d'une application selon l'invention. Le conteneur est installé sur un hyperviseur. L'invention vise également un premier programme d'ordinateur sur un support d'enregistrement, ce programme étant susceptible d'être mis en oeuvre dans un ordinateur ou dans un dispositif compris dans le système selon l'invention, ce programme comportant des instructions adaptées à la mise en oeuvre d'un procédé de création d'une image d'une application tel que décrit 35 ci-dessus. L'invention vise également un second programme d'ordinateur sur un support d'enregistrement, ce programme étant susceptible d'être mis en oeuvre dans un ordinateur ou dans 5 un dispositif compris dans le système selon l'invention, ce programme comportant des instructions adaptées à la mise en oeuvre d'un procédé d'exécution d'une image selon l'invention. Chacun de ces programmes peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code 5 objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable. L'invention vise aussi des supports d'information ou d'enregistrement lisibles par un ordinateur, et comportant des instructions des programmes d'ordinateur tels que mentionnés ci-dessus. 10 Les supports d'information ou d'enregistrement peuvent être n'importe quelle entité ou dispositif capable de stocker les programmes. Par exemple, les supports peuvent comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette (floppy disc) ou un disque dur, ou une mémoire flash. 15 D'autre part, les supports d'information ou d'enregistrement peuvent être des supports transmissibles tels qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par lien radio, par lien optique sans fil ou par d'autres moyens. Les programmes selon l'invention peuvent être en particulier téléchargés sur un réseau de type Internet. 20 Alternativement, chaque support d'informations ou d'enregistrement peut être un circuit intégré dans lequel un des programmes est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution de la méthode en question. Brève description des dessins 25 D'autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins annexés qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif. Sur les figures : La figure 1 est un organigramme représentant les étapes d'un procédé de création d'une 30 image d'une application, conformément à un mode de réalisation particulier ; La figure 2 illustre l'architecture fonctionnelle d'un système de création d'une image selon un mode de réalisation particulier ; La figure 3 illustre l'architecture matérielle d'un dispositif du système de création d'une image selon un mode de réalisation particulier ; 35 La figure 4 représente une image d'une application créée par le procédé proposé selon un mode de réalisation particulier ; et La figure 5 représente l'architecture logicielle permettant l'exécution d'une image conforme à l'invention, selon un mode de réalisation particulier. 6 Description détaillée La figure 1 représente un organigramme représentant des étapes d'un procédé de 5 création d'une image IMG d'une application, conforme à un mode de réalisation particulier. Dans ce mode de réalisation, un code source CODE_APP de l'application a été compilé au cours d'une étape T10 qui précède la mise en oeuvre des étapes du procédé de création proposé. Au cours d'une étape E10, un système SYS qui met en oeuvre le procédé de création 10 d'une image obtient un premier objet 01 obtenu par compilation (T10) du code source de l'application. Le premier objet 01 obtenu par compilation est un fichier objet dans un langage cible, par exemple un fichier objet conforme à un langage machine tel qu'un langage assembleur. On rappelle qu'un fichier objet est un fichier intermédiaire obtenu au cours d'un processus de 15 compilation. Ce fichier contient des données nécessaires à l'édition de liens. Ainsi, ce fichier objet est non exécutable directement. Dans un mode de réalisation particulier, le premier objet 01 est un objet binaire. Par exemple ce premier objet 01 est de type blob (Binary Large OBject). L'obtention (E10) du premier objet 01 peut consister en la réception de l'objet 01, par 20 un moyen de communication du système ou par une lecture à partir d'un support mobile d'enregistrement sur lequel le premier objet 01 a été enregistré. La compilation, non décrite ici, peut être effectuée par un compilateur de l'art antérieur. Au cours d'une étape E20, le système SYS détermine l'ensemble des bibliothèques 25 logicielles LIB requises par l'application à partir de l'ensemble des appels systèmes utilisés par l'application et identifiés dans le premier objet 01. Dans ce mode de réalisation, le système SYS cherche dans le premier objet binaire 01 tous les différents appels systèmes utilisés pour former l'ensemble des appels systèmes. Le système SYS identifie ensuite la ou les bibliothèques logicielles requises par chaque appel système 30 en ignorant les éventuels doublons de bibliothèques logicielles, correspondant par exemple à deux appels systèmes distincts d'une même bibliothèque, et obtient ainsi une liste de l'ensemble des bibliothèques logicielles LIB requises par l'application. Dans un mode de réalisation particulier, la recherche des appels systèmes utilisés par l'application se base sur une recherche d'une première séquence, caractéristique d'un appel 35 système. Une deuxième séquence connexe à la première séquence permet ensuite d'identifier l'appel système requis par l'application. Dans un mode particulier, la première et la deuxième séquence sont des séquences binaires. 7 Par exemple, la première séquence binaire est caractéristique d'un appel système. Plus particulièrement, un appel système spécifique de type Posix comporte deux parties : une première partie identique pour tous les appels système, et une deuxième partie qui caractérise cet appel système spécifique. La première partie identique est la première séquence binaire recherchée, 5 alors que la deuxième partie représente la deuxième séquence connexe à la première séquence. Les deuxièmes parties sont par exemple contenues ou référencées dans une liste, permettant ainsi d'identifier un appel système à partir de cette liste. Dans un mode de réalisation particulier, un dictionnaire associe un appel système ABI (pour « Application Binary Interface ») avec des bibliothèques logicielles les implémentant. Le 10 système SYS identifie ainsi la ou les bibliothèques logicielles requises par chaque appel système. Dans un mode de réalisation particulier, des dépendances d'une bibliothèque logicielle identifiée avec une ou d'autres bibliothèques logicielles sont déterminées et cette ou ces dernières sont ajoutées à la liste des bibliothèques logicielles requises par l'application. Au cours d'une étape E30, le système SYS obtient un deuxième objet 02 généré par 15 compilation de l'ensemble des bibliothèques logicielles LIB déterminé à l'étape E20 pour un système d'exploitation donné. Ce deuxième objet 02 est ainsi personnalisé pour ce système d'exploitation. Ce deuxième objet 02 est également un fichier objet. L'ensemble des bibliothèques logicielles LIB peut être compilé par le système SYS au cours de l'étape E30 elle-même, le résultat de la compilation est le deuxième objet 02. 20 Dans un mode de réalisation particulier, le deuxième objet 02 est un objet binaire. Par exemple ce deuxième objet 02 est de type blob. Dans un mode de réalisation particulier, une signature SIG1, SIG2 est calculée pour chacun des objets 01 et 02 au cours d'une étape E40. On entend par signature une empreinte calculée sur tout ou partie d'un objet 0 et 25 caractérisant ce dernier. La signature SIG1 est calculée sur une partie de l'objet 01 qui n'est pas modifiée lors de l'étape d'assemblage E50, décrite ultérieurement. Dans un mode de réalisation particulier, la signature de l'objet 01 correspond à la liste de l'ensemble des appels systèmes identifiés dans cet objet 01. 30 Dans un mode de réalisation particulier, la signature de l'objet 02 correspond à la liste des appels systèmes qu'il implémente, ainsi que le système d'exploitation dont le support est visé. Contrairement à une image créée par un procédé de l'état de l'art où le code et les bibliothèques logicielles sont compilés ensemble, l'image créée selon le procédé de création proposé est caractérisée par un couple des deux signatures (SIG1, SIG2) correspondant aux 35 signatures des deux objets 01 et 02. Au cours d'une étape E50, le premier objet 01 et le deuxième objet 02 sont assemblés (« link » en anglais) pour créer l'image IMG de l'application. Dans cette étape E50, les adresses mémoire des appels système identifiés dans le premier objet 01 sont éditées pour pointer vers les 8 routines correspondantes dans le deuxième objet 02. Ainsi, cette édition produit un objet 0'1 correspondant au premier objet 01. L'image créée IMG peut être exécutée, au cours d'une étape qui fait suite au procédé de création, pour obtenir un conteneur de l'application. L'application peut ainsi être exécutée sur 5 une machine physique ou virtuelle compatible avec le système d'exploitation personnalisé utilisé pour obtenir le deuxième objet 02. Plusieurs instances de l'image IMG peuvent être générées pour exécuter l'application sur différentes machines physiques ou virtuelles compatibles avec le système d'exploitation personnalisé utilisé pour obtenir le deuxième objet 02. 10 Dans un autre mode de réalisation, le procédé de création ne dispose en entrée que du code source CODE_APP. Le système SYS compile le code source CODE_APP au cours de l'étape E10, le résultat de la compilation représentant le premier objet 01. Dans un autre mode de réalisation, l'étape E30 de génération du deuxième objet 02 par compilation des bibliothèques logicielles LIB est effectuée par un dispositif ne faisant pas partie 15 du système SYS. Le système SYS reçoit, au cours de l'étape E30, le deuxième objet 02. Ce procédé de création d'une image trouve une application avantageuse dans le cadre de la construction d'images système de type « unikernel », dans lequel un exécutable d'une application comprend l'ensemble des routines du système d'exploitation suffisantes pour son exécution dans un environnement de virtualisation système. Grâce au procédé de création 20 proposé, l'exécutable de l'application comprend uniquement les routines du système d'exploitation strictement nécessaires pour son exécution. La figure 2 représente l'architecture fonctionnelle d'un système SYS de création d'une image IMG d'une application, conformément à un mode de réalisation de l'invention. 25 Le système SYS comporte : un module MOD_01 d'obtention d'un premier objet 01 obtenu par compilation (E10, T10) du code CODE_APP de l'application ; un module MOD_LIB configuré pour déterminer un ensemble de bibliothèques logicielles LIB requises par l'application à partir d'un ensemble des appels systèmes utilisés par l'application 30 et identifiés dans le premier objet 01; un module MOD_02 d'obtention d'un deuxième objet 02 obtenu par compilation (E30) desdites bibliothèques logicielles LIB, pour un système d'exploitation personnalisé; et un module MOD_LINK d'assemblage des objets 01 et 02 pour créer l'image IMG de l'application. 35 Dans un mode de réalisation, le premier objet 01 et/ou le deuxième objet 02 sont des fichiers objets. Le module MOD_01 d'obtention d'un premier objet 01 peut recevoir en entrée le premier objet 01 ou le code CODE_APP de l'application. 9 Le module MOD_01 fournit en sortie le premier objet 01. Le module MOD_LIB reçoit en entrée le premier objet 01. Le module MOD_LIB génère en sortie l'ensemble des bibliothèques logicielles LIB requises par l'application, comme décrit précédemment. 5 Le module MOD_02 d'obtention d'un deuxième objet 02 reçoit en entrée l'ensemble LIB des bibliothèques logicielles requises par l'application, pour un système d'exploitation personnalisé, et fournit en sortie le deuxième objet 02. Le module MOD_LINK d'assemblage des objets 01 et 02 requiert en entrées le premier objet 01 et le deuxième objet 02. En sortie, il fournit l'image IMG de l'application par 10 édition de liens, comme décrit précédemment. Les modules MOD_01, MOD_02, MOD_LIB et MOD_LINK peuvent être mis en oeuvre par différents dispositifs du système SYS. Dans le mode de réalisation décrit ici, chaque dispositif du système SYS conforme à 15 l'invention a l'architecture d'un ordinateur, telle qu'illustrée à la figure 3. Elle comprend notamment un processeur 7, une mémoire vive 8, une mémoire morte 9, une mémoire flash non volatile 10 dans un mode particulier de réalisation de l'invention, ainsi que des moyens de communication 11. De tels moyens sont connus en soi et ne sont pas décrits plus en détail ici. La mémoire morte 9 d'un dispositif compris dans le système SYS de création d'une 20 image selon l'invention constitue un support d'enregistrement conforme à l'invention, lisible par le processeur 7 et sur lequel est enregistré ici un programme d'ordinateur Prog conforme à l'invention. La mémoire 10 d'un dispositif compris dans le système SYS permet d'enregistrer des variables utilisées pour l'exécution des étapes de l'invention, telles que le code CODE_APP de 25 l'application, une liste des appels systèmes utilisés par l'application, une liste des appels systèmes de type Posix System Call, un résultat temporaire ou définitif de recherche d'appels systèmes, etc. Le programme d'ordinateur Prog définit des modules fonctionnels et logiciels ici, configurés pour permettre à un système SYS de créer une image IMG d'une application. Ces modules fonctionnels s'appuient sur et/ou commandent les éléments matériels 7-11 d'un dispositif 30 du système SYS cités précédemment. La figure 4 représente une image IMG d'une application, l'image IMG étant obtenue par exécution du procédé de création proposé. L'image IMG est un programme exécutable par une machine physique ou virtuelle. 35 L'image IMG comporte : un objet 01 correspondant au premier objet 01 obtenu par compilation (E10, T10) du code source CODE_APP de l'application, produit lors de l'assemblage avec un deuxième objet 02; et 10 - le deuxième objet 02 obtenu par compilation (E30) d'un ensemble de bibliothèques logicielles LIB requises par l'application. L'image IMG conforme à l'invention est caractérisée par un couple de signatures SIG1 et SIG2 correspondant aux signatures du premier objet 01 et du deuxième objet 02. 5 La figure 5 illustre l'architecture logicielle permettant l'exécution d'une image IMG conforme à l'invention, selon un mode de réalisation de l'invention. Dans ce mode de réalisation, pour exécuter l'application sur une machine physique ORD, un conteneur d'application C_APP est exécuté à partir de l'image IMG de l'application, et 10 installé sur un hyperviseur HYP de la machine ORD. L'hyperviseur HYP est mis en oeuvre au-dessus de l'infrastructure matérielle PHY de la machine ORD. Dans un mode de réalisation particulier, l'image IMG est une image de type « unikernel » et le conteneur d'application C_APP est une machine virtuelle s'exécutant sur l'infrastructure matérielle PHY de la machine ORD. 15 La machine physique ORD a l'architecture d'un ordinateur, similaire à l'architecture présentée à la figure 3. Cette architecture logicielle peut par exemple être utilisée dans un réseau de communication mobile de 5ème génération (5G) dans lequel des fonctions réseaux virtualisées sont mises en oeuvre, pour assurer à la fois la performance et la portabilité de la fonction réseau 20 virtualisée. L'invention vise aussi un programme d'ordinateur ProgImg qui définit des modules fonctionnels et logiciels ici, configurés pour permettre à une machine physique ORD d'exécuter une image IMG conforme à l'invention. Ces modules fonctionnels s'appuient sur et/ou commandent les 25 éléments matériels 7-11 de la machine ORD: un processeur 7, une mémoire vive 8, une mémoire morte 9, une mémoire flash non volatile 10 dans un mode particulier de réalisation de l'invention, ainsi que des moyens de communication 11. La mémoire morte 9 de la machine ORD constitue un support d'enregistrement conforme à l'invention, lisible par le processeur 7 de la machine ORD et sur lequel est enregistré ici 30 un programme d'ordinateur ProgImg conforme à l'invention, permettant l'exécution de l'image IMG présentée à la figure 4. La mémoire 10 de la machine ORD permet d'enregistrer des variables utilisées pour l'exécution des étapes d'exécution de l'image IMG conforme à l'invention. REVENDICATIONS1. Procédé de création d'une image d'une application caractérisé en ce qu'il comporte les étapes suivantes : obtention (E10) d'un premier objet (01) obtenu par compilation (E10, T10) du code (CODE_APP) de l'application ; détermination (E20) d'un ensemble de bibliothèques logicielles (LIB) requises par l'application à partir d'un ensemble des appels systèmes utilisés par l'application et identifiés dans le premier objet (01) ; obtention (E30) d'un deuxième objet (02) obtenu par compilation (E30) desdites bibliothèques logicielles (LIB) pour un système d'exploitation personnalisé ; et assemblage (E50) desdits objets pour créer ladite image (IMG) de l'application. 2. Procédé selon la revendication 1 comportant en outre une étape (E40) de calcul de signatures (SIG1, 5IG2) de chacun desdits objets (01, 02). 3. Procédé selon la revendication 1 ou 2, dans lequel l'étape (E20) de détermination d'un ensemble de bibliothèques logicielles comporte une recherche, dans ledit premier objet (01), d'une première séquence correspondant à un appel système, l'appel système utilisé par l'application étant identifié par une deuxième séquence connexe à la première séquence. 4. Programme d'ordinateur (Prog) comportant des instructions pour la création d'une image d'une application selon une des revendications 1 à 3, lorsque ledit programme est exécuté par un ordinateur. 5. Support d'enregistrement lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur (Prog) comprenant des instructions pour l'exécution des étapes d'un procédé de création d'une image d'une application selon une des revendications 1 à 3. 6. Système (SYS) de création d'une image d'une application, caractérisé en ce qu'il comporte: un module (MOD_01) d'obtention d'un premier objet (01) obtenu par compilation (E10, T10) du code (CODE_APP) de l'application ; un module (MOD_LIB) configuré pour déterminer un ensemble de bibliothèques logicielles (LIB) requises par l'application à partir d'un ensemble des appels systèmes utilisés par l'application et identifiés dans le premier objet (01); un module (MOD_02) d'obtention d'un deuxième objet (02) obtenu par compilation (E30) desdites bibliothèques logicielles pour un système d'exploitation personnalisé; et 12 - un module (MOD_LINK) d'assemblage desdits objets (01, 02) pour créer ladite image (IMG) de l'application. 7. Image (IMG) d'une application caractérisée en ce qu'elle comporte: 5 - un objet (0'1) correspondant au premier objet (01) obtenu par compilation (E10, T10) du code de l'application, produit lors d'un assemblage avec un deuxième objet (02) ; et - ledit deuxième objet (02) obtenu par compilation (E30) d'un ensemble de bibliothèques logicielles, requises par l'application, pour un système d'exploitation personnalisé. 10 8. Procédé d'installation, sur un hyperviseur, d'un conteneur d'application (C_APP) exécuté à partir d'une image (IMG) d'une application selon la revendication 7. 9. Programme d'ordinateur (ProgImg) comportant des instructions pour l'exécution d'une image (IMG) selon la revendication 7, lorsque ledit programme est exécuté par un 15 ordinateur. 10. Support d'enregistrement lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur (ProgImg) comprenant des instructions pour l'exécution d'une image (IMG) selon la revendication 7. 20