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.