MCP et les API sont souvent présentés comme des rivaux, alors qu’ils se situent à des couches différentes d’une pile d’IA. Cet article montre comment fonctionne chacun, ce qui les distingue pour la liste des outils, l’état et la sécurité, exécute la même tâche d’image des deux façons, et se termine par une courte liste de contrôle pour choisir.
Vous avez construit une intégration avec une API REST le trimestre dernier, et elle fonctionne parfaitement. Puis un collègue affirme que l’assistant devrait « simplement utiliser MCP », et voilà que la même tâche porte deux noms et oppose deux camps aux avis tranchés. Voici la version courte : une API est une porte d’entrée vers un service, et MCP est une norme qui permet à un modèle d’IA de trouver cette porte, de lire l’indication qui y figure et de la franchir sans câblage sur mesure. Les deux ne sont pas rivaux. Dans la plupart des architectures réelles, l’un repose directement sur l’autre.
Cet article détaille la différence en termes simples, exécute la même tâche de deux façons avec de vrais endpoints et outils de Picasso IA, et se termine par une courte liste de contrôle que vous pouvez appliquer en deux minutes. Si vous livrez des logiciels qui appellent des services, si vous créez des agents ou si vous intégrez un assistant à votre propre produit, le choix entre les deux se posera plus tôt que vous ne le pensez.
Le problème que MCP a été conçu pour supprimer est facile à imaginer. Chaque application d’IA a sa propre façon d’appeler des outils, et chaque service a sa propre API, si bien que chaque couple devient un travail sur mesure. C’est la baie de câblage ci-dessous : elle fonctionne, jusqu’au jour où quelqu’un doit la modifier.
Une API (interface de programmation d’application) est un contrat entre deux programmes. L’un envoie une requête dans une forme convenue, l’autre renvoie une réponse dans une forme convenue. Sur le web, cela passe presque toujours par HTTP et JSON : vous appelez une URL, vous joignez un token secret dans un en-tête, vous envoyez un corps de requête et vous lisez ce qui revient.
Chaque appel suit le même rythme. Votre code construit la requête, le serveur effectue le travail, puis le serveur répond. Rien dans ce contrat n’indique à l’appelant ce que le serveur peut faire d’autre. Vous le découvrez en lisant une documentation écrite pour des humains, puis vous écrivez du code qui s’y conforme.
Pensez au passe d’une cuisine de restaurant. Le bon de commande a un format fixe, le plat ressort toujours par le même passe-plat, et le serveur connaît la carte parce qu’on lui a remis une copie imprimée. Cette carte imprimée, c’est votre documentation d’API. Le serveur, c’est votre code, qui l’a mémorisée à l’avance.
De nombreux services de génération d’images et de vidéos ajoutent une étape supplémentaire. Ils fonctionnent de manière asynchrone : vous créez une tâche, vous obtenez immédiatement un ID, puis vous interrogez le service jusqu’à ce que le résultat soit prêt. L’API de Picasso IA fonctionne exactement ainsi : créer une prédiction, l’interroger, récupérer la sortie.
Les API ont gagné leur place pour de bonnes raisons :
💡 Lorsque l’appelant est un programme que vous avez écrit et que les étapes ne changent jamais, une API suffit. Ajouter une couche supplémentaire n’ajoute que des pièces mobiles.
MCP signifie Model Context Protocol. Anthropic l’a présenté fin 2024 comme une norme ouverte, et d’autres grands éditeurs d’IA l’ont adopté depuis. Son rôle est précis : définir une manière commune pour une application d’IA de communiquer avec des outils et des données externes, afin que personne n’ait à écrire un connecteur sur mesure pour chaque couple modèle-service.
Imaginez un adaptateur de voyage universel. Sans lui, chaque appareil a besoin de sa propre fiche pour chaque pays. Avec lui, il existe une seule norme de votre côté, une seule norme au mur, et tout se recharge. MCP joue ce rôle entre les applications d’IA et les services. Le calcul explique sa diffusion : cinq applications d’IA et dix services pourraient nécessiter jusqu’à cinquante intégrations sur mesure, alors qu’un protocole partagé demande à chaque côté de le mettre en œuvre une seule fois, soit quinze éléments de travail.
MCP définit trois rôles :
Les messages circulent en JSON-RPC 2.0. Une session s’ouvre par une poignée de main initialize, au cours de laquelle les deux côtés déclarent ce qu’ils prennent en charge. C’est pourquoi MCP est avec état, alors qu’un appel REST classique ne l’est pas.
Un serveur peut proposer trois types d’éléments :
| Primitive | Ce que c’est | Qui le déclenche | Exemple |
|---|---|---|---|
| Outils | Actions que le modèle peut appeler | Le modèle | Générer une image |
| Ressources | Données en lecture seule que l’application peut charger | L’application ou l’utilisateur | Une liste des générations passées |
| Prompts | Modèles réutilisables | L’utilisateur | Un modèle de prompt pour photo de produit |
Les outils attirent le plus d’attention, et ce sont eux qui comptent pour cette comparaison.
Voici la fonctionnalité qui sépare réellement MCP d’une API classique : le client peut demander au serveur ce qu’il propose. Une requête tools/list renvoie chaque outil avec un nom, une description en langage courant et un JSON Schema pour ses entrées. Le modèle lit ces descriptions et décide quel outil convient à la demande.
C’est comme ouvrir le fichier de la bibliothèque au lieu de mémoriser les rayonnages. Si le serveur ajoute demain un outil, le modèle le voit dès la session suivante, et le client n’a besoin d’aucune modification de code. Avec une API classique, un nouveau endpoint signifie que quelqu’un lit le journal des modifications, modifie le code et livre une nouvelle version.
| Aspect | API traditionnelle | MCP |
|---|---|---|
| Appelant principal | Le code d’un développeur | Un modèle d’IA via une application hôte |
| Contrat rédigé pour | Les humains et les générateurs de SDK | Les modèles et les applications hôtes |
| Découverte des capacités | Lire la doc, écrire le code | Interroger le serveur avec tools/list |
| Protocole | Celui choisi par le service (REST, GraphQL, gRPC) | Une norme unique, JSON-RPC 2.0 |
| État | Généralement sans état | Session avec état après une poignée de main |
| Quand le serveur change | Le code client doit être mis à jour | Le client voit les nouveaux outils à la session suivante |
| Qui décide de l’appel suivant | Votre code | Le modèle, avec validation humaine facultative |
| Usage idéal | Backends, tâches par lots, applications mobiles et web | Assistants, agents et éditeurs dotés de nombreux outils |
Trois éléments les distinguent : qui décide, comment les capacités sont décrites et où se trouve l’état. Avec une API, votre code décide de chaque étape. Avec MCP, un modèle décide à l’exécution, à partir des descriptions d’outils qu’on lui a fournies. Cela rend MCP flexible, mais aussi moins prévisible, ce qui compte lorsqu’une exécution doit produire le même résultat à chaque fois.
Le modèle qui prend ces décisions est un grand modèle de langage, par exemple Claude Sonnet 5 ou GPT 5.6 Sol, tous deux disponibles sur Picasso IA. Les modèles plus performants choisissent plus souvent le bon outil, mais ils lisent tout de même les descriptions, si bien que des descriptions vagues entraînent de mauvais appels.
La plupart des serveurs MCP sont de simples enveloppes autour d’une API. Le serveur transforme la tools/call d’un modèle en une requête HTTP ordinaire, attend la réponse et la renvoie. La vraie question n’est donc presque jamais « MCP ou API ». Elle est plutôt « qui appelle : mon code ou un modèle ? »
💡 Règle de base : si vous pouvez écrire à l’avance la séquence exacte d’appels, utilisez l’API. Si la séquence dépend de ce que le modèle décide en cours de conversation, utilisez MCP.
Les deux exemples accomplissent la même tâche : générer une photo 16:9 à partir d’un prompt texte sur Picasso IA.
L’URL de base est https://api.picassoia.com/v1, et chaque requête transporte un Bearer token qui commence par pia_sk_. Les endpoints suivent le style de Replicate : créer une prédiction, puis l’interroger.
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": "Photo of a hotel concierge handing a city map to a guest, 50mm, soft window light", "aspect_ratio": "16:9"}}'
La réponse contient un ID de prédiction. Votre code appelle ensuite GET /v1/predictions/{id} à intervalles réguliers, jusqu’à la fin de la tâche, puis lit l’URL de la sortie. Vous gérez l’URL, les en-têtes, la boucle de polling, les relances et les délais d’expiration. C’est le prix du contrôle total, et pour un traitement par lots nocturne, c’est exactement ce qu’il vous faut.
Une application hôte dotée du connecteur Picasso IA s’épargne toute cette plomberie. Après la poignée de main, elle demande tools/list, et le serveur répond avec des outils de génération d’images, de modification, de vidéo et de vérification du statut. Lorsqu’une personne tape « Faites-moi une photo 16:9 d’un concierge d’hôtel », le modèle choisit generate_image et le client envoie :
{
"jsonrpc": "2.0",
"id": 7,
"method": "tools/call",
"params": {
"name": "generate_image",
"arguments": {
"prompt": "Photo of a hotel concierge handing a city map to a guest, 50mm, soft window light",
"aspect_ratio": "16:9"
}
}
}
Le serveur répond avec un ID et une indication sur le moment où vérifier à nouveau. Le modèle appelle ensuite get_generation avec cet ID jusqu’à ce que le statut indique succeeded. Personne n’a écrit de boucle de polling : ce sont les descriptions des outils qui ont indiqué au modèle comment se comporter.
Le connecteur Picasso IA liste des outils tels que generate_image, edit_image, generate_video_picassoia, generate_video_seedance, get_generation, list_generations, cancel_generation, list_models et get_account. Chacun arrive avec une description et un schéma d’entrée. Cela permet à un modèle de les enchaîner sans qu’un développeur écrive l’ordre dans un script : générer une ébauche d’image, examiner le résultat, demander une modification, puis animer la meilleure version.
Les deux voies mènent au même service. Le bon choix dépend de la personne qui marche.
Le concierge d’hôtel est l’image mentale qui convient. Le client dit ce qu’il veut en langage courant, et le concierge, qui connaît chaque service de l’établissement, choisit le bon. C’est le mode MCP : vous exprimez l’intention, et le choix de l’outil est pris en charge pour vous.
La plupart des architectures matures utilisent les deux. Le serveur MCP appelle l’API sous-jacente, et un script nocturne sollicite directement cette même API. Un seul backend, deux portes d’entrée. Un designer demande à un assistant, via MCP, trois visuels principaux, en choisit un, puis une tâche planifiée redimensionne ensuite le gagnant en douze formats via l’API.
Une démarche pragmatique : commencez par l’API, car elle est plus simple à tester et vous en aurez de toute façon besoin. Dès qu’un assistant doit utiliser la même fonctionnalité, encapsulez les appels dans un serveur MCP et donnez à chaque outil une description courte et concrète, accompagnée d’exemples d’entrées. Passez cette couche si personne d’autre que votre propre code n’appellera jamais le service. Un outil qu’aucun modèle n’utilisera ne fait qu’ajouter de la surface à maintenir.
Appliquez cette liste de contrôle avant de construire quoi que ce soit :
Les deux voies nécessitent une authentification, mais elle se situe à des endroits différents. Un appel API transporte un Bearer token dans l’en-tête de chaque requête. Les tokens Picasso IA commencent par pia_sk_, et un compte peut en détenir deux au maximum. Avec MCP, l’hôte garde la connexion ouverte, et les serveurs distants s’authentifient généralement une seule fois par session, via un flux de type OAuth.
Deux habitudes vous protègent sur l’une comme l’autre voie :
MCP ne supprime pas les limites, car les deux voies aboutissent au même backend. Picasso IA applique les limites suivantes à ses connexions API et MCP :
| Limite | Valeur |
|---|---|
| Prédictions simultanées | 5 par compte, partagées entre les tokens et 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 |
Cinq agents sur MCP plus un script API nocturne se partagent les mêmes cinq emplacements. Anticipez-le avant de lancer un traitement par lots.
Il existe un autre coût facile à négliger. MCP place les noms, descriptions et schémas des outils dans la fenêtre de contexte du modèle, si bien qu’un serveur doté de dizaines d’outils consomme des tokens avant même que l’utilisateur ait dit un mot. Limitez le nombre de serveurs connectés et gardez-les ciblés. Pour les conditions d’accès actuelles aux connexions API et MCP, consultez la page de tarifs Picasso IA, car les offres évoluent.
PicassoIA Image est un modèle texte vers image qui fonctionne via le site web, l’API et le connecteur MCP. Voici le chemin le plus rapide pour passer de zéro à une image finie.
curl vue plus haut.Conseils sur les paramètres de PicassoIA Image :
aspect_ratio accepte sept valeurs : 1:1, 16:9, 9:16, 4:3, 3:4, 3:2 et 2:3. Utilisez 16:9 pour les en-têtes de blog et 9:16 pour les stories.seed fige un résultat. Réutilisez le même prompt et la même seed pour reproduire une image à l’identique.num_outputs accepte 1 ou 2, ce qui vous permet de comparer deux variantes en un seul appel.output_format prend en charge jpg, png et webp, et output_quality (de 0 à 100) s’applique aux formats jpg et webp.💡 Les deux voies donnent accès aux mêmes quatre modèles et aux mêmes cinq emplacements simultanés. Construisez d’abord un prompt dans le navigateur, puis transférez-le vers du code ou vers un assistant.
Le moyen le plus rapide de percevoir la différence est de lancer deux fois le même prompt. Générez une image sur le site, envoyez le même prompt depuis un court script via l’API, puis demandez à un assistant équipé du connecteur de la créer pour vous. Observez ce que vous contrôlez dans chaque version et ce que vous déléguez.
Ouvrez Picasso IA, commencez par PicassoIA Image, et transformez votre meilleur résultat en courte vidéo avec PicassoIA Video. Modifiez le format, figez une seed, essayez un second prompt, et voyez quelle voie correspond à votre façon de travailler. Les modèles sont à un clic, et chaque expérience vous apprendra davantage sur MCP et les API qu’un nouveau tableau comparatif.
Choisissez votre langue
