Intégrer un agent IA à votre SI existant : MCP, APIs, connecteurs

L’un des obstacles les plus fréquemment cités par les entreprises face au déploiement d’agents IA n’est pas technique au sens fondamental : c’est l’intégration. « Notre ERP a 20 ans. Notre CRM est une instance Salesforce personnalisée depuis des années. Comment un agent va-t-il se connecter à tout ça sans qu’on réécriveour infrastructure ? »

La réponse est concrète. Les agents IA modernes n’ont pas besoin que vous remplaciez votre SI. Ils ont besoin d’une interface pour le lire et y écrire. Cette interface, dans l’écosystème actuel, prend trois formes : les APIs REST que vos systèmes exposent déjà, les serveurs MCP que vous créez pour encapsuler l’accès à ces APIs, ou des connecteurs custom pour les cas particuliers. Voyons comment chacun fonctionne et quand l’utiliser.

Le MCP : le standard d’intégration des agents modernes

Le Model Context Protocol (MCP) est un protocole ouvert publié par Anthropic pour standardiser la façon dont les agents IA se connectent à des sources de données et des outils externes. Il fonctionne sur le modèle client-serveur : votre application ou votre SI expose un serveur MCP, et l’agent s’y connecte pour découvrir et utiliser les outils disponibles.

La logique est élégante. Plutôt que d’apprendre à l’agent comment faire un appel HTTP vers votre API Salesforce, comment authentifier la requête, comment parser la réponse et comment gérer les erreurs de rate limiting, vous créez un serveur MCP qui expose des outils de haut niveau : get_contact, create_opportunity, update_stage. L’agent comprend ces outils en langage naturel via leur description, et les appelle directement sans connaître les détails d’implémentation sous-jacents.

Un serveur MCP expose trois types de ressources :

• Tools : fonctions que l’agent peut appeler pour effectuer des actions (lecture, écriture, déclenchement).
• Resources : données auxquelles l’agent peut accéder en lecture (documents, fichiers, bases de données).
• Prompts : templates d’instructions réutilisables pour des tâches spécifiques.

Un article dédié de notre blog couvre le MCP en profondeur. Pour les besoins de ce guide d’intégration, retenez l’essentiel : le MCP est le moyen le plus propre et le plus pérenne de connecter un agent à votre SI, car il découple complètement la logique métier de l’agent des détails techniques de vos systèmes.

Cas concret : intégration avec un CRM Salesforce

Prenons un exemple qui illustre les différentes couches d’intégration.

Le contexte : une agence B2B de conseil veut déployer un agent de qualification de leads. Chaque nouveau lead entrant dans Salesforce doit être enrichi, scoré, et si qualifié, un premier email personnalisé doit être envoyé automatiquement et le lead assigné au bon commercial.

Étape 1 : mapper les outils nécessaires. Avant d’écrire une ligne de code, on liste les actions que l’agent doit pouvoir effectuer sur Salesforce :

• Lire une Lead (objet Salesforce) avec tous ses champs
• Mettre à jour les champs de qualification (score, statut, notes)
• Créer un Activity (log de l’action de l’agent)
• Assigner un Owner (commercial)
• Déclencher un email depuis un template Salesforce

Étape 2 : créer un compte de service restreint. On crée un utilisateur Salesforce dédié à l’agent, avec uniquement les permissions nécessaires pour les cinq actions listées. Aucun accès aux objets Account, Contract, ou Opportunity dans cette phase. Le principe du moindre privilège s’applique.

Étape 3 : développer le serveur MCP. On développe un serveur MCP (typiquement en TypeScript ou Python) qui implémente un outil pour chacune des cinq actions. Chaque outil a une description claire pour l’agent : get_lead(lead_id: string) → Lead avec une description « Récupère les informations complètes d’un prospect Salesforce à partir de son identifiant. »

Étape 4 : configurer l’agent. L’agent reçoit dans son system prompt le contexte métier (grille ICP, règles de qualification, templates d’email), et la liste des outils MCP disponibles. À partir de là, il peut exécuter le processus de qualification complet de manière autonome.

Résultat observé en production : sur un flux de 200 leads par semaine, le temps de qualification est passé de 45 minutes par lead (enrichissement manuel + email + assignation) à moins de 3 minutes d’intervention humaine pour les cas ambigus seulement, soit 95 % de réduction de la charge de travail de qualification.

Cas concret : intégration avec un ERP SAP

L’intégration avec SAP est plus complexe que Salesforce, mais suit la même logique.

Le contexte : une ETI industrielle veut un agent de back-office capable de rapprocher les bons de commande fournisseurs reçus par email avec les commandes enregistrées dans SAP, et de déclencher le paiement si tout correspond.

Les spécificités SAP : contrairement à Salesforce ou HubSpot, SAP expose ses données via plusieurs protocoles selon la version et la configuration : OData (API REST standardisée pour S/4HANA), BAPI (appels RFC propriétaires pour les instances plus anciennes), ou des web services SOAP.

Approche recommandée pour S/4HANA : SAP expose des OData services documentés pour les principaux objets métier (Purchase Order, Invoice, Payment). On construit un serveur MCP qui encapsule ces appels OData. Les outils exposés à l’agent ressemblent à : get_purchase_order(po_number: string), match_invoice_to_po(invoice_data: object) → MatchResult, approve_payment(po_number: string, invoice_number: string).

Approche pour les SAP legacy : si votre instance SAP ne dispose pas d’OData, on passe par une couche intermédiaire. L’extraction de données se fait par RFC ou par un reporting SAP périodique vers un fichier CSV ou une base SQL. L’agent lit la base SQL (outil plus simple) et écrit les résultats de son traitement dans une table que votre équipe SAP peut ensuite importer.

Cette approche est moins propre techniquement (latence de quelques heures sur les données), mais elle permet de déployer un agent sans toucher au core SAP, ce qui est souvent un prérequis des équipes IT.

Le panorama des patterns d’intégration

Selon votre SI, vous utiliserez un ou plusieurs de ces patterns.

Pattern 1 : MCP natif (recommandé quand c’est possible)

Utilisé quand : votre système expose une API REST documentée.

Exemples : Salesforce, HubSpot, Pipedrive, Monday.com, Airtable, Notion, Stripe, Zendesk, Linear, Jira.

Avantages : découplage maximal, description des outils en langage naturel, gestion native des erreurs et du retry, sécurité centralisée.

Délai de mise en œuvre : 2 à 5 jours par système.

Pattern 2 : API REST directe (outils natifs d’agent)

Utilisé quand : vous ne voulez pas créer un serveur MCP dédié, ou quand l’API est simple et peu d’outils sont nécessaires.

L’agent reçoit directement les credentials et les endpoints dans ses outils. C’est plus rapide à mettre en place mais moins pérenne (les credentials sont dans le system prompt, les erreurs moins bien gérées).

Recommandé pour les POC et les intégrations légères (2 à 3 outils maximum).

Pattern 3 : Base de données intermédiaire

Utilisé quand : votre SI est un legacy sans API, ou quand votre équipe IT ne peut pas exposer d’API directement.

On extrait périodiquement les données vers une base SQL (PostgreSQL, SQLite) ou un stockage structuré. L’agent lit et écrit dans cette base intermédiaire. Une synchronisation périodique (toutes les heures, toutes les nuits) reporte les changements vers le SI source.

Avantages : zéro risque d’impact sur le système source, déploiement rapide côté agent.

Limites : latence de données (pas de temps réel), double source de vérité à gérer.

Pattern 4 : Webhooks entrants

Utilisé quand : vous voulez que votre SI pousse des événements vers l’agent plutôt que l’agent ne poll le SI.

Votre CRM ou ERP émet un webhook quand un événement survient (nouveau lead, commande reçue, ticket ouvert). Un endpoint de votre infrastructure reçoit ce webhook et déclenche l’exécution de l’agent. L’agent répond à l’événement et peut écrire le résultat via API ou MCP.

C’est le pattern le plus réactif (latence quasi nulle) pour les flux événementiels.

Pattern 5 : Connecteur custom pour legacy

Utilisé quand : aucun des patterns précédents n’est applicable (interface graphique sans API, protocole propriétaire très ancien).

Un micro-service intermédiaire agit comme proxy : il présente une API REST propre à l’agent tout en communicant avec le legacy via son protocole natif (SOAP, RPC, simulation d’interface graphique via Playwright headless).

Ce pattern est le plus coûteux à développer et maintenir, mais il reste parfois la seule option.

Tableau de décision : quel pattern pour votre SI ?

Type de système	Protocole exposé	Pattern recommandé	Délai de mise en œuvre
CRM moderne (Salesforce, HubSpot)	API REST + OAuth	MCP natif	2-5 jours
ERP moderne (SAP S/4HANA)	OData v4	MCP natif	1-3 semaines
ERP legacy (SAP R/3, Sage 100)	RFC / BAPI	Base intermédiaire	3-5 jours (extraction)
Messagerie (Gmail, Outlook 365)	API native	MCP natif	1-2 jours
Base de données SQL exposée	SQL direct	Outil DB natif	1-2 jours
Application sans API	Interface graphique	Connecteur custom	2-4 semaines
Service cloud (Stripe, Zendesk)	API REST	MCP natif	1-3 jours
ERP industriel (AVEVA, Infor)	Variable	Audit nécessaire	À qualifier

Sécurité et gouvernance des intégrations

Une règle fondamentale que nous appliquons systématiquement : chaque intégration est gouvernée par un compte de service dédié avec des droits minimaux.

Cela signifie qu’un agent de qualification de leads n’a pas accès aux données financières dans le CRM. Un agent de facturation n’a pas accès aux dossiers RH. Un agent de veille documentaire ne peut pas modifier de données, seulement les lire.

Cette séparation des droits répond à deux enjeux :

• Sécurité : si le comportement d’un agent est compromis ou dévie, l’impact est limité à son périmètre de droits.
• Auditabilité : chaque action de l’agent est tracée dans les logs de votre SI avec le compte de service dédié, ce qui facilite l’audit et le diagnostic en cas d’erreur.

En complément, nous recommandons la mise en place d’un human-in-the-loop pour les actions à fort impact : suppression de données, paiements au-delà d’un certain seuil, modifications de contrats. L’agent prépare l’action et notifie un humain pour validation finale avant exécution.

Les erreurs d’intégration les plus fréquentes

Donner trop de droits à l’agent. C’est le reflexe le plus courant pour simplifier l’intégration, et c’est une erreur. Un agent avec des droits admin peut faire des dégâts involontaires. Commencez en lecture seule et ajoutez les droits d’écriture un à un.

Ignorer la gestion des erreurs. Vos APIs ont des limites de rate, des timeouts, des erreurs intermittentes. Un serveur MCP bien conçu gère le retry exponentiel, la mise en file d’attente, et remonte à l’agent des erreurs exploitables (« le CRM est temporairement indisponible, réessayer dans 60 secondes ») plutôt que des stack traces brutes.

Exposer des données sensibles dans le contexte de l’agent. Si votre outil get_customer retourne l’intégralité du dossier client incluant les données bancaires, ces données transitent par les messages de l’agent. Filtrez les données exposées aux strict minimum nécessaire à la tâche.

Oublier la traçabilité. Chaque action d’un agent en production doit être loggée avec : timestamp, identifiant de session, outil appelé, paramètres envoyés, résultat reçu. Ces logs sont votre filet de sécurité pour diagnostiquer les erreurs et démontrer la conformité.

Comment nous procédons chez VirtuoseWeb

Notre processus d’intégration fait partie de la méthode SOP → Agent décrite dans notre guide complet. À l’étape de design de l’agent, nous cartographions systématiquement les systèmes cibles, le pattern d’intégration adapté à chacun et les droits minimaux nécessaires.

Ce travail est inclus dans tous nos packs, du Solo Agent à l’Enterprise Souverain. Pour les projets complexes avec plusieurs systèmes à intégrer, nous réalisons d’abord un Diagnostic Agents à 990 € qui inclut une cartographie d’intégration complète avant de proposer un devis de développement.

Si vous souhaitez évaluer la faisabilité de l’intégration de vos systèmes spécifiques avant de vous engager, notre audit SOP gratuit de 30 minutes est le premier pas. Vous repartez avec une évaluation de faisabilité technique et une recommandation de voie de déploiement adaptée à votre contrainte de souveraineté.