J'ai maintenant une vue complète du schéma. Je vais produire une analyse structurée.Voici une analyse complète du schéma.
—
## Architecture générale
Le schéma modélise une plateforme SaaS de gestion locative (type Property Management System). Il suit une architecture multi-tenant stricte où `Tenant` est l'agrégat racine — presque tous les autres modèles portent un `tenantId` et toutes les relations remontent à lui. L'isolation des données entre agences est donc garantie au niveau du schéma, pas seulement applicatif.
On compte ~75 modèles et ~38 enums, répartis en 20 domaines.
—
## Les 20 domaines en détail
Core infrastructure (teal)
`Tenant` est le point d'entrée unique. `User` porte l'auth complète : sessions, refresh tokens, historique de connexion, MFA multi-méthode, préférences. Le RBAC est flexible via `Role → Permission` avec une table de jointure `UserRole / RolePermission` — les rôles sont globaux (`code` unique), les assignations sont par user.
Transactionnel (coral)
C'est le cœur métier. `Reservation` est le pivot central autour duquel gravitent `Contract`, `Payment`, `Invoice`, `ReservationPricing`, `ReservationGuest`, et l'historique de statuts. Une réservation peut avoir plusieurs contrats (versions successives) et plusieurs paiements. La chaîne de valeur complète est tracée : réservation → contrat signé → paiement → facture → écriture comptable.
CRM (bleu)
Deux populations distinctes sont gérées : `Customer` (voyageurs ayant réservé) et `Lead` (prospects). Les leads avancent dans un `Pipeline` à travers des `PipelineStage` vers des `Opportunity`. Les deux populations sont reliées aux `Task`, `Activity`, `Campaign`, et peuvent participer aux `Conversation` comme les propriétaires et les utilisateurs internes.
OTA & Channel Manager (amber)
Un `Channel` (Airbnb, Booking, VRBO…) se connecte via `ChannelConnection` (credentials par tenant). Une `PropertyDistribution` lie un bien à une connexion de canal. Les réservations importées passent par `ChannelReservation`. Les synchros sont loggées dans `SyncExecution / SyncError` avec compteurs de succès/erreurs.
Revenue Management (amber)
`PricingRule` définit des règles conditionnelles (Json `conditions` + `actions`). `DynamicPrice` stocke le prix calculé par bien par jour avec ses facteurs (occupation, saisonnalité, demande, compétiteur). `RevenueForecast` et `RevenueSimulation` permettent la prévision et le what-if. `CompetitorSnapshot` et `MarketDemand` alimentent les facteurs externes.
Governance (gris)
`Workflow` avec `WorkflowStep`, `WorkflowInstance`, et `WorkflowExecution` modélise les circuits d'approbation multi-étapes. `AuditLog` trace toutes les actions (CREATE, UPDATE, DELETE, LOGIN…). `EntityHistory` snapshote les versions successives d'une entité. `FeatureFlag` permet le feature toggling par tenant.
Enterprise Security (gris)
`Consent` gère le RGPD (6 types de consentement, avec versionning). `SecurityPolicy` stocke les règles de sécurité configurables. `Risk` modélise une matrice de risques (probabilité × impact = score). `ComplianceAudit` supporte ISO27001, SOC2, NIS2. `SecurityIncident` trace les incidents avec gravité et actions correctives. `DataClassification` et `RetentionPolicy` complètent le dispositif.
IA — Phase 2-N (rose)
Trois nouvelles couches ajoutées. `AiConversation / AiMessage` historisent les échanges avec l'assistant (4 rôles : SYSTEM, USER, ASSISTANT, TOOL). `KnowledgeDocument / KnowledgeChunk` implémentent la base documentaire pour le RAG — un document est découpé en chunks avec un `embeddingId` (référence vers le vecteur stocké dans un vector store externe). `Recommendation` stocke les recommandations IA avec un `confidenceScore` et un flag `accepted`.
—
## Points de design notables
Patterns récurrents bien appliqués : soft delete via `deletedAt` sur User, Customer, Owner, Property. Unicité tenant-scoped (`@@unique([tenantId, code])`) sur une vingtaine de modèles. Timestamps `createdAt / updatedAt` systématiques. Index sur toutes les FK et les champs filtrés fréquemment.
Flexibilité via Json : `conditions`, `actions`, `configuration`, `assumptions`, `payload` sont stockés en Json sur plusieurs modèles — c'est un choix délibéré pour la variabilité des règles métier, au prix de l'impossibilité de les requêter côté DB.
Multi-acteur dans Messaging : `ConversationParticipant` et `Message` supportent trois types d'émetteurs (User, Customer, Owner) via des FK optionnelles. Le fix appliqué (UUID propre + `@@unique` nullable) est la bonne approche PostgreSQL.
Un point d'attention : `AutomationExecution` a maintenant `automationRuleId` et `automationScenarioId` tous deux optionnels — il n'y a pas de contrainte DB qui force qu'exactement l'un des deux soit renseigné. C'est à gérer au niveau applicatif (ou via une check constraint en migration SQL manuelle).