MCP entreprise IA

L’IA dans les logiciels métiers : pourquoi nous croyons à une architecture ouverte fondée sur MCP

Pendant plusieurs années, l’intelligence artificielle a surtout été ajoutée aux logiciels sous la forme d’un assistant intégré : un bouton, une fenêtre de conversation ou un copilote propre à chaque application. L’importance de l’architecture ouverte dans cette optique est cruciale pour l’entreprise MCP entreprise IA.

Cette première étape a démontré l’intérêt de l’IA dans l’entreprise. Mais elle soulève aussi une question structurante : faut-il réellement disposer d’une IA différente dans chaque logiciel métier ?

Chez Cloud Store, nous pensons que l’avenir repose davantage sur une architecture ouverte. Les logiciels métiers doivent rester les systèmes de référence, tout en exposant de manière sécurisée leurs données et leurs actions aux intelligences artificielles par l’intermédiaire de serveurs MCP.

Notre principe est simple : MCP par défaut ; IA intégrée lorsqu’elle apporte un avantage métier irremplaçable.

MCP : une interface commune entre l’IA et les logiciels

Le Model Context Protocol, ou MCP, est un protocole ouvert qui standardise la manière dont une application d’IA accède à des données, découvre des outils et déclenche des actions dans un système externe.

Un serveur MCP peut notamment exposer :

  • des ressources, comme des appareils, des tickets, des clients ou des documents ;
  • des outils permettant de rechercher, créer, modifier ou déclencher une action ;
  • des instructions structurées destinées à guider l’utilisation de ces fonctionnalités.

Le protocole distingue l’application d’IA, qui héberge le raisonnement, du serveur MCP, qui donne accès au logiciel métier. Cette séparation rend les intégrations composables : un même agent peut, si son environnement le permet, utiliser plusieurs serveurs au cours d’une même mission.

📖 Spécification officielle MCP

MCP ne remplace pas nécessairement les API. L’API demeure souvent l’interface technique fondamentale du logiciel. Le serveur MCP constitue une couche adaptée aux agents, qui décrit les données et les actions dans un format qu’un environnement d’IA peut découvrir et utiliser.

Notre attente : Tout logiciel métier disposant d’une API devrait progressivement proposer une interface MCP officielle, sécurisée et documentée.

Notre architecture cible repose sur quatre composantes

Voici les 4 éléments clés d’une architecture ouverte fondée sur MCP :

Architecture ouverte MCP
Architecture cible de l’IA métier avec MCP

1. Les logiciels métiers, systèmes de référence

Le logiciel métier reste propriétaire de ses données, de ses règles, de ses autorisations et de ses journaux d’activité. Son serveur MCP expose uniquement les capacités utiles et autorisées. Il ne doit jamais permettre de contourner les droits définis dans l’application.

2. Les environnements d’IA compatibles avec plusieurs serveurs MCP

L’entreprise doit pouvoir choisir l’environnement d’IA correspondant à ses besoins : Claude, ChatGPT, Gemini ou une autre solution compatible.

Le choix peut alors dépendre de la qualité du raisonnement, de l’ergonomie, des modalités d’hébergement, des règles de sécurité ou du modèle économique, sans obliger l’entreprise à reconstruire toutes ses intégrations métiers.

Dans le contexte de l’évolution technologique, la mise en œuvre de solutions basées sur MCP entreprise IA est essentielle pour rester compétitif.

3. Les agents chargés d’orchestrer les processus

L’agent apporte la logique opérationnelle. Il reçoit un objectif, recherche les informations nécessaires dans différents systèmes, construit un plan d’action et utilise les outils auxquels il est autorisé à accéder.

L’agent n’est donc pas un logiciel métier supplémentaire. Il devient l’orchestrateur entre plusieurs logiciels spécialisés.

4. Une couche de gouvernance

Cette quatrième composante est indispensable. Elle garantit :

  • l’identité de la personne ou du service qui agit ;
  • l’application des permissions ;
  • la validation humaine des opérations sensibles ;
  • la journalisation des actions ;
  • la révocation des accès ;
  • la séparation entre les environnements de test et de production.

Sans cette gouvernance, une architecture ouverte pourrait simplement déplacer la dépendance et augmenter le risque.

Les avantages d’une architecture ouverte

✓ Conserver le choix de l’IA

Le serveur MCP appartient à la couche métier, indépendamment du modèle utilisé. Une organisation peut ainsi faire évoluer son environnement d’IA sans reconstruire systématiquement toutes les connexions avec ses applications.

✓ Construire des processus entre plusieurs métiers

Un incident informatique ne commence pas toujours dans l’outil de gestion de parc. Un agent ayant accès à plusieurs serveurs MCP peut rapprocher ces éléments et coordonner les logiciels concernés.

✓ Réutiliser les intégrations

Un serveur MCP correctement conçu peut servir plusieurs agents et plusieurs environnements compatibles. L’investissement réalisé pour ouvrir le logiciel ne dépend plus d’une seule interface conversationnelle.

✓ Mutualiser la capacité d’IA entre les logiciels

Une architecture fondée sur MCP permet de mutualiser davantage la couche de raisonnement et d’orchestration. L’entreprise peut connecter plusieurs logiciels à un environnement d’IA commun.

Nous ne savons pas si cette architecture est systématiquement moins chère. Son avantage robuste est la réutilisation d’une même capacité d’IA entre plusieurs systèmes.

✓ Donner à l’IA un cadre d’action explicite

Les outils disponibles sont décrits par le serveur. L’agent appelle donc des opérations identifiées, accompagnées de paramètres structurés.

✓ Appliquer les droits du logiciel métier

Le serveur MCP peut reprendre les autorisations de l’utilisateur connecté. PDQ indique par exemple que son serveur applique les permissions du compte PDQ Connect et que les opérations modificatrices réalisées par MCP sont inscrites dans ses journaux d’audit.

✓ Déployer l’automatisation progressivement

Une organisation peut commencer par la consultation en lecture seule, puis autoriser progressivement certaines actions.

MCP déplace le risque d’enfermement, il ne le supprime pas

Si les logiciels métiers deviennent interchangeables derrière des interfaces MCP, l’agent, l’orchestrateur et la plateforme de gouvernance peuvent devenir le nouveau centre de gravité.

MCP peut libérer l’accès aux logiciels métiers sans garantir la liberté vis-à-vis du fournisseur d’agents.

Ce risque doit être traité dès la conception :

  • conserver les instructions et règles métier dans des formats exportables ;
  • documenter les dépendances propres à l’orchestrateur ;
  • pouvoir remplacer le modèle sans réécrire tout le processus ;
  • prévoir l’export des journaux, configurations et évaluations ;
  • éviter qu’une fonction critique ne dépende d’un outil propriétaire impossible à reproduire ;
  • tester régulièrement un scénario de réversibilité.

Un serveur MCP n’est pas nécessairement un bon serveur MCP

La conformité technique au protocole ne garantit pas la qualité métier de l’intégration.

Un serveur insuffisamment conçu peut présenter :

  • des outils trop généraux ou trop puissants ;
  • des descriptions ambiguës ;
  • des paramètres mal documentés ;
  • des résultats difficiles à interpréter ;
  • une mauvaise séparation entre lecture et écriture ;
  • des erreurs peu exploitables ;
  • une journalisation insuffisante ;
  • aucune protection adaptée aux opérations de masse.

Cloud Store ne devrait pas seulement demander aux éditeurs « avez-vous un serveur MCP ? », mais aussi « votre serveur MCP est-il suffisamment sûr, précis et réversible pour être utilisé en production ? »

Pourquoi l’IA intégrée conserve sa place

Nous ne pensons pas que l’IA directement intégrée au logiciel doive disparaître. Elle reste pertinente lorsqu’elle apporte une valeur indissociable du produit :

  • accompagner l’utilisateur dans un écran complexe ;
  • exploiter un modèle ou des règles fortement spécialisés ;
  • intervenir avec une très faible latence ;
  • fonctionner dans un contexte hors ligne ou fortement cloisonné ;
  • personnaliser profondément un processus métier ;
  • fournir une expérience contrôlée de bout en bout par l’éditeur.

Pour les fonctions génériques de dialogue, de synthèse et d’orchestration, nous privilégions une IA choisie par l’entreprise et reliée aux applications par MCP.

L’exemple de la gestion de parc avec PDQ Connect

PDQ Connect propose actuellement un serveur MCP en accès anticipé.

Workflow incident PDQ Connect
Workflow de gestion d’incident avec PDQ Connect et MCP

Prenons le cas d’un incident reçu par e-mail ou créé dans un logiciel de ticketing :

  1. Un message ou une alerte signale un problème sur un poste.
  2. L’agent informatique reçoit le contexte par un connecteur autorisé.
  3. Il recherche l’appareil concerné dans PDQ Connect.
  4. Il analyse les informations du ticket et les vulnérabilités détectées.
  5. Il prépare une proposition de remédiation.
  6. Une personne valide l’intervention lorsque l’action est sensible.
  7. L’agent déclenche le déploiement du correctif.
  8. Il vérifie le résultat, met le ticket à jour et prépare l’information destinée à l’utilisateur.

Ce workflow constitue une architecture possible, pas une intégration universelle prête à l’emploi.

⚠️ Le principal risque : l’injection de prompt indirecte

Une boîte mail ou un outil de tickets reçoit du contenu provenant de l’extérieur. Ce contenu doit être considéré comme non fiable, même lorsque le canal lui-même est autorisé.

Un attaquant pourrait insérer dans un message des instructions destinées non pas au technicien, mais à l’agent qui analysera le contenu. Si cet agent possède également des droits d’administration sur le parc, une simple donnée entrante pourrait influencer une action sensible.

Nous recommandons notamment :

  • de séparer l’agent qui collecte les contenus externes de celui qui exécute les actions d’administration ;
  • de transformer les données entrantes en faits structurés avant de les transmettre à l’agent d’action ;
  • d’interdire à un contenu externe de modifier les règles ou les objectifs de l’agent ;
  • d’utiliser des listes d’actions autorisées et des périmètres de machines explicites ;
  • d’exiger une validation humaine indépendante pour un déploiement sensible ou étendu ;
  • de tester les agents avec des scénarios d’injection avant leur passage en production ;
  • de permettre l’arrêt et la révocation immédiate des accès.

Souveraineté, localisation et RGPD

Connecter des tickets, des e-mails ou des données de parc à une IA peut entraîner le traitement de données personnelles, d’informations techniques sensibles ou de secrets d’entreprise.

Avant tout déploiement, l’organisation doit notamment identifier :

  • les catégories de données transmises ;
  • les finalités du traitement ;
  • les rôles respectifs du client, de l’intégrateur et des fournisseurs ;
  • les lieux de traitement et de stockage ;
  • les éventuels transferts hors de l’Espace économique européenne ;
  • les durées de conservation des requêtes, réponses et journaux ;
  • l’utilisation éventuelle des données pour améliorer les services ou les modèles ;
  • les mécanismes de suppression, d’export et de réversibilité.

📖 Recommandations de la CNIL du 22 juillet 2025

La bonne formulation est : connecter uniquement les services, les données et les actions compatibles avec la doctrine de sécurité, le cadre contractuel et les obligations réglementaires de l’organisation.

Qui répond lorsque l’agent se trompe ?

Lorsqu’un agent déclenche une mauvaise opération, plusieurs acteurs interviennent : l’éditeur du logiciel métier, le fournisseur du serveur MCP, l’orchestrateur, le fournisseur du modèle, l’intégrateur et l’organisation utilisatrice.

Cette incertitude doit être traitée avant la mise en production, et non après un incident.

Le contrat et la documentation d’exploitation devraient préciser au minimum :

  • qui maintient le serveur MCP et ses outils ;
  • qui valide les changements de périmètre ;
  • qui répond d’une erreur d’exécution ou d’une indisponibilité ;
  • quelles preuves sont conservées ;
  • quelles actions exigent une validation humaine ;
  • comment un incident est détecté, arrêté, corrigé et notifié ;
  • comment les données et configurations sont restituées en fin de contrat.

Les services Cloud Store disposant d’un accès MCP vérifié

Liste consultée le 11 septembre 2026

Serveurs MCP fournis ou documentés par l’éditeur

PDQ Connect — serveur MCP distant en accès anticipé pour consulter le parc et effectuer certaines opérations. Documentation PDQ

Dropbox — serveur MCP distant en bêta ouverte pour rechercher, consulter et utiliser les contenus Dropbox. Dropbox MCPDropbox Dash MCP

DocuSign — offre MCP en cours de généralisation. Annonce DocuSign

Zoom Workplace — Zoom documente des passerelles MCP régionales, dont une pour l’Union européenne. Documentation Zoom MCP

Applications accessibles par Zoho MCP

Zoho permet de créer un serveur MCP et d’y ajouter les outils correspondant aux services autorisés. Liste officielle Zoho MCP :

Services tiers mobilisables par Zoho MCP

La liste des services tiers Zoho MCP contient également plusieurs produits Cloud Store :

Une architecture ouverte exige une gouvernance forte

MCP facilite les connexions, mais ne garantit pas à lui seul leur sécurité. Pour une exploitation professionnelle, nous recommandons :

  • de n’activer que les outils nécessaires ;
  • de commencer en lecture seule ;
  • d’appliquer les droits de l’utilisateur authentifié ;
  • de demander une confirmation avant les actions sensibles ;
  • de journaliser les opérations ;
  • de contrôler les serveurs auxquels l’IA peut se connecter ;
  • de protéger les jetons et secrets d’authentification ;
  • de tester les risques d’injection de prompt ;
  • de prévoir une procédure de révocation immédiate.

La grille de qualification MCP pour cahier des charges

La question « le produit possède-t-il un serveur MCP ? » est insuffisante. Cloud Store recommande d’évaluer les critères suivants :

📋 Origine et maintenance

  • Le serveur est-il fourni ou officiellement reconnu par l’éditeur ?
  • Qui le maintient et selon quel engagement de service ?
  • Les versions du protocole et du serveur sont-elles documentées ?
  • Les changements d’outils font-ils l’objet d’un historique et d’un préavis ?

🔐 Authentification et autorisations

  • L’authentification repose-t-elle sur OAuth ou un mécanisme équivalent ?
  • Le serveur hérite-t-il réellement des rôles et permissions du logiciel métier ?
  • Les droits peuvent-ils être limités par utilisateur, groupe, client ou site ?
  • Les jetons sont-ils courts, révocables et stockés de manière sécurisée ?

⚙️ Qualité des outils

  • Les outils sont-ils séparés entre consultation et modification ?
  • Les noms, descriptions, paramètres, résultats et erreurs sont-ils explicites ?
  • Les actions de masse comportent-elles des limites et des garde-fous ?
  • Le serveur permet-il un mode de simulation ou de préparation ?
  • Les opérations sont-elles idempotentes lorsque cela est nécessaire ?

👥 Contrôle humain et sécurité

  • Quelles opérations nécessitent une confirmation ?
  • Peut-on imposer une double validation selon le niveau de risque ?
  • Les contenus externes sont-ils isolés des instructions de l’agent ?
  • Des tests d’injection de prompt et d’abus d’outils sont-ils réalisés ?
  • Existe-t-il un bouton d’arrêt et une révocation immédiate ?

📊 Journalisation et preuve

  • Chaque action indique-t-elle l’utilisateur, l’agent, le client MCP et l’outil concernés ?
  • Les paramètres, résultats, validations et erreurs sont-ils conservés ?
  • Les journaux sont-ils exportables vers le système de supervision du client ?
  • La durée de conservation est-elle configurable ?

🌍 Données, souveraineté et conformité

  • Où sont traitées et stockées les données ?
  • Quelles données sont transmises au modèle, au client MCP et au serveur ?
  • Les données peuvent-elles être exclues de l’entraînement ou de l’amélioration du service ?
  • Les exigences RGPD et les éventuels transferts internationaux sont-ils documentés ?
  • Le service est-il compatible avec la doctrine applicable ?

♻️ Réversibilité

  • Les configurations, journaux et règles d’agents sont-ils exportables ?
  • Le serveur peut-il être utilisé avec plusieurs clients et plusieurs modèles ?
  • Peut-on changer d’orchestrateur sans reconstruire entièrement les workflows ?
  • Que devient l’accès MCP à la fin du contrat ?

Notre vision pour Cloud Store

Le rôle de Cloud Store ne sera pas seulement de distribuer des licences. Il consistera de plus en plus à aider les organisations à construire et gouverner un environnement cohérent :

  1. Choisir des logiciels métiers qui restent les systèmes de référence ;
  2. Privilégier les produits capables d’exposer leurs fonctions par MCP ;
  3. Sélectionner une ou plusieurs IA compatibles avec la politique de l’entreprise ;
  4. Concevoir des agents adaptés aux processus réels ;
  5. Encadrer leurs droits, leurs validations et leur traçabilité ;
  6. Vérifier la souveraineté, les responsabilités contractuelles et la réversibilité.

Nous pensons que la valeur ne viendra pas d’une accumulation d’assistants indépendants. Elle viendra de la capacité à faire coopérer les bons logiciels, la bonne IA et des agents correctement gouvernés.

Le logiciel métier fournit les données et les actions. L’IA comprend la demande. L’agent organise le travail. La gouvernance maintient le contrôle. MCP leur fournit un langage commun.

C’est cette architecture ouverte, évolutive et maîtrisable que Cloud Store souhaite accompagner.

L’enjeu n’est pas seulement de connecter l’IA aux logiciels. Il est de permettre cette connexion sans perdre le contrôle, la responsabilité ni la liberté de choisir demain.

Prêt à explorer une architecture ouverte avec Cloud Store ?

Discutez de vos besoins avec nos experts Cloud Store

💬 Contacter un expert

 

Tags: IA, RGPD, Sécurité