RETROUVEZ CET ARTICLE ET PLUS ENCORE DANS NOTRE MAGAZINE : Quel futur pour le stockage de données ?
Découvrez toutes les newsletters thématiques gratuites d'Archimag dédiées aux professionnels de la transformation numérique, des bibliothèques, des archives, de la veille et de la documentation
[NDLR : Cet article est la première partie d’un duo consacré à la réussite de l’urbanisation d’un système d’information (SI) dans le cadre d’un projet écoresponsable. Un second article, dédié à l’urbanisation du SI à proprement parler, sera publié le mois prochainement]
Qu’est-ce qu’une API ?
Une interface de programmation (ou API, pour application programming interface) est une façade clairement délimitée par laquelle un logiciel offre des services à d’autres logiciels afin que des données ou des fonctionnalités soient échangées. Autrement dit, une API est un intermédiaire, qui permet à différentes applications de communiquer entre elles. Une API peut donc être comparée au serveur d’un restaurant : vous (le client) passez commande via ce serveur (l’API), qui la transmet au cuisinier (l’application cible). Une fois le plat prêt, le serveur vous l’apporte.
Lire aussi : Entre gouvernance et stratégie data, la DSI en première ligne
Les API offrent de nombreuses possibilités, comme la portabilité des données, la mise en place de campagnes de courriels publicitaires, des programmes d’affiliation, l’intégration de fonctionnalités d’un site sur un autre ou l’open data. Elles peuvent être gratuites ou payantes.
Les différents types d’API
API publiques
Une API publique est ouverte et disponible pour être utilisée par tout développeur ou acteur tiers. Une entreprise qui cultive une stratégie commerciale impliquant le partage de ses applications et de ses données avec d’autres sociétés développera et offrira une API publique.
API partenaires
Une API partenaire, uniquement disponible pour des développeurs externes ou des consommateurs d’API spécifiquement triés et autorisés, est un moyen de faciliter les activités interentreprises. Par exemple, si une organisation souhaite partager certaines de ses données clients avec des spécialistes de la gestion de la relation client (CRM), une API partenaire peut connecter le système interne de données clients à ces parties tierces. En revanche, aucun autre usage de l’API n’est permis.
API internes
Une API interne (ou privée) est destinée à être utilisée uniquement au sein de l’entreprise pour connecter des systèmes et des données. Par exemple, une API interne peut connecter les systèmes de paie et de ressources humaines (RH) d’une société.
API composites
Les API composites combinent généralement deux ou plusieurs interfaces de programmation pour établir une séquence d’opérations connexes ou interdépendantes. Les API composites peuvent être utiles pour traiter des comportements complexes ou étroitement liés, et peuvent parfois améliorer la vitesse et les performances par rapport aux API individuelles.
Lire aussi : Les défis de la data gouvernance
API versus connecteurs
API et connecteurs sont les deux faces d’une même pièce. Il est inutile de les différencier du point de vue de l’urbanisation, car ils participent tous deux au même objectif, qui est de relier entre elles les couches applicatives du SI. Si l’on souhaite tout de même les différencier en prenant une analogie, on pourrait dire que le connecteur est le tuyau et l’API la vanne dans un système de raccordement d’un réseau d’eau. Autrement dit, l’API est la façon dont une application va pouvoir communiquer avec une autre et le connecteur est le code implémenté du côté de l’application cliente pour transporter les données.
Si l’API est unique, côté application, avec une description unique, les connecteurs peuvent être de différentes natures et donc de différentes qualités. Les connecteurs sont les acteurs : ils appliquent les règles définies par les API. Si une API est le règlement, un connecteur est l’acteur du jeu, qui suit ces règles, pour atteindre un objectif précis.
Qu’est-ce qu’un endpoint ?
Il est important de noter que les endpoints et les API sont différents. Un endpoint (ou point d’extrémité) est un composant d’une API, tandis qu’une API est un ensemble de règles qui permettent à deux applications de partager des ressources. Les points d’extrémité sont les emplacements des ressources et l’API utilise les URL des points d’extrémité pour récupérer les ressources demandées.
Prenons l’exemple d’une RESTful API pour une librairie (bookstore) avec de multiples endpoints :
- GET /books: Retrieves a list of all books.
- GET /books/{id}: Retrieves a specific book by its ID.
- POST /books: Creates a new book.
- PUT /books/{id} : Updates an existing book by its ID.
- DELETE /books/{id} : Deletes a book by its ID.
Dans cet exemple, /books est le point d’extrémité de base pour la gestion des livres, et l’identifiant unique du livre est un espace réservé à l’identifiant unique du livre.
Lire aussi : Gare au "greenwashing" sur les produits et services de la digitalisation !
Les API Managers
Les différentes solutions de gestion des API du marché offrent des fonctionnalités variées, mais qui permettent généralement aux utilisateurs d'effectuer les tâches suivantes :
- conception d'API : grâce aux solutions de gestion des API, les utilisateurs, depuis les développeurs jusqu'aux partenaires, peuvent créer des API, les publier, les déployer, mais aussi enregistrer de la documentation, des stratégies de sécurité, des descriptions, des limitations d'utilisation, des fonctionnalités de "runtime", entre autres informations utiles,
- passerelle d'API : les solutions de gestion des API servent également de passerelle d'API (ou API Gateway), qui garantit la sécurité des API en appliquant les stratégies et requêtes de sécurité adaptées, et en garantissant les autorisations et la sécurité,
- stockage d'API : les solutions d’API management permettent aux utilisateurs de conserver leurs API dans un magasin ou un catalogue où ils peuvent les exposer à des intervenants internes et/ou externes. Ce "magasin" d'API sert ensuite de marché en ligne pour les API. Les utilisateurs peuvent y souscrire des API, obtenir de l'aide de la part d'autres utilisateurs et de la communauté, etc.,
- analyse des API : la gestion des API offre aux utilisateurs la capacité de surveiller l'utilisation des API, le chargement, les journaux de transactions, les données historiques et bien d'autres mesures relatives aux API, qui apportent des informations sur le statut et le succès des API disponibles.
Les API de l’État
Les API proposées par la sphère publique sont disponibles sur le site Piste.gouv.fr. Plateforme d'intermédiation des services pour la transformation de l'État gérée par l'Agence pour l'informatique financière de l'État (AIFE), Piste met à disposition les API de la sphère publique et facilite la vie des développeurs.
API Manager VS expert ESB
L’API Manager et l’expert ESB (Enterprise Service Bus) sont deux rôles qui nécessitent une forte compréhension des systèmes d’information et des besoins de l’entreprise, et qui doivent garantir la fluidité et la sécurité des échanges de données. Il existe malgré tout quelques différences :
- l’API Manager gère les interfaces de programmation d’applications, se concentre sur l’exposition des services, la sécurité et la performance des API,
- l’expert ESB concentre ses efforts sur l’intégration et la communication entre différentes applications au sein de l’entreprise, utilisant des ESB pour orchestrer les échanges de données.
Plutôt que de les opposer, il est essentiel de comprendre que l’ESB et l’API management répondent à des besoins distincts et peuvent parfaitement fonctionner ensemble. Exemple de complémentarité : L’ESB intègre des systèmes internes et orchestre les données complexes. Les résultats de ces intégrations sont exposés via des API gérées par une solution d’API Management.
Quand les utiliser ensemble ? ESB pour transformer et orchestrer les flux internes, API Manager pour rendre ces services accessibles à des applications externes ou des partenaires.
Guillaume Vola
[Consultant expert en écoresponsabilité et chef de projet dématérialisation au sein de collectivités]
