Jump to section

Les microservices comme technologie d'intégration dans le secteur de la santé

Copier l'URL

Les microservices permettent aux développeurs, notamment ceux du secteur de la santé, de créer des applications qui sont constituées de services faiblement couplés, ce qui facilite les étapes de développement, de test, de déploiement et de mise à niveau. Ces avantages expliquent l'engouement croissant pour les microservices au détriment de la précédente génération de technologies d'intégration, les ESB (Enterprise Service Bus).

Comme dans toute grande entreprise, l'environnement informatique d'un établissement de santé se compose de différents systèmes qui doivent partager des données essentielles. Des systèmes d'admission, sortie et transfert, de laboratoire et de radiologie, aux systèmes de planification et facturation, entre autres, tous doivent être en mesure de communiquer et de s'échanger des données qui peuvent s'avérer vitales en cas d'urgence médicale.

Depuis l'avènement du numérique, les professionnels de santé utilisent des dossiers médicaux électroniques, mais sans partage des données entre les différentes applications, ces dossiers présentent un intérêt limité. La problématique de l'intégration des systèmes de santé est apparue il y a plusieurs dizaines d'années, plus précisément en 1987 avec l'établissement des normes internationales HL7 (Health Level Seven) pour le transfert des données cliniques et administratives entre les applications utilisées dans le domaine médical. Ce langage commun établi, il restait à trouver les moyens de connecter les applications afin qu'elles puissent communiquer via le format HL7.

Au fil des ans, les professionnels de santé ont constaté que les connexions directes point à point entre applications étaient peu pratiques et engendraient davantage de difficultés à mesure que l'établissement s'agrandissait. En outre, malgré le langage universel HL7, il n'existait pas de méthode unique pour interpréter les champs. Pour permettre la communication entre les systèmes de santé, il fallait donc transformer les données et se doter de capacités de connexion.

La toute première technologie d'intégration adoptée par les prestataires de services de santé, l'IE (Interface Engine), était un serveur qui faisait office de concentrateur pour l'ensemble des systèmes d'un hôpital. Chaque système se connectait à l'IE, qui transformait les données et les acheminait vers les autres systèmes selon les besoins. Puis, il y a 20 ans environ, la technologie ESB (Enterprise Service Bus) a fait son apparition. Comme l'IE, un ESB est un concentrateur qui permet l'échange de données entre plusieurs applications médicales, essentiellement via le langage HL7. Compatible avec différents services web, JMS, HTTP et SOAP, l'ESB offre des fonctions de transformation des données, de conversion de protocoles et de routage, et simplifie la gestion ainsi que la surveillance. C'est la solution d'intégration la plus utilisée depuis 20 ans, dans la santé comme dans d'autres secteurs.

Le développement d'applications a considérablement évolué depuis l'apparition du modèle ESB, et celui-ci a pris du retard notamment à cause de l'essor des approches DevOps et agile.

Le pipeline DevOps désigne un cycle de développement basé sur des changements progressifs et des tests automatisés en continu. À l'ère du DevOps, ce qui faisait hier la popularité de l'ESB représente aujourd'hui un obstacle. Avec un ESB, toutes les intégrations sont déployées sous la forme d'un monolithe. Avant, il s'agissait d'un atout, mais aujourd'hui, cette caractéristique rend l'ESB incompatible avec le DevOps.

Voici les limites de l'ESB dans l'environnement de développement moderne :

  • Incompatibilité avec le développement agile et les outils DevOps : souvent formés dans un environnement DevOps, les jeunes développeurs agiles sont plus productifs avec les dernières solutions DevOps, qu'ils ont l'habitude d'utiliser. Or, les ESB n'ont pas été conçus pour prendre en charge ces outils.
  • Impact des modifications sur le système tout entier : pour effectuer un changement, même minime, dans la règle d'un ESB, il faut interrompre tout le moteur. Cette intervention perturbe toutes les applications qui interagissent avec l'ESB et les rend inutilisables. De la même manière, une erreur introduite par une modification est susceptible d'affecter l'ensemble des intégrations. Au final, les équipes rechignent à appliquer les mises à niveau et les correctifs, ce qui est contreproductif.
  • Point de défaillance unique : comme toutes les intégrations sont routées via le même concentrateur, l'ESB représente un point de défaillance unique pour l'établissement tout entier. Si l'ESB tombe en panne, l'ensemble des intégrations est affecté.
  • Impossibilité d'automatiser les tests : les tests automatisés sont une composante clé du modèle DevOps. Dans le pipeline DevOps, chaque mise à jour est testée de façon indépendante sans interrompre le processus de développement, et ce, de manière automatisée. L'ESB, quant à lui, dispose d'un système de contrôle des versions et d'une interface utilisateur graphique propriétaires qui empêchent l'automatisation des tests.

Le secteur de la santé, comme d'autres secteurs d'ailleurs, a adopté les nouvelles pratiques de développement telles que les microservices, le DevOps et le développement agile. L'adoption de ces méthodes s'est étendue également aux intégrations. En effet, les applications modernes et les nouveaux points de contact numériques doivent être intégrés aux différents protocoles existants, dont HL7 et REST. Les développeurs de microservices qui travaillent dans le domaine de la santé souhaitent contrôler les intégrations et les autres applications qu'ils développent (pour les données, la diffusion, l'interface utilisateur, les systèmes de commande et contrôle, etc.) et mettre en paquets toutes les modifications sous la forme d'unités déployables transmises tout au long du processus CI/CD. Malheureusement, les limites évoquées ci-dessus empêchent l'utilisation d'une approche CI/CD pour l'intégration des applications.

Les microservices représentent l'avenir du développement et le modèle ESB n'est tout simplement pas compatible. Les microservices sont l'exact opposé des ESB monolithiques : ils permettent aux développeurs de créer des applications et des intégrations à partir de services faiblement couplés. En décomposant les applications en modules indépendants, il est plus facile de les développer, tester, modifier, retester, corriger, déployer, tester en production, mettre à niveau, et ainsi de suite.

Les microservices soutiennent le modèle DevOps grâce aux tests automatisés. En raison de leur petite taille, ils sont faciles à placer dans des conteneurs qui servent à automatiser le processus de test ainsi qu'à simplifier l'intégration et la distribution continues (CI/CD). A contrario, un ESB monolithique ne tient pas dans un conteneur et ne peut pas être décomposé ; impossible donc de le tester de la même manière.

Le principal argument en faveur de l'adoption de l'intégration basée sur des microservices est sans doute qu'elle permet aux développeurs agiles d'utiliser leurs outils DevOps favoris. Sans ESB, les développeurs sont libres de travailler dans l'environnement de développement agile de leur choix. Ils n'ont pas besoin d'être formés à l'utilisation d'un système propriétaire et peuvent ainsi concentrer leurs efforts sur une approche plus productive.

Par ailleurs, les microservices rendent l'intégration plus accessible. Elle n'est plus réservée à une équipe de spécialistes des ESB et chaque développeur peut déterminer ses propres besoins en matière d'intégration. Cette démarche est plus logique, car personne ne comprend mieux les exigences liées aux données d'une application que son développeur.

Les microservices facilitent aussi la gestion des API et, par conséquent, l'intégration basée sur des API (si besoin).

Enfin, l'intégration basée sur des microservices offre les mêmes avantages qu'un ESB, notamment la transformation graphique et la logique pour créer des règles sophistiquées concernant les transferts de données dans l'entreprise. Ainsi, si vous aimez les interfaces de développement graphiques des ESB, sachez qu'il existe des interfaces similaires compatibles avec l'intégration basée sur des microservices.

L'intégration basée sur des microservices apporte un certain nombre d'avantages :

  • Surveillance et gestion complètes : les développeurs agiles peuvent surveiller les microservices à l'aide des meilleurs outils (Kibana, ElasticSearch, Grafana, Prometheus, etc.) et identifier les points de défaillance, ce qui permet la résolution des problèmes avant qu'ils n'affectent l'entreprise.
  • Tests automatisés : les tests automatisés sont l'un des principaux avantages des microservices et du DevOps. Chaque intégration est testée en tant que composant indépendant, et ce, sans jamais perturber les autres composants de l'application ni les autres applications.
  • Logiciels de meilleure qualité : avec des processus plus efficaces et de meilleurs résultats de test, la qualité des logiciels s'améliore forcément.
  • Développement accéléré : la rationalisation du développement des intégrations grâce au DevOps et à l'automatisation ainsi que l'élimination des processus manuels permettent de réduire la durée du développement.
  • Évolutivité supérieure : puisqu'une application est constituée de modules séparés, chaque service peut être mis à l'échelle de façon indépendante sans affecter le reste de l'application.
  • Innovation encouragée : grâce à la combinaison microservices/DevOps, les développeurs peuvent imaginer des solutions d'intégration qui permettent à l'établissement de lancer de nouveaux services et de mieux servir les clients.
  • Agilité métier : le développement agile favorise naturellement l'agilité métier, c'est-à-dire la capacité à s'adapter rapidement à l'évolution du marché. Imaginons que de nouveaux partenaires ou fournisseurs aient besoin d'accéder à certaines données de l'établissement. Grâce aux microservices, les développeurs agiles peuvent créer rapidement les intégrations nécessaires pour permettre ces nouvelles relations professionnelles.
  • Expérience client améliorée : votre objectif premier consiste à servir les clients, en l'occurrence les patients qui dépendent au quotidien de vos services de soin. En améliorant les processus et en simplifiant le partage des données entre les systèmes et services, vous leur offrez une expérience satisfaisante.

Vous redoutez peut-être la migration de votre modèle d'intégration vers des microservices. Pourquoi changer ? Après tout, votre équipe maîtrise déjà les éléments propriétaires de l'ESB que vous utilisez depuis si longtemps. C'est précisément là le problème. Supposez qu'un ou deux spécialistes de l'ESB quittent votre établissement. Comment ferez-vous pour retrouver le même niveau de compétences ?

La difficulté prétendument insurmontable que représente l'abandon de l'ESB monolithique est justement la raison pour laquelle il faut relever le défi. Lorsque vous vous serez affranchi de ses limites, vous pourrez exploiter tout le potentiel d'un nouveau monde d'intégration.

Cas d'utilisation d'un Event Mesh

Combinée à l'Event Mesh, l'architecture orientée événements est capable de prendre en charge de nombreux cas d'utilisation, avec des topologies multicloud complexes hautement distribuées et des piles d'applications diverses. Voici quelques-uns des nombreux cas d'utilisation potentiels de l'Event Mesh.

Intégration des microservices

Un Event Mesh permet de connecter entre elles des applications basées sur des microservices ainsi qu'avec les technologies existantes.

Commerce en ligne

Un Event Mesh accélère le traitement des transactions et améliore la rapidité et la fiabilité des interactions avec les clients via les sites web et les applications.

Assistance clients

Un Event Mesh assure la transmission rapide des données d'interaction pour permettre à l'assistance de répondre en temps réel aux clients et d'offrir ainsi une expérience personnalisée.

Services financiers

Un Event Mesh offre une latence faible pour la synchronisation des données boursières en temps réel. Il peut aussi faciliter la détection des fraudes en envoyant instantanément des informations sur les transactions suspectes.

Connectivité de l'IoT

Un Event Mesh apporte une connectivité fiable et évolutive pour l'Internet des objets (IoT) aux systèmes back-end, qui peuvent ainsi traiter les indicateurs de mesure renvoyés par quasiment tous types de capteurs.

L'infrastructure Event Mesh procure de nombreux avantages à l'entreprise.

Des réponses en temps réel

La réussite d'une entreprise est conditionnée par sa capacité à réagir au changement. La réactivité est l'un des principaux avantages que procure l'Event Mesh grâce à la transmission en temps réel des données, sous forme de flux d'événements via une architecture orientée événements. Très efficace, l'Event Mesh détermine le trajet le plus rapide entre le producteur et le consommateur, pratiquement sans latence. Les équipes peuvent ainsi réagir rapidement en cas de problèmes critiques qui exigeraient des décisions urgentes.

Une expérience client améliorée

En transmettant en temps réel les données utilisées par les équipes en contact avec la clientèle et par les technologies de commerce en ligne, l'Event Mesh permet aux entreprises de mieux servir les clients et donc de leur offrir une meilleure expérience.

Des coûts d'exploitation réduits

Grâce aux informations sur la production, les ventes, les stocks et les expéditions accessibles en temps réel, les entreprises peuvent optimiser l'exploitation, gagner en efficacité et réduire les coûts.

Des développeurs plus productifs

L'Event Mesh ne dépend d'aucun environnement, système de messagerie ou protocole. Les développeurs peuvent donc concentrer leurs efforts sur le déploiement d'une logique métier basée sur les meilleures technologies. C'est autant de temps consacré à l'innovation plutôt qu'à la mise en place d'un réseau complexe de transmission des données, et ce, sans restrictions concernant l'environnement de développement, la plateforme de messagerie ou le type de cloud.

Pour aller plus loin

ARTICLE

Les microservices comme technologie d'intégration dans le secteur de la santé

Les microservices permettent aux développeurs, notamment ceux du secteur de la santé, de créer des applications qui sont constituées de services faiblement couplés, ce qui facilite les étapes de développement, de test, de déploiement et de mise à niveau.

ARTICLE

Les microservices, qu'est-ce que c'est ?

Les microservices désignent une approche architecturale du développement d'applications selon laquelle les différentes parties d'une application fonctionnent en synergie tout en étant séparées.

ARTICLE

Un Service Mesh, qu'est-ce que c'est ?

Un Service Mesh est une couche d'infrastructure comprise dans une application qui permet de documenter les interactions entre les services, pour simplifier l'optimisation des communications et réduire les temps d'arrêt.

En savoir plus sur les microservices

Produits

Red Hat OpenShift

Plateforme de conteneurs Kubernetes pour les entreprises qui automatise l'exploitation de toute la pile pour la gestion des déploiements multicloud, de clouds hybrides et d'edge computing.

Ressources

Livre numérique

La voie vers les applications natives pour le cloud

Livre numérique

Apprendre la danse à un éléphant : synthèse

Formations

Cours gratuit

Développement d'applications cloud-native avec des architectures de microservices

Illustration - mail

Ce type de contenu vous intéresse ?

Inscrivez-vous à notre newsletter Red Hat Shares.