Système d'autorisations

La plateforme Mirox contrôle l'accès au moyen d'un modèle d'autorisations multicouche basé sur les rôles, qui vous donne un contrôle précis sur qui peut voir et modifier quelles centrales — sans vous obliger à gérer les droits individuels un par un. Les rôles assurent le regroupement ; la hiérarchie assure l'héritage.

Philosophie des autorisations

Le système d'autorisations repose sur quelques principes qui rendent l'accès à la fois sécurisé et facile à appréhender :

Héritage hiérarchique — L'accès suit la hiérarchie naturelle des ressources et organisations : accordez une fois en haut, et l'accès descend en cascade.
Moindre privilège — Chaque rôle ne porte que les droits dont sa fonction a réellement besoin.
Séparation des responsabilités — Le statut organisationnel et l'accès aux ressources sont deux axes distincts, de sorte que vous pouvez attribuer à quelqu'un un rôle organisationnel élevé sans exposer chaque centrale, et inversement.
Attribution explicite — L'accès est accordé intentionnellement, jamais présumé.
Sensibilité au contexte — Une même personne peut disposer de droits différents sur différentes centrales.

Ensemble, ces principes maintiennent une approche à la fois sécurisée et flexible de la gestion des accès sur l'ensemble de la plateforme Mirox.

Couches d'autorisations

Une requête traverse une séquence de vérifications. Chaque couche répond à une question ; toutes les couches concernées doivent être en accord avant que l'accès ne soit accordé.

Remarque : la couche API ne s'applique qu'aux requêtes authentifiées par un jeton API ; les sessions interactives passent directement à la couche système.

Les couches :

Couche API (orange) — Uniquement pour les requêtes par jeton API. Elle valide le jeton et applique son groupe d'autorisations, qui ne peut jamais que restreindre ce que le propriétaire du jeton pouvait déjà faire.
Couche système (rouge) — La première barrière pour chaque requête. Elle établit le statut au niveau de la plateforme (utilisateur ordinaire ou administrateur de la plateforme) et protège les opérations critiques pour le système, indépendamment de toute autre couche.
Couche organisation (bleu) — Vérifie que vous appartenez à l'organisation propriétaire de la ressource et applique votre rôle d'organisation.
Couche fonction (vert) — La vérification la plus granulaire : elle décide de ce que vous pouvez faire sur une centrale ou un portefeuille spécifique.

Le diagramme ci-dessous présente les combinaisons courantes. Les données à l'échelle de l'organisation nécessitent la vérification de l'organisation ; une centrale unique nécessite la vérification de la fonction ; de nombreuses requêtes nécessitent les deux.

Couche d'autorisation système

La couche système est la première barrière de sécurité. Elle distingue les administrateurs de la plateforme des utilisateurs ordinaires et protège les opérations à l'échelle du système :

Les administrateurs de la plateforme peuvent effectuer des opérations à l'échelle du système.
Les utilisateurs ordinaires ne peuvent pas réaliser d'actions affectant la plateforme elle-même.
Cette couche n'évalue pas l'accès au niveau des fonctionnalités (comme la génération de rapports) — cela se produit plus bas.

L'intégrité du système reste protégée même si une vérification plus granulaire est mal configurée.

Couche d'autorisation d'organisation

Chaque utilisateur appartient à exactement une organisation, qui est la porte d'entrée vers les ressources :

Les organisations possèdent des ressources (portefeuilles et parcs).
Vous recevez votre accès de base par l'intermédiaire de votre rôle d'organisation.
Les organisations peuvent établir des accords de coopération pour partager des ressources spécifiques au-delà de la frontière de l'organisation.

Cette couche fait respecter les frontières organisationnelles : vous n'atteignez que les ressources que votre organisation possède ou qui lui ont été accordées par une coopération.

Couche d'autorisation des ressources (fonction)

Le niveau le plus granulaire contrôle ce que vous pouvez faire sur une centrale ou un portefeuille individuel. L'accès y est exprimé sous la forme d'un rôle de fonction (voir ci-dessous) :

Votre rôle d'organisation fournit un rôle de fonction par défaut sur chaque ressource possédée.
Les organisations peuvent remplacer cette valeur par défaut en vous accordant un rôle de fonction spécifique sur une ressource spécifique — plus large ou plus restreint que votre valeur par défaut.
Un octroi direct l'emporte toujours sur la valeur par défaut héritée, ce qui facilite les exceptions.

Cette couche permet un contrôle précis, parc par parc, sans modifier le rôle d'organisation de qui que ce soit.

Couche d'autorisation des jetons API

Une couche facultative pour l'automatisation et les intégrations :

Les jetons API sont créés par les utilisateurs pour piloter des scripts et des systèmes externes.
Un jeton ne peut jamais dépasser les autorisations de l'utilisateur qui l'a créé — il ne fait que restreindre.
Un jeton est lié à un groupe d'autorisations qui le limite à un domaine fonctionnel (voir Groupes d'autorisations API).
Un jeton ne se voit jamais demander de second facteur, et les règles de durée de connexion n'y mettent pas fin. Une seule règle : un utilisateur sans second facteur ne peut pas créer de nouveau jeton tant que sa propre organisation exige l'authentification à deux facteurs (2FA).

Cela maintient l'automatisation sécurisée tout en respectant le principe du moindre privilège. Pour plus de détails, consultez la documentation de la fonctionnalité Jetons API.

L'exigence de 2FA s'ajoute aux rôles

Les rôles décident quelles centrales vous pouvez atteindre. Une organisation peut y ajouter une condition : exiger l'authentification à deux facteurs (2FA) pour l'accès à ses centrales.

Un rôle accorde la centrale. L'exigence décide si elle vous est affichée. Si l'organisation propriétaire d'une centrale exige la 2FA et que votre compte n'a pas de second facteur (application d'authentification ou passkey), vous ne voyez pas les centrales de cette organisation — quel que soit le rôle que vous y détenez.
Rien n'est retiré. Vos rôles et vos octrois restent tels quels. Vous restez connecté, et un message dans l'en-tête vous invite à activer la 2FA. Dès que vous l'activez, les centrales réapparaissent.
Le propriétaire de la centrale décide. L'exigence s'applique à toute personne qui atteint la centrale : les membres de l'organisation comme les utilisateurs d'un partenaire de coopération.

Qui fixe l'exigence et ce qui est masqué exactement est décrit sur la page Politique de sécurité de l'organisation.

Système de contrôle d'accès basé sur les rôles

Mirox utilise le contrôle d'accès basé sur les rôles (RBAC) avec des rôles prédéfinis sur trois axes : un rôle système à l'échelle de la plateforme, un rôle d'organisation et des rôles de fonction par ressource.

Rôles système

Les rôles système définissent le statut à l'échelle de la plateforme :

Administrateur — Personnel de la plateforme ayant accès aux opérations et à la configuration à l'échelle du système.
Utilisateur — Le rôle standard pour toute personne utilisant la plateforme ; aucun privilège administratif.

Comptes de démonstration

Un rôle de démonstration restreint existe également pour les comptes d'évaluation. Il se comporte comme un utilisateur ordinaire aux droits réduits et n'est pas quelque chose que vous attribuez vous-même.

Rôles d'organisation

Votre rôle d'organisation est votre statut par défaut au sein de votre organisation. Les deux rôles de manager sont au cœur de la structure d'autorisations actuelle : ils vous permettent de déléguer une responsabilité de haut niveau sans céder le contrôle complet de modérateur.

Rôle d'organisation	À qui il s'adresse
Admin	Gère tous les aspects de l'organisation — membres, coopérations, facturation et toutes les ressources.
Modérateur	Dirige l'équipe et les relations partenaires aux côtés de l'Admin — invite des membres et modifie leur rôle (n'importe quel rôle, Admin compris), gère les coopérations — ainsi que toutes les ressources ; seule la suppression de l'organisation elle-même reste réservée à l'Admin.
Asset Manager (Technical)	Asset manager technique. Exploite les centrales sur le plan technique — configuration, composants, événements, tickets et réseaux des centrales par accès distant. Voit l'équipe, mais ne la gère pas.
Asset Manager (Commercial)	Asset manager commercial. Exploite les centrales sur le plan commercial — contrats, facturation, revenus et tarifs — avec la même gestion de la configuration, des événements et des tickets que le manager technique, mais sans accès distant aux réseaux des centrales. Voit l'équipe, mais ne la gère pas.
Membre	Membre standard avec un accès en lecture aux ressources de l'organisation.
Externe	Statut limité sans accès aux ressources par défaut ; n'atteint les ressources que par des octrois explicites.

Les deux rôles de manager sont des pairs — au même niveau sous Modérateur, l'un technique et l'autre commercial. Cette séparation permet à une même organisation de distinguer proprement la responsabilité d'ingénierie de la responsabilité contractuelle et de facturation.

Contenus partagés de l'organisation. Les Admins, les Modérateurs et les deux rôles de Gestionnaire d’actifs créent, dupliquent, modifient et suppriment les modèles, chapitres et indicateurs de rapport de l'organisation, ses modèles et formules d'export de données, ainsi que les règles, destinataires, modèles et mises en sourdine du Gestionnaire d'alertes ; les Membres les voient et les utilisent. Un élément marqué Privé n'est modifié que par son créateur, un Admin ou un Modérateur — voir Rapports et Gestionnaire d'alertes. Les agrégateurs restent réservés aux Admins et aux Modérateurs.

Qui gère l'équipe

Les adhésions sont gérées exclusivement par les Admins et les Modérateurs. Tous deux invitent des membres et attribuent n'importe quel rôle — un Modérateur peut inviter ou promouvoir un nouvel Admin. Les deux rôles de manager, les Membres et les Externes voient l'équipe mais ne peuvent inviter personne, modifier un rôle ni accorder des autorisations sur les centrales. Les Admins et les Modérateurs sont aussi les seuls à créer, accepter, suspendre ou mettre fin à une coopération. Eux seuls définissent la politique de sécurité de l'organisation.

Autorisations de ressources basées sur la fonction

Les rôles de fonction définissent ce qu'un utilisateur peut faire sur une centrale ou un portefeuille spécifique, indépendamment de son rôle d'organisation :

Rôle de fonction	Accès
Exploitant (`operator`)	Accès opérationnel complet : tout ce que possèdent les deux rôles de manager, plus les actions destructrices réservées au propriétaire — la suppression de composants et de tickets.
Gestionnaire technique (`tom`)	Autorité technique sur une ressource : configuration, composants, événements (y compris leur suppression), tickets et réseaux de la centrale par accès distant.
Gestionnaire d'actifs (`com`)	Autorité commerciale : la même gestion de la configuration, des événements et des tickets, plus les chiffres de revenus et les paramètres tarifaires — mais pas d'accès distant aux réseaux de la centrale.
Spectateur (`viewer`)	Accès en lecture seule aux données et indicateurs de performance d'une ressource.
Responsable sécurité (`security_officer`)	Accès aux segments réseau uniquement. Atteint par accès distant les équipements réseau des segments accordés (infrastructure réseau, caméras, systèmes de sécurité) et consulte le journal d'accès de la centrale. Aucune donnée de production, de performance ou commerciale, et jamais un réseau de commande de la centrale. Voir Segmentation réseau.
Mandant (`observer`)	Données d'exploitation uniquement, actuelles et historiques : production, batterie, turbines, analyse, le tableau de bord, la prévision et les prix de marché. Aucun événement, ticket, rapport, export, contact, fichier, réseau ni donnée financière, et aucune notification push pour la centrale. Un cran sous Spectateur.
Aucune	Aucun accès.

Le rôle Responsable sécurité s'attribue uniquement de façon explicite. Aucun rôle d'organisation n'y correspond : personne ne devient responsable sécurité en rejoignant une organisation. Il est accordé délibérément, par centrale ou par portefeuille, ou partagé via une coopération.

Le rôle Mandant s'attribue lui aussi uniquement de façon explicite, et c'est le seul rôle dont l'attribution peut restreindre un compte : les attributions s'additionnent, un Membre qui reçoit une attribution Mandant conserve donc l'accès Spectateur du Membre — la vue limitée ne prend effet que pour un membre Externe ou un partage par coopération. Une attribution Mandant peut porter une date d'expiration.

Le jeton entre parenthèses est l'identifiant utilisé dans les octrois API et les partages de coopération ; partout dans l'interface, vous voyez l'intitulé complet.

Groupes d'autorisations API

Les jetons API sont affectés à exactement un groupe d'autorisations qui délimite ce que le jeton peut atteindre :

Accès complet — Les mêmes autorisations que l'utilisateur créateur, dans les limites de sa portée.
Metric Export — Limité à la lecture de l'export de données : indicateurs sous forme de séries temporelles, modèles d'export, catalogue des indicateurs, informations de centrale et événements. Il ne peut rien modifier.
Base de données temporelle — Accès aux points d'accès de séries temporelles pour la lecture des séries de mesure brutes.

Pour les cas d'usage et exemples, consultez la documentation de la fonctionnalité Jetons API.

Héritage des autorisations

L'accès descend en cascade dans la hiérarchie des ressources, de sorte que vous accordez en haut et affinez en bas :

Organization
├── Organization Role (your default standing)
│
├── Portfolio 1
│   ├── Inherits organization-level access
│   ├── Portfolio-specific grants (optional)
│   │
│   ├── Park A
│   │   ├── Inherits portfolio access
│   │   └── Park-specific grants (optional)
│   │
│   └── Park B
│       ├── Inherits portfolio access
│       └── Park-specific grants (optional)
│
└── Portfolio 2
    └── Park C
        └── Inherits portfolio access

Ce modèle d'héritage signifie que :

L'accès issu de votre rôle d'organisation s'applique à tous les portefeuilles et parcs que votre organisation possède.
Un octroi au niveau du portefeuille s'applique à chaque parc de ce portefeuille.
Un octroi sur un parc unique affine l'accès pour ce parc seulement, en remplaçant la valeur par défaut héritée.

Correspondance entre rôle d'organisation et rôle de fonction

Lorsque vous accédez à une ressource, votre rôle d'organisation détermine automatiquement votre rôle de fonction par défaut :

Rôle d'organisation	Rôle de fonction par défaut
Admin	Exploitant (gestion complète des ressources)
Modérateur	Exploitant (gestion complète des ressources)
Asset Manager (Technical)	Gestionnaire technique (autorité technique)
Asset Manager (Commercial)	Gestionnaire d'actifs (autorité commerciale)
Membre	Spectateur (accès en lecture seule)
Externe	Aucune (aucun accès aux ressources par défaut)

Cette séparation maintient les autorisations de ressources (rôles de fonction) distinctes du statut organisationnel. Votre rôle d'organisation définit la valeur par défaut, mais des octrois explicites par ressource peuvent l'augmenter ou l'abaisser pour n'importe quelle centrale individuelle.

Autorité commerciale vs technique

Les deux rôles de manager correspondent à deux rôles de fonction distincts situés au même niveau. Tous deux configurent la centrale, traitent les événements (y compris leur suppression) et travaillent sur les tickets — créer, modifier, fermer, rouvrir. Ce qui les distingue : le Gestionnaire technique atteint les réseaux de la centrale par accès distant (VPN, proxy navigateur) et modifie les tableaux de bord Grafana ; le Gestionnaire d'actifs voit les chiffres de revenus et modifie les paramètres tarifaires et de marché. Aucun des deux ne supprime de composants ni de tickets — cela reste réservé à l'Exploitant, c'est-à-dire aux Admins et aux Modérateurs.

Coopération entre organisations

Les organisations peuvent établir des accords de coopération pour partager des ressources spécifiques au-delà de la frontière de l'organisation :

Deux organisations forment une coopération formelle.
L'organisation propriétaire de la ressource accorde un accès spécifique à l'aide de rôles de fonction.
Ce qui est partagé au niveau de la coopération plafonne ce que l'organisation réceptrice peut ensuite déléguer à ses propres membres.
Tout accès reste auditable et peut être révoqué par le propriétaire de la ressource à tout moment.

Accès automatique pour l'Admin uniquement

Seul un Admin de l'organisation réceptrice atteint automatiquement les ressources partagées. Toutes les autres personnes de cette organisation — les Modérateurs, les deux rôles de Gestionnaire d'actifs, les Membres et les Externes — n'atteignent une centrale partagée qu'après que cet Admin la leur a déléguée. Un membre doté d'une telle délégation travaille bien sur la centrale partagée, avec le rôle qui lui a été attribué.

Si l'organisation propriétaire d'une centrale partagée exige la 2FA, cela s'applique aussi à l'Admin récepteur et à chaque membre délégué — voir L'exigence de 2FA s'ajoute aux rôles.

Pour connaître les règles complètes sur la manière dont l'accès partagé est délimité et délégué, consultez Restrictions de coopération.

Bonnes pratiques

Pour une gestion efficace des autorisations dans Mirox :

Utilisez les rôles standards — Les rôles d'organisation et de fonction prédéfinis couvrent la grande majorité des situations réelles.
Adaptez le manager à la responsabilité — Utilisez le rôle Asset Manager (Technical) pour la responsabilité d'ingénierie et le rôle Asset Manager (Commercial) pour la responsabilité contractuelle et de facturation.
Attribuez au niveau approprié le plus élevé — Accordez au niveau de l'organisation ou du portefeuille lorsque l'accès doit s'appliquer largement ; affinez au niveau du parc uniquement pour de véritables exceptions.
Révisez régulièrement — Auditez périodiquement les rôles des membres et les octrois par ressource, et définissez des dates d'expiration pour les accès à durée limitée.
Vérifiez l'accès — Confirmez une configuration en vérifiant ce qu'un membre donné peut réellement atteindre avant de vous y fier.

Exemples pratiques

Gestion multi-sites

Une organisation gérant plusieurs parcs solaires pourrait mettre en place :

Un responsable des opérations en tant qu'Admin, avec le contrôle complet de l'organisation.
Un responsable d'ingénierie en tant qu'Asset Manager (Technical), gérant l'état des composants, les événements et les tickets de toutes les centrales.
Un responsable financier en tant qu'Asset Manager (Commercial), gérant les contrats, la facturation et les tarifs sans aucun accès distant aux réseaux des centrales.

Accès prestataire

Un prestataire de maintenance invité de l'extérieur pourrait recevoir :

Un rôle d'organisation Externe avec un rôle de fonction Gestionnaire technique ou Spectateur sur les parcs spécifiques qu'il dessert.
Un octroi par ressource limité uniquement à ces centrales.
Une date d'expiration afin que l'accès prenne fin automatiquement à la fin de la mission.

Visibilité pour les investisseurs

On peut accorder aux investisseurs :

Un rôle d'organisation Membre ou Externe avec un rôle de fonction Spectateur sur des portefeuilles spécifiques.
Un accès en lecture aux données de performance et de rapport, sans aucune capacité de gestion.

Fonctionnalités associées

Restrictions de coopération — comment l'accès partagé est délimité entre organisations coopérantes
Politique de sécurité de l'organisation — l'exigence de 2FA et les règles de connexion qu'une organisation définit
Coopérations — partage de centrales et de portefeuilles au-delà de la frontière de l'organisation
Invitations — inviter des membres et attribuer leur rôle d'organisation
Jetons API — jetons délimités pour l'automatisation et les intégrations
Journal d'audit — qui a accédé à quels appareils de centrale et quand
Tickets — la couche de gestion du travail humain conditionnée par le rôle de fonction