API – Application Programming Interface : Définition, Utilité et Fonctionnement

API est l’acronyme de Application Programming Interface. Il s’agit d’une interface permettant de connecter un logiciel à un autre logiciel. Le but : les faire “communiquer” entre eux à travers un échange de données et de fonctionnalités.

Concrètement, vous utilisez une API dès que vous vous servez d’une application comme LinkedIn, que vous envoyez un message ou que vous vérifiez la météo du jour sur votre smartphone. Je vous l’ai dit : les API (gratuites et payantes) sont partout et nous sont très utiles !

Vous imaginez bien que les possibilités offertes par les API sont innombrables :

• Intégration de fonctionnalités d’une application à une autre ;
• Programmes d’affiliation (via l’installation de cookies) ; 
• Campagnes publicitaires ;
• Partage de données ;
• Etc.

Littéralement, Application Programming Interface se traduit par Interface de Programmation d’Applications (IPA). Notez que c’est plutôt l’acronyme API qui est utilisé, même en français.

Une Application Programming Interface se connecte à internet et envoie de la data à un serveur dès qu’un utilisateur l’utilise (par exemple via une application mobile). Le serveur récupère alors la data et la traite en fonction des actions qu’il est programmé à effectuer. Puis, il renvoie la data à l’application qui la traite à son tour, avant de présenter à l’utilisateur les informations demandées (de façon compréhensible pour l’humain).

Tout se fait quasi-immédiatement et de manière automatisée. Si bien que l’utilisateur n’a pas à se soucier de ce qui se passe “de l’autre côté”. C’est comme cela que fonctionne toute API. Il y a ainsi 3 parties :

• Un utilisateur : la personne ou l’application tierce qui effectue une demande ;
• Un client : l’application qui envoie la demande au serveur ;
• Un serveur : l’ordinateur chargé d’interpréter la demande et de lui répondre (en fonction de ce qu’il est programmé à faire).

Autrement dit, on parle d’API dès qu’un système informatique (application, logiciel, site internet, etc.) cherche à interagir de façon normalisée avec un système informatique tiers. On dit alors que le système informatique tiers “expose une API”.

Je vous épargne les explications techniques, comme la façon dont sont interprétées les données ou le détail des langages de programmation utilisés (souvent en Java, JavaScript, PHP, et C#).  

Il existe plusieurs types d’Application Programming Interfaces en fonction de qui peut y accéder et des cas d’utilisation. Voici les principaux :

• L’API ouverte (ou externe) : accessible par des utilisateurs extérieurs à l’entreprise qui l’a conçue, ce type d’API est souvent proposé en libre-service. C’est le cas de Google Maps par exemple, dont les fonctionnalités sont utilisées et “customisées” par d’autres applications (livreurs, covoitureurs, etc.).
• L’API interne (ou privée) : uniquement utilisable et modifiable par des utilisateurs internes à l’entreprise, ce type d’API sert la plupart du temps à améliorer la productivité des collaborateurs. C’est le cas par exemple d’une API-maison orientée sur l’optimisation de la donnée client.
• L’API partenaire : à mi-chemin entre API ouverte et API interne, ce type d’API est accessible par des utilisateurs externes à l’entreprise à condition d’en avoir l’autorisation. Les organismes de santé (mutuelle, hôpitaux, etc.) sont un très bon exemple d’API partenaires qui échangent des données entre eux.

Les types API peuvent aussi se distinguer par leur utilisation. Il y a :

• L’API système : ce type d’API rend accessible des données issues de systèmes d’enregistrement utilisés par l’entreprise (ERP, bases de données propriétaires, CRM, etc.).
• L’API de processus : ce type d’API orchestre plusieurs API systèmes afin d’accomplir un objectif métier bien précis (comme exprimer l’état d’une expédition, créer une vue à 360° d’un client-type, etc.).
• L’API d’expérience : ce type d’API combine les API systèmes et les API de processus pour exposer des données exploitables par les utilisateurs prévus (par exemple : applications mobiles, portails RH, etc.).

Même si ces deux “systèmes de communication de la data” semblent proches, il existe une différence entre l’API et le Web Service. La différence, c’est que le Web Service fait interagir deux systèmes situés sur un même réseau, tandis que l’API fait interagir deux systèmes différents (pas forcément situés sur un même réseau donc). Tout simplement.

Allez, je me permets un petit écart pour vous parler d’un point technique. Pour standardiser l’échange de données entre des API toujours plus variées, il a fallu développer un protocole : le SOAP (pour Simple Object Access Protocol). Sorte d’Espéranto pour les robots, le SOAP est là pour veiller à ce que les API parlent la même langue (en utilisant le format XML et en recevant des requêtes via HTTP ou SMTP).

Vous avez également le REST (pour Representational State Transfer) qui sert lui aussi à normaliser les échanges de données entre des API créées dans des langages informatiques différents. La différence entre SOAP et REST est que le premier est un protocole, tandis que REST est un style d’architecture. Cela veut dire qu’il n’y a aucune norme officielle pour régir les API en REST.

En résumé, les API sont là pour que les applications et autres systèmes informatiques puissent “parler” efficacement entre eux et échanger de la data. Elles sont devenues si importantes aujourd’hui qu’elles sont à la source même de business models basés sur l’exploitation de la Data Client (regardez du côté des GAFA). Autrement dit, savoir faire parler la donnée est un enjeu capital à l’ère du Big Data.