Comment les API peuvent-elles faire briller leurs développeurs 

Provoquer le « déclic » de la réutilisation chez les développeurs

Satish Maram, directeur de l’API et de l’intégration chez Astrazeneca, déclare : « fondamentalement, après l’avoir conçue, une API s’utilise plusieurs fois ». Selon Satish Maram, un bon cas d’usage pour une API réutilisable se présente lorsqu’il est nécessaire d’intégrer deux systèmes et que cette intégration est susceptible d’être utilisée à plus d’un endroit au sein d’une architecture.

Cette réutilisation devient un élément clé de la stratégie IT du ministère du travail et des pensions britannique (DWP). « Construire des services réutilisables est notre objectif stratégique », affirme Jacqui Leggeter, responsable de l’intégration au DWP.

Lors d’une table ronde organisée dans le cadre de la conférence Mulesoft Connect 2019 à Londres, Jacqui Leggeter, Satish Maram et Ben Turner, CTO de l’assurance Legal & General, ont été invités à donner leur avis sur les avantages des API ainsi que sur les meilleures pratiques en matière de réutilisation.

« Je ne parle pas des API. Nous parlons des services que l'entreprise veut consommer et nous essayons de trouver des scénarios quotidiens pour expliquer leurs rôles. »

Les membres du panel ont convenu que le concept d’API est quelque chose que les entreprises auront souvent du mal à comprendre. La discussion devrait plutôt porter sur les services aux entreprises qui sont mis à disposition par le biais d’API, comme l’a expliqué Ben Turner. « Je ne parle pas des API », précise-t-il. « Nous parlons des services que l’entreprise veut consommer, et nous essayons de trouver des scénarios quotidiens pour expliquer leurs rôles ».

Au cours de la première année d’utilisation des API, Jacqui Leggeter les équipes IT du DWP ont changé la manière de les nommer. Les anciennes API avaient pour appellation des numéros. « Au cours de la première année, nous avons cessé de numéroter les API », relate-t-elle. « Chaque nom d’API devrait commencer par un verbe ». Selon la responsable, cela a entraîné l’état d’esprit autour de ces interfaces.

Des changements économiques

Le lancement d’un programme visant à développer de nouvelles API utilisables dans toute l’entreprise nécessite un changement d’attitude par rapport à l’alignement entre l’IT et les activités économiques. Alors que les équipes de développement d’applications peuvent être habituées à écrire des logiciels pour une fonction commerciale spécifique, une approche « API-First » exige une réflexion sur la manière dont le code peut être réutilisé.

Avant 2016, Legal & General dirigeait des projets logiciels qui reposaient sur des connexions point à point, avance Ben Turner. « L’idée était de le construire une fois et c’est tout. Nous devions changer et perturber les mentalités, tant celles des métiers que celles des développeurs ».

De même, Jacqui Leggeter assure que l’équipe a vécu un déclic lorsqu’elle a commencé à travailler sur un projet pour le gouvernement écossais, qui présentait de nombreuses similitudes avec un microservice qu’elle avait précédemment développé pour le HM Revenue & Customs (HMRC). « Le service que nous avons construit pour le HMRC n’était pas réutilisable parce que nous avons exposé cinq choses dans une seule API », déplore-t-elle.

L’équipe a réalisé que les microservices développés devaient avoir des fonctions plus précises. Pour son prochain projet – un service gratuit de vérification des droits de prescriptions au National Health System (le système de santé britannique) qui présente des similitudes avec le microservice du HMRC –, l’équipe a donc cherché à « diviser le microservice en API distinctes », explique Jacqui Leggeter.

Les autres membres du panel ont partagé leur expérience quant aux gains de productivité de leurs équipes, après avoir adopté une méthode de développement centrée sur les API. Chez Astrazeneca, Satish Maram affirme que le premier projet « API-First » a réclamé moins de travail que l’intégration traditionnelle point à point.
Cependant, la réelle valeur des API s’est fait ressentir au cours du deuxième projet. « Nous avons assemblé des blocs modulaires Lego [de logiciels], donc nous n’avons eu besoin de construire que l’équivalent de la moitié de ce que nous avions construit lors du deuxième projet », témoigne-t-il.

L’entreprise de produits agricoles et environnementaux Yara International, fait partie de ces organisations qui se lancent dans l’aventure des API. Yara a commencé à utiliser le logiciel de gestion de l’API AnyPoint de MuleSoft dans le cadre d’une initiative élargie visant à rapprocher l’IT des activités économiques et à développer des logiciels plus rapidement.

Lancer une stratégie « API-First » à l’échelle de l’entreprise

Patrick De Sarrazin, responsable de l’API et de l’intégration chez Yara, a expliqué les raisons de l’utilisation de la gestion des API. « Nous n’avons pas le luxe de pouvoir discuter d’un projet puis de travailler dessus pendant un an. Si vous pensez à quelque chose, alors quelqu’un d’autre a probablement déjà commencé à y travailler », avance-t-il.

Il y a trois ans, le département IT de Yara s’est transformé pour se rapprocher des métiers. Pour cela, il a lancé une initiative appelée « Yara API economy ». « Nous voulions adopter une philosophie "Shift Left" concernant l’intégration. Nous voulions donner à nos programmeurs les moyens d’en faire plus et de le faire de manière organisée », explicite Patrick De Sarrazin.

Selon le responsable, l’approche adoptée par Yara permet aux développeurs de travailler à l’aide « d’un modèle bimodal ». La méthodologie Shift Left signifie que l’entreprise laisse les équipes résoudre les problèmes à leur manière et partager leurs travaux, pour que tout le monde puisse en bénéficier.

Ross Mason, fondateur de Mulesoft, estime que les programmeurs ont du mal à comprendre les avantages des API réutilisables. D’après son expérience, ils ont du mal à faire le lien entre les logiciels qu’ils créent et les résultats que l’entreprise recherche.

« Nous devons commencer à aider [les développeurs] à réfléchir à la valeur qu'ils apportent aux applications qu'ils construisent ».

« Les développeurs ne pensent pas vraiment à la valeur », affirme-t-il. « C’est comme si on livrait un projet informatique qui n’a aucune utilité en dehors du domaine pour lequel il a été conçu, par opposition à un projet qui apporte une valeur ajoutée à un ou plusieurs éléments de l’organisation. Nous devons commencer à les aider à réfléchir à la valeur qu’ils apportent aux applications qu’ils construisent ».

À bien des égards, Ross Mason et les autres responsables à qui Computer Weekly (propriété de Techtarget, également propriétaire du MagIT) a parlé pensent que l’IT doit cesser de se contenter de fournir ce que veut l’entreprise.

Les développeurs de logiciels doivent plutôt fournir des services disponibles via des API publiées réutilisables encore et encore, aidant ainsi leur organisation à mettre plus rapidement sur le marché de nouveaux produits numériques.