FR 3144351 A1 20240628 FR 2214244 A 20221222 Pipeline de traitement de données, comprenant une pluralité de micro-services (MicServ) partageant une même structure et configurés pour échanger des données entre eux par l’intermédiaire d’un bus de service d’entreprise (ESB), chaque micro-service étant mis en œuvre au moyen d’un bloc de base (100) comprenant un cœur logique (Lgc) encapsulé par structure logicielle (FWK) limitée à cinq blocs d’interface chacun en communication avec le cœur logique (Lgc) : un premier bloc d’interface (ASync) de messagerie asynchrone ; un deuxième bloc d’interface (Sync) de communication bidirectionnelle directe de manière synchrone avec le bus (ESB) ; un troisième bloc d’interface (Journ.Intrf) d’enregistrement dans un fichier journal (Journ) de l’activité des cinq blocs d’interface et du cœur logique (Lgc) ; un quatrième bloc d’interface (Strg.Intrf) de lecture et d’écriture dans un stockage permanent (Strg) ; un cinquième bloc d’interface (Config.Intrf) de chargement de configuration. Figure à publier avec l’abrégé : Fig. 2 Infrastructure logicielle légère pour l’intégration de nœuds de décision dans un traitement automatisé de forage de données DOMAINE TECHNIQUE DE L’INVENTION L'invention concerne une infrastructure logicielle légère facilitant l’intégration de nœuds de décision dans une activité de traitement automatisé de forage et de classification de données par des modules d’intelligence artificielle et des règles métiers élémentaires. ARRIERE PLAN TECHNOLOGIQUE Le forage de données désigne l’analyse de données brutes selon différentes méthodes, complémentaires les unes des autres, ayant pour but de transformer ces données brutes en informations utiles, en établissant des relations entre les données, par exemple en effectuant un tri de ces données. Une telle analyse repose sur des algorithmes pouvant être complexes et mettant en œuvre différents types d’analyse au sein d’un arbre décisionnel comportant des nœuds dits nœuds de décisions. Parmi les types d’analyse mis en œuvre, on peut citer la recherche d’associations entre des données ou des événements, la recherche de séquences d’événements, la recherche de nouvelles classifications pertinentes pour le classement des données, le partitionnement de données qui consiste en la division d’un ensemble de données en groupes homogènes, ou encore l’analyse prédictive qui consiste à analyser des faits présents pour en tirer des hypothèses prédictives sur des événements futurs. Une analyse complète peut nécessiter la combinaison de chacun de ces types d’analyse, qui peuvent chacun être décomposés en tâches de base relativement simples prises individuellement, mais dont l’assemblage peut s’avérer ardu. En effet, l'acheminement des données à travers différents nœuds de décision, formant un ensemble complexe de traitement des données et d'inférence dit « pipeline de traitement de données », est d’autant plus difficile que l’analyse souhaitée est exhaustive et que la quantité de données à disposition est massive, que ces données sont continuellement renouvelées et proviennent de sources de formats hétérogènes. Il existe de nombreux principes de conception pour réaliser un tel pipeline, tels que la construction de micro-services ou l'architecture hexagonale, mais il n'existe pas de cadre concret ni de guide opérationnel pour le développer et le rendre facile à intégrer rapidement, à superviser et à maintenir. Ainsi, une solution satisfaisante d’un point de vue pratique reste encore à mettre en place. Un objet de l’invention est de fournir une infrastructure logicielle légère avec des interfaces de programmation d’application (API) et une encapsulation logique standardisée permettant d'accélérer et d'harmoniser la création de micro-services communiquant entre eux par l’intermédiaires des APIs, formant ainsi une chaîne de traitement intégrée. Au moyen de cette infrastructure, les micro-services peuvent échanger de manière bidirectionnelle des données de manière transparente par le biais de méthodes asynchrones ou synchrones et mettre en œuvre une séquence complexe de processus de décision, par exemple composée de nœuds de décision d'intelligence artificielle et de règles de consolidation d'entreprise. Chaque nœud, intégré dans la chaîne de traitement, utilise l’infrastructure logicielle selon l’invention, conçue pour fournir les fonctions essentielles à tout algorithme (chargement de paramètres, persistance de données, production de traces sur l’activité interne, échanges synchrones et échanges asynchrones de messages) tout en (1) limitant les technologies utilisées et (2) standardisant les pratiques de codage. Cela permet de simplifier le processus de supervision et de maintenance en connectant chaque nœud de la chaîne de traitement de manière cohérente avec une méthode unique. En vue de la réalisation de ce but, un aspect de l’invention est un pipeline de traitement de données, comprenant une pluralité de micro-services partageant une même structure et configurés pour échanger des données entre eux par l’intermédiaire d’un bus de service d’entreprise, dans lequel chaque micro-service est mis en œuvre au moyen d’un bloc de base comprenant un cœur logique encapsulé par structure logicielle limitée à cinq blocs d’interface chacun en communication avec le cœur logique, dans lequel les cinq blocs d’interface sont : un premier bloc d’interface comprenant une messagerie asynchrone ; un deuxième bloc d’interface configuré pour permettre une communication bidirectionnelle directe de manière synchrone avec le bus de service d’entreprise ; un troisième bloc d’interface configuré pour enregistrer dans un fichier journal l’activité des cinq blocs d’interface et du cœur logique ; un quatrième bloc d’interface configuré pour permettre la lecture et l’écriture de données dans ou vers un stockage permanent de données ; un cinquième bloc d’interface est configuré pour charger la configuration du cœur logique et des quatre autres blocs d’interface mentionnés ci-dessus à partir d’un fichier de configuration. Un pipeline de traitement de données selon l’invention est particulièrement simple et aisé à mettre en place, à maintenir et à modifier, reposant sur une architecture légère et extrêmement modulaire à base de blocs présentant une même structure et gérables par l’intermédiaires d’un même système d’interfaces. Selon des caractéristiques additionnelles non-limitative du premier aspect de l’invention, considérées individuellement ou selon toute combinaison techniquement réalisable : - chacun des blocs d’interface peut être configuré pour échanger des données avec les autres blocs d’interface ; - chacun des blocs d’interface peut être configuré pour échanger des données avec les autres blocs d’interface sans passer par le cœur logique ; - chaque micro-service peut être configuré pour échanger des données avec les autres micro-services du pipeline de données au moyen du bus de service d’entreprise (ESB) via les premiers blocs d’interface ; - chaque micro-service peut enregistrer son activité interne dans le fichier journal selon un format standardisé commun à la pluralité de micro-services ; - un enregistrement dans le fichier journal d’un événement d’une activité interne de chaque micro-service peut comprendre au moins une date, une indication de criticité, une identification du micro-service concerné, une identification de l’événement, et une description de l’événement ; - chaque micro-service peut utiliser un même horodatage pour enregistrer l’activité des cinq blocs d’interface et du cœur logique dans le fichier journal la structure logicielle est unique et partagée entre chacun des micro-services ; - le deuxième bloc d’interface peut être configuré pour diriger un appel externe vers l’un des quatre autres blocs d’interface ou vers le cœur logique, sur la base d’un identifiant du type d’appel porté par le message ; - un premier des micro-services peut comprendre un cœur logique configuré pour enregistrer une identité de chacun des micro-services connectés au pipeline de traitement de données ; et - un second des micro-services peut comprendre un cœur logique configuré pour consulter les identités de chacun des micro-services enregistrées par le cœur logique du premier des micro-services. BREVE DESCRIPTION DES FIGURES D’autres caractéristiques et avantages de l’invention ressortiront de la description détaillée de l’invention qui va suivre en référence aux figures annexées sur lesquels : La représente un bloc de base de l’infrastructure logicielle selon l’invention ; et La représente un pipeline de traitement de données selon l’invention, intégrant une pluralités de blocs de base illustrés par la . DESCRIPTION DETAILLEE DE L’INVENTION Les figures 1 et 2 illustrent l’infrastructure logicielle selon l’invention. La illustre un bloc de base 100 de l’architecture logicielle selon l’invention. Ce bloc constitue un micro-service MicServ. Le cœur logique du bloc, Lgc dans la , est constitué d’une logique informatique dédiée à une tâche unique et traduisant un algorithme applicatif, par exemple une règle métier ou une composante d’une application de forage de données. La illustre une intégration de cinq micro-services MicServ au sein de l’infrastructure logicielle selon l’invention, formant par exemple un pipeline de traitement de données DataPip connecté à une application App au moyen d’un module de supervision SuperV qui est contrôlé par un utilisateur Usr via une interface d’utilisateur Usr.Interf, par exemple une interface graphique. Un bus de service d’entreprise ESB (Enterprise Service Bus, en terminologie anglaise) est configuré pour communiquer avec chacun des micro-services MicServ ainsi qu’avec un module Calc de l’application App, dédié au traitement de données. Chacun des micro-services comprend un cœur logique qui lui est propre, assurant une fonction particulière au sein du pipeline de traitement de données. Une structure logicielle FWK encapsule le cœur logique Lgc de chacun des micro-service MicServ du pipeline de traitement de données et les isole des communications extérieures. Cette structure logicielle FWK comprend cinq blocs d’interface permettant au cœur logique du micro-service de fonctionner de façon optimale en le déchargeant de toutes les tâches ne relevant pas directement de la tâche unique à laquelle il est dédié. En outre, l’interface logicielle FWK est configurée de manière à fournir des connexions directes entre chacun des blocs d’interfaces, ce qui leur permet de communiquer directement les uns avec les autres et évite d’avoir à perturber les calculs du cœur logique Lgc pour des opérations ne relevant pas directement de sa fonction particulière. Bien entendu, d’autres modules ou services extérieurs que ceux cités dans ce document peuvent communiquer avec les micro-services, soit via le bus de service d’entreprise ESB soit directement via le deuxième bloc d’interface Sync. Un premier bloc d’interface ASync est configuré pour permettre une communication bidirectionnelle indirecte au moyen d’une messagerie asynchrone avec un autre composant externe tel qu’un autre micro-service, en utilisant une méthode de publication et d'abonnement (Publish-subscribe en terminologie anglaise). Le cœur logique peut ainsi demander de router un message sur le bus de service d'entreprise ESB. Les autres micro-services qui sont abonnés à cette route peuvent recevoir et interpréter ce message. Aucune réponse n'est attendue de l’émetteur du message, sauf si le cœur logique est configuré pour écouter et recevoir des messages sur une route spécifique, par exemple un canal de réponse défini dans un fichier de configuration. Un deuxième bloc d’interface Sync est configuré pour permettre une communication bidirectionnelle directe de manière synchrone selon une approche ReST (Representational State Transfer). Certains appels externes reçus par ce deuxième bloc peuvent être traités directement au niveau des blocs d’interfaces, par exemple pour fournir des informations concernant le statut ou la version du micro-service. Le deuxième bloc Sync d’interface est configuré de manière à générer un message à destination de l’un des quatre autres blocs d’interface en fonction du type d’appel reçu, sans passer par le cœur logique Lgc. Alternativement, un appel externe peut être transféré au cœur logique, à la condition que le traitement de cet appel soit lié à la tâche unique du cœur logique Lgc, comme par exemple la transmission du dernier résultat calculé par le cœur, tel que la prédiction d’un coefficient de pertinence ou le résultat d’une opération de tri. Un appel externe est un message émis par un élément extérieur à un micro-service considéré. L’élément extérieur peut être un autre micro-service, l’application App ou tout autre composant connecté directement ou indirectement au micro-service considéré. Cet appel externe est porteur de métadonnées comportant un identifiant du type d’appel. Le deuxième bloc d’interface est configuré pour orienter chaque appel externe vers l’un des quatre autres blocs d’interface ou vers le cœur logique, selon le type de l’appel, sur la base de l’identifiant du type d’appel porté par le message et de l’identifiant de son émetteur. Le type d’appel peut être indicatif d’un degré d’urgence à traiter l’appel en question, d’un bloc d’interface auquel il doit être transmis, ou encore du fait que l’appel est lié à la tâche unique du cœur logique du micro-service considéré. Dans un micro-service, les traitements ou calculs effectués par le cœur logique Lgc et les deux blocs Sync et Async sont parallélisés en multithreading de manière à pouvoir agir indépendamment les uns des autres. Un intérêt de ce principe apparaît lorsque, par exemple, le cœur logique est en cours de calcul : le cœur logique peut mettre à disposition l’état d’avancement de ce calcul pour le bloc Sync ou le bloc Async, qui, en cas d’interrogation externe, pourront consulter et transmettre cet état d’avancement à un élément externe au micri-service sans stopper ni perturber le travail en cours de son cœur logique. Un troisième bloc d’interface Journ.Intrf est configuré pour enregistrer dans un même fichier journal Journ l’activité interne des éléments composant le micro-service MicroServ (les cinq blocs d’interface et le cœur logique) selon un format standardisé. Cela signifie que, dans le pipeline de traitement de données, les événements enregistrés dans le fichier journal sont identifiés selon une nomenclature commune à tous les micro-services concernés du pipeline. La fonction du fichier journal est d’enregistrer tous les événements liés à l’utilisation du pipeline. Il permet par exemple de retrouver, pour un ensemble de micro-services échangeant des messages portant des données, l’ordre dans lequel les messages ont été envoyés et traités. La nomenclature est définie de manière à associer à chaque événement enregistré, une date d’occurrence, un niveau de criticité, une identification de l’élément émetteur (l’un des blocs d’interfaces ou le cœur logique d’un micro-service identifié), un code descriptif du type de l’événement (démarrage, arrêt, réception, envoi, etc…), et une description détaillée. Grâce à l’interconnexion interne de la structure logicielle FWK des blocs d’interfaces, il est par exemple possible de reconfigurer la nomenclature en question en fonction des informations stockées dans le fichier de configuration. En ce qui concerne le cas particulier de la date d’occurrence, un horodatage commun est utilisé par les micro-services du pipeline. Il peut s’agir de l’utilisation d’une horloge commune en utilisant un protocole tel qu’un protocole de temps réseau ou NTP pour Network Time Protocol en anglais, par exemple dans le cas où tous les micro-serveurs sont hébergé par un même serveur, l’horloge du serveur peut constituer l’horloge commune. Il peut également s’agir d’une pluralité d’horloges de différents serveurs lorsque les micro-services du pipeline sont hébergés par ces différents serveurs, l’important étant que ces différentes horloges soient synchronisées entre elles. Dans tous les cas, les dates d’occurrences des événements enregistrés sont immédiatement comparables les unes vis-à-vis des autres de manière à pourvoir reconstituer de manière immédiate l’ordre d’occurrence des événements distribués dans les fichiers journaux de chacun des micro-services. L’intérêt de cette centralisation standardisée est de permettre une agrégation aisée des données enregistrées, permettant leur consolidation temporelle et événementielle de manière extrêmement simple, et leur traitement ultérieur par un analyseur de journal pour comprendre globalement l’activité d’un micro-service donné ou dans le cadre d’un passage à l’échelle de l’ensemble du pipeline de traitement de données DataPip. Un quatrième bloc d’interface Strg.Intrf est configuré pour permettre la lecture et l’écriture de données dans ou vers un stockage permanent Strg de données tel qu’une base de donnée, par exemple afin de stocker les résultats de traitement de données par le cœur logique Lgc, sans que ce dernier ne prenne en charge les détails de l’écriture des données mais au contraire délègue cette tâche au quatrième bloc d’interface. Un cinquième bloc d’interface Config.Intrf est configuré pour charger les configurations respectives du cœur logique et des quatre autres blocs d’interface mentionnés ci-dessus à partir d’un fichier de configuration Config, et transmettre à ses éléments leurs configurations respectives. Il peut s’agir par exemple de charger la configuration du journal, la version du micro-service, ou la configuration spécifique du cœur logique Lgc. Chacun des blocs d’interface est configuré pour échanger des données (configuration, journal, données à stocker de manière permanente etc…) avec les autres blocs d’interface sans passer par le cœur logique. Intégré au sein d’un pipeline de traitement de données, chaque micro-service MicServ est configuré pour échanger des données avec les autres micro-services du pipeline de traitement de données au moyen du bus de service d’entreprise ESB via les premiers blocs d’interface ASync chacun constitués d’une messagerie asynchrone. Ce mode de fonctionnement permet d’optimiser le fonctionnement du cœur logique Lgc en le laissant terminer, sans l’interrompre, les traitements en cours. Dans le pipeline de traitement de données illustré par la , deux des cinq micro-services ont un rôle de supervision des autres micro-services. L’un de ces deux micro-services constitue un registre : son cœur logique, indiqué comme Reg dans la , est configuré pour enregistrer dans sa mémoire Strg l’identité et la tâche unique associées à chacun des micro-services MicServ connectés au pipeline de traitement de données. Ce micro-service permet ainsi la découverte centralisée des services offerts par le pipeline : une application se connectant au pipeline consulterait en premier le registre pour savoir s'il existe une application particulière, telle qu’un classifieur permettant une prédiction binaire dans un domaine particulier ou toute autre fonction recherchée par l’application et potentiellement offerte par le pipeline. L’autre de ces deux micro-services joue un rôle de surveillance, c’est-à-dire de chien de garde ou de watchdog en terminologie anglaise, des micro-services du pipeline de traitement de données : son cœur logique, indiqué comme WDog dans la , est configuré pour consulter le registre formé par le micro-service de cœur logique Reg, vérifier le statut de chacun des micro-services qui y sont enregistrés par exemple en lisant et copiant les derniers événements enregistrés dans leurs fichiers journaux respectifs, et mettre les derniers événements enregistrés ainsi récupérés à disposition d’une application extérieure à travers le bloc d’interface Sync. Toutes ces opération sont effectuées sans avoir besoin d’accéder aux cœurs logiques des micro-services surveillés, les blocs d’interface suffisant à cette tâche et déchargeant donc le cœur de celle-ci. Le pipeline de traitement de données est configuré de sorte qu’un utilisateur Usr peut, via par exemple une interface, échanger des données avec le deuxième bloc d’interface Sync. Comme décrit plus haut, ce bloc est configuré de manière à minimiser les transmissions d’appels externes au cœur logique. Il permet cependant une bonne réactivité du système vis-à-vis de l’utilisateur. Ici, le micro-service de cœur logique WDog sert d’intermédiaire entre le module de supervision SuperV contrôlé par l’utilisateur et les autres micro-services, jouant un rôle de concentrateur évitant au module de supervision d’avoir à interroger l’ensemble des autres micro-services. La structure logicielle FWK peut être dupliquée de sorte que chaque micro-service en possède son propre exemplaire, ou bien peut être partagée par ces micro-services. Dans ce dernier cas, la maintenance du pipeline est facilitée en ce qu’une mise à jour de la structure logicielle s’applique implicitement à chacun des micro-services. Une architecture logicielle telle que décrite ci-dessus, avec des blocs de base contenant un cœur logique Lgc encapsulé par structure logicielle FWK limitée à cinq blocs d’interface assurant les services essentiels de fonctionnement d’un service informatique, permet d’assurer une excellente compatibilité entre des micro-services chacun mis en œuvre au moyen de l’un de ces blocs de base. En effet, la limitation du type d’interfaces amène une limitation du type de données ou d’appels à gérer, et donc facilite l’intégration, la supervision, ou encore la maintenance d’un pipeline de données basé sur cette architecture logicielle. Bien entendu l'invention n'est pas limitée au mode de mise en œuvre décrit et on peut y apporter des variantes de réalisation sans sortir du cadre de l'invention tel que défini par les revendications. Pipeline de traitement de données, comprenant une pluralité de micro-services (MicServ) partageant une même structure et configurés pour échanger des données entre eux par l’intermédiaire d’un bus de service d’entreprise (ESB), dans lequel chaque micro-service est mis en œuvre au moyen d’un bloc de base (100) comprenant un cœur logique (Lgc) encapsulé par structure logicielle (FWK) limitée à cinq blocs d’interface chacun en communication avec le cœur logique (Lgc), dans lequel les cinq blocs d’interface sont : - un premier bloc d’interface (ASync) comprenant une messagerie asynchrone ; - un deuxième bloc d’interface (Sync) configuré pour permettre une communication bidirectionnelle directe de manière synchrone avec le bus de service d’entreprise (ESB) ; - un troisième bloc d’interface (Journ.Intrf) configuré pour enregistrer dans un fichier journal (Journ) l’activité des cinq blocs d’interface et du cœur logique (Lgc) ; - un quatrième bloc d’interface (Strg.Intrf) configuré pour permettre la lecture et l’écriture de données dans ou vers un stockage permanent (Strg) de données ; - un cinquième bloc d’interface (Config.Intrf) est configuré pour charger la configuration du cœur logique et des quatre autres blocs d’interface mentionnés ci-dessus à partir d’un fichier de configuration (Config). Pipeline de traitement de données selon la revendication 1, dans lequel chacun des blocs d’interface est configuré pour échanger des données avec les autres blocs d’interface. Pipeline de traitement de données selon l’une quelconque des revendications 1 à 2, dans lequel chacun des blocs d’interface est configuré pour échanger des données avec les autres blocs d’interface sans passer par le cœur logique. Pipeline de traitement de données selon l’une quelconque des revendications 1 à 3, dans lequel chaque micro-service (MicServ) est configuré pour échanger des données avec les autres micro-services du pipeline de données au moyen du bus de service d’entreprise (ESB) via les premiers blocs d’interface (ASync). Pipeline de traitement de données selon l’une quelconque des revendications 1 à 4, dans lequel chaque micro-service (MicServ) enregistre son activité interne dans le fichier journal selon un format standardisé commun à la pluralité de micro-services. Pipeline de traitement de données selon la revendication 5, dans lequel un enregistrement dans le fichier journal d’un événement d’une activité interne de chaque micro-service comprend au moins une date, une indication de criticité, une identification du micro-service concerné, une identification de l’événement, et une description de l’événement. Pipeline de traitement de données selon l’une quelconque des revendications 1 à 6, dans lequel chaque micro-service (MicServ) utilise un même horodatage pour enregistrer l’activité des cinq blocs d’interface et du cœur logique (Lgc) dans le fichier journal. Pipeline de traitement de données selon l’une quelconque des revendications 1 à 7, dans lequel la structure logicielle (FWK) est unique et partagée entre chacun des micro-services. Pipeline de traitement de données selon l’une quelconque des revendications 1 à 8, dans lequel le deuxième bloc d’interface est configuré pour diriger un appel externe vers l’un des quatre autres blocs d’interface ou vers le cœur logique, sur la base d’un identifiant du type d’appel porté par le message. Pipeline de traitement de données selon l’une quelconque des revendications 1 à 9, dans lequel un premier des micro-services comprend un cœur logique (Reg) configuré pour enregistrer une identité de chacun des micro-services (MicServ) connectés au pipeline (DataPip) de traitement de données. Pipeline de traitement de données selon la revendication 10, dans lequel un second des micro-services comprend un cœur logique (WDog) configuré pour consulter les identités de chacun des micro-services enregistrées par le cœur logique (Reg) du premier des micro-services.