Demandez à la plupart des éditeurs ce que fait leur agent IA et vous obtiendrez une réponse fluide : il répond à des questions, synthétise des documents, traite des tickets. Insistez — « mais comment lit-il concrètement notre ERP ? » — et la conversation devient rapidement vague.
Cette vagueur mérite attention. L’écart entre un agent qui parle de faire quelque chose et un qui le fait réellement se résume à une seule chose : l’usage des outils. Concrètement, comment un agent est connecté à vos systèmes réels — bases de données, CRM, ERP, calendriers, espaces documentaires — et quels standards régissent cette connexion.
Cet article explique comment les agents IA utilisent les outils, ce qu’est réellement le Model Context Protocol (MCP), et les questions concrètes à poser à tout éditeur avant de vous engager.
La différence entre un chatbot et un agent qui travaille vraiment
Un modèle de langage seul n’a pas de mains. Il traite du texte et renvoie du texte. C’est utile pour rédiger et synthétiser, mais il ne peut ni vérifier votre stock, ni mettre à jour une fiche client, ni déclencher un bon de commande sans quelque chose en plus.
Ce quelque chose en plus, c’est l’usage des outils — le mécanisme par lequel un agent appelle des fonctions externes, des API ou des services en cours de conversation et intègre les résultats dans son raisonnement. L’agent reçoit une description des outils disponibles (par exemple : « get_order_status(order_id) », « create_calendar_event(…) »), décide quel outil appeler et avec quels paramètres, l’exécute, puis utilise la réponse pour produire un résultat utile ou franchir l’étape suivante.
C’est aussi ce qui distingue un agent IA d’un simple chatbot ou copilot. Un chatbot récupère et reformule. Un agent avec des outils lit, décide, agit.
À quoi ressemble concrètement l’usage des outils
Imaginons un responsable logistique qui demande à un agent : « Quelles commandes ouvertes risquent de rater la date limite de vendredi ? »
Sans outils, l’agent invente une réponse plausible. Avec des outils, la séquence ressemble à ceci :
- L’agent appelle
get_open_orders(status="pending", due_before="2026-06-13")dans votre ERP. - Il reçoit une liste de douze commandes avec leur statut de livraison actuel.
- Il appelle
get_estimated_delivery(order_id=...)pour chacune dont le statut est incertain. - Il compare les dates de livraison estimées avec la date limite et signale les trois en risque.
- Il renvoie un récapitulatif avec les numéros de commande, le retard en jours, et le nom du responsable commercial depuis votre CRM.
Rien de tout cela n’est possible sans les outils. Les outils — et la capacité de l’agent à les enchaîner sur plusieurs appels — sont ce qui rend le résultat opérationnellement utile. Cet enchaînement d’appels d’outils dans une seule tâche est le cœur de ce que les workflows agentiques signifient en pratique.
Où s’insère MCP : la couche d’intégration expliquée
Définir des outils individuels pour chaque système qu’un agent doit atteindre est un travail d’ingénierie coûteux. Vous écrivez la fonction, gérez l’authentification, le versioning des API, et recommencez pour chaque source de données. Pour quelques intégrations dans un environnement maîtrisé, c’est gérable. Pour une entreprise dotée d’un CRM, d’un ERP, d’un espace documentaire, d’un système de ticketing et d’un calendrier — tous de fournisseurs différents — cela devient une charge de maintenance significative.
Model Context Protocol (MCP) est un standard ouvert, publié par Anthropic fin 2024, qui cherche à résoudre ce problème. En décembre 2025, Anthropic a cédé MCP à l’Agentic AI Foundation (AAIF), un fonds dirigé de la Linux Foundation co-fondé par Anthropic, Block et OpenAI — ce qui renforce son statut de standard genuinement neutre vis-à-vis des éditeurs. L’idée est simple : plutôt que d’intégrer les connexions directement dans l’agent, MCP définit une interface commune. Un système qui implémente MCP expose ses données et actions sous la forme d’un « MCP server ». Un runtime d’agent qui supporte MCP peut se connecter à n’importe quel serveur conforme sans travail d’intégration spécifique par système.
Pensez-y comme au standard USB pour les données. Avant USB, chaque périphérique avait son propre connecteur. Après USB, le périphérique et l’appareil n’ont qu’à s’accorder sur un seul protocole.
En pratique : une entreprise pourrait avoir un MCP server pour son CRM, un autre pour son ERP, et un autre pour son système de fichiers. Un agent compatible MCP peut découvrir ce que chaque serveur propose et l’appeler — sans que le développeur de l’agent écrive du code sur mesure pour chaque intégration.
Ce que MCP n’est pas
Il vaut la peine d’être précis sur l’état actuel de MCP. À mi-2026, MCP est un standard avec une adoption solide et croissante. Les principaux fournisseurs de modèles (Anthropic, OpenAI, Google) ont évolué vers son support, et un nombre significatif d’éditeurs de logiciels d’entreprise ont construit des interfaces conformes à MCP. Mais de nombreux systèmes que votre entreprise utilise réellement — notamment les bases de données développées sur mesure, les instances ERP fortement modifiées et les applications métier de niche — manquent encore de support MCP et nécessitent un travail d’intégration personnalisé.
Dans la plupart des déploiements réels, un mix reste donc nécessaire : MCP là où il est disponible, des définitions d’outils personnalisées là où il ne l’est pas. Tout éditeur qui prétend que MCP élimine tout travail d’intégration exagère.
Les questions que tout acheteur doit poser
Comprendre comment les agents utilisent les outils n’est pas purement académique. Cela change la façon dont vous évaluez les fournisseurs et ce que vous mettez dans un contrat. Voici les questions qui comptent vraiment :
Comment l’agent accède-t-il à mes systèmes spécifiques ? Pas « peut-il s’intégrer avec des CRM » — demandez : « Comment se connecte-t-il à mon instance de HubSpot / SAP / Odoo, et qui maintient cette connexion lors des mises à jour ? »
Quels outils utilise-t-il, et quelles permissions chaque outil possède-t-il ? Un outil qui ne peut que lire des données a un profil de risque fondamentalement différent d’un outil qui peut écrire ou supprimer. Vous devriez voir un manifeste des outils — une liste de ce que l’agent peut appeler et quel scope chaque appel porte. C’est central pour la sécurité des agents IA et mérite la même rigueur que le contrôle d’accès dans tout autre système.
Supporte-t-il MCP, et lesquels de mes systèmes disposent de MCP servers ? Si la réponse est « nous utilisons MCP », la question suivante est : « Pour quels systèmes précisément, et quelles intégrations sont encore personnalisées ? » Les éditeurs honnêtes distinguent clairement les deux.
Que se passe-t-il quand un appel d’outil échoue ? Un agent qui ignore silencieusement un appel API échoué et continue à raisonner est dangereux. Vous voulez savoir : réessaie-t-il, expose-t-il l’erreur, escalade-t-il vers un humain, ou s’arrête-t-il ? Le comportement en cas d’échec des appels d’outils est une partie sous-examinée de la plupart des spécifications d’agents.
Comment les credentials des outils sont-ils gérés et renouvelés ? Chaque appel d’outil qui touche un système réel requiert une authentification. Les clés API et les tokens OAuth vieillissent et doivent être renouvelés. Demandez qui gère cela et si la gestion des credentials est automatisée.
Une illustration : ce que cela signifie pour un distributeur de taille intermédiaire
Un distributeur en gros de 40 collaborateurs gère son activité sur un ERP de marché intermédiaire, un processus de devis basé sur des tableurs, et un CRM que les commerciaux utilisent de façon inconsistante. Ils souhaitent un agent capable de traiter les demandes de statut de commande des clients et de signaler les déclencheurs de réapprovisionnement à l’équipe achats.
Sur le papier, le cas d’usage est clair. En pratique, y parvenir signifie :
- Construire ou sourcer des outils compatibles MCP pour leur ERP (ou écrire des wrappers API personnalisés si le support MCP n’est pas disponible dans leur version)
- Définir le périmètre exact de ce que l’agent peut lire par rapport à ce qu’il peut écrire
- Mettre en place les flux d’authentification que l’agent peut utiliser à l’exécution
- Tester les cas limites — que se passe-t-il quand les données de stock sont obsolètes, quand un identifiant de commande n’existe pas, quand l’API ERP est indisponible pendant les heures ouvrées
Rien de tout cela n’est insurmontable, mais rien de tout cela n’est « simplement connecter un agent ». La couche d’intégration est là que réside le vrai travail d’ingénierie, et c’est là qu’apparaît l’écart entre une démo convaincante et un système fiable en production. Pour en savoir plus sur ce que ce travail d’intégration implique concrètement, consultez notre guide sur la connexion des agents IA à votre CRM et ERP.
À quoi ressemble une bonne architecture d’agent
Un agent bien conçu n’a pas ses outils ajoutés comme une réflexion tardive. La couche d’outils est pensée dès le départ avec :
- Privilège minimal : chaque outil dispose du périmètre de permissions le plus restreint qui permette encore la tâche
- Appels observables : chaque invocation d’outil est journalisée avec ses entrées, sorties, horodatage et l’étape de raisonnement de l’agent qui l’a déclenchée
- Dégradation gracieuse : l’agent sait quoi faire quand un outil est indisponible — ce qui signifie souvent « demander à l’humain » plutôt que deviner
- Interfaces versionnées : quand une API sous-jacente change, la définition de l’outil se met à jour sans nécessiter de modifications à la logique de raisonnement centrale de l’agent
Pour un regard plus approfondi sur la façon dont ces composants s’assemblent, l’architecture des agents IA expliquée aux décideurs couvre le design système global.
Qui devrait s’en préoccuper maintenant
Si vous évaluez un projet d’agent IA et que votre réponse à « comment l’agent se connecte-t-il à nos systèmes ? » est « je ne sais pas exactement », vous portez un risque technique qui se concrétisera à l’implémentation. Ce n’est pas une raison de retarder — c’est une raison de poser les bonnes questions plus tôt.
Si vous avez déjà un agent en production que vous n’avez pas construit vous-même, c’est le bon moment pour auditer son manifeste d’outils. Que peut-il appeler ? Avec quelles credentials ? Quels sont les modes de défaillance ? La plupart des organisations qui utilisent des agents tiers n’ont jamais examiné ce point.
Parlez-nous de vos exigences d’intégration
Chez Orange ITS, nous concevons des agents pour lesquels la couche d’intégration est une préoccupation de premier plan — pas une réflexion après coup. Notre service de développement d’agents IA couvre la totalité de la pile : conception des outils, adoption de MCP là où elle s’applique, intégration personnalisée là où elle ne s’applique pas, et l’infrastructure de credentials et d’observabilité qui garantit la fiabilité en production.
Si vous évaluez un projet d’agent et souhaitez un avis indépendant sur la solidité de l’approche d’intégration — ou si vous partez de zéro et voulez éviter les pièges courants — réservez un appel de 30 minutes avec notre équipe. Nous passerons en revue votre paysage applicatif et vous donnerons une évaluation directe de ce qu’un agent aurait besoin pour s’y connecter.