Vous utilisez déjà les trois sans le savoir

La semaine dernière, un client m'a demandé pourquoi il avait besoin d'une "API" alors qu'il utilisait déjà Zapier. La semaine d'avant, un autre voulait savoir ce qu'était un "MCP server" après avoir lu un article sur Claude. Et la question que je reçois le plus souvent : "c'est quoi la différence entre un CLI et une API ?"

La réalité, c'est que vous utilisez déjà ces trois concepts tous les jours. Quand vous tapez `git push` dans votre terminal, vous utilisez un CLI. Quand votre Calendly envoie automatiquement une notification dans Slack, c'est un appel API. Et quand Claude accède à votre CRM pour trouver les derniers leads signés, c'est du MCP. Trois mécanismes différents, trois façons de faire communiquer des outils entre eux. Et depuis l'arrivée des agents IA, comprendre la différence n'est plus optionnel — c'est devenu une compétence professionnelle de base.

API : le langage universel entre logiciels

Une API, c'est la façon dont deux logiciels se parlent sans qu'un humain ait besoin de cliquer sur quoi que ce soit. Imaginez un restaurant : vous (le client) passez commande au serveur (l'API), qui transmet à la cuisine (le serveur). Vous n'allez jamais dans la cuisine vous-même. L'API, c'est ce serveur — une interface qui transmet des requêtes et rapporte des réponses.

Pour rendre ça concret, prenons Optimzd, le SaaS que j'ai construit. La plateforme connecte l'API Meta Ads (qui envoie les données de campagnes publicitaires) à l'API HubSpot (qui envoie les données de deals signés). Un script Python fait le lien entre les deux pour montrer le vrai coût par client signé, pas par lead généré. Sans ces APIs, il faudrait exporter des CSV chaque matin, les croiser manuellement dans un tableur, et prier pour ne pas se tromper de colonne. C'est exactement ce que faisaient les équipes marketing avant — et c'est exactement le problème que les APIs résolvent.

Dans mon quotidien, j'utilise une dizaine d'APIs différentes. L'API Meta Marketing pour les données pub, l'API HubSpot pour le CRM, le Measurement Protocol de GA4 pour le tracking server-side, l'API Google Sheets pour les rapports automatisés. À chaque fois, le principe est le même : du code envoie une requête structurée à un serveur, et le serveur renvoie une réponse. Pas d'interface graphique, pas de clics, pas d'humain dans la boucle. C'est rapide, fiable, et ça tourne 24h/24.

Le point important à retenir : une API n'est pas un outil que vous "utilisez" directement. C'est une interface que du code utilise en votre nom. Cette distinction va devenir cruciale pour la suite.

CLI : la télécommande du développeur

Un CLI — Command Line Interface — c'est une interface textuelle où vous tapez des commandes pour contrôler un outil. Au lieu de naviguer dans des menus et de cliquer sur des boutons, vous écrivez ce que vous voulez et ça se fait. Pensez-y comme une télécommande : au lieu d'appuyer sur des boutons physiques, vous tapez le nom de l'action.

Dans mon workflow quotidien, le CLI est omniprésent. `vercel deploy` pour mettre un site en production en 30 secondes. `git push` pour envoyer du code. `npm run build` pour compiler un projet. Chacune de ces commandes remplace une série de clics dans une interface graphique — et ça va beaucoup plus vite. Quand je travaillais sur le site de Skello, c'est via le CLI Vercel que je déployais les mises à jour sur les 7 marchés européens. Un seul `vercel --prod` et c'est live partout.

Ce qui change aujourd'hui, c'est que les CLIs ne sont plus réservés aux développeurs. Claude Code, l'outil que j'utilise pour coder, est lui-même un CLI. Vous ouvrez un terminal, vous décrivez ce que vous voulez en français, et il écrit le code pour vous. C'est un CLI piloté en langage naturel. La barrière d'entrée n'a jamais été aussi basse.

La distinction fondamentale : un CLI parle à un humain. Vous tapez une commande, vous lisez la réponse. C'est interactif, direct, immédiat. Une API, elle, parle à du code. Aucun humain ne voit les requêtes passer. Gardez cette différence en tête — elle est au cœur de ce qui rend MCP si différent.

MCP : quand l'IA a besoin de ses propres APIs

Le MCP — Model Context Protocol — est le concept le plus récent et le plus mal compris des trois. Lancé par Anthropic fin 2024 et adopté depuis par OpenAI et Google, c'est un protocole standardisé qui permet aux agents IA de découvrir et utiliser des outils automatiquement.

La différence fondamentale, c'est la découverte automatique. Quand vous installez un MCP server — par exemple le serveur Vercel MCP ou le serveur HubSpot MCP — l'agent IA fait quelque chose de remarquable au démarrage : il envoie une requête `tools/list` au serveur, et celui-ci répond avec la liste complète de tout ce qu'il peut faire, avec la description de chaque outil et le format exact des paramètres attendus. L'agent lit ces descriptions et décide seul quel outil utiliser en fonction de votre demande.

Concrètement, dans mon setup Claude Code, j'ai des MCP servers connectés à Notion, Slack, Gmail, Google Calendar et Webflow. Quand je demande "envoie un message dans le channel #engineering", Claude ne me demande pas quel outil utiliser. Il sait que le MCP server Slack expose un outil `slack_send_message`, il connaît les paramètres nécessaires, et il l'appelle directement. Je n'ai jamais eu à lui expliquer comment fonctionne l'API Slack.

Avec un CLI classique, l'agent doit déjà connaître les commandes disponibles par son entraînement. Mais il y a une nuance importante : les CLIs modernes comme Claude Code ont développé leur propre mécanisme de découverte avec les skills. Un skill, c'est un fichier qui décrit une capacité — quand le déclencher, quoi faire, comment l'utiliser. Quand vous installez un skill, Claude Code le détecte automatiquement et sait quand l'activer sans que vous le lui disiez explicitement. C'est une forme de découverte, mais côté CLI. La différence avec MCP : les skills sont liés à un CLI spécifique (Claude Code), tandis que MCP est un protocole universel — n'importe quel agent IA peut s'y connecter.

Et pour être clair sur un point que beaucoup de gens confondent : MCP ne remplace pas les APIs. Un MCP server est construit au-dessus des APIs. Le serveur Vercel MCP appelle l'API REST de Vercel sous le capot. Le serveur Slack MCP appelle l'API Web de Slack. Ce que MCP fait, c'est supprimer le code glue entre l'agent IA et l'API. L'agent n'a plus besoin de connaître les endpoints, les headers d'authentification ou le format des requêtes. Le MCP server gère tout ça.

Le framework de décision : qui fait le travail ?

La question n'est jamais "quel concept est meilleur". La question, c'est : qui ou quoi exécute l'action ?

Si c'est un humain qui fait le travail de manière interactive, CLI. Vous tapez `vercel deploy`, vous regardez les logs, vous validez. C'est direct, rapide, et vous avez le contrôle total. Il faut connaître la commande, mais une fois apprise, c'est la méthode la plus efficace pour des actions ponctuelles.

Si c'est du code qui fait le travail automatiquement, API. Votre pipeline CI/CD appelle l'API Vercel à chaque push sur la branche main. Pas d'humain dans la boucle, ça tourne tout seul. C'est plus complexe à mettre en place, mais une fois configuré, c'est fiable et scalable.

Si c'est un agent IA qui fait le travail, MCP. Vous dites "déploie mon site en production" et l'agent découvre le MCP server Vercel, choisit l'outil approprié, et exécute le déploiement. Vous n'avez pas besoin de connaître la commande ni l'API — l'agent s'en charge.

Prenons un deuxième exemple avec HubSpot et le travail que je fais chez Skello. CLI : je tape `hubspot contacts list --limit 10` pour vérifier rapidement les derniers contacts. API : un workflow n8n appelle l'API HubSpot toutes les heures pour synchroniser les leads avec Salesforce automatiquement. MCP : je demande à Claude "trouve tous les leads allemands qui ont signé le mois dernier" et il interroge HubSpot via le MCP server, filtre les résultats, et me les présente. Trois approches, même base de données, trois niveaux d'automatisation différents.

En pratique, on utilise les trois. Le talent, c'est de savoir lequel sortir dans quel contexte. Utiliser une API quand un simple `git push` suffirait, c'est de la sur-ingénierie. Faire manuellement ce qui devrait tourner en automatique via une API, c'est du temps brûlé.

Ce que l'IA change vraiment dans l'équation

Il y a deux ans, ces trois concepts vivaient dans des mondes séparés. Les APIs étaient pour les développeurs backend. Les CLIs étaient pour les devops. Et MCP n'existait pas encore. Aujourd'hui, l'IA a fait exploser ces frontières.

Le changement le plus visible : les CLIs parlent maintenant en langage naturel. Claude Code est un CLI où je décris ce que je veux en français, et il écrit le code, exécute les commandes, et déploie les changements. Je ne mémorise plus les flags et les options — je décris l'intention et l'outil traduit. Chez Skello, construire une synchronisation HubSpot-Salesforce nécessitait qu'un développeur passe 2 à 3 jours à écrire du code d'intégration API. Aujourd'hui, avec Claude Code, on prototype la même chose en une après-midi.

Le changement le plus profond : les agents IA coexistent avec les deux mondes. Claude Code utilise les CLIs via le terminal — il connaît `git`, `npm`, `vercel` par son entraînement. ET il utilise les MCP tools via le protocole de découverte. Les deux coexistent dans le même agent. L'avantage du MCP : la découverte est formalisée, structurée, auto-documentée. L'avantage du CLI : la simplicité et l'universalité — n'importe quel outil en ligne de commande fonctionne sans qu'on ait besoin d'écrire un MCP server pour lui.

Et la confusion à éviter : MCP ne remplace ni les APIs, ni les CLIs. Il ajoute une couche d'abstraction spécifiquement conçue pour les agents IA. Les APIs font toujours le gros du travail sous le capot. Les CLIs restent le moyen le plus rapide pour un humain d'exécuter une action ponctuelle. MCP est la couche qui permet à un agent IA de naviguer entre ces outils sans qu'un humain ait besoin de lui tenir la main.

Par où commencer lundi matin

Si vous travaillez en marketing ou en ops et que tout ça vous semble lointain, commencez par les CLIs. Installez un terminal, tapez votre première commande. Ça peut être aussi simple que `npx create-next-app` pour créer un site ou `vercel deploy` pour le mettre en ligne. Le terminal démystifie tout le reste — une fois que vous êtes à l'aise avec une interface texte, les APIs et le MCP deviennent beaucoup moins intimidants.

Si vous êtes déjà à l'aise avec les CLIs, apprenez une API. L'API HubSpot ou l'API Google Sheets sont d'excellents points de départ. Construisez une petite automatisation avec n8n ou Python — un script qui récupère vos leads et les envoie dans un tableur, par exemple. Vous comprendrez en 2 heures ce que font réellement toutes les intégrations Zapier que vous payez chaque mois.

Et si vous utilisez déjà des APIs au quotidien, explorez MCP. Configurez Claude avec un MCP server pour un de vos outils (Notion, Slack, votre CRM). Observez comment l'agent découvre les outils et décide seul lequel utiliser. C'est le moment où la magie opère — quand vous réalisez que l'IA ne se contente plus de répondre à vos questions, elle agit sur vos outils.

Le but n'est pas de devenir développeur. Le but, c'est d'arrêter d'être bloqué par des choses que vous pourriez automatiser ou déléguer à un agent IA. API, MCP, CLI — ce sont les trois briques de base. Vous les utilisez déjà sans le savoir. Maintenant, vous savez lesquels sortir en premier.

Si vous voulez savoir lequel de ces trois concepts débloquerait le plus de valeur dans votre stack actuelle, on peut en parler.