Gestion des API : il ne faut pas perdre ses objectifs en route

Qui est le responsable ?

Les équipes de développement ont à charge la création d’API, et dans la plupart des cas, ce sont aussi ces mêmes équipes qui gèrent l’acquisition et la mise en place de services tiers via des API. Cela est pratique si le développement dispose d’une forme d’exclusivité dans la création du portefeuille d’API de l’entreprise. Ce portefeuille doit en effet fournir les caractéristiques des API, comme par exemple, leurs paramètres, leurs dépendances à d’autres services et bases de données, leurs états (stateful ou stateless), ainsi que leurs contraintes en matière d’exécution.

Une erreur que l’on rencontre souvent dans les entreprises est d’autoriser les équipes opérationnelles à intégrer des API Cloud directement au portefeuille. Les API sont des ressources de développement et sont supposées alimenter la conception d’applications, y compris celles à venir. Il est donc ici capital que pour chaque API tierce, y compris les API Cloud, ce soit les développeurs – ils comprennent mieux le processus et ont davantage la capacité à définir les caractéristiques d’un API – qui en aient la charge.

Les opérationnels doivent eux être responsables des implications sur le cycle de vie de chaque application et par extension, des API qui les motorisent. Cette entité doit valider les API placées dans le catalogue par les équipes de développement et approuver les services pour la production. Si plusieurs versions d’une API sont créées, c’est à l’équipe opérationnelle de séparer les versions et de contrôler leur usage dans le temps.

Les équipes en charge de la conformité et de l’audit interne ont, quant à elles, la responsabilité du commissionnement des nouvelles API et de la gestion du cycle de vie. Elles doivent donc pouvoir collaborer avec les équipes de développement et celles des opérations lors de la création du portefeuille d’API. Ces équipes sont clé car, elles ont la possibilité de retirer un service ou une API en production quand un problème de sécurité est identifié. Cela devrait d’ailleurs être intégré aux processus de développement et ALM afin de s’assurer que quiconque utilise une API suspecte puisse en être averti.

Ces trois moteurs de la gestion des API se retrouvent dans les grandes entreprises, mais dans la plupart des cas, un seul se distinguera des deux autres. Si l’entreprise dispose de beaucoup d’applicatifs développés en interne, il s’agit de considérer des outils de gestion d’API qui favorisent les développeurs. Généralement dans les entreprises, les stratégies de gestion d’API contrôlées par les équipes opérationnelles fonctionnement bien, même si le nombre d’API tierce est élevé. Les entreprises ayant d’importantes contraintes en matière de régulation peuvent quant à elles mettre l’accent sur l’audit et la conformité.

Les outils pour bâtir un portefeuille d’API

La principale difficulté pour coordonner ces équipes réside enfin dans le choix des bons outils. La gestion des API s’est étendue au-delà des usages de type bus de services. Les fournisseurs comme Tibco (avec Mashery) ou encore Mulesoft (Anypoint) prennent bien en charge les 3 précédents rôles et fonctionnent dans des contextes SOA ou via des API RESTful, mais leur approche initiale, centrée sur le développeur, pourrait refroidir les opérationnels. Pour les entreprises qui n’ont pas prévu d’utiliser de bus de services, cela peut être trop complexe.

Les équipes opérationnelles, tout comme celles dédiées à l’audit interne, apprécient les outils de gestion d’API dans le Cloud, comme peuvent le proposer Oracle, HPE et IBM – là où l’intégration avec l’ALM fait partie du package et où l’approche bus de service est moins visible. Apigee (propriété de Google) est  quant à lui apprécié des utilisateurs centrés sur la gouvernance et convient pour une gouvernance globale – surtout si plusieurs architectures sont en action (Java, .NET, …)

Ces outils peuvent également attirer certains spécialistes du développement, peu portés sur les bus de services. Conçus à la base pour les environnements Cloud et de micro-services (comme celui de WSO2), ils conviennent bien à la gestion de portefeuille d’API multi-rôles.

D’autant que côté Cloud, le marché a également évolué. Amazon s’y est frayé un chemin avec  sa Gateway, mais l’outil est moins complet que le reste du marché mais il constitue un complément Cloud pour les outils de gestion d’API en place. L’outil convient mieux aux utilisateurs du Cloud public à cause de son modèle de facturation à l’usage.

Le fait que plusieurs rôles au sein d’une même entreprise puissent utiliser différents outils risquent de conduire à une perte regrettable des priorités et de cohérence dans la gestion. Quand cela est possible, la meilleure méthode pour développer un portefeuille d’API est d’utiliser un seul produit ou groupes d’outils, et de segmenter leurs usages par vue et rôle. Cela permet de réduire le nombre de solutions en s’assurant que celles sélectionnées conviennent aux modèles de déploiements et aux évolutions possibles des applications.

La même approche doit également être appliquée aux processus de développement d’API. Une bonne stratégie doit suivre les évolutions tout en proposant les fonctions adaptées aux trois rôles précédemment cités. Planifiez votre gestion d’API, et vous obtiendrez de bien meilleurs résultats.