> ## Documentation Index
> Fetch the complete documentation index at: https://docs.solya.app/llms.txt
> Use this file to discover all available pages before exploring further.

# Vue d'ensemble de l'architecture

> Comment Solya est construit — l'application, sa base de données opérationnelle et les couches d'analyse Databricks.

Solya est une application Next.js soutenue par deux magasins de données ayant des rôles distincts.

Voici comment l'architecture s'articule :

```mermaid theme={null}
flowchart TB
    Browser["Navigateur / API"]
    NextJS["Application Next.js<br/>(Actions serveur, Routes)"]
    Services["Services<br/>(logique métier)"]
    Rules["Règles métier<br/>(validation)"]
    
    PostgreSQL["PostgreSQL<br/>(base de données opérationnelle)"]
    
    Databricks["Databricks<br/>(analyse)"]
    Gold["Couche gold<br/>(prêt métier)"]
    Silver["Couche silver<br/>(nettoyée)"]
    
    Browser --> NextJS
    NextJS --> Services
    Services --> Rules
    Services --> PostgreSQL
    Services --> Databricks
    Databricks --> Gold
    Databricks --> Silver
```

## Les composants

<CardGroup cols={3}>
  <Card title="Application Next.js" icon="window">
    App Router + React Server Components. Les actions serveur et les routes `/api/` contiennent la
    logique métier.
  </Card>

  <Card title="Base de données opérationnelle" icon="database">
    PostgreSQL (Drizzle ORM) stocke les entités gérées par l'application : plans, règles, alertes,
    étiquettes, paramètres, audit.
  </Card>

  <Card title="Analyse (Databricks)" icon="layer-group">
    Les couches gold/silver contiennent les données de détail nettoyées et prêtes à l'emploi métier pour l'analyse,
    les prévisions et les décisions.
  </Card>
</CardGroup>

## Deux magasins de données, deux rôles

* **PostgreSQL (opérationnel)** — tout ce que les utilisateurs *créent* dans Solya : plans d'inventaire et
  articles, règles métier et jeux de règles, alertes, étiquettes et règles de tagging, workflows, paramètres,
  modèles de navigation et le journal d'audit. Limité à l'organisation via `organizationId`.
* **Databricks (analyse)** — tout ce qui est *ingéré et calculé* : ventes, commandes,
  mouvements, stock, dimensions, résumés, prévisions et vecteurs de décision. Rempli par
  la plateforme données (ETL des systèmes POS) et lu par l'application pour les tableaux de bord, KPIs,
  la recherche, les alertes et les recommandations. Voir [Modèle de données](/fr/developers/data-model).

## Flux de demande

1. Un utilisateur (navigateur) ou une intégration (token API) appelle une **action serveur** ou une
   **route `/api/`**.
2. L'appel est authentifié et résolu en une **organisation** (voir
   [Authentification & multi-tenancy](/fr/developers/multi-tenancy)).
3. Les **services** exécutent la logique métier — lectures/écritures PostgreSQL et/ou requêtes
   Databricks — et les **règles métier** encadrent les mutations où applicable (voir
   [Moteur de règles métier](/fr/developers/business-rules-engine)).
4. Les réponses utilisent une enveloppe cohérente avec des codes d'erreur stables (voir
   [Codes d'erreur](/fr/developers/error-codes)).

## La plateforme données

Les travaux lourds — ingestion, évaluation d'étiquettes/alertes et calcul de recommandations/décisions —
s'exécutent sur la plateforme données (Databricks). L'application les déclenche en tant qu'
**exécutions** et suit leur statut et leurs journaux (exécutions d'ingestion, exécutions d'évaluation d'étiquettes/alertes,
exécutions de workflow), pour que les travaux de longue durée restent observables à partir de l'interface utilisateur et de l'API.