Réseau bidirectionnel intégré à la blockchain à mémoire longue durée pour la détection d’intrusion en temps réel dans l’Internet des objets médicaux en santé

Résumé

Ce protocole décrit la mise en œuvre d’un système de détection d’intrusion bidirectionnel à court terme intégré à la blockchain pour les réseaux Internet des objets médicaux dans la santé, permettant la détection en temps réel des attaques, la journalisation médico-légale inviolable et l’atténuation automatisée.

Résumé

Les environnements d’Internet des objets médicaux (IoMT) dans la santé nécessitent des systèmes de détection d’intrusion qui non seulement identifient les cyberattaques avec précision, mais offrent aussi des capacités de responsabilité médico-légale, d’auditabilité et de réponse rapide. Les approches conventionnelles de détection d’intrusion mettent principalement l’accent sur la performance de classification tout en offrant un support limité pour l’enregistrement des événements à l’épreuve de la falsification et l’enquête post-incident. Cette étude présente un cadre de détection d’intrusion conscient de la criminalistique qui intègre un réseau Bidirectionnel Long Short-Term Memory (BiLSTM) avec une couche blockchain autorisée pour supporter la détection en temps réel, la journalisation sécurisée et l’atténuation automatisée dans les systèmes IoMT de la santé. Le protocole combine le prétraitement des données, la sélection de fonctionnalités AQU-IMF-RFE, la modélisation temporelle, l’apprentissage basé sur l’attention, les connexions résiduelles et l’enregistrement d’événements basé sur la blockchain. Le modèle BiLSTM étendu a été entraîné et évalué indépendamment sur les ensembles de données de référence UNSW-NB15, CICIDS2017 et Bot-IoT en utilisant un prétraitement reproductible, un partitionnement stratifié des données et des graines aléatoires fixes. Les événements d’intrusion détectés par le modèle ont été enregistrés sur une blockchain Proof-of-Authority via des contrats intelligents permettant une journalisation immuable et des actions de réponse automatisées. Les résultats expérimentaux ont démontré une forte performance de détection d’intrusion avec de faibles taux de faux positifs sur tous les ensembles de données évalués, tout en maintenant la traçabilité judiciaire et la capacité de réponse en temps réel. La couche blockchain offrait des enregistrements d’audit résistants à la falsification et une atténuation automatisée sans introduire une surcharge computationnelle prohibitionnelle. Ces résultats démontrent que l’intégration de la détection d’intrusion basée sur l’apprentissage profond avec la journalisation médico-légale habilitée par la blockchain améliore la fiabilité, la responsabilité et la facilité de déploiement pratique des systèmes de cybersécurité en santé.

Introduction

Dans le système de santé, la numérisation a inauguré une nouvelle ère de services de santé intelligents, connectés et centrés sur le patient. L’infrastructure médicale moderne repose fortement sur la communication réseau et l’échange de données entre capteurs portables, systèmes de surveillance à distance des patients, dossiers médicaux électroniques (^DME)1,2 et plateformes de diagnostic intelligentes. Cependant, cette interconnexion croissante élargit également la surface d’attaque des réseaux de santé, les exposant à des menaces cybernétiques telles que les violations de données, les ransomwares, les attaques par déni de service distribué (DDoS) et les attaques man-in-the-middle³. Ces intrusions entraînent des pertes financières importantes et, plus important encore, peuvent compromettre la sécurité des patients lorsque des données médicales sensibles ou des fonctionnalités critiques de dispositifs sont compromises.

L’ampleur et la complexité des systèmes Internet des objets médicaux (IoMT) aggravent encore ces défis de sécurité. Les réseaux de santé modernes doivent simultanément fournir une communication à faible latence, une grande fiabilité et des garanties de sécurité robustes, des exigences auxquelles les mécanismes de sécurité traditionnels peinent souvent^{à satisfaire 4}. La croissance rapide du trafic IoMT, caractérisée par des sources de données hétérogènes, des schémas de communication dynamiques et des exigences réglementaires strictes telles que la loi sur la portabilité et la responsabilité de l’assurance maladie (HIPAA) et le règlement général sur la protection des données (RGPD), nécessite des systèmes intelligents de détection d’intrusion (IDS) capables d’atteindre des taux de détection élevés tout en minimisant les fausses^{alertes 5}.

Dans les environnements de santé réglementés, la détection d’intrusion n’est pas seulement une exigence opérationnelle, mais aussi une fonction de responsabilité. Les alertes de sécurité peuvent déclencher l’isolement des dispositifs, affecter la continuité des soins, et par la suite faire l’objet d’audits, de revues réglementaires ou d’enquêtes juridiques. Par conséquent, un IDS IoMT efficace doit fournir une détection précise en temps réel, des décisions explicables soutenant le triage des incidents, ainsi que des dossiers inviolables garantissant la non-répudiation et la traçabilité^{médico-légale 6}. Cette exigence déplace l’objectif de détection d’intrusion d’une classification centrée sur la performance vers une gouvernance de sécurité centrée sur la confiance et la responsabilité.

Les techniques d’apprentissage profond, en particulier les réseaux de mémoire à court terme long (LSTM) et de mémoire bidirectionnelle à court terme (BiLSTM), ont démontré une forte capacité à modéliser les dépendances temporelles dans le trafic réseau et à détecter des comportements^{anormaux 7}. Néanmoins, les IDS existants basés sur BiLSTM souffrent fréquemment d’un surajustement, d’une attention insuffisante aux événements temporels critiques, et d’une généralisation limitée à travers des dispositifs IoMT hétérogènes et des environnements de santé. De plus, les réseaux IoMT sont exposés à une grande variété de menaces cybernétiques qui affectent la confidentialité, l’intégrité et la disponibilité (CIA) des données et services médicaux, comme résumé dans le tableau 1.

Type d’attaque	Contexte IoMT	Dimension de la CIA affectée	Impact sur les systèmes de santé
Accès nonautorisé 19	Exploitation de mécanismes d’authentification faibles pour accéder aux appareils des patients ou aux dossiers médicaux	Confidentialité, Intégrité	Fuite de données et contrôle non autorisé des dispositifs médicaux
Usurpation / usurpationd’identité 19	Un dispositif malveillant imite un nœud IoMT légitime	Intégrité	Des lectures erronées pouvant conduire à un mauvais diagnostic ou à un traitement dangereux
Écouteclandestine 21	Interception de données médicales non chiffrées lors de la transmission	Confidentialité	Violations de la vie privée et divulgation d’informations sensibles des patients
Falsification de données / Exploits du firmware19	Modification du firmware de l’appareil ou des données de santé transmises	Intégrité	Diagnostic incorrect ou décisions thérapeutiques inappropriées
Ransomware20	Chiffrement des données des patients ou du firmware des dispositifs médicaux	Disponibilité, Intégrité	Verrouillage des systèmes critiques et retards de traitement
Déni de service (DoS) / Déni de service distribué (DDoS)6	Surcharge des dispositifs médicaux ou des réseaux de santé	Disponibilité	Perturbations de service affectant les systèmes de surveillance et les opérations des unités de soins intensifs (USI)
Attaques par canallatéral 22	Extraction de clés cryptographiques par techniques de synchronisation ou d’analyse de puissance	Confidentialité	Compromission de dispositif et vol de clé cryptographique

Tableau 1 : Cyberattaques courantes affectant les environnements de santé de l’Internet des objets médicaux. Ce tableau résume les cyberattaques représentatives visant les systèmes de l’Internet des objets médicaux (IoMT), leur contexte opérationnel, les dimensions de sécurité de confidentialité, d’intégrité et de disponibilité (CIA) concernées, ainsi que leur impact potentiel sur la prestation des soins, la sécurité des patients et le fonctionnement des dispositifs médicaux.

La technologie blockchain offre plusieurs avantages qui peuvent compléter la détection d’intrusion dans les environnements IoMT. Comme résumé dans le tableau 2, la blockchain permet une journalisation immuable des événements pour la validation médico-légale, facilite l’atténuation automatisée via des contrats intelligents, élimine les points de défaillance isolés grâce à une opération décentralisée, et soutient la conformité aux réglementations de protection des données de santé en maintenant des traces d’audit traçables. Malgré ces avantages, les mécanismes de sécurité basés sur la blockchain restent sous-utilisés dans les IDS de santé.

Caractéristiques	Description	Avantages dans le contexte des soins de santé
Intégrité des données	Chaque transaction est hachée cryptographiquement et liée au bloc précédent	Garantit l’immuabilité des dossiers des patients et des appareils
Détection de falsification	Toute modification des données stockées modifie le hachage de bloc et invalide la chaîne	Permet la détection rapide de modifications non autorisées d’enregistrements
Contrôle d’accès	Les contrats intelligents appliquent des autorisations et des politiques d’autorisation prédéfinies	Restreint l’accès aux informations de santé sensibles aux utilisateurs et appareils autorisés
Provenance des données	Chaque événement est signé numériquement et avec un horodatage	Soutient la traçabilité médico-légale, l’audit et la conformité réglementaire
Consensus à faible latence	Le mécanisme de consensus Proof-of-Authority (PoA) permet une validation rapide des transactions avec une surcharge computationnelle inférieure à la Proof-of-Work	Prend en compte la journalisation des événements quasi en temps réel dans les environnements de santé critiques

Tableau 2 : Avantages de la technologie blockchain pour la santé Internet des objets médicaux Systèmes de détection d’intrusion. Ce tableau résume les principales fonctionnalités de la blockchain et leurs avantages associés dans les environnements de santé Internet des objets médicaux (IoMT). Les capacités listées supportent la journalisation immuable, la détection de falsifications, le contrôle d’accès, la provenance des données et des mécanismes de consensus à faible latence nécessaires pour une détection d’intrusion sécurisée et auditable.

Au-delà de l’évaluation des performances, l’intégration blockchain offre une protection contre de multiples menaces de sécurité dans les environnements IoMT. Le tableau 3 résume les forces et les limites de la blockchain dans ce contexte, en mettant en lumière les menaces efficacement atténuées, telles que la falsification et la répudiation des données, ainsi que les menaces nécessitant des protections supplémentaires. La couche blockchain supporte une journalisation à faible latence adaptée aux environnements de santé en temps réel, la résilience byzantine face aux nœuds défectueux ou malveillants, ainsi qu’une évolutivité sur les réseaux hospitaliers distribués et les dispositifs IoMT.

Menace à la sécurité	Traité par la blockchain ?	Mécanisme	Notes
Falsification de données27	Oui	Liaison cryptographique par hachage	Toute modification invalide l’intégrité de la chaîne
Répudiation26	Oui	Signatures numériques associées à chaque bloc	Empêche le déni des événements d’intrusion enregistrés
Défaillancecentralisée 25	Oui	Registre distribué maintenu entre les passerelles autorisées	Élimine un point de défaillance unique
Attaque Sybil24	Partiel	Consensus de procuration autorisé nécessitant des validateurs de confiance	Peut être atténué par une autorisation validatrice basée sur l’identité
51 % d’attaque23	Partiel	Nécessite la compromission de la majorité des validateurs autorisés	Moins probable dans les déploiements privés de blockchains PoA
Provenance desdonnées 26	Oui	Enregistrements d’événements horodatés et signés numériquement	Soutient la traçabilité médico-légale et la conformité réglementaire

Tableau 3 : Les menaces de sécurité prises en charge par l’intégration de la blockchain dans les environnements de santé de l’Internet des objets médicaux. Ce tableau résume les principales menaces de sécurité liées aux systèmes de l’Internet des objets médicaux (IoMT) et indique dans quelle mesure la technologie blockchain atténue chaque menace. Les mécanismes de protection sous-jacents et les considérations de mise en œuvre sont fournis pour chaque catégorie de menace.

La plupart des IDS existants reposent sur des règles prédéfinies ou des modèles légers d’apprentissage^{automatique 8,9}. Bien que ces approches puissent identifier des schémas d’attaque connus, elles peinent souvent à faire face à la nature dynamique et évolutive des cybermenaces modernes. Ils sont particulièrement inadéquats pour sécuriser des infrastructures de santé basées sur l’IoMT en pleine croissance, où des fausses alertes, une adaptabilité limitée et une mauvaise auditabilité peuvent affecter de manière significative l’efficacité opérationnelle. Les systèmes basés sur des règles génèrent fréquemment des taux élevés de faux positifs car ils ne peuvent pas distinguer de manière fiable les anomalies bénignes des attaques^{réelles 9}. Les modèles conventionnels d’apprentissage automatique entraînés sur des ensembles de données statiques ou obsolètes, ainsi que les approches existantes de détection d’intrusion basées sur l’apprentissage profond, ne généralisent souvent pas les comportements d’attaque émergents, y compris les intrusions^{zero-day 10,11}. De plus, les approches traditionnelles de journalisation centralisée restent vulnérables à la falsification, limitant ainsi la fiabilité des enquêtes médico-légales^{post-incident.} De nombreuses solutions IDS existantes imposent également une surcharge computationnelle importante, ce qui les rend difficiles à déployer sur les dispositifs IoMT et passerelles^{à ressources limitées 13}. En conséquence, les environnements IoMT de santé restent vulnérables aux cyberattaques sophistiquées et à plusieurs stades. Relever ces défis nécessite un cadre intelligent, sécurisé et efficace en ressources, capable d’apprendre les schémas temporels du trafic en temps réel tout en garantissant simultanément la fiabilité judiciaire et la mitigation automatisée des menaces détectées.

Malgré des avancées significatives dans l’apprentissage automatique et la détection d’intrusion basée sur l’apprentissage profond, plusieurs lacunes critiques subsistent. Premièrement, de nombreux modèles IDS existants sont développés et évalués à l’aide de jeux de données statiques et manquent donc d’adaptabilité aux comportements d’attaque en constante évolution. Deuxièmement, bien que les architectures avancées d’apprentissage profond puissent améliorer la précision de la détection, elles offrent souvent une interprétabilité limitée et ne priorisent pas les schémas de trafic cliniquement importants. Troisièmement, et surtout, les cadres IDS actuels ne fournissent généralement pas un support intrinsèque pour la fiabilité judiciaire, l’auditabilité ou la tenue de dossiers immuables, des capacités essentielles à la conformité réglementaire, à l’enquête sur les incidents et à la responsabilité juridique dans les systèmes de santé.

Bien que les mécanismes de journalisation basés sur la blockchain assurent intégrité et transparence des données, ils sont rarement intégrés de manière cohérente avec des modèles avancés de détection d’intrusion basés sur l’apprentissage profond dans des environnements IoMT sensibles à la latence. Les études existantes se concentrent généralement soit sur l’amélioration des performances de détection sans aborder l’intégrité médico-légale, soit sur des mécanismes de sécurité basés sur la blockchain sans intégrer la détection avancée des anomalies temporelles. Par conséquent, une lacune importante subsiste dans le développement d’un cadre unifié capable de fournir simultanément une détection d’intrusion spatio-temporelle en temps réel, une journalisation médico-légale inviolable, une atténuation automatisée et un déploiement pratique dans des environnements IoMT de santé hétérogènes et limités en ressources.

Motivée par ces défis, cette étude vise à développer un cadre de détection d’intrusion qui améliore les réseaux BiLSTM grâce à des mécanismes d’attention et des couches personnalisées pour une meilleure priorisation des fonctionnalités temporelles, intègre la technologie blockchain pour une journalisation des intrusions sécurisées et vérifiables ainsi que des réponses automatisées, et fonctionne efficacement dans des environnements IoMT de santé en temps réel. Nous émettons l’hypothèse que l’intégration d’une architecture BiLSTM étendue axée sur l’attention avec la journalisation médico-légale basée sur blockchain et des mécanismes automatisés d’atténuation améliorera l’efficacité de la détection des intrusions tout en offrant simultanément l’auditabilité, la fiabilité et la responsabilité requises dans les environnements de santé réglementés.

Ce travail répond à une lacune fondamentale dans la recherche en sécurité de l’IoMT en traitant la détection d’intrusion comme un problème de responsabilité judiciaire plutôt que comme un simple problème de classification. Le cadre proposé intègre la détection pilotée par l’intelligence artificielle (IA), l’enregistrement d’événements immuables et les mécanismes de réponse automatisée dans une architecture unifiée qui soutient la sécurité clinique, la conformité réglementaire et la confiance opérationnelle. L’adoption croissante des appareils IoMT et des infrastructures de santé connectées au cloud a fait des réseaux de santé des cibles attrayantes pour les cyberattaques, notamment les ransomwares, la manipulation de données, les accès non autorisés et les attaques par déni de service qui menacent la confidentialité, l’intégrité et la disponibilité des informations des patients. Le cadre proposé Extended BiLSTM–Blockchain établit un processus de sécurité en boucle fermée qui relie directement la détection d’attaque à la validation médico-légale et à l’atténuation automatisée.

Les principales contributions de cette étude sont quinquelles. Tout d’abord, un modèle de détection d’intrusion temporelle aligné cliniquement est développé en étendant une architecture BiLSTM conventionnelle avec un apprentissage temporel bidirectionnel, des connexions résiduelles, des mécanismes d’attention et des couches personnalisées afin d’améliorer la détection de schémas d’attaque complexes dans le trafic des réseaux de santé. Deuxièmement, une couche de sécurité légère basée sur la blockchain est intégrée au modèle BiLSTM étendu pour fournir une journalisation immuable, sécurisée et inviolable des événements d’intrusion et des actions système. Troisièmement, un pipeline IDS en temps réel de bout en bout est développé pour les environnements de santé, permettant une analyse du trafic en temps réel et la prédiction des intrusions avec une faible latence et une grande précision. Quatrièmement, le cadre proposé est évalué de manière exhaustive à l’aide de trois ensembles de données de référence publiques, à savoir UNSW-NB15, CICIDS2017 et Bot-IoT. Enfin, l’architecture est conçue comme un cadre edge-cloud évolutif et extensible, adapté à un déploiement pratique dans les réseaux de santé, les infrastructures médicales et les applications de e-santé.

En combinant les capacités d’apprentissage temporel des réseaux BiLSTM étendus avec la confiance et l’immuabilité offertes par la technologie blockchain, le cadre proposé offre un IDS sécurisé et fiable, adapté aux besoins évolutifs en cybersécurité des environnements de santé. Ce cadre comble les lacunes critiques dans la sécurité des réseaux de santé et établit les bases d’une adoption plus large de l’intégration de l’IA et de la blockchain pour protéger les infrastructures de santé critiques.

Protocole

Toutes les expériences ont été menées exclusivement à partir de jeux de données de référence d’intrusion réseau accessibles publiquement (UNSW-NB15, CIC-IDS-2017 et Bot-IoT), qui contiennent des enregistrements de trafic réseau sans informations personnelles ou médicales identifiables. Les ensembles de données ont été utilisés conformément à leurs licences et conditions d’utilisation respectives. Parce qu’aucun participant humain, échantillon de patients ou données personnelles identifiables n’a été impliqué, l’approbation éthique institutionnelle ni le consentement éclairé n’étaient pas requis.

Aperçu du cadre proposé
Cette section présente le cadre proposé de détection et de prévention des intrusions à double couche pour sécuriser les environnements IoMT. Le cadre intègre un réseau BiLSTM étendu pour la détection d’intrusion spatio-temporelle avec une couche blockchain légère pour la journalisation inviolable et l’atténuation automatisée. Contrairement aux approches IDS conventionnelles qui se concentrent uniquement sur la précision de la détection, l’architecture proposée est conçue pour soutenir simultanément la détection en temps réel, la responsabilité médico-légale et la conformité réglementaire, qui sont des exigences essentielles dans les systèmes de santé. Le flux de travail global et l’architecture du cadre proposé de détection d’intrusion BiLSTM–Blockchain étendu pour les réseaux IoMT sont illustrés dans la Figure 1.

Figure 1. Architecture du cadre proposé de détection d’intrusion BiLSTM–Blockchain pour les réseaux de l’Internet des objets médicaux. Représentation schématique du cadre proposé montrant les flux de travail de formation et de déploiement. Dans le flux de travail d’entraînement, les dispositifs de l’Internet des objets médicaux (IoMT) génèrent un trafic réseau qui subit un prétraitement des données et une ingénierie de caractéristiques avant d’être analysé par le modèle BiLSTM (Extended Bidirectional Long Short-Term Memory) avec une attention temporelle. Les paramètres du modèle sont optimisés par le calcul de la fonction de perte et l’entraînement itératif. Dans le flux de déploiement, le modèle entraîné effectue la détection d’intrusion selon la fonction de décision définie dans l’équation 13. Les événements d’intrusion détectés sont transmis au module blockchain, où une journalisation immuable, l’isolement des nœuds et la génération d’alertes par les administrateurs sont effectués. BiLSTM, mémoire bidirectionnelle à court terme ; IoMT, Internet des objets médicaux. Veuillez cliquer ici pour voir une version agrandie de cette figurine.

Les dispositifs IoMT générent des flux de données hétérogènes composés de trafic réseau, de métadonnées d’appareils et de signaux liés au patient. Ces entrées brutes sont souvent bruyantes, redondantes et incohérentes, ce qui les rend inadaptées à l’entraînement direct du modèle. Par conséquent, un pipeline de prétraitement est appliqué pour garantir la qualité et la structure des données avant de les intégrer au modèle BiLSTM étendu. Le pseudocode détaillé du prétraitement est fourni dans l’Algorithme 1 (Fichier Supplémentaire 1), qui décrit le pipeline de prétraitement appliqué aux flux de données IoMT avant l’entraînement BiLSTM étendu (pseudocode dans le Fichier Supplémentaire 1 ; implémentation dans le Fichier Supplémentaire 2). L’architecture complète de BiLSTM étendu est résumée dans l’Algorithme 2 (Fichier supplémentaire 1).

Flux de reproduction de bout en bout
L’étude complète peut être reproduite à l’aide des étapes ci-dessous. Le logiciel et le matériel sont listés dans la configuration expérimentale, et le code supplémentaire couvre chaque étape.

Obtenez les jeux de données → téléchargez UNSW-NB15. Utilisez les fichiers UNSW_NB15_training-set.csv et UNSW_NB15_testing-set.csv. Téléchargez CICIDS2017. Utilisez les cinq fichiers journaux MachineLearningCSV (du lundi au vendredi). Télécharger Bot-IoT. Utilisez les fichiers de sous-ensemble à 5 % UNSW_2018_IoT_Botnet_Full5pc_1_to_4. Les études antérieures de détection d’intrusion s’appuyaient généralement sur des ensembles de données de référence tels que KDD Cup 99,¹⁴ ; cependant, cette étude utilise les ensembles de données plus récents de l’UNSW-NB15, CICIDS2017 et Bot-IoT pour mieux représenter le trafic réseau contemporain. Traitez chaque jeu de données séparément. L’ensemble de données UNSW-NB15 est disponible auprès de l’Université de Nouvelle-Galles du Sud à https://research.unsw.edu.au/projects/unsw-nb15-dataset (dernière modification : 8 février 2024). Le jeu de données CICIDS2017 est disponible auprès de l’Institut canadien de cybersécurité à https://www.unb.ca/cic/datasets/ids-2017.html (publié : juillet 2017). Le jeu de données Bot-IoT est disponible auprès de l’Université de Nouvelle-Galles du Sud à https://research.unsw.edu.au/projects/bot-iot-dataset (dernière modification : 5 février 2024). Tous les ensembles de données ont été consultés en mai 2025 pour cette étude.

Prétraiter les données → supprimer les enregistrements corrompus. Combler les valeurs manquantes en utilisant les moyens de l’ensemble d’entraînement. Appliquer le débruit EMA (α = 0,3). Normaliser les caractéristiques à [0,1] en utilisant les statistiques de l’ensemble d’entraînement. Champs catégoriels par encodage d’étiquette. Construisez des fenêtres coulissantes (T = 20, foulée = 1). Ces étapes de prétraitement permettent une détection robuste d’intrusion en réduisant le bruit et en améliorant la qualité des représentations du trafic réseau pour les IDS^15,16 basés sur l’apprentissage automatique.

Certaines caractéristiques (AQU-IMF-RFE) → Classez les caractéristiques par information mutuelle. Affinez avec l’Aquila Optimizer. Appliquer la RFE Random Forest avec une validation croisée 10 fois. Gardez les dernières fonctionnalités. Cette stratégie hybride de sélection de caractéristiques suit le concept plus large de combinaison de techniques complémentaires de détection d’intrusion¹⁷ et est mise en œuvre à l’aide du cadre AQU-IMF-RFE développé dans notre travail^{précédent 18}.

Entraîner le modèle → Pour chaque ensemble de données, les données ont été aléatoirement partitionnées en ensembles d’entraînement (80 %) et de test (20 %) en utilisant une graine aléatoire fixe de 42. Vingt pour cent de la partition d’entraînement était en plus réservée comme ensemble de validation. Construis le BiLSTM étendu. Entraînez-vous en utilisant la perte binaire pondérée en entropie croisée et l’optimiseur Adam (taux d’apprentissage = 0,001, taille du lot = 64, maximum de 50 époques, avec arrêt précoce). Sauvez le modèle entraîné. L’utilisation de modèles d’apprentissage profond temporel convient parfaitement au trafic IoMT^{hétérogène 19}. Le flux de travail complet d’entraînement du modèle est résumé dans l’Algorithme 3 (Fichier supplémentaire 1). Les poids finaux des classes étaient calculés automatiquement à partir des distributions des classes de l’ensemble d’entraînement selon les équations 19 et 20. Les poids de classe résultants étaient les suivants : UNSW-NB15 : , ; CICIDS2017 : , ; et Bot-IoT (sous-ensemble de 5 %) : , . La grande valeur de w_n pour l’ensemble de données Bot-IoT reflète la sous-représentation sévère des échantillons bénins dans la partition d’entraînement du sous-ensemble des 5 %.

Déployez la blockchain → lancez la chaîne de preuve d’autorité (POA). Déployez le smart contract et notez son adresse. Autorisez les comptes passerelle. Exécutez le client de manière à ce que chaque intrusion détectée soit enregistrée et déclenche l’isolation et les alertes. Le flux de travail complet de détection, de journalisation blockchain et d’atténuation est résumé dans l’Algorithme 4 (Fichier Supplémentaire 1). La couche blockchain a été implémentée en utilisant le client go-ethereum (Geth) version 1.13.15 pour exploiter le réseau PoA autorisé, le compilateur Solidity (solc) version 0.8.19 pour la compilation et le déploiement de smart contracts, et la bibliothèque web3.py version 6.15.1 pour la communication entre l’IDS et le réseau blockchain.

Évaluer → tester le modèle sur l’ensemble de test tendu. Calculez la précision, la précision, le rappel, le score F1 et le taux de faux positifs. Enregistrer la latence et le débit. Vérifiez l’intégrité du registre blockchain. Le flux de travail complet de l’évaluation est résumé dans l’Algorithme 5 (Fichier Supplémentaire 1). La latence de détection (T_d) a été mesurée immédiatement avant l’appel d’inférence du modèle jusqu’au moment où les probabilités prédites ont été retournées. La latence d’atténuation de bout en bout (T_d +_{T b}) a été mesurée du même point de départ jusqu’à l’achèvement de la transaction de création de blocs blockchain correspondante. Le débit était calculé comme le nombre total de fenêtres de test prétraitées traitées par le pipeline complet de détection et de journalisation divisé par le temps d’horloge murale écoulé pour un seul passage complet de chaque ensemble de données. La charge de travail consistait en les partitions de test fenêtrées tout en conservant la distribution de classe bénigne à l’intrusion d’origine. Les fenêtres malveillantes entraînaient également la surcharge de la journalisation de la blockchain, tandis que les fenêtres inoffensives n’entraînaient que le coût de détection d’intrusion.

Générez des chiffres et des tableaux → tracez les courbes de précision et de pertes, la matrice de confusion et les graphiques d’évaluation comparative. Construis les tableaux comparatifs. Le flux complet de génération de figures et de tables est résumé dans l’Algorithme 6 (Fichier Supplémentaire 1). Le code source complet développé sur mesure utilisé pour générer toutes les figures et tableaux est fourni dans le Fichier Supplémentaire 2. En particulier, le script figures.py reproduit les chiffres du manuscrit directement à partir des résultats expérimentaux sauvegardés (par exemple, historique d’entraînement et fichiers de matrice de confusion), tandis que les scripts restants génèrent les données traitées et les métriques de performance utilisées pour construire les tableaux rapportés.

La figure 2 montre le flux de données au niveau de la mise en œuvre entre les modules IDS et blockchain. La BiLSTM étendue produit une décision par fenêtre (Équation 13) ; sur une classification malveillante, le client passerelle construit et signe une transaction et la soumet via web3/JSON-RPC au smart contract PoA, qui ajoute un bloc lié par hachage (Équation 14) au registre immuable et émet des événements (BlockCreated, NodeIsolated et AdminAlert) déclenchant l’isolement des nœuds et des alertes administrateurs.

Figure 2. Interaction au niveau de l’implémentation entre la détection d’intrusion et les modules blockchain. Diagramme de flux de travail illustrant la communication entre le système de détection d’intrusion et les composants blockchain. Le modèle BiLSTM étendu classe chaque fenêtre d’entrée et applique la règle de décision définie dans l’équation 13. Lorsqu’une intrusion est détectée, le client passerelle génère et signe une transaction qui est transmise via Web3.py/JSON-RPC au contrat intelligent Proof-of-Authority (PoA). Le contrat ajoute un bloc lié par hachage au registre immuable selon l’équation 14 et émet des événements BlockCreated, NodeIsolated et AdminAlert qui déclenchent des actions de confinement et de notification. IDS, Système de détection d’intrusion ; BiLSTM, mémoire bidirectionnelle à court terme ; Procuration, preuve d’autorité ; JSON-RPC, notation d’objet JavaScript – Appel de procédure distante. Veuillez cliquer ici pour voir une version agrandie de cette figurine.

Représentation des données
Considérons R comme le flux brut de trafic IoMT. Après prétraitement, chaque enregistrement brut est mappé dans un vecteur de caractéristiques normalisé de dimension d (Équation 1) :

(1)

Ici, f (⋅) est la fonction de transformation des caractéristiques qui mappe les enregistrements bruts en un vecteur de caractéristiques normalisé de dimension d. Soit le réseau IoMT constitué d’un ensemble de nœuds (Équation 2) :

N = {_{n 1} , n₂, ... , n_k} (2)

Chaque nœud _{n j} ∈ R produit un flux de données en série temporelle (Équation 3) :

(3)

Ici, x_t est le vecteur de caractéristiques au temps t, avec d caractéristiques (par exemple, taille du paquet, type de protocole, adresse source/destination) couramment observées dans le trafic réseau de santé de l’Internet des^{objets 19}. L’ensemble d’étiquettes correspondant est (Équation 4) :

  (4)

Ici, y_t=0 représente le trafic normal et y_t =1 désigne une intrusion.

Prétraitement des données
Le pipeline de prétraitement comprend les étapes suivantes, qui répondent aux défis courants de qualité des données et de sécurité liés au trafic^{IoMT 20} :

Nettoyage des données et gestion des valeurs manquantes :
Un enregistrement était identifié comme corrompu et supprimé avant l’imputation s’il remplissait l’une des conditions explicites suivantes : (i) tous les champs de caractéristiques de l’enregistrement étaient manquants (c’est-à-dire que l’enregistrement entier était nul), ou (ii) l’enregistrement contenait une valeur non finie (infini positif ou négatif) dans un champ numérique après coercition de type. La seconde règle supprime les entrées invalides telles que celles produites par la division par zéro lors du calcul des caractéristiques de flux (par exemple, des valeurs infinies de débits résultant de flux de durée nulle). Après la suppression des enregistrements corrompus, les valeurs manquantes restantes étaient imputées par remplacement moyen calculé par fonctionnalité, par jeu de données, et uniquement depuis la partition d’entraînement ; Les moyens obtenus ont été appliqués aux ensembles d’entraînement, de validation et de test afin d’éviter la fuite d’information. L’imputation n’était pas conditionnelle à la classe, et les moyennes n’étaient pas regroupées entre les ensembles de données.

Débruit temporel :
Le débruit temporel a été réalisé à l’aide d’un filtre à moyenne mobile exponentielle (EMA) par caractéristique appliqué le long de l’axe temporel. La forme récursive (causale ) y_t = α·x_t + (1 − α)·y_t−1 a été utilisée, avec un facteur de lissage α = 0,3, implémentée via la fonction ewm de pandas avec adjust=False. Chaque fonctionnalité était lissée indépendamment. En tant que filtre exponentiel (réponse impulsionnelle infinie), l’EMA n’a pas de fenêtre ou de taille de noyau fixe ; Le facteur de lissage α est le paramètre unique régissant le degré de lissage et la mémoire effective du filtre.

Normalisation Min–Max :
La normalisation min–max a été appliquée pour mettre chaque caractéristique à l’échelle [0,1] en utilisant la transformation x′=(x−min)/(max−min+ε), où ε = 1 × 10⁻⁸. Les statistiques minimales et maximales étaient calculées par caractéristique, par ensemble de données, et uniquement à partir de la partition d’entraînement ; Ces statistiques d’entraînement stockées étaient ensuite appliquées pour normaliser les ensembles d’entraînement, de validation et de test, empêchant ainsi la fuite d’informations cachées. Lors de l’inférence, les valeurs de caractéristiques situées en dehors de la zone d’entraînement étaient réduites à l’intervalle [0,1].

Encodage des caractéristiques catégorielles :
Les caractéristiques catégorielles ont été converties en forme numérique à l’aide du codage d’étiquette. Cela s’appliquait à toutes les variables catégorielles : dans^{UNSW-NB 15}, les champs proto, service et état ; dans Bot-IoT, le proto-champ ; CICIDS2017 ne contient aucun champ catégoriel parmi les caractéristiques sélectionnées. L’encodage était implémenté avec LabelEncoder par variable.

Fenêtrage temporel pour l’apprentissage séquentiel :
Le flux de caractéristiques prétraité était segmenté en séquences de longueur fixe à l’aide d’une fenêtre glissante de longueur T = 20 pas de temps avec une foulée de s = 1. Chaque fenêtre générée était validée avant inclusion. Une fenêtre n’était acceptée que si elle contenait exactement T = 20 pas de temps consécutifs et que toutes les valeurs des caractéristiques étaient finies. Les flux plus courts que T = 20 enregistrements ne produisaient pas de fenêtres. Cette configuration (T = 20, s = 1, chevauchement à 95 %) a été appliquée de manière cohérente à toutes les expériences et ensembles de données. Le flux de travail complet du prétraitement est résumé dans l’Algorithme 1 (Fichier supplémentaire 1).

L’objectif du prétraitement est de permettre une correspondance prédictive des séquences d’entrée vers les labels d’intrusion (Équation 5).

(5)

paramétrée par θ, cela prédit si un événement est bénin ou malveillant.

Sélection des caractéristiques à l’aide de AQU-IMF-RFE
La sélection des caractéristiques a été réalisée à l’aide d’AQU-IMF-RFE, une méthode hybride qui intègre l’information mutuelle (MI), l’Aquila Optimizer (AO) et l’élimination des caractéristiques récursives (RFE), introduite dans notre travail^{précédent 18}. La méthode fonctionne en trois étapes. Lors de la première étape, l’information mutuelle entre chaque caractéristique et l’étiquette de classe est calculée pour obtenir un classement initial de pertinence. Lors de la deuxième étape, l’Aquila Optimizer effectue une recherche globale sur des sous-ensembles de caractéristiques candidats en utilisant ses quatre stratégies d’optimisation. À la troisième étape, le sous-ensemble raffiné est passé par l’élimination des caractéristiques récursives avec une validation croisée de 10 fois à l’aide d’un estimateur Random Forest (RF).

L’Aquila Optimizer était configuré avec une population de 100 personnes, un maximum de 10 itérations, un facteur d’exploitation de 0,1, un taux d’apprentissage de 0,1 et un facteur d’attraction de 0,005. Appliqué indépendamment à chaque jeu de données, AQU-IMF-RFE a conservé 14 fonctionnalités pour UNSW-NB15, 24 pour CICIDS2017 et 12 pour Bot-IoT. Le pseudocode complet est fourni dans le Fichier Supplémentaire 1, et les sous-ensembles de caractéristiques sélectionnés sont listés dans le Tableau 4.

Tableau 4A. Caractéristiques sélectionnées conservées pour UNSW-NB15
S. Non.	Caractéristiques	Type	Catégorie
1	dur	Numérique (flottant)	Base
2	sbytes	Numérique (entier)	Base
3	Taux	Numérique (flottant)	Base
4	dload	Numérique (flottant)	Base
5	sinpkt	Numérique (flottant)	Temps
6	Dinpkt	Numérique (flottant)	Temps
7	sjit	Numérique (flottant)	Temps
8	TCPrtt	Numérique (flottant)	Temps
9	synack	Numérique (flottant)	Temps
10	ackdat	Numérique (flottant)	Temps
11	smean	Numérique (entier)	Contenu
12	ct_srv_src	Numérique (entier)	Connexion
13	ct_dst_src_ltm	Numérique (entier)	Connexion
14	ct_srv_dst	Numérique (entier)	Connexion
Tableau 4B. Caractéristiques sélectionnées conservées pour CICIDS2017
S. Non.	Caractéristiques
1	Destination Port
2	Durée de l’écoulement
3	Longueur totale des paquets en avant
4	Longueur totale des paquets inversés
5	Longueur maximale de paquet en transfert
6	Longueur maximale de paquet en arrière
7	Moyenne inverse de la longueur des paquets
8	Paquets de flux
9	Temps maximal d’inter-arrivée du débit
10	Temps total avant avant entre les arrivées
11	Longueur de la tête avant
12	Longueur de l’en-tête à l’envers
13	Paquets avant par seconde
14	Longueur maximale du paquet
15	Moyenne de la longueur des paquets
16	Écart-type de longueur de paquet
17	Variance de la longueur des paquets
18	Taille moyenne des paquets
19	Taille moyenne des segments à l’envers
20	Octets en avant du sous-flux
21	Octets rétro de sous-flux
22	Octets de fenêtre initiaux en avant
23	Octets de fenêtre initiale à l’envers
24	Longueur des paquets en avant
Tableau 4C. Fonctionnalités sélectionnées conservées pour Bot-IoT
S. Non.	Caractéristiques	Type
1	seq	Numérique
2	Moyenne	Numérique
3	STDDEV	Numérique
4	min	Numérique
5	Max	Numérique
6	srate	Numérique (flottant)
7	drate	Numérique (flottant)
8	N_IN_Conn_P_SrcIP	Numérique (entier)
9	N_IN_Conn_P_DstIP	Numérique (entier)
10	proto	Catégorique (encodé)
11	state_number	Numérique (entier)
12	Taux	Numérique (flottant)

Tableau 4 : Caractéristiques sélectionnées par la méthode de sélection de caractéristiques AQU-IMF-RFE. Ce tableau liste les sous-ensembles finaux de caractéristiques sélectionnés par le cadre de sélection de caractéristiques AQU-IMF-RFE pour les ensembles de données UNSW-NB15, CICIDS2017 et Bot-IoT. Les noms de caractéristiques, types de données et catégories fonctionnelles sont fournis lorsque cela est applicable.

Installation expérimentale
Toutes les expériences ont été menées sur un serveur Dell PowerEdge R740 équipé d’un processeur Intel Xeon Silver 4214 fonctionnant à une fréquence de base de 2,20 GHz, avec 12 cœurs physiques, 24 threads logiques, 16,5 Mo de cache et une vitesse Intel Ultra Path Interconnect (UPI) de 9,6 GT/s. Le serveur était configuré avec 128 Go de RAM, un SSD (SSD) de 512 Go, et fonctionnait sous Microsoft Windows 11. La pile logicielle comprenait Python 3.12.7, TensorFlow 2.16.1, scikit-learn 1.8.0, pandas 3.0.2 et NumPy 2.4.4. La couche blockchain a été implémentée sur la même station de travail en utilisant un réseau PoA Ethereum. La communication entre l’IDS et la blockchain se faisait via JSON-RPC en utilisant le client go-ethereum (Geth) version 1.13.15, le compilateur Solidity (solc) version 0.8.19 pour la compilation et le déploiement de smart contracts, ainsi que la version 6.15.1 de la bibliothèque Web3.py. Le temps d’entraînement rapporté, la latence d’inférence et le débit ont été mesurés sur cette configuration matérielle et logicielle.

Architecture et formation de modèles
Le modèle BiLSTM étendu constitue le composant central de détection du cadre, s’appuyant sur les approches précédentes de détection d’intrusion basées sur l’apprentissage développées pour les environnements^{IoMT 21}. Des études antérieures de détection d’intrusion ont souligné à la fois l’importance d’équilibrer la performance de détection avec la réduction des fausses^{alertes 15} et les défis uniques liés à l’application de méthodes d’apprentissage automatique au trafic réseau^{en évolution 16}. Les architectures collaboratives de détection d’intrusion par réseau neuronal ont également démontré la valeur de l’apprentissage séquentiel profond des caractéristiques pour le trafic réseau^{complexe 22}. Alors que les modèles BiLSTM standards capturent des dépendances temporelles bidirectionnelles, le trafic IoMT présente à la fois des motifs de rafales à court terme et des dépendances à longue portée causées par des attaques à plusieurs étages. Pour y remédier, le modèle proposé étend BiLSTM avec l’extraction de caractéristiques temporelles, un apprentissage temporel bidirectionnel amélioré, des connexions résiduelles et une priorisation temporelle basée sur l’attention. Les LSTM bidirectionnels (BiLSTM) surmontent cette limitation en combinant des états cachés avant et arrière, permettant une représentation temporelle plus riche des schémas de trafic IoMT, comme indiqué dans l’Algorithme 2 (Fichier Supplémentaire 1).

Soit la séquence d’entrée X^(n_j) = {_{x 1} , x₂ , ... , x_T }, où chaque x_t ∈ R^d est un vecteur de caractéristiques prétraité.

Extraction des caractéristiques temporelles :
Une convolution légère unidimensionnelle est appliquée sur la dimension temporelle pour souligner les anomalies temporelles à courte portée (Équation 6) :

U = φ (Conv1D(X^{(_{n j})}), U = {u₁, u₂, ..., u_T } (6)

Ici, φ(⋅) est une fonction d’activation non linéaire et les caractéristiques convoluelles u_t sont transmises à la BiLSTM.

La couche Conv1D extrait des motifs temporels à courte portée avant la modélisation bidirectionnelle des séquences. Les paramètres complets d’implémentation sont fournis dans le fichier supplémentaire 3B.

Apprentissage LSTM bidirectionnel empilé :
Les états cachés avant et arrière sont calculés comme (Équation 7) :

(7)

La représentation finale de la BiLSTM est la concaténation des états cachés passés (en avant) et futurs (en arrière) (Équation 8).

(8)

Deux couches BiLSTM empilées modélisent les dépendances temporelles bidirectionnelles. Des paramètres architecturaux détaillés sont fournis dans le fichier supplémentaire 3B. Les détails de l’initialisation des poids sont fournis dans le fichier supplémentaire 3B.

Connexion résiduelle et normalisation
Après projection linéaire à des dimensions correspondantes, les connexions résiduelles et la normalisation des couches sont appliquées (Équation 9) :

La projection résiduelle et la normalisation des couches alignent les représentations convolutionnelles et BiLSTM avant l’attention. Les paramètres d’implémentation détaillés sont fournis dans le fichier supplémentaire 3B.

Mécanisme d’attention
Bien que BiLSTM fournisse une modélisation temporelle solide, tous les pas de temps ne contribuent pas de manière égale à la prédiction. Pour souligner les horodatages critiques (par exemple, des pics anormales soudains), un mécanisme d’attention est introduit. Chaque état caché se voit attribuer un score de pertinence α_t pour améliorer la précision de la détection (Équation 10).

Ici, W_a est un paramètre entraînable et les poids d’attention satisfont

Le vecteur de contexte c agrège les états cachés en fonction de leur importance apprise (Équation 11) :

Le mécanisme de l’attention agrège les représentations temporelles dans un vecteur de contexte. Les paramètres d’implémentation détaillés sont fournis dans le fichier supplémentaire 3B.

Couche de sortie et classification
Le vecteur de contexte agrégé est fait passer par une couche entièrement connexe suivie d’une activation sigmoïde pour obtenir la prédiction finale (Équation 12) :

Ici, W_c et b_c sont des paramètres entraînables, et σ(·) est la fonction d’activation sigmoïde qui associe la sortie à l’intervalle [0,1]. Un seuil est appliqué pour classer le trafic comme bénin () ou intrusif ().

La régularisation du dropout et le seuil de classification fixe utilisé lors de l’inférence sont décrits dans le Fichier Supplémentaire 3B.

L’architecture BiLSTM étendue est identique sur les trois ensembles de données ; seule la dimension des caractéristiques d’entrée diffère, prenant respectivement les valeurs 14, 24 et 12 pour UNSW-NB15, CICIDS2017 et Bot-IoT. Comme la couche Conv1D associe toute entrée de dimension à une représentation fixe de 64 canaux, toutes les couches suivantes sont indépendantes du jeu de données, et seule la forme d’entrée et le nombre de paramètres Conv1D varient avec . L’architecture complète couche par couche est résumée dans le tableau 5, avec les comptes de paramètres exprimés en termes de d ; Les totaux obtenus sont de 184 641, 186 561 et 184 257 paramètres entraînables pour D = 14, D = 24 et D = 12, respectivement.

S. Non.	Couche (type)	Forme de sortie	Paramètres adaptés à l’entraînement	Fonction d’activation
1	Entrée	(20, d)	0	—
2	Conv1D (64 filtres, taille du noyau = 3, même remplissage)	(20, 64)	192d + 64	ReLU
3	LSTM bidirectionnel couche 1 (64 unités par direction)	(20, 128)	66,048	tanh / sigmoïde
4	LSTM bidirectionnel couche 2 (64 unités par direction)	(20, 128)	98,816	tanh / sigmoïde
5	Projection résiduelle dense	(20, 128)	8,320	Linéaire
6	Ajout résiduel	(20, 128)	0	—
7	Normalisation des couches (axe = −1, ε = 1 × 10⁻³)	(20, 128)	256	—
8	Attention temporelle (Wa ∈ R¹²⁸×¹)	128	128	Softmax
9	Couche cachée dense	64	8,256	ReLU
10	Abandon (p = 0,3)	64	0	—
11	Couche de sortie dense	1	65	Sigmoïde

Tableau 5 : Architecture couche par couche du modèle de mémoire bidirectionnelle longue et courte durée étendue. Ce tableau résume l’architecture du modèle proposé de mémoire bidirectionnelle longue et courte durée (BiLSTM), incluant les types de couches, les dimensions de sortie, le nombre de paramètres entraînables et les fonctions d’activation.

Le logiciel et l’environnement informatique utilisés pour toutes les expériences sont résumés dans le tableau 6.

Composant	Version / Spécification
Système d’exploitation	Windows
Plateforme serveur	Dell PowerEdge
CPU	Processeur 64 cœurs
RAM	128 Go
Stockage	SSD 512 Go
Python	3.12.7
NumPy	2.4.4
Pandas	3.0.2
scikit-learn	1.8.0
TensorFlow / Keras	2.16.1
Web3 (client blockchain)	6.15.1
eth-account	0.1
Compilateur Solidity (solc)	0.8.19
go-ethereum (Geth)	1.13.15

Tableau 6 : Logiciels et environnement informatique utilisés pour la mise en œuvre et l’évaluation du cadre proposé. Ce tableau résume les spécifications matérielles, les composants logiciels, les outils blockchain et les numéros de version utilisés pour le prétraitement des données, la sélection des fonctionnalités, l’entraînement des modèles, le déploiement de blockchain et l’évaluation des performances.

Décision d’intrusion et réponse automatisée
La détection d’intrusion dans les environnements de santé n’est efficace que si elle est suivie d’une réponse rapide et d’une atténuation. La couche de détection d’intrusion convertit la probabilité prédite en décision. Formellement, la décision d’intrusion à l’étape temporelle t est représentée comme suit (Équation 13) :

Ici, est la probabilité d’intrusion prédite au temps t et est le seuil de classification.

Une fois une intrusion détectée, la couche de détection d’intrusion interagit directement avec le module blockchain, qui effectue une journalisation immuable, une atténuation automatisée et une application de la sécurité en boucle fermée. Les détails des événements, y compris les informations sur la source, les informations de destination et certaines fonctionnalités de trafic, sont enregistrés dans un nouveau bloc blockchain. Les contrats intelligents exécutent des actions d’atténuation en temps réel telles que l’isolement des nœuds et les alertes aux administrateurs. Cette architecture en boucle fermée permet aux résultats de détection d’intrusion d’alimenter directement les mécanismes de prévention, minimisant ainsi la latence d’atténuation. Ainsi, la couche de détection d’intrusion sert de pont entre la détection temporelle utilisant le modèle BiLSTM étendu et la réponse sécurisée utilisant la technologie blockchain, complétant ainsi la fonctionnalité de bout en bout du cadre proposé.

Journalisation médico-légale basée sur la blockchain
Bien que le modèle BiLSTM étendu permette la détection d’intrusion en temps réel, le stockage sécurisé et l’audit vérifiable des événements d’intrusion sont tout aussi critiques dans les environnements de santé IoMT. Les mécanismes traditionnels de journalisation centralisée sont vulnérables à la falsification et compromettent la traçabilité médico-légale. Pour répondre à cette limitation, le cadre proposé intègre un module blockchain léger qui garantit l’immutabilité, la décentralisation et la réponse automatisée basée sur les contrats intelligents.

Chaque événement d’intrusion détecté génère un bloc qui est ajouté à la blockchain. Un bloc B_i est défini comme suit (Équation 14) :

Ici, H_i est le hachage cryptographique des données de l’événement, de l’horodatage et du résultat de prédiction, T_i est l’horodatage, D_i contient certaines caractéristiques d’intrusion d’événement, Si_gi est la signature numérique, et PrevHash relie le bloc au bloc précédent, assurant l’immutabilité.

Cette conception garantit la résistance à la falsification car toute modification de D_i ou T_i modifie le hachage du bloc et rompt l’intégrité de la chaîne. Il offre également une auditabilité car toutes les anomalies détectées sont stockées et vérifiables de façon permanente. L’atténuation automatisée est prise en charge par des smart contracts qui exécutent des actions prédéfinies telles que l’isolement des nœuds et les alertes aux administrateurs. La décentralisation est obtenue grâce à plusieurs passerelles IoMT qui maintiennent le grand livre distribué, éliminant ainsi un point de défaillance unique.

La génération de blocs utilise la fonction de hachage cryptographique Keccak-256, la primitive de hachage native de l’environnement Ethereum/Solidity (invoquée via keccak256 de Solidity). Pour chaque bloc d’intrusion, le hachage du bloc est calculé comme suit :

Ici, D_i est le résumé de la caractéristique événement, T_i est l’horodatage, et PrevHash est le hachage du bloc précédent. Les champs sont concaténés à l’aide de l’encodage très compact de Solidity (abi.encodePacked) avant le hachage, produisant un résumé sur 256 bits.

Le même calcul Keccak-256 est utilisé par la routine de vérification de chaîne, qui recalcule chaque hachage de bloc à partir de ses champs stockés et confirme qu’il correspond à la valeur enregistrée, validant ainsi l’intégrité de la chaîne. Keccak-256 a été choisi car il s’agit de l’algorithme de hachage résistant aux collisions standard utilisé nativement dans les smart contracts Ethereum. Le smart contract a été développé dans Solidity et compilé à l’aide du compilateur Solidity (solc) version 0.8.19. Il a été déployé sur un réseau privé Ethereum Proof-of-Authority (PoA) exploité avec Geth version 1.13.15. Le réseau blockchain était configuré avec quatre nœuds validateurs utilisant le protocole de consensus Clique Proof-of-Authority, un identifiant de chaîne de 9848, une période de blocage de 5 s et une limite de gaz de bloc de 30 000 000. La communication entre le moteur de détection d’intrusion BiLSTM étendu et la couche blockchain a été réalisée via la bibliothèque Web3.py version 6.15.1 via l’interface JSON-RPC HTTP.

Mécanisme de consensus des points d’intérêt
Parce que les systèmes IoMT de santé sont très sensibles à la latence, le cadre proposé utilise un mécanisme de consensus PoA au lieu d’une Proof-of-Work (PoW)²³, coûteuse en calcul. Dans le point de retrait, un ensemble fixe de nœuds validateurs de confiance, tels que les passerelles hospitalières, autorise les transactions, offrant à la fois efficacité et résilience.

La complexité temporelle de la validation par blocs sous PoW peut s’exprimer comme suit (Équation 15) :

Ici, d représente la difficulté de minage.

En revanche, la complexité temporelle du consensus PoA est donnée comme suit (Équation 16) :

car la validation ne nécessite que la vérification par signature numérique par des nœuds validateurs autorisés.

En conséquence, PoA offre un fonctionnement à faible latence adapté aux alertes médicales en temps réel, une efficacité énergétique en évitant le minage à forte intensité de calcul, et une résilience face à un nombre limité de validateurs malveillants. Le réseau PoA était configuré avec quatre nœuds validateurs, et cette configuration est restée fixe tout au long de toutes les expériences afin d’assurer des mesures de latence cohérentes, une évaluation des performances reproductibles et une comparaison équitable entre tous les ensembles de données de benchmark.

Implémentation de la blockchain et fonctionnement des contrats intelligents
La composante blockchain a été mise en œuvre sur un réseau Ethereum autorisé fonctionnant selon le modèle de consensus^{PoA 24}. Le réseau était exploité via le client go-ethereum (Geth) avec le protocole de consensus^{Clique PoA 25}, dans lequel un ensemble de nœuds validateurs (sealer) autorisés sont responsables de la production et de la validation des blocs. Le smart contract à intrusion logging (IoMTIntrusionLedger) a été écrit dans Solidity et déployé sur ce réseau, suivant des architectures de sécurité IoT basées sur blockchain pour une gestion d’événements décentralisée^{sécurisée 26}. Seuls les comptes passerelle autorisés en chaîne (via la fonction de contrôle d’accès du contrat) étaient autorisés à soumettre des enregistrements d’intrusion, conformément aux architectures de smart contracts blockchain autorisées pour les applications Internet^{des objets 27}. La couche blockchain a été implémentée en utilisant le client go-ethereum (Geth) version 1.13.15 pour l’exploitation du réseau PoA autorisé, le compilateur Solidity (solc) version 0.8.19 pour la compilation et le déploiement de smart contracts, et la bibliothèque Web3.py version 6.15.1 pour la communication entre l’IDS et le réseau blockchain.

Les paramètres détaillés de déploiement et de configuration de la blockchain sont fournis dans le fichier supplémentaire 3C.

Chaque enregistrement d’intrusion est signé numériquement avant d’être inscrit dans le registre, soutenant l’auditabilité des soins de santé basée sur la blockchain et la tenue sécurisée des dossiers^{médico-légaux 28}. Les procédures de génération et de vérification de signatures numériques, y compris l’ECDSA sur la courbe secp256k1^29,30, sont décrites dans le Fichier Supplémentaire 3D. Chaque passerelle contient une paire de clés Ethereum composée d’une clé privée de 256 bits (32 octets) et de la clé publique correspondante, à partir de laquelle son adresse de compte est dérivée ; La génération de clés suit la procédure standard d’Ethereum, utilisant une clé privée aléatoire de 256 bits cryptographiquement sécurisée, la clé publique obtenue par multiplication scalaire secp256k1. Pour créer une signature, le client passerelle calcule le digest de la caractéristique d’événement D_i et le signe avec sa clé privée en utilisant le format de signature de messages EIP-191, produisant une signature de 65 octets composée des composants r, s et v. La signature est soumise avec l’enregistrement d’intrusion. La vérification est effectuée en chaîne par le contrat intelligent : en utilisant la précompilation EVM ecreais, le contrat récupère l’adresse du signataire à partir du digest et de la signature signés et exige qu’elle soit égale à l’adresse de la passerelle autorisée soumettant la transaction. Si l’adresse récupérée ne correspond pas à une passerelle autorisée, la transaction est rejetée. Cela lie chaque entrée de registre à une passerelle autorisée spécifique et empêche les enregistrements d’intrusion non autorisés ou falsifiés.

Les contrats intelligents sont déclenchés automatiquement lors de la détection d’intrusion, garantissant une réponse en temps réel sans intervention manuelle (Équation 17) :

(17)

Le module blockchain fonctionne en parallèle avec le classificateur BiLSTM étendu. Une fois qu’une anomalie est détectée : (i) l’événement est étiqueté et classifié par le BiLSTM, (ii) un bloc est généré, signé et ajouté au registre de la blockchain, et (iii) les contrats intelligents appliquent des politiques de réponse automatique.

Le smart contract de journalisation des intrusions (IoMTIntrusionLedger) maintient un registre uniquement annexé des blocs d’intrusion ainsi qu’un registre des comptes passerelle autorisés, et expose les fonctions résumées dans le tableau 7. Le contrat impose deux rôles d’accès via des modificateurs : onlyAdmin (l’administrateur du déploiement) et onlyGateway (comptes autorisés à soumettre des enregistrements d’intrusion). L’état se compose de la correspondance d’autorisation de passerelle, du tableau de registre de blocs, et de la tête de chaîne courante (le hachage du bloc le plus récent).

S. Non.	Fonction / Composant	Type	Accès	Logique
1	constructeur	Constructeur	—	Définit le déployeur comme administrateur et l’autorise comme passerelle initiale.
2	setGateway (adresse, bool)	Fonction	onlyAdmin	Ajoute ou supprime un compte de passerelle autorisé ; émet GatewayUpdated.
3	recordIntrusion(nodeId, patientId, attackClass, probabilityBp, dataDigest, signature, isolate)	Fonction	onlyGateway	Calcule Hi = Keccak-256(Di ∥ Ti ∥ probabilité ∥ PrevHash) ; vérifie la signature ECDSA de la passerelle sur Di via ecrecover ; ajoute le bloc au grand livre ; avance la tête de la chaîne ; émet BlockCreated, optionnellement NodeIsolated, et AdminAlert. Retour de H. i.
4	verifyChain()	Fonction de vue	Public	Recalcule le hachage de chaque bloc à partir de ses champs stockés et vérifie la liaison PrevHash ; revient vrai seulement si toute la chaîne est cohérente (détection de falsification).
5	ledgerLength()	Fonction de vue	Public	Retourne le nombre de blocs dans le registre.
6	_recoverSigner(hachage, signature)	Fonction interne	—	Divise la signature de 65 octets en (r, s, v) et récupère l’adresse de signature via la précompilation ecreper.
7	BlockCreated / NodeIsolated / AdminAlert / GatewayUpdated	Événements	—	Émis pour que les auditeurs hors chaîne puissent piloter la journalisation, l’isolement des nœuds, les alertes administrateur et les mises à jour du registre de passerelle.
8	onlyAdmin / onlyGateway	Modificateurs	—	Limitez les fonctions à l’administrateur et aux passerelles autorisées, respectivement.

Tableau 7 : Fonctions, événements et composants de contrôle d’accès du contrat intelligent IoMTIntrusionLedger. Ce tableau résume les principales fonctions, événements et modificateurs de contrôle d’accès implémentés dans le contrat intelligent blockchain autorisé. Ces composants supportent l’autorisation de passerelle, la journalisation des intrusions, la vérification blockchain, la génération d’événements et l’atténuation automatisée.

La propriété d’immuabilité de la blockchain découle directement de l’équation 14, où toute modification des données d’événements ou des horodatages invalide la chaîne de hachage. La blockchain offre ainsi intégrité des données, traçabilité et auditabilité aux systèmes de santé grâce à des dossiers médico-légaux immuables. Les dossiers d’intrusion des patients et des appareils restent inchangés une fois stockés, chaque bloc est lié de manière sécurisée au bloc précédent permettant la reconstruction chronologique des événements, et les administrateurs ou régulateurs de santé peuvent vérifier les incidents d’intrusion sans risque de falsification.

Fonction de perte et optimisation des modèles
Le modèle BiLSTM étendu proposé répond au problème de classification binaire consistant à distinguer entre le trafic normal et les événements d’intrusion dans les réseaux IoMT. Pour guider le processus d’entraînement, une perte binaire d’entropie croisée (BCE) est adoptée, ce qui convient parfaitement aux sorties probabilistes de la couche d’activation sigmoïde. Pour un ensemble de données avec N échantillons, la perte est définie comme suit (Équation 18) :

(18)

Ici, est l’étiquette de vérité fondamentale de la ^i-ème suite d’entrée (0 = bénigne, 1 = intrusion), et est la probabilité prédite d’intrusion.

Le cadre fonctionne comme un pipeline de classification en deux étapes. La première étape effectue la détection d’intrusion binaire : la BiLSTM étendue produit une sortie sigmoïde et applique le seuil τ = 0,5 pour classer chaque fenêtre comme bénigne ou intrusive (Équations 12,13), entraînée avec une perte binaire pondérée en entropie croisée. Une seconde étape peut effectuer la catégorisation des attaques, dans laquelle les fenêtres identifiées comme intrusions sont transmises à un classificateur multiclasse qui attribue la catégorie d’attaque spécifique à l’aide d’une couche de sortie softmax entraînée à l’entropie croisée catégorique. La présente étude se concentre sur et évalue le stade de détection binaire. Les deux étapes partagent la même colonne vertébrale d’extraction de caractéristiques Extended BiLSTM (Conv1D, BiLSTM, couches résiduelles, de normalisation et d’attention) ; ils ne diffèrent que par leur couche de sortie (sigmoïde pour la détection et softmax pour la catégorisation) et la fonction de perte correspondante. L’étape de détection binaire et la phase de catégorisation multiclasse ont été entraînées et évaluées selon les mêmes partitions de données, graines aléatoires et conditions d’entraînement décrites ci-dessus.

Bien que le trafic IoMT soit souvent déséquilibré, une perte binaire pondérée d’entropie croisée est utilisée pour pénaliser la mauvaise classification de la classe minoritaire. Les poids de classe sont calculés en utilisant le nombre d’échantillons d’intrusion N_p, le nombre d’échantillons bénins N n, et le nombre total d’échantillons N (Équations 19,20) :

Cette pondération garantit que le modèle n’est pas biaisé en faveur de la classe dominante de trafic bénin et reste sensible aux événements d’intrusion rares mais critiques.

La perte binaire pondérée en entropie croisée est donnée comme suit (Équation 21) :

(21)

La formation était réalisée à l’aide de mini-séries de taille 64. Au début de chaque époque, les échantillons d’entraînement étaient aléatoirement regroupés avant d’être partitionnés en lots, de sorte que la composition des lots variait selon les époques et que le modèle ne voyait pas d’exemples dans un ordre fixe. Les lots n’étaient pas explicitement équilibrés ou stratifiés par classe ; au contraire, chaque lot reflétait la distribution naturelle des classes de l’ensemble d’entraînement, et le déséquilibre de classe était corrigé par la perte binaire pondérée par classe (Équations 19–21). Le sous-ensemble de validation réservé à la partition d’entraînement restait fixe à travers les époques et n’était pas regroupé dans les lots d’entraînement.

Les poids de classe dans la perte binaire pondérée par entropie croisée n’ont pas été définis manuellement mais calculés automatiquement pour chaque jeu de données à partir de ses décomptes de classes dans l’ensemble d’entraînement selon les équations 19 et 20. Pour le jeu de données UNSW-NB15, les poids de classe résultants concernaient la classe normale et la classe d’intrusion. Pour le jeu de données CICIDS2017, les poids de classe résultants concernaient la classe normale et la classe intrusion. Pour le jeu de données Bot-IoT (sous-ensemble de 5 %), les poids de classe résultants concernaient la classe normale et la classe intrusion.

Stratégie d’entraînement et optimisation
Le modèle BiLSTM étendu a été entraîné en utilisant des mini-lots de taille B = 64 avec perte binaire pondérée d’entropie croisée, l’optimiseur Adam, et un arrêt précoce basé sur la perte de validation. L’entraînement était limité à 50 époques, et l’arrêt précoce était appliqué avec patience K = 5. Si la perte de validation ne s’améliorait pas pendant cinq époques consécutives, l’entraînement était interrompu et les poids du modèle étaient rétablis à ceux de l’époque ayant la perte de validation la plus faible. Ainsi, 50 époques représentaient le budget maximal de formation plutôt qu’une durée fixe. Une probabilité d’abandon de 0,3 a été appliquée pour la régularisation. Les réglages architecturaux comprenaient 64 filtres Conv1D, 64 unités LSTM par direction, une longueur de fenêtre de T = 20, et une foulée de s = 1. La stratégie d’entraînement adoptée est résumée dans l’Algorithme 3 (Fichier Supplémentaire 1). Les équations de mise à jour d’Adam utilisées pour l’optimisation sont fournies dans le fichier supplémentaire 3A.

L’optimiseur Adam était configuré avec un taux d’apprentissage de , un taux de désintégration au premier moment (β₁) de 0,9, un taux de désintégration au second moment (β₂) de 0,999, et une constante de stabilité numérique () de 1 × 10-7. Aucune option d’optimiseur supplémentaire n’a été utilisée, et aucune décroissance de poids ni découpage de gradient n’a été appliquée.

Génération d’alertes et atténuation automatisée
La détection seule est insuffisante dans les réseaux IoMT sensibles à la latence, où une réponse rapide est cruciale pour garantir la sécurité des patients. La couche de génération et d’atténuation d’alertes opérationnelle permet de prendre la décision d’intrusion prise par le modèle BiLSTM étendu et le mécanisme de journalisation blockchain. Si δ_t = 1, le module blockchain ajoute un nouveau bloc contenant les détails de l’intrusion . Simultanément, un contrat intelligent est exécuté pour déclencher des actions d’atténuation (Équation 22) :

(12)

Ici, BlockCreation assure une journalisation médico-légale immuable de l’événement, NodeIsolation (_{n j}) met en quarantaine le nœud IoMT compromis pour éviter d’autres dommages, et AdminAlert fournit une notification en temps réel aux administrateurs système. Pour faire fonctionner ce pipeline de réponse à double couche, le pseudocode est présenté dans l’Algorithme 4 (Fichier Supplémentaire 1).

Le traitement des événements par smart contract et les mécanismes de réponse hors chaîne sont décrits dans le fichier supplémentaire 3E.

Chaque entrée engagée dans le registre blockchain est stockée sous forme d’enregistrement IntrusionBlock, dont les champs et formats de données sont listés dans le tableau 8. Le registre est un tableau uniquement à ajouter de ces enregistrements, et la tête de chaîne actuelle stocke le hachage du bloc le plus récemment ajouté.

S. Non.	Terrain	Type de données	Taille	Description
1	hashId	bytes32	32 octets	Hachage de bloc Hi = Keccak-256(Di ∥ Ti ∥ probabilité ∥ PrevHash)
2	Horodatage	uint256	32 octets	Temps de création du bloc Ti (secondes d’époque Unix, à partir de l’horodatage du bloc)
3	nodeId	bytes32	32 octets	Identifiant du nœud IoMT nj
4	patientId	bytes32	32 octets	Identifiant patient/appareil (métadonnées médico-légales)
5	Classe d’attaque	uint16	2 octets	Code de catégorie d’attaque (0 = Normal, 1 = DDoS, 2 = Usurpation, ...)
6	probabilitéBp	uint16	2 octets	Probabilité d’intrusion prédite ŷ en points de base (0–10000, c’est-à-dire 0,00–100,00 %)
7	dataDigest	bytes32	32 octets	Le résumé Di des événements sélectionnés présente
8	Signature	Octets	Variable (65 octets)	Signature ECDSA Sigi du digest d’événements par la passerelle (r, s, v)
9	prevHash	bytes32	32 octets	Hachage du bloc précédent (PrevHash), reliant la chaîne
10	isolé	bool	1 octet	Si l’isolation des nœuds a été déclenchée pour cet enregistrement

Tableau 8 : Structure de l’enregistrement IntrusionBlock stocké dans le registre blockchain. Ce tableau décrit les champs, types de données, tailles de stockage et objectifs des enregistrements du registre blockchain utilisés pour stocker les événements d’intrusion. La structure prend en charge la vérification de l’intégrité cryptographique, la traçabilité médico-légale et les mécanismes automatisés de réponse.

La latence globale d’atténuation peut s’exprimer comme la somme du délai de détection (T_d) du modèle BiLSTM étendu et du délai d’exécution de la blockchain (T_b) (Équation 23) :

(23)

Analyse de la complexité computationnelle
L’efficacité du cadre BiLSTM–Blockchain étendu proposé est déterminée à la fois par le coût de calcul du modèle BiLSTM et par la surcharge introduite par le module blockchain. Le cadre proposé intègre la détection étendue de BiLSTM avec la journalisation blockchain afin de satisfaire aux exigences de sécurité fondamentales de la triade Confidentialité, Intégrité et Disponibilité (CIA).

Soit la longueur de la séquence d’entrée prétraitée T, la dimension des caractéristiques d, et la dimension cachée du BiLSTM h.

Pour chaque pas de temps, un BiLSTM traite une entrée de dimension d de taille cachée h. Puisqu’elle est bidirectionnelle (avant + arrière) (Équation 24) :

) (24)

Ici, T est la longueur de la suite (pas de temps), d est la dimension de la caractéristique d’entrée, h est la dimension d’état caché

La couche d’attention calcule les poids d’importance et agrège les états cachés avec complexité (Équation 25).

(25)

qui est linéaire à la fois dans la longueur de la suite T et dans la dimension cachée h.

La complexité globale de détection par séquence est donc donnée comme suit (Équation 26) :

(26)

démontrant que la modélisation temporelle domine le coût computationnel, tandis que le mécanisme d’attention n’introduit qu’une surcharge légère.

Pour chaque événement d’intrusion détecté, la journalisation blockchain effectue des opérations de hachage, de signature et d’ajout de blocs (Équation 27) :

(27)

Pour N événements de détection d’intrusion, la complexité combinée devient la suivante (Équation 28) :

(28)

qui peut être simplifiée comme suit (Équation 29) :

(29)

car la surcharge blockchain croît linéairement avec le nombre d’événements et reste négligeable comparée aux calculs de traitement de séquences.

La complexité computationnelle est résumée dans les équations 24–29. Une interprétation détaillée est fournie dans le Fichier Supplémentaire 3F.

Résultats

Les résultats sont organisés pour suivre les étapes méthodologiques du protocole, chaque sous-section rapportant les observations produites par l’étape correspondante.

Gestion des jeux de données et mise en place expérimentale
Les trois ensembles de données de référence ont été analysés indépendamment plutôt que fusionnés. Parce que UNSW-NB15, CICIDS2017 et Bot-IoT utilisent des schémas de caractéristiques et des conventions d’étiquetage di...

Discussion

La présente étude propose un cadre intégré Extended BiLSTM–Blockchain pour la détection et la prévention des intrusions dans les environnements IoMT. Les résultats démontrent que ce cadre identifie efficacement les schémas d’intrusion dans le trafic hétérogène du réseau IoMT en combinant l’apprentissage temporel bidirectionnel avec la journalisation médico-légale basée sur la blockchain. L’architecture bidirectionnelle permet au modèle de capturer à la fois les dépendances temporelles av...

Matériaux

Liste des matériaux utilisés dans cet article

Nom	Entreprise	Numéro de catalogue	Commentaires
AQU-IMF-RFE Feature Selection Module	Self-developed	N/A	Méthode hybride de sélection de caractéristiques intégrant l'information mutuelle, l'optimiseur Aquila et l'élimination récursive des caractéristiques
Attention Layer	Self-developed (Keras-based)	N/A	Mécanisme d'attention temporelle utilisé pour le pondérage des caractéristiques dans le modèle Extended BiLSTM
Bot-IoT Dataset	UNSW Canberra Cyber	N/A	Jeu de données de référence public utilisé pour l'évaluation de la détection des intrusions
CICIDS2017 Dataset	Canadian Institute for Cybersecurity	N/A	Jeu de données de référence public pour la détection des intrusions
Ethereum Client (Geth)	Ethereum Foundation	1.13.15	Client de blockchain utilisé pour déployer et faire fonctionner le réseau Proof-of-Authority
Extended BiLSTM Model	Self-developed	N/A	Modèle de détection d'intrusion en apprentissage profond intégrant Conv1D, BiLSTM, l'apprentissage résiduel et l'attention temporelle
Jupyter Notebook	Project Jupyter	7.x	Environnement interactif utilisé pour la mise en œuvre, l'expérimentation et la visualisation des résultats
NumPy	NumPy Developers	2.4.4	Bibliothèque de calcul numérique utilisée pour le prétraitement et l'entraînement des modèles
Pandas	Pandas Development Team	3.0.2	Bibliothèque de traitement de données utilisée pour le prétraitement et l'analyse des données
Proof-of-Authority Blockchain Network	Self-developed	N/A	Réseau blockchain autorisé utilisé pour la journalisation immuable des intrusions et l'atténuation automatisée
Python	Python Software Foundation	3.12.7	Langage de programmation utilisé pour le prétraitement des données, le développement de modèles, l'intégration de blockchain et l'évaluation
Random Forest Estimator	Scikit-learn Developers	N/A	Classificateur Random Forest utilisé pour l'élimination récursive des caractéristiques (RFE)
Scikit-learn	Scikit-learn Developers	1.8.0	Bibliothèque d'apprentissage automatique utilisée pour le prétraitement, la sélection de caractéristiques et l'évaluation des modèles
Solidity Compiler (solc)	Solidity Team	0.8.19	Compilateur utilisé pour la compilation et le déploiement de contrats intelligents
Solid-State Drive (SSD)	Dell	512 GB	Stockage utilisé pour les ensembles de données, les modèles entraînés et le registre blockchain
System Memory (RAM)	Dell	128 GB	Mémoire principale utilisée pendant le prétraitement, l'entraînement des modèles, l'exécution de la blockchain et l'évaluation
TensorFlow	Google	2.16.1	Cadre d'apprentissage profond utilisé pour implémenter et entraîner le modèle Extended BiLSTM
UNSW-NB15 Dataset	UNSW Canberra Cyber	N/A	Jeu de données de référence public utilisé pour l'entraînement et l'évaluation
Web3.py	Web3.py Developers	6.15.1	Interface Python utilisée pour la communication entre le système de détection d'intrusion et le réseau blockchain
Windows Operating System	Microsoft	Windows 11	Système d'exploitation utilisé pour toutes les expériences
Workstation / Server	Dell	PowerEdge R740	Plateforme informatique utilisée pour l'entraînement des modèles, le déploiement de la blockchain et l'évaluation