Brevet FR3011955A1 — publié le 20150417

La présente invention concerne un procédé de déploiement d'une application, un programme d'ordinateur correspondant, un système de déploiement d'une application et une installation comportant le système de déploiement. L'architecture à services (de l'anglais « Service Oriented Architecture » ou SOA) est un style architectural pour construire des applications, fondé sur la composition de composants fournissant des services. Chaque service est réalisé sur requête par des opérations d'un composant offrant ce service. L'architecture à services permet l'inter-opérabilité de composants applicatifs écrits dans différents langages de programmation reposant sur différentes technologies et standards. Il existe plusieurs spécifications (par exemple : SCA, OSGi, iPOJO, Fractal) qui standardisent les différentes phases du cycle de vie d'une application que sont la modélisation, l'assemblage, le déploiement et l'exécution d'applications dans une approche à services. En particulier, le déploiement de l'application signifie que les composants de l'application peuvent être distribués sur des ordinateurs connectés en réseau. En outre, un unique composant peut être lui-même divisé en modules distribués entre les ordinateurs, ces modules étant pouvant être écrits dans des langages de programmation différents. Pour permettre la communication des modules de l'application déployée, l'application comprend généralement un intergiciel. Un intergiciel est définit comme un logiciel servant d'intermédiaire de communication entre plusieurs applications (modules dans le cas présent), généralement complexes ou distribuées sur un réseau informatique. Cet intergiciel peut lui-même être construit de manière modulaire, chacun de ses modules étant appelé un conteneur et étant associé à un module de l'application, de manière que ce module communique avec les autres modules de l'application au travers du conteneur associé. De manière classique, tous les conteneurs sont identiques. Or, les applications de pointes sont fortement contraintes en termes de qualité de service et/ou de temps réel (déterminisme, prédictibilité), ce que ne permet pas l'utilisation d'un même type de conteneur pour tous les modules de l'application. Il peut ainsi être souhaité de prévoir un procédé de déploiement d'une application qui permette de s'affranchir d'au moins une partie des problèmes et contraintes précités. Il est donc proposé un procédé de déploiement d'une application pour obtenir l'exécution de parties de l'application sur respectivement des ordinateurs en réseau, chaque partie de l'application comportant un conteneur et un module associé, au moins un module étant destiné à envoyer un message au travers de son conteneur associé et au moins un module étant destiné à recevoir le message au travers de son conteneur associé, le procédé comportant : pour chaque partie de l'application, la compilation de code source implémentant le module et de code source implémentant le conteneur, pour obtenir du code machine de cette partie de l'application, et la commande de l'exécution du code machine de chaque partie de l'application par l'ordinateur destiné à exécuter cette partie de l'application, dans lequel le code source implémentant le conteneur et le code source implémentant le module d'au moins une première partie de l'application sont écrits dans un même premier langage informatique et dans lequel le code source du conteneur et le code source du module d'au moins une seconde partie de l'application sont écrits dans un même second langage informatique, différent du premier langage informatique. Le fait que le conteneur et le module soient écrits dans le même langage permet un meilleur contrôle sur la communication entre eux. De façon optionnelle, le procédé de déploiement d'une application comporte : l'obtention d'une description fonctionnelle de l'application, indiquant : - les modules de l'application, - pour chaque module, au moins un service, soit utilisé par le module, soit réalisé par le module, pour chaque module, la génération d'au moins une partie du code source implémentant le conteneur associé à partir de la description fonctionnelle, ce code source comportant, pour chaque service utilisé par le module, une fonction destinée à contacter le conteneur associé au module réalisant le service et, pour chaque service réalisé par le module, un appel à une fonction du module implémentant le service. De façon optionnelle également, la description fonctionnelle indique en outre : - pour chaque module, le langage de programmation de ce module, et, pour chaque module, le code source implémentant le conteneur associé est généré dans le langage de programmation du module tel qu'indiqué dans la description fonctionnelle. De façon optionnelle également, la description fonctionnelle est écrite dans un langage à balises, tel que le langage XML. De façon optionnelle également, le procédé de déploiement d'une application comporte en outre : - pour chaque conteneur associé à un module réalisant un service, la réception d'une indication d'une voie de communication ouverte sur l'ordinateur exécutant le conteneur, par laquelle le conteneur est apte à recevoir des messages, - l'indication à chaque conteneur associé à un module utilisant un service, de la voie de communication par laquelle le conteneur associé au module réalisant le service est apte à recevoir des messages. De façon optionnelle également, le procédé de déploiement d'une application comporte en outre : - la transmission à chaque ordinateur d'une requête de création de processus, et la commande de l'exécution du code machine de chaque partie comporte la commande de charger le code machine de cette partie en tant que processus léger du processus. Il est également proposé un programme d'ordinateur téléchargeable depuis un réseau de communication et/ou enregistré sur un support lisible par ordinateur et/ou exécutable par un processeur, caractérisé en ce qu'il comprend des instructions pour l'exécution des étapes d'un procédé de déploiement d'une application selon l'invention, lorsque ledit programme est exécuté sur un ordinateur. Il est également proposé un système de déploiement d'une application pour obtenir l'exécution de parties de l'application sur respectivement des ordinateurs en réseau, chaque partie de l'application comportant un conteneur et un module associé, au moins un module étant destiné à envoyer un message au travers de son conteneur associé et au moins un module étant destiné à recevoir le message au travers de son conteneur associé, le système comportant : - un dispositif destiné, pour chaque partie de l'application, à compiler du code source implémentant le module et du code source implémentant le conteneur, pour obtenir du code machine de cette partie de l'application, et - un dispositif destiné à commander l'exécution du code machine de chaque partie de l'application par l'ordinateur destiné à exécuter cette partie de l'application, dans lequel le code source implémentant le conteneur et le code source implémentant le module d'au moins une première partie de l'application sont écrits dans un même premier langage informatique et dans lequel le code source du conteneur et le code source du module d'au moins une seconde partie de l'application sont écrits dans un même second langage informatique, différent du premier langage informatique. Il est également proposé une installation comportant : un système de déploiement d'une application selon l'invention, les ordinateurs sur lesquels les parties de l'application sont destinées à être exécutées, un réseau d'interconnexion du système de déploiement et des ordinateurs. L'invention sera mieux comprise à l'aide de la description qui va suivre, donnée uniquement à titre d'exemple et faite en se référant aux dessins annexés dans lesquels : la figure 1 représente schématiquement la structure générale d'une installation de déploiement d'une application, selon un mode de réalisation de l'invention, la figure 2 représente une description fonctionnelle d'une application destinée à être déployée, la figure 3 illustre les étapes successives d'un procédé de déploiement de l'application, selon un mode de réalisation de l'invention, les figures 4 à 7 illustrent respectivement des étapes du procédé de la figure 3, et la figure 8 illustre l'installation de la figure 1 une fois l'application déployée. En référence à la figure 1, une installation 100 de déploiement d'une application va à présent être décrite. L'installation 100 comporte tout d'abord un système 102 de déploiement d'une application. Dans l'exemple décrit et illustré, le système de déploiement 102 est un ordinateur muni d'une unité de traitement 104 (par exemple un processeur) et d'une mémoire 106 (par exemple une mémoire RAM). Un programme 108 de déploiement d'application est enregistré dans la mémoire 106. Ce programme 108 comporte des instructions destinées à être exécutées par l'unité de traitement 104 pour réaliser les étapes d'un procédé de déploiement d'application qui sera décrit plus loin. Il sera apprécié que le programme 108 peut en pratique être divisé en plusieurs programmes interagissant entre eux pour réaliser les mêmes étapes. En variante, au moins une partie du programme 108 pourrait être remplacée par des circuits intégrés dédiés. Ainsi, en variante, le système de déploiement 102 5 pourrait être composé uniquement de circuits intégrés (sans programme d'ordinateur). Dans la suite, lorsqu'il sera indiqué qu'un programme d'ordinateur réalise une action, cela signifiera que l'unité de traitement, exécutant les instructions correspondantes du programme d'ordinateur, réalise cette action. 10 L'installation informatique 100 comporte en outre des ordinateurs Ml, M2 similaires au système de déploiement 102 et comportant de la même manière des unités de traitement 114, 116 associées à des mémoires 118, 120. L'installation informatique 100 comporte en outre un réseau 122 d'interconnexion des ordinateurs 102, MI et M2. 15 Dans l'exemple décrit, l'installation 100 est destinée à déployer une application « hello world », dans laquelle un module ml est destiné à envoyer une requête à un module m2 afin que ce dernier affiche un message « hello world » sur un dispositif d'affichage. Comme illustré sur la figure 1, l'application « hello world », une fois déployée, 20 est divisée en plusieurs parties pl, p2 enregistrées respectivement dans les mémoires 118, 120 des ordinateurs Ml, M2 et destinées à être exécutées par respectivement les unités de traitement 114, 116 des ordinateurs Ml, M2. Chaque partie pl, p2 de l'application « hello world » comporte un conteneur contl, cont2 et un module ml, m2 associé. Au moins un module (le module ml dans l'exemple décrit) 25 est destiné à envoyer un message au travers de son conteneur associé (le conteneur contl), et au moins un module (le module m2 dans l'exemple décrit) est destiné à recevoir ce message au travers de son conteneur associé (le conteneur cont2). En référence à la figure 2, une description fonctionnelle 200 de l'application « hello world » va à présent être décrite. 30 La description fonctionnelle 200 indique la présence d'au moins deux composants chacun comportant au moins un module muni d'au moins une opération. Lorsqu'un composant comporte plusieurs modules, ces derniers peuvent être destinés à être exécutés sur des ordinateurs différents. Dans l'exemple décrit, la description fonctionnelle 200 indique tout d'abord la 35 présence d'un composant cl comportant le module ml muni d'une opération opl destinée à envoyer une requête pour afficher le message « hello world ». La description fonctionnelle indique en outre la présence d'un composant c2 comportant le module m2 muni d'une opération op2 destinée à afficher, sur requête, le message « hello world ». La description fonctionnelle 200 introduit en outre la notion de « service » qui correspond à une ou plusieurs actions qu'un composant peut réaliser sur requête d'autres composants. Plus précisément, cette ou ces actions sont réalisées par une opération d'un module du composant ou par l'interaction de plusieurs opérations d'un même module ou de modules différents du composant. Ainsi, un service constitue une interface pour les composants le sollicitant, cette interface cachant l'implémentation concrète du service, c'est-à-dire la ou les opérations réalisant le service. La notion de service est utile pour permettre de définir chaque composant indépendamment des autres, ce qui facilite la conception d'applications complexes pouvant regrouper plusieurs centaines de composants. La description fonctionnelle 200 associe chaque composant à au moins un service, qui peut être soit un service utilisé par le composant, auquel cas le composant comporte alors une référence à ce service (indiquée en traits pointillés sur la figure 2), soit un service offert à d'autres composants. Dans le cas d'une référence à un service, la description fonctionnelle 200 indique au moins une opération utilisant le service. Dans le cas d'un service offert, la description fonctionnelle 200 indique au moins une opération réalisant le service. Un service s est utilisé dans l'application « hello world », ce service s étant : « afficher « hello world » sur un dispositif d'affichage ». La description fonctionnelle 200 indique que le composant c2 offre le service s, et que ce service s est réalisé par l'opération op2. Cela est représenté sur la figure 2 par une flèche entre le service s et l'opération op2. La description fonctionnelle 200 indique en outre que le composant cl comporte une référence r(s) au service s et que l'opération opl utilise le service s. Cela est représenté sur la figure 2 par une flèche entre l'opération opl et la référence r(s) au service s. La description fonctionnelle 200 indique en outre au moins un lien de service connectant chaque référence à un service au service référencé. Dans l'exemple décrit, la description fonctionnelle 200 indique que la référence r(s) est reliée au service s par un lien de service W. La description fonctionnelle 200 indique en outre, pour chaque module, un langage de programmation dans lequel ce module est destiné à être écrit et un ordinateur destiné à exécuter le module. Dans l'exemple décrit, la description fonctionnelle 200 indique que le module ml est destiné à être écrit en C et à être exécuté par l'ordinateur Ml, et que le module m2 est destiné à être écrit en C++ et à être exécuté par l'ordinateur M2. La description fonctionnelle 200 est de préférence écrite dans un langage à balises, tel que le langage XML. En référence à la figure 3, un procédé 300 de déploiement de l'application « hello world » utilisant l'installation 100 de la figure 1 va à présent être décrit. Au cours d'une étape 302, le programme de déploiement 108 obtient la description fonctionnelle 200 de l'application « hello world ». Au cours d'une étape 304, pour chaque module, le programme de déploiement 108 obtient du code source implémentant ce module, dans le langage de programmation indiqué dans la description fonctionnelle 200. Ce code source est par exemple écrit par un informaticien. Dans l'exemple décrit, le code source du module ml comporte un fichier ClImpl.c comportant en particulier une fonction f1 implémentant l'opération opl. La fonction ft comporte un appel à une fonction hello request sync du conteneur contl destinée à contacter le service s, comme cela sera expliqué plus loin. Le code source du module m2 comporte un fichier C2Impl.c comportant en particulier une fonction hello request received implémentant l'opération op2, c'est-à-dire affichant le message « hello world ». Au cours d'une étape 306, pour chaque module, le programme de déploiement 108 obtient en outre du code source implémentant un conteneur générique dans le langage informatique du module. Le conteneur générique est destiné à fournir des fonctions générales permettant en particulier la communication avec d'autres conteneurs. Le conteneur générique est destiné à être complété par une extension implémentant des fonctions spécifiques au module, comme cela sera expliqué plus loin, pour former le conteneur associé au module. Dans l'exemple décrit, le programme 108 obtient un fichier container.c écrit en C pour le module ml et un fichier container.cpp écrit en C++ pour le module m2. Au cours d'une étape 308 (illustrée en détail sur la figure 4), pour chaque module, le programme de déploiement 108 génère une interface de programmation du module. L'interface de programmation sera appelée dans la suite « API », de l'anglais « Application Programming Interface ». Dans l'exemple décrit, l'API du module ml comporte un fichier entête Cl Impl.h ne comportant pas de déclaration de fonction spécifique à l'exemple décrit car l'opération opl n'est pas utilisée à l'extérieur du module ml. En revanche, l'API du module m2 comporte un fichier entête C2Impl.h déclarant la fonction hello request received implémentant l'opération op2, car cette dernière réalise le service s. Au cours d'une étape 310 (illustrée en détail sur la figure 5), pour chaque module, le programme de déploiement 108 génère, à partir de la description fonctionnelle 200, une API de l'extension au conteneur générique pour le module. Plus précisément, pour chaque référence à un service utilisée par le module, cette API déclare une fonction destinée à contacter le service référencé. Dans l'exemple décrit, l'API de l'extension au conteneur générique pour le module ml comporte un fichier entête Cl Impl containerh déclarant la fonction hello request sync destinée à contacter le service s. L'API de l'extension au conteneur générique pour le module m2 comporte un fichier entête C2Impl container.h sans déclaration de fonction spécifique à l'exemple décrit car le module m2 n'utilise pas de service. Au cours d'une étape 312 (illustrée en détail sur la figure 6), pour chaque module, le programme de déploiement 108 génère, à partir de la description fonctionnelle 200, du code source implémentant l'extension au conteneur générique pour le module. Ce code source est écrit dans le langage du module. Ce code source implémente en particulier les fonctions déclarées dans l'API de l'extension. Dans l'exemple décrit, le code source de l'extension pour le module ml comporte un fichier Climpl containerc implémentant la fonction hello request sync. Le code source de l'extension pour le module m2 comporte un fichier C2Impl container.c. Au cours d'une étape 314 (illustrée en détail sur la figure 7), pour chaque partie pl, p2 de l'application « hello world », le programme de déploiement 108 compile le code source implémentant le conteneur générique, le code source implémentant l'extension au conteneur générique et le code source implémentant le module, pour obtenir du code machine implémentant la partie pl, p2. Dans l'exemple décrit, le code machine est sous la forme d'une librairie contenue dans un fichier libC1Impl.so pour la partie pl et dans un fichier libC2Impl.so pour la partie p2. Au cours d'une étape 316, le programme 108 transmet à chaque ordinateur Ml, M2 une requête de création de processus. De manière générale, chaque processus est destiné à accueillir une ou plusieurs parties de l'application déployée. Au cours d'une étape 318, en réponse à la requête, les ordinateurs Ml, M2 créent respectivement les processus Exl, Ex2. Au cours d'une étape 320, pour chaque partie pl, p2 de l'application « hello world », le programme de déploiement 108 commande à l'ordinateur Ml, M2 destiné à exécuter cette partie pl, p2 d'après la description fonctionnelle 200, d'exécuter le code machine de cette partie pl, p2. Dans l'exemple décrit, pour réaliser cette étape 320, le programme de déploiement 108 envoie à chaque ordinateur la librairie implémentant la partie que cet ordinateur doit exécuter. Ainsi, le programme de déploiement 108 envoie le fichier libCilmpl.so à l'ordinateur M1 et le fichier libC2Impl.so à l'ordinateur M2. En outre, le programme de déploiement 108 demande à chaque ordinateur Ml, M2 d'exécuter la librairie libCilmpl.so, /ibC2lmpl.so envoyée en tant que processus léger dans le processus Ex1, Ex2 précédemment créé. Au cours d'une étape 322, en réponse à la commande, chaque ordinateur Ml, M2 exécute le code machine reçu en le chargeant en tant que processus léger dans le processus précédemment créé. Ainsi, l'ordinateur M1 exécute la partie pl de l'application « hello world » tandis que l'ordinateur M2 exécute la partie p2. Au cours d'une étape 324, lors de l'exécution des parties pl, p2, chaque conteneur contl, cont2 ouvre une voie de communication vl, v2 sur l'ordinateur Ml, M2 l'exécutant afin de pouvoir recevoir des messages depuis le réseau 122. Les voies de communication vl, v2 comportent par exemple des ports de communication de l'ordinateur Ml, M2. Au cours d'une étape 326, chaque conteneur contl, cont2 indique au programme de déploiement 108 la voie de communication vl, v2 qu'il a ouvert pour recevoir des messages. Au cours d'une étape 328, le programme de déploiement 108 reçoit les indications de voie de communication et configure des liaisons entre les parties pl, p2 de l'application « hello world » en fonction du ou des liens de service indiqués 35 dans la description fonctionnelle 200. Plus précisément, le programme de déploiement 108 indique, à chaque conteneur associé à un module utilisant un service, la voie de communication utilisée par le conteneur associé au module réalisant le service. Dans l'exemple décrit, le programme de déploiement 108 indique au conteneur contl la voie de communication v2 utilisée par le conteneur cont2. Une fois l'application « hello world » déployée, pour requérir le service s, le module ml appelle la fonction hello request sync de son conteneur associé contl. Ce dernier transmet alors la requête au conteneur cont2 par la voie de communication v2. En réponse à la réception de la requête, le conteneur cont2 appelle la fonction hello request received du module m2. Ce dernier exécute la fonction hello request received et réalise le service s, c'est-à-dire affiche « hello world » sur un dispositif d'affichage. La figure 8 illustre l'installation 100 avec l'application « hello world » déployée entre les ordinateurs Ml, M2 à la fin du procédé 300 de la figure 3. Il apparaît clairement qu'un procédé de déploiement tel que celui décrit précédemment permet d'obtenir des parties d'application homogènes, c'est-à-dire provenant de code source écrit dans un même langage de programmation. On notera par ailleurs que l'invention n'est pas limitée au mode de réalisation décrit précédemment. Il apparaîtra en effet à l'homme de l'art que diverses modifications peuvent être apportées au mode de réalisation décrit ci-dessus, à la lumière de l'enseignement qui vient de lui être divulgué. Par exemple, le programme de déploiement pourrait obtenir l'implémentation des conteneurs génériques directement sous forme compilée (avant édition des liens), plutôt que sous la forme de code source. Dans les revendications qui suivent, les termes utilisés ne doivent pas être interprétés comme limitant les revendications au mode de réalisation exposé dans la présente description, mais doivent être interprétés pour y inclure tous les équivalents que les revendications visent à couvrir du fait de leur formulation et dont la prévision est à la portée de l'homme de l'art en appliquant ses connaissances générales à la mise en oeuvre de l'enseignement qui vient de lui être divulgué. REVENDICATIONS1. Procédé de déploiement d'une application pour obtenir l'exécution de parties (p1, p2) de l'application sur respectivement des ordinateurs (M1, M2) en réseau, chaque partie (p1, p2) de l'application comportant un conteneur (contl , cont2) et un module (m1, m2) associé, au moins un module (m1) étant destiné à envoyer un message au travers de son conteneur associé (contl) et au moins un module (m2) étant destiné à recevoir le message au travers de son conteneur associé (cont2), le procédé comportant : pour chaque partie (p1, p2) de l'application, la compilation de code source (ClImpl.c, C2Impl.cpp) implémentant le module (m1, m2) et de code source (container.c, Cl Impl container.c, container.cpp, C2Impl container.cpp) implémentant le conteneur (contl, cont2), pour obtenir du code machine (libC1Impl.so, libC2Impl.so) de cette partie (p1, p2) de l'application, et la commande de l'exécution du code machine (libC1Impl.so, libC2Impl.so) de chaque partie (p1, p2) de l'application par l'ordinateur (M1, M2) destiné à exécuter cette partie (p1, p2) de l'application, dans lequel le code source (container.c, Cl Impl container.c) implémentant le conteneur (contl) et le code source (C1 Impl.c) implémentant le module (m1) d'au moins une première partie (pl) de l'application sont écrits dans un même premier langage informatique (C) et dans lequel le code source (container.cpp, C2Impl container.cpp) du conteneur (cont2) et le code source (C2lmpl.cpp) du module (m2) d'au moins une seconde partie (p2) de l'application sont écrits dans un même second langage informatique (C++), différent du premier langage informatique (C). 2. Procédé de déploiement d'une application selon la revendication 1, comportant : l'obtention d'une description fonctionnelle (200) de l'application, indiquant : - les modules (m1, m2) de l'application, - pour chaque module, au moins un service (s), soit utilisé par le module (m1), soit réalisé par le module (m2),pour chaque module (ml, m2), la génération d'au moins une partie du code source (ClImpl container.c, C2lmpl_container.cpp) implémentant le conteneur associé (contl , cont2) à partir de la description fonctionnelle, ce code source (C1 Impl container.c, C2lmpl_container.cpp) comportant, pour chaque service (s) utilisé par le module (m1), une fonction (hello request sync) destinée à contacter le conteneur (cont2) associé au module (m2) réalisant le service (s) et, pour chaque service (s) réalisé par le module (m2), un appel à une fonction (hello request received) du module (m2) implémentant le service (s). 3. Procédé de déploiement d'une application selon la revendication 2, dans lequel la description fonctionnelle (200) indique en outre : pour chaque module (ml, m2), le langage de programmation (C, C++) de ce module (ml, m2), et dans lequel, pour chaque module (ml, m2), le code source (container.c, Cl Impl container.c, container.cpp, C2lmpl_container.cpp) implémentant le conteneur associé (contl , cont2) est généré dans le langage de programmation (C, C++) du module (ml, m2) tel qu'indiqué dans la description fonctionnelle (200). 4. Procédé de déploiement d'une application selon la revendication 2 ou 3, dans lequel la description fonctionnelle (200) est écrite dans un langage à balises, tel que le langage XML. 5. Procédé de déploiement d'une application selon l'une quelconque des revendications 2 à 4, comportant en outre : pour chaque conteneur (contl , cont2) associé à un module (m1) réalisant un service (s), la réception d'une indication d'une voie de communication (v1, v2) ouverte sur l'ordinateur exécutant le conteneur (contl , cont2), par laquelle le conteneur (contl , cont2) est apte à recevoir des messages, l'indication à chaque conteneur (contl ) associé à un module (m1) utilisant un service (s), de la voie de communication (v2) par laquelle le conteneur (cont2) associé au module (m2) réalisant le service (s) est apte à recevoir des messages. 6. Procédé de déploiement d'une application selon l'une quelconque des revendications 1 à 5, comportant en outre :- la transmission à chaque ordinateur (M1, M2) d'une requête de création de processus (Exl , Ex2), et dans lequel la commande de l'exécution du code machine (libC1Impl.so, libC2Impl.so) de chaque partie (p1, p2) comporte la commande de charger le code machine (libC1Impl.so, libC2Impl.so) de cette partie (p1, p2) en tant que processus léger du processus. 7. Programme d'ordinateur téléchargeable depuis un réseau de communication et/ou enregistré sur un support lisible par ordinateur et/ou exécutable par un processeur, caractérisé en ce qu'il comprend des instructions pour l'exécution des étapes d'un procédé de déploiement d'une application selon l'une quelconque des revendications 1 à 6, lorsque ledit programme est exécuté sur un ordinateur. 8. Système de déploiement d'une application pour obtenir l'exécution de parties (p1, p2) de l'application sur respectivement des ordinateurs (M1, M2) en réseau, chaque partie (p1, p2) de l'application comportant un conteneur (contl , cont2) et un module (m1, m2) associé, au moins un module (m1) étant destiné à envoyer un message au travers de son conteneur associé (contl) et au moins un module (m2) étant destiné à recevoir le message au travers de son conteneur associé (cont2), le système comportant : un dispositif destiné, pour chaque partie (p1, p2) de l'application, à compiler du code source (C1 Impl.c, C2Impl.cpp) implémentant le module (ml, m2) et du code source (container.c, Cl Impl container.c, container.cpp, C2Impl container.cpp) implémentant le conteneur (contl, cont2), pour obtenir du code machine (libC1Impl.so, libC2Impl.so) de cette partie (p1, p2) de l'application, et - un dispositif destiné à commander l'exécution du code machine (libC1Impl.so, libC2Impl.so) de chaque partie (pl, p2) de l'application par l'ordinateur (M1, M2) destiné à exécuter cette partie (p1, p2) de l'application, dans lequel le code source (container.c, Cl Impl container.c) implémentant le conteneur (contl) et le code source (C1 Impl.c) implémentant le module (m1) d'au moins une première partie (pl ) de l'application sont écrits dans un même premier langage informatique (C) et dans lequel le code source (container.cpp, C2Impl container.cpp) du conteneur (cont2) et le code source (C2lmpl.cpp) du module (m2) d'au moins une seconde partie (p2) de l'application sont écrits dans unmême second langage informatique (C++), différent du premier langage informatique (C). 9. Installation comportant : un système (102) de déploiement d'une application selon la revendication 8, les ordinateurs (M1, M2) sur lesquels les parties (p1, p2) de l'application sont destinées à être exécutées, un réseau (122) d'interconnexion du système de déploiement et des ordinateurs (M1, M2).