Configuration
La configuration est répartie dans config/. Cette page explique ce que fait chaque réglage et ce qui se passe quand il manque. Les valeurs de production sont décrites côté DevOps, dans Les variables de l'API.
Quel fichier, quand ?
| Fichier | Lu | Contient |
|---|---|---|
config.exs | à la compilation, toujours | les réglages communs |
dev.exs | à la compilation, en développement | base locale, rechargement du code, secrets de développement |
test.exs | à la compilation, en test | base de test, e-mails coupés, date figée |
prod.exs | à la compilation, en production | cookies sécurisés (secure_cookies: true) |
runtime.exs | au démarrage | en production : tout ce qui vient des variables d'environnement |
Seul runtime.exs est lu au démarrage du serveur : c'est ce qui permet de construire une image Docker, puis de lui donner ses secrets au lancement, sans jamais les écrire dans l'image ni dans le dépôt.
Les variables d'environnement (production)
Obligatoires
Sans elles, l'API refuse de démarrer, avec un message qui dit laquelle manque.
| Variable | Rôle |
|---|---|
DATABASE_URL | l'adresse de la base : ecto://utilisateur:motdepasse@hôte/base |
SECRET_KEY_BASE | la clé secrète de Phoenix (signatures) ; mix phx.gen.secret en génère une |
WEB_URL ou CORS_ORIGINS | l'adresse du site web, pour les liens des e-mails ; sans WEB_URL, la première origine de CORS_ORIGINS |
Recommandées
| Variable | Rôle | Si elle manque |
|---|---|---|
CORS_ORIGINS | les sites autorisés à appeler l'API avec des cookies, séparés par des virgules | aucun navigateur ne peut appeler l'API (le site web ne marche pas) |
JWT_SECRET | la clé qui signe les jetons d'accès | SECRET_KEY_BASE est utilisée à la place |
BREVO_API_KEY | la clé d'envoi des e-mails (compte Brevo) | l'API démarre quand même, mais les e-mails ne partent pas : ils sont seulement signalés dans le journal, sans leur contenu (qui peut contenir un lien secret) |
MAIL_FROM | l'expéditeur des e-mails, vérifié dans Brevo | no-reply@<PHX_HOST> |
PHX_HOST | le nom de domaine de l'API | example.com |
Techniques
| Variable | Rôle | Défaut |
|---|---|---|
PORT | le port d'écoute | 4000 |
PHX_SERVER | démarre le serveur web (dans une release) | — |
POOL_SIZE | le nombre de connexions à la base | 10 |
ECTO_IPV6 | se connecter à la base en IPv6 | non |
DNS_CLUSTER_QUERY | regrouper plusieurs instances (non utilisé aujourd'hui) | — |
Les secrets
Une clé ou un mot de passe ne s'écrit jamais dans le code, dans un commit ou dans un message. Ceux de l'API sont gardés dans la configuration Ansible de production, puis écrits dans le .env de l'application sur le serveur (voir Secrets et accès).
Les réglages du code (config.exs)
| Réglage | Valeur | Rôle |
|---|---|---|
:time_zone | "Europe/Paris" | le fuseau de la mairie : à quel jour appartient une heure (semaines, absences, moyennes, notifications) |
:cors_origins | ["http://localhost:5173"] | le site web en développement |
:web_url | "http://localhost:5173" | les liens des e-mails en développement |
:mail_from | no-reply@timemanager.local | l'expéditeur en développement |
Les réglages des tests (test.exs)
| Réglage | Rôle |
|---|---|
base timemanager_test | une base séparée, vidée à chaque test |
Swoosh.Adapters.Test | aucun e-mail ne part ; les tests vérifient qu'il aurait été envoyé |
:fixed_today = 2026-10-12 | un « aujourd'hui » figé, pour que les règles qui dépendent de la date (4 semaines de corrections) donnent le même résultat chaque jour |
bcrypt log_rounds: 4 | Bcrypt volontairement rapide : sinon, des centaines de mots de passe hachés ralentiraient les tests |