Intelligence Artificielle (IA)

005Model Context Protocol (MCP)

Des serveurs MCP qui connectent les assistants IA à vos systèmes

Le Model Context Protocol (MCP) est la norme ouverte qui permet aux assistants IA comme Claude de lire vos données et d'agir au sein de vos outils. Nous concevons et développons des serveurs MCP sur mesure qui exposent vos bases de données, API et workflows internes aux LLM, avec les contrôles d'accès qu'exige votre équipe sécurité. Pour les CTO et responsables produit qui veulent une IA qui s'appuie sur le contexte réel de l'entreprise, pas des réponses génériques.

AI005

Parlons-en
001/

Ce que nous construisons

Ce que comprend un mandat MCP

Un serveur MCP en production, c'est bien plus qu'une simple enveloppe autour de votre API. Nous couvrons tout le parcours, de la conception de l'intégration jusqu'au déploiement et à la supervision.

  1. Audit et conception de l'intégration

    Nous cartographions les systèmes dont votre assistant a besoin, distinguons les opérations de lecture et d'écriture, et identifions où se situe le risque. Vous obtenez une conception du serveur avant même la première ligne de code.

  2. Développement de serveurs MCP sur mesure

    Nous construisons des serveurs qui exposent vos sources de données et API internes sous forme d'outils et de ressources MCP, avec des schémas qu'un LLM peut réellement utiliser de façon fiable.

  3. Authentification et contrôle d'accès

    Flux OAuth, permissions par utilisateur et jetons à portée limitée, pour que l'assistant ne voie que ce que la personne qui l'utilise est autorisée à voir.

  4. Conception d'outils pensée pour la fiabilité

    Nommage des outils, descriptions et structuration des réponses, ajustés pour que le modèle choisisse la bonne opération et gère les erreurs sainement. C'est là que la plupart des projets MCP échouent silencieusement.

  5. Déploiement et hébergement

    Serveurs locaux pour un usage bureau ou serveurs distants derrière votre infrastructure, conteneurisés et intégrés à votre CI/CD et à votre journalisation existants.

  6. Tests et évaluation

    Suites de tests automatisées qui sollicitent chaque outil, complétées par des passes d'évaluation qui mesurent la qualité d'utilisation du serveur par le modèle sur des tâches réalistes, avant que votre équipe n'en dépende.

Notre méthode de travail

Du cas d'usage au serveur en production

(4)
  1. 1

    Cadrer le cas d'usage

    Nous partons de ce que vos utilisateurs ou employés attendent réellement de l'assistant, puis remontons vers l'ensemble minimal d'outils et de sources de données nécessaires.

  2. 2

    Concevoir la surface d'outils

    Nous spécifions chaque outil, ses entrées, ses sorties et ses modes d'échec, puis validons la conception avec vos ingénieurs avant l'implémentation.

  3. 3

    Construction et tests

    Nous implémentons le serveur, branchons l'authentification, et le confrontons à de vrais prompts et cas limites jusqu'à ce que la sélection des outils et la gestion des erreurs tiennent la route.

  4. 4

    Déployer et transférer

    Nous déployons le serveur dans votre environnement, documentons comment l'étendre, et formons votre équipe pour que l'ajout du prochain outil ne nécessite pas de nous rappeler.

003/

Pourquoi Webisoft

Pourquoi les équipes nous confient leurs projets MCP

MCP est une technologie jeune, et la plupart des leçons difficiles ne sont pas encore documentées. Nous construisons des intégrations LLM depuis avant même l'existence du protocole.

  1. Ingénierie IA appliquée, pas des démos

    Nous construisons des systèmes IA qui tournent en production, avec la journalisation, les permissions et la gestion des échecs qui distinguent un prototype d'un système sur lequel votre entreprise peut compter.

  2. La sécurité d'abord

    Les serveurs MCP touchent aux vraies données de l'entreprise. Nous traitons le cadrage des accès, l'exposition aux injections de prompt et les pistes d'audit comme des exigences fondamentales, pas des réflexions après coup.

  3. Équipe à cycle complet

    Ingénieurs backend, spécialistes infrastructure et experts IA sous un même toit, si bien que l'équipe qui conçoit le serveur est aussi celle qui le déploie et le sécurise.

  4. Conçu pour être maintenu

    Vous obtenez du code propre, une documentation et une transmission que vos propres développeurs peuvent prolonger. Aucune boîte noire, aucune dépendance envers nous pour modifier la description d'un outil.

FAQ

Les questions MCP qu'on nous pose le plus

(6)
  1. Les deux plus gros facteurs sont le nombre de systèmes à connecter et la complexité du modèle de permissions. Un serveur en lecture seule sur une API propre, c'est une question de semaines. Un serveur qui couvre plusieurs systèmes hérités, qui exige OAuth par utilisateur et qui inclut des actions d'écriture avec étapes d'approbation prend plus de temps, parce que l'essentiel de l'effort porte sur la correspondance des authentifications, la mise en forme des données et les tests plutôt que sur le protocole lui-même. Nous délimitons une première version fixe pour que vous voyiez du logiciel fonctionnel tôt au lieu de payer pour une longue phase de conception.
  2. Les serveurs stdio locaux conviennent aux développeurs individuels, mais pour une organisation, nous recommandons presque toujours un serveur distant en HTTP diffusable. Un serveur distant vous donne une authentification centralisée, un seul endroit à corriger et à mettre à niveau, une journalisation de l'usage pour la conformité, et aucune dépendance à ce qui est installé sur chaque portable. La contrepartie est que vous exploitez désormais un service, qui exige donc le même traitement de disponibilité et de sécurité que n'importe quelle API interne.
  3. Les permissions sont appliquées dans le serveur, jamais dans le prompt. Chaque requête transporte l'identité de l'utilisateur via OAuth, et le serveur applique vos règles existantes de rôles et de niveau ligne avant que la moindre donnée n'atteigne le modèle, de sorte que le modèle ne peut physiquement pas récupérer ce à quoi l'utilisateur n'a pas accès. Nous limitons aussi étroitement la portée des jetons, nous journalisons chaque appel avec l'identité agissante, et nous plaçons des barrières de confirmation sur tout outil qui écrit ou supprime.
  4. MCP est un standard ouvert, donc un même serveur fonctionne avec Claude, Claude Code et l'ensemble grandissant de clients et de cadriciels qui parlent le protocole, y compris les agents basés sur l'OpenAI Agents SDK et de nombreux outils d'IDE. Cette portabilité est le principal argument en faveur de MCP par rapport à des intégrations de function calling faites sur mesure pour chaque fournisseur. Nous testons avec les clients que vos équipes utilisent réellement et nous gardons le serveur exempt d'hypothèses propres à un client.
  5. Les outils peuvent écrire : créer un billet, mettre à jour une fiche CRM, déclencher un déploiement. La vraie question est le degré d'autonomie accordé. Notre patron par défaut : les outils de lecture s'exécutent librement, les écritures à faible risque s'exécutent avec journalisation, et les écritures à risque élevé exigent une confirmation humaine à même la conversation. Nous définissons cette gradation du risque avec vous durant la phase d'audit pour que les règles reflètent vos exigences de conformité plutôt qu'un gabarit générique.
  6. Commencez par un flux de travail où les employés copient actuellement des données à la main dans un modèle de clavardage, parce que c'est là qu'un serveur MCP démontre sa valeur le plus rapidement. Nous menons un court exercice de cadrage, habituellement une à deux semaines, qui produit l'inventaire d'outils, une recommandation d'architecture et une estimation de coût pour la première version. Si l'audit montre qu'une intégration plus simple vous servirait mieux, nous vous le disons au lieu de construire un serveur dont vous n'avez pas besoin.
005/

Capacités MCP

Où nous apportons de la valeur sur les projets MCP

Un serveur MCP n'est utile que s'il expose les bonnes données, applique les bonnes permissions et reste fiable lorsqu'un modèle l'appelle des milliers de fois par jour. Voici les domaines où notre travail d'ingénierie se rentabilise.

  1. Serveurs MCP sur mesure

    Nous construisons des serveurs MCP en TypeScript ou en Python avec les SDK officiels, en exposant vos systèmes internes sous forme d'outils, de ressources et de prompts. Chaque outil reçoit un schéma JSON précis et une description écrite pour le modèle, pas pour des humains, car des définitions d'outils vagues sont la cause la plus fréquente pour laquelle les agents choisissent le mauvais outil ou transmettent de mauvais arguments.

  2. Connecteurs de systèmes d'entreprise

    Nous connectons les serveurs MCP aux systèmes que vos équipes utilisent déjà : Postgres et Snowflake, Salesforce, SAP, Jira, SharePoint, ainsi que vos API REST ou GraphQL internes. La couche serveur gère la pagination, les limites de débit et les nouvelles tentatives, afin que le modèle reçoive des résultats propres et bornés plutôt que des extraits bruts d'API qui saturent la fenêtre de contexte.

  3. Cartographie de l'authentification et des permissions

    Les appels MCP s'exécutent sous l'identité d'un utilisateur réel, donc nous implémentons des flux OAuth 2.1 et transposons vos rôles existants en permissions par outil et par ligne. Un représentant commercial qui interroge via Claude ne voit que ses propres comptes, et les outils destructeurs peuvent exiger une étape de confirmation explicite avant leur exécution.

  4. Structuration et filtrage du contexte

    Renvoyer un tableau de 400 lignes à un modèle gaspille des jetons et dégrade les réponses. Nous concevons chaque réponse d'outil pour renvoyer des données résumées, classées ou tronquées avec des références que le modèle peut approfondir, ce qui garde les conversations économiques et rend le raisonnement multi-étapes nettement plus précis.

  5. Transport et déploiement

    Nous déployons les serveurs via stdio pour un usage bureau local ou via HTTP en flux continu pour un accès distant partagé, conteneurisés et hébergés dans votre compte cloud. Les serveurs distants reçoivent un traitement opérationnel standard : contrôles de santé, journalisation structurée, mise à l'échelle horizontale et versions publiées, afin qu'un changement de schéma ne casse jamais silencieusement les clients en production.

  6. Évaluation et observabilité

    Avant le lancement, nous constituons un jeu d'évaluation de tâches réalistes et mesurons si le modèle sélectionne les bons outils et produit les bons résultats. En production, chaque appel d'outil est journalisé avec ses arguments, sa latence et son statut, ce qui vous donne une piste d'audit et un moyen concret de repérer et corriger les workflows défaillants.

FAQ

Questions que se posent les acheteurs sur les projets MCP

(6)
  1. Les deux principaux facteurs sont le nombre de systèmes connectés et la complexité du modèle de permissions. Un serveur en lecture seule sur une API propre se règle en quelques semaines. Un serveur qui couvre plusieurs systèmes legacy, exige OAuth par utilisateur, et inclut des actions d'écriture avec étapes d'approbation prend plus de temps, car l'essentiel de l'effort porte sur la cartographie des accès, la structuration des données et les tests plutôt que sur le protocole lui-même. Nous cadrons une première version fixe afin que vous voyiez un logiciel fonctionnel rapidement, plutôt que de payer pour une longue phase de conception.
  2. Les serveurs stdio locaux conviennent aux développeurs individuels, mais pour une organisation, nous recommandons presque toujours un serveur distant en HTTP à flux continu. Un serveur distant vous offre une authentification centralisée, un seul endroit à corriger et mettre à jour, une journalisation d'usage pour la conformité, et aucune dépendance à ce qui est installé sur chaque poste. La contrepartie, c'est que vous exploitez désormais un service, qui doit recevoir le même traitement en matière de disponibilité et de sécurité que toute API interne.
  3. Les permissions sont appliquées dans le serveur, jamais dans le prompt. Chaque requête porte l'identité de l'utilisateur via OAuth, et le serveur applique vos règles existantes de rôle et de niveau de ligne avant que la moindre donnée n'atteigne le modèle, si bien que le modèle ne peut physiquement pas récupérer ce à quoi l'utilisateur n'a pas accès. Nous limitons aussi étroitement la portée des jetons, journalisons chaque appel avec l'identité agissante, et plaçons des verrous de confirmation sur tout outil qui écrit ou supprime.
  4. MCP est une norme ouverte, donc un seul serveur fonctionne avec Claude, Claude Code, et l'ensemble croissant de clients et de frameworks qui parlent le protocole, y compris les agents basés sur l'OpenAI Agents SDK et de nombreux outils d'IDE. Cette portabilité est le principal argument en faveur de MCP plutôt que la construction d'intégrations de function calling sur mesure pour chaque fournisseur. Nous testons sur les clients que vos équipes utilisent réellement et gardons le serveur libre de toute hypothèse propre à un client.
  5. Les outils peuvent écrire : créer un ticket, mettre à jour un enregistrement CRM, déclencher un déploiement. La vraie question est le niveau d'autonomie que vous accordez. Notre schéma par défaut est que les outils de lecture s'exécutent librement, les écritures à faible risque s'exécutent avec journalisation, et les écritures à haut risque exigent une confirmation humaine dans la conversation. Nous définissons cette hiérarchisation du risque avec vous durant la phase d'audit, afin que les règles reflètent vos exigences de conformité plutôt qu'un modèle générique.
  6. Commencez par un workflow où les employés copient actuellement des données à la main dans un modèle de chat, car c'est là qu'un serveur MCP démontre sa valeur le plus rapidement. Nous menons un court exercice de cadrage, généralement une à deux semaines, qui produit l'inventaire d'outils, une recommandation d'architecture et une estimation de coût pour la première version. Si l'audit révèle qu'une intégration plus simple vous servirait mieux, nous vous le disons plutôt que de construire un serveur dont vous n'avez pas besoin.
007/

Capacités MCP

Là où nous ajoutons de la valeur sur les projets MCP

Un serveur MCP n'est utile que s'il expose les bonnes données, applique les bonnes permissions et reste fiable quand un modèle l'appelle des milliers de fois par jour. Voici les domaines où notre travail d'ingénierie se rentabilise.

  1. Serveurs MCP sur mesure

    Nous construisons des serveurs MCP en TypeScript ou en Python avec les SDK officiels, en exposant vos systèmes internes sous forme d'outils, de ressources et de prompts. Chaque outil reçoit un schéma JSON précis et une description rédigée pour le modèle, pas pour les humains, parce que des définitions d'outils vagues sont la raison la plus fréquente pour laquelle les agents choisissent le mauvais outil ou passent de mauvais arguments.

  2. Connecteurs vers les systèmes d'entreprise

    Nous relions les serveurs MCP aux systèmes que vos équipes utilisent déjà : Postgres et Snowflake, Salesforce, SAP, Jira, SharePoint et vos API REST ou GraphQL internes. La couche serveur gère la pagination, les limites de débit et les nouvelles tentatives pour que le modèle reçoive des résultats propres et bornés plutôt que des vidages d'API bruts qui font exploser la fenêtre de contexte.

  3. Authentification et correspondance des permissions

    Les appels MCP s'exécutent avec l'identité d'un utilisateur réel, alors nous implémentons des flux OAuth 2.1 et nous transposons vos rôles existants en permissions par outil et par ligne. Un représentant aux ventes qui interroge via Claude ne voit que ses propres comptes, et les outils destructeurs peuvent exiger une étape de confirmation explicite avant de s'exécuter.

  4. Mise en forme et filtrage du contexte

    Renvoyer un tableau de 400 lignes à un modèle gaspille des tokens et dégrade les réponses. Nous concevons chaque réponse d'outil pour retourner des données résumées, classées ou tronquées, avec des références que le modèle peut suivre au besoin, ce qui garde les conversations économiques et rend le raisonnement en plusieurs étapes nettement plus précis.

  5. Transport et déploiement

    Nous déployons les serveurs en stdio pour un usage local sur poste de travail ou en HTTP diffusable pour un accès distant partagé, conteneurisés et exécutés dans votre compte cloud. Les serveurs distants reçoivent un traitement opérationnel standard : vérifications de santé, journalisation structurée, mise à l'échelle horizontale et versions étiquetées pour qu'un changement de schéma ne brise jamais silencieusement les clients en cours d'exécution.

  6. Évaluation et observabilité

    Avant le lancement, nous construisons un ensemble d'évaluation de tâches réalistes et nous mesurons si le modèle sélectionne les bons outils et produit les bons résultats. En production, chaque appel d'outil est journalisé avec ses arguments, sa latence et son statut de résultat, ce qui vous donne une piste d'audit et un moyen concret de trouver et de corriger les flux de travail défaillants.

Notre approche

Comment se déroule un mandat MCP

(4)
  1. 1

    Audit des flux de travail et des données

    Nous commençons par cartographier les flux de travail que vous voulez confier aux modèles et les systèmes qui détiennent les données requises. Le livrable est un inventaire d'outils bien délimité : quels outils exposer, ce que chacun retourne, quelles permissions s'appliquent et quels flux de travail sont exclus de la première version.
  2. 2

    Conception du serveur et prototype

    Nous définissons les schémas d'outils, les URI de ressources et le modèle d'authentification, puis nous livrons un prototype fonctionnel contre une copie de préproduction de vos données dès les premières semaines. Vous le testez directement dans Claude Desktop ou votre propre client, ce qui fait ressortir les problèmes de nommage et de portée bien avant le renforcement pour la production.
  3. 3

    Renforcement et intégration

    Nous ajoutons OAuth, la limitation de débit, la validation des entrées, la gestion des secrets et la journalisation d'audit, puis nous exécutons la suite d'évaluation sur des tâches réelles. Cette phase couvre aussi le déploiement dans votre infrastructure, que ce soit ECS, Kubernetes ou une plateforme gérée, avec des pipelines CI et un mécanisme de retour arrière en place.
  4. 4

    Déploiement et itération

    Nous lançons auprès d'un groupe pilote, nous passons en revue les journaux d'appels d'outils chaque semaine et nous ajustons les descriptions d'outils et la forme des réponses selon les endroits où le modèle éprouve réellement des difficultés. La plupart des serveurs ont besoin de deux ou trois cycles d'itération avant que la sélection d'outils soit fiable, et nous le prévoyons au lieu de crier victoire au déploiement.

On donne un élan à vos systèmes

Stacks technologiques pour un monde en évolution rapide.
Parlons-en

Wbsft®

Mtl (Can)

Webisoft