Développer des serveurs MCP.
Connecter les systèmes avec précision.
L’IA doit pouvoir travailler de manière ciblée avec les systèmes existants, au-delà des réponses. DAXS développe serveurs MCP et adaptateurs adaptés, avec des outils clairs, des droits limités et des résultats vérifiables.
Un serveur MCP rend des fonctions définies utilisables par les applications d’IA.
Un assistant doit pouvoir lire le statut d’un ticket, rechercher une documentation autorisée ou créer une entrée préparée. Il nécessite un accès clairement décrit et limité. DAXS développe les serveurs MCP et connexions API adaptés aux systèmes d’entreprise existants.
Le Model Context Protocol décrit comment les applications d’IA peuvent notamment utiliser outils, ressources de données et prompts préparés. Un serveur MCP est un adaptateur technique. Un bon nom d’outil ne suffit ni à le sécuriser ni à en faire un agent autonome.
API classique
Une application appelle une fonction définie d’un autre système. Modèle de données, autorisations, validation et traitement des erreurs sont préparés pour cet accès.
Intégration MCP
Un client d’IA compatible peut utiliser fonctions et ressources décrites via un protocole commun. Validation concrète et mise en œuvre dans le système cible restent des tâches propres.
Agent IA
Une application combine modèle, état et outils pour plusieurs étapes. Elle nécessite une mission limitée, des conditions d’arrêt et un contrôle traçable des actions. Un agent peut utiliser MCP ou d’autres API.
Client, interface et système cible vérifient chacun leur périmètre.
L’application d’IA propose un appel d’outil. Le serveur MCP vérifie identité, fonction autorisée et entrées. Le système cible applique aussi ses règles d’accès. Pour les actions critiques, une validation concrète est vérifiée avant exécution.
Le schéma montre une architecture d’exemple pour une intégration spécifique. Les versions compatibles de client, SDK et protocole sont définies et testées avant la réalisation.
La mission détermine les données et actions.
Une interface au système de tickets n’a pas à ouvrir toute la base. Un outil peut, par exemple, fournir uniquement les champs nécessaires à un statut autorisé. Un autre crée exclusivement un brouillon. Des fonctions générales de shell, SQL ou administration offriraient un périmètre inutilement large.
| Type | Outil possible | Vérification importante |
|---|---|---|
| En lecture | Consulter le statut d’un ticket, rechercher une documentation autorisée ou interroger un état technique. | L’utilisateur peut voir l’objet précis ; ne fournir que les champs nécessaires, un volume limité et aucune donnée d’un autre tenant. |
| En écriture, limitée | Préparer un brouillon de réponse ou une note interne structurée. | Vérifier champs et contenus autorisés, identifier clairement le brouillon, maîtriser les répétitions et restituer le résultat de manière traçable. |
| Critique | Déclencher une modification convenue sur un système de production. | Validation supplémentaire liée à l’action et à l’objet cible ; revérifier les droits juste avant exécution et définir limites et retour. |
Même un outil de lecture peut divulguer des informations confidentielles. La lecture seule ne remplace donc pas l’autorisation. Pour l’écriture, nous préparons aussi idempotence, états d’erreur et gestion des résultats incertains : un délai dépassé ne prouve pas que l’action n’a pas été exécutée.
Une connexion réussie n’autorise pas tous les objets.
Nous distinguons connexion au client IA, autorisation sur le serveur MCP et droits dans l’application cible. Contexte utilisateur, groupe et tenant proviennent d’une identité fiable. Le modèle ne peut pas définir lui-même son rôle ou périmètre de données par une saisie textuelle.
Une intégration HTTP distante nécessite un concept d’autorisation adapté. Les tokens doivent être destinés au service prévu et vérifiés quant à leur validité et périmètre. Les identifiants des systèmes en aval sont protégés et limités selon la destination. Un token client transmis sans discernement n’est pas un accès universel.
Une connexion de processus locale présente d’autres limites qu’un service distant d’entreprise : programme lancé, provenance et droits système notamment. L’exécution locale simple ne remplace pas la vérification du programme et de ses accès aux données. Pour les deux variantes, connexions autorisées et responsabilités techniques sont convenues.
MCP est un protocole, sans constituer une architecture de sécurité complète.
Les limites réelles sont appliquées par logique serveur, droits cibles, identifiants protégés, règles réseau et validations vérifiables. La mise en œuvre dépend du client, des données, des actions et du mode d’exploitation.
Les limites s’appliquent aussi aux propositions inadaptées du modèle.
Document, texte de ticket ou résultat d’outil peuvent contenir des instructions manipulées. Ces contenus sont traités comme des données. Ils ne peuvent ni attribuer de nouveaux droits ni justifier une action normalement bloquée. Les indications du prompt peuvent aider l’application ; le contrôle faisant autorité reste extérieur au modèle.
Entrées et destinations
Valider côté serveur types, valeurs autorisées, lien avec l’objet, chemins et volumes de résultats. Limiter API et destinations réseau ; éviter commandes assemblées librement et appels d’adresses incontrôlés.
Actions et validations
Afficher clairement périmètre de l’appel et effets secondaires. Lier les validations critiques à l’opération concrète, limiter leur durée et les revérifier avant exécution. Définir règles d’arrêt et de nouvelle tentative.
Exploitation et traçabilité
Prévoir limites de débit et de durée, gestion des erreurs et journaux à finalité définie. Exclure les identifiants du contexte du modèle et des diagnostics. Pouvoir examiner les accès suspects et révoquer les accès.
Nous testons processus normaux, accès interdits à des objets, contenus manipulés, autorisations expirées, appels doubles et validation refusée. Cela réduit les risques ; promettre de bloquer toute injection de prompt ne serait pas sérieux.
Commencer par une fonction limitée.
Nous recensons application cible, API existantes, rôles utilisateurs et champs nécessaires. Il en résulte un catalogue d’outils limité avec des entrées et résultats clairs. Un pilote en lecture peut montrer l’utilité au quotidien ; l’écriture est ajoutée et testée séparément au besoin.
- Délimiter la mission : quel problème, quels objets et quels utilisateurs ?
- Développer l’interface : connecter l’API cible, décrire l’outil et mettre en œuvre droits et gestion des erreurs.
- Réaliser la recette pratique : vérifier cas autorisés et interdits, validations et nouvelles tentatives.
- Transmettre avec un suivi : consigner documentation, gestion des accès, versions et responsabilités.
DAXS peut réaliser ce travail comme développement spécifique et intégration. Une simple consultation de données peut aussi se résoudre avec une API classique ou un script. Nous définissons le périmètre adapté selon vos systèmes existants.
Une fonction concrète souhaitée, l’application concernée, la documentation API disponible et un exemple anonymisé. Identifiants et données clients confidentielles ne doivent pas figurer dans une demande publique.
Ce que nous clarifions ensemble.
Quelle différence entre API et MCP ?
Une API expose les fonctions d’un système. MCP décrit une manière commune de proposer outils et contexte aux applications d’assistance IA. Un serveur MCP peut utiliser des API existantes ; leurs droits et règles métier restent nécessaires.
Toute automatisation nécessite-t-elle un agent IA ?
Non. Un import défini ou un calcul déterministe se réalise souvent plus simplement avec un script ou une connexion API directe. Un agent peut convenir lorsque des tâches variables nécessitent réellement un choix flexible d’étapes.
Un outil MCP peut-il effectuer lui-même des modifications ?
Si cela répond au besoin métier et est sécurisé techniquement. Lecture, modifications limitées et actions critiques sont traitées séparément. Validations, droits cibles, contrôle des entrées et résultats traçables font partie de chaque fonction.
La connexion au service d’IA suffit-elle comme autorisation ?
Non. Le serveur doit vérifier appelant et habilitations ; le système cible doit aussi autoriser la fonction et l’objet précis. Un appel d’outil ne doit pas créer des droits que l’utilisateur ne possède pas.
Comment commencer un pilote pertinent ?
Avec une utilité claire et quelques outils limités, idéalement en lecture au départ. Nous définissons les critères de réussite et testons accès interdits, contenus problématiques, délais dépassés et appels répétés avant d’étendre l’écriture.
Un accès aux outils ne constitue pas une autorisation d’exploitation.
Un agent sous Linux peut utiliser API, outils locaux ou services externes. Identité de service propre, accès fichiers limités, isolation des processus, destinations réseau autorisées et identifiants gérés en sécurité sont planifiés séparément. Un agent local n’est donc pas automatiquement hors ligne ; tout appel externe appartient au flux de données. Changements de modèle, erreurs d’outils, limites de durée et coûts, ainsi qu’un arrêt traçable sont également testés.
Approfondir droits et validations pour les agents
Script, workflow ou agent IA : questions de décision concrètes
Parlons de votre cas d’usage.
Que faut-il simplifier, quelles données sont concernées et quels systèmes existent déjà ? Nous en déduisons une entrée pertinente et une prochaine étape limitée.