API : une économie ou une tour de Babel ?
Les interfaces de programmation (API) font la promesse d’ouvrir les back-offices des entreprises aux tiers. Mais au final, quel est l’impact ?
Les interfaces de programmations (API) sont actuellement au cœur de débats. Les fournisseurs de technologies et quelques entreprises vouent un culte à l’économie des APIs, comme si finalement l’avenir de l’IT et des entreprises en dépendait.
Les APIs sont-elles si importantes ? Oui et non, répondent au final des analystes.
Mais nous devons d’abord savoir dans quelle mesure les APIs sont nécessaires, comment elles peuvent être utilisées et pourquoi elles sont devenues plus importantes qu’auparavant.
Historiquement, les applications restaient centrées sur un unique segment de l’activité de l’entreprise. Les SIRH prenaient en compte les problématiques liées au RH, les CRM aux interactions avec les clients, les ERP géraient une partie des fonctions de back-office. Chacune, jusqu’à un certain point, fonctionnant de façon autonome – les systèmes généraient leurs propres données, avec leurs systèmes de reporting et les utilisateurs en étaient satisfaits.
Sauf que ce n’est plus le cas. Ces systèmes étanches ont créé leur propre silo de données. Les entreprises réalisent qu’elles doivent désormais rapprocher ces silos de données afin d’améliorer les analyses. Cela a conduit les entreprises vers l’EAI (Enterprise Applicatios Integration) et les ESB (Entreprise Service Bus), mettant en place un certain nombre d’interactions entre les applicatifs.
Cette approche nécessitait au final de composer avec chacune des applications de l’équation. D’où la besoin d’APIs.
Grâce à une API, le propriétaire d’une application crée une série de méthodes d’accès qui peuvent être appelées par une autre application. L’API est documentée et, si correctement utilisée, crée une couche d’abstraction entre les deux applications. Avec cette approche, chacune des applications peut être modifiée ou mise à jour sans affecter la façon avec laquelle elles dialoguent.
S’adapter aux systèmes qui interagissent avec le client
Ce mécanisme est devenu d’autant plus important avec la montée en puissance des terminaux mobiles. Le besoin de créer une abstraction, entre la façon dont l’utilisateur interagit avec les données et comment il l’utilise (on parle de système d’engagement) et celle liée au stockage et à la gestion de ces mêmes données (« System of record »), est clé pour que des modifications sur le premier soit effectué selon le rythme souhaité par les clients, mais sans avoir à modifier le second.
Toutefois, des APIs comportent encore des fonctions clés qui ne sont pas documentées. Par exemple, certains propriétaires d’applications peuvent se réserver des fonctions pour accroître de leur côté le champ fonctionnel ou le niveau de performance, plaçant les tierces parties dans une situation de désavantages. D’autres peuvent encore être mal codées et contenir des vulnérabilités pouvant être exploitées par des pirates.
Si les développeurs d’applications entrent directement dans les APIs, les problèmes déjà rencontrés avec la création d’applications composites, comme avec la SOA (Software Oriented Architecture), se répètent de nouveau. La SOA symbolisait l’abandon du couplage étroit (qui crée des dépendances entre deux fonctions) en exposant les fonctions sous la forme de services, régis dans un mécanisme de couplage plus lâche – facilitant leur remplacement.
Toutefois, de nombreuses applications reposant sur les principes de la SOA comportent encore des services où le couplage est très fort. Et pour corser l’histoire, le Cloud Computing est arrivé. Pour que le Cloud tienne véritablement ses promesses, une approche radicalement différente de l’application est nécessaire. Au lieu d’utiliser un système ERP ou CRM, le Cloud donne la possibilité de migrer vers une application composite, qui repose sur un ensemble de fonctions spécifiques, assemblées pour répondre à un processus spécifique.
Ces fonctions peuvent être internes, dans un Cloud privé ou dans un Cloud public. Elles doivent être assemblées rapidement et efficacement. Et cela ne peut être fait que via des APIs.
Mais qu’arrive-t-il si ces APIs ne sont pas ouvertes, ou tout simplement insuffisantes ? Pouvez-vous prendre le risque que l’application composite comporte des risques de sécurité, ou que l’application ne fonctionne pas à cause d’une API mal documentée ?
Le rôle de la gestion d’APIs
C’est là qu’entrent en jeux les solutions de gestion d’APIs. Des nombreux fournisseurs ont à leur catalogue des solutions qui répondent à ce besoin et le cabinet Quocirca anticipe un accroissement du marché, avec la montée en puissance du Cloud.
La gestion d’APIs consiste à ce que la solution administre les autorisations et la sécurité entre les fonctions appelées et les réponses, tout en gérant les audits, les transformations (s’assurer par exemple que les fonctions d’appels formulent leurs appels d’une façon comprise par les fonctions de réponses).
Nombres de systèmes proposent aussi des portails capables de gérer le billing et le mode self-service, mais ceux-là peuvent encore être considérés comme accessoires, et non pas comme une nécessité.
Mais quels sont les acteurs en place ? CA a racheté Layer 7 en 2013, un acteur important de la gestion des APIs. API Management Service d’IBM disposent d’outils pour assembler des fonctions réparties sur plusieurs plateformes, y compris celles de son environnement SoftLayer.
WSO2 est un système de gestion d’APIs Open Source extensible avec de bonnes fonctionnalités. Apigee gagne en popularité et propose un outil gratuit de création d’APIs (Edge). Fiorano Software s’intéresse quant à lui aux applications composites en direct, via des microservices.
Intel a racheté Mashery en 2013 (la société est tombée fin août dans le giron de Tibco), mais la solution n’est pas forcément favorite. Akana (anciennement SOA Software) est quant à lui fortement considéré, avec son approche historique des architectures SOA.
Dell, avec l’acquisition de Boomi, a gagné des outils d’intégration et d’administration des APIs. Ces outils sont une bonne extension de son offre d’agrégation de services Cloud.
Parmi les autres acteurs, on retrouve Axway, Mulesoft et d’autres acteurs du monde de l’ESB, comme Tibco. Citons également le Français Restlet et son Paas APISpark capable de prendre en charge l’ensemble du cycle de vie d’une API.
Mais comme tout segment de marché naissant, un problème apparait : on y trouve de nombreux fournisseurs, bataillant pour trouver leur place, mais empruntant des chemins différents. Il existe également peu de standards en place ; le choix d’un mauvais outil peut donc laisser l’entreprise sans la possibilité d’accéder à de nouvelles fonctions et surtout sans la capacité à revenir en arrière et de migrer d’un système vers un autre pour conserver la façon dont les applications ont été développées.
Faire le bon choix
Il est donc crucial de s’assurer que le bon choix ait été fait – ou du moins, le moins mauvais. Il faut également d’assurer que l’outil de gestion d’API soit flexible et dispose d’une vaste sélection de connecteurs et de méthodes éprouvées pour, à la fois, accéder aux données et à la logique métier.
Préférez également les fournisseurs qui ont un bon écosystème, avec des partenaires channels qui fournissent des services sur mesure sur des solutions de gestion d’API lié à un domaine ou spécifique à l’entreprise. Il est également nécessaire de s’assurer que les outils choisis garantissent un bon fonctionnement des APIs, mais également puissent les contrôler et appliquer des fonctions de sécurité et d’audit à l’application composite.
Si vous opérez dans un environnement de type Cloud hybride, recherchez plutôt des systèmes capables de gérer le billing, pour une utilisation en temps réel des fonctions commerciales. Dans de nombreux cas, il sera opportun de chercher des intégrateurs doués de fonctions de gestion d’APIs, capables de fonctionner de pair avec vos systèmes. Vérifiez enfin que les données fournies sont compréhensibles et exploitables par votre environnement, et que les requêtes envoyées par votre système soient comprises par le système du fournisseur.
Le marché de la gestion d’APIs et des outils associés est encore jeune. Peu d’entre eux ont atteint la maturité. Nombre de fournisseurs parviendront difficilement à faire évoluer leur produit et certains resteront sur le bas de la route. D’autres opteront pour de nouvelles approches, comme l’API Management-as-a-service.
Du côté des utilisateurs, le problème est bien d’éviter les nombreux pièges qui pourraient joncher la route vers les APIs. On ne peut pas prétendre que toutes les applications et les fonctions s’appuieront sur une unique API. Les développeurs vont continuer à créer leurs propres APIs, pensant que la leur est la meilleure. Il est en revanche plus logique de prétendre que les APIs, tant des applications et des fonctions, évolueront à un rythme différent et qu’une solution de gestion d’APIs flexible soit ainsi nécessaire.
