À l'article 9, 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 9, 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
Quand on ouvre une documentation d'API pour la première fois, on s'attend à quelque chose d'ésotérique. Plein de termes qu'on ne connaît pas, organisé pour des développeurs et incompréhensible pour le reste du monde.
La doc HubSpot, c'est 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, on ne sait pas 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.
Ce qui ressort, c'est que 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
La documentation d'Anthropic, la société qui développe Claude, suit la même logique. Quand Claude Code génère du code, il appelle lui-même Claude via cette doc.
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.
Pour rendre ça concret : quand Claude Code 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 9. 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.
On a longtemps tendance à croire qu'une API c'est quelque chose de technique au sens mystérieux du terme, quelque chose qui appartient aux développeurs et dont on n'a pas à se préoccuper. C'est juste un contrat entre deux programmes : voilà ce que tu peux demander, voilà ce que tu reçois en retour.
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.
Ça arrive plus souvent qu'on ne le pense. Tu veux connecter deux outils que tu utilises au quotidien. L'un a une API bien documentée. L'autre a une API, mais quand tu cherches l'opération dont tu as besoin, elle n'y est pas. L'outil permet de faire la chose dans son interface, à la main. Mais il n'a pas choisi d'exposer cette fonction à d'autres programmes.
Résultat : l'automatisation que tu voulais construire est impossible, peu importe ton niveau technique. Ce n'est pas un problème de compétence. C'est un problème de menu : le plat n'est 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.
On a tendance à croire que les blocages dans nos projets d'automatisation viennent de nos lacunes techniques. Parfois oui. Mais une bonne partie viennent de là : des outils qui n'ont pas rendu accessibles les fonctions qu'on voulait utiliser. Le savoir évite beaucoup de temps perdu à chercher une solution technique à un problème qui n'en a pas.
À l'article 15, 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.