# Modèles et exemples La façon la plus rapide d'apprendre Sovrium est de partir d'une application fonctionnelle. Sovrium fournit un ensemble de configurations d'exemple — chacune étant un projet complet et exécutable qui compose de vraies fonctionnalités (tables, authentification, pages, thème, i18n, automatisations) en une seule arborescence de configuration. Ces mêmes exemples servent aussi de modèles `sovrium init`, vous pouvez donc échafauder n'importe lequel dans un nouveau répertoire et commencer à itérer immédiatement. Chaque exemple est un **répertoire** avec un point d'entrée `app.yaml`. Tout ce qui dépasse le plus petit démarrage scinde sa configuration sur une sous-arborescence `config/` à l'aide de [`$ref`](/fr/docs/configuration-files#multi-file-configs-with-ref) — un fichier par entité de collection, un fichier par singleton, les scalaires restant en ligne. Cela reflète la structure que `sovrium init` échafaude pour vous. ## Modèles disponibles | Modèle | Description | | ----------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **hello-world** | Démarrage minimal — une page, aucune collection. Le défaut de `sovrium init`. Reste un seul `app.yaml` pour montrer quand _ne pas_ pré-scinder. | | **landing-page** | Site marketing bilingue avec i18n, un thème, des composants réutilisables et la page d'accueil scindée pour la taille. | | **crud-app** | Application CRUD avec tables (contacts, sociétés), authentification e-mail/mot de passe, un thème et des pages tableau de bord + connexion. | | **api-only** | Mode API sans interface, avec tables (projets, tâches) et authentification — aucune page. Démontre Sovrium en tant que backend. | | **member-portal** | Pages marketing publiques plus une zone de portail protégée par authentification avec sections selon le rôle. Authentification lien magique + mot de passe. | | **mcp-server** | Serveur MCP sans interface exposant des tables à un client LLM via un `aiAccess` par entité — aucune page. Voir [Intégration MCP](/fr/docs/mcp-integration). | | **blog** | Blog avec articles (rich-text), étiquettes, auteurs, et un index plus une route de détail dynamique `/blog/:slug`. | | **docs-site** | Site de documentation présentant la fonctionnalité de pages markdown : de vrais fichiers `.md` sous `content/docs/`, une collection `contentDir`, une barre latérale dérivée du frontmatter, une navigation précédent/suivant, une table des matières et du code coloré par Shiki. Aucune table, aucune authentification. | Plusieurs modèles sont fournis avec un agent éditeur associé (une définition de sous-agent Claude Code) que `sovrium init` installe dans `.claude/agents/`. Voir [`sovrium agents`](/fr/docs/cli#sovrium-agents-list) pour gérer directement les modèles d'agents. ## Échafauder un projet `sovrium init` copie un modèle dans un nouveau répertoire (ou le répertoire courant). Sans `--template`, le démarrage minimal `hello-world` est utilisé. ```bash # Défaut (hello-world, aucun agent associé) sovrium init my-app # Choisir un modèle — installe aussi l'agent éditeur associé sovrium init my-app --template crud-app sovrium init my-app --template landing-page sovrium init my-app --template blog sovrium init my-app --template member-portal # Ignorer l'installation de l'agent associé sovrium init my-app --template crud-app --no-agent ``` Exécutez ensuite l'application échafaudée : ```bash sovrium start app.yaml # Démarrer le serveur de développement sovrium validate app.yaml # Valider sans démarrer ``` Voir la [Référence CLI](/fr/docs/cli#sovrium-init) pour toutes les options de `init`. ## Anatomie d'un exemple Un exemple non trivial ressemble à ceci (disposition abrégée de `crud-app`) : ``` crud-app/ ├── app.yaml # Point d'entrée — référence tout via $ref ├── config/ │ ├── auth.yaml # Singleton : stratégies d'auth, rôles │ ├── theme.yaml # Singleton : jetons de design │ └── tables/ │ ├── companies.yaml # Un fichier par table │ └── contacts.yaml └── public/ # Ressources statiques (favicon, images) ``` Le point d'entrée `app.yaml` rassemble chaque partie avec `$ref`, gardant le fichier de premier niveau petit et chaque entité dans son propre fichier : ```yaml name: crud-app auth: $ref: ./config/auth.yaml theme: $ref: ./config/theme.yaml tables: - $ref: ./config/tables/companies.yaml - $ref: ./config/tables/contacts.yaml pages: - $ref: ./config/pages/dashboard.yaml - $ref: ./config/pages/sign-in.yaml ``` La résolution de `$ref` a lieu **avant** la validation : tout objet contenant exactement une clé — `$ref` dont la valeur est un chemin relatif — est remplacé par le contenu analysé de ce fichier. Un `$ref` peut lui-même contenir d'autres `$ref`, donc les configurations s'imbriquent à n'importe quelle profondeur. Les formes mono-fichier et multi-fichiers sont interchangeables ; choisissez celle qui garde le projet lisible. :::callout **Quand scinder.** Gardez une configuration dans un seul fichier tant qu'elle est petite (comme `hello-world`). Scindez avec `$ref` dès qu'une section devient assez grande pour mériter son propre fichier — généralement dès que vous avez plus d'une table, d'une page ou un thème conséquent. La mécanique complète se trouve dans [Fichiers de configuration → Configurations multi-fichiers](/fr/docs/configuration-files#multi-file-configs-with-ref). ::: ## Parcours d'apprentissage Un ordre pratique pour parcourir les exemples : 1. **hello-world** — comprendre la forme minimale d'une configuration et le tableau `pages`. 2. **landing-page** — ajouter un thème, des composants réutilisables et l'i18n avec les clés de traduction `$t:`. 3. **crud-app** — introduire les tables, l'authentification et les pages liées aux données (formulaires + tableaux de données). 4. **api-only** / **mcp-server** — exécuter Sovrium sans interface : comme backend REST ou serveur MCP face à un LLM. 5. **blog** / **member-portal** / **docs-site** — combiner routes dynamiques, zones selon le rôle et contenu markdown. ## Pages associées - [Démarrage rapide](/fr/docs/quick-start) — de zéro à une application en cours d'exécution via YAML + CLI ou TypeScript + Bun. - [Fichiers de configuration](/fr/docs/configuration-files) — composition multi-fichiers YAML, JSON, TypeScript et `$ref`. - [Référence CLI](/fr/docs/cli) — `sovrium init`, `sovrium agents` et l'ensemble des commandes. - [Intégration MCP](/fr/docs/mcp-integration) — le modèle de serveur MCP sans interface expliqué.