Bonnes pratiques en matière de stratégie API

Les interfaces de programmation d’application (API) sont d’une valeur inestimable pour les entreprises modernes. Ces dernières les utilisent pour connecter et intégrer les applications, les systèmes et les bases de données, orchestrer les workflows, accélérer le développement et la distribution de nouveaux services et applications, créer des interfaces modernisées pour les systèmes hérités, et bien plus encore. Une entreprise possède en moyenne plus de 613 points de terminaison d’API en production.

Cependant, si des API sont créées, déployées ou intégrées de manière ponctuelle, les entreprises risquent de laisser de la valeur sur la table ou, pire, de s’exposer à des risques liés à la cybersécurité. Une stratégie API complète permet de s’assurer qu’une entreprise tire pleinement parti de ses API et que ces dernières sont au service d’initiatives commerciales partagées.

Une stratégie API est un plan de haut niveau qui décrit comment une entreprise utilisera les API pour atteindre ses objectifs commerciaux. Il établit des directives et des politiques pour la conception, le développement et le déploiement des API, la gestion des API, la sécurité, etc. La stratégie d’API permet de garantir que les API d’une entreprise n’existent pas isolément mais fonctionnent ensemble pour répondre à des besoins et à des objectifs commerciaux plus importants.

La stratégie d’API prend en compte les besoins techniques, de sécurité et de conformité de l’entreprise, tout en favorisant un système durable, prévisible et centralisé pour la mise en œuvre des nouvelles API.

En bref, la stratégie d’API aide les entreprises à concevoir et à gérer des API plus efficaces, plus utiles et plus sûres. Les fonctionnalités des API sont tellement étendues, variées et évoluent si rapidement que les parties prenantes doivent pouvoir s’appuyer sur une stratégie d’API concrète pour préserver la cohésion, l’efficience et l’efficacité des projets d’API.

Parce qu’il existe de nombreux types d’API, et encore plus de façons de s’en servir, et qu’elles jouent un rôle essentiel dans l’entreprise moderne, une stratégie d’API claire et complète est indispensable maintenir l’ordre dans l’écosystème numérique, éviter le gaspillage de ressources et les problèmes de sécurité, et maximiser la création de valeur.

Une stratégie d’API robuste peut offrir une meilleure expérience aux développeurs, améliorer la compatibilité et l’évolutivité, aider les entreprises à monétiser leurs API et plus encore. La stratégie des API est également un élément important de la réalisation d’objectifs holistiques tels que la transformation numérique.

La transformation numérique est une stratégie qui vise à intégrer la technologie au sein de l’entreprise. Il s’agit d’une refonte complète des processus, des produits, des opérations et de la pile technologique afin de permettre une innovation continue, rapide et axée sur le client. Il ne s’agit pas seulement de remplacer certains processus, ni de mettre à jour certains services ; c’est une transformation opérationnelle complète, qui place la technologie au cœur de l’entreprise.

Les API — et une stratégie API bien conçue — jouent un rôle prépondérant dans cette transformation. La technologie étant au centre, ce sont les API qui sont le plus souvent utilisées pour connecter les technologies au sein d’une entreprise et pour connecter les utilisateurs aux applications, systèmes et services de l’entreprise.

Les API permettent aux organisations de fournir plus de services à davantage d’utilisateurs (ouvrant de nouvelles sources de revenus), de rendre ces services plus rapides et d’améliorer l’expérience globale des utilisateurs, de faciliter l’échange de données entre les systèmes internes, les bases de données et les applications, de connecter les ressources hébergées sur différents fournisseurs de cloud, de moderniser l’infrastructure informatique héritée et bien plus encore. 

Une stratégie d’entreprise solide en matière d’API comprend une documentation API (lire plus sur la manière dont les entreprises peuvent découvrir les API ici) qui explique clairement comment les API d’une entreprise sont construites et utilisées. Un portail développeur peut être un outil précieux pour rendre les API front-end et back-end disponibles, organisées et facilement accessibles aux développeurs. Sans une bonne stratégie API, les développeurs pourraient avoir du mal à trouver les outils dont ils ont besoin, ce qui peut ralentir la production et la mise en œuvre et entraîner une redondance des API et un gaspillage de ressources.

Les API doivent être contrôlées et mises à jour pour suivre le rythme des nouveaux logiciels et de leurs mises à jour. Une stratégie d’API bien développée comprend généralement des plans pour l’ensemble du cycle de vie de l’API : idéation, conception de l’API, tests, mise en œuvre, maintenance et, le cas échéant, interruption. Ce processus assure la cohérence de la compatibilité de l’API avec les dernières versions du logiciel et réduit le risque de pannes liées à la compatibilité ou de comportements imprévisibles.

L’évolution fulgurante de la technologie signifie que presque toutes les entreprises dépendent d’un service, d’un logiciel ou d’une base de données hérités. La mise à jour de ces ressources est souvent coûteuse et chronophage.

À mesure que les efforts de modernisation progressent, les organisations peuvent utiliser des API pour moderniser l’interface avec ces systèmes et bases de données. Cela permet aux entreprises d’intégrer les ressources héritées – et de tirer parti des données précieuses qu’elles contiennent – sans avoir à attendre la mise à jour de l’ensemble du système.

Par exemple, un vaste ensemble d’enregistrements de comptes clients peut être stocké dans une base de données qui n’est plus utilisée par le reste de l’entreprise. Plutôt que de migrer minutieusement toutes ces données vers un nouveau système (ou pendant que cette migration est en cours), une API peut être utilisée pour permettre à d’autres parties du système de communiquer avec la base de données et de demander des informations.

Une stratégie d’API garantit que les API sont conçues, déployées et documentées de manière à orienter l’entreprise vers les objectifs fixés et à s’inscrire dans une stratégie commerciale plus large. La stratégie API permet de créer une feuille de route pour le développement et la distribution des API, ainsi qu’un plan qui génère des modèles commerciaux plus cohérents et rationalisés et une plus grande valeur ajoutée pour les API.

Les API sont souvent utilisées comme vecteur d’attaque et présentent un risque de sécurité qui doit être pris en compte. Une stratégie d’API qui détaille les normes de sécurité d’entreprise et la façon dont une entreprise empêchera l’utilisation abusive de ses API peut réduire ce risque. Des outils tels que les passerelles API et des techniques telles que l’authentification ou la limitation du débit sont souvent utilisés à cette fin.

La limitation de débit est utilisée pour réduire le risque d’attaques par force brute ou déni de service distribué (attaques DDoS). La limitation du débit bloque ou rejette les demandes qui présentent un risque en termes de volume et empêche les systèmes d’être inondés de demandes. Certaines fonctions automatisées peuvent également être encore plus précises. Par exemple, les entreprises peuvent fixer des limites de débit pour certaines adresses IP dont l’activité de requêtes est élevée et qui ont été signalées comme suspectes. 

Les techniques d’authentification sont également intégrées à la stratégie de sécurité API afin de garantir que seules les requêtes sûres et approuvées sont satisfaites. OAuth, ou autorisation ouverte, est un protocole qui utilise un token qui permet aux utilisateurs d’accéder à des données ou à des services précédemment approuvés sans avoir à se connecter. Les clés API, qui sont une chaîne unique de caractères connue uniquement du client et du serveur, sont un autre outil populaire utilisé par les entreprises pour assurer la sécurité des API.

Les entreprises peuvent utiliser des plates-formes de test automatisées qui vérifient en permanence la sécurité du système pour compléter et améliorer les vérifications et les tests manuels.

Dans une architecture de microservices, les applications sont composées de nombreux petits composants ou services faiblement couplés et déployables de manière indépendante. Ces composants communiquent souvent via des API.

Les microservices permettent une plus grande flexibilité et une plus grande polyvalence, mais peuvent également ajouter des complications, notamment des problèmes de compatibilité, des problèmes de latence liés à une plus grande quantité de connexions réseau et une augmentation de la journalisation des données. En effet, une architecture de microservices apporte plus de liberté, mais aussi une complexité accrue.

Une stratégie d’API d’entreprise permet d’établir la cohérence et la découvrabilité des API, nécessaires pour des applications de microservices rapides et efficaces.

Une stratégie API-first accorde une grande priorité aux API en tant qu’actifs métier. Dans cette optique, les API sont les pierres angulaires autour desquelles les développeurs écrivent le code, plutôt que des fonctionnalités à ajouter après le développement du logiciel. Il s’agit d’une approche populaire dans les stratégies axées sur le numérique car elle met l’accent sur l’intégration et la communication entre les systèmes, les bases de données et les applications de l’entreprise.

Une stratégie axée sur les API présente plusieurs avantages :

• Réduit le risque de redondance des API
  
  
• Favorise la réutilisation des API
  
  
• Permet de découvrir les API dans un endroit centralisé pour faciliter la recherche et l’adoption.
  
  
• Rendre l’écosystème API plus efficace
  
  
• Réduction du temps consacré par les développeurs au débogage du code
  
  
• Permet une plus grande évolutivité
  
  
• Facilite la maintenance et la mise à jour des API
  
  
• Offre un avantage concurrentiel dans un monde de plus en plus axé sur les API.
  
  
• Permet aux équipes de développement de travailler en parallèle sur plusieurs API et de collaborer en temps réel.

Les stratégies API sont très différentes selon les objectifs et les besoins de chaque entreprise. Mais certains concepts et composants plus larges constituent des stratégies API solides, et de nombreuses stratégies API sont construites en suivant les étapes suivantes :

L’élaboration d’une stratégie commence par une question simple : que cherche à réaliser l’organisation avec ses API ?

Ces objectifs doivent s’aligner avec d’autres objectifs fixés par l’entreprise, que ce soit la mise en œuvre d’une transformation numérique, l’optimisation des workflows pour les développeurs, l’augmentation des indicateurs tels que la base utilisateur, l’expérience client ou la monétisation, l’augmentation de l’efficacité opérationnelle – ou, bien sûr, tout cela à la fois.

Un catalogage approfondi des cas d’utilisation potentiels peut orienter une stratégie API efficace.

L’entreprise souhaite-t-elle partager facilement des données entre les équipes internes ? Permettre aux développeurs de créer et d’améliorer rapidement des logiciels ? Connecter les clients ou les utilisateurs à des données et à des services ? Les stratégies d’API changent en fonction des besoins précis d’une entreprise, il est donc logique de commencer par une simple question : comment les API seront-elles utilisées ?

La gouvernance des API désigne l’ensemble complet de normes, de politiques et de pratiques qui orientent la manière dont une organisation développe, déploie et utilise ses API.

Idéalement, une organisation définit d’abord sa gouvernance puis conçoit les API conformément à ces règles, plutôt que l’inverse. Lors de l’élaboration de cette gouvernance, les équipes tiennent compte de facteurs tels que les objectifs d’entreprise, les technologies existantes et les technologies que l’entreprise pourrait intégrer à l’avenir.

Un cadre peut également définir le type d’API à utiliser pour les différents cas d’utilisation. Il existe plusieurs protocoles d’API, styles architecturaux et langages différents, chacun présentant des forces et des faiblesses. Il s’agit notamment de¹:

L’appel de procédure à distance (RPC) est un protocole qui permet à un programme de demander un service à un autre programme sur un autre ordinateur en utilisant essentiellement le même code que s’il demandait un service localement.

Le RPC fournit le modèle de communication de haut niveau utilisé dans le système d’exploitation. Il suppose l’existence d’un protocole de transport de bas niveau, tel que le protocole TCP/IP (Transmission Control Protocol/Internet Protocol) ou le protocole UDP (User Datagram Protocol), pour le transport des données de message entre les programmes qui communiquent.

Le RPC met en œuvre un système logique de communication client-serveur conçu spécifiquement pour soutenir les applications réseau. ²

Les protocoles RPC comprennent notamment XML-RPC, JSON-RPC et gRPC.

Le REST (Representational state transfer) est un ensemble de principes d’architecture d’API web. Les API REST (également appelées API RESTful) sont des API qui respectent certaines contraintes architecturales REST. Les API REST utilisent des requêtes HTTP telles que GET, PUT, HEAD et DELETE pour interagir avec les ressources. REST présente les données sous forme de ressources, chaque ressource étant représentée par un URI unique. Les clients demandent une ressource en fournissant son URI.

Les API REST sont des API sans état : elles n’enregistrent pas les données client entre les requêtes. Il est possible de créer des API RESTful avec des protocoles SOAP, mais les spécialistes considèrent généralement ces deux normes comme des spécifications concurrentes.

GraphQL est un langage de requête open source et un environnement d’exécution côté serveur qui permet aux clients de cibler exactement les ressources dont ils ont besoin. Contrairement à REST, qui utilise généralement plusieurs points de terminaison pour récupérer les données et effectuer des opérations réseau, les API GraphQL utilisent un seul point de terminaison GraphQL pour fournir aux clients une réponse précise et complète en un aller-retour à partir d’une seule demande, éliminant ainsi les problèmes de récupération excessive et insuffisante.³

Cependant, GraphQL peut introduire une complexité supérieure à celle nécessaire pour les applications simples.

Le protocole SOAP (Simple Object Access Protocol) est une spécification de protocole de messagerie légère basée sur XML qui permet aux points de terminaison d’envoyer et de recevoir des données via plusieurs protocoles de communication, notamment SMTP (Simple Mail Transfer Protocol) et HTTP (Hypertext Transfer Protocol). Le protocole SOAP est indépendant, ce qui permet aux API SOAP de partager des informations entre des applications ou des composants logiciels exécutés dans différents environnements ou écrits dans différents langages.

Les plateformes de gestion d’API sont des outils spécialement conçus pour accéder aux API, les contrôler, les distribuer et les analyser, tout en un seul emplacement centralisé. Les plateformes de gestion d’API permettent aux entreprises de partager la documentation et les outils entre équipes, renforcent la sécurité des données, respectent les normes de conformité et de gouvernance, et soutiennent les initiatives de transformation numérique.

Les plateformes de gestion des API comprennent souvent un portail pour les développeurs, qui leur permet de parcourir, d’accéder et de partager la documentation relative aux API. Cette solution peut éviter le problème des référentiels multiples, des bibliothèques obsolètes et des identifiants de propriété mystérieux (ou inconnus) dans le développement des API et des logiciels : tout est dans un seul endroit.

Les plateformes API incluent également des outils analytiques précieux. Cette plateforme centralisée permet de surveiller l’utilisation des API, le temps de réponse et les performances globales, et de détecter les vulnérabilités des API.

Enfin, l’utilisation de plateformes de gestion des API permet une gestion complète du cycle de vie de l’API. Le cycle de vie des API implique de nombreuses étapes différentes : création, développement, test, publication, maintenance, retrait. Une plateforme API peut rassembler toutes ces étapes en un seul endroit, ce qui permet aux entreprises d’avoir une visibilité sur des environnements API complexes et de grande envergure.

Étant donné que les API permettent d’accéder à des données et à des services, que ce soit pour des clients internes ou tiers, la sécurité doit être une préoccupation majeure à tous les stades de l’élaboration de la stratégie en matière d’API. Une sécurité API défectueuse peut entraîner des cyberattaques, des violations de données et d’autres accès non autorisés. Une stratégie d’API doit aborder la manière dont une entreprise s’assurera que les API sont sécurisées et conformes, en détaillant les approches d’authentification, de chiffrement, de validation, de surveillance, de mises à jour régulières et plus encore.

Une stratégie API complète inclut des plans pour ce qui se passe après la création des API : comment elles seront surveillées, maintenues, analysées, testées et mises à jour.

Il est essentiel de surveiller l’utilisation des API pour plusieurs raisons, notamment pour :

• S’assurer que les API fonctionnent correctement et sont exemptes de bogues
  
  
• Analyser les schémas de trafic pour détecter les comportements inhabituels et potentiellement dangereux
  
  
• Vérifier si toutes les API sont à jour
  
  
• Rester attentif au risque de duplication
  
  
• Supprimer les API qui sont inutilisables ou qui ont été remplacées

Une stratégie API doit détailler la manière dont une entreprise va promouvoir la visibilité sur l’ensemble de son environnement d’API, comment des informations issues de l’analytique et des commentaires des utilisateurs seront incorporées pour améliorer la performance de l’API, comment les mises à jour seront mises en œuvre et documentées et comment, si nécessaire, les API seront mises hors service.