Multi-tenant B2B : isolation, RBAC et gouvernance des modèles

# Multi‑tenant B2B : isolation, RBAC et gouvernance des modèles avec AISIA – une approche FinOps ## Introduction – Le dilemme du DSI/RSSI Les entreprises B2B doivent fournir à chaque client un environnement IA isolé, tout en maîtrisant les coûts et la latence. Le choix entre exécuter les modèles en local‑first ou déléguer les requêtes au cloud génère des arbitrages complexes : déploiement d’infrastructure on‑premise, gouvernance des accès (RBAC), suivi de la consommation et risque de fuite de données. AISIA propose une passerelle d’orchestration qui privilégie d’abord les modèles locaux, puis interroge le catalogue cloud si‑et‑seulement si la confiance ou la capacité le nécessite. Ce post présente les critères décisionnels concrets pour implémenter une architecture multi‑tenant fiable et économiquement optimisée. ## 1. Isolation des locataires grâce aux routes organisationnelles - **Endpoints UI** : les routes **/orgs** et **/orgs/:slug** permettent de créer un espace dédié à chaque client (tenant) et de l’identifier de façon unique. - **Séparation des ressources** : chaque tenant peut se voir attribuer un sous‑ensemble de nœuds du cluster (ex. 21 nœuds Docker Swarm) ou des quotas de modèles locaux. - **Critère FinOps** : en limitant chaque tenant à un nombre défini de modèles locaux (max 123 modèles locaux actifs) on évite les dépenses inutiles de licences cloud tout en garantissant une isolation stricte. ## 2. Gouvernance du RBAC et traçabilité des appels modèle - **Contrôle d’accès** : le RBAC s’appuie sur le micro‑service d’authentification intégré à la couche **/orgs/:slug**, qui mappe les rôles (admin, développeur, analyste) aux permissions d’inférence. - **Traçabilité** : chaque requête passe par la passerelle AISIA, qui consigne dans le **Health API** (status=ok, version=6.12.91) les métadonnées d’appel