Apigee plaide pour la création d'un API World

Vendredi dernier, le spécialiste de la plate-forme API (donc des applications et du développement) Apigee voyait accepté son dossier d'introduction en course au Nasdaq, première étape vers l'introduction en bourse à New York. Un signal fort de la part des financiers, conscients de l'intérêt de ces technologies, et qui consacrent ainsi la place centrale de ce type d'acteurs dans un avenir proche.

Apigee orchestre l'infrastructure applicative des échanges informatiques d'acteurs comme Uber ou Netflix. Quel que soit l'avis que l'on ait sur ces acteurs, il convient de constater que l'informatique, élément essentiel de leur modèle, s'avère efficace. La société s'est jusqu'à présent montrée très discrète. Pourtant, créée en 2005, elle a déjà levé plus 173 millions de dollars en 7 fois, auprès de 11 investisseurs. Dont un dernier tour fin avril 2014 pour 60 millions de dollars.

Logique donc qu'elle organise une journée sur les API baptisée «I Love APIs, Get Digital Ready» (J'aime les API, soyez prêt pour l'ère numérique). Autre conséquence illustrant encore l'intérêt pour le sujet, les organisateurs attendaient 250 participants, et 400 sont venus à Londres.

Chet Kapoor - Président d'Apigee

Une longue marche déjà initiée vers l'API Mass Customization !

« L'entreprise numérique crée de la valeur en procurant une expérience numérique à ses clients, partenaires et employés,» pose Chet Kapoor, président d'Apigee (ex VP chez IBM, CEO de Gluecode, VP chez BEA, etc.). «L'arrivée du Web n'a pas modifié l'activité principale de votre entreprise. D'ailleurs, la chaîne de valeur est généralement identique. En revanche, le numérique bouleverse réellement le business model. Ainsi, si l'iPhone a lentement fait disparaître le BlackBerry, Uber a totalement chamboulé le modèle des taxis et des transports aux États-Unis.»
Puis, il décrypte deux démarches, pas forcément antinomiques: la création de directions marketing, des ventes et des opérations que l'informatique s'attèle à relier entre elles ; et, un modèle ou le client est au centre d'une activité au coeur de laquelle l'informatique est au service des métiers pour favoriser la meilleure livraison possible du produit ou du service.
« Après avoir informatisé le marketing et les canaux, puis les processus et les opérations, le temps est venu de numériser le business model,» assène Chet Kapoor.

Une première évolution par exposition

Que peuvent apporter les API dans ce modèle où se déploient déjà depuis des années les bus d'intégration applicative (ESB) et les services Web ?
Rassurant, le dirigeant lance: « Les investissements réalisés pour les systèmes transactionnels ont demandé de nombreux efforts depuis des années. Ils restent utilisables et il n'est pas nécessaire de tout casser ! Cependant, les besoins sont différents pour les clients, partenaires et employés pour lesquels il faut disposer d'un système d'engagement [ou système d'enrôlement/d'implication.]. Une plate-forme API permet de rendre l'entreprise agile, par un positionnement au coeur du système dont elle devient le chef d'orchestre.»
En effet, l'ESB favorise les échanges entre applications, voire le partage de composants. Cependant, la fonction ou le composant reste généralement un des éléments de l'application originelle.

Stade 2 : Penser API d'abord !

« Il existe plusieurs façons d'évoluer vers les API,» explique Ed Anuff, vice-président stratégie Produit chez Apigee. «L'exposition de services est l'un des scénarios possibles. Proche des services Web, cette technique donne accès à une fonction existante, sans savoir a priori à qui elle sera destinée. Il est d'ailleurs possible de la suivre et même d'en monétiser l'utilisation. Cette généralisation peut fonctionner dans certains cas, à l'instar des cartes de Google Maps que chacun peut intégrer à un site Web. Dans le cas d'une entreprise, l'approche API First est préférable, car elle permet d'exposer la fonction à une ou quelques applications bien connues et identifiées, via une plate-forme qui assurera des services comme la sécurité, la persistance, l'orchestration, l'analytique. Il est ensuite possible (si nécessaire) de la rendre publique. A plus long terme, l'API Mass Customization rendra cette plate-forme centrale, les développeurs y créeront des fonctions utilisables par des utilisateurs identifiés, et les applications seront essentiellement un assemblage.» (voir les illustrations)

Le monde idéal de l'API, si l'on part de zéro.

Plus que de l'ESB, c'est l'avenir !
Autre grande différence d'approche entre API et ESB est mise en exergue par ces deux experts. Dans le cas du bus d'intégration (ESB), il s'agit plutôt de briser des silos applicatifs, et l'on considère le problème en l'étudiant du point de vue des applications.
« Avec les API, on se place du point de vue de l'application finale, du client. Et cela change tout,» insiste Anant Jhingran, vice-président Produits chez Apigee (en fait, plutôt directeur technique - ex VP et CTO chez IBM). « Les ESB sont conçus pour favoriser l'exposition de processus ou de services existants, tandis qu'une plateforme API regroupe des éléments conçus précisément pour les consommateurs d'un service qu'ils rendent spécifiquement. Si le besoin est très global et ne nécessite pas de traitement ou considération précise, alors l'ESB peut généralement convenir. Les API permettent de concevoir du code simple qui réalise des traitements très rapidement. L'ESB répond plutôt à des besoins complexes, nécessitant moins de rapidité et de flexibilité.»

On comprend alors la nécessité de disposer d'une plateforme dédiée aux API au centre du système, qui puisse évoluer de façon simple, avec agilité et élasticité, et en répartissant la charge dynamiquement pour obtenir les meilleures performances possible. Et l'attrait pour Apigee dont nous évoquerons très bientôt l'offre et le positionnement.

A lire aussi :

IBM instille du deep learning à Watson avec AlchemyAPI

Qlik Branch, une plateforme ouverte au partage d'API entre développeurs