API : les meilleures pistes pour une stratégie réussie

Comment fonctionne une API ?

Prenons un exemple : un producteur de denrées alimentaires met à disposition des API qui couvrent la traçabilité, les ingrédients et les unités de gestion des stocks (les SKU, Stock Keeping Units). Un supermarché les utilise pour gérer les niveaux de stock dans ses centres de distribution. Les API des prestataires logistiques permettent ensuite de s’assurer que les commandes des producteurs sont expédiées de façon régulière dans les centres de distribution, avec un script qui automatise le réapprovisionnement en fonction d’un niveau seuil de stock.

Dans le commerce B2C (à destination des particuliers, donc), une API interne peut indiquer à un site de vente en ligne si une marchandise est disponible en stock et si elle est prête à être expédiée. Une API externe peut fournir des services de paiement. Une autre peut se connecter au transporteur pour autoriser le service de messagerie à envoyer des informations de suivi directement au client.

Souvent décrites comme le liant entre les applications, les services Web, les systèmes d’exploitation ou d’autres plus petits composants d’application, les API obéissent à une syntaxe précise et sont activées par des appels de fonction composés de noms et de verbes. En pratique, les développeurs ont le choix : ils peuvent utiliser des fonctionnalités préintégrées, via leurs API, pour accélérer le développement des logiciels ou accéder à des services du système d’exploitation, ou ils peuvent soumettre ou demander des données à une application d’entreprise.

Pour les moins familiers de la programmation, pour que l’API puisse être mise à disposition, un développeur doit créer un appel de fonction conçu pour recevoir certains paramètres, par exemple des valeurs de données. Ces données assurent une certaine souplesse au développeur de l’API, car les fonctionnalités peuvent changer suivant les paramètres. Certains n’exécutent qu’une instruction à la fois, en mode « one-shot », par exemple « faire passer le feu de circulation au vert », d’autres, plus utiles, renvoient une valeur du type « quel est l’état du feu de circulation ? ». 

La bonne nouvelle est que les développeurs n’ont pas forcément besoin de maîtriser les aspects techniques du fonctionnement des API à leur disposition. En tout et pour tout, trois informations leur sont indispensables : l’existence et l’objet de l’API, les paramètres dont elle a besoin, et les valeurs qu’elle renvoie au programme qui l’appelle.

Ainsi armés, les développeurs peuvent accéder aux services de l’OS, lire et écrire des données correctement dans et depuis les datastores des entreprises, et accéder aux technologies applicatives évoluées allant de l’internet des objets (IoT) en passant par l’edge computing et l’intelligence artificielle (IA).

Juger la maturité de l’organisation au regard des API

Bien que le concept d’API ne soit pas nouveau, il incombe aux décideurs informatiques d’éclaircir un point : quelles API sont internes et accessibles aux équipes de développement, et lesquelles sont externes et accessibles aux équipes en interne, voire en cas d’impératif, aux partenaires externes ?

Le cabinet d’analyse Gartner distingue cinq domaines dans la gestion des API : la prise en main de l’API par les développeurs, l’alignement métier, les indicateurs clés de performance (Key Performance Indicators, KPI), la gestion du cycle de vie des API et les passerelles API qui contrôlent l’accès aux interfaces de programmation. Pour aider les responsables IT à cerner leurs priorités, les analystes Gartner leur recommandent d’évaluer la maturité de leur entreprise dans chacun de ces domaines, sur une échelle allant d’« inexistante » à « en progrès ».

Dans son article « What are the three steps for a successful API product? » (Réussir son API en 3 étapes), l’analyste Carolin Zhou invite les DSI à se projeter en définissant les principaux objectifs métier et en faisant le point avec les dirigeants sur les objectifs métier actuels et à long terme de l’entreprise, avant d’élaborer les cas d’usage des API.

« Pour savoir où les API seront utiles, les équipes IT doivent impliquer les différentes parties prenantes. »

« Pour savoir où les API seront utiles, les équipes IT doivent impliquer les différentes parties prenantes. Par exemple, avec des cas d’usage qui démontrent l’intérêt des API aux dirigeants, même ceux au plus haut niveau de la hiérarchie », écrit-elle. « Lorsque vous construisez votre argumentaire en faveur d’une API et pour emporter l’adhésion de la direction, ne considérez pas l’API comme un projet, mais comme un produit. Non seulement la nomination d’un responsable API et la création d’une équipe chargée de la plateforme API en seront facilitées, mais l’intérêt des API en matière d’agilité métier et de rapidité de mise sur le marché n’en sera que plus évident. »

Après avoir déterminé quelles API sont nécessaires pour l’entreprise, l’analyste recommande aux responsables informatiques d’évaluer les écarts entre les objectifs métier de l’entreprise et les principaux cas d’usage des API. « Prenez, par exemple, les fonctions de surveillance automatique du niveau de service, les obligations en matière de conformité, etc. Ces écarts vous permettront d’envisager la création de vos API en mode produit et vous serviront de feuille de route dans une perspective d’amélioration continue », affirme-t-elle.

Pour combler ce fossé, Gartner recommande d’aligner les cas d’usage des API sur les objectifs métier. Les responsables informatiques devraient chercher en quoi leurs API peuvent servir des objectifs métier et commerciaux, puis traduire ces objectifs en métriques permettant de mesurer des valeurs telles que la qualité de la conception des API, le nombre d’appels API, etc.

 Mettre en place des équipes fusionnées (ou réunir les métiers autour de la table)

Les conclusions du cabinet d’analyse, sur l’alignement entre la stratégie API et les objectifs métier, rejoignent celles d’une récente étude menée par Mulesoft, qui reprend à son compte le terme d’« équipes fusionnées » pour décrire la collaboration entre utilisateurs professionnels et informaticiens, aux compétences distinctes.

D’après Mulesoft, ces équipes fusionnées doivent répondre aux difficultés de fonctionnement déclenchées par le climat économique délétère, dans un souci d’efficacité. Pluridisciplinaires, elles intègrent des profils variés – technologie, analyse, experts d’un domaine… – et partagent les responsabilités techniques et des résultats.

« Avec les vents contraires qui secouent l’économie, la technologie joue un rôle majeur pour la réussite de l’entreprise à tous les niveaux : vente, service, marketing, commerce, informatique… », affirme Matt McLarty.

D’après l’étude Mulesoft menée à l’international auprès de 1 000 décideurs informatiques, 69 % des entreprises ont créé ou sont en train de déployer des équipes fusionnées, et 22 % ont prévu de faire de même dans l’année. Dans les entreprises où ces équipes sont déjà en place, presque deux tiers (63 %) des décideurs informatiques affirment qu’elles ont eu un impact positif sur les objectifs.

Dans la même étude, la majorité des responsables IT affirment que les projets d’intégration des données ou des systèmes prennent trop de temps (66 %) et sont trop coûteux (69 %). Mais plus des deux tiers (68 %) reconnaissent que l’absence d’intégration de données ou de systèmes crée une expérience client décousue. Presque tous les dirigeants IT (98 %) qui ont participé à l’étude Mulesoft indiquent que les nouveaux investissements sont influencés par la capacité d’intégration des outils aux technologies en place.

Le rôle de responsable API est progressivement en train d’être formalisé, reconnu et popularisé, même si toutes les entreprises ne disposent pas d’une équipe API dédiée. Pour Alessandro Chimera, directeur des stratégies de digitalisation chez TIBCO Software, le développement des API s’est démocratisé et diversifié au point d’être une discipline et une compétence répandues.

API : pourquoi élaborer une stratégie à l’échelle de l’entreprise

« À bien des égards, le défi des API est surtout humain. Les API sont faciles à implémenter et, lorsqu’elles ont été conçues soigneusement, elles exécutent leurs fonctions rapidement », explique-t-il.

Elles exigent toutefois un effort d’adaptation : d’après sa théorie, bien utiliser les API impose de revoir la notion de partenariat, de réimaginer la collaboration, la connexion et la coordination.

Utiliser des API pour accéder à des données, par exemple, réduit l’effort de maintenance en continu des développeurs. Ces derniers peuvent, entre autres, se libérer de tâches liées à l’installation et la mise à niveau des pilotes, ou ne sont plus obligés de compter avec des pilotes non pris en charge pour faire tourner les applications.

L’accès aux données peut également être simplifié, selon Jeff Carpenter, formateur en ingénierie chez DataStax, qui explique que les services de données allègent la charge des programmeurs devant assurer la maintenance de leur propre accès aux données ou couches d’abstraction. « En utilisant des API à la place de connexions directes du type mapping objet-relationnel (object-relational mapping, ORM), vous vous simplifiez nettement la tâche et vous obtenez le fonctionnement souhaité par votre équipe. »

Autre avantage selon lui, l’équipe de programmation peut utiliser le style d’API qu’elle maîtrise le mieux ; REST, gRPC ou orientée documents. La courbe d’apprentissage de la gestion des données est réduite, et l’équipe peut se concentrer sur le développement de la logique métier de vos applications.

Du point de vue de la stratégie API, l’idée développée par Mulesoft d’une équipe fusionnée est un ingrédient essentiel de la recette du succès, surtout si les données exposées par l’API exigent une expertise spécifique qui risquerait d’en freiner l’utilisation.

Dans un entretien récent avec Computer Weekly [Propriété de TechTarget, également propriétaire du MagIT], James Fleming, DSI chez Francis Crick Institute, expose les difficultés que pose le partage de données de la recherche médicale entre différentes organisations au niveau international. À un bout du spectre, l’accès au réseau virtuel privé (Virtual Private Network, VPN) est sans doute le moyen le plus simple de permettre aux chercheurs d’accéder à un magasin de fichiers distant. À l’autre bout, l’accès par API offre un contrôle programmatique de très grande précision.

Mais, pour James Fleming, tant que les API fonctionnent et que les données en accès sont bien comprises, la grande majorité des données de recherche n’entrent pas dans cette catégorie. En dehors des données de la recherche scientifique, il existe sans doute bien d’autres exemples de data stores internes, ésotériques pour quiconque ne fait pas partie de l’entreprise. Dans ces cas, l’accès par API est-il intéressant ? Et s’il est nécessaire, quel niveau d’expertise faudra-t-il au programmeur pour l’utiliser correctement ?

« Les entreprises soucieuses de proposer des API efficaces doivent réfléchir à la rétrocompatibilité. C’est ainsi que les développeurs, [...] pourront se consacrer aux fonctions frontales. »

Bernadette Nixon, PDG d’Algolia, ne met pas en cause l’intérêt de disposer d’experts du domaine pour développer au mieux des API, mais soutient l’idée d’une stratégie axée API impliquant de réfléchir aux API dès le début du processus de développement de produits et services. Pour elle, une stratégie axée API est gage de flexibilité, de vitesse et de rétrocompatibilité pour les entreprises.

Sur le plan de la flexibilité, les API devraient être conçues pour un large éventail de cas d’usage, à l’inverse de ce que proposent les éditeurs ou les fournisseurs. En matière de vitesse, elles doivent être en mesure de soutenir l’intensité du débit et des « appels » des applications, sans l’intervention des développeurs.

Et Bernadette Nixon de préciser : « les entreprises soucieuses de proposer des API efficaces doivent réfléchir à la rétrocompatibilité. C’est ainsi que les développeurs, libérés de tâches de maintenance fastidieuses, pourront se consacrer aux fonctions frontales. »