MCP et interfaces en langage naturel : pourquoi votre prochaine intégration sera une intention, pas une API

Le langage naturel devient une couche d’interface primaire pour les systèmes d’entreprise, et non plus un simple chatbot cosmétique en façade. Les grands modèles de langage (LLM), le Model Context Protocol (MCP) et les workflows agentiques font évoluer les logiciels des appels de fonctions vers l’orchestration d’intentions.
Cet article analyse comment cela transforme les stratégies d’intégration, comment les stacks NoCode/LowCode peuvent exposer les API sous forme de capacités lisibles par les modèles, et ce que cela implique pour la gouvernance, l’auditabilité et les modèles opérationnels. Des scénarios concrets incluent la data en self‑service, l’automatisation de l’onboarding client et des copilotes métiers connectés à des back‑offices legacy.

---

Des APIs aux intentions : un changement structurel d’interface

🧩 Ancien paradigme : les logiciels attendaient des humains qu’ils parlent leur langage.
grep, ls, GET /users, des méthodes de SDK comme client.orders.list() — tout cela exigeait de l’utilisateur ou du développeur :

• de savoir quel outil appeler
• de savoir comment l’appeler (paramètres, ordre, authentification)
• de composer manuellement plusieurs appels en workflows

Dans ce modèle, les APIs et SDK constituent la surface des systèmes. Intégrer signifie cartographier des endpoints, des schémas et des événements.

🧠 Nouveau paradigme : les LLM et MCP inversent la responsabilité.
Les utilisateurs et les agents expriment des résultats attendus en langage naturel, par exemple :

« Génère un rapport de risque sur nos 50 principaux clients, en utilisant les 12 derniers mois de transactions et de notes CRM, et mets en évidence les anomalies. »

La couche d’orchestration (un sujet que nous approfondissons en examinant l’orchestration multi‑agents dans l’IA d’entreprise) :

1. Interprète l’intention et les entités
2. Sélectionne les capacités pertinentes (outils/APIs)
3. Séquence les appels et gère l’état
4. Renvoie des résultats structurés ou narratifs

Au lieu de se demander « quelle API dois‑je appeler ? », le système se demande « quelles capacités peuvent satisfaire cette intention ? ».

MCP apparaît ici comme un protocole partagé pour :

• décrire les outils et sources de données de façon adaptée aux modèles
• exposer des métadonnées de capacité (ce que fait l’outil, pas seulement son chemin)
• permettre à des agents de découvrir et d’orchestrer ces outils de façon autonome

Les APIs ne disparaissent pas. Elles deviennent des détails d’implémentation derrière une couche d’orchestration orientée intention.

---

Des capacités, pas des endpoints : comment MCP re-cadre l’intégration

flowchart LR
    subgraph Old_Model[Traditional API and SDK model]
        A[User or developer] --> B[Choose specific tool or endpoint]
        B --> C[Figure out parameters order and auth]
        C --> D[Manually compose multiple calls into workflow]
        D --> E[Integration by mapping endpoints schemas events]
    end

    subgraph New_Model[LLM and MCP outcome based model]
        F[User or agent states outcome in natural language]
        F --> G[Orchestration layer interprets intent and entities]
        G --> H[Selects relevant capabilities tools or APIs]
        H --> I[Sequences calls and manages state]
        I --> J[Produces risk report or other requested outcome]
    end

    A --- F

🔧 L’intégration traditionnelle se concentre sur :

• les endpoints (/customers, /invoices)
• les schémas d’entrée/sortie
• les flux d’authentification
• la transformation et le code de “glue”

Avec une approche MCP + agents LLM, l’artefact principal est la capacité :

« Récupérer toutes les factures d’un client sur une période et retourner les paiements en retard. »

En interne, cette capacité peut :

• appeler plusieurs microservices
• joindre des données de la facturation, du CRM et du recouvrement
• appliquer des règles métier sur les concepts de “retard” ou “impayé”

Mais pour le modèle et l’utilisateur, cela apparaît comme un outil avec :

• une description claire en langage naturel
• des paramètres typés alignés sur le domaine métier
• des contraintes et des préconditions

Une comparaison simplifiée permet de clarifier ce changement :

Dimension	Intégration centrée API	Centrée capacité (MCP, agents)
Unité de conception principale	Endpoint / fonction	Capacité métier / surface d’intention
Langage d’interface	HTTP, gRPC, méthodes de SDK	Langage naturel + métadonnées structurées d’outils
Qui compose les workflows	Développeurs, ingénieurs d’intégration	Agents LLM + couche d’orchestration (avec supervision)
Modèle mental de l’utilisateur	« Quel système / quelle méthode ? »	« Quel résultat je veux obtenir ? »
Focus de la documentation	Swagger/OpenAPI, listes de paramètres	Ontologie, catalogue de capacités, politiques d’usage
Friction principale	Mapping de schémas, gestion des cas limites	Ambiguïté des intentions, alignement sémantique et contrôle

Sous MCP, le tooling consiste surtout à :

• rendre les capacités découvrables
• exprimer des sémantiques utilisables par le modèle
• exposer des garde‑fous et des contraintes
• permettre aux orchestrateurs (agents, workflows) de les chaîner

C’est là que les écosystèmes NoCode/LowCode s’insèrent naturellement.

---

NoCode/LowCode rencontre MCP : des workflows aux capacités agentiques

🧱 Des outils comme Make, n8n, Zapier, Retool, Bubble ont déjà abstrait une grande partie de la charge d’intégration classique :

• connecteurs vers des SaaS et APIs internes
• workflows visuels
• mappers de schémas et logique d’automatisation basique

Cependant, les utilisateurs doivent toujours :

• choisir le bon connecteur
• modéliser déclencheurs et actions
• concevoir manuellement les séquences d’étapes

Avec MCP et les interfaces en langage naturel, ces stacks évoluent de “concepteurs de workflows” vers de véritables backplanes de capacités.

Convertir des actifs NoCode en capacités lisibles par les modèles

Les workflows NoCode existants représentent souvent déjà des processus métier :

• « Créer un lead dans le CRM lorsqu’un formulaire est soumis »
• « Synchroniser le statut des factures de l’ERP vers l’outil de comptabilité »
• « Enrichir les données de contact depuis une API externe avant envoi au marketing automation »

Pour tirer parti de MCP :

1. Envelopper les workflows en capacités

   • Donner à chaque workflow une description sémantique : objectif, entrées, sorties, contraintes.
   • Les exposer comme outils accessibles via MCP plutôt que de les laisser cachés derrière des boutons d’UI.

2. Aligner les entrées sur l’ontologie métier

   • Utiliser des termes métier, pas techniques : client_id devient CustomerIdentifier, startDate devient ReportingPeriodStart.
   • Documenter les dépendances : « nécessite un enregistrement CRM valide » ou « réservé aux rôles Finance ».

3. Connecter aux interfaces conversationnelles

   • Un agent LLM reçoit la demande utilisateur.
   • La couche MCP fait correspondre l’intention à un ou plusieurs workflows.
   • Le moteur NoCode exécute, tandis que l’agent gère le contexte et le dialogue.

Résultat : un seul prompt peut déclencher un processus métier complet qui nécessitait auparavant des clics manuels ou plusieurs appels d’API.

---

Patrons d’architecture : ontologies, MCP et orchestrateurs d’agents

🏗️ L’architecture émergente pour l’intégration orientée intention comporte généralement quatre couches :

1. Ontologie d’entreprise
2. Catalogue de capacités exposées via MCP
3. Orchestrateurs agentiques
4. Systèmes existants et workflows NoCode/LowCode

1. Ontologie d’entreprise : la colonne vertébrale sémantique

Une ontologie d’entreprise formalise les concepts clés :

• Entités : Client, Contrat, Dossier, Commande, Facture, Incident
• Relations : Un Client a plusieurs Contrats ; un Contrat a un Statut ; une Facture est liée à une Commande
• Événements : Nouveau client onboardé, Facture en retard, Ticket escaladé

Cela fournit :

• un vocabulaire commun pour les humains, les LLM et les outils
• une base pour la désambiguïsation lors de l’analyse des prompts
• un moyen de mapper plusieurs systèmes à des concepts partagés (CRM, ERP, ticketing, GED, etc.)

2. MCP comme couche d’exposition des capacités

Les capacités sont décrites en termes d’ontologie :

• « Créer un nouveau Client avec vérification d’identité et contrôles KYC. »
• « Générer un ChurnRiskScore pour un Client donné sur une période. »

Chaque capacité inclut :

• une description lisible par un humain
• des paramètres alignés avec l’ontologie
• l’implémentation technique (appels d’API, scénarios NoCode, RPA, scripts)
• des contraintes et périmètres de sécurité

MCP fournit un protocole standard pour que les modèles sachent :

• quels outils existent
• ce qu’ils font
• comment les appeler en toute sécurité

3. Orchestrateurs agentiques

Au‑dessus de MCP, les agents LLM agissent en orchestrateurs :

• interprètent l’intention utilisateur
• la décomposent en sous‑objectifs
• sélectionnent et séquencent les capacités
• maintiennent une mémoire de contexte entre les étapes
• posent des questions de clarification si nécessaire

Parmi les patterns :

• Copilotes mono‑domaine (ex. uniquement Finance ou RH) pour un périmètre maîtrisé
• Meta‑agents qui décident quel agent spécialisé impliquer
• Composants de garde‑fou pour valider les plans avant exécution (contrôles de politique, de coût, de périmètre de données)

4. Intégration avec NoCode/LowCode

Les plateformes NoCode deviennent :

• des hôtes d’implémentation pour les capacités (workflows, automatisations, micro‑apps UI)
• des outils visuels de débogage du comportement des agents (inspecter ce que l’agent a déclenché)
• un pont vers les systèmes legacy via des connecteurs existants et des bots RPA

On obtient une stack où :

• l’ontologie définit le sens
• MCP décrit comment agir dans ce domaine
• les agents pilotent l’orchestration
• le NoCode accélère l’implémentation et l’adaptation

---

Cas d’usage concrets : du prompt au processus métier complet

1. Data en self‑service : des tickets SQL à l’analytics conversationnel

📊 Problème

Les équipes métier dépendent des analystes pour :

• écrire des requêtes SQL
• combiner les données de plusieurs systèmes
• générer rapports et dashboards

Ce qui entraîne :

• des délais importants
• des équipes data surchargées
• une prolifération d’extractions incohérentes

🧠 Approche orientée intention

Un utilisateur demande :

« Donne‑moi le chiffre d’affaires des 6 derniers mois par région pour les clients SMB, compare avec les 6 mois précédents, et mets en évidence les segments où le risque de churn a augmenté. »

En coulisses :

1. L’agent interprète des termes comme « clients SMB », « chiffre d’affaires », « risque de churn » via l’ontologie d’entreprise.
2. MCP expose des capacités telles que :
   • GetClientSegments
   • GetRevenueMetrics
   • ComputeChurnRisk
3. L’orchestrateur compose un workflow :
   • récupérer les segments
   • agréger le chiffre d’affaires
   • récupérer ou calculer des indicateurs de churn
   • assembler les résultats sous forme de tableau et de résumé textuel
4. Si besoin, un outil NoCode (par ex. n8n, Make) exécute des requêtes vers les data warehouses et APIs de BI.

✅ Résultat

• Data en self‑service sans écrire de SQL
• Latence réduite de plusieurs jours à quelques minutes
• Les équipes data se concentrent sur la qualité des modèles et la gouvernance plutôt que sur des demandes manuelles

⚠️ Limites et risques

• Nécessite une gouvernance data robuste, des couches sémantiques et un contrôle d’accès solide
• Une ontologie mal conçue produit des réponses trompeuses
• Les agrégations et approximations doivent être auditables en contexte réglementaire

---

2. Onboarding client automatisé : un prompt, de multiples systèmes

📂 Problème

L’onboarding client implique souvent :

• des contrôles KYC/AML
• la vérification d’identité
• la création de comptes dans le CRM, la facturation et les systèmes de contrats
• la génération et le stockage de documents

Les APIs traditionnelles automatisent cela partiellement, mais les équipes opérations gèrent encore :

• de multiples formulaires
• de la saisie manuelle
• la coordination entre départements

🧠 Approche orientée intention

Un conseiller lance l’onboarding avec :

« Onboarde ce nouveau client corporate à partir des documents déposés, lance un KYC complet, crée le contrat et provisionne les comptes nécessaires pour notre offre “Premium Business”. »

En coulisses :

1. L’agent extrait les informations des documents (OCR + extraction via LLM).
2. Des capacités exposées via MCP incluent :
   • VerifyCompanyIdentity
   • RunKYCChecks
   • CreateCRMRecord
   • GenerateContract
   • CreateBillingAccount
   • CreateUserAccessProfiles
3. Un plan d’orchestration est construit et validé par rapport aux règles de politique.
4. Des workflows NoCode interagissent avec le CRM, les APIs KYC, les outils de signature électronique et les systèmes IAM.
5. L’agent remonte : statut, documents manquants, points de blocage.

✅ Résultat

• Moins de changements de contexte pour les conseillers
• Application cohérente des règles d’onboarding
• Activation plus rapide des clients

⚠️ Limites et risques

• Une forte pression réglementaire impose des étapes d’audit et d’approbation rigoureuses
• L’extraction via LLM doit être contrôlée par des seuils de qualité
• Le traitement de données personnelles sensibles suppose des contrôles stricts de protection des données

---

3. Copilote métier au‑dessus de back‑offices legacy

🏢 Problème

Les systèmes back‑office legacy (AS/400, mainframes, ERP maison) :

• ont des interfaces cryptiques
• exposent des APIs incomplètes ou fragiles
• nécessitent un savoir‑faire implicite important

La formation des nouveaux employés est lente et sujette à l’erreur.

🧠 Approche orientée intention

Un gestionnaire de compte demande :

« Montre‑moi tous les sinistres ouverts pour le client Dupont, mets en évidence ceux de plus de 30 jours, et rédige un email de statut résumant les principaux points de blocage. »

En coulisses :

1. Un ensemble de capacités masque la complexité legacy :
   • GetClientByName (faisant proxy vers plusieurs systèmes)
   • ListOpenClaimsForClient
   • SummarizeClaimStatus
2. Certaines capacités appellent des workflows NoCode ou des bots RPA qui interagissent avec des terminaux “écran vert” ou d’anciennes UIs.
3. L’agent combine données factuelles et génération narrative, en proposant un brouillon d’email.
4. L’humain relit et édite avant envoi.

✅ Résultat

• Un copilote métier qui réduit la charge cognitive
• Les experts métier peuvent agir sans maîtriser chaque interface legacy
• Moins de dépendance vis‑à‑vis de quelques “vétérans du système”

⚠️ Limites et risques

• Les interactions de type RPA avec des systèmes legacy sont fragiles
• Besoin de droits d’accès par rôle précis pour éviter une surexposition de données sensibles
• Les communications générées doivent être soigneusement relues en contexte régulé

---

Gouvernance, audit et « prompt collapse » : gérer les nouveaux risques

Le passage aux interfaces en langage naturel introduit des risques différents de ceux des APIs traditionnelles.

1. Gouvernance et contrôle d’accès

🔐 Questions clés :

• Quelles intentions sont autorisées pour chaque rôle ?
• Un agent peut‑il chaîner des capacités entre domaines d’une façon impossible pour un humain ?
• Où le consentement est‑il capturé et appliqué ?

Contrôles recommandés :

• Permissions au niveau des capacités, pas seulement des scopes d’API
• Accès contextuel (par ex. données de sinistres uniquement pour les portefeuilles assignés)
• Séparation des modes lecture, simulation et exécution

2. Audit et traçabilité des appels d’outils

Avec des workflows agentiques, les équipes de conformité doivent pouvoir répondre :

• Quelles capacités ont été utilisées ?
• Avec quels paramètres et périmètres de données ?
• Sous quelle identité utilisateur et à quel moment ?
• Qui a approuvé ou revu le résultat ?

Mécanismes utiles :

• Journalisation des appels d’outils avec snapshots de contexte complets
• Lien entre prompt, plan, appels d’outils et sortie finale
• Intégration des logs aux stacks d’audit / SIEM existantes
• Capacités de “replay” pour l’analyse d’incidents

3. Prompt collapse et sur‑centralisation

Le “prompt collapse” décrit la situation où :

• chaque interaction devient “juste” une conversation
• les systèmes sous‑jacents disparaissent derrière une couche d’IA opaque
• les organisations risquent de devenir « une API avec une interface en langage naturel » sans transparence adéquate

Risques associés :

• logique de décision cachée, difficile à expliquer aux régulateurs
• sur‑dépendance cognitive au copilote
• faible visibilité sur quel système a réellement fourni quelles données

Stratégies de mitigation :

• UX transparente : afficher quels systèmes et capacités ont été utilisés
• Outils d’explicabilité : exposer les traces de raisonnement et critères de décision lorsque possible
• Points de contrôle humain‑dans‑la‑boucle pour les actions à fort impact
• Distinction claire entre recommandation et exécution

---

Nouveaux rôles : capability architect, ontology engineer, agent enablement

Cette transformation n’est pas seulement technique. Elle reconfigure l’organisation des équipes IT et produit.

Capability architect

🏗️ Focus :

• concevoir et maintenir le catalogue de capacités
• décider quelles opérations métier sont exposées aux agents
• s’assurer que chaque capacité possède des sémantiques, entrées, sorties et politiques claires
• travailler étroitement avec la sécurité, la conformité et les experts métier

Ce rôle fait le lien entre architecture d’entreprise et product ownership, mais avec une vision orientée intention.

Ontology engineer

📚 Focus :

• construire et faire évoluer l’ontologie d’entreprise
• aligner les concepts entre CRM, ERP, DWH, ticketing, SIRH
• gérer les mappings entre schémas physiques et modèles sémantiques
• définir les standards de nommage et les patterns de relations

Ce rôle devient critique pour la data en self‑service, l’analytics et toute interface conversationnelle.

Agent enablement / spécialiste de l’orchestration

🤖 Focus :

• configurer et monitorer les agents LLM et leurs règles d’orchestration
• ajuster prompts, logique de sélection d’outils et contrôles de sécurité
• analyser la télémétrie : quelles capacités sont utilisées, où les agents échouent, où les humains reprennent la main
• coordonner avec les builders NoCode/LowCode pour transformer les patterns récurrents en capacités réutilisables

Ce rôle se situe à l’intersection du MLOps, du DevOps et des équipes d’automatisation, avec une forte exigence de fiabilité opérationnelle.

---

Points clés à retenir

• MCP et les agents LLM déplacent l’intégration des appels d’endpoints vers l’orchestration d’intentions, où les capacités remplacent les APIs brutes comme unité de conception principale.
• Les plateformes NoCode/LowCode peuvent devenir de puissants backplanes de capacités en exposant leurs workflows via MCP et en alignant les entrées sur une ontologie d’entreprise partagée.
• Les interfaces en langage naturel permettent la data en self‑service, l’onboarding automatisé et des copilotes métiers au‑dessus de systèmes legacy, mais exigent une gouvernance rigoureuse.
• Un déploiement efficace requiert de nouvelles pratiques de gouvernance, d’audit et de contrôle d’accès, incluant une traçabilité complète des appels d’outils et des garde‑fous clairs.
• Les organisations auront besoin de rôles comme capability architect, ontology engineer et agent enablement specialist pour piloter ces architectures agentiques, orientées intention.