Connecter un agent IA à votre logiciel consiste à lui donner accès à de vraies actions, lire un compte, créer un ticket, changer un statut, via des appels d'outils encadrés, pas seulement à une documentation qu'il résume. Techniquement, ça passe par du tool calling exposé par le modèle, une connexion à vos API existantes ou à un serveur MCP, et un système de permissions qui limite l'agent aux droits de l'utilisateur qui l'interroge.
Le travail difficile n'est pas de brancher une API. C'est de décider ce que l'agent a le droit de faire seul, ce qui exige une validation humaine, et comment on mesure qu'il agit correctement une fois en production, sur de vraies données de vos utilisateurs.
Ce qui suit part du problème métier, répondre depuis une documentation ne suffit plus dès que l'utilisateur veut une action sur son propre compte, puis descend vers les choix techniques (tool calling, API ou MCP, permissions, validation, évaluation), et termine sur la question qui se pose à tout éditeur logiciel ou DSI, construire cette brique en interne ou se faire accompagner. Ce n'est pas un tutoriel de code, c'est ce qu'on met en production et pourquoi.
Ce qu'il faut retenir
- Un agent qui agit répond à des questions sur le compte réel d'un utilisateur, pas à des questions sur une doc générale
- Le tool calling laisse le modèle choisir un outil et ses arguments, jamais l'exécuter lui-même
- Une API directe suffit pour un usage interne, le MCP devient utile quand plusieurs agents réutilisent la même connexion
- L'agent agit toujours avec les droits de l'utilisateur, jamais avec un compte de service partagé entre clients
- Validation humaine sur les actions irréversibles, évaluation sur les appels d'outils, pas seulement sur le texte final
Du chatbot qui répond à l'agent qui agit
Un chatbot qui lit votre documentation répond à une question comme « comment poser un congé ? » en résumant une politique écrite une fois pour toutes, valable pour tout le monde. Un agent qui agit répond à « pourquoi ma note de frais de mardi est refusée ? », une question qui n'a pas de réponse dans la doc. La réponse est dans le compte de cet utilisateur précis, à cet instant précis.
Pour répondre à la deuxième question, l'agent doit interroger votre système de notes de frais avec l'identité de l'utilisateur, lire le statut réel du justificatif, et parfois déclencher une action, renvoyer la demande, notifier un valideur. C'est un appel d'outil sur une donnée vivante, pas une recherche dans un corpus statique. C'est ce basculement qui transforme un assistant qui documente en agent qui agit, et qui change tout ce qu'il faut sécuriser autour de lui.
| Critère | Chatbot qui répond depuis la doc | Agent qui agit sur le compte utilisateur |
|---|---|---|
| Source de la réponse | Contenu écrit une fois, identique pour tous | Données vivantes du compte, au moment de la question |
| Exemple type | Comment poser un congé | Pourquoi ma note de frais de mardi est refusée |
| Ce qu'il fait techniquement | Recherche dans un corpus, puis résumé | Appel d'un outil, API ou MCP, avec l'identité de l'utilisateur |
| Risque principal | Répondre à côté de la question | Agir à la place de l'utilisateur, sur les mauvaises données |
Un éditeur logiciel ou un DSI qui veut passer du premier cas au second ne fait pas évoluer un prompt, il ajoute une brique d'exécution complète. C'est ce que couvre le reste de cet article, et c'est aussi la différence de fond entre les agents IA et les chatbots pour PME, présentée ici du point de vue de ce qu'il faut connecter, pas de ce qu'il faut choisir.
Tool calling, comment un agent IA choisit et exécute une action
Le tool calling (appel d'outil) est le mécanisme par lequel un modèle de langage décide d'appeler une fonction externe plutôt que de répondre directement en texte. Le modèle ne touche jamais votre base de données ni votre API. Il demande une exécution, votre système l'effectue, et le résultat lui est renvoyé pour qu'il continue son raisonnement.
Le mécanisme à connaître
Chaque outil exposé au modèle est décrit par un schéma, un nom, une description en langage naturel de ce qu'il fait, et des paramètres typés (le format de description d'outil structuré est aujourd'hui standard sur la plupart des fournisseurs de modèles). Le modèle lit ces schémas, choisit s'il doit appeler un outil et lequel, et produit les arguments demandés. La qualité de la description de l'outil détermine directement la fiabilité de la décision du modèle, une description ambiguë produit des appels d'outils incohérents.
Le périmètre d'actions autorisées se définit outil par outil, pas globalement. Un outil « lire les tickets support d'un client » ne doit jamais être confondu, au niveau du code, avec un outil « supprimer un compte client », même si les deux touchent au même système. Trois règles reviennent sur les intégrations qui tiennent en production :
- Un outil, une action précise. Éviter les outils fourre-tout qui acceptent un paramètre libre capable de déclencher plusieurs types d'actions différentes.
- Réduire le nombre d'outils exposés à ce qui est strictement utile à la tâche. Notre diagnostic des agents IA qui déraillent en production observe qu'un agent qui a le choix entre une douzaine d'outils prend des décisions moins prévisibles qu'un agent qui en a quatre.
- Séparer lecture et écriture. Un outil qui lit une donnée et un outil qui la modifie ne devraient jamais partager le même point d'entrée technique, même s'ils touchent la même table.
Connecter l'agent à vos outils, API directe ou MCP
Deux voies existent pour brancher un agent sur votre logiciel. La première consiste à décrire vos API existantes comme des outils, chaque endpoint devient un schéma que le modèle peut appeler. La seconde consiste à exposer ces mêmes capacités derrière un serveur MCP (Model Context Protocol), un standard ouvert introduit par Anthropic en novembre 2024 pour donner aux applications basées sur un modèle de langage une façon commune de se connecter à des outils et des sources de données externes.
Le MCP n'est plus un sujet de niche. Il a depuis été adopté par OpenAI, Google DeepMind et Microsoft, et sa gouvernance est passée en décembre 2025 sous une fondation dédiée (Agentic AI Foundation, hébergée par la Linux Foundation), cofondée par Anthropic, Block et OpenAI. Cette adoption large ne veut pas dire qu'il faut l'utiliser par défaut, elle veut dire qu'il faut savoir dans quel cas il sert vraiment.
| Critère | API directe | Serveur MCP |
|---|---|---|
| Ce que c'est | Vos endpoints existants décrits comme des outils pour le modèle | Un serveur qui expose vos outils selon un standard commun |
| Effort de mise en place | Faible si l'API existe déjà et son périmètre est clair | Plus élevé, il faut construire, héberger et sécuriser le serveur |
| Intérêt principal | Simplicité, quand un seul agent a un seul usage | Réutiliser la même connexion pour plusieurs agents ou clients IA |
| À éviter quand | Plusieurs agents différents doivent brancher le même outil | Un seul agent interne existe, sans besoin de réutilisation |
Sur la sécurité, le protocole a mûri sans devenir sans risque. Les révisions de la spécification publiées en 2025 ont adossé l'autorisation des serveurs MCP distants à OAuth 2.1, ce qui a corrigé une partie des angles morts des premières implémentations. Les risques qui restent documentés sont connus, des serveurs mal authentifiés ou trop permissifs, des outils dont le périmètre dépasse le besoin réel, et de l'injection de contenu malveillant via les données renvoyées par un outil. Ce sont exactement les mêmes catégories de risque qu'une API mal cloisonnée, le MCP ne les invente pas, il les rend seulement visibles à plus d'agents à la fois si la gouvernance n'a pas suivi.
Notre guide sur le Model Context Protocol en entreprise détaille les trois primitives du protocole (tools, resources, prompts) et la gouvernance des serveurs MCP pour qui veut aller plus loin sur ce point précis. Ici, la question qui compte pour la plupart des logiciels métier reste plus simple, avez-vous vraiment plusieurs agents à connecter, ou un seul, sur une seule API que vous contrôlez déjà.
Permissions, l'agent agit avec les droits de l'utilisateur, jamais plus
Le principe ne change pas parce que l'exécutant est un modèle de langage plutôt qu'un humain, un agent agit avec exactement les droits de la personne qui l'interroge, jamais avec un compte de service aux privilèges plus larges. Un agent qui répond aux questions de note de frais d'un salarié ne doit techniquement rien pouvoir faire que ce salarié ne pourrait pas faire lui-même dans l'interface.
Le cadre professionnel qui s'est imposé en 2026 pour les applications agentiques ajoute une dimension à ce principe classique du moindre privilège, l'autonomie. Ce n'est plus seulement une question de ce à quoi l'agent a accès, c'est une question de combien d'actions il peut enchaîner seul avant de revenir vers un humain. Le Top 10 OWASP des applications agentiques désigne cette dimension comme la moindre agentivité, et recommande des jetons éphémères et créés au moment de l'usage plutôt que des accès permanents.
Dans un logiciel multi-clients, l'isolement se joue au niveau de chaque appel d'outil, pas au niveau de la réponse générée. Chaque appel doit porter l'identifiant du client concerné, sans qu'un cache, une base vectorielle ou un contexte partagé ne puisse mélanger les données de deux clients différents. C'est un défaut de conception qui se corrige à la connexion de l'agent aux outils, jamais après coup en filtrant les réponses.
- Jeton scopé au strict périmètre de la tâche déclarée, jamais un jeton d'administration partagé entre systèmes
- Jetons éphémères plutôt que permanents, créés au moment de l'exécution et révoqués ensuite
- Identifiant de tenant obligatoire sur chaque appel d'outil dans un logiciel multi-clients, jamais déduit implicitement du contexte de conversation
Validation humaine, journalisation et annulation sur les actions sensibles
Toutes les actions ne se valent pas. Une action de lecture, consulter un statut, afficher un historique, peut s'exécuter sans intervention. Une action à fort impact ou irréversible, une suppression, un paiement, une modification qui touche un tiers, doit passer par une validation humaine explicite avant exécution, jamais après.
Cette distinction est directement recommandée par les cadres de sécurité 2026 sur les applications agentiques, qui demandent une confirmation humaine pour toute opération qui modifie un état, pas seulement pour les opérations jugées dangereuses a posteriori. La différence compte, un agent qui demande confirmation seulement quand il détecte lui-même un risque reste exposé à ses propres angles morts.
Ce qui ne se négocie pas
- Toute action irréversible ou à fort impact passe par une confirmation humaine avant exécution
- Chaque décision de l'agent, outil appelé, arguments, résultat, doit être journalisée dans un format consultable en quelques minutes, pas en heures
- Les actions à fort enjeu doivent avoir un chemin d'annulation explicite, pas une simple confiance dans le fait que l'agent ne se trompera pas
La journalisation n'est pas une case à cocher pour un audit futur, c'est ce qui permet de répondre, le jour où un utilisateur conteste une action, à la question « pourquoi l'agent a-t-il fait ça ». Sans cette trace, la reconstitution après coup prend des heures, et arrive presque toujours trop tard pour rassurer l'utilisateur concerné.
Évaluer un agent qui agit, et choisir comment le construire
Tester les appels d'outils, pas seulement les réponses
Évaluer un chatbot classique revient à juger si le texte final est bon. Évaluer un agent qui agit demande de vérifier la trace d'appels d'outils, le bon outil a-t-il été choisi, avec les bons arguments, dans le bon ordre. Un agent peut produire une réponse parfaitement convaincante tout en ayant appelé le mauvais outil ou modifié la mauvaise ressource, un défaut qu'une évaluation centrée sur le texte final ne détecte jamais.
La méthode qui tient en pratique consiste à construire un petit jeu de scénarios représentatifs de vos cas réels, congé accepté, note de frais refusée, utilisateur sans droit suffisant, puis à comparer la trace d'exécution obtenue à la trace attendue pour chacun. C'est la même logique de baseline que sur un système d'Agentic RAG qui enchaîne plusieurs étapes de recherche avant de répondre, on mesure le chemin suivi, pas seulement l'arrivée.
Chaque appel d'outil a un coût et une latence. Un aller-retour supplémentaire, des tokens de schéma d'outil, un résultat renvoyé au modèle, tout cela s'additionne, surtout sur les tâches qui enchaînent plusieurs appels avant de répondre. Router les tâches de tool calling répétitives et peu ambiguës vers un modèle plus léger, parfois un modèle spécifiquement affiné pour cet usage, réduit cette facture sans dégrader la fiabilité sur les cas qui exigent vraiment du raisonnement.
Construire en interne ou vous faire accompagner
Un prototype qui appelle un ou deux outils se construit vite dès que votre équipe connaît déjà l'API concernée, souvent en quelques jours. Ce qui prend du temps n'est pas le branchement, c'est le cadrage des permissions, les points de validation humaine, la journalisation, et une évaluation qui prouve que l'agent ne casse pas silencieusement sur les cas limites que personne n'a pensé à tester au démarrage.
C'est cette deuxième partie qui justifie de se faire accompagner, sur le cadrage et la mise en garde-fous, pas sur l'ensemble du projet. Quel que soit le chemin choisi, le code de l'intégration vous appartient, il n'y a pas de raison qu'il en soit autrement pour une brique connectée à votre propre logiciel.
Chez Tensoria, c'est ce cadrage qu'on fait en premier avant d'écrire la moindre ligne de code, quels outils exposer, avec quel périmètre, quelles actions demandent une validation humaine, et comment on va mesurer que l'agent fonctionne une fois en production. Le développement d'agents IA sur mesure se fait sur devis, sur la base de ce cadrage, avec une durée et des livrables définis avant de démarrer. Pour un cas d'usage précis comme le traitement des demandes entrantes, notre offre d'agent IA support client part du même principe de permissions et de validation humaine décrit plus haut.
Questions fréquentes sur la connexion d'un agent IA à un logiciel
Un agent IA à connecter à votre logiciel ?
Cadrons ensemble les outils, les permissions et les points de validation.
Articles recommandés
- Agents IA vs chatbots pour PME : comprendre la différence entre répondre et agir, avant de cadrer une connexion à vos outils.
- MCP, enjeux du Model Context Protocol en entreprise : les trois primitives du protocole, la sécurité et la gouvernance des serveurs MCP.
- Frameworks pour construire des agents IA : les options pour implémenter le tool calling et l'orchestration d'un agent.
- Agent IA qui boucle ou dérape : diagnostic et reprise en main quand la trajectoire, le coût ou les permissions dérapent en production.
- Agentic RAG : quand l'agent enchaîne plusieurs étapes de recherche documentaire avant de répondre.
- Fine-tuner un SLM pour les agents IA métier : réduire le coût et la latence du tool calling sur les tâches répétitives.
Aller plus loin
Découvrez notre guide sur les agents IA en entreprise ou cadrez votre projet d'agent connecté à vos outils avec nous, sur devis, avec des livrables définis avant de démarrer.
