Crealcs Development DokuWiki

Vous affichez une ancienne révision du document ! Si vous l'enregistrez, vous créerez une nouvelle version avec ce contenu.

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).

Résumé

Note : En modifiant cette page, vous acceptez que le contenu soit placé sous les termes de la licence suivante : CC Attribution-Share Alike 4.0 International