Laissez-vous tenter par les mashups

Pierre Tran

01 Informatique

le 07/01/2009 à 07h00

envoyer
par mail

imprimer
l'article

Les mashups, ces applications combinant sur une page Web des données provenant de sources multiples, sont apparus vers 2005 avec la disponibilité des services web de Google Maps et d'Amazon. Les premiers mashups étaient orientés grand public, mais les entreprises ont commencé à comprendre l'intérêt d'utiliser cette technique pour combiner des données provenant de leurs applications avec des services existants, tout d'abord externes et, de plus en plus, internes. Les spécialistes de l'intégration d'applications – BEA, IBM, Tibco – ont alors proposé leurs offres. De nouveaux venus sur ce marché, notamment Serena et Twinsoft, les ont rejoints. Le cabinet Forrester prévoit que le marché des mashups d'entreprise atteindra 700 millions de dollars vers 2013.

Mais bien que le mouvement semble avoir pris aux Etats-Unis, on est encore loin d'un raz-de-marée. En France, c'est à peine si on a entendu parler de cette technologie. Et pourtant, il est probable que, comme M. Jourdain faisait de la prose, les utilisateurs utilisent déjà des mashups sans le savoir. Ne serait-ce qu'à travers des flux RSS, des sites d'itinéraire ou de réseaux sociaux. Fred Cavazza, consultant indépendant, voit toutefois deux freins principaux à leur adoption en entreprise : la disponibilité effective des données de l'entreprise (car non exposées aux utilisateurs) et une certaine réticence des DSI, qui y voient une perte de leur pouvoir.

Pourtant, la technologie des mashups ne manque pas d'atouts. Elle pourrait devenir une stratégie gagnant-gagnant pour les utilisateurs et pour le DSI, pour peu qu'on se donne la peine de s'y pencher un peu.

Les usages

Parmi les usages des mashups, on citera d'abord l'agrégation d'informations en self-service. L'utilisateur crée lui-même son tableau de bord en combinant des données de sources diverses pour un besoin ponctuel : une étude de marché, une analyse de compétitivité, une gestion des risques…

Autre usage, le développement d'applications jetables. Les mashups permettent de bâtir rapidement – et sans s'encombrer de la gouvernance du service informatique – des prototypes, des démos, ou de petites applications ponctuelles très spécifiques à usage restreint, traditionnellement à la charge des informaticiens.

Fait non négligeable, le mashup est aussi un moyen d'accéder aux données des applications existantes, pour peu que les flux correspondants soient créés. C'est donc une façon rapide de moderniser son patrimoine applicatif, de mettre en place une pseudo-architecture orientée services et de se constituer une solution d'intégration d'applications (EAI) simplifiée. Parmi les autres utilisations figurent l'intégration de ressources applicatives externes (applications SaaS, interaction avec le SI des clients ou fournisseurs) et la publication d'applications dans un environnement mobile.

Les technologies

Au cœur des mashups, on trouve des API, des services web, des widgets et des flux RSS. Les API sont les interfaces de programmation qui permettent d'accéder à des services web existants, par exemple Google Maps ou Amazon, ou à des applications d'entreprise exposées sous forme de services web.

Un widget ou, selon les éditeurs, gadget, block ou flake, est un petit composant applicatif ou un contenu dynamique qui peut être facilement placé dans une page HTML. Il peut être écrit en n'importe quel langage (Java, .NET, PHP), voire en HTML, et il encapsule, en général, une API pour accéder à une source ou à un flux de données.

Comme pour toutes les technologies un peu nouvelles, on trouve de grands débats pour définir ce qui est et ce qui n'est pas un mashup. Un portail est-il un mashup ? Une application composite est-elle un mashup, ou l'inverse ? Des éléments de comparaison apparaissent en distinguant les trois typologies de mashup existantes : par ordre de complexité croissante, les mashups de présentation, ceux de données et ceux de processus.

Au niveau basique, le mashup de présentation agrège des données de diverses sources et affiche les blocs de données dans une même page. Il n'y a aucune interaction entre les blocs. D'un point de vue fonctionnel, on se retrouve avec un portail, les technologies utilisées sont juste différentes. Netvibes est l'exemple type d'un mashup de présentation.

Le mashup de données, outre présenter les données dans une même page, autorise une interaction entre les données en maintenant un contexte entre les différentes sources. Les données peuvent être combinées, manipulées et liées ensemble pour recréer une nouvelle source de données ou un nouveau service. Fonctionnellement, on se rapproche d'une solution d'intégration avec des fonctionnalités de tableau de bord. L'offre d'IBM permet, par exemple, de créer ce type de mashup.

Au niveau le plus élaboré, le mashup de processus permet non seulement de mixer les données, mais aussi les processus métier, de personnaliser la conception des processus et d'invoquer une logique métier à travers une suite d'applications. Ce type de mashup commence à ressembler à un moteur de BPM (Business Process Management). Les solutions de Serena et de Twinsoft sont à ranger dans cette catégorie.

Les offres

Il existe deux grands types d'outils génériques : les outils de composition et les serveurs de mashups.

L'outil de composition se présente comme un environnement de conception visuelle, avec une palette qui permet de glisser-déposer des services web, des flux de données ou bien des processus métier, de les relier entre eux, de les mixer, de les transformer, et de choisir un modèle de présentation.

Le serveur de mashups peut avoir plusieurs rôles : mettre à disposition les sources de données, découvrir et partager des widgets, gérer et partager les mashups à l'intérieur et à l'extérieur du pare-feu. Il fait office de hub de mashups.

Autour de ces deux types d'outils on peut trouver des outils de création de widgets et de composants métier, des modules qui permettent d'exposer en services web, ou en portlets, des applications héritées (mainframe, mini), des applications web classiques, ou même des portions de page HTML

Le nouveau rôle du service informatique

Grâce à la facilité d'usage des outils de composition, les utilisateurs satisfont eux-mêmes à leurs besoins. Mais ils peuvent aussi se retrouver bloqués. Par exemple, l'accès à une donnée particulière n'a pas était prévu au départ, et il nécessite des développements importants. Problème identique lorsqu'ils doivent connecter deux sources de données. Dans ce cas, le service informatique risque bien d'être mis à contribution pour leur porter assistance.

Un petit mashup développé au départ pour un besoin ponctuel peut aussi devenir populaire et s'enrichir progressivement de boutons, de workflows, pour devenir un beau jour une application stratégique. Développée de la sorte, il y a fort peu de chances pour que l'application supporte la montée en charge correspondante. D'où un nouveau problème de maintenance pour le service informatique.

Attention aussi aux désillusions, au “ syndrome BI ”. Il y a quelques années, les éditeurs clamaient que la Business Intelligence allait permettre aux utilisateurs de créer eux-mêmes leurs propres rapports de gestion sans intervention des informaticiens. On connaît la suite… Avec les mashups la situation peut devenir similaire, les outils s'avérer plus difficiles à utiliser que prévu, et certaines sources de données impossible à mettre à disposition des utilisateurs. Ils ne pourront alors créer des mashups réellement utiles. Pour éviter les déconvenues, pour les utilisateurs comme pour la DSI, il faut mettre en place dès le départ une gouvernance des mashups. Il sera aussi nécessaire de prévoir un programme de formation et de support aux utilisateurs.

Mais surtout, avant de permettre la libre création de mashups, il faudra vérifier que le besoin est “ mashable ” : dispose-t-on de toutes les sources de données nécessaires ? Sont-elles fiables ? L'application sera-t-elle utilisée par une ou quelques personnes ou par des centaines d'utilisateurs ? L'application est-elle stratégique pour le métier ? L'utilisateur a-t-il les compétences nécessaires pour créer le mashup ?

Le nouveau rôle du service informatique consiste ici à assurer la disponibilité et la consistance des données de l'entreprise pour alimenter les mashups et administrer le référentiel de mashups des utilisateurs. Une charge bien moins lourde que de gérer une équipe de développeurs en charge de satisfaire les besoins métier des utilisateurs. De plus, les utilisateurs seraient “ forcément ” heureux de leurs applications faites sur mesure par eux-mêmes… Et la DSI soulagée d'une tâche parfois ingrate. Alors, pourquoi ne pas se laisser tenter ?

Architecture d'une plate-forme de mashup

agrandir la photo

Dans ce bulletin de visite client, le mashup affiche en bandeau la fiche issue de l'application de GRC de Salesforce. Le commercial sélectionne dans une liste déroulante le nom du client à visiter.

Le widget Chart de Visifire récupère les données de la GRC, et affiche dans un graphique les modes d'interaction habituels du client sélectionné.

Au sein d'autres widgets, le mashup peut afficher des flux RSS d'actualités et des données financières liées à l'entreprise du client : autant d'informations utiles au commercial, ne serait-ce que pour trouver des sujets de conversation avec le client.

Le mashup peut se connecter aux réseaux sociaux (Linkedin, Facebook, etc.) pour visualiser les relations et l'activité professionnelle et sociale de la personne à visiter.

Le composeur de mashup

agrandir la photo

Comme dans d'autres outils du même type, l'interface de composition graphique des mashups de Serena Mashup Composer rappelle certains environnements de développement intégré.

1. Le sélecteur d'espace de travail. Dans cette arborescence, l'utilisateur choisit sur quel aspect du mashup il travaille : formulaire, sources de données, workflow de l'application, etc.
2. L'espace de travail principal. Celui-ci fait apparaître une partie du formulaire. Une vue globale apparaît en bas à droite de l'environnement.
3. La palette du formulaire. Elle comprend les éléments (zones de texte, images, contrôles, widgets proposés par le service informatique ou glanés sur le web) que l'utilisateur-développeur peut incorporer dans son mashup, par simple glisser-déposer sur l'espace de travail.
4. Le paramétrage du composant. Pour certains composants, il est nécessaire de régler les attributs pour définir leur comportement, notamment lorsqu'une source de données externe est utilisée.