API : quand les entreprises en font des interfaces économiques

Avec les API, les éditeurs sourient

À ce titre, deux éditeurs se sont largement imposés sur le marché des API : Apigee Edge et Mulesoft. Le premier appartient à Google, le second à Salesforce. Selon le cabinet d’étude Gartner, ils dominent ce secteur en proposant des environnements de développement et de déploiement pratiquement clé en main. Mulesoft se distingue par la simplicité d’utilisation et son portail d’API, tandis que Google joue sur les fonctionnalités avancées et la possibilité de monétiser les éléments qui traversent les API.

La croissance de Mulesoft dans ce domaine change petit à petit le visage de Salesforce. L’éditeur spécialiste du CRM a non seulement trouvé un moyen de relier ses PaaS, mais il s'est aussi installé dans un secteur qui représente près de la moitié de ses revenus.

Sur ce marché, IBM n’est pas très loin, en quatrième position selon le Magic Quadrant de Gartner. L’éditeur entend mettre au service de ses clients un ensemble d’outils qui doivent aller au-delà des API.

« Aujourd’hui, nous parlons beaucoup d’API. Il y a cinq ans, nous évoquions beaucoup l’aspect technique afin d’évangéliser le concept et son fonctionnement. Notre stratégie actuelle ne concerne pas seulement ces ressources, mais l’intégration en général. Les API correspondent à une brique disponible. Nous voulons couvrir plusieurs technologies. Il y aussi besoin de connecteurs vers Salesforce, Confluence, etc. des connecteurs applicatifs avec des flux synchrones et de flux asynchrones », explique Michel Lara, Technical Advocate chez IBM.

Le cas IBM

Big Blue a donc rassemblé au sein d’une seule solution packagée un ensemble d’outils d’intégration. Celle-ci se nomme IBM Cloud Pak for Integration et est proposée en mode SaaS sur Microsoft Azure, GCP, AWS et sur site.

« Pratiquement tous les clients que je rencontre ont du SaaS, commencent à avoir du cloud public et ont un gros patrimoine applicatif. Ils veulent rassembler les capacités d’intégration et ne veulent pas avoir d’adhérence avec une plateforme. Même s’ils ont fait un choix particulier, ils espèrent pouvoir déplacer ces outils sur des clouds publics ou privés, affirme Michel Lara. « Notre stratégie se démarque de la concurrence parce que nous proposons un seul produit installable où le client le souhaite. La décision que nous avons prise après le rachat de Red Hat, c’est de déployer cela sur du Kubernetes en particulier sur OpenShift. Auparavant, la solution était embarquée sur l’équivalent IBM Cloud Private ».

IBM n’a pas attendu l'acquisition de Red Hat pour développer ses capacités d’intégration. En 2015, l’éditeur a racheté StrongLoop, un spécialiste de la création d’API en Node.JS qui propose le framework open source LoopBack. Big Blue exploite également OpenAPI, Kafka pour le messaging, ou encore son vieux middleware MQ. Big Blue serait capable de déployer ses services d'intégration en une semaine suivant les cas, le portail associé en quelques heures. Selon Gartner, IBM a fait le choix de réarchitecturer sa solution API Connect en 2018 pour les déploiements multicloud en adoptant une gateway OpenAPI.

« Tout le monde utilise des standards parce que l’on veut échanger entre les instances de différentes entreprises ».

« Tout le monde est d’accord sur les briques technologiques à déployer : du Kubernetes, de l’OpenAPI, du Swagger, de l’Elasticsearch, du Kibana, du Docker. Tout le monde utilise des standards parce que l’on veut échanger entre les instances de différentes entreprises », affirme Michel Lara.

Surtout, IBM vante l’aspect économique de sa solution qui lui permet selon le Technical Advocate de servir les TPE. « Aujourd’hui, nous pouvons prendre en charge les projets de TPE. Elles me disent "je n’osais pas vous appeler". Je leur réponds de regarder combien cela coûte annuellement et je leur fais des offres à moins de 10 000 euros en SaaS. Les 50 000 premières requêtes sont gratuites » assure-t-il.

Des entreprises en transformation…

C’est pour ces mêmes capacités de flexibilité que Decathlon USA a choisi Mulesoft. La filiale du groupe français voulait déployer une architecture rapidement afin de connecter les systèmes de gestion d’approvisionnement, des taxes et de les synchroniser avec des services de paiement locaux. Les 11 API réutilisables font également le lien vers des robots en magasin et vers le CRM du groupe. Decathlon consomme donc des API pour accélérer les déploiements et tenter de lancer de nouveaux produits.

Cependant, comme le signale Gartner, les entreprises ne cherchent pas seulement à faciliter les déploiements, elles veulent se transformer à l’aide des technologies qu’elles utilisent. Cette transformation passe par une forme d’ouverture technique et économique.

De grands groupes comme HSBC entendent augmenter le nombre de transactions et leur croissance, en proposant à leurs associés des API publiques. La société bancaire en aurait déployé plus de 3000 dont certaines sont gratuites et d’autres non. Par exemple, elle fournit à ses partenaires via son portail développeur une API pour localiser les distributeurs de billets, pour confirmer un paiement, pour obtenir des informations en temps réel sur les clients HSBC, etc. Il aurait généré plus de 35 millions de transactions grâce à ces dernières.

De son côté, Air France KLM pousse une double stratégie autour des API. Il y a cinq ans, le groupe a commencé à mettre en œuvre des API dans le but de numériser tous les processus et d’aligner toutes les applications internes. « Nous avons plusieurs sites Web, des réseaux sociaux, etc. Nous voulions afficher les mêmes informations aux clients », affirme Stijn Bannier, Product Manager OpenAPI pour la compagnie aérienne. « En 2018, nous avons considéré que nous avions atteint une forme de maturité et qu’il était temps de les partager avec nos partenaires », ajoute-t-il.

Stijn Bannier s’occupe des API dédiées au parcours client, plus particulièrement celles destinées à la vente de billets. « Du côté commercial, nous avons environ 25 API. Air France KLM met en oeuvre OpenAPI pour s’ouvrir aux partenariats économiques. Si une entreprise a un cas d’usage intéressant à l’esprit où un partenaire veut utiliser une ou deux de nos API, nous pouvons discuter et négocier pour les rendre disponibles », déclare le responsable.

La compagnie aérienne propose également des API pour informer sur les statuts des vols, pour vérifier l’accès au lounge, pour s’assurer que le client a bien sa carte d’embarquement, et bien d’autres. Tout comme HSBC, il ne s’agit pas laisser les clés à tout le monde, mais de s’ouvrir à des opportunités commerciales.

« Par exemple, Google utilise nos API pour le service Google Flights afin de réserver des billets directement auprès d’Air France. Skyscanner en profite également. Nous ne facturons pas les API, mais nous voyons en elle un moyen d’étendre notre portée commerciale par l’ouverture. En 2019 avec Accor, nous avons connecté leur programme de fidélité avec Flying Blue. Quand un client dort dans un hôtel Accor, il gagne des miles, mais il va également engranger des points Accor grâce à son vol et vice-versa. Cela permet de renforcer la fidélité et en fin de compte d’augmenter les ventes », précise Stijn Bannier.

Selon le product manager, la compagnie aérienne peut ainsi proposer des billets dans davantage de pays, là où les voyageurs ne sont pas habitués à se rendre sur son site Web, comme en France ou aux Pays-Bas. Air France KLM se connecte également aux API des aéroports de Paris et de Schiphol, à Amsterdam. Cela permet d’indiquer aux clients le temps d’attente pour les vérifications de sécurité et à la douane, ainsi que les durées de trajet dans l’aéroport, pour en sortir, etc.

Par ailleurs, Air France KLM fournit un portail pour les développeurs qui ne contient pas seulement la documentation technique, mais aussi des recommandations commerciales. « De mon point de vue, tout ce qui concerne les API a longtemps été un sujet réservé à l’IT, maintenant nous souhaitons en faire un sujet économique », déclare Stijn Bannier.

… Quitte à concevoir leurs propres technologies

MAIF, « L’assureur militant » défend une utilisation similaire des API.

La MAIF a trois usages des API. Un premier, interne, consiste à bénéficier de la vision complète des informations d’un sociétaire. Les API font le lien entre les puits de données et une application métier, via un portail nommé Nora. Le deuxième cas concerne les parcours digitaux disponibles depuis le Web et le mobile. Ils sont construits à l’aide de ces briques. « Les API nous permettent d’adapter rapidement l’expérience client », affirme Guillaume Rincé, CTO de la MAIF. Enfin, le troisième cas d’usage consiste à exposer les produits à ses partenaires en leur favorisant les interactions avec son SI.

« Nous avons évidemment beaucoup de composants historiques, car la durée de vie d’une instance est souvent liée à celle d’une assurance. Cette stratégie d’API nous permet de construire en agilité tout en rendant possible des usages digitaux, de pouvoir les exécuter dans nos clouds privés et publics », déclare le responsable technique.

Mais la société va plus loin que les entreprises précédemment citées. Elle a développé sa propre solution open source d’API management, dans le cadre de son programme OSS by MAIF.

« En 2018, nous avons ouvert deux technologies que nous utilisions au sein de nos portails d’assurance. Ces outils nous les avons créés à partir de 2016 parce qu’ils n’existaient ni en open source ni chez les éditeurs », affirme Guillaume Rincé.

La première Otoroshi, est une solution de reverse proxy et d’API management. Elle permet d’exposer des API au sein du système d’information ou à des partenaires « tout en maitrisant l’accès aux données ».

La deuxième, Izanami, doit faciliter les tests des applications dans des environnements microservices. « C’est une brique d’activation à chaud. Le principe c’est que vous déployez des fonctionnalités dans vos applications, dans vos parcours digitaux. Cela permet de laisser aux métiers le choix de les tester sans qu’il y ait d’opérations de mise en production », précise le CTO.

La MAIF a poursuivi sa démarche dans le cadre de la mise en place du règlement européen sur la protection des données personnelles en publiant dans un objectif de transparence son orchestrateur RGPD nommé Nio en mode API.

Au début du mois de décembre 2019, la MAIF a présenté une autre brique open source : Daikoku. Il s’agit d’un portail de valorisation des API qui vient parfaire Otoroshi. « À travers Daikoku, il est possible de valoriser, voire de monétiser des API. Le couple Daikoku / Otoroshi permet d’avoir une solution complète d’API Management », atteste Guillaume Rincé. Celle-ci ne concerne pas seulement le secteur de l’assurance. La MAIF la propose dans une démarche agnostique. « Vous avez la capacité d’organiser du service de vente autour des API et les fonctionnalités de mesure des métriques permettent de monétiser les API et les données », ajoute-t-il.

« Nous sommes dans une activité où nous avons de véritables enjeux d’ouverture de notre système d’information. Les API sont au cœur de cette transformation. »

En contribuant deux à trois fois par an à des projets open source, La MAIF devient en quelque sorte un concurrent des acteurs cités plus haut. « Nous sommes dans une activité où nous avons de véritables enjeux d’ouverture de notre système d’information. Les API sont au cœur de cette transformation. Aujourd’hui, nous faisons le choix d’investir dans les technologies qui nous rendent réellement singuliers », assure Guillaume Rincé.

Toutefois, la sélection des technologies semble secondaire à la stratégie à mettre en place qui selon Mehdi Medjaoui demande la participation des équipes IT, des métiers, et donc un profond changement culturel.