À l'article 7, tu as ouvert l'inspecteur réseau de ton navigateur. Tu as regardé une requête partir vers un fichier qui s'appelait quotes.json. Tu as vu la réponse revenir, propre, lisible. Tu savais ce qui se passait : quelque chose demandait, quelque chose répondait.
Ce que tu as fait ce jour-là, c'est regarder deux programmes se parler.
Cette fois, on va regarder la même chose, mais à l'échelle des outils qu'on utilise vraiment au travail.
À l'article 7, la requête partait vers un fichier
Le fichier quotes.json était simple. Il contenait des citations, il les renvoyait quand on le demandait. Pas de logique, pas de traitement, juste un tiroir qu'on ouvrait.
Mais la plupart des outils qu'on utilise ne sont pas des tiroirs. HubSpot ne stocke pas juste des données, il les manipule. Claude ne renvoie pas un texte pré-écrit, il en génère un nouveau à chaque fois. Quand une requête s'adresse à eux, elle ne dit pas "donne-moi le contenu du tiroir". Elle dit quelque chose de plus précis : "crée un contact", "envoie ce message à ce modèle".
La question que je me suis posée la première fois que j'ai voulu connecter deux outils entre eux : comment est-ce que je sais ce que j'ai le droit de demander ? Et dans quel format ?
La réponse, c'est que les outils sérieux publient une liste. Une liste de demandes qu'ils acceptent, avec pour chacune le format attendu et ce qu'ils renvoient en retour. Cette liste a un nom, on y arrive. Mais avant, on va la regarder en vrai.
HubSpot a une liste de ce qu'il accepte
La première fois que j'ai ouvert une documentation d'API, j'avais ... peur. Je m'attendais à quelque chose d'ésotérique, plein de termes que je ne connaîtrais pas, organisé pour des développeurs et incompréhensible pour le reste du monde. Mais même en étant prévenue...
Ce que j'ai trouvé dans la doc HubSpot, c'était une liste.
Une liste d'opérations. Avec, pour chacune, un nom qui ressemblait à ce qu'il faisait :
GET /crm/v3/objects/contacts/{contactId}: récupérer un contact à partir de son identifiant-POST /crm/v3/objects/contacts: créer un nouveau contact-PATCH /crm/v3/objects/contacts/{contactId}: mettre à jour un contact existant-POST /crm/v3/objects/deals: créer une affaire-GET /crm/v3/objects/deals: récupérer la liste des affaires Le code autour, les accolades, les barres obliques, je ne savais pas encore tout lire. Mais les mots, oui. Contact. Affaire. Récupérer. Créer. Mettre à jour.
Ce sont les objets métier d'un CRM. Les mêmes qu'on manipule dans l'interface, à la souris. Sauf qu'ici, ils sont exposés sous forme de commandes qu'un autre programme peut passer.
C'est ça qui m'a frappée. HubSpot ne cache pas ses données derrière une interface graphique réservée aux humains. Il les rend accessibles à d'autres programmes, à condition qu'ils passent par cette liste et respectent le format.
La doc précise aussi ce que HubSpot renvoie en retour. Si tu crées un contact, il te renvoie l'identifiant du contact créé. Si tu récupères une affaire, il te renvoie ses propriétés dans un format structuré. C'est un contrat. Tu envoies ça, tu reçois ça.
Anthropic a la même chose, pour autre chose
Quelques mois plus tard, j'ai ouvert la documentation d'Anthropic, la société qui développe Claude. Je cherchais à comprendre comment Claude Code, quand il génère du code pour moi, appelle lui-même Claude.
J'ai trouvé la même structure. Une liste, avec des noms lisibles :
POST /v1/messages: envoyer un message à Claude et recevoir une réponse Une seule opération principale, mais avec des paramètres précis. Quel modèle utiliser (claude-opus-4-5,claude-sonnet-4-5, etc.). Le contenu du message. Le nombre maximum de mots dans la réponse. Et en retour : le texte généré, le modèle utilisé, le nombre de mots consommés.
Deux outils complètement différents. HubSpot gère des relations clients, Anthropic génère du texte. Leurs listes n'ont rien à voir dans leur contenu. Mais la logique est identique : un ensemble de demandes connues, un format attendu pour chaque demande, un format de réponse documenté.
Et quand Claude Code appelle Claude pour générer du code, c'est exactement ce mécanisme qu'il utilise. Il consulte cette liste, il choisit l'opération POST /v1/messages, il remplit les paramètres avec mon contexte et ma question, il envoie. Ce n'est pas de la magie. C'est une commande passée à un menu connu.
Ce qui m'a aidée à comprendre ça concrètement : quand Claude Code me dit "je génère le composant", il y a en coulisse une requête qui part vers Anthropic, exactement comme la requête que tu as regardée partir vers quotes.json à l'article 7. Même mécanique. Destinataire différent, contenu différent, mais le geste est le même.
Ce qu'on appelle ça
Cette liste de demandes acceptées, avec ses formats et ses réponses documentées, c'est ce qu'on appelle une API.
Une API, c'est le menu d'un restaurant. Pas ce qu'il y a en cuisine, pas la recette, pas comment le chef travaille. Juste ce que tu as le droit de commander, dans quel format tu dois le demander, et ce qui arrive dans ton assiette en retour.
J'avais longtemps cru qu'une API c'était quelque chose de technique au sens mystérieux du terme, quelque chose qui appartenait aux développeurs et dont je n'avais pas à me préoccuper. Le jour où j'ai compris que c'était juste un contrat entre deux programmes sur ce qu'on peut demander et ce qu'on reçoit, tout ce que j'avais vu avant a pris un sens différent.
Quand quelqu'un dit "cet outil a une API", ça veut dire qu'il a publié cette liste. Qu'il a rendu ses fonctionnalités accessibles à d'autres programmes, de façon documentée et prévisible. Ce n'est pas une promesse vague d'interopérabilité. C'est une liste concrète de ce qu'on peut demander.
Pourquoi "avoir une API" est une décision
Tous les outils n'ont pas d'API. Et ceux qui en ont ne mettent pas tout dans leur liste.
J'ai découvert ça d'une façon assez frustrante, il y a quelques années. Je voulais connecter deux outils que j'utilisais au quotidien dans un projet de suivi opérationnel. L'un des deux avait une API bien documentée. L'autre avait une API, mais quand j'ai cherché l'opération dont j'avais besoin, elle n'y était pas. L'outil permettait de faire la chose dans son interface, à la main. Mais il n'avait pas choisi d'exposer cette fonction à d'autres programmes.
Résultat : l'automatisation que je voulais construire était impossible, peu importe mon niveau technique. Ce n'était pas un problème de compétence. C'était un problème de menu : le plat n'était pas proposé.
Cette décision, les éditeurs d'outils la prennent pour des raisons variées. Parfois commerciales : certaines fonctionnalités sont réservées aux plans payants plus élevés. Parfois stratégiques : on n'expose pas ce qui pourrait permettre à un concurrent de copier la logique métier. Parfois simplement par manque de ressources : documenter et maintenir une API, ça coûte.
Ce que ça change pour toi, concrètement : la question "est-ce que cet outil a une API ?" est une question utile mais incomplète. La question utile, c'est "est-ce que cet outil expose dans son API la fonction dont j'ai besoin ?". Et cette question, tu peux maintenant aller la vérifier toi-même, dans la documentation, avant de choisir un outil ou de construire quelque chose autour.
Ce que ça change pour toi, maintenant
Tu peux relire autrement les pages marketing des outils que tu utilises.
"Disponible via API" signifie : tu peux demander à un autre programme de l'utiliser à ta place, de façon automatisée. Pas juste toi, à la main, dans l'interface. Un autre programme, qui peut lui-même être déclenché par quelque chose d'autre.
"API complète" ou "API ouverte" signifie en général que l'éditeur a fait le choix d'exposer une bonne partie de ses fonctionnalités, pas juste quelques opérations de base. C'est un signal sur la philosophie de l'outil.
Et quand une automatisation que tu essaies de construire bloque, la première question à poser n'est pas "est-ce que je fais une erreur ?" mais "est-ce que l'outil expose ce dont j'ai besoin dans son menu ?". Souvent, la limite n'est pas technique. Elle est fonctionnelle. Le plat n'est pas au menu.
J'ai passé un moment à croire que les blocages dans mes projets d'automatisation venaient de mes lacunes techniques. Certains, oui. Mais une bonne partie venaient de là : des outils qui n'avaient pas rendu accessibles les fonctions que je voulais utiliser. Comprendre ça m'a évité beaucoup de temps perdu à chercher une solution technique à un problème qui n'en avait pas.
À l'article 13, on verra les MCP. C'est un mécanisme qui permet à Claude d'utiliser ces menus en langage naturel, sans qu'on ait à rédiger les commandes soi-même. Tu lui dis ce que tu veux faire, il consulte le menu et passe la commande. Mais pour comprendre pourquoi c'est intéressant, il fallait d'abord savoir ce qu'est un menu.