Sommaire

C'est quoi une API (Application Programming Interface) ?

« C’est bloqué côté API. » « Il nous faudrait une API pour ça. » « Est-ce que l’outil a une API ? »

Si vous travaillez dans le numérique, vous avez forcément entendu une de ces phrases. Peut-être en hochant la tête, avec une idée assez floue de ce qu’il y avait derrière. Et c’est normal : c’est un de ces mots que tout le monde utilise et que personne ne prend le temps d’expliquer.

Je l’ai effleuré dans mon article sur les clés d’API, le temps de trois paragraphes. Mais je me suis dit que je n’expliquais pas assez. Parce que les API ne servent pas qu’aux agents IA : elles sont derrière à peu près toutes les applications que vous utilisez.

De mon côté, je baigne dedans depuis longtemps. J’en ai consommé dans les applications mobiles que j’ai développées, j’en ai conçu, et j’en ai souvent discuté avec des PO. Alors essayons de rendre ça simple.

Pour ça, je vous emmène à l’hôtel. Oui, encore. On y était déjà pour la clé d’API, autant y rester :)

Le room service

Vous êtes dans votre chambre, il est tard, vous avez faim. Vous n’allez pas descendre en cuisine, ouvrir le frigo et vous faire un gratin au milieu des cuisiniers. Ce n’est pas votre cuisine, vous ne savez pas où sont rangées les choses, et puis, vous n’avez tout simplement pas le droit d’y être.

À la place, il y a la carte du room service posée sur la table de votre chambre. Vous la lisez, vous choisissez ce que vous voulez, puis vous appelez pour commander ce délicieux gratin de ravioles (car vous avez très envie de cette spécialité de la Drôme) en donnant votre numéro de chambre. Un peu plus tard, on frappe : votre plateau est là.

Vous n’avez aucune idée de ce qui s’est passé en cuisine. Combien de cuisiniers, quel four, d’où vient la crème. Et vous n’avez pas besoin de le savoir. Vous avez fait une demande prévue par le menu, et vous avez reçu ce qui était annoncé.

Une API, c’est ce room service. Mais entre deux logiciels.

Une API, avec des mots simples

API veut dire Application Programming Interface, interface de programmation en français. Le mot important, c’est interface : un point de contact entre deux choses, avec des règles pour la manière de se parler.

Quand vous utilisez une application, vous passez par son interface graphique : des écrans, des boutons, des menus. C’est fait pour des humains. Un logiciel, lui, n’a ni yeux ni doigts. Quand il veut quelque chose d’un autre logiciel, il passe par une autre porte : l’API. C’est une liste de demandes que le service accepte de recevoir, avec la manière de les formuler et ce qu’il répondra.

Prenez l’application météo de votre téléphone. Elle n’a pas de stations météo sur les toits. Elle demande les prévisions à un service spécialisé, via son API, et se contente de les afficher joliment. Le service météo, c’est la cuisine. L’application, c’est vous dans la chambre.

Une demande, une réponse

Concrètement, ça fonctionne par échanges. Un logiciel envoie une demande (on dit une requête), l’autre renvoie une réponse.

La requête de l’application météo ressemble, en gros, à « donne-moi la météo de Paris pour demain ». Et la réponse pourrait ressembler à ça :

{
  "ville": "Paris",
  "date": "2026-11-08",
  "temperature": 9,
  "ciel": "nuageux",
  "pluie": "20 %"
}

Pas de jolie icône de nuage, pas de mise en page. Juste les informations, rangées dans un format que n’importe quel programme sait lire (celui-là s’appelle JSON, et vous en croiserez très souvent).

C’est un point que je trouve important quand on travaille sur un produit : l’API donne les informations, pas l’affichage. C’est l’application qui décide quoi en faire : un gros chiffre sur l’écran d’accueil, un widget, une notification « prenez un parapluie ». La même réponse peut servir un site web, une application mobile, une montre connectée ou l’application d’un partenaire.

La carte, c’est la documentation

Revenons au room service. Ce qui rend tout ça possible, c’est la carte. Elle dit ce qu’on peut commander, comment le demander, et ce qu’on va recevoir.

Une API a la même chose : sa documentation. Elle est écrite par l’équipe qui fabrique l’API à destination des développeurs qui vont s’en servir. « Pour obtenir la météo, envoyez telle demande à telle adresse, en précisant la ville et la date. Vous recevrez la température, le ciel et le risque de pluie. »

Et comme au room service, ce qui n’est pas sur la carte ne se commande pas. Vous pouvez réclamer une pizza tant que vous voulez, si elle n’y est pas, la cuisine ne la fera pas. Une API ne fait que ce qui a été prévu. Si elle ne donne pas la vitesse du vent, l’application ne pourra pas l’afficher, même si le service météo la connaît parfaitement.

C’est souvent ce qui se cache derrière « ce n’est pas possible, ce n’est pas dans l’API ». Le service sait peut-être le faire, mais il ne le propose simplement pas à l’extérieur (ou pas encore).

Il y en a partout

Une fois qu’on a l’image en tête, on en voit partout.

  • Vous payez sur un site marchand : le site transmet le paiement à l’API d’un service comme Stripe ou PayPal, qui répond « accepté » ou « refusé ».
  • Votre fil d’actualités sur votre réseau social préféré, il vient d’une API. Tout l’algorithme est sur le serveur.
  • Vos outils se parlent dans n8n ou Zapier : chaque étape, c’est un appel à l’API d’un service.
  • Et les IA aussi : Claude et ChatGPT ont leur API, qui permet à d’autres applications d’utiliser leurs modèles (c’est d’ailleurs comme ça qu’on peut ajouter de l’IA dans une application mobile).

Et puis il y a toutes celles qu’on ne voit jamais. Par exemple un outil de tracking pour permettre d’analyser le trafic d’un site. Ou même les API que le serveur lui-même consomme pour vous fournir les bonnes informations - eh oui, il y a parfois des intermédiaires.

Publique, partenaire ou interne

Toutes les API ne sont pas ouvertes à tout le monde.

Le room service est réservé aux clients de l’hôtel. Mais la même cuisine prépare aussi les plats du restaurant, du bar, et peut-être les repas du personnel. Une cuisine, plusieurs guichets, chacun avec sa carte.

Pour les API, c’est pareil :

  • une API publique est ouverte à qui veut (souvent avec une inscription et une clé) : la météo, Notion, Slack ;
  • une API partenaire n’est accessible qu’à quelques entreprises, avec un contrat ;
  • une API interne ne sert qu’à l’entreprise elle-même, entre ses propres logiciels et ses équipes.

Dans les applications mobiles que j’ai développées, il y avait l’application d’un côté, le serveur (le back-end) de l’autre, et une API interne au milieu pour qu’ils se parlent. Parfois, des API de services tiers venaient s’y ajouter. On peut même aller jusqu’à fabriquer une API sur mesure pour une seule application, j’en parlais à propos du Backend for Frontend.

Ce que ça change quand on travaille sur un produit

Si vous êtes PO, designer, chef de projet, ou simplement curieux de ce que racontent les développeurs, voilà ce que je trouve utile d’avoir en tête.

Une API, c’est un contrat. Une fois la carte écrite et acceptée, la cuisine et les clients peuvent avancer chacun de leur côté. L’équipe mobile n’a pas besoin d’attendre que le serveur soit terminé : elle connaît la forme des réponses et peut travailler avec de fausses données en attendant (on appelle ça des mocks). C’est souvent ce qu’il y a derrière « on attend l’API / on attend le back-end » : soit le plat n’est pas encore cuisiné, soit, plus embêtant, la carte n’est pas encore écrite.

On ne change pas la carte du jour au lendemain. Si vous retirez le gratin, les habitués qui le commandaient chaque soir vont être déçus. Pour une API, c’est pire : les logiciels qui l’utilisent cassent. C’est pour ça qu’on parle de versions. On garde l’ancienne carte un moment, on publie la nouvelle à côté, et on prévient avant de retirer l’ancienne. Une modification qui paraît anodine (renommer un champ, changer le format d’une date) peut demander beaucoup de coordination quand d’autres en dépendent. Faites discuter vos équipes !

La cuisine a ses limites. Elle ne peut pas préparer mille plateaux à la minute. Beaucoup d’API limitent le nombre de demandes autorisées (on parle de rate limit), et certaines sont payantes à l’usage. Bon à savoir avant d’imaginer une fonctionnalité qui interroge un service toutes les secondes.

Dépendre d’une API, c’est dépendre de quelqu’un. Si la cuisine ferme, plus de room service. Si un service tiers tombe en panne, change ses conditions ou ferme son API, la fonctionnalité qui en dépend s’arrête aussi. Ça ne veut pas dire qu’il faut s’en priver, mais ça vaut le coup de se demander ce que fait le produit quand la réponse n’arrive pas.

Il faut dire qui commande. Au room service, on donne son numéro de chambre, pour savoir où livrer et sur quelle note mettre le plateau. La plupart des API demandent la même chose. C’est le rôle de la clé d’API, le badge d’hôtel dont je parlais dans l’article précédent.

Et les agents IA, dans tout ça ?

Un agent IA est un logiciel. Quand vous lui demandez de lire votre agenda ou de créer une page Notion, il ne va pas cliquer dans l’interface comme vous le feriez (enfin, la plupart du temps). Il passe par l’API du service.

Souvent pas directement : un connecteur ou un MCP fait l’intermédiaire. Mais en bout de chaîne, ce sont souvent des appels à une API. C’est pour ça qu’un service sans API est difficile à brancher à un agent.

J’en parle plus en détail dans la série sur la connexion d’un agent à vos outils.

Avec quoi on repart ?

Une API, au fond, c’est une forme de discussion et un contrat entre logiciels. On ne débarque pas dans la cuisine des autres : on lit la carte, on commande ce qui est prévu, on donne son numéro de chambre, et on reçoit son plateau. On fait une demande, on obtient une réponse.

Il existe aussi un autre cas intéressant : quand c’est l’hôtel qui doit vous prévenir, sans que vous ayez rien demandé. C’est le principe du webhook, et il aura son article dans la série.


Connecter un agent IA à d’autres services :

Hors-série complémentaire :