Skip to main content
View as Markdown

Concepts fondamentaux

Une application Sovrium est un unique objet de configuration déclaratif. Vous décrivez ce qu'est votre application — ses données, ses pages, ses formulaires, son authentification, ses automatisations — et Sovrium transforme cette description en une application web full-stack opérationnelle. Il n'y a aucun code générique, aucun échafaudage de framework et aucun pipeline de build à câbler.

Cette page explique l'anatomie de cet objet de configuration afin que le reste de la référence du Schéma d'application prenne tout son sens.

L'objet de configuration

Tout part d'un seul objet racine. Seul name est obligatoire ; toutes les autres sections sont optionnelles et s'ajoutent en couches à mesure que votre application grandit.

name: my-app # Identifiant de l'application (obligatoire)
version: 1.0.0 # Version SemVer
description: My application # Description en une ligne

tables: [...] # Modèles de données (49 types de champs)
pages: [...] # Pages rendues côté serveur (~80 types de composants)
forms: [...] # Formulaires autonomes qui capturent des soumissions
auth: { ... } # Authentification, rôles, RBAC
theme: { ... } # Jetons de design (couleurs, polices, espacement, …)
languages: { ... } # Prise en charge multilingue (syntaxe $t:)

automations: [...] # Workflows pilotés par événements (déclencheurs + actions)
actions: [...] # Modèles d'actions réutilisables ($ref)
connections: [...] # Identifiants de services externes
agents: [...] # Agents IA agissant sous un rôle d'authentification
buckets: [...] # Conteneurs de stockage de fichiers nommés

components: [...] # Modèles d'interface réutilisables ($ref, $variable)
analytics: { ... } # Analytique de première partie, sans cookie
env: { ... } # Variables d'environnement d'automatisation déclarées ($env.NAME)
scripts: { ... } # Scripts de page globaux

Les sections racine

L'objet de configuration regroupe ses fonctionnalités dans les sections ci-dessous. Chacune renvoie à sa référence dédiée.

Section Objet Référence
name Identifiant de l'application (règles de nommage npm). La seule propriété obligatoire. Métadonnées de l'application
version Chaîne de versionnage sémantique. Alimente le registre de versions immuable. Métadonnées de l'application
description Description de l'application en une seule ligne (2000 caractères max). Métadonnées de l'application
tables Modèles de données — les colonnes que les enregistrements peuvent stocker via 49 types de champs. Vue d'ensemble des tables
pages Pages rendues côté serveur, construites à partir d'un arbre de types de composants, avec SEO et i18n. Vue d'ensemble des pages
forms Formulaires autonomes qui capturent des soumissions dans une table ou déclenchent une automatisation. Vue d'ensemble des formulaires
auth Stratégies d'authentification, rôles, RBAC, sessions et double authentification. Vue d'ensemble de l'authentification
theme Jetons de design : couleurs, polices, espacement, ombres, animations, points de rupture, rayons. Thème
languages Prise en charge multilingue avec la syntaxe de traduction $t: et le routage d'URL. Langues
automations Workflows pilotés par événements : un déclencheur se déclenche, une séquence d'actions s'exécute. Vue d'ensemble des automatisations
actions Modèles d'actions réutilisables référencés depuis les automatisations via $ref. Vue d'ensemble des automatisations
connections Identifiants réutilisables pour les services externes (OAuth2, clé API, basic, bearer). Vue d'ensemble des automatisations
agents Agents IA qui agissent au nom d'un rôle d'authentification dans un ensemble d'outils restreint. Vue d'ensemble de l'IA
buckets Conteneurs de stockage nommés avec des limites de fichiers et des permissions par bucket. Vue d'ensemble des buckets
components Modèles d'interface réutilisables insérés dans les pages via $ref avec substitution de $variable. Vue d'ensemble des pages
analytics Analytique de première partie, sans cookie. true pour les valeurs par défaut ou un objet pour les options. Vue d'ensemble du schéma
env Variables d'environnement déclarées, résolues à l'exécution, référencées comme $env.NAME. Variables d'environnement
scripts Scripts globaux chargés sur chaque page avant les scripts au niveau de la page. Vue d'ensemble des pages

La philosophie pilotée par la configuration

Sovrium inverse la relation habituelle entre code et configuration. Au lieu d'écrire du code applicatif qui lit occasionnellement un fichier de configuration, vous écrivez une configuration que Sovrium exécute directement.

  • Déclarer, ne pas implémenter. Vous déclarez un champ relationship ; Sovrium crée la clé étrangère, les requêtes de jointure et l'interface des enregistrements liés. Vous déclarez une automation ; Sovrium câble le déclencheur, exécute les actions et enregistre l'historique des exécutions.
  • Une seule source de vérité. Le même objet pilote le schéma de la base de données, l'API REST, le serveur MCP, les pages rendues et le tableau de bord d'administration. Il n'y a pas de second endroit où la forme de vos données serait redéfinie.
  • Validation inter-sections. Les sections sont validées ensemble, et non isolément. Une automatisation d'enregistrement qui référence une table inexistante, un champ de pièce jointe pointant vers un bucket non déclaré ou une permission nommant un rôle inconnu sont tous rejetés avant le démarrage du serveur — voir sovrium validate.
  • Auto-hébergeable, sans dépendance. La configuration s'exécute sur votre infrastructure avec un stockage standard (SQLite par défaut, PostgreSQL optionnel). Vos données et votre schéma restent les vôtres.

Le modèle en couches (en un coup d'œil)

En interne, Sovrium suit une architecture à quatre couches. Vous n'écrivez jamais de code dans ces couches pour une application uniquement configurée, mais ce modèle explique pourquoi le schéma est structuré ainsi.

Couche Responsabilité Ce que votre configuration touche
Présentation Rend les pages et sert l'API REST/MCP. pages, forms, components, theme, scripts
Application Orchestre les workflows et les cas d'usage. automations, actions, agents
Domaine Règles métier pures et schéma d'application validé lui-même. tables, auth, languages, validation
Infrastructure Communique avec la base de données, le stockage de fichiers et les API externes. connections, buckets, env

Le sens des dépendances va toujours vers l'intérieur (Présentation → Application → Domaine ← Infrastructure), c'est pourquoi déclarer les données et les règles (tables, auth) est indépendant de la manière dont elles sont rendues (pages) ou persistées (buckets).

Étapes suivantes