Connecter un agent IA au SI : ERP, CRM, messagerie
Un agent sans accès à vos outils se contente de répondre. Raccordé à la messagerie, au CRM ou à l'ERP, il devient utile, et il devient aussi un nouvel utilisateur de votre système d'information. La façon dont on le connecte décide de ce qu'une erreur ou un détournement peut provoquer.
Publié le 22 septembre 2026
Trois décisions avant le premier branchement
Raccorder un agent à un outil de l'entreprise revient à répondre à trois questions, dans cet ordre :
- Avec quels droits l'agent accède-t-il à l'outil ?
- Par quel moyen : un connecteur fourni par la plateforme, une API développée en interne, un serveur MCP ?
- Quelles opérations de l'outil l'agent peut-il appeler : lire, créer, modifier, supprimer ?
La plupart des incidents d'agents raccordés viennent d'une de ces décisions prise par défaut plutôt que choisie. Ce guide les reprend une à une. Il complète la grille d'achat du guide plateforme agentique en entreprise, qui fait de ces points des exigences.
Avec quels droits : délégués ou compte de service
C'est la décision la plus structurante, et la plus souvent prise par commodité.
| Mode d'accès | Principe | Ce qu'il permet | Ce qu'il risque |
|---|---|---|---|
| Droits délégués de l'utilisateur | L'agent s'authentifie au nom de la personne, qui a consenti à la connexion | Les droits de l'outil source s'appliquent tels quels ; la trace désigne la bonne personne | Chaque utilisateur doit connecter son compte ; certains outils anciens ne le permettent pas |
| Compte de service | Un compte technique unique, souvent très large, utilisé pour tous | Mise en place rapide, un seul secret à gérer | L'agent voit tout ; un utilisateur obtient par lui ce qu'il ne peut pas ouvrir ; la trace de l'outil ne montre que le compte technique |
| Clé d'API personnelle | Chaque utilisateur colle une clé générée dans l'outil | Droits de la personne, sans intégration d'annuaire | Clés souvent trop larges, rarement renouvelées, stockées sans contrôle |
La règle à retenir : l'agent ne doit jamais pouvoir faire ce que la personne qui l'emploie ne peut pas faire elle-même. Les droits délégués, via les mécanismes d'autorisation que proposent la plupart des suites bureautiques et des applications SaaS, sont la cible par défaut.
Le compte de service n'est pas interdit, mais il se réserve aux cas où l'agent travaille sur des données qui n'ont pas de propriétaire individuel, par exemple un référentiel produit public en interne, et avec un périmètre réduit au strict nécessaire.
Un agent partagé entre plusieurs utilisateurs ne doit pas utiliser la connexion de la personne qui l'a créé. Sinon, chaque utilisateur de l'agent hérite des droits de son créateur.
Connecteurs natifs, API maison, serveurs MCP
Trois moyens techniques existent pour relier un agent à un outil. Ils ne s'excluent pas.
Fourni et maintenu par la plateforme. Opérations décrites, authentification gérée, mises à jour suivies par l'éditeur.
Développée par vos équipes pour un outil métier spécifique. Contrôle total, mais maintenance et sécurité à votre charge.
Un standard ouvert pour exposer des outils à un agent. Intégration rapide, qualité variable selon qui l'a écrit.
Le Model Context Protocol (MCP) se présente comme un standard ouvert pour connecter des applications d'IA à des systèmes externes. Il simplifie réellement l'intégration : un outil exposé en MCP peut être utilisé par des clients différents. Mais un serveur MCP reste du code qui décrit et exécute des actions. Avant d'en brancher un, posez les mêmes questions qu'à tout logiciel tiers :
- Qui l'a écrit et qui le maintient ? Un serveur publié par l'éditeur de l'outil n'a pas le même statut qu'un projet personnel.
- Où s'exécute-t-il ? Un serveur hébergé par un tiers voit passer les données échangées avec l'outil.
- Qu'expose-t-il ? La liste des opérations et leur nature (lecture, écriture, exécution) doit être connue et filtrable.
- Que dit-il à l'agent ? Les descriptions d'outils sont lues par le modèle. Une description modifiée peut orienter son comportement : un serveur ne doit pas pouvoir changer ses descriptions sans que l'administrateur le sache.
Exposer des opérations, pas des systèmes
« Connecter l'agent au CRM » ne veut rien dire tant qu'on n'a pas choisi les opérations. Un CRM expose des dizaines d'actions ; un agent de préparation de rendez-vous en utilise trois. Chaque opération inutile élargit ce qu'une erreur peut provoquer.
| Outil | Opérations à ouvrir d'abord | Opérations à soumettre à validation | Opérations à ne pas exposer sans besoin démontré |
|---|---|---|---|
| Messagerie | Lire, chercher, préparer un brouillon | Envoyer, transférer | Supprimer, créer des règles de transfert |
| Agenda | Consulter les disponibilités | Créer ou modifier un rendez-vous | Supprimer des événements d'autrui |
| GED, partage de fichiers | Chercher, lire | Créer, modifier un document | Supprimer, changer les droits de partage |
| CRM | Consulter comptes et contacts | Créer une opportunité, mettre à jour une fiche | Supprimer, exporter en masse |
| ERP | Consulter commandes, stocks, factures | Créer une commande, modifier une écriture | Valider un paiement, modifier un référentiel |
| Gestion de tickets | Lire, chercher, commenter | Changer un statut, réassigner | Clôturer en masse, supprimer |
La troisième colonne s'appuie sur la validation humaine : l'agent prépare, une personne confirme en voyant l'action exacte. La quatrième n'est pas une interdiction définitive, mais une ouverture qui se justifie cas par cas.
Les risques propres au raccordement
Le référentiel OWASP des risques des applications LLM regroupe sous le nom d'« agentivité excessive » les dommages causés par un agent qui dispose de trop de fonctionnalités, de trop de permissions ou de trop d'autonomie. Appliqué au raccordement, cela donne quatre risques concrets.
L'injection par le contenu lu
Un agent qui lit des courriels, des tickets ou des pages web lit aussi ce qu'un tiers y a écrit. Une consigne cachée dans un message peut tenter de lui faire transférer des documents ou modifier un enregistrement. La défense ne repose pas sur le modèle : elle repose sur des droits limités et sur la validation des actions qui écrivent ou envoient.
La fuite par un outil d'envoi
Un agent qui peut à la fois lire des documents sensibles et envoyer des messages à l'extérieur combine les deux conditions d'une fuite. Séparer ces capacités entre agents, ou soumettre tout envoi externe à validation, casse la chaîne.
Les données envoyées au modèle
Tout ce que l'agent lit dans vos outils part vers le modèle qui raisonne. Si ce modèle est hébergé chez un fournisseur externe, l'extrait du CRM ou le courriel lu quitte votre périmètre. Le choix du modèle fait donc partie du choix de raccordement.
Les secrets de connexion
Jetons d'accès, clés d'API, comptes de service : ils doivent être stockés chiffrés, jamais exposés au modèle, et révoqués automatiquement au départ d'un utilisateur ou à la suppression d'une connexion.
Questions fréquentes
Faut-il ouvrir l'ERP à un agent dès le départ ?
Rarement. L'ERP porte des effets financiers et comptables difficiles à rattraper. Commencez par des outils où l'agent lit et prépare (messagerie, documents, tickets), mesurez la qualité de ses propositions, puis ouvrez l'ERP en consultation avant toute écriture.
Un serveur MCP trouvé en ligne est-il sûr ?
Pas par défaut. Le protocole est un standard d'échange, il ne dit rien de la qualité ou de l'intention du code qui l'implémente. Traitez-le comme n'importe quelle dépendance logicielle : provenance, lieu d'exécution, opérations exposées, et passage par le même catalogue et la même validation que les connecteurs natifs.
Comment révoquer l'accès d'un agent ?
Avec des droits délégués, en retirant la connexion de l'utilisateur ou en désactivant son compte : l'agent perd l'accès en même temps que la personne. Avec un compte de service, il faut révoquer le secret lui-même, ce qui coupe l'accès pour tous les utilisateurs de l'agent.
Où se situe SmartAGT
SmartAGT, déployé on-premise, propose des connecteurs vers Outlook, Teams, SharePoint, OneDrive, Dynamics 365, Gmail, Google Agenda, Google Drive, Jira, Confluence, GLPI et Slack, ainsi que les serveurs MCP. Chaque connecteur agit avec les droits du compte connecté.
Toute action d'écriture ou d'exécution est mise en pause jusqu'à confirmation humaine, et la décision est tracée. Les connecteurs disponibles et en cours de test sont listés sur la page Intégrations, les usages métier sur la page Cas d'usage.
