FR 3134204 A1 20231006 FR 2203056 A 20220404 L’invention concerne un procédé (100) d’intégration et d’exécution d’une application logicielle (A1) pour être mis en œuvre par une plateforme d’imagerie médicale (4, 41) opérant un système de fichiers (42). Un tel procédé (100) comporte une étape de lecture (110) d’un contrat (C1) dédié à une application logicielle (A1), ledit contrat comportant les chemins d’accès à des répertoires d’entrée et/ou de sortie dudit système de fichiers (42) pour écrire (120) et/ou lire (140) les valeurs de données d’entrée/de sortie de l’application logicielle (A1). L’invention concerne en outre une plateforme d’imagerie médicale adaptée pour mettre en œuvre un tel procédé (100) d’intégration et d’exécution d’applications logicielles (A1). Figure à publier avec l’abrégé : Fig 4 Procédé d’intégration et d’exécution d’une application mis en œuvre par une plateforme d’imagerie médicale L’invention concerne un procédé d’intégration et d’exécution d’une application d’analyse d’images médicales mis en œuvre par une plateforme d’imagerie médicale. Il est connu d’utiliser une plateforme d’imagerie médicale pour aider un praticien à identifier des pathologies en exploitant des images médicales acquises éventuellement selon différentes modalités par exemple via un appareil d’imagerie par résonance magnétique, également connue sous l’acronyme français IRM ou anglo-saxon MRI (pour « Magnetic Resonance Imaging »). Une telle plateforme d’imagerie médicale est conçue pour héberger une ou plusieurs applications logicielles généralement spécialisées pour identifier une pathologie donnée (accident vasculaire cérébral, pneumopathie, tumeur, etc.), analyser un organe déterminé (cerveau, poumon, sein, etc.) ou pour estimer des paramètres physiologiques ou hémodynamiques spécifiques (densité tissulaire, flux ou volumes sanguins, etc.). En milieu hospitalier, les images médicales sont générées depuis un ou plusieurs appareils d’imagerie médicale (IRM, scanners, etc.) et sont transmises auxdites plateformes ou archivées au sein de serveurs d’archivage et de transmission d’images également connus sous l’abréviation « PACS » de la dénomination anglo-saxonne « Picture Archiving and Communication System ». Les images médicales sont en outre encodées et transmises selon un protocole spécifique, connu sous le terme « DICOM » acronyme anglo-saxon de « Digital Imaging and Communications in Medicine », pour faciliter les transferts d'images médicales entre les appareils et systèmes d’imagerie de différents constructeurs. Une plateforme d’imagerie médicale héberge ainsi une pluralité d’applications logicielles pour traiter une pluralité de cas (en termes de pathologies, organes, modalités d’acquisition). Le format DICOM permet d’associer des méta-informations complémentaires aux images en tant que telles à partir desquelles une plateforme d’imagerie médicale « décide » de lancer l’exécution de telle ou telle application logicielle. Les plateformes actuellement disponibles ne peuvent toutefois comporter à tout instant l’ensemble des applications logicielles pour répondre à une diversité de cas en croissance constante, ni même les toutes dernières versions desdites applications logicielles pour bénéficier continuellement des nombreuses innovations dans ce domaine. Il est donc nécessaire d’enrichir ou de mettre à jour la pluralité d’applications logicielles au sein des plateformes d’imagerie médicale déployées sur les sites. D’un point de vue technique, une plateforme d’imagerie médicale s’apparente à un ordinateur comportant une unité de traitement consistant en un ou plusieurs microprocesseurs ou microcontrôleurs mettant en œuvre des instructions de programmes d’un système d’exploitation de ressources matérielles (mémoires de données ou de programmes, périphériques, etc. ) et des applications logicielles hébergées. Lesdites instructions de programme sont chargées dans une ou plusieurs mémoires de ladite plateforme en communication avec ladite unité de traitement. On entend par « mémoire ou moyen de mémorisation » toute mémoire informatique que celle-ci soit volatile ou non. Une mémoire non volatile est une mémoire informatique dont la technologie permet de conserver ses données en l’absence d’une alimentation en énergie électrique. Elle peut contenir des données résultant de saisies, de calculs, de mesures et/ou des instructions de programmes. Les principales mémoires non volatiles actuellement disponibles sont de type inscriptible électriquement, telles que l’EPROM (« Erasable Programmable Read- Only Memory », selon une terminologie anglo-saxonne) ou encore inscriptibles et effaçables électriquement, telle que l’EEPROM (« Electrically-Erasable Programmable Read- Only Memory ), flash, SSD (« Solid-State Drive », selon une terminologie anglo-saxonne), etc. Les mémoires non volatiles se distinguent des mémoires dites « volatiles » dont les données sont perdues en l’absence d’une alimentation électrique. Les principales mémoires volatiles actuellement disponibles sont de type RAM (« Random Access Memory » selon une terminologie anglo-saxonne ou encore nommée « mémoire vive »), DRAM (mémoire vive dynamique, nécessitant une réactualisation régulière), SRAM (mémoire vive statique nécessitant une telle réactualisation lors d’une sous-alimentation électrique), DPRAM ou VRAM (particulièrement adaptées à la vidéo), etc. Les plateformes d’imageries médicales connues présentent ou imposent des modes d’intégration des applications logicielles. Le mode d’intégration le plus répandu exploite le standard DICOM. Selon ce mode, toute application logicielle est conçue pour ne traiter que des données d’entrée au format DICOM et pour ne délivrer que des résultats selon ce même format, lesdites données devant en outre respecter un protocole de transmission spécifique. Ce premier mode d’intégration présente toutefois des inconvénients majeurs. Tout d’abord, le format et le protocole DICOM ne sont pas optimaux pour produire et partager un rapport à partir de résultats intermédiaires produits par d’autres applications logicielles. En outre, le standard DICOM ne permet pas de pouvoir configurer aisément des applications logicielles selon certains contextes de réception et/ou d’exploitation des données d’imagerie à analyser. D’autres plateformes connues ont opté pour un deuxième mode d’intégration basé sur l’exploitation d’interfaces de programmation d’applications également connues sous l’abréviation API de l’expression anglo-saxonne « Application Programming Interface ». Cette solution est avantageuse car elle facilite l’accès aux services de configuration pour lesdites applications logicielles et ouvre de nombreuses possibilités d’exportation de résultats. En revanche, ce deuxième mode présente généralement un inconvénient majeur induit par le fait qu’une API est généralement spécifique ou dédiée à une plateforme d’imagerie médicale donnée ou à un constructeur donné de telles plateformes. Pour pouvoir développer une application intégrable sur une première plateforme d’imagerie médicale, le concepteur de l’application doit connaître l’API requise par ladite première plateforme et construire son application autour de cette API. Si ladite application doit être intégrée sur une deuxième plateforme requérant une deuxième API distincte de la première, ledit concepteur doit modifier la conception de son application et produire une deuxième application logicielle. En outre, il est délicat voire impossible pour ledit concepteur de tester le bon fonctionnement d’une application avant son émission en l’absence d’une plateforme de test tenue à sa disposition. Il doit pour cela disposer d’un émulateur de ladite plateforme ou d’un « bouchon » pour simuler le comportement de celle-ci, ce qui n’est pas toujours le cas ou peut s’avérer complexe ou onéreux. L’invention répond aux inconvénients soulevés par l’état de la technique. Parmi les nombreux avantages procurés par l’invention, nous pouvons mentionner plus particulièrement que l’invention permet de concevoir des applications logicielles indépendamment d’une plateforme d’imagerie médicale particulière. Grâce à l’invention, lesdites applications logicielles peuvent exploiter et/ou produire des données conformes au standard DICOM ou selon tout autre format. Ainsi, les applications logicielles sont intégrées dans une plateforme d’imagerie médicale sous la forme de modules applicatifs autonomes spécifiant leurs dépendances dont les entrées et sorties sont lues ou écrites sur le système de fichiers qu’opère toute plateforme d’imagerie médicale. L’invention procure ainsi une très grande interopérabilité ne liant plus, comme c’est encore le cas aujourd’hui, une application à un type de plateforme donné. En outre, un concepteur d’une application a la capacité de tester très facilement le fonctionnement de son application avant l’émission de celle-ci sans nécessiter l’acquisition ou l’immobilisation d’une plateforme d’imagerie médicale à des fins de déverminage, d’un simulateur/émulateur de celle-ci ou encore d’un bouchon sophistiqué ou en variante, trop limité pour simuler l’intégralité des fonctionnalités d’une telle plateforme. Par la suite du document, on entend par « système de fichiers » également connu sous la terminologie anglo-saxonne « File System », les services opérés par une plateforme d’imagerie médicale ou par tout ordinateur, qui déterminent l’organisation des données accessibles en lecture ou en écriture au sein d’une mémoire, ou plus généralement au sein d'un volume physique ou logique d’une telle mémoire. Classiquement, un tel système de fichiers détermine la manière de stocker lesdites données et de les organiser dans des structures logiques, que l’on nomme « fichiers ». Un tel système de fichiers permet de traiter, conserver et partager des données entre plusieurs programmes informatiques tels qu’un système exploitation des ressources de l’ordinateur (ou en l’espèce d’une plateforme d’imagerie médicale) et les applications logicielles qui font appel auxdites ressources via ledit système d’exploitation. Un système de fichiers offre ainsi une vue abstraite des données stockées dans une mémoire et permet d’y accéder en lecture et/ou en écriture à partir d'un chemin d'accès également nommé « path » selon une terminologie anglo-saxonne. A cette fin, l’invention prévoit un procédé d’intégration et d’exécution d’une application logicielle, ledit procédé étant conçu pour être mis en œuvre par une plateforme d’imagerie médicale opérant un système de fichiers. Un tel procédé comporte : une étape de lecture d’un contrat dédié à une application logicielle qui produit une donnée de sortie à partir d’une donnée d’entrée, ledit contrat consistant en un contenu numérique comportant : un identifiant unique désignant ladite application logicielle ; un répertoire virtuel d’entrée destiné à contenir une valeur de la donnée d’entrée de l’application logicielle ; un répertoire virtuel de sortie destiné à contenir une valeur de la donnée de sortie de l’application logicielle; une étape d’écriture de la valeur de la donnée d’entrée de l’application logicielle dans un répertoire d’entrée du système de fichiers ; une étape de lancement de l’exécution de l’application logicielle désignée par l’identifiant unique avec comme arguments les chemins d’accès au répertoire d’entrée du système de fichiers et à un répertoire de sortie dudit système de fichiers, lesdits chemins d’accès étant associés respectivement aux répertoires virtuels d’entrée et de sortie lus dans ledit contrat ; une étape de lecture de la valeur de la donnée de sortie de l’application logicielle dans le répertoire de sortie du système de fichiers. Pour permettre de paramétrer aisément l’exécution d’une application logicielle, le contrat peut comporter une valeur d’un paramètre de fonctionnement de ladite application logicielle. Dans ce cas, l’étape de lancement de l’exécution de ladite application logicielle d’un procédé conforme à l’invention peut être adaptée pour comporter comme argument la valeur dudit paramètre de fonctionnement. Pour réaliser l’intégration d’une application logicielle, un procédé selon l’invention peut comprendre une étape de chargement de l’application logicielle et du contrat dans une mémoire de la plateforme logicielle. De manière avantageuse et faciliter notamment le test préalable d’une application logicielle, cette dernière peut se présenter sous la forme d’un conteneur informatique, l’identifiant unique désignant ladite application logicielle compris dans ledit contrat exprimant l’image dudit conteneur informatique. A titre avantageux, le répertoire virtuel d’entrée destiné à contenir la donnée d’entrée de l’application logicielle peut être associé dans le contrat à un attribut précisant le caractère optionnel ou obligatoire de ladite donnée d’entrée. Dans ce cas, lorsqu’un tel attribut atteste un caractère optionnel de ladite donnée d’entrée, l’étape d’écriture de cette dernière peut n’être mise en œuvre que si une telle donnée d’entrée est disponible pour la plateforme d’imagerie médicale. L’invention prévoit également d’enrichir en méta-informations une donnée de de sortie produite par une application logicielle intégrée et exécutée selon l’invention. Pour cela, le répertoire virtuel de sortie destiné à contenir la valeur de la donnée de sortie de l’application logicielle peut être associé dans le contrat à un attribut de typage de ladite sortie. L’étape de lecture de la valeur de la donnée de sortie de l’application logicielle peut alors consister à associer ladite valeur dudit attribut de typage à la valeur de ladite donnée de sortie. Pour préserver toute modification malveillante d’un contrat associé à une application logicielle, ledit contrat peut être encodé préalablement à son intégration dans la plateforme, voire après toute mise à jour de ce dernier par ladite plateforme. Dans ce cas, l’étape de lecture d’un contrat peut comporter une sous-étape préalable de décodage dudit contrat. Selon un deuxième objet, l’invention concerne un produit programme d’ordinateur comportant des instructions de programme exécutables par l’unité de traitement d’un ordinateur, lesdites instructions de programme étant chargeables dans une mémoire non volatile dudit ordinateur et dont l’exécution par ladite unité de traitement provoque la mise en œuvre d’un procédé d’intégration et d’exécution d’une application logicielle selon l’invention. Selon un troisième objet, l’invention concerne en outre un support de mémorisation lisible par un ordinateur comportant les instructions d’un tel produit programme d’ordinateur. Enfin, l’invention concerne en outre une plateforme d’imagerie médicale comprenant une unité de traitement, une mémoire exploitée par un système de fichiers, ladite mémoire comprenant les instructions de programme d’un produit programme d’ordinateur selon l’invention. D’autres caractéristiques et avantages apparaîtront plus clairement à la lecture de la description qui suit et à l'examen des figures qui l'accompagnent parmi lesquelles : illustre un système d’imagerie médicale comprenant une plateforme d’imagerie médicale ; illustre l’architecture simplifiée d’une plateforme d’imagerie médicale conforme à l’invention ; illustre un exemple de conception d’une application logicielle intégrable et exécutable par une plateforme d’imagerie médicale conforme à l’invention ; illustre un procédé d’intégration et d’exécution d’une application logicielle par une plateforme d’imagerie médicale conforme à l’invention. La illustre un exemple d’un système d’imagerie médicale S comportant un appareil d'imagerie 1. Celui-ci délivre une pluralité de séquences d'images numériques 12 d'une ou plusieurs parties du corps d'un patient, à titre d'exemples non limitatifs, le cerveau, le cœur, les poumons. L'appareil d'imagerie par résonance magnétique 1 est généralement commandé à l'aide d'une console 2. Un utilisateur 6, par exemple un opérateur, praticien ou chercheur, peut ainsi choisir des commandes 11 pour piloter l'appareil d’imagerie 1 à partir de paramètres ou de consignes 16 saisis via une interface homme-machine d'entrée 8 du système d'analyse S. Une telle interface homme-machine 8 peut consister par exemple en un clavier informatique, un dispositif de pointage, un écran tactile, un microphone ou, plus généralement, toute interface agencée pour traduire une gestuelle ou une consigne émise par un humain 6 en données de commande ou de paramétrage d’un appareil d’imagerie 1. A partir d'informations 10 produites par ledit appareil 1, on obtient une pluralité de séquences d'images numériques 12 d'une partie d'un corps d’un humain ou d’un animal. Les séquences d'images 12 peuvent optionnellement être stockées au sein d'un serveur 3 ou PACS, c'est-à-dire un ordinateur doté de moyens de mémorisation propres et constituer un dossier médical 13 d'un patient. Un tel dossier 13 peut comprendre des images de différents types, telles que des images fonctionnelles mettant en évidence l'activité des tissus ou des images anatomiques reflétant les propriétés des tissus. Les séquences d'images 12 ou, plus généralement les données expérimentales, sont analysées par une plateforme d’imagerie médicale 4 agencée à cette fin pour produire des indicateurs textuels ou graphiques 14 visualisables via une interface homme-machine de sortie 5 par un personnel de santé 6 selon des consignes 16 adressées à ladite plateforme d’imagerie médicale 4. La décrit un exemple d’architecture d’une plateforme d’imagerie médicale 4 conforme à l’invention et destinée à être intégrée dans un système d'analyse d'imagerie tel que le système S illustré par la . Une telle plateforme d’imagerie médicale 4 peut comporter une unité de traitement sous la forme d’un ou plusieurs microprocesseurs ou microcontrôleurs 41 mettant en œuvre des instructions de programmes d'applications idoines chargées dans des moyens de mémorisation ou mémoire 45 dudit système d'analyse d'imagerie S. L’accès en lecture et/ou écriture à ladite mémoire 45 par l’unité de traitement 41 peut être régi par un système de fichiers 42. Ladite unité de traitement 41 est avantageusement en communication avec un module d’entrée/sortie 43 chargé notamment de réceptionner les séquences d’images médicale 12, voire avec un module 44 chargé de déterminer, à partir desdites séquences d’images 12 réceptionnées, quelle est ou quelles sont les applications logicielles parmi des applications logicielles disponibles A1, A2, An qui méritent d’être mises en œuvre pour analyser lesdites séquences d’images 12 dans le but de produire des quantités d’intérêt pertinentes 14 à destination des personnels de santé 6. Lesdites applications logicielles A1 à An sont préalablement, ou plus précisément les instructions de programmes qui les caractérisent, chargées en mémoire 45 de la plateforme 4. Comme nous l’étudierons ultérieurement chaque application logicielle A1, A2, An est associée à un contenu numérique distinct de ladite application logicielle et qui est dédié à cette dernière, contenu numérique que nous nommons dans la suite « contrat » C1, C2, Cn. Ainsi, conjointement au chargement des instructions de programme de l’application logicielle A1, un contrat C1 sous la forme d’un contenu numérique comportant des informations exploitables ou interprétables par l’unité de traitement 41, plus précisément selon un procédé 100 d’intégration et d’exécution d’applications logicielles conforme à l’invention. Pour adapter le fonctionnement de la plateforme d’imagerie médicale 4, un programme d’ordinateur comportant les instructions exécutables par l’unité de traitement 41 de ladite plateforme 4 est chargé dans la mémoire 45, lesdites instructions de programme provoquant la mise en œuvre d’un tel procédé d’intégration et d’exécution 100. La illustre un exemple de description fonctionnelle d’une application logicielle au sens de l’invention. Une telle application logicielle consiste en un traitement numérique portant sur une ou plusieurs données d’entrée pour produire une ou plusieurs données de sortie. A titre d’exemple, une telle première application logicielle peut consister en une application visant à catégoriser un flux d’images DICOM 12 acquises par un appareil d’imagerie à rayons X et produire des données de sortie triées par type, lesdites images étant enrichies par un ou plusieurs labels visant à qualifier lesdites images. De tels label pourraient être choisis parmi un ensemble d’acronymes « CTP », « CTA », « NCCT » d’expressions anglo-saxonnes « c omputed t omography p erfusion », « c omputed t omography a ngiography », « n on- c ontrast c omputed t omography » qualifiant des modalités d’acquisition. En variante, une telle première application logicielle pourrait exploiter des données d’entrée sous la forme d’images DICOM labélisées « CTP » et produire en sortie des données de sortie sous la forme de cartes illustrant un paramètre hémodynamique et un rapport de résultat exprimé sous une forme textuelle et destiné à être communiqué in f ine par courriel. Une deuxième application logicielle pourrait être conçue pour exploiter des données d’entrée sous la forme d’un flux 12 d’images DICOM acquises à partir d’un appareil d’imagerie à résonnance magnétique et produire des données de sortie triées par types, lesdites images étant enrichies par un ou plusieurs labels visant à qualifier lesdites images. De tels label pourraient être choisis parmi un ensemble d’acronymes « DWI », « PWI », « FLAIR » d’expressions anglo-saxonnes « diffusion- weighted i maging », « perfusion- weighted o maging », « f luid-attenuated inversion recovery » qualifiant des modalités d’acquisition de l’appareil d’imagerie. De manière générale et comme l’illustre la , une application logicielle A1 produit des données de sortie OD1, …, ODj à partir de données d’entrée ED1, …, EDi. Lesdites données d’entrée et/ou de sortie peuvent respectivement être de différents formats, par exemple de types textuel, DICOM ou autres. Une application logicielle A1 peut en outre exploiter une ou plusieurs variables d’environnement E1, …, Ek. De telles variables d’environnement sont transmises à l’application logicielle lors de l’exécution de celle-ci dans le but de paramétrer ladite exécution de l’application logicielle ou les traitements mis en œuvre par celle-ci. Selon un mode de réalisation préférée, l’application A1 peut être définie sous la forme d’un conteneur informatique dont l’image se présente sous la forme d’un fichier statique refermant un code (c’est-à-dire un ensemble d’instructions de programme) exécutable et définissant les paramètres ou dépendances nécessaires à son exécution. Un tel choix technique de « conteneurisation » des applications logicielles permet notamment de simplifier l’étape de test du fonctionnement d’une application logicielle avant son déploiement sans pour autant nécessiter une configuration de test proche d’une plateforme d’imagerie médicale. En effet, le « pattern » de l’application logicielle est clairement défini, l’image du conteneur peut être mise en œuvre et testée telle un module applicatif autonome à l’instar d’une machine virtuelle légère et modulaire. Prenons l’exemple de la technologie « Docker » initialement conçue pour traiter les conteneurs Linux (famille de systèmes d'exploitation « open source » de type Unix (AT&T) créée par Linus Torvalds. Supposons que l’identificateur AID de l’image de l’application logicielle A1 illustrée par la désigne la version 1.0 de l’application logicielle « my_application ». Une exécution de ladite application logicielle A1 par un ordinateur pourrait être provoquée en invoquant manuellement la commande : « d ocker run \ - v / tmp /inputs/ED1 :/inputs/ED1 \ ( arg 1 ) - v / tmp /inputs/ED1:/inputs/ EDi \ ( arg 2) - v / tmp /outputs/OD1:/outputs/OD1 \ ( arg 3 ) - v / tmp /outputs/ ODj :/outputs/ ODj \ ( arg 4 ) - e E1=VALUE1 \ ( arg 5 ) - e E k = VALUE k \ ( arg 6 ) my_application:1.0 » ( arg 7) L’argument (arg1) de la commande permet de définir ou résoudre un lien (opération également connue sous le vocable de « mapping » selon une terminologie anglo-saxonne) entre l’emplacement ou répertoire « physique » DED1 de la donnée d’entrée ED1 (en l’espèce selon l’exemple illustré par la un répertoire temporaire du système de fichier 45 d’une plateforme 4 d’imagerie médicale ou plus généralement d’un ordinateur de développement ou de test) ledit répertoire DED1 étant accessible par le chemin d’accès DPED1 « /tmp/inputs/ED1 » et le répertoire « virtuel » VDED1 (en l’espèce sur l’exemple illustré par la , le répertoire virtuel « /inputs/ED1 ») défini par le concepteur de l’application A1 dans le module applicatif. Ainsi, lorsque ladite application logicielle A1 est exécutée, cette dernière lit la valeur de la donnée d’entrée ED1 dans le répertoire virtuel VDED1 « /inputs/ED1 » alors que physiquement, c’est-à-dire dans la mémoire 45 de la machine 4 mettant en œuvre ladite application logicielle A1, ledit répertoire virtuel correspond à un répertoire physique DED1 choisi par ledit utilisateur, en l’espèce le répertoire dont le chemin d’accès DPED1 est « /tmp/inputs/ED1 ». De la même manière, les arguments (arg2), (arg3) et (arg4) définissent, respectivement pour les données EDi, OD1 et ODj, les liens entre les répertoires virtuels VDEDi « /inputs/EDi », VDOD1 « /outputs/OD1 », VDODj « /outputs/ODj » et les répertoires physiques DEDi « /tmp/inputs/EDi », DOD1 « /outputs/OD1 » et DODj « /outputs/ODj ». Les arguments (arg5) et (arg6) permettent de transmettre à l’application A1 les valeurs VALUE1 et VALUEk respectivement aux variables d’environnement E1 et Ek. Enfin l’argument (arg7) de la commande désigne l’identifiant AID de l’image de l’application A1, en l’espèce « my_application » de version 1.0. L’invention ne saurait être limitée à ce seul choix d’implémentation d’une application logicielle sous la forme d’un conteneur ou de la technologie « Docker ». En variante, elle pourrait s’appuyer sur une solution équivalente telle que la solution « podman » développée par Red Hat. Une application logicielle pourrait également consister en un programme exécutable « classique » en lieu et place d’un conteneur. Dans tous les cas, pour être exploitée par un procédé d’intégration et d’exécution d’applications logicielles conforme à l’invention tel que le procédé 100 dont un exemple de mise en œuvre est illustré par la , une application logicielle, telle que l’application A1 décrite par la , est associée à un contenu numérique tiers C1, nommé contrat. Par l’exploitation de ce dernier, par exemple par le module 44 illustré en , l’exécution d’une application logicielle peut être déclenchée en désignant cette dernière de manière non ambigüe, en résolvant les liens entre les emplacements physiques DED1, DEDi des données d’entrées ED1, EDi, les emplacements physiques DOD1, DODj des données de sortie OD2, ODj sur la plateforme d’imagerie 4 et les emplacements virtuels ou « internes » VDED1, VDEDi, VDOD1, VDODj au module applicatif, voire en définissant des valeurs à des variables d’environnement E1 à Ek. C’est l’exploitation conjointe de ce contrat C1 et du système de fichiers 42 qui permet de faciliter l’intégration et l’exécution d’une application logicielle. Ainsi, en liaison avec la et la , un contrat C1 comporte un ensemble de champs ou d’éléments, distinguables les uns et d’autres par exemple par des balises ou tout autre moyen technique équivalent, afin que préalablement à l’exécution en tant que telle d’une application logicielle éventuellement paramétrée par des variables d’environnement E1, Ek, les valeurs des données d’entrées ED1, EDi soient inscrites dans des emplacements de la mémoire 45 via le système de fichiers 42 et qu’à l’issue de l’exécution de ladite application logicielle A1, les données de sortie OD1 et ODj produites par celle-ci puissent être exploitées par ladite plateforme 4. Le contrat C1, associé à l’application logicielle A1 peut avantageusement comprendre : l’identifiant unique AID de l’application logicielle A1, en l’espèce sur la , l’image du conteneur ; les valeurs EV1 et EVk à assigner respectivement aux variables d’environnement E1 et Ek lors de l’exécution de ladite application logicielle A1; les répertoires virtuels d’entrée VDED1, VDEDi destinés à contenir, les valeurs des données d’entrée ED1, EDi de l’application logicielle A1 ; les répertoires virtuels de sortie VDOD1, VDODj destinés à contenir les valeurs des données de sortie OD1, ODj de l’application logicielle A1. Plus généralement, un tel contrat C1 comporte par donnée d’entrée ED1, EDi ou de sortie OD1, ODj, les emplacements virtuels VDED1, VDEDi, VDOD1, VDODj pour écrire/lire une valeur de ladite donnée d’entrée ED1, EDi ou de sortie OD1, ODj. La présence d’une valeur EV1, EVk à assigner à une variable d’environnement est optionnelle, certaines applications logicielles ne nécessitant de tels paramètres de fonctionnement comme par exemple pour sélectionner une palette de couleurs parmi une pluralité ou encore un référentiel d’unités. Le format d’un contrat est imposé par la plateforme d’imagerie médicale de sorte que celle-ci puisse avoir la capacité d’exploiter (c’est-à-dire lire et éventuellement mettre à jour) ledit contrat C1. En revanche, le contenu dudit contrat C1 est imposé par l’application logicielle selon les données d’entrée, de sorties/variables d’environnement qu’elle nécessite. Après installation de l’application logicielle et de son contrat en mémoire 45 de la plateforme d’imagerie médicale 4, il revient à l’opérateur de la plateforme ou à la plateforme en tant que telle, de modifier et/ou paramétrer ledit contrat C1 par exemple en inscrivant les chemins d’accès physique DPED1, DPDEi, DPOD1, DPODj aux répertoires DED1, DEDi, DOD1, DODj du système de fichiers 42 régissant la mémoire 45 de ladite plateforme 4 pour stocker les données d’entrée ED1, EDi et de sortie OD1, ODj de ladite application A1 si lesdits répertoires d’entrée DED1, DEDi et de sortie DOD1, DODj sont immuables, ainsi que pour fixer les valeurs de variables d’environnement EV1, EVk si elles existent ou sont requises. De manière préférée, lesdits chemins d’accès DPED1, DPDEi, DPOD1, DPODj ne sont pas inscrits dans le contrat C1 de sorte à laisser la plateforme d’imagerie 4 le soin d’allouer des répertoires temporaires DED1, DEDi, DOD1, DODj préalablement à l’exécution en tant que telle de l’application A1. La résolution des liens entre les répertoires virtuels VDE1, VDEi, VDO1, VDOj et les répertoires physiques DED1, DEDi, DOD1, DODj est réalisée par les arguments de la commande d’exécution comme illustré précédemment en lien avec l’application « my_application ». Nous pouvons parler d’une étape de configuration de l’application logicielle A1 à l’issue de son installation ou chargement en mémoire 45 pour qualifier ladite mise à jour optionnelle du contrat C1. La permet d’illustrer la mise en œuvre et la description fonctionnelle d’un procédé 100 d’intégration et d’exécution d’une application logicielle conforme à l’invention. Un tel procédé 100 est mis en œuvre par une plateforme d’imagerie médicale telle que la plateforme 4 selon la et la . Le fonctionnement de cette dernière est adapté par l’implantation dans la mémoire 45 d’un programme d’ordinateur dont les instructions de programme provoquent, lors de leur exécution par l’unité de traitement 41 sous le contrôle éventuel d’un module décisionnel 44, la mise en œuvre d’un tel procédé 100. Supposons que la mémoire 45 comporte en outre l’application logicielle A1, par exemple sous la forme d’un conteneur associée à un contrat C1, ce dernier se présentant sous la forme d’un fichier texte structuré, c’est-à-dire agencé au moyen de balises idoines, à l’instar des application logicielle A1 et du contrat C1 d’ores et déjà décrits en lien avec la . La réception d’une séquence d’images médicales 12 exploitée par l’unité de traitement 41 déclenche la mise en œuvre du procédé 100 pour provoquer l’exécution de l’application logicielle A1 jugée pertinente. Les principales étapes dudit procédé 100 sont illustrées par des flèches pleines de couleur blanche sur la . Par ailleurs, les étapes d’un traitement propre à l’application logicielle A1 sont illustrées par des flèches pleines de couleur noire sur ladite . Cette dernière décrit en outre les interactions entre les « acteurs » principaux concernés par la mise en œuvre dudit procédé 100 (c’est-à-dire l’unité de traitement 41 de la plateforme 4, le système de fichiers 42 opéré par cette dernière, le contrat C1 et l’application logicielle A1). Ledit procédé 100 comporte une première étape de lecture 110 dans la mémoire 45 du contrat C1 dédié à l’application logicielle A1. Pour rappel cette dernière produit deux données de sortie OD1 et OD2 à partir de données d’entrée ED1 et ED2. Lorsque le contrat C1 comporte les chemins d’accès DPED1, DPEDi à des répertoires DED1, DEDi du système de fichiers 42 qui doivent être exploités pour respectivement initialiser des valeurs des données d’entrées ED1 et EDi, l’unité de traitement 41 connaît en réponse (symbolisée par une flèche en trait fin discontinu) lesdits chemins d’accès DPED1, DPEDi. De la même manière, lorsque le contrat C1 comporte les chemins d’accès DPOD1, DPODj à des répertoires DOD1, DODj du système de fichiers 42 qui doivent être exploités pour respectivement lire des valeurs des données de sortie OD1 et ODj qui seront produites par l’application logicielle A1, l’unité de traitement 41 connaît lesdits chemins d’accès DPOD1, DPODj. Ladite unité de traitement 41 peut également connaître en outre les variables d’environnement E1, Ek éventuellement exploitées par l’application logicielle A1 dont les valeurs EV1, EVk seront transmises lors de l’exécution en tant que telle de ladite application logicielle A1. En variante, selon un cas plus général, ledit contrat C1 n’a pas fait l’objet de modification ou de configuration par la plateforme d’imagerie médicale 4. L’étape 110 du procédé 100 comporte en outre une sous-étape (non représentée par mesure de simplification sur la ) d’allocation ou de détermination de répertoires temporaires DED1, DEDi du système de fichiers 42 qui doivent être exploités pour respectivement initialiser des valeurs des données d’entrées ED1 et EDi et des répertoires DOD1, DODj du système de fichiers 42 qui doivent être exploités pour respectivement lire des valeurs des données de sortie OD1 et ODj. Le procédé 100 comporte à présent une étape d’écriture 120 de la valeur de chaque donnée d’entrée ED1, EDi de l’application logicielle A1 dans le répertoire d’entrée DED1, DEDi du système de fichiers 42 tel que spécifié par ledit contrat C1 ou déterminé par la plateforme d’imagerie médicale 4. Ledit procédé 100 comporte une étape de lancement 130 de l’exécution de l’application logicielle A1 dont l’image est désignée par l’identifiant unique AID tiré de l’étape 110. Une telle étape 130 s’accompagne de la transmission éventuelle de valeurs de variables d’environnement lors que l’application logicielle le requiert, en l’espèce les valeurs EV1 et EVk des variables E1 et Ek. Pour résoudre les liens entre les répertoires d’entrée DED1, DEDi et de sortie DOD1, DODj physiques (c’est-à-dire ceux dont l’accès en lecture/écriture est régi par le système de fichiers) et les répertoires virtuels d’entrée VDED1, VDEDi et de sortie VDOD1, VDODj, l’étape 130 consiste en outre à transmettre les chemins d’accès DPED1, DPEDi, DPOD1, DPODj auxdits répertoires d’entrée DED1, DEDi et de sortie DOD1, DODj pour chaque donnée d’entrée ED1, EDi et de sortie OD1, ODj concernée. Cette étape 130 consiste ainsi à automatiquement constituer un équivalent de la commande manuelle évoquée précédemment en lien avec le test de l’application logicielle « my_application » sous la forme d’un conteneur, les arguments nécessaires à l’exécution de l’application étant transmis à ladite application logicielle conformément aux exigences (éléments, balises et/ou ordre) spécifiées par le contrat C1. Le procédé 100 demeure en attente du fruit de l’exécution de l’application logicielle A1 (via un compte rendu d’exécution 240 produit par cette dernière, symbolisé par une flèche en trait fin discontinu sur la ). En effet, à l’issue de l’étape 130, l’unité de traitement 41 met en œuvre l’application A1 qui comporte à son tour une première étape 210 visant à lire les valeurs des données d’entrée ED1 et EDi dans les répertoires DED1, DEDi du système de fichiers 42, puis met en œuvre un traitement 220 portant sur lesdites données d’entrée ED1, EDi pour produire des données de sorties OD1, ODj. Les liens entre les répertoires physiques (mémoire 45 / système de fichiers 42) et virtuels ayant été préalablement résolus par les arguments d’exécution transmis l’étape 130 conformément audit contrat C1, les valeurs desdites données de sortie sont inscrites par l’application logicielle A1 en une étape 230 dans les répertoires DOD1, DODj du système de fichiers 42. La mise en œuvre de l’application logicielle A1 se termine par une étape 240 d’élaboration d’un compte rendu d’exécution précisant par exemple si ladite exécution a été réalisée avec ou sans erreur. Un procédé 100 conforme à l’invention comporte à présent une étape de lecture 140 de la valeur de chaque donnée de sortie OD1, ODj de l’application logicielle A1 dans le répertoire de sortie DOD1, DODj du système de fichiers 42 tel que défini par le contrat C1 ou par la plateforme 4. A l’issue de la mise en œuvre du procédé d’intégration et d’exécution de l’application logicielle A1, la plateforme d’imagerie médicale 4 peut déclencher la mise en œuvre d’un traitement subséquent visant à exploiter le résultat produit par ladite application A1. Un tel traitement subséquent peut consister en une nouvelle occurrence dudit procédé 100 pour provoquer l’exécution d’un deuxième application logicielle A2, An. A titre avantageux, l’invention prévoit qu’une application logicielle A1, A2, An puisse gérer une donnée d’entrée ou une donnée de sortie présentant un caractère optionnel. Pour cela, le caractère optionnel peut être spécifié dans le contrat C1, C2, Cn qui est associé à ladite application A1, A2, An. Selon un mode de réalisation préféré, en liaison avec l’application A1 illustrée par la , le champ ou élément dudit contrat C1 déterminant le répertoire virtuel VDED1, VDEDi destiné à contenir une donnée d'entrée ED1, EDi peut être associé à un attribut précisant un caractère optionnel ou obligatoire de ladite donnée d'entrée ED1, EDi. Selon ce mode de réalisation, un procédé 100 selon l’invention est adapté de sorte que, lorsqu'un tel attribut atteste un caractère optionnel d’une donnée d'entrée ED1, EDi, l'étape d'écriture 120 de la valeur de cette dernière n'est mise en œuvre que si une telle donnée d'entrée ED1, EDi est disponible pour la plateforme d’imagerie médicale 4. Le lancement de l’exécution de l’application logicielle A1 ne provoquera pas d’erreur en l’absence d’argument dédié à une telle donnée optionnelle dans la commande 130. Un tel attribut peut ainsi consister en une valeur booléenne pour caractériser un tel caractère optionnel ou obligatoire d’une donnée d’entrée. En variante, l’absence d’un tel attribut peut signifier que ladite donnée d’entrée revêt un caractère obligatoire. Il en est de même pour une donnée de sortie OD1, ODj qui peut être optionnelle selon le résultat produit par une application logicielle telle que l’application A1 selon la . Selon ce mode de réalisation, le champ ou élément dudit contrat C1 déterminant le répertoire virtuel VDOD1, VDODj destiné à contenir une donnée de sortie OD1, ODi peut être associé à un attribut précisant le caractère optionnel ou obligatoire de ladite donnée de sortie OD1, ODj. Lorsqu'un tel attribut atteste un caractère optionnel de ladite donnée de sortie OD1, ODj, ce dernier peut comporter une valeur déterminée spécifiant une valeur de non-intérêt. De cette manière, l’unité de traitement 41 sait qu’il ne faut pas tenir compte d’une telle donnée de sortie si ladite donnée décrit une valeur égale à ladite valeur déterminée. Par ailleurs, l’invention prévoit d’ajouter une ou des méta-informations, telles qu’un label ou une étiquette ou, plus généralement un attribut de typage pour qualifier une donnée d’entrée ED1, EDi et/ou de sortie OD1, ODj d’une application logicielle telle que l’application A1 selon la . Lorsqu’une telle donnée de sortie OD1, ODj peut être enrichie ou qualifiée par la présence d’un label, le contrat C1 associé à ladite application logicielle A1 peut être agencé de sorte que le répertoire virtuel de sortie VDOD1, VDODj destiné à contenir la valeur de la donnée de sortie, puisse être associé à un tel attribut de typage de ladite donnée de sortie OD1, ODj. Dans ce cas, l’étape de lecture 140 (du procédé 100 selon la ) de la valeur de la donnée de sortie OD1, ODj concernée peut consister à associer ladite valeur dudit attribut de typage à la valeur de ladite donnée de sortie. Lorsque l’application logicielle A1 ne prévoit pas un tel typage, le contrat C1 qui lui est associé n’associe pas un tel attribut de typage. En revanche, la plateforme d’imagerie 4 peut mettre à jour ledit contrat C1 pour adjoindre ledit attribut de typage au répertoire virtuel de sortie de la donnée de sortie concernée. Un tel enrichissement d’une donnée de sortie produite par une application logicielle peut ainsi être mis à profit par la plateforme d’imagerie médicale 4 pour choisir des données d’entrée ED1, EDi de l’application logicielle A1 à inscrire dans le répertoire d’entrée DED1, DEDi du système de fichiers 42 ou pour choisir des données d’entrée de toute autre application. L’invention prévoit en outre un mode de réalisation avantageux selon lequel un contrat C1, C2, Cn associé à une application logicielle A1, A2, An, peut être mis à jour ou initialisé de manière sécurisée. A ce titre, un tel contrat peut être chiffré après toute modification et déchiffré durant l’étape 110 d’un procédé 100 selon l’invention et tel qu’illustré par la . L’identifiant AID de l’application logicielle A1 peut en outre comporter un code de redondance (par exemple, un haché de ladite application logicielle associée) de sorte que l’étape 130 de lancement de l’exécution de l’application comporte un traitement pour vérifier ce code de redondance préalablement au déclenchement de l’exécution en tant que telle de l’application logicielle. Si le code de redondance calculé correspond à la valeur inscrite dans le contrat, l’exécution de l’application logicielle est confirmée et provoquée. Dans le cas contraire, ladite exécution est avortée. De cette manière, la plateforme d’imagerie médicale 4 peut s’assurer que le contrat est bien associé avec la version idoine de ladite application logicielle. Procédé (100) d’intégration et d’exécution d’une application logicielle (A1, A2, An) conçu pour être mis en œuvre par une plateforme d’imagerie médicale (4, 41) opérant un système de fichiers (42), ledit procédé (100) comportant : une étape de lecture (110) d’un contrat (C1, C2, Cn) dédié à une application logicielle (A1, A2, An) qui produit une donnée de sortie (OD1, OD2) à partir d’une donnée d’entrée (ED1, ED2), ledit contrat (C1, C2, Cn) consistant en un contenu numérique comportant : un identifiant unique (AID) désignant ladite application logicielle (A1, A2, A3) ; un répertoire virtuel d’entrée (VDED1, VDEDi) destiné à contenir une valeur de la donnée d’entrée (ED1, EDi) de l’application logicielle ; un répertoire virtuel de sortie (VDOD1, VDODj) destiné à contenir la valeur de la donnée de sortie (OD1, ODj) de l’application logicielle (A1, A2, An) ; une étape d’écriture (120) de la valeur de la donnée d’entrée (ED1, EDi) de l’application logicielle (A1, A2, An) dans un répertoire d’entrée (DED1, DEDi) du système de fichiers (42) ; une étape de lancement (130) de l’exécution de l’application logicielle (A1, A2, An) désignée par l’identifiant unique avec comme arguments les chemins d’accès (DPED1, DPEDi, DPOD1, DPODj) au répertoire d’entrée (DED1, DEDi) du système de fichiers (42) et à un répertoire de sortie (DOD1, DODj) dudit système de fichiers (42), lesdits chemins d’accès (DPED1, DPEDi, DPOD1, DPODj) étant associés respectivement aux répertoires virtuels d’entrée (VDED1, VDEDi) et de sortie (VDOD1, VDODj) lus (110) dans ledit contrat (C1, C2, Cn) ; une étape de lecture (140) de la valeur de la donnée de sortie (OD1, ODj) de l’application logicielle (A1, A2, An) dans le répertoire de sortie (DOD1, DODj) du système de fichiers (42). Procédé (100) selon la revendication précédente, pour lequel le contrat (C1, C2, Cn) comporte une valeur (EV1, EVk) d’un paramètre de fonctionnement (E1, Ek) de l’application logicielle (A1, A2, An) et pour lequel l’étape de lancement (130) de l’exécution de ladite application logicielle (A1, A2, An) est adaptée pour comporter comme argument la valeur dudit paramètre de fonctionnement. Procédé (100) selon l’une quelconque des revendications précédentes, comprenant une étape de chargement de l’application logicielle (A1, A2, An) et du contrat (C1, C2, Cn) dans une mémoire (45) de la plateforme logicielle (4). Procédé selon l’une quelconque des revendications précédentes, pour lequel l’application logicielle (A1, A2, An) se présente sous la forme d’un conteneur informatique, l’identifiant unique (AID) désignant ladite application logicielle (A1, A2, An) compris dans ledit contrat (C1, C2, Cn) exprimant l’image dudit conteneur informatique. Procédé (100) selon l’une quelconque des revendications précédentes pour lequel le répertoire virtuel d’entrée (VDED1, VDEDi) destiné à contenir la donnée d’entrée (ED1, EDi) de l’application logicielle (A1, A2, An) est associé dans le contrat (C1, C2, Cn) à un attribut précisant le caractère optionnel ou obligatoire de ladite donnée d’entrée (ED1, EDi) et pour lequel, lorsqu’un tel attribut atteste un caractère optionnel de ladite donnée d’entrée (ED1, EDi), l’étape d’écriture (120) de cette dernière n’est mise en œuvre que si une telle donnée d’entrée (ED1, EDi) est disponible pour la plateforme d’imagerie médicale (4). Procédé (100) selon l’une quelconque des revendications précédentes pour lequel le répertoire virtuel de sortie (DOD1, DODj) destiné à contenir la valeur de la donnée de sortie (OD1, ODj) de l’application logicielle (A1, A2, An) est associé dans le contrat (C1, C2, Cn) à un attribut de typage de ladite sortie (OD1, ODj) et pour lequel l’étape de lecture (140) de la valeur de la donnée de sortie (OD1, ODj) de l’application logicielle (A1, A2, An) consiste à associer ladite valeur dudit attribut de typage à la valeur de ladite donnée de sortie (OD1, ODj). Procédé (100) selon l’une quelconque des revendications précédentes pour lequel le contrat (C1, C2, Cn) est encodé préalablement à son intégration dans la plateforme (4) et pour lequel l’étape de lecture (110) d’un contrat (C1, C2, Cn) comporte une sous-étape préalable de décodage dudit contrat. Produit programme d’ordinateur comportant une ou plusieurs instructions de programme exécutables par l’unité de traitement (41) d’un ordinateur, lesdites instructions de programme étant chargeables dans une mémoire non volatile (45) dudit ordinateur et dont l’exécution par ladite unité de traitement (41) provoque la mise en œuvre d’un procédé (100) selon l’une quelconque des revendications précédentes. Support de mémorisation lisible par un ordinateur comportant les instructions d’un produit programme d’ordinateur selon la revendication précédente. Plateforme d’imagerie médicale (4) comprenant une unité de traitement (41), une mémoire (45) exploitée par un système de fichiers (42), ladite mémoire (45) comprenant les instructions de programme d’un produit programme d’ordinateur selon la revendication 8.