Cloud Computing recherche standards désespérément

SaaS : Des applications pas toujours riches en API pour assurer une interopérabilité

«Pour des raisons de coûts, nous avons migré notre plateforme SaleForce.com vers la solution ZohoCRM et il nous a fallu quatre jours pour l'exécuter » indique Mathieu Hug, fondateur de RunMyProcess dont le métier est d'interconnecter différentes applications SaaS. Le plus important est de récupérer toutes les données. Pour cela, RunMyProcess a utilisé les API fournies avec les solutions SaaS. Ces dernières  facilitent l'interopérabilité entre les applications. « C'est le principe des mashups, couramment utilisé dans le Web 2.0» souligne Guillaume Plouin, responsable de l'offre Cloud chez Octo et, d'ajouter «on assiste dans le SaaS à une standardisation des API permettant la réversibilité des données...». Mathieu Hug tient néanmoins à préciser que certaines applications SaaS ne disposent pas d'API, c'est d'ailleurs souvent des applications spécifiques que l'on retrouve dans les petites et moyennes entreprises. Dans ce cas, on est bloqué. « Effectivement, concernant les applications métiers, les entreprises sont très liées à leur fournisseur, c'est normal, elles ont été créées pour répondre à leurs réels besoins» précise Nicolas Odet, responsable marketing et communication de la SSII Hardis qui met l'accent sur la spécificité et la criticité de certaines applications.

Les API liées aux web services

Les API SaaS utilisent pour la majorité des cas deux formats de services web Rest (REpresentational State Transfer) et Soap (Simple Object Access Protocol). Les web services Soap utilisent le langage XML et permettent de réaliser des échanges entre un client et un serveur via le protocole HTTP. De leur côté, les web services Rest se limitent à l'utilisation du protocole HTTP pour les entrées/sorties. Ils ne sont pas contraints à utiliser XML comme langage et leurs échanges entre le client et le serveur sont moins verbeux que ceux de SOAP, ce qui les rendent plus simples. On le voit, l'existence d'API, et leur complétude fonctionnelle, est donc un vrai enjeu, un critère de choix absolument stratégique.

La gestion des identités en manque de standards

Le manque de standard et d'interopérabilité des applications pose aussi un vrai problème sur la gestion des identités et des mots de passe. Le problème se pose à deux niveaux selon Matthieu Hug (en illustration principale), au niveau des interfaces et au niveau des API.

Pour les interfaces utilisateurs (pages web, etc.), il y a effectivement une standardisation qui se fait autour du protocole SAMLv2 pour le SSO (Single Sign On) et OpenID/oAuth pour la fédération des identités. Un avis que partage Guillaume Plouin. En revanche, au niveau des API, aucun standard n'existe. « C'est un élément très largement oublié ou passé sous silence, mais critique pour une quelconque interaction automatisée » confirme Matthieu Hug. Et d'ajouter « nous proposons dans RunMyProcess un mécanisme de "coffre-fort d'authentification" qui permet de stocker les éléments critiques de l'authentification de manière sécurisée chez nous, lesquels éléments ne peuvent être utilisés que par notre plateforme pour faire appel aux API suivant le mécanisme indiqué par le client ».  Ce n'est certes pas une norme, mais un mécanisme pragmatique, avec une gestion centralisée et sécurisée. On le voit bien, la portabilité des applications inter-cloud est devenue une étape nécessaire pour faire évoluer l'informatique dans le nuage et rassurer de ce fait les décideurs IT dans les entreprises.

>> Sommaire du dossier

. Le manque d'interopérabilité freine-t-il l'adoption du cloud ?

. IaaS : L'Open Source, avenir du cloud computing?

. PaaS : Pas d'interopérabilité entre les plateformes...

.SaaS : Des applications pas toujours riches en API pour assurer une interopérabilité.

.Interview d'Alphonso Castro, directeur de la stratégie interopérabilité chez Microsoft France.