# Variables d'environnement : répertoires de projet et de données Les variables de [Variables d'environnement](/fr/docs/env-vars) sont des valeurs : un port, une URL, une chaîne de connexion. Les quatre traitées ici sont des _chemins_, et ce sont celles dont un processus superviseur a besoin : l'application de bureau Sovrium, une unité systemd, une étape de CI. Toutes sont optionnelles. Non définies, elles se résolvent sur le répertoire de travail, ce que veut quelqu'un qui tape `sovrium start` dans le dossier de son projet. ## Exécution sous un superviseur Un superviseur sait quel dossier contient l'application, mais ne choisit pas le répertoire de travail depuis lequel le binaire est lancé. Ces quatre variables lui permettent de le dire sans `cd`. Toutes relèvent de l'environnement, jamais du schéma : rien de la façon dont une application est supervisée n'entre dans `AppSchema`, si bien qu'une configuration rédigée sous un superviseur s'exécute telle quelle dans Docker, sur un serveur et en CI. | Variable | Par défaut | Description | | --------------------------------- | ----------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `SOVRIUM_PROJECT_DIR` | non définie (le répertoire de travail) | La racine du projet : où `start` et `build` cherchent une configuration, et la prison dont tout le graphe de configuration ne doit pas sortir. | | `SOVRIUM_CONFIG_FILE` | non définie (`app.yaml` → `app.yml` → `app.ts`) | Le fichier de configuration **à l'intérieur** de cette racine. Nomme un fichier au lieu de sonder des candidats. | | `SOVRIUM_SHUTDOWN_ON_STDIN_CLOSE` | non définie | `1` fait de la fin de fichier sur l'entrée standard un arrêt du serveur, comme le ferait un signal. | | `SOVRIUM_INSTALL_METHOD` | détectée | Le mode d'installation de Sovrium. `desktop` confie la mise à jour à l'application — voir [Administration et maintenance](/fr/docs/cli-admin#sovrium-update). | ### Le répertoire de projet ```bash SOVRIUM_PROJECT_DIR=/srv/contact-book sovrium start ``` Sovrium **résout** par rapport à ce répertoire ; il ne s'y déplace jamais par `chdir`. Un `process.chdir()` serait une mutation globale au processus, qui relogerait d'un coup et en silence tous les autres chemins relatifs — un argument de configuration relatif, un `SOVRIUM_PUBLIC_DIR` relatif — et sa justesse dépendrait de l'ordre dans lequel ceux-ci se trouvent lus. Trois conséquences en découlent, et chacune est le but recherché : **Un chemin que vous passez l'emporte toujours.** `SOVRIUM_PROJECT_DIR` déplace l'endroit où `start` et `build` _découvrent_ une configuration quand vous n'en nommez aucune. `sovrium start ./other.yaml` charge `./other.yaml` relativement au répertoire de travail exactement comme avant, et il en va de même pour `APP_SCHEMA_FILE` et `APP_SCHEMA`. **`SOVRIUM_CONFIG_FILE` nomme un fichier dans la racine, pas un chemin qui en sort.** Elle remplace le sondage des candidats par un fichier nommé, parce que nommer `staging.yaml` désigne ce fichier-là et qu'un repli sur `app.yaml` démarrerait quelque chose que vous n'avez pas demandé. Une valeur qui se résout hors du répertoire de projet est refusée avant la moindre lecture de fichier : ```console $ SOVRIUM_PROJECT_DIR=/srv/app SOVRIUM_CONFIG_FILE=../secrets.yaml sovrium start Error: SOVRIUM_CONFIG_FILE resolves outside the project directory SOVRIUM_CONFIG_FILE: ../secrets.yaml Project directory: /srv/app It names a config file within the project directory, so it must stay inside it. To run a config elsewhere, point SOVRIUM_PROJECT_DIR at its folder. ``` **Tout le graphe de configuration est enfermé dans la racine — mais seulement si vous en définissez une.** Un `$ref` qui en sort est refusé avant même l'ouverture du fichier référencé : une référence refusée ne révèle donc pas jusqu'à son existence. ```console $ SOVRIUM_PROJECT_DIR=/srv/app sovrium start Using app.yaml (auto-discovered) Error: Failed to parse YAML file: /srv/app/app.yaml Details: $ref resolves outside the project directory: /srv/shared/tables.yaml The project directory is /srv/app, and the whole config graph must stay inside it. ``` Cette prison n'existe que là où quelque chose l'a demandée. Non définie, la racine de projet retombe sur le répertoire de travail : c'est le bon défaut pour _résoudre_ un chemin et le mauvais pour le _confiner_, car une configuration légitimement chargée d'ailleurs — `sovrium start ../other/app.yaml` — tire aussi des `$ref` d'ailleurs, et enfermer contre un défaut implicite les refuserait tous. Confier un dossier, c'est déclarer que ce dossier est tout ce que le moteur a le droit de lire. ### Arrêt sur fin de fichier Windows n'a pas de `SIGTERM` : un superviseur n'y dispose d'aucun moyen portable de demander à un enfant de s'arrêter. Fermer l'entrée standard de l'enfant en est l'équivalent portable, et `SOVRIUM_SHUTDOWN_ON_STDIN_CLOSE=1` en fait une demande d'arrêt : ```text 23:19:30 [server] stdin closed — stopping 23:19:30 [server] stopped ``` C'est l'arrêt gracieux qu'exécute un signal — le fichier de verrou est retiré, les requêtes en cours se vident, le processus sort en `0` — si bien qu'un arrêt sur fin de fichier est indiscernable d'un arrêt sur signal pour qui lit ensuite le code de sortie ou le fichier de verrou. Elle **ajoute** un déclencheur sans en remplacer aucun : `SIGINT` et `SIGTERM` continuent de fonctionner exactement comme aujourd'hui. L'option se demande, et elle continue de se demander. Un serveur est couramment lancé avec l'entrée standard déjà fermée — `nohup`, une unité systemd, une étape de CI, `sovrium start &` — et un gestionnaire de fin de fichier inconditionnel tuerait chacun d'eux à l'instant de son démarrage. Ne la définissez que depuis un superviseur qui tient l'entrée standard ouverte aussi longtemps qu'il veut le serveur vivant. ## Répertoire de données Les artefacts d'exécution vivent sous un répertoire unique, pour qu'une racine de projet neuve reste propre. | Variable | Par défaut | Description | | ------------------ | --------------------- | ---------------------------------------------------------------------------------- | | `SOVRIUM_DATA_DIR` | `./.sovrium` | Répertoire de base des artefacts générés à l'exécution. Résolu en chemin absolu. | | `SOVRIUM_LOCK_DIR` | répertoire de données | Répertoire du fichier de verrou du serveur (PID et empreinte de la configuration). | ```text .sovrium/ database.db # SQLite par défaut — DATABASE_URL remplace encryption-key # secret racine propre à l'installation — SOVRIUM_ENCRYPTION_KEY remplace lock # PID du serveur + empreinte de config — SOVRIUM_LOCK_DIR remplace storage/ # fichiers téléversés en local — STORAGE_LOCAL_DIRECTORY remplace ``` `SOVRIUM_DATA_DIR` ne déplace que l'emplacement de _repli_. Chaque artefact garde sa propre variable de remplacement, et celle-ci l'emporte toujours. L'URL de la base de données est traitée sur [Variables d'environnement](/fr/docs/env-vars), le répertoire de stockage sur [Variables d'environnement : services](/fr/docs/env-vars-services). :::callout **Une valeur relative se résout par rapport au [répertoire de projet](#le-rpertoire-de-projet)**, et non par rapport au répertoire de travail. Un même `SOVRIUM_DATA_DIR=.sovrium` désigne donc un dossier différent sous chaque projet qu'un superviseur ouvre, sans quoi deux applications ouvertes depuis un même atelier finiraient par partager une base. Une valeur absolue est prise telle quelle, et sans `SOVRIUM_PROJECT_DIR` le répertoire de projet _est_ le répertoire de travail : rien de ce qui se résout aujourd'hui ne se résout autrement. ::: ## Pages connexes - [Variables d'environnement](/fr/docs/env-vars) — l'application, le serveur, la base de données et les deux secrets. - [Variables d'environnement : services](/fr/docs/env-vars-services) — stockage, IA, e-mail, MCP, éco, observabilité. - [Fichiers de configuration](/fr/docs/configuration-files) — les formats et l'ordre dans lequel une commande cherche une configuration. - [Administration et maintenance](/fr/docs/cli-admin#sovrium-update) — ce que `SOVRIUM_INSTALL_METHOD=desktop` change pour `sovrium update`.