SSO et rôles : déployer Octowise à l'échelle de l'organisation
Microsoft Entra ID par instance, permissions granulaires finance/conformité/bâtiments : la gouvernance d'accès suit la structure patrimoniale.
Équipe Octowise
Déployer Octowise à l'échelle d'une organisation, c'est aligner l'identité et les droits sur la structure patrimoniale, pas créer un second annuaire. Chaque organisation connecte son compte Microsoft et un catalogue de rôles : bâtiments, finance, factures, conformité ne s'héritent pas automatiquement.
Connexion Microsoft, web et mobile
Chaque organisation configure sa propre connexion Microsoft. Les utilisateurs déjà dans l'annuaire n'ont pas de mot de passe Octowise supplémentaire. Les comptes locaux restent possibles selon le déploiement, mais le modèle cible des organisations multi-sites est l'annuaire d'entreprise.
La même identité sert sur le navigateur et sur le téléphone. On ne gère pas deux régimes d'accès.
Des permissions séparées par métier
Lire les bâtiments n'ouvre pas les factures. Lecture et écriture des factures sont des droits distincts. Conformité, sources de données, tableaux de bord suivent la même logique : on compose le rôle selon le métier, on n'accorde pas « tout le patrimoine » par défaut.
Les nouveaux droits doivent être rattachés explicitement. C'est volontaire : un déploiement existant ne s'ouvre pas tout seul à la finance.
- Connexion Microsoft configurable par organisation.
- Même compte sur le web et sur mobile.
- Rôles séparés bâtiments / finance / factures / conformité.
- Clés d'intégration soumises au même modèle.
L’organigramme comme frontière
Les droits se combinent au rattachement patrimonial : un gestionnaire de territoire voit sa branche, pas tout le groupe. L'organigramme n'est donc pas qu'un visuel ; c'est une maille d'autorisation et de reporting.
Les utilisateurs scoped et les clés d'intégration partagent cette discipline. Un agent MCP n'est pas « plus puissant » qu'un humain : il est limité par la clé.
Gouvernance et révocation
Clés révocables, rôles ajustables, SSO centralisé : on part, on change de poste, on retire l'accès sans chasser des mots de passe dans des fichiers d'intégrateurs.
C'est le prérequis pour ouvrir OData et MCP en production. Sans cette gouvernance, l'ouverture de l'API est un risque, pas un écosystème.