La réponse courte
Choisissez une intégration API directe lorsque les étapes sont connues à l’avance : le même déclencheur, les mêmes appels et les mêmes contrôles à chaque fois. Envisagez MCP lorsque vos équipes travaillent avec un assistant IA et que vous voulez qu’il choisisse parmi un petit nombre d’outils exposés délibérément.
Beaucoup de systèmes utiles combinent les deux : du code API fixe et testé pour tout ce qui écrit des données ou engage de l’argent, et quelques outils en lecture seule pour un assistant qui répond aux questions.
| Question | Intégration API directe | Outils MCP pour un assistant |
|---|---|---|
| Qui décide de l’étape suivante ? | Votre code, dans un ordre fixe | Le modèle, parmi les outils exposés |
| Usage le plus adapté | Workflows répétables aux étapes connues | Questions variées dans un assistant |
| Tests | Chaque chemin peut être testé unitairement | Jeux d’évaluation sur le choix d’outil et les paramètres |
| Écritures sensibles | Étape d’approbation intégrée au flux | Approbation exigée avant l’exécution de l’outil |
| Données exposées | Uniquement les champs envoyés par votre code | Tout ce que les outils exposés renvoient au modèle |
| Évolution | Les changements arrivent avec votre code | Un outil ajouté ou modifié change ce que l’assistant peut faire |
API directe : votre code décide des étapes
Dans une intégration directe, un webhook, une planification ou un bouton lance un workflow que vous avez écrit. Le modèle peut classer un message ou rédiger un texte, mais c’est votre code qui décide quel système appeler, avec quels champs, et que faire en cas d’erreur.
C’est généralement plus simple à tester, à auditer et à tenir dans un budget, car chaque chemin est visible dans le code. C’est le choix naturel pour la mise à jour de commandes, l’extraction de documents, la synchronisation CRM et tout ce qui comporte une étape d’approbation fixe.
MCP : l’assistant choisit parmi les outils exposés
Avec MCP, un serveur publie des outils comme « rechercher dans l’aide » ou « consulter le statut d’une commande ». Un assistant connecté à ce serveur peut décider, pendant la conversation, quel outil appeler et avec quels paramètres.
Cette souplesse aide lorsque les questions varient et que l’assistant doit combiner des informations. Mais c’est alors le modèle, et non votre code, qui choisit l’étape suivante : la liste des outils, leurs permissions et leurs règles d’approbation comptent davantage. Le guide d’OpenAI sur les connecteurs et serveurs MCP distants décrit comment limiter les outils disponibles et exiger une approbation avant un appel, et rappelle qu’un serveur distant est un tiers qui reçoit les données envoyées.
Questions de sécurité, quelle que soit l’option
Ces points s’appliquent aussi bien à une intégration directe qu’à un serveur MCP.
- Authentification et moindre privilège : chaque intégration a ses propres identifiants, avec les droits les plus étroits possibles. Un assistant qui agit pour un utilisateur ne doit atteindre que les données de cet utilisateur.
- Contenu non fiable : e-mails, documents, pages web et résultats d’outils peuvent contenir des instructions. Traitez-les comme des données, jamais comme une autorisation d’agir.
- Approbation avant les écritures sensibles : remboursements, paiements, suppressions, messages sortants et modifications d’enregistrements attendent la confirmation d’une personne, ou restent hors de portée de l’assistant.
- Exposition des données, journaux et conservation : décidez quels champs quittent votre système, ce qui est journalisé, qui peut lire les journaux et combien de temps ils sont conservés, y compris chez le fournisseur de modèle et tout serveur tiers.
Fiabilité : évaluation, doublons et erreurs
Écrivez des cas d’évaluation avant le développement : des demandes réelles avec les appels d’outils et les résultats attendus, y compris les demandes que le système doit refuser. Rejouez-les à chaque changement d’instructions, de modèle ou d’outil.
- Une sortie structurée conforme au schéma peut contenir des valeurs fausses : validez-les dans le code.
- Rendez les écritures idempotentes : une nouvelle tentative ou un appel répété ne doit pas créer deux fois le même ticket ou la même facture.
- Prévoyez les délais dépassés et les appels en échec : un repli clair pour l’utilisateur et assez de contexte journalisé pour rejouer sans risque.
- Des réponses fondées sur vos fichiers, avec citations, sont plus faciles à vérifier, mais les citations ne garantissent pas l’exactitude.
Entreprise et données fictives, à titre d’illustration uniquement.
Un exemple fictif
L’équipe support d’un distributeur reçoit plusieurs fois par jour la même question : « Où en est ma commande, et pouvez-vous changer l’adresse de livraison ? »
Version API directe
- Un message arrive via le webhook de la boîte support.
- Le code extrait le numéro de commande et vérifie que l’expéditeur en est bien le titulaire.
- Le code appelle l’API du système de commandes pour obtenir le statut et prépare une réponse à partir d’un modèle.
- Un changement d’adresse crée une demande qu’un membre de l’équipe approuve avant l’envoi au transporteur.
Version MCP
- Un agent du support interroge l’assistant interne sur la commande du client.
- L’assistant peut appeler deux outils en lecture seule : statut de commande et recherche dans les articles d’aide.
- Un troisième outil, « demander un changement d’adresse », existe mais exige l’approbation de l’agent avant de s’exécuter.
- Les appels d’outils et les approbations sont journalisés ; aucun outil ne peut rembourser ni modifier une facture.
Les deux versions gardent l’écriture risquée derrière une personne. La version directe est plus simple à tester ; la version MCP aide lorsque les agents posent des questions variées.
À préparer avant d’en parler à un développeur
- Le workflow ou le type de question à améliorer, avec dix à vingt exemples réels
- Les systèmes concernés, l’existence d’API et la personne qui peut créer des identifiants aux droits limités
- Les actions en lecture seule, celles qui modifient des données et celles qu’une personne doit toujours approuver
- Les données qui ne doivent jamais quitter vos systèmes et vos exigences de conservation des journaux
- À quoi ressemble un résultat correct, et qui relira les cas d’évaluation
- Ce qui doit se passer si l’IA ou un système externe est indisponible
- Comment mesurer le succès : temps gagné, erreurs détectées, réponses acceptées
Questions fréquentes
MCP remplace-t-il les API ?
Non. Un serveur MCP appelle généralement les mêmes API en arrière-plan. MCP standardise la façon dont un assistant découvre et appelle des outils ; vos systèmes ont toujours besoin d’API et d’identifiants aux droits bien délimités.
Peut-on commencer par une intégration directe et ajouter MCP plus tard ?
Oui. Des fonctions API bien testées, avec des entrées, permissions et règles d’approbation claires, peuvent ensuite être exposées une à une comme outils à un assistant.
Proposez-vous la mise en place de MCP comme service ?
Pas comme service séparé. MCP peut apparaître dans un projet d’intégration IA ; il est alors cadré comme un pilote de faisabilité avec ses propres cas d’évaluation. Ce guide est pédagogique et ce site n’exploite pas de serveur MCP public.
Vous hésitez sur l’approche adaptée à votre workflow ?
Décrivez en quelques lignes le workflow, les systèmes concernés et ce qui doit rester soumis à une approbation humaine. Vous recevrez un avis de faisabilité, pas un argumentaire commercial.
Réponses en français, en anglais ou en arabe.
Sources
Documentation de référence utilisée pour ce guide (en anglais). Les plateformes évoluent : vérifiez la version actuelle.
- OpenAI API docs: Connectors and MCP servers
Outils des serveurs MCP distants, restriction des outils, approbations et risques liés aux tiers.
- OpenAI API docs: File search
Recherche dans des fichiers approuvés, avec citations.
- OpenAI API docs: Structured outputs
Sorties conformes à un schéma JSON, qui peuvent malgré tout contenir des erreurs.
- n8n docs: Human-in-the-loop for AI tool calls
Revue humaine des appels d’outils dans un agent IA n8n.