Développeur supervisant les données, le code et les métriques d’un serveur MCP pour logiciel métier.

MCP sur mesure

Développement MCP pour logiciels métier au Maroc

Nous qualifions les interfaces de votre logiciel — API, COM, ODBC ou exports — puis développons un serveur MCP pour les assistants compatibles. Les accès, les actions autorisées et les critères de recette sont définis avant le pilote.

En bref

MCP (Model Context Protocol) ne remplace pas une API : il standardise la façon dont un assistant IA appelle des outils et consulte des données. Hunter BI, agence d'ingénierie IA basée à Casablanca, vérifie d'abord les interfaces réellement disponibles sur votre version — API, COM, ODBC, SDK ou export — puis conçoit le serveur MCP, ses permissions, ses journaux et ses tests.

Ce que nous livrons

D'une automation locale à un outil pour votre agent IA

Le périmètre et les livrables sont précisés au devis, après vérification des interfaces disponibles et des droits accordés.

Audit de connectivité

Nous cartographions ce qui existe réellement derrière votre logiciel — automation COM, interface ODBC, export planifié, ou API sous accord partenaire — avant d'écrire une ligne de code.

Serveur MCP sur mesure

Un catalogue d'outils avec leurs entrées, résultats et erreurs attendues, puis une implémentation adaptée à l'interface retenue. Un connecteur existant peut être évalué : le développement porte sur les besoins qui ne sont pas couverts.

Sécurisation et déploiement

Une matrice de permissions, une configuration de déploiement et un rapport de tests d'accès. Lecture et écriture sont séparées ; les actions sensibles doivent être approuvées selon les règles définies avec votre équipe.

Maintenance et support

Une documentation d'exploitation, les versions testées et les dépendances à surveiller. Les mises à jour du logiciel, du client ou du protocole nécessitent des tests de non-régression. Le périmètre du support est convenu au contrat.

Architecture MCP

Du besoin utilisateur à l'accès métier contrôlé

Schéma de référence proposé : il décrit les responsabilités à mettre en place, pas un déploiement client déjà réalisé.

  1. Assistant et client MCP

    L'utilisateur formule sa demande. L'application présente l'action à approuver lorsqu'elle engage le métier.

  2. Serveur MCP et contrôles

    Le serveur vérifie l'identité, les permissions et les paramètres. Seuls les outils prévus sont exposés.

  3. Interface autorisée

    Une API, un SDK, une interface locale ou un export fournit l'accès réellement disponible, dans les droits accordés.

  4. Logiciel métier

    Le résultat est relu, limité aux champs utiles et renvoyé à l'assistant. Une erreur doit être signalée, pas masquée.

Aller : demande, contrôle, accès autorisé. Retour : résultat métier, filtrage, réponse à l'assistant. Une validation humaine ne remplace pas les contrôles côté serveur et côté logiciel.

Le transport est choisi selon le client : stdio pour un processus local, ou Streamable HTTP pour un serveur distant. Les flux d'identité, l'hébergement et les données transmises au modèle doivent être vérifiés séparément. MCP ne fournit pas automatiquement ces protections.

Checklist de sécurité et de recette

Six contrôles à prouver avant la mise en service

Ce sont des critères de test proposés. Seuls les résultats obtenus sur votre installation permettent de valider le connecteur ; cette checklist n'est pas une certification.

Droits minimaux

Tester un utilisateur autorisé, un utilisateur interdit et un accès hors périmètre. Livrable attendu : matrice des droits et résultats prouvant que le serveur refuse les opérations non autorisées.

Écritures approuvées

Vérifier la cible et le contenu avant l'exécution d'une action sensible, puis relire le résultat. Tester le refus, l'approbation devenue obsolète et la prévention d'un doublon après une réponse incertaine.

Identité et secrets

Contrôler le compte d'exécution en local et l'autorisation du serveur distant. Dans un flux OAuth, refuser un jeton destiné à une autre ressource. Tester la révocation ; ne pas placer les secrets dans les outils ni dans les journaux.

Données et instructions hostiles

Limiter les champs renvoyés et la taille des réponses. Tester un document contenant une consigne malveillante : son contenu ne doit pas élargir les droits de l'assistant. Documenter les données envoyées au modèle.

Pannes et traçabilité

Tester une interface indisponible, un délai dépassé et un résultat invalide. Le rapport doit permettre de relier demande, outil et résultat, sans exposer de secret. Prévoir qui reçoit l'alerte et comment suspendre le connecteur.

Compatibilité et exploitation

Rejouer les scénarios sur les clients et versions annoncés. Remettre le catalogue d'outils, les tests, les dépendances et la procédure de mise à jour. Une évolution du logiciel métier déclenche une nouvelle vérification.

Exemples techniques

Des squelettes à adapter à votre logiciel

Configuration

Exemple de déclaration dans Claude Desktop

Ce bloc illustre la déclaration d'un serveur MCP dans Claude Desktop. Il n'est pas exécutable tel quel : la commande, les chemins et les paramètres de connexion doivent être remplacés puis testés sur votre instance.

claude_desktop_config.json
{
  "mcpServers": {
    "logiciel-metier": {
      "command": "python",
      "args": ["-m", "mcp_server_logiciel_metier"],
      "env": {
        "APP_INSTANCE_PATH": "C:\\Program Files\\Editeur\\Application",
        "APP_DB_DSN": "DSN=AppProd"
      }
    }
  }
}

Le serveur

Squelette illustratif d'un serveur MCP

Ce fragment non exécutable montre la structure générale avec le SDK MCP et le transport stdio. L'automation, les objets métier, les contrôles d'accès et les tests dépendent de votre logiciel, de sa version et de votre configuration.

mcp_server_logiciel_metier.py
from mcp.server.fastmcp import FastMCP
import win32com.client  # exemple d'interface COM fictive à qualifier

mcp = FastMCP("logiciel-metier")

@mcp.tool()
def get_record(reference: str) -> dict:
    """Lit une fiche via l'automation COM locale du logiciel."""
    app = win32com.client.Dispatch("Editeur.Application")
    record = app.Find(reference)
    return {"reference": record.Reference, "libelle": record.Libelle}

if __name__ == "__main__":
    mcp.run(transport="stdio")

Logiciels couverts

ERP, gestion, CAO et création 3D : des interfaces à qualifier

API, SDK, automation locale, base de données ou export : le point d'entrée dépend de l'éditeur, de la version et de votre installation.

Opérateur consultant une tablette technique dans un atelier logistique, connecteur MCP GMAO GPAO
Gestion, maintenance, production : des interfaces différentes à qualifier pour chaque logiciel. Illustration.

FAQ

Questions fréquentes

MCP, quelle est la différence avec une API ?

Une API est une porte que l'éditeur du logiciel choisit d'ouvrir, avec ses propres règles. MCP est un protocole qui standardise la façon dont un agent IA appelle un outil — mais il faut toujours un point d'entrée réel derrière : automation COM, ODBC, fichier d'échange, ou une API existante. MCP ne crée pas d'accès qui n'existait pas ; il rend accessible à un agent IA ce qui était jusque-là réservé à un développeur.

Mon logiciel n'a vraiment aucune API — c'est possible de le connecter quand même ?

Cela dépend de la version, des modules installés et des droits accordés. Une API n'est pas la seule interface possible : COM, DLL, ODBC ou fichiers d'échange peuvent parfois fournir l'accès nécessaire. Hunter BI inspecte votre configuration avant de confirmer le périmètre réalisable.

Combien de temps pour un connecteur MCP sur mesure ?

Le délai se définit après l'inspection de l'interface disponible, des actions autorisées et du niveau de sécurité attendu. Un premier lot doit rester ciblé — par exemple consulter une fiche ou préparer un document — puis être testé sur votre instance avant d'élargir le périmètre.

Nos données restent-elles chez nous ?

Héberger le serveur MCP chez vous ne garantit pas que les données restent locales. Un assistant cloud peut transmettre au fournisseur du modèle les résultats des outils et le contexte de conversation. Le cadrage doit cartographier ces flux et limiter les champs retournés. Une exigence de traitement strictement interne implique de vérifier toute la chaîne : assistant, modèle, connecteur, journaux et services tiers.

Le même serveur MCP fonctionne-t-il dans tous les assistants ?

Non, la compatibilité doit être testée. Le client doit prendre en charge la version du protocole, le transport, les outils et l'authentification retenus. Un serveur local en stdio n'est pas directement accessible à un assistant cloud. Le dossier de livraison indique les clients, les versions et les opérations effectivement testés, sans promettre une compatibilité universelle.

Quelles informations préparer pour un devis de développement MCP ?

Indiquez l'éditeur, la version et les modules du logiciel, son hébergement, l'assistant visé et une première tâche à réaliser. Précisez si l'accès est en lecture seule ou autorise une écriture, les utilisateurs concernés et l'existence d'un environnement de test. Ne transmettez pas de mots de passe, de clés API ni de données de paie dans le formulaire de contact.

Quel outil métier souhaitez-vous connecter à l'IA ?

Indiquez votre logiciel, sa version, l'assistant visé et une première tâche. Nous pourrons cadrer l'accès à vérifier et le périmètre d'un pilote.