Un choix d’architecture

Les technologies Internet sonnent comme une réponse évidente aux besoins de déploiement rapide et massif de nouveaux services. Dans l’assurance maladie comme ailleurs, l’offre de services ciblant un grand nombre d’utilisateurs trouve dans Internet un media naturel. Sans Internet, il n’est pas possible de déployer un service à grande échelle avec un coût considéré comme raisonnable, et surtout dans un délai acceptable.

L’uniformité apparente d’Internet cache en pratique des différences d’autant plus importantes que les choix d’architecture des services sont structurants pour les utilisateurs eux-mêmes et leur environnement de travail, et ne peuvent donc être remis en cause facilement sans modifier sensiblement cet environnement : installer ou mettre à jour des librairies, des exécutables, modifier des options du navigateur (cas de la gestion des pop-up). Ces choix ne sont pas apparents pour l'utilisateur, mais le choix relatif au modèle d’échange de données entre l’utilisateur final et les serveurs applicatifs me paraît toutefois particulièrement important.

Dans le monde du Web, plusieurs modèles d’échange de données entre client et serveur coexistent et se chevauchent : un modèle orienté « ressources », sans mémoire, à base de sélection d’URL, théorisé sous le nom de « REST », et un modèle orienté « verbes » privilégiant le couplage fonctionnel entre le client et le serveur, type RPC. L’article correspondant de Wikipedia décrit bien les deux philosophies d’échange.

Le modèle REST représente le Web dans son état originel. Comme Monsieur Jourdain, la plupart des sites Web font du REST sans le savoir. Le modèle orienté « verbes » à la sauce RPC, SOAP ou Web Services, est aujourd’hui plus restreint dans son usage mais rencontre un vif succès auprès des DSI et dans le monde informatique en général (cf. Web 2.0). Il soulève toutefois des questions qui ne sont pas toutes résolues dans notre contexte assurance maladie.

Des questions de déploiement tout d’abord. Il semble qu’au delà de l’affichage marketing, faire du Web Services n’est pas si simple pour les éditeurs de progiciel santé. Il faut intégrer sur le poste client une couche technique de gestion du service. Dans le modèle REST la couche technique à implémenter paraît plus limitée. Se pose également la question de la performance et de la fiabilité du service, même si elle n’est probablement que transitoire, liée à la maturité des applications ou des outils utilisés. Les Web Services sont peut être éprouvés dans une liaison serveur à serveur, mais avec des milliers d’utilisateurs simultanés, cela est moins évident. Ce n’est qu’un exemple, mais lorsque je mets à jour mon blog sur la plate-forme Blogger (qui héberge des millions de blog), en utilisant les API Atom, les erreurs en retour sont fréquentes. Personnellement je n’ai jamais eu de problème à afficher la page d’accueil de Yahoo ou Google.

Une question plus technique ensuite. Dans le secteur santé, on est évidemment exigeant sur la confidentialité et la protection des données. Les cartes V i t a l e et C P S sont des éléments d’un système global de sécurité spécifique, conçu pour protéger les données nominatives des assurés sociaux. Or par définition il est difficile d’intégrer un dispositif sécuritaire spécifique dans un standard applicatif comme les Web Services, à moins de n’utiliser qu’une partie du standard.

Dans l’assurance maladie, le modèle « Plain Old XML » sur HTTP sera-t-il préféré aux Web Services ?

Je vous salue bien bas,
Alexis.