Accès agentique (MCP)

Mirox permet à un agent IA externe d'exploiter la plateforme en votre nom — selon vos autorisations exactes — via le Model Context Protocol (MCP). La plateforme exécute un serveur MCP qui expose ses capacités sous forme d'outils pour l'agent : tout client compatible MCP peut ainsi lire vos données, gérer vos centrales et réaliser des opérations exactement comme vous le feriez dans l'interface ou avec l'API REST, sans jamais dépasser ce que votre propre accès autorise.

Concept

Le MCP (Model Context Protocol) est un standard ouvert qui permet à un agent IA de découvrir et d'appeler les fonctions qu'un système met à disposition. Mirox publie ses capacités sous forme d'un catalogue d'outils MCP — chaque outil correspond à une opération bien définie, comme lister vos centrales, lire une métrique ou proposer une modification des détails d'une centrale.

Un agent se connecte à l'endpoint MCP de Mirox, voit les outils qu'il est autorisé à utiliser et les appelle pour accomplir son travail. Comme chaque outil passe par les mêmes contrôles d'accès et la même logique métier que l'interface et l'API REST, l'agent voit exactement ce que vous verriez et peut faire exactement ce que vous pouvez faire — rien de plus.

Remarque : le jeton de l'agent et votre rôle sous-jacent déterminent quels outils aboutissent — l'agent ne peut jamais aller au-delà de votre propre accès.

Ce que vous pouvez faire

Grâce aux outils MCP, un agent peut intervenir sur l'ensemble de la plateforme à peu près comme vous le faites manuellement :

• Consulter votre patrimoine — lister et inspecter vos portefeuilles, centrales, événements de centrale et tickets.
• Interroger les données de performance — extraire des métriques de séries temporelles et exécuter des requêtes MiroxQL pour les centrales auxquelles vous avez accès.
• Gérer les centrales — proposer la création d'une nouvelle centrale ou la mise à jour de ses informations de base, dates, adresse, informations métier, composants, contacts et valeurs de ratio de performance.
• Piloter l'exploitation — ouvrir et lister des tickets, examiner l'état de connexion VPN direct d'une centrale et proposer un correctif de configuration sûr.
• Travailler avec les documents — rechercher, lire et joindre des fichiers dans le stockage documentaire, et consulter la documentation produit.

Les opérations d'écriture suivent un schéma proposer-puis-appliquer : l'agent propose une modification et le résultat est présenté pour examen et acceptation, plutôt que d'être écrit aveuglément. Vous restez ainsi le décideur, même lorsqu'un agent se charge de la préparation — et cela reste vrai quel que soit le client qui pilote l'agent.

Une couche de capacités, tous les modèles

MCP n'est pas seulement la voie par laquelle les agents externes atteignent Mirox : c'est la voie par laquelle tout modèle atteint Mirox, y compris l'assistant intégré. Il existe un seul catalogue de capacités, et quelle que soit l'IA qui répond, elle l'appelle de la même manière.

C'est cette couche unique qui rend la plateforme précisément contrôlable :

• Les capacités sont sélectionnées, pas générées. Chacune est une opération délibérée et bien définie, avec ses propres contrôles d'accès — et non un point de terminaison exposé automatiquement parce qu'il existait. Ce que l'IA peut faire est une décision, examinée capacité par capacité.
• Lecture et écriture sont séparées par conception. Les opérations d'écriture suivent le principe proposer-puis-appliquer ; l'accès de repli, plus large, est en lecture seule et rejette tout ce qui n'est pas un GET. Un agent ne peut pas inventer un moyen de modifier des données.
• Changer de modèle ne change rien à la frontière. Connectez un autre fournisseur, ou votre propre modèle hébergé : il hérite exactement du même catalogue et des mêmes contrôles. La capacité est une propriété de la plateforme, pas de l'IA que vous avez choisie cette semaine.
• Les secrets sont structurellement absents. Aucune capacité ne renvoie de clé, de certificat, de clé pré-partagée, de jeton ou de mot de passe — aucun modèle ne peut donc en extraire un, quelle que soit la façon dont on le sollicite.

La piste d'audit

Chaque appel de capacité est attribué et enregistré comme n'importe quel autre accès à votre compte, ce qui rend l'activité de l'IA vérifiable plutôt qu'affaire de confiance :

• Qui — l'appel est attribué à la personne dont les autorisations ont été utilisées. Il n'y a pas de « c'est l'IA » anonyme : un agent agit en votre nom, et l'enregistrement le dit.
• Quoi — quelle capacité a été exécutée, et le résultat qu'elle a produit.
• Quel modèle — une conversation indique quel modèle a répondu à chaque message, de sorte qu'une réponse peut être rattachée à l'IA qui l'a produite.
• Ce qui a été proposé et décidé — chaque exécution d'assistant conserve sa transcription complète avec chaque action proposée et votre décision de l'accepter ou de la refuser.

Les enregistrements d'audit ne peuvent être ni modifiés ni supprimés par les utilisateurs. Combinés à la règle proposer-puis-appliquer, ils donnent à un auditeur les deux éléments dont il a réellement besoin : ce que l'IA pouvait faire, et ce qu'elle a effectivement fait.

Connecter un agent IA

Connecter n'importe quel client compatible MCP se fait en deux étapes.

1. Créez un jeton API à portée limitée. Dans votre profil, créez un jeton API et choisissez le groupe d'autorisations adapté à la tâche — Full Access pour un agent qui doit exploiter la plateforme, ou un groupe plus restreint (Reporting, Timeseries Database) pour un travail en lecture seule. La valeur complète du jeton n'est affichée qu'une seule fois : conservez-la donc en lieu sûr. Consultez le guide d'utilisation des jetons API pour la procédure pas à pas.

2. Pointez votre client MCP vers l'endpoint MCP de Mirox et authentifiez-vous avec ce jeton. Mirox utilise les mêmes jetons API à portée limitée que l'API REST : le client envoie le jeton dans l'en-tête standard Authorization: Bearer <api_token>. Une fois connecté, votre client liste les outils disponibles et peut commencer à les appeler.

Autorisations et contrôle

Un agent agissant via MCP est soumis exactement aux mêmes contrôles que vous — il n'existe aucun privilège spécifique aux agents. Trois éléments, ensemble, déterminent ce que tout appel d'outil peut faire :

• Le groupe d'autorisations du jeton API. Un jeton limité à Reporting ou Timeseries Database ne peut effectuer que des opérations de lecture/export ; seul un jeton Full Access permet à un agent d'exploiter la plateforme. Le groupe ne peut jamais que restreindre l'accès, jamais l'élargir.
• Votre rôle sous-jacent. Le jeton agit toujours en votre nom. Tout ce que votre rôle d'organisation (Admin, Modérateur, Asset Manager (Technical), Asset Manager (Commercial), Membre, Externe) et votre rôle de fonction par centrale (Exploitant, Technical Manager, Asset Manager, Spectateur) vous permettent d'atteindre constitue le plafond exact de l'agent — centrale par centrale et portefeuille par portefeuille, les coopérations étant respectées exactement comme ailleurs.
• Le modèle d'autorisations complet. Chaque appel d'outil passe par les mêmes contrôles en couches qu'une requête normale — portée du jeton, statut sur la plateforme, votre rôle d'organisation et la vérification de fonction par centrale — de sorte que l'accès est décidé de la même manière que partout dans le système d'autorisations.

Deux garanties de la plateforme s'appliquent à tout ce que fait un agent :

• Aucun secret transmis à l'agent. Les outils MCP n'exposent jamais de clés VPN, certificats, clés pré-partagées, jetons ni aucun autre identifiant. Un agent peut, par exemple, proposer un correctif de VPN direct sans jamais voir les clés sous-jacentes.
• Tout est audité. Chaque appel d'outil vous est attribué et enregistré, exactement comme tout autre accès à votre compte, afin que l'activité agentique reste traçable et vérifiable.

Fonctionnalités associées

• Assistant IA et assistants guidés — l'assistant de chat natif et les assistants guidés qui utilisent ces mêmes outils depuis l'intérieur de la plateforme
• Jetons API — les identifiants à portée limitée et révocables avec lesquels un agent s'authentifie
• Système d'autorisations — le modèle d'accès en couches et les groupes d'autorisations qui encadrent tout ce qu'un agent peut faire
• Journalisation d'audit — où l'activité agentique est enregistrée, aux côtés des autres accès à votre compte
• Guide d'utilisation des jetons API — création pas à pas d'un jeton pour connecter un agent
• FAQ IA — questions fréquentes sur la sécurité de l'IA, le traitement des données et le contrôle