Administration et projets IA - contrat de restructuration

Périmètre

Enterprise AI Platform uniquement : portal, Administration du Control Plane, gestion des projets LLM et dépendances directes d'autorisation. Navin Manager n'est ni modifié ni redéployé. Aucun service, technologie, rôle IAM, registre, moteur de routage ou système FinOps ajouté. Les modifications concurrentes sont conservées.

Audit et localisation cible

Fonction actuelle	Source de vérité et implémentation	Cible et action
Tenants	tenancy/__init__.py, /v1/tenants, eai.tenants	Administration globale, gestion réservée plateforme, tenant courant pour les autres
Organisations et unités	tenancy/hierarchy.py, /v1/organizations, /v1/business-units, tables homonymes	Vue hiérarchique tenant ; liens des projets existants, pas de seconde hiérarchie
Projets et environnements	tenancy/__init__.py, /v1/projects, eai.projects, eai.environments	Entrée métier unique, informations et environnements de l'espace projet
Membres et rôles	/v1/members, eai.users, eai.memberships, auth.py, OpenFGA	Affectations tenant ou projet explicites ; ne pas transformer un rôle projet en rôle tenant
Clés API Navin	identity/__init__.py, /v1/api-keys, eai.api_keys.project (slug)	Accès projet Navin distinct des clés LiteLLM ; permissions, propriété et scopes existants
Identités de service	/v1/service-identities, eai.service_identities	Portée tenant conservée ; aucune association projet inventée
Groupes d'annuaire	identity/group_mappings.py, /v1/identity/group-mappings, eai.group_mappings, group_mapping_grants	Administration tenant ; synchronisation et retrait des seules affectations gérées conservés
Profils de quota	/v1/identity/quota-profiles, eai.quota_profiles, eai.quotas	Réutilisés pour l'annuaire, indépendants des réglages projet sans copie supplémentaire
Licence et support	kit-platform.tsx, intégrations existantes	Entrée actuelle réservée aux administrateurs autorisés
Fournisseurs, registre global, routage, configuration LiteLLM, versions globales	screens/llm.tsx, kit-data.tsx, domaines LLM existants	Retirés de la navigation métier, accès technique Manager existant ; API, données et intégrations conservées
Projets LLM	llm_management/__init__.py, /v1/llm/projects, eai.llm_projects.project_id	Configuration interne liée à eai.projects, affichée dans l'espace projet
Clés LiteLLM	/v1/llm/projects/{id}/keys, eai.llm_project_keys	Accès virtuels distincts dans le projet, secrets montrés une seule fois
Isolation	kit-data.tsx, backend existant	Conserver sa portée technique réelle, pas de règle globale présentée comme paramètre projet
Résolveur, budget de contexte, playground	llm-tools.tsx, API existantes	Diagnostics autorisés, contexte projet réutilisé ; catalogue global non ressaisi
Consommation	quotas/compteurs existants, spend des clés LiteLLM, événements FinOps	Afficher source/période/devise et indisponibilité ; jamais additionner compteurs et spend pour un total fictif

Contrat minimal

• La hiérarchie existante reste tenant -> organization -> business_unit -> project -> environment.
• eai.projects.id demeure l'identifiant métier ; eai.llm_projects.id et litellm_team_id conservent leurs identités techniques. Aucun renommage ni fusion de tables.
• La création métier accepte les paramètres LLM existants en option et prépare l'association dans la même transaction. La synchronisation HTTP est effectuée après commit, avec un état persistant exact.
• Les projets existants déjà liés sont réutilisés. Les associations multiples restent consultables. Un projet LLM orphelin est associé seulement par choix explicite d'identifiant, jamais par similitude de nom.
• Une modification de quota conserve les identifiants et compteurs ; un quota retiré est désactivé, non supprimé.
• Les rôles actuels restent inchangés : un tenant_admin avec project_id est une affectation d'administration de ce projet, pas un administrateur du tenant. Les relations OpenFGA owner/editor/viewer/can_invoke restent les mécanismes d'autorisation.
• Les réponses projet incluent les permissions calculées côté serveur. Les menus ne sont qu'une projection de ces droits ; listes, détails, sélecteurs et mutations sont filtrés côté backend.
• Le contexte conserve UUID pour les relations/liens et slug pour X-Project, plus environnement réel. Tout changement de parent efface les choix descendants et les caches du périmètre précédent.
• Les clés Navin, clés LiteLLM et identités SPIFFE ne sont jamais fusionnées. Les coûts ne sont jamais agrégés entre devises ou périodes différentes.

Conservation et migration

L'unicité des memberships doit intégrer le projet, y compris le cas tenant NULL, sans suppression de ligne. Les anciens UUID, équipes, clés, compteurs, droits tenant explicites et informations d'audit sont conservés. Aucun backfill par nom ; aucune migration de production durant l'implémentation. Les migrations sont vérifiées sur PostgreSQL de test avec données représentatives avant toute application locale autorisée.

Validation prévue

Un scénario intégré backend vérifie création, association/réutilisation, compteurs, panne LiteLLM, cinq profils existants et isolation interprojets/intertenants. Les tests frontend ciblés vérifient parcours, corps des formulaires, permissions et navigation. Builds du Control Plane et du portail après les derniers changements. Le portail doit être observé en fonctionnement ; les dépendances indisponibles sont signalées, pas déclarées validées.

État initial

Audit terminé. Référence des empreintes initiales : /tmp/eai-project-refactor-baseline-20261105.json (2389 fichiers, dont Navin Manager en lecture seule). Le contrôle partagé de clôture associe des fichiers d'autres missions ; il ne constitue pas une validation de cette restructuration et n'est pas contourné.