Qu'est-ce qu'une API ? Le guide en français clair

Vous avez forcément déjà croisé le terme « API » — peut-être dans la bouche d’un ami développeur, peut-être au détour d’un article tech. Un truc qui sert à connecter des données, non ? Ce guide s’adresse à tous ceux qui se sont un jour demandé, tout haut ou tout bas, ce qu’est réellement une API. On va le faire sans jargon, en s’appuyant sur des exemples du quotidien, et en montrant comment les API et leur proche cousin, les webhooks, font tourner les automatisations sur lesquelles vous comptez tous les jours.

Que signifie API ?

API est l’acronyme d’Application Programming Interface, soit « interface de programmation d’application ». Trois mots qui sonnent plus intimidants que l’idée qu’ils recouvrent. À la fin de cet article, chacun d’eux aura du sens — et vous commencerez à remarquer les API qui travaillent en silence derrière presque toutes les applications que vous utilisez.

Une API, c’est quoi au juste ?

La première chose à comprendre, c’est qu’une API est une interface. Une interface vers quoi ? Vers une application. Et qui s’en sert ? D’autres programmes — pas des humains. C’est le point essentiel : les API sont consommées par des logiciels, pas par des personnes qui cliquent sur des boutons.

Voici donc une définition nette : une API est une interface qu’un programme utilise pour interagir avec une autre application. Ou, dit encore plus simplement, les API permettent aux ordinateurs de se parler entre eux.

Une analogie utile, c’est la prise électrique. Pour vous sécher les cheveux, votre sèche-cheveux a besoin d’électricité. Vous n’allez pas mettre le doigt dans les fils pour aller chercher le courant — ça ne sécherait pas vos cheveux, et ce serait dangereux. Il vous faut une interface qui rende l’électricité accessible et utilisable en toute sécurité : la prise. Et vous ne touchez pas non plus la prise directement ; vous branchez le sèche-cheveux. La fiche tire le courant à travers la prise pour alimenter l’appareil.

Transposez cela au logiciel : vous êtes la personne qui utilise son ordinateur, le sèche-cheveux est le programme, la prise est l’API, et l’électricité est l’application qui fournit la donnée ou le service. « Se sécher les cheveux », c’est tout ce que le programme a été conçu pour faire.

Une mise en garde : une API n’est pas du matériel. C’est simplement un autre logiciel qui tourne sur un serveur — un ensemble de règles convenues que les deux parties respectent pour échanger des informations de manière fiable.

Quelques exemples d’API

Voyons les API à l’œuvre. Imaginez que vous gériez le contenu d’un site qui recense les choses à faire dans une ville. Pour chaque événement que vous publiez, vous voulez afficher une carte avec un repère indiquant le lieu. Plusieurs options s’offrent à vous :

1. Chercher à la main la latitude et la longitude de chaque adresse, puis les positionner vous-même.
2. Demander à un développeur d’écrire une ligne de code sur mesure pour chaque adresse.
3. Utiliser un service qui, via les API de géocodage et de cartographie d’un fournisseur de cartes, récupère les coordonnées et place une carte toute prête sur votre page en quelques secondes.

L’option 3 est la seule qu’une personne sensée choisirait. Voici ce qui se passe quand vous l’utilisez : votre gestionnaire de contenu saisit une adresse dans un formulaire du back-office. Appuyer sur « Entrée » envoie de petits paquets de données — par Wi-Fi, puis à travers les câbles physiques d’Internet — vers les serveurs du fournisseur. Ces serveurs interprètent la requête, recherchent les coordonnées et les renvoient dans un format lisible par une machine, comme le JSON (grâce à l’API de géocodage). La carte et le repère s’affichent ensuite sur votre page dans un format lisible par un humain.

Cette unique requête fait gagner beaucoup de travail à la fois à votre gestionnaire de contenu et à votre développeur. C’est l’un des principaux avantages d’une API : elle permet à l’utilisateur final de faire quelque chose d’utile tout en épargnant aux programmeurs le code fastidieux et répétitif qu’il aurait fallu écrire pour construire la même chose de zéro. Plus une API transforme un processus complexe et souvent répété en quelques lignes de code réutilisable, plus tout le monde gagne en productivité.

C’est pour cela que les API sont partout. Fournisseurs de cartes, plateformes sociales, services de paiement, services de messagerie — tous exposent des API pour que les développeurs puissent intégrer des cartes, activer des boutons « se connecter avec… », accepter des paiements, et bien plus encore. Les possibilités vont du plus simple au plus sophistiqué.

Reprenons notre site d’événements. Supposons qu’un concert soit annulé et que vous deviez prévenir par SMS les 500 détenteurs de billets. Vous pourriez prendre votre téléphone et envoyer 500 messages à la main — ou intégrer une API de SMS comme Callr qui les envoie automatiquement, en appliquant exactement les principes ci-dessus. Le résultat : un gain d’efficacité spectaculaire et la capacité de construire des workflows qui apportent une vraie valeur à votre activité.

Les webhooks et le « principe d’Hollywood »

Quand un programme utilise une API, il émet une requête — on dit souvent qu’il « appelle l’API ». Chaque appel consomme des ressources serveur, ce qui explique pourquoi de nombreuses API commerciales plafonnent le nombre de requêtes autorisées sur une période donnée, afin de ne pas surcharger leurs systèmes.

Dans certaines situations, appeler une API en permanence juste pour vérifier si quelque chose a changé est un gaspillage. Il serait bien plus efficace que l’API puisse simplement vous prévenir au moment où une nouvelle information arrive. C’est exactement ce que font les webhooks.

Imaginez un site marchand qui a intégré l’API d’un service de paiement pour que ses clients achètent facilement. Des événements importants se produisent côté fournisseur sans apparaître si vous ne les demandez pas — par exemple, lorsqu’un paiement d’abonnement échoue. Interroger l’API encore et encore pour vérifier est une utilisation inefficace des ressources. Mais si votre site n’apprend jamais que le paiement a échoué, vous vous retrouvez avec des clients mécontents.

Les webhooks résolvent ce problème en inversant le flux. Au lieu que votre programme demande sans cesse des mises à jour à l’API, c’est l’API qui notifie votre programme dès qu’un événement prédéfini se produit. On parle parfois du « principe d’Hollywood » : ne nous appelez pas, c’est nous qui vous appellerons.

Pour un service de paiement, les webhooks peuvent mettre à jour la fiche d’un client lorsqu’un paiement réussit ou échoue, signaler un litige, et ainsi de suite. Chez Callr, nous utilisons les webhooks de la même façon — pour prévenir nos clients qu’un SMS a été remis, qu’un solde de compte devient faible, et pour bien d’autres événements qu’il vaut la peine de connaître à la seconde où ils surviennent.

Les webhooks en action

Pour réunir toutes ces idées, voici un dernier exemple de workflow efficace et automatisé.

Imaginez que vous êtes commercial sur un salon professionnel et que vous notez sur une tablette les prospects que vous rencontrez. Votre équipe utilise un outil pour collecter les coordonnées via un formulaire, et un autre pour gérer les leads sur un tableau partagé. Prospecter sur un salon est épuisant, et la dernière chose que l’on a envie de faire, c’est de recopier à la main les coordonnées de chaque lead, de faire quelques recherches en ligne, puis de monter une fiche pour chaque personne croisée.

C’est là qu’intervient un outil d’automatisation no-code — le genre d’outil qui relie différentes API en workflows plus intelligents sans que vous écriviez la moindre ligne de code. Avec lui, vous pourriez :

• Utiliser un webhook pour qu’à l’instant où quelqu’un remplit votre formulaire de contact, une nouvelle fiche lead soit créée automatiquement sur votre tableau partagé.
• Aller plus loin en ajoutant un service d’enrichissement de données qui, à partir d’une adresse e-mail, récupère les informations publiques pertinentes sur cette personne ou cette entreprise.

Reliez le tout et, chaque fois que votre commercial saisit l’e-mail d’un prospect, une fiche pré-remplie apparaît sur le tableau, visible par toute l’équipe — avec les notes du formulaire et les données enrichies — sans effort supplémentaire de sa part. C’est une manière remarquablement simple de mettre les API au travail et de fluidifier un workflow, sans une seule ligne de code.

Ce qu’il faut retenir

Quelques points à garder en tête :

• Une API est une Interface utilisée par des Programmes pour interagir avec une Application.
• Les API exposent des données ; les développeurs écrivent des programmes qui les consomment.
• Les fournisseurs de cartes, les plateformes sociales, les services de paiement et les services de messagerie comme Callr proposent tous des API utiles — c’est le cas de presque tous les services modernes.
• Les développeurs branchent ces API dans leurs propres applications au lieu de réinventer la roue, ce qui leur permet de se concentrer sur la valeur centrale de ce qu’ils construisent.
• Les API sont conçues pour exposer des données dans un format lisible par une machine (souvent du JSON), tandis que les sites web exposent des données dans un format lisible par un humain (images, liens, formulaires).
• Les webhooks sont des appels d’API inversés : la requête est envoyée par le service externe et reçue par votre application, à l’instant où quelque chose se produit.

Ce guide s’est surtout concentré sur les API web, mais il existe bien d’autres types d’API. Si vous voulez en voir une de près, jetez un œil à la documentation de l’API Callr — Callr fournit une API REST et des webhooks que vous pouvez mettre au travail dès maintenant.