Transformation numérique oblige, l’utilisation d’APIs est devenue une problématique majeure pour les DSI. En effet, les APIs sont aujourd’hui si performantes qu’elles tendent à s’articuler dans une stratégie d’intégration plus globale au sein des systèmes d’informations.

Le choix d’un écosystème d’APIs n’est donc pas anodin et il convient de prendre en compte quelques étapes avant de faire son choix.

Étape 1 : prendre le temps de comprendre les besoins de son équipe IT

Les besoins d’une équipe IT ne se résument pas à une API “100 % UX-friendly« . Il faut creuser davantage pour connaître leurs besoins réels. En effet, une API performante, c’est bien plus qu’une simple fonctionnalité. La puissance des API réside en partie dans le fait que les développeurs créatifs leur trouvent des usages auxquels les concepteurs d’API n’ont jamais pensé. Si une API est bien conçue et facile à utiliser, elle peut constituer un avantage et une opportunité énormes, en transformant un service en une plate-forme capable de se développer de multiples façons.

Bien comprendre la notion de fournisseur et consommateur d’API :

  • Fournisseur d’API : ce sont ceux qui ont développé l’API.
  • Consommateur d’API : ce sont ceux qui utilisent une API développée.

Choisir une API qui respecte les “normes” des développeurs

Quel que soit le protocole ou l’architecture qu’une API utilise, elles ont toutes des normes ou des styles plus ou moins strictes qui peuvent influer sur l’expérience de développement de l’équipe IT.

Exemple : les API basées sur le framework gRPC utilisent des tampons de protocole pour définir des structures de données, ce qui n’est pas toujours intuitif lorsque l’on code avec le langage GraphQL, qui est davantage un langage de requête.

Pour vous assurer que votre équipe pourra tirer le meilleur d’une API, il faut donc comparer les langages et frameworks avec lesquels l’équipe est familière aux spécifications techniques de l’API recherchée. Existe-t-il une communauté active autour de l’API ?

Beaucoup d’API – souvent open source – ne disposent pas de service support. C’est donc la communauté de développeurs qui consomment l’API qui fait office de service client. Au-delà du rôle de support, une communauté active peut contribuer à décupler la productivité des équipes de développeurs grâce au partage de frameworks de tâches courantes ou encore de bonnes pratiques et idées.

Plateforme de support - Exemple

La plateforme support de l’API Shopify est un bon exemple de plateforme communautaire proactive, en témoignent les nombreux canaux d’échanges : forum, profil Twitter, chaîne Youtube, chaîne Twitch, etc.

Étape 2 : s’assurer que le fonctionnement de l’API s’aligne avec l’organisation de l’entreprise et les objectifs

Au-delà des besoins et des attentes de l’équipe IT, l’API doit aussi correspondre à l’organisation structurelle de l’entreprise. Dans ce sens, de nombreuses questions doivent être posées avant de choisir une API ou de la développer.

Choisir un système de facturation qui convient à l’utilisation que vous avez de l’API

On retrouve deux types d’API pour ce qui est de la facturation :

  • Celles qui facturent à l’appel
  • Celles qui facturent un forfait contenant un certain nombre d’appels

Dans les deux cas, il est essentiel d’analyser le nombre d’appels dont vous aurez besoin sur une API pour connaître son coût. Ainsi, une API qui coûte plus cher par appel, mais vous permet d’accomplir plus avec un seul appel peut être plus rentable qu’une API moins chère, mais avec laquelle vous avez besoin de plusieurs appels pour obtenir le même résultat. Pensez aussi à vérifier les modalités de l’API en cas de dépassement du nombre d’appels. En effet, certains frais supplémentaires sont parfois très dissuasifs.

Gérer les processus d’authentification

Certaines API disposent d’un procédé standard d’authentification mais ce n’est pas le cas de toutes. Lors du choix d’une API sans système d’authentification, il faudra parfois avoir recours à un service tiers d’authentification pour assurer la cybersécurité de l’infrastructure.

Étape 3 : choisir une API gérée ou non-gérée ?

Une API moderne qui se respecte doit-elle forcément disposer d’une solution de gestion ? En effet, c’est la garantie d’une interface bien définie et d’un contrôle sur le comportement d’exécution des consommateurs de l’API. Mais alors, pourquoi vouloir une API non-gérée ?

Voici quelques exemples où le choix d’une API non-gérée est approprié :

  • Pour un capteur ou un équipement (thermostat domestique, capteur Fitbit de surveillance de l’activité physique…) ;
  • Un logiciel existant : un système SAP standard ou un système plus complexe possédant une interface REST native.

Les principales différences entre une API gérée ou non-gérée :

  • Une API non-gérée peut avoir un public cible, mais celui-ci n’est que rarement défini avec précision. Si un utilisateur a accès à l’API via le réseau, il peut en général l’utiliser.

Une API non-gérée ne met pas en œuvre de contrôles métiers et informatiques indépendamment. Un contrôle est fourni par la logique lors de la mise en œuvre de l’API, généralement sous forme de code.

Notre conseil pour le choix d’API gérée ou non-gérée : ne pas se ruer d’instinct sur les API gérées, car les API non-gérées peuvent être des ressources importantes dans beaucoup d’écosystèmes, en fournissant des données et des fonctionnalités clés de manière uniforme.

Étape 4 : ne pas négliger la phase de test de l’API

Les tests d’API sont essentiels pour identifier les défauts à plusieurs niveaux d’une application et pour garantir une expérience client sans faille.

Nos conseils :

  • Utiliser un outil de test fiable et réputé ;
  • Faire les tests en conditions de production réelles ;
  • Systématiquement enregistrer et tracker les réponses d’API pendant les tests pour la postérité ;
  • Faire des tests “négatifs” : tout comme l’on fait des tests de réponses positives, il faut penser à tester la façon dont l’API va gérer la réception de données incorrectes ou invalides. Une API mal conçue à ce stade peut générer des “crashs”.
  • Faire des tests de sécurité : nous vous recommandons de faire appel à des spécialistes en cybersécurité pour vérifier toutes les failles potentielles.

La réflexion sur les API ne se limite pas au choix d’un écosystème d’API qui correspond aux besoins d’une structure et d’une équipe IT ou DevOps. Elle tend de plus en plus à s’articuler dans une stratégie d’intégration plus globale pour transformer votre entreprise en moteur d’innovation. C’est là tout l’enjeu de l’API Management.

Vous souhaitez APIser votre organisation ? Blue Soft vous accompagne ! 👇

Contactez-nous

Partagez cet article !