# Variables d’environnement

Les variables ci-dessous sont utilisées par le site (Laravel) et/ou par l’intégration Dolibarr.

## Général
- `APP_ENV`
- `APP_KEY`
- `LOG_CHANNEL`
- `LOG_LEVEL`

## Base de données
- `DB_CONNECTION` (`mysql` en production depuis la bascule — cf. `doc/mysql.md`)
- `DB_HOST`
- `DB_PORT`
- `DB_DATABASE`
- `DB_USERNAME`
- `DB_PASSWORD`
- `DB_LEGACY_SQLITE_DATABASE` — chemin **absolu** de l’ancienne base SQLite, lu
  uniquement par `php artisan db:migrate-legacy-sqlite`.
  Variable distincte de `DB_DATABASE` volontairement : la connexion `sqlite` lit
  `DB_DATABASE`, qui vaut désormais le *nom* de la base MySQL. À laisser vide en dehors
  d’une bascule.

## Sauvegardes (cf. `doc/backups.md`)
- `BACKUP_KEEP_DAYS` (défaut `14`) — rétention à la racine du dossier de sauvegarde.
  Le sous-dossier `manual/` n’est jamais purgé.
- `BACKUP_PATH` (défaut `storage/app/backups`) — dossier de destination de `db:backup`.
- `BACKUP_MYSQLDUMP` (optionnel) — chemin de `mysqldump` / `mariadb-dump`. Vide,
  `db:backup` cherche les deux noms dans le `PATH`.

Ces trois variables sont lues **via `config/backup.php`**, jamais par un `env()` appelé
depuis la commande : avec `config:cache` — que fait `deploy.sh` —, `env()` ne lit plus le
`.env` et renverrait `null` en silence (c’était D-14). Conséquence pratique : **modifier
l’une d’elles en production n’a d’effet qu’après `php artisan config:cache`**, ce que
`deploy.sh` fait à chaque déploiement. Un test refuse leur retour dans un `env()` hors de
`config/` (`tests/Feature/DatabaseBackupCommandTest.php`).

## Emails
- `MAIL_MAILER`
- `MAIL_HOST`
- `MAIL_PORT`
- `MAIL_USERNAME`
- `MAIL_PASSWORD`
- `MAIL_FROM_ADDRESS`
- `MAIL_FROM_NAME`
- `MAIL_QUOTATION` (destinataire du devis en cas de succès)
- `MAIL_DOLIBARR_FAILURE_RECIPIENT` (destinataire du devis en cas d’échec côté Dolibarr)
- `MAIL_ALERTS_RECIPIENT` — alertes **techniques** : sauvegarde de base en échec, devis
  transmis mais non archivé. Sans valeur, repli sur `MAIL_DOLIBARR_FAILURE_RECIPIENT`.
  Ces alertes passent par e-mail et non par les logs, précisément pour rester fiables si
  la stack de logs est mal configurée (cf. « Points de vigilance » ci-dessous).

## Dolibarr (logiciel de gestion)
- `DOLIAPIKEY` (header `DOLAPIKEY` envoyé à Dolibarr)
- `DOLIBASEURL` (ex: `https://10.0.2.10/api/index.php`)
- `DOLIBARR_SSL_VERIFY`
  - `true` (recommandé) => vérifie le certificat Dolibarr
  - `false` => dépannage (moins sécurisé)
- `DOLIBARR_SSL_CA_PATH` (optionnel) => chemin vers un bundle de CA pour valider un certificat self-signed
- `DOLIBARR_SYNC_WHEN_NOT_PRODUCTION` (`true`/`false`) : si `true`, les devis sont aussi envoyés à Dolibarr quand `APP_ENV` n’est pas `production` (utile pour tests Docker en local)

## Logs Discord (optionnel)
- `LOG_CHANNEL=discord`
- `LOG_DISCORD_WEBHOOK_URL` (webhook Discord)

## Points de vigilance — variables lues autrement qu’on le croit

Repérés pendant le chantier de bascule, non corrigés à ce stade (cf. la section « Dette
technique » de `doc/suivi-chantier.md`). Les connaître évite de chercher longtemps
pourquoi une variable « ne prend pas ».

- `LOG_STACK` est **ignorée** : `config/logging.php` code la stack en dur sur
  `['single']`. Le canal `nightwatch` référencé dans le `.env` n’existe pas. (D-1)
- `APP_LOCALE` et `APP_FALLBACK_LOCALE` sont **ignorées** : `config/app.php` code
  `locale` et `fallback_locale` en dur. (D-2)
- `CACHE_STORE` est **ignorée** : `config/cache.php` lit `CACHE_DRIVER`. (D-3)
- `BACKUP_PATH`, `BACKUP_KEEP_DAYS` et `BACKUP_MYSQLDUMP` étaient **ignorées en
  production**, `db:backup` les lisant par `env()` alors que la configuration est en
  cache. ✅ **corrigé** : elles passent par `config/backup.php` (cf. « Sauvegardes »
  ci-dessus). (D-14)
- `.env` contient un webhook Discord en clair : `chmod 600 .env` en production, et
  rotation recommandée. (D-6)