MCP et les API ne résolvent pas les mêmes problèmes. Cet article montre où le Model Context Protocol fait vraiment gagner du temps, où une API directe est plus rapide et moins chère, et comment PicassoIA propose les deux, avec une checklist de décision, des exemples concrets et les limites à respecter.
Votre assistant peut écrire un sonnet en quelques secondes, mais il ne peut pas réserver une réunion, consulter les ventes de la veille ou générer une photo de produit tant que rien ne le relie à ces systèmes. Pendant des années, ce « quelque chose » était une API accompagnée d’une montagne de code de liaison sur mesure. Puis le Model Context Protocol (MCP), un standard ouvert présenté par Anthropic en novembre 2024, a donné aux applications d’IA une manière commune de se connecter à des outils externes. Une question légitime en découle : pourquoi utiliser MCP plutôt qu’une API ? La réponse honnête dépend de qui effectue l’appel. Lorsque votre code appelle un service, une API classique est difficile à battre. Lorsqu’un modèle d’IA décide à l’exécution quel service appeler, MCP supprime une quantité surprenante de travail. Vous trouverez ci-dessous les avantages, les limites et des exemples concrets, y compris la façon dont PicassoIA propose à la fois une API et un connecteur MCP, afin que vous choisissiez la bonne porte pour votre prochain projet.
MCP définit la façon dont une application d’IA, appelée le client, communique avec un programme externe, appelé le serveur, qui propose des capacités. Les messages utilisent JSON-RPC 2.0, et les deux modes de transport courants sont stdio pour les serveurs locaux et Streamable HTTP pour les serveurs distants. Un serveur peut exposer trois types d’éléments :
generate_image ou create_invoice.Avant tout appel, le client demande au serveur ce qu’il propose grâce à une requête tools/list, et reçoit le nom, la description et le schéma d’entrée de chaque outil. Le modèle lit ces descriptions, choisit un outil et remplit les arguments. C’est toute l’astuce : l’interface se décrit elle-même dans un langage sur lequel un modèle peut agir.
Une API est un contrat écrit pour un développeur. Vous lisez la documentation, écrivez la requête, gérez la réponse et livrez le code. Un serveur MCP est un contrat écrit à la fois pour un modèle et pour un développeur. Sous le capot, la plupart des serveurs MCP appellent tout de même une API classique. MCP se place au-dessus de l’API, et non à sa place.
💡 Confusion fréquente : MCP ne remplace pas REST ou GraphQL. C’est une couche de liaison standard qui permet à un client d’IA d’utiliser ces services sans nouvelle intégration sur mesure pour chaque application.
| Question | API directe | Serveur MCP |
|---|---|---|
| Qui décide quand appeler ? | Votre code | Le modèle d’IA |
| Comment est-il décrit ? | Documentation pour les humains, fichier OpenAPI facultatif | Outils auto-décrits avec schémas |
| Travail par nouvelle application d’IA | Une nouvelle intégration à chaque fois | Un seul serveur, réutilisé par tous les clients MCP |
| Idéal pour | Des tâches prévisibles et répétables | Des tâches ouvertes et conversationnelles |
| En cas d’échec | Vous écrivez la logique de nouvelle tentative | Le modèle lit l’erreur et s’adapte |
| Coût typique par tâche | L’appel lui-même | L’appel plus les tokens du modèle |
Pensez à un restaurant. Un appel d’API direct, c’est aller vous-même au passe-plat, commander avec le code exact du plat et porter l’assiette jusqu’à la table. MCP, c’est le serveur de restaurant qui lit la carte, écoute ce que vous voulez vraiment et vous l’apporte. La cuisine est la même dans les deux cas. Ce qui change, c’est qui fait la traduction.
Sans standard commun, chaque application d’IA a besoin de sa propre intégration pour chaque service, si bien que le travail croît comme le nombre d’applications multiplié par le nombre de services. Avec MCP, chaque service livre un serveur et chaque application livre un client, si bien que le travail croît comme la somme des applications et des services. Une équipe qui construit un serveur MCP une seule fois peut l’utiliser depuis un assistant de discussion, un éditeur de code et un agent d’automatisation sans réécrire une seule ligne. Pour un éditeur, cela signifie un connecteur au lieu d’une douzaine de plug-ins. Pour un utilisateur, cela signifie que l’outil qu’il paie déjà apparaît tout simplement dans l’assistant qu’il utilise déjà.
Les API classiques cachent l’intention dans la documentation. Un fichier OpenAPI liste les points de terminaison, mais un modèle a tout de même besoin d’un wrapper pour transformer « rends l’image principale plus sombre » en la bonne requête. Les descriptions d’outils MCP sont écrites pour le modèle lui-même, qui peut donc choisir entre generate_image et edit_image, demander à l’utilisateur un détail manquant ou réessayer après un message d’erreur clair.
Voici ce que cela représente concrètement :
Quand un éditeur renomme un champ ou ajoute un paramètre, les mainteneurs du serveur le corrigent une fois et chaque client continue de fonctionner. Comparez avec cinq scripts internes, chacun appelant le même point de terminaison d’une façon légèrement différente, chacun cassant un jour différent. Les équipes qui transfèrent des flux répétés du type « demande à l’assistant de faire X » vers un serveur partagé constatent souvent que la liste de maintenance diminue en premier, bien avant que le gain de vitesse n’apparaisse.
💡 Règle empirique : si une personne exprime ce qu’elle veut en langage courant et que l’assistant choisit les étapes, MCP fait gagner du temps. Si un développeur connaît déjà les étapes exactes, un appel d’API direct est plus simple.
Les rapports nocturnes, 10 000 vignettes de produits, un webhook qui se déclenche dès qu’un paiement est validé : aucun de ces cas ne nécessite qu’un modèle décide de quoi que ce soit. Un appel d’API direct est plus rapide (un seul saut au lieu d’un aller-retour avec le modèle), moins coûteux (aucun token dépensé en raisonnement) et répétable (la même entrée mène au même appel à chaque fois). Dans un script, vous contrôlez aussi les lots, les nouvelles tentatives, les temporisations et les limites de débit jusqu’à la dernière ligne.
Chaque serveur MCP connecté ajoute ses définitions d’outils à la fenêtre de contexte du modèle. Dix serveurs comptant chacun trente outils peuvent consommer des milliers de tokens avant que l’utilisateur ne tape un mot, et un menu plus long donne au modèle davantage de façons de choisir le mauvais outil. Ces limites sont réelles :
💡 Solution simple : connectez uniquement les serveurs dont une tâche a besoin, gardez chaque liste d’outils courte et rédigez des descriptions précises. Un modèle avec six outils clairs fait mieux qu’un modèle avec soixante outils flous.
Un designer demande à un assistant : « donne-moi une photo d’en-tête au format 16:9 d’un studio éclairé par le soleil, puis rends la lumière plus chaude. » Avec un connecteur MCP, l’assistant liste les outils disponibles, appelle un outil de génération d’images, reçoit immédiatement un identifiant de tâche et interroge le serveur jusqu’à la fin du rendu. Puis il appelle un outil de retouche sur le résultat. Aucun développeur n’a écrit ce déroulement, car le modèle l’a assemblé à partir des descriptions d’outils. Avec une API directe, un développeur écrirait une fois la même séquence sous forme de code et l’attacherait à un bouton. Les deux fonctionnent, mais une seule permet au designer de modifier le plan en cours de phrase.
Une équipe de blog connecte un assistant à trois serveurs : un générateur d’images, une base d’articles et un espace de stockage de fichiers. Pour chaque article, l’assistant vérifie que le slug est libre, génère les images, les importe et enregistre l’article finalisé. Chaque étape est un appel d’outil au sein d’une même conversation. Un script pourrait faire la même chose, ce qui est parfait lorsque les étapes ne changent jamais. Cela devient pénible lorsque chaque article demande un mélange d’étapes différent, et c’est là que le jugement du modèle justifie son coût en tokens.
Une boutique en ligne doit remplacer pendant la nuit 2 000 arrière-plans de produits. Un court script boucle sur l’API avec un pool de workers, respecte la limite de concurrence, relance les échecs et rédige un rapport. Il n’y a aucun modèle dans la boucle, aucune facture de tokens et le même résultat chaque nuit. Placer MCP devant ce travail ajouterait du coût et de la variabilité sans aucun gain.
PicassoIA propose les deux portes vers les mêmes quatre modèles : PicassoIA Image, PicassoIA Image Editor Pro, PicassoIA Video et Seedance 2.5 Lite, un modèle vidéo avec audio. Le choix de la porte dépend de qui effectue l’appel.
L’API est accessible à https://api.picassoia.com/v1 et utilise un token Bearer qui commence par pia_sk_. Les points de terminaison suivent le style Replicate bien connu, et chaque tâche est asynchrone : vous créez une prédiction, vous l’interrogez, puis vous récupérez le résultat.
# 1. Create a prediction
curl -X POST https://api.picassoia.com/v1/models/picassoia/picassoia-image/predictions \
-H "Authorization: Bearer $PICASSOIA_TOKEN" \
-H "Content-Type: application/json" \
-d '{"input": {"prompt": "A sunlit loft studio, 85mm, natural light"}}'
# 2. Poll until the status is "succeeded"
curl https://api.picassoia.com/v1/predictions/PREDICTION_ID \
-H "Authorization: Bearer $PICASSOIA_TOKEN"
Deux autres points de terminaison permettent d’annuler une tâche (POST /v1/predictions/{id}/cancel) et de lister vos tâches (GET /v1/predictions). Consultez la documentation de l’API pour les champs d’entrée exacts de chaque modèle avant de vous appuyer sur l’exemple ci-dessus.
Le connecteur met à la disposition d’un assistant un petit ensemble d’outils prêts à l’emploi pour les mêmes modèles : generate_image, edit_image, generate_video_picassoia, generate_video_seedance, get_generation, list_generations, list_models, get_account et cancel_generation. Les outils de génération renvoient un identifiant de prédiction dès qu’un GPU accepte la tâche. L’assistant attend ensuite et appelle get_generation jusqu’à ce que le statut affiche succeeded, puis vous montre l’URL de l’image ou de la vidéo. Vous n’écrivez jamais la boucle d’interrogation. Les connexions se gèrent depuis la page MCP de votre compte sur picassoia.com/en/mcp/accounts, ce qui nécessite une connexion.
Les deux portes partagent les mêmes limites :
| Limite | Valeur |
|---|---|
| Prédictions simultanées | 5 par compte, partagées entre tous les tokens et toutes les connexions MCP |
| Corps de requête | 10 Mo |
| Longueur du prompt | 4 000 caractères |
| Délai d’expiration d’une tâche | 3 heures |
| Tokens secrets | Jusqu’à 2 par compte |
💡 Note sur le budget : l’accès à l’API et aux connexions MCP dépend de votre forfait. Consultez la page tarifaire pour les conditions en vigueur avant de planifier vos volumes.
list_models.generate_image avec PicassoIA Image et reçoit un identifiant de prédiction.get_generation et renvoie l’URL de l’image dès que le statut est succeeded.
Avec une API directe, votre backend détient un token secret, et quiconque peut atteindre ce backend peut l’utiliser. Avec un serveur MCP distant, l’utilisateur approuve généralement l’accès une seule fois via OAuth, et l’assistant agit en son nom, ce qui garde les secrets hors des prompts et des journaux de discussion. Le compromis est un nouveau risque : un outil que l’assistant peut appeler est un outil qu’une page web ou un document malveillant peut tenter de lui faire appeler. C’est ce qu’on appelle l’injection de prompt, et l’habitude la plus sûre consiste à traiter tout ce que renvoie un outil comme une entrée non fiable.
Utilisez cette courte liste la prochaine fois que quelqu’un demande s’il faut construire un serveur MCP ou appeler directement l’API.
| Votre situation | Meilleur choix |
|---|---|
| Une personne demande en langage courant et les étapes varient | MCP |
| Une seule intégration doit fonctionner dans de nombreuses applications d’IA | MCP |
| Une tâche planifiée exécute les mêmes étapes à chaque fois | API directe |
| Vous avez besoin d’un contrôle précis des nouvelles tentatives et des lots | API directe |
| Des milliers d’appels où les tokens du modèle domineraient le coût | API directe |
| Un assistant interne plus une automatisation nocturne | Les deux |
La plupart des équipes expérimentées finissent par utiliser les deux : un serveur MCP pour les personnes et les agents, et des appels d’API directs pour les tâches planifiées. Le serveur MCP appelle généralement la même API en dessous, si bien que rien n’est construit deux fois. En bref, MCP n’est pas une meilleure API. C’est une meilleure porte d’entrée vers les modèles.
Lire sur les protocoles ne suffit pas. La façon la plus rapide de sentir la différence est de suivre les deux chemins avec un même prompt. Ouvrez PicassoIA, générez une photo avec PicassoIA Image, puis reprenez le même prompt via une connexion MCP et observez l’assistant gérer l’interrogation à votre place. Vous voulez un second regard sur votre prompt ? Demandez à un grand modèle de langage comme Claude Sonnet 5 ou Gemini 3.5 Flash de le resserrer avant le rendu. Affinez le résultat dans PicassoIA Image Editor Pro et animez-le avec Seedance 2.5 Lite. Parcourez tous les modèles sur picassoia.com/en/all-models et commencez dès aujourd’hui à créer vos propres images avec PicassoIA.
Choisissez votre langue
