Brevet FR3140970A1 — publié le 20240419

Procédé de déploiement d’applications, dispositif électronique et produit programme d’ordinateur correspondant L’invention concerne un procédé de déploiement d’une application logicielle passive dans un réseau de communication, ledit procédé comprenant : Une obtention du code binaire de ladite application passive et d’une désignation du ou des type(s) de données consommées et/ou produites par ladite application ; Une sélection au moins partiellement automatique d’un accès aux données d’au moins une source de données dudit réseau et/ou vers au moins un consommateur de données dudit réseau, ladite sélection tenant compte dudit au moins un type désigné et d’au moins un type de données attendu via ledit accès; Une création automatique d’un exécutable actif dont au moins un processus logiciel comprend une invocation de ladite application passive avec en paramètre(s) d’entrée au moins une donnée obtenue via ledit accès et/ou avec en paramètre(s) de sortie au moins une donnée à émettre via ledit accès. L’invention concerne aussi le dispositif électronique, système, produit programme d’ordinateur et support d’enregistrement correspondants. Figure pour l'abrégé : Fig. 3 Procédé de déploiement d’au moins une application logicielle, dispositif électronique et produit programme d’ordinateur correspondant 1. Domaine technique La présente application se rapporte au domaine général du déploiement d’applications, dans divers secteurs comme par exemple dans le secteur de l’industrie, de l’agriculture et/ou du médical. Elle concerne notamment un procédé de déploiement d’application(s) logicielle(s) ainsi qu’un dispositif électronique adapté à la mise en œuvre d’un tel procédé, et les produit programme d’ordinateur et support d’enregistrement correspondants. 2. Etat de la technique L’industrie connait aujourd’hui plus que jamais des défis environnementaux et sociétaux (sécurité du personnel, manque de disponibilité de personnel qualifié, concurrence...) la poussant à automatiser certaines opérations, comme des tâches de contrôle qualité, de sécurité et de maintenance prédictive, en lien avec des postes de production. Pour faire face à ces défis, les industriels s’appuient souvent des fournisseurs externes, multiples, spécialisés chacun dans la fourniture de solutions automatisées répondant à une problématique particulière. Des exemples de telles fournitures comprennent une application de détection de défaut par vision par ordinateur (ou « computer vision » selon la terminologie anglaise), une application de détection de panne par analyse de vibration, une application de détection de passage etc. Chaque fournisseur de solution amène à l’industriel son propre environnement : des capteurs dédiés, en majorité filaires, son propre matériel informatique (comme un serveur de proximité à installer dans le site industriel concerné, ou ses propres connexions avec les machines du client, en majorité filaires etc..) Cela conduit à une complexification du parc matériel et logiciel d’un industriel et à des difficultés à garder une vision d’ensemble de ce parc, pour un industriel. La présente demande a pour objet de proposer des améliorations à au moins certains des inconvénients de l’état de la technique. 3. Exposé de l'invention La présente demande vise à améliorer la situation à l'aide notamment d'un procédé de déploiement au moins partiellement automatique d’une application logicielle passive dans un réseau de communication, ledit procédé comprenant : Une obtention du code binaire de ladite application passive et d’une désignation du ou des type(s) de données consommées et/ou produites par ladite application ; Une sélection au moins partiellement automatique d’au moins un accès aux données d’au moins une source de données dudit réseau et/ou vers au moins un consommateur de données dudit réseau, ladite sélection tenant compte dudit au moins un type désigné et d’au moins un type de données attendu via ledit accès; Une création automatique d’un exécutable actif dont au moins un processus logiciel comprend une invocation de ladite application passive avec en paramètre(s) d’entrée au moins une donnée obtenue via ledit accès et/ou avec en paramètre(s) de sortie au moins une donnée à émettre via ledit accès. Dans au moins certains modes de réalisation, ledit procédé comprend un ajout dans une bibliothèque d’exécutables actifs dudit réseau de communication dudit premier exécutable actif créé. Dans au moins certains modes de réalisation, ledit premier exécutable ajouté est associé dans ladite bibliothèque à ladite au moins une source de données et/ou audit au moins un consommateur de données. Dans au moins certains modes de réalisation, ledit procédé comprend un lancement dudit premier exécutable actif ou une proposition d’un tel lancement. Dans au moins certains modes de réalisation, ladite désignation est obtenue par accès à un fichier descriptif des données consommées et/ou produites par ladite application. Dans au moins certains modes de réalisation, ledit accès est un accès à une base de données. Dans au moins certains modes de réalisation, ledit au moins un type de données via ledit accès est obtenu par scrutation dudit réseau. Dans au moins certains modes de réalisation, ledit accès est un canal d’un bus de données dudit réseau. Dans au moins certains modes de réalisation, lesdites données obtenues via ledit canal sont obtenues par souscription dudit processus logiciel audit canal de données pour recevoir les données en provenance de ladite au moins une source de données. Dans au moins certains modes de réalisation, ledit processus logiciel comprend une transmission desdites données desdites données à émettre sur ledit canal. Dans au moins certains modes de réalisation, lesdits canaux de données sont des canaux d’un bus de données MQTT Les caractéristiques, présentées isolément dans la présente demande en lien avec certains modes de réalisation du procédé de la présente demande peuvent être combinées entre elles selon d’autres modes de réalisation de ce procédé. Selon un autre aspect, la présente demande concerne également un dispositif électronique adapté à mettre en œuvre le procédé de la présente demande dans l’un quelconque de ses modes de réalisations. Par exemple, la présente demande concerne ainsi un dispositif électronique comprenant un moins un processeur configuré pour un déploiement au moins partiellement automatique d’une application logicielle passive dans un réseau de communication, le processeur étant notamment configuré pour: Une obtention du code binaire de ladite application passive et d’une désignation du ou des type(s) de données consommées et/ou produites par ladite application ; Une sélection au moins partiellement automatique d’au moins un accès aux données d’au moins une source de données dudit réseau et/ou vers au moins un consommateur de données dudit réseau, ladite sélection tenant compte dudit au moins un type désigné et d’au moins un type de données attendu via ledit accès; Une création automatique d’un exécutable actif dont au moins un processus logiciel comprend une invocation de ladite application passive avec en paramètre(s) d’entrée au moins une donnée obtenue via ledit accès et/ou avec en paramètre(s) de sortie au moins une donnée à émettre via ledit accès. La présente demande concerne aussi par exemple un système comprenant : au moins un dispositif électronique comprenant un moins un processeur configuré pour un déploiement au moins partiellement automatique d’une première application logicielle passive dans un réseau de communication, le processeur étant notamment configuré pour: Une obtention du code binaire de ladite application passive et d’une désignation du ou des type(s) de données consommées et/ou produites par ladite application ; Une sélection au moins partiellement automatique d’au moins un accès aux données d’au moins une source de données dudit réseau et/ou vers au moins un consommateur de données dudit réseau, ladite sélection tenant compte dudit au moins un type désigné et d’au moins un type de données attendu via ledit accès; Une création automatique d’un exécutable actif dont au moins un processus logiciel comprend une invocation de ladite application passive avec en paramètre(s) d’entrée au moins une donnée obtenue via ledit accès et/ou avec en paramètre(s) de sortie au moins une donnée à émettre via ledit accès. Au moins un dispositif source et/ou un consommateur de données dudit réseau. La présente demande concerne aussi un programme d'ordinateur comprenant des instructions pour la mise en œuvre des divers modes de réalisation du procédé ci-dessus, lorsque le programme d’ordinateur est exécuté par un processeur et un support d’enregistrement lisible par un dispositif électronique sur lequel est enregistré le programme d’ordinateur. Par exemple, la présente demande concerne ainsi un programme d'ordinateur comprenant des instructions pour la mise en œuvre, lorsque le programme est exécuté par un processeur d’un dispositif électronique, d'un procédé de déploiement au moins partiellement automatique d’une première application logicielle passive dans un réseau de communication, ledit procédé comprenant : Une obtention du code binaire de ladite application passive et d’une désignation du ou des type(s) de données consommées et/ou produites par ladite application ; Une sélection au moins partiellement automatique d’au moins un accès aux données d’au moins une source de données dudit réseau et/ou vers au moins un consommateur de données dudit réseau, ladite sélection tenant compte dudit au moins un type désigné et d’au moins un type de données attendu via ledit accès; Une création automatique d’un exécutable actif dont au moins un processus logiciel comprend une invocation de ladite application passive avec en paramètre(s) d’entrée au moins une donnée obtenue via ledit accès et/ou avec en paramètre(s) de sortie au moins une donnée à émettre via ledit accès. Par ailleurs, la présente demande concerne aussi un support d’enregistrement lisible par un processeur d’un dispositif électronique et sur lequel est enregistré un programme d’ordinateur comprenant des instructions pour la mise en œuvre, lorsque le programme est exécuté par le processeur, d'un procédé de déploiement au moins partiellement automatique d’une première application logicielle passive dans un réseau de communication, ledit procédé comprenant : Une obtention du code binaire de ladite application passive et d’une désignation du ou des type(s) de données consommées et/ou produites par ladite application ; Une sélection au moins partiellement automatique d’au moins un accès aux données d’au moins une source de données dudit réseau et/ou vers au moins un consommateur de données dudit réseau, ladite sélection tenant compte dudit au moins un type désigné et d’au moins un type de données attendu via ledit accès; Une création automatique d’un exécutable actif dont au moins un processus logiciel comprend une invocation de ladite application passive avec en paramètre(s) d’entrée au moins une donnée obtenue via ledit accès et/ou avec en paramètre(s) de sortie au moins une donnée à émettre via ledit accès. Les programmes mentionnés ci-dessus peuvent 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 objet, tel que dans une forme partiellement compilée, ou dans n’importe quelle autre forme souhaitable. Les supports d'informations mentionnés ci-dessus peuvent être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, un support peut 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. Un tel moyen de stockage peut par exemple être un disque dur, une mémoire flash, etc. D'autre part, un support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Un programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet. Alternativement, un support d'informations peut être un circuit intégré dans lequel un programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution de l’un quelconque des modes de réalisation du procédé objet de la présente demande de brevet. De façon générale, par obtention d’un élément, on entend dans la présente demande par exemple une réception de cet élément depuis un réseau de communication, une acquisition de cet élément (via par exemple des éléments d’interface utilisateur ou des capteurs ou autres composants de mesure), une création de cet élément par divers moyens de traitement tels que par copie, encodage, décodage, transformation etc. et/ou un accès de cet élément depuis un support de stockage local ou distant accessible à au moins un dispositif mettant en œuvre, au moins partiellement, cette obtention. 4. Brève description des dessins D’autres caractéristiques et avantages de l’invention apparaîtront plus clairement à la lecture de la description suivante de modes de réalisation particuliers, donnés à titre de simples exemples illustratifs et non limitatifs, et des dessins annexés, parmi lesquels : La présente une vue simplifiée d’un système, cité à titre d’exemple, dans lequel au moins certains modes de réalisation du procédé de la présente demande peuvent être implémentés. La présente une vue simplifiée d’un dispositif adapté à mettre en œuvre au moins certains modes de réalisation du procédé de la présente demande. La présente un aperçu du procédé de la présente demande, dans certains de ses modes de réalisation. La illustre un exemple d’architecture d’un exécutable actif obtenu par le procédé de la présente demande, dans au moins certains de ses modes de réalisation. La illustre un exemple d’implémentation du procédé de la présente demande, dans au moins certains de ses modes de réalisation. 5. Description des modes de réalisation La présente demande propose un procédé, au moins partiellement automatique, de déploiement d’applications logicielles au sein d’un environnement physique, plus ou complexe, comme un ensemble industriel (éventuellement distribué sur plusieurs sites). Les applications peuvent par exemple correspondre à des solutions logicielles mettant en œuvre des techniques d’intelligence artificielle (IA) ou à des programmes compilés et/ou interprétés plus classiques, fournis par divers fournisseurs. Dans la présente demande, on entend par application ou ressource logicielle « passive », une ressource logicielle sous format binaire ou textuel s’exécutant uniquement si un autre exécutable l’a invoquée (ou « appelée ») en lui fournissant les éventuels paramètres d’entrée qu’il attend. Une telle ressource peut correspondre par exemple au code binaire obtenu par une compilation du code source d’une méthode ou d’une fonction logicielle. Une ressource passive n’a pas été prévue pour obtenir elle-même ses paramètres d’entrée. C’est l’exécutable (passif ou actif) qui l’invoque, ou l’opérateur qui l’invoque via une ligne de commande par exemple, qui va affecter des valeurs à ses paramètres d’entrée. De même, la ressource passive se contente de « retourner », en fin d’exécution, son ou ses paramètres de sortie éventuel(s), à l’exécutable (passif ou actif) ou l’opérateur qui l’invoque. A l’opposé, on entend ici par application ou ressource « active », ou exécutable « actif », ou autonome, un code binaire logiciel capable de s’exécuter sans être invoqué par un autre exécutable, en acquérant par lui-même les valeurs des variables qu’il utilise. Une telle ressource peut correspondre par exemple au code binaire d’un processus logiciel obtenu par couplage (ou « link » selon la terminologie anglais) du code binaire obtenu par compilation du code source de ce processus et les codes binaires issues des compilations des méthodes, fonctions, dictionnaires qu’il utilise. Un tel code exécutable peut être lancé par une application logicielle (créant ainsi le processus objet du code) et s’exécuter ensuite en tâche de fond, en acquérant de lui-même les valeurs de ses paramètres d’entrée. Dans une infrastructure automatisée, un exécutable actif peut par exemple obtenir ses paramètres d’entrée parmi les données brutes disponibles sur une infrastructure de gestion de données, qu’il connait et avec laquelle il peut interagir (comme une base de données, un bus de données et/ou une autre application). Une telle interaction peut être prévue par exemple lors du développement du code source de l’exécutable, ou via un fichier de configuration. Par exemple, il peut obtenir ses paramètres d’entrée en se connectant à une base de données, ou en souscrivant à au moins un canal d’un bus de données mettant à disposition des données. Par données « mises à disposition », on entend ici à la fois les données véhiculées par le bus en provenance d’au moins une source des données (que l’exécutable va consommer) que les données émises sur le bus (par l’exécutable) et susceptibles d’être consommées par d’autres exécutables, ou à servir de commandes à des machines connectées à ce bus. Le procédé de la présente demande vise à modifier une ressource logicielle « passive » pour en faire un exécutable « actif », et ceci de manière au moins partiellement (voire totalement) automatique, par exemple sans réécriture de code, et/ou, au moins dans certains modes de réalisation, à déployer cet exécutable actif simplement, par exemple en le proposant sur une interface utilisateur. Par exemple, dans au moins certains modes de réalisation, l’exécutable actif créé à partir de l’application passive peut être rendu accessible (par exemple dans une bibliothèque d’exécutables) à une plateforme logicielle offrant une interface utilisateur permettant de lancer ces exécutables actifs. Ces exécutables actifs peuvent par exemple être définis de façon à s’exécuter en continue, en tâche de fond, en partageant entre eux des ressources logicielles ou matérielles à leur disposition, comme des capteurs, ou des machines qu’ils commandent. Ainsi, plusieurs applications « passives » peuvent partager (via leur encapsulation dans des exécutables actifs) une même source de données (comme un même capteur par exemple). Les exécutables et leurs ressources logicielles ou matérielles peuvent dans certains modes de réalisation communiquer ensemble de façon asynchrone. Dans certains mode de réalisation, un exécutable actif peut par exemple avoir la capacité à la fois de : de s’alimenter au fil de l’eau avec des données provenant de cette ou de ces source(s) (par exemple des données acquises par un ou plusieurs capteurs connectés à la plateforme), par exemple via des mécanismes de souscription à au moins un canal de données véhiculant de telles données; d’invoquer l’application passive avec des donnée d’entrée résultant de données provenant de cette/ces source(s); transmettre au fil de l’eau des données résultants de l’invocation de l’application passive à d’autres exécutables (par exemple via des mécanismes de publication de ces résultats dans au moins un canal du bus de données adapté à véhiculer de telles données. Selon les modes de réalisation, les données provenant de ces sources de données peuvent être des données « brutes » ou « non traitées » (ie des données acquises par cette/ces source(s) de données, par exemple telles que mesurées par ces sources de données, comme une vitesse lorsqu’une source de données est un capteur de vitesse), ou des données « traitées » , obtenue par traitement de données « brutes ». Il peut s’agir par exemple d’une donnée intégrant une interprétation d’une vitesse mesurée par un capteur de vitesse, comme une qualification de cette vitesse (trop vite, trop lent) éventuellement corrélée à d’autres données (état des pneumatiques sur une voiture, chaussée mouillée ou non, etc.)). L’application passive elle-même peut par exemple être une application ne mettant en œuvre aucun mécanisme de communication asynchrone de données (comme une souscription à, ou une publication vers, au moins un canal de données) L’invocation de l’application active peut par exemple permettre à l’exécutable actif créé d’interagir (via l’application passive) avec des équipements (par exemple des machines industrielles) connectées à la plateforme et auxquelles est dédiée l’application passive. La transmission des données (de sortie) résultant de l’invocation de l’application passive à d’autres exécutables en charge de la commande d’équipements comme des machines industrielles peut également permettre une commande indirecte (via ces « autres » exécutables) de ces équipements. Dans au moins certains de ses modes de réalisation, le procédé peut ainsi aider à générer simplement des combinaisons d’exécutables, pour obtenir par exemple des fonctionnalités complexes complètement automatisées et personnalisées, dédiées par exemple aux besoins particuliers d’une entreprise. Dans au moins certains de ses modes de réalisation, le procédé peut aider un utilisateur à mettre en œuvre diverses applications, en les intégrant de façon simple, au moins partiellement automatique, à son propre environnement, et ceci sans multiplier les interfaces utilisateurs, les matériels etc... On décrit à présent, en lien avec la , de façon plus détaillée la présente demande. La représente un système de télécommunication 100 dans lequel certains modes de réalisation de l’invention peuvent être mis en œuvre. Le système 100 comporte un ou plusieurs dispositifs électroniques, certains au moins pouvant communiquer entre eux via un ou plusieurs réseaux de communication, éventuellement interconnectés, comme un réseau local ou LAN (Local Area Network) et/ou un réseau de type étendu, ou WAN (Wide Area Network). Par exemple, le réseau peut comprendre un réseau LAN d’entreprise ou domestique et/ou un réseau WAN de type internet, ou cellulaire, GSM - Global System for Mobile Communications, UMTS - Universal Mobile Telecommunications System, Wi-Fi - Wireless, etc.) . Un exemple de tel réseau de communication est le bus de données 420 illustré en . Comme illustré en , le système 100 peut également comprendre plusieurs dispositifs électroniques, comme des terminaux (tel qu’un ordinateur portable 110, un smartphone 130, une tablette 120), des objets connectés 160 ( par exemple des machines de production (comme des outillages électroniques) ou des capteurs, et/ou un serveur 140 (par exemple un serveur d’applications) et/ou un dispositif de stockage 150. Le système peut également comprendre des éléments de gestion et/ou d’interconnexion réseau (non représentés). La illustre une structure simplifiée d’un dispositif électronique 200 du système 100, par exemple l’un des dispositifs 110, 120, 130, 140, 150, 160 de la , adapté à mettre en œuvre le procédé de la présente demande. Comme illustré, selon les modes de réalisation, il peut s’agir d’un serveur, d’un terminal ou d’un objet connecté. Le dispositif 200 peut par exemple jouer le rôle de plateforme de gestion d’exécutables dans la présente demande. Il peut dans certains modes de réalisation est compatible avec des plateformes du commerce (comme la plateforme « Kubernetes » ©) de déploiement d’applications. Le dispositif 200 comprend notamment au moins une mémoire M 210 comme une mémoire tampon, une mémoire volatile, par exemple de type RAM (pour « Random Access Memory » selon la terminologie anglaise), et/ou une mémoire non volatile (par exemple de type ROM (pour « Read Only Memory » selon la terminologie anglaise). Le dispositif 200 peut également comprendre une unité de traitement UT 220, équipée par exemple d'au moins un processeur P 222, et pilotée par un programme d'ordinateur PG 212 stocké en mémoire M 210. A l'initialisation, les instructions de code du programme d'ordinateur PG sont par exemple chargées dans une mémoire RAM avant d'être exécutées par le processeur P. Ledit au moins un processeur P 222 de l'unité de traitement UT 220 peut notamment mettre en œuvre, individuellement ou collectivement, l'un quelconque des modes de réalisation du procédé de la présente demande (décrit notamment en relation avec la figures 3), selon les instructions du programme d'ordinateur PG. Le dispositif peut également comporter, ou être couplé à, au moins un module d’entrée/ sortie I/O 230, tel qu’un module de communication, permettant par exemple au dispositif 200 de communiquer avec d’autres dispositifs du système 100, via des interfaces de communication filaires ou sans fils, et/ou tel qu’un module d’interfaçage avec un utilisateur du dispositif (aussi appelé plus simplement dans cette demande « interface utilisateur »). Par interface utilisateur du dispositif, on entend par exemple une interface intégrée au dispositif 200, ou une partie d’un dispositif tiers couplé à ce dispositif par des moyens de communication filaires ou sans fils. Par exemple, il peut s’agir d’un écran secondaire du dispositif ou d’un ensemble de hauts parleurs connectés par une technologie sans fils au dispositif. Une interface utilisateur peut notamment être une interface utilisateur, dite «de sortie», adaptée à un rendu (ou au contrôle d’un rendu) d’un élément de sortie d‘une application informatique utilisée par le dispositif 200, par exemple une application s’exécutant au moins partiellement sur le dispositif 200 ou une application « en ligne » s’exécutant au moins partiellement à distance, par exemple sur le serveur 140 du système 100. Des exemples d’interface utilisateur de sortie du dispositif incluent un ou plusieurs écrans, notamment au moins un écran graphique (tactile par exemple), un ou plusieurs haut-parleurs, un casque connecté. Par ailleurs, une interface utilisateur peut être une interface utilisateur, dite «d’entrée», adaptée à une acquisition d’une commande d’un utilisateur du dispositif 200. Il peut s’agir notamment d’une action à effectuer en lien avec un item rendu sur une interface de sortie du dispositif, et/ou d’une commande à transmettre à une application informatique utilisée par le dispositif 200 (par exemple un exécutable actif comme introduit ci-avant), par exemple une application s’exécutant au moins partiellement sur le dispositif 200 ou une application « en ligne » s’exécutant au moins partiellement à distance, par exemple sur le serveur 140 du système 100. Des exemples d’interface utilisateur d’entrée du dispositif 200 incluent un moyen d’acquisition audio et/ou vidéo (microphone, caméra (webcam) par exemple), un clavier, une souris. De tels moyens d’entrées/sorties peuvent par exemple être adaptés à une gestion (création, mémorisation, sélection, lancement, paramétrage etc.) d’au moins un exécutable. Ils peuvent permettre par exemple un paramétrage des entrées/sorties d’une ressource (ou application) « passive » à déployer sous forme d’un exécutable actif (par exemple une désignation d’au moins un canal de données à utiliser pour fournir des paramètres d’entrée à la ressource via l’exécutable à déployer et/ou une désignation d’au moins un canal de données à alimenter, via l’exécutable, avec des paramètres de sortie fournis par cette ressource, une désignation d’au moins une source de données pour cet exécutable à déployer et/ou d’un destinataire de données pour cet exécutable). Dans certains modes de réalisation, les modules d’entrées/ sorties peuvent également comprendre des moyens de communication adaptés à recevoir des données (par exemple des données acquises par un autre dispositif comme des images, des mesures etc..) et/ou de moyens d’acquisitions de ces données. Ces moyens d’acquisition peuvent comprendre des capteurs physiques ou logiciels aptes à l’acquisition de telles données. De tels modules d’entrées/sorties peuvent notamment être adaptés à consommer des données circulant sur au moins un canal 422, 424 d’un bus 420 de données et/ou à émettre des données sur au moins un canal 426 d’un bus 420 de données (voir ). Ledit au moins un microprocesseur du dispositif 200 peut notamment être adapté pour un déploiement au moins partiellement automatique d’une première application logicielle passive dans un réseau de communication. Ledit processeur peut notamment être configuré pour: Une obtention du code binaire de ladite application passive et d’une désignation du ou des type(s) de données consommées et/ou produites par ladite application ; Une sélection au moins partiellement automatique d’au moins une source de données dudit réseau et/ou d’au moins un consommateur de données dudit réseau, ladite sélection tenant compte dudit au moins un type désigné et d’au moins un type de données mises à disposition et/ou attendues dans ledit réseau; Une création automatique d’un exécutable actif dont au moins un processus logiciel comprend une invocation de ladite application passive avec en paramètre(s) d’entrée au moins une donnée mise à disposition par ladite source de données sélectionnée et/ou avec en paramètre(s) de sortie au moins une donnée attendue par ledit au moins un consommateur sélectionné. Dans certains modes de réalisation, le procédé de la présente demande peut être mis en œuvre de façon distribuée entre au moins deux dispositifs 110, 120, 130, 140, 150 ou 160 du système 100. Ainsi, dans certains modes de réalisation, un premier dispositif (par exemple un serveur 140 du système 100) peut construire un exécutable « actif » (selon le procédé de la présente demande) qu’il communique à au moins un second dispositif (par exemple un terminal 110 ou le dispositif de stockage 150 du système 100), de qui un troisième dispositif (comme le terminal 110, ou le serveur 140) pourra ultérieurement obtenir ce modèle. L’exécutable peut ensuite être lancé sur le second et/ou le troisième dispositif (par exemple le serveur 140, ou un autre serveur, ou le terminal 110) (selon le procédé de la présente demande). Dans d’autres modes de réalisation, le procédé de la présente demande peut être mis en œuvre localement par le dispositif 200. Une mise en œuvre distribuée du procédé peut permettre de déployer en parallèle un même exécutable sur plusieurs dispositifs (par exemple pour permettre une redondance de traitements critiques) en mettant en commun certains traitements pour l’obtention de l’exécutable « actif » à partir d’une application passive. Par ailleurs, une implémentation locale à un dispositif peut aider à simplifier la mise en œuvre de la solution objet de la présente demande, et donc aider à limiter son coût d’implémentation. Elle peut aussi aider à préserver la confidentialité de certaines données sensibles ou de certains traitements secrets (comme des secrets de fabrication faisant partie du savoir-faire d’une entreprise) dont on souhaite éviter la diffusion. Certains des modules d‘entrée -sorties ci-dessus sont optionnels et peuvent donc être absents du dispositif 200 dans certains modes de réalisation. Notamment, lorsque le procédé est mis en œuvre localement, certains modules d’entrées/sorties liés à la transmission ou à la réception de données peuvent être absents. Par le terme « module » ou le terme « composant » ou «élément » du dispositif, on entend ici un élément matériel, notamment câblé, ou un élément logiciel, ou une combinaison d’au moins un élément matériel et d’au moins un élément logiciel. Le procédé selon l’invention peut donc être mis en œuvre de diverses manières, selon ses modes de réalisation, notamment sous forme câblée et/ou sous forme logicielle. On présente à présent, en lien avec les figures 3 et 4, certaines mises en œuvre du procédé 300 de la présente demande sur un dispositif électronique (qui peut être similaire au dispositif 200 de la ). tel que le serveur 140 ou le terminal 110 de la . Comme illustré, le procédé 300 peut comprendre une obtention 310 des caractéristiques d’au moins une application logicielle à déployer dans ledit réseau de communication. Cette obtention peut comprendre notamment une obtention 312 de l’application elle-même et une obtention 314 de sa description. Selon les modes de réalisation, ces deux étapes peuvent être effectuées en parallèle, ou successivement (sans préjugé de leur ordre respectif), ou encore, ces deux étapes peuvent être réunies en seule étape, où l’application et sa description sont obtenues ensemble (par exemple dans un même flux de données). Dans certains modes de réalisation, l’application et/ou sa description peut être reçue d’un autre dispositif (via des moyens de communication) ; par exemple téléchargée depuis un serveur d’applications (par exemple par un opérateur, via une interface web), ou chargée depuis un support de stockage interne ou externe (tel qu’un disque dur externe ou qu’une clé USB par exemple), Après obtention, l’application et/ou sa description reçue(s) peut par exemple être chargée pour y être mémorisée, sur un support de stockage (comme un support non transitoire tel qu’un disque dur) de la plateforme. Par exemple, un fournisseur d’applications ou un fournisseur d’un équipement à commander peut fournir une application (par exemple une application de commande de de cet équipement), sous forme d’un code binaire ou d’un fichier texte (comme un script), et une description de l’application. Cette description peut par exemple préciser si l’application possède des paramètres d’entrée et/ou de sortie, et si c’est le cas, le nombre, le type, l’ordre, et /ou l’éventuelle valeur par défaut de ces paramètres. Il peut s’agir par exemple d’une liste exhaustive et ordonnée (selon l’ordre des paramètres lors de l’invocation de l’application), indiquant le type de chacun des paramètres d’entrée et/ou de sortie. Selon les modes de réalisation, la description peut être transmise sous diverses formes, comme un document papier ou électronique, transmis via un support de stockage, ou téléchargé, conjointement à l’application ou de façon séparée. Le format du document électronique peut différer selon les modes de réalisation. Dans le cas d’un document électronique, il peut s’agir d’un document au format « pdf », ou basé sur le format « HTML» (pour « HyperText Markup Language » en anglais), ou d’un fichier descriptif interprétable automatiquement. Par exemple, il peut utiliser un format particulier au fournisseur d’applications ou de l’équipement à commander ou utiliser un format standard de sérialisation de données, comme le format connu sous le nom de YAML, ou un format utilisant un langage de balisage, comme HTML. L’obtention 314 de la description peut par exemple mettre en œuvre une transcription d’au moins une partie d’un document papier ou électronique (comme un document au format « pdf ») dans un format interprétable automatiquement. Cette transcription peut par exemple être effectuée manuellement par un opérateur via une interface homme machine (comme une interface web) du dispositif 200 ou de façon automatique, par exemple via des techniques automatiques d’analyse de documents telles que des techniques automatiques de reconnaissance de caractères, d’analyse syntaxique et/ou sémantique etc.. Comme illustré en , le procédé peut comprendre dans certains modes de réalisation, une obtention 320 d’une description des données susceptibles d’être véhiculées vers des dispositifs du système 100 (comme des capteurs, des caméras etc.. ou d’autres exécutables actifs du système 100) (et donc susceptible d’alimenter, via un exécutable actif, l’application obtenue 310 ) et vice versa des données susceptibles d’être attendues par des dispositifs du système 100. Dans l’exemple de la , les dispositifs du système 100 utilisent un ou plusieurs canaux d’un bus de données pour s’échanger de façon asynchrone des informations en utilisant par exemple un protocole de messagerie utilisant un mécanisme d’abonnements (ou de souscriptions) à des évènements et/ou de publications d’évènements. Selon les modes de réalisation, le protocole de messagerie peut être divers, il peut dans exemple s’agir d’un protocole de messagerie basé sur un protocole standard de communication comme TCP/IP (de l'anglais Transmission Control Protocol (TCP) et Internet Protocol (IP) , comme MQTT (pour Message Queuing Telemetry Transport). Une description des données circulant sur le bus de données peut par exemple être obtenue auprès d’une entité gestionnaire du bus de données. Par exemple, certaines modes de réalisation peuvent utiliser une entité de type « Broker » dans le cas d’un bus MQTT et/ou une analyse dynamique 322 des données effectivement mises à disposition sur le bus. Par exemple, dans le cas d’un bus MQTT, un abonnement au canal ‘#’ permet de recevoir les données circulant sur tous les canaux actifs. Chaque message de données peut alors indiquer par exemple le canal utilisé. Dans certains modes de réalisation, un système déclaratif peut également mis en place afin de permettre à une source de données (un capteur par exemple) de signaler qu’elle est active et qu’elle utilise un canal spécifique. Ainsi, un canal dédié peut par exemple être utilisé pour générer (et/ou diffuser) un annuaire des canaux disponibles. Chaque source peut par exemple émet un signal sur ce canal (par exemple dans un format bien défini). Les exécutables (abonnés à ce canal peuvent alors être averti du canal utilisé par la source et s’enregistrer (ou non) dans les destinataires du canal de la source. Une analyse dynamique des canaux peut par exemple utiliser un outil de détection de type (comme le détecteur de type « Java Data Type »), afin d’obtenir dynamiquement le type de données d’au moins un canal du bus (par exemple automatiquement lors de l’utilisation du procédé de la présente demande, avant ou pendant l’exécution de l’exécutable actif. Dans le cas de l’outil Java Data Type, l’analyse dynamique d’une donnée circulant sur un canal de données peut permettre par exemple de retrouver un type primitif, de bas niveau, de Java, comme le type « booléen », le type « caractère », le type « entier », le type « nombre flottant », ou le type « double ». Bien entendu, les formats identifiés lors de l’analyse dynamique peuvent varier selon les modes de réalisation (par exemple selon l’outil de détection de type utilisé). La description des données susceptibles de circuler sur le bus de données peut notamment comprendre un identifiant d’au moins un dispositif et/ou processus source de telles données (comme les éléments 442, 444 de la ) et/ou d’un dispositif et/ou processus consommateur de telles données(comme l’élément 446 de la ), et/ou au moins un format de ces données. Elle peut aussi comprendre dans certains modes de réalisation, une fréquence probable et/ou demandée des mises à disposition de telles données, une taille probable, minimale ou maximale de ces données etc. Dans l’exemple de la , le procédé peut comprendre une mise en correspondance 330 entre au moins une portion de la description de l’application, relative aux paramètres d’entrée et/ou de sortie de l’application, et les données susceptibles de circuler sur le bus de données. Par exemple, lorsqu’un type (primitif par exemple) de données circulant sur le bus est identique à un type (primitif par exemple) d’un paramètre d’entrée ou de sortie de l’application, le canal de circulation sera considéré comme un canal possible de mise à disposition de données (par ou pour un exécutable invoquant l’application) et mémorisé en association 334 du paramètre d’entrée ou de sortie de l’application concerné. Lorsqu’un type de données susceptibles de circuler sur au moins un des canaux du bus est différent d’un type d’un paramètre d’entrée ou de sortie de l’application, le procédé peut comprendre une lecture 332 d’une table de conversion associant au moins un couple constitué d’un premier et d’un second type de données (primitifs par exemple) avec au moins une méthode de conversion à utiliser pour convertir des données de ce premier type en données de ce second type. La table de conversion (comme l’élément 430 de la ) peut être stockée par exemple sur le dispositif 200 ou dans un dispositif de stockage comme le dispositif 150 du système 100). La lecture 332 de la table de conversion peut permettre d’identifier une méthode de conversion à utiliser pour convertir au moins une donnée circulant sur au moins un des canaux du bus en au moins un paramètre d’entrée de l’application, ou pour convertir au moins un paramètres de sortie de l’application en donnée adaptée à circuler sur au moins un des canaux du bus. Si la lecture de la table de conversion permet d’identifier une méthode de conversion entre un canal de données et un paramètre d’entrée ou de sortie de l’application, le canal de circulation sera considéré comme un canal possible de mise à disposition de données (par ou pour un exécutable invoquant l’application), moyennant l’utilisation de la méthode de conversion. Ce canal de données sera alors mémorisé en association avec le paramètre d’entrée et/ou de sortie de l’application concernée, et la méthode de conversion (ou un lien vers cette méthode) à utiliser. La mise en correspondance aboutit ainsi, dans l’exemple illustré, à une éventuelle association 334, à une donnée d’entrée ou de sortie, d’au moins un canal de mise à disposition de données, ainsi qu’optionnellement à au moins une méthode de conversion associée. Lorsque au moins un paramètre d’entrée ou de sortie n’est associée à aucun canal, et, dans le cas d’un paramètre d’entrée, ne possède aucune valeur par défaut, le procédé peut comprendre une génération d’un message d’alerte et son émission vers un autre dispositif distant et/ou à son rendu vers une interface homme machine du dispositif 200. En effet, il peut être nécessaire d’affecter manuellement une valeur par défaut à un paramètre d’entrée et/ou de modifier ou d’ajouter un canal et/ou une source de données au système 100 pour permettre la mise à disposition de données d’un type correspondant (éventuellement via une conversion) au paramètre d’entrée. On notera qu’un paramètre de sortie qui n’est associé à aucun canal peut tout simplement être ignoré par l’exécutable invoquant l’application passive. Dans certains modes de réalisation, le procédé peut comprendre une sélection, parmi les canaux associés à un paramètre d’entrée ou de sortie de l’application, d’au moins un canal de données à utiliser lors d’une invocation de l’application passive. Dans certains modes de réalisation, cette sélection peut être automatique. Par exemple, la sélection d’au moins un canal de données peut être automatique dans des cas où un seul canal est associé à un paramètre d’entrée et/ou de sortie de l’application, ou lorsque la sélection se base sur l’application de règles paramétrées préalablement. Par exemple, une règle peut indiquer que les données de tous les canaux associés à un paramètre d’entrée doivent être utilisées comme paramètre d’entrée de l’application (l’exécutable surveillant alors l’ensemble de ces canaux), ou encore qu’un paramètre de sortie doit être mis à disposition (émis par exemple) sur tous les canaux associés à ce paramètre de sortie. Dans certains modes de réalisation, le procédé peut comprendre un rendu 336 des canaux associés à un paramètre de l’application, ainsi que par exemple des caractéristiques de ces canaux (comme un identifiant d’au moins un dispositif source ou consommateur des données circulant sur un canal ), de façon à permettre à un opérateur de faire un choix parmi le ou les canaux associés au paramètre concerné et/ou de confirmer la sélection (automatique) d’un ou de plusieurs canaux. Dans un tel mode de réalisation , le procédé peut comprendre une acquisition 338 d’une désignation d’au moins un des canaux associé au paramètre. La désignation peut par exemple comprendre au moins un identifiant d’au moins un canal de données à sélectionner (ou en variante à ne pas utiliser) et/ou au moins un identifiant d’au moins un dispositif source ou consommateur de données utilisant un canal de données à sélectionner (ou en variante à ne pas utiliser). Dans l’exemple de la , le procédé peut comprendre une création 340 automatique d’un exécutable actif 410 en charge d’invoquer l’application passive en utilisant les données mises à disposition via les canaux sélectionnés lors de la mise en correspondance 330. La illustre un exemple de l’architecture logicielle d’un tel exécutable 410 et de son environnement. Un tel exécutable 410 peut comprendre: un élément logiciel offrant une fonctionnalité de souscription (ou abonnement) et/ou de désabonnement à au moins un premier canal 422, 424 d’un bus de données 420 (par exemple les canaux associés à un paramètre d’entrée de l’application sélectionnés lors de la mise en correspondance 330) ou en variante, plus spécifiquement, aux mises à disposition de données, via ce premier canal 422, 424, en provenance d’au moins une première source 442, 444 de données ; un élément logiciel en charge d’écouter en permanence sur le premier canal 422, 424, et d’obtenir les données circulant sur ce premier canal 422, 424 ou , en variante, les données en provenant de la première source 442, 444;de données utilisant ce premier canal) un élément logiciel offrant une conversion éventuelle d’au moins une donnée (« brute » par exemple) mise à disposition sur le premier canal, en au moins une donnée d’un type connu (« donnée primitive ») et/ou une conversion éventuelle d’au moins une donnée primitive en au moins une donnée de format adapté au paramètre d’entrée 414 associé au premier canal 422, 424, en utilisant par exemple une méthode de conversion associée à ce paramètre d’entrée 414 et à ce premier canal 422, 424 lors de la mise en correspondance 330; un élément logiciel adapté à une invocation de l’application « passive » 412 avec en paramètre(s) d’entrée 414 au moins une donnée obtenue via l’écoute sur le premier canal 422, 424 (et éventuellement convertie) (ou une donnée fonction de la donnée obtenue) un élément logiciel offrant une conversion éventuelle d’au moins un paramètre(s) 416 de sortie de l’application 412 invoquée, en utilisant la méthode de conversion associée à ce paramètre de sortie 416 lors de la mise en correspondance 330 et un élément logiciel adapté à une mise à disposition du paramètre de sortie 416 (ou d’une donnée fonction de ce paramètre) sur un deuxième canal 426 associé à ce paramètre de sortie 416 et sélectionné lors de la mise en correspondance 330 et éventuellement converti Selon les modes de réalisation, l’exécutable peut comprendre divers autres éléments logiciels. Par exemple, dans certains modes de réalisation, il peut comprendre un module de génération de traces de l’invocation de l’application passive (ie d’alertes rapportant cette invocation) vers un dispositif d’un opérateur. Ces éléments logiciel peuvent être mis en œuvre dans des modules logiciel distincts ou commun. Par exemple, dans certains modes de réalisation, au moins certains de ces éléments logiciels peuvent être mis en œuvre par un module logiciel commun appelé par la suite Publish/subscrib Proxy . Le code d’au moins certains de ces éléments et/ou module(s) logiciel(s) peut être identique quelle que soit l’application passive du système 100, l’instanciation des élément(s) et/ou module(s) logiciel(s) se faisant par exemple en utilisant la description obtenue 310 de l’application, la description obtenue 320 des données mises en circulation sur le bus et/ou les associations mémorisées lors de la mise en correspondance 330 du procédé de la présente demande. L’exécutable actif (ou autonome) peut par exemple être créé 342 de façon automatique, à partir de l’application passive et (par exemple) du et/ou des modules logiciels ci-dessus, via des outils de génération d’exécutable; comme des outils utilisant des techniques d’encapsulation comme la technologie Docker ©. Ainsi, dans l’exemple de la , l’exécutable actif peut être obtenu via le programme « Image Docker » ©. Un tel programme peut aider par exemple à obtenir un exécutable en quelques secondes. Dans l’exemple de la , le procédé peut comprendre une mémorisation de l’exécutable actif créé. Cette mémorisation peut par exemple comprendre un ajout 344 dans une bibliothèque d’exécutables, accessible à un opérateur, pour permettre un déploiement 360 ultérieur de cet exécutable sur le dispositif 200 (ou un autre dispositif du système 100). Cet ajout peut être optionnel dans certains modes de réalisation. Comme illustré en , le procédé peut comprendre un rendu 350 d’informations représentative des exécutables actifs à la disposition d’un opérateur (via une bibliothèque telle que mentionnée ci-dessus par exemple). Par exemple les informations représentatives d’un exécutable actif peuvent inclure des informations relatives au système 100 (comme les dispositifs présents dans le système, leurs capacités mémoire et /ou de traitement, leurs connexions (USB, série, bus), etc..) des informations relatives à l’exécutable actif lui-même (comme un identifiant de l’exécutable actif et/ou sa taille mémoire), des informations relatives à l’application passive à partir de laquelle a été généré cet exécutable actif (par exemple une information présente dans la description de l’application passive, comme un identifiant de l’application, un libellé (explicatif par exemple) associé à l’application, un format et/ou une taille minimale ou maximale d’au moins un paramètre d’entrée ou de sortie de l’application), des informations relatives à au moins un dispositif ou processus, source et/ou consommateur de données mises à disposition sur un canal sélectionné pour l’application (par exemple une information présente dans la description des canaux du bus de données, comme un identifiant et/ou un libellé de ce dispositif ou processus, source et/ou consommateur de données, un format et/ou une taille minimale ou maximale d’au moins une donnée mise à disposition par/pour ce dispositif sur le bus, etc.. Un opérateur peut ainsi avoir la possibilité, par exemple, de vérifier la configuration de l’exécutable actif. Des informations relatives à l’état courant du bus, aux dispositif et/ou processus, source et/ou consommateur de données, présents à l’instant courant sur le bus et/ou aux autres exécutables en cours d’exécution sur la plateforme et aux dispositif ou processus, source et/ou consommateur de données pour ces autres exécutables peuvent également être rendus. Le rendu peut être optionnel dans certains modes de réalisation. Dans certains modes de réalisation, le procédé peut comprendre une mise à jour 352 éventuelle de l’exécutable actif. Une telle mise à jour 352 peut prendre par exemple la forme d’un remplacement d’une version antérieure d’un processus actif par une version ultérieure (générée comme déjà exposé par le procédé de la présente demande). Dans certains modes de réalisation, l’exécutable actif peut par exemple recevoir via un canal spécifique du bus de donnée une commande de désabonnement à au moins un canal sélectionné (ou en variante une commande de désabonnement à une source de données utilisant ce canal) et une nouvelle commande d’abonnement à un nouveau canal (ou en variante une nouvelle commande d’abonnement à une source de données utilisant ce canal) .L’exécution d’une telle commande peut par exemple comprendre une validation automatique de la commande, utilisant la table de conversion introduite précédemment. Une telle mise à jour peut par exemple survenir lorsque les données d’une source de données nouvellement présentes dans le système (un capteur par exemple), sont plus pertinentes que celles d’une source de données déjà présentes dans le système. Une telle possibilité de mise à jour peut être optionnelle dans certains modes de réalisation. Dans l’exemple illustré en , le procédé peut comprendre un déploiement 360 de l’exécutable actif créé. Ce déploiement 360 comprendre un lancement 362 de l’exécutable actif (sur la plateforme donnant accès à plusieurs exécutables introduite ci-dessus par exemple). Ainsi, dans l’exemple illustré en , où l’exécutable actif est créé sous forme d’un environnement d’exécution de type « Docker » ©, lors du déploiement du docker, le programme principal (ie l’exécutable actif) du docker se lance. Dans certains modes de réalisation, où la mise en correspondance est effectuée avant création de l’exécutable actif, celui-ci s’abonne automatiquement aux canaux sélectionnés correspondant au(x) paramètre(s) d’entrée de l’application passive. Lors de la réception d’au moins une donnée via au moins un de ces canaux, l’exécutable la convertit éventuellement puis invoque l’exécutable « passif » comme expliqué ci-avant, s’il a obtenu l’ensemble des paramètres d’entrée (ou au moins ceux n’ayant pas de valeur par défaut) de l’application. Si une première donnée correspondant à un premier paramètre d’entrée est reçue alors qu’aucune donnée n’est encore disponible pour un second paramètre d’entrée, la première donnée peut être stockée temporairement (au moins jusqu’à l’expiration d’une première durée (time out selon la terminologie anglaise) jusqu’à réception de données correspondant aux autres paramètres d’entrée de l’application. L’invocation de l’application peut donc être effectuée de façon asynchrone par rapport à la mise à disposition de données sur un canal. Dans certains modes de réalisation, la mise en correspondance peut être effectuée manuellement, par exemple après le lancement de l’exécutable actif. Dans de tels modes de réalisation, la mise en correspondance peut être effectuée plusieurs fois (par exemple quand un nouveau canal de données, ou une nouvelle source de données paraît intéressant à un opérateur, ou quand un nouveau consommateur de données, pouvant être intéressé par le résultat de l’exécution de l’application passive est nouvellement présent dans le système). Dans de tels modes de réalisation, pouvant induire une modification des souscriptions aux canaux du bus de données, le module logiciel peut comprendre un désabonnement de certains canaux. De tels modes de réalisation peuvent permettre par exemple de modifier les sources de données utilisées comme paramètres d’entrée de l’application passive, comme de modifier l’utilisation des résultats d’exécution de l’application, sans arrêter l’exécution de l’exécutable actif. Le procédé objet de la présente demande a été détaillé ci-dessus. Un tel procédé, dans au moins certains de ses modes de réalisation; peut par exemple aider un opérateur à construire et à lancer (par exemple de façon simple) des exécutables actifs, ou autonomes, utilisant des procédures automatisées, et éventuellement à combiner facilement ces exécutables (par exemple via des fonctionnalités de chainage d’action offertes par une interface homme machine de la plateforme), par exemple via des fonctionnalités de chainage connues sous le nom de « low code » (comme par exemple l’outil « NodeRed »). On présente un exemple d’utilisation du procédé de la présente demande en liaison avec la : Dans cet exemple, on suppose que le système 100 comprend une machine industrielle telle qu’un convoyeur M1 512, M2 514, installée une zone industrielle Z1 510. Le procédé est mis en œuvre: d’une part pour obtenir une première procédure P1 automatique effectuant un contrôle visuel de la qualité des pièces produites par la machine industrielle, avec arrêt du convoyeur et génération d’un message (email, sms) en cas de défaut, et d’autre part pour obtenir une seconde procédure P2 automatique limitant l’accès à une zone Z1 510 dans laquelle est effectué le contrôle par la procédure P1 car celle-ci peut présenter un danger pour des opérateurs du fait des arrêt et redémarrage du convoyeur. L’automatisation de la procédure P1 nécessite par exemple le déploiement d’un exécutable actif (ici un Image Docker) I1 créé , selon le procédé de la présente demande, à partir d’une application IA1 d’un fournisseur F1, spécialisé en vision par ordinateur. Par exemple, l’application passive A1 peut être une application mettant en œuvre des techniques d’intelligence artificielle (IA) pour détecter des fissures dans un objet, et ayant : un paramètre d’entrée au format Base64, JPEG (pour « Joint Photographic Expert Group »), PNG (pour » Portable Network Graphics »), SVG (pour « Scalable Vector Graphics »), ou WebP (pour « Web Picture » ), permettant à l’application d’acquérir une photo de l’objet ; un paramètre de sortie sous forme d’un booléen, ou JSON représentatif de la détection ou non d’une fissure et/ou éventuellement de la localisation sur l’image de la fissure. Dans une zone de supervision 530, un collecteur de données 532 en provenance de capteurs collecte 522 en temps réel les données des capteurs. Ainsi, à chaque détection la caméra C1 transmet ses données (ici des images) au collecteur 532 qui les distribue via le bus de données 538 (par exemple sur des canaux spécifiques) aux exécutables I1 534 et I2 536. L’exécutable actif I1 souscrit par exemple à un canal de données S1 véhiculant des données de format base 64 (correspondant par exemple à des images publiées par une caméra C1 512 située à proximité du convoyeur). L’exécutable actif I1 reçoit ainsi les images de la caméra C1 et les utilise pour invoquer l’application IA1 qui analyse ces images. Les images peuvent par exemple être véhiculées dans un format binaire via un des canaux ou être véhiculées en format Base64 . L’exécutable I1 publie à chaque analyse d’une image par l’application IA1 le résultat (booléen) de cette analyse dans un second canal S2. Dans cet exemple, un exécutable « lowcode » LC1 peut en outre être créé pour utiliser les résultats fournis via le canal S2 par l’exécutable I1. Par exemple l’exécutable LC1 peut souscrire au canal S2 et à chaque réception via ce canal d’une donnée (« True » par exemple) indiquant un défaut, il envoie un email ou sms d’alerte à un contact dont les coordonnées sont accessibles à l’exécutable LC1. Par ailleurs, l’automatisation de la procédure P2 nécessite par exemple le déploiement d’un exécutable actif (ici un Image Docker également) I2 créé, selon le procédé de la présente demande, à partir d’une application IA2 d’un fournisseur F2, spécialisé dans la détection de franchissement. L’exécutable actif I2 souscrit par exemple au même canal de données S1 que l’exécutable actif I1 (véhiculant des données de format base 64 correspondant par exemple à des images publiées par la même caméra C1. L’exécutable actif I2 536 reçoit ainsi les images de la caméra C1 et les utilise pour invoquer l’application IA2 qui analyse ces images pour détecter un franchissement d’un délimitateur de zone (ici Z1). L’exécutable I2 publie à chaque analyse d’une image par l’application IA2 le résultat (booléen) de cette analyse dans un troisième canal S3. Un exécutable de type « low code » (par exemple l’exécutable LC1 ou un autre exécutable) souscrire au canal S3 et à chaque réception via ce canal S3 d’une donnée (« True » par exemple) indiquant un franchissement du délimitateur de la zone Z1, il envoie un email ou sms d’alerte à un contact dont les coordonnées sont accessibles à l’exécutable LC1. L’exécutable IA2 publie une donnée (par exemple une donnée booléenne dont la valeur correspondant à une commande d’arrêt par exemple) dans le canal des contrôleurs des machines M1 et M2 qui à leur tour détectent cette donnée et interprètent cette valeur et arrêtent 524 les convoyeurs M1 et M2 (par exemple des jumeaux numériques des machines M1 et M2). L’exemple ci-dessus montre l’application du procédé de la présente demande pour obtenir, de façon au moins partiellement automatique, et plus facilement que certaines solutions de l’art antérieur, des procédures complexes de contrôle, particulière aux besoins d’un système et/ou de ses utilisateurs. Des exemples d’implémentation ont été testés par les inventeurs, avec par exemple: une machine disposant au minimum de 2 CPU, 2Go de RAM, une latence inférieure à 10ms, un nombre d’ exécutables actifs de l’ordre d’une dizaine ; des connectiques USB ; des capacité de connectivité par Ethernet ; des machines industrielles du client avec automate connectable via Ethernet ou sans fil ; des capteurs connectables via Ethernet ou sans fil ; des applications comportant des techniques d’Intelligence Artificielle et/ou des services, de fournisseurs du marché. Au moins certains modes de réalisation du procédé de la présente demande peuvent aider une entreprise/un opérateur (ou utilisateur) à limiter le coût et/ou l’impact de l'automatisation d’opérations afférentes à son activité, tout en aidant à maintenir un niveau de performance de ces opérations. Au moins certains modes de réalisation du procédé de la présente demande peuvent par exemple aider un industriel à limiter les coûts d’installation ou d’usage de matériel (comme des capteurs ou des serveurs) en lien avec une application (en utilisant par exemple du matériel déjà opérationnel en lien avec d’autres applications). Au moins certains modes de réalisation du procédé de la présente demande peuvent par exemple aider un industriel à limiter la densité en matériel dans un environnement physique tel un site industriel. Au moins certains modes de réalisation du procédé de la présente demande peuvent par exemple aider un industriel à limiter l’hétérogénéité de son parc logiciel et/ou matériel et/ou à simplifier les modalités de surveillance, d’évolution et/ou de maintenance de ce parc. Au moins certains modes de réalisation du procédé de la présente demande peuvent par exemple aider un industriel à limiter les conflits d’accès à des automates de machines, dont l’impact peut être désastreux Au moins certains modes de réalisation du procédé de la présente demande peuvent par exemple aider à obtenir, de façon au moins relativement simple, des analyses de bout en bout de certaines chaînes de production.. La présente demande peut s’’appliquer à des applications logicielles « passives » diverses et notamment des applications en lien avec tout type d’équipement (comme de type « IoT » (pour « Internet of Things » selon la terminologie anglaise) ou industriel, fixe ou mobile, etc..) Par exemple, le procédé de la présente demande peut être mise en œuvre dans les sites industriels possédant un parc de machines équipées d’automates, pour aider à automatiser des procédures complexes. Ainsi, il peut par exemple créer des exécutables actifs à partir d’applications « passives » de divers fournisseurs, par exemple des fournisseurs spécialisés dans les problématiques suivantes : Contrôle de sécurité de zone avec arrêt automatisé et notification des alertes au personnel habilité ; Contrôle de qualité des pièces usinées à la sortie de machines d’usinage avec isolement des pièces défectueuses (par exemple dans des zones différentes selon leur niveau et/ou type de défaut) ; Application de calibrage automatique après détection de défaut ; Détection préventive de panne via des capteurs de vibration et des applications mettant en œuvre des techniques d’’Intelligence Artificielles associées Collecte de données et génération de statistiques et aux métriques Modifications de procédures de production à la volée et mesure des impacts de différentes versions de procédures. Procédé de déploiement au moins partiellement automatique d’une application logicielle passive dans un réseau de communication, ledit procédé comprenant : Une obtention du code binaire de ladite application passive et d’une désignation du ou des type(s) de données consommées et/ou produites par ladite application ; Une sélection au moins partiellement automatique d’au moins un accès aux données d’au moins une source de données dudit réseau et/ou vers au moins un consommateur de données dudit réseau, ladite sélection tenant compte dudit au moins un type désigné et d’au moins un type de données attendu via ledit accès; Une création automatique d’un exécutable actif dont au moins un processus logiciel comprend une invocation de ladite application passive avec en paramètre(s) d’entrée au moins une donnée obtenue via ledit accès et/ou avec en paramètre(s) de sortie au moins une donnée à émettre via ledit accès. Procédé selon la revendication 1 où ledit procédé comprend un ajout dans une bibliothèque d’exécutables actifs dudit réseau de communication dudit exécutable actif créé. Procédé selon la revendication 2 où ledit exécutable ajouté est associé dans ladite bibliothèque à ladite au moins une source de données et/ou audit au moins un consommateur de données. Procédé selon l’une quelconque des revendications 1 à 3 où ledit procédé comprend un lancement dudit exécutable actif ou une proposition d’un tel lancement. Procédé selon l’une quelconque des revendications 1 à 4 où ladite désignation est obtenue par accès à un fichier descriptif des données consommées et/ou produites par ladite application. Procédé selon l’une quelconque des revendications 1 à 5 où ledit accès est un accès à une base de données. Procédé selon l’une quelconque des revendications 1 à 5 où ledit au moins un type de données attendu via ledit accès est obtenu par scrutation dudit réseau. Procédé selon l’une quelconque des revendications 1 à 5 ou 7 où ledit accès est un canal d’un bus de données dudit réseau. Procédé selon la revendication 8 où lesdites données obtenues via ledit canal sont obtenues par souscription dudit processus logiciel audit canal de données pour recevoir les données en provenance de ladite au moins une source de données. Procédé selon l’une des revendication 8 ou 9 où ledit processus logiciel comprend une transmission desdites données à émettre sur ledit canal.