Architecture

Une installation Liberty Next comporte toujours les mêmes éléments. Docker ou Python change seulement l'emplacement de chacun et la commande qui le pilote (./liberty ou liberty-ops).

Élément	Rôle
Le serveur	Un seul processus Python : l'application web, l'API REST, le planificateur de tâches Nomaflow et les mises à jour en temps réel (Socket.IO), sur un même port.
La base du framework	Historique des exécutions Nomaflow, vues de grille enregistrées, packages de modifications, notifications, historique des mises à jour — ainsi que les utilisateurs et les rôles quand ils sont gérés en base plutôt que dans `auth.toml`.
La configuration	Des fichiers TOML : pools, connecteurs, dictionnaire, menus, écrans, tableaux de bord, graphiques, règles de notification, tâches Nomaflow, paramètres de l'application. Tout ce qui est enregistré dans Paramètres y est écrit.
Les applications sous licence (facultatif)	Nomasx-1, Nomajde et leurs tâches : fichiers de configuration, code Python (`plugins/`) et données de référence, livrés dans un seul wheel.
Deux secrets	La clé maître, qui chiffre les mots de passe stockés dans la configuration, et la clé qui signe les sessions.

Les données affichées par les applications restent dans leurs bases d'origine (Oracle, PostgreSQL…) : Liberty Next les lit au travers des pools de sa configuration et ne copie rien, sauf si une tâche Nomaflow le demande.

Vue d'ensemble — l'installation Docker complète

Trois façons de l'exécuter

	Docker — légère	Docker — complète	Python
Serveur	Conteneur `liberty-next`	Conteneur `liberty-next`	Paquet pipx lancé par systemd
Autour	—	Conteneurs PostgreSQL 16, Traefik, pgAdmin, Portainer	Un PostgreSQL existant, un proxy inverse existant
Base du framework	SQLite	PostgreSQL fourni	Un PostgreSQL existant (SQLite pour un essai)
Adresse	`http://<hôte>:8000/`	`http(s)://<hôte>/`	`http://<hôte>:8000/` derrière un proxy inverse
HTTPS	Un proxy inverse existant	Traefik (HTTPS et Traefik)	Un proxy inverse existant
Applications sous licence	Possible, mais elles demandent PostgreSQL	Oui	Oui
Commande d'exploitation	`./liberty`	`./liberty`	`liberty-ops`
Page	Docker	Docker	Serveur Python

Dans l'installation complète, Traefik est le seul point d'entrée : il envoie / vers Liberty Next, et /pgadmin, /portainer, /traefik vers les outils. PostgreSQL n'est publié que sur 127.0.0.1:5432 — accessible depuis l'hôte ou par un tunnel SSH, pas depuis le réseau.

Emplacement de la configuration

La configuration est répartie à deux endroits, selon la même règle pour Docker et pour Python :

Fichiers	Emplacement
`app.toml` (paramètres de l'application, licence, IA, SSO, SMTP) et `auth.toml` (utilisateurs et rôles locaux)	Le dossier `config/` du répertoire de travail du serveur — ou, pour `app.toml`, le fichier désigné par `LIBERTY_APP_CONFIG`.
`connectors.toml`, `dictionary.toml`, `menus.toml`, `screens.toml`, `dashboards.toml`, `charts.toml`, `notifications.toml`…	Le dossier désigné par `LIBERTY_APPS_DIR` quand la variable est définie — le dossier `config/` des applications sous licence —, sinon ce même dossier `config/`.
`jobs.toml` (Nomaflow)	`plugins/nomaflow/jobs.toml` à côté de ce dossier (`LIBERTY_APPS_DIR/../plugins/…`), sinon `config/jobs.toml`.
Historique de la configuration et des mises à jour (`.versions/`)	À côté de `connectors.toml`.

D'où l'organisation du dossier des applications sous licence, identique en Docker et en Python :

apps/
├── config/      ← LIBERTY_APPS_DIR : connecteurs, écrans, menus, dictionnaire… et .bundled/ (ce qui a été livré)
├── plugins/     ← le code Python des applications, et nomaflow/jobs.toml
└── data/        ← données de référence chargées à l'installation

Emplacement de chaque élément

Élément	Docker — légère	Docker — complète	Python (chemins de la page Serveur Python)
`app.toml`, `auth.toml`	volume `liberty-config`	volume `liberty-config`	`/var/lib/liberty-next/config/`
Autres fichiers de configuration	volume `liberty-config`, ou `release/apps/config/` avec les applications sous licence	idem	`/var/lib/liberty-next/apps/config/`
Code et données des applications sous licence	`release/apps/plugins/`, `release/apps/data/` (montés sur `/apps`)	idem	`/var/lib/liberty-next/apps/plugins/`, `…/data/`
Base du framework	SQLite dans le volume `liberty-data`	PostgreSQL dans le volume `pg-data`	le serveur PostgreSQL existant
Bases des applications sous licence (`nomasx1`, `nomajde`)	—	PostgreSQL dans `pg-data`	le serveur PostgreSQL existant
Secrets	`release/.env`	`release/.env`	`/etc/liberty/secrets.env`
Outils, certificats	—	volumes `pgadmin-data`, `portainer-data`, `traefik-acme`	—
Sauvegardes	`release/backups/`	`release/backups/`	`backups/` à côté du dossier de configuration

Avec Docker, arrêter, recréer ou mettre à jour les conteneurs ne touche ni aux volumes ni à release/apps/ ; seuls docker compose down -v et ./liberty install --reset suppriment les volumes. Le contenu de chaque sauvegarde est détaillé sur Exploitation.

Les deux secrets

L'installation Docker les génère tous deux dans release/.env (mode 0600) ; pour une installation Python, ils sont générés dans le fichier d'environnement du service. En garder une copie hors du serveur.

Secret	Sert à	S'il change
`LIBERTY_MASTER_KEY`	Chiffrer toutes les valeurs `ENC:` de la configuration : mots de passe des pools, clé de licence, clé de l'IA, secret OIDC, mot de passe SMTP.	Toutes les valeurs chiffrées deviennent illisibles : les pools ne se connectent plus. Ne jamais la changer sur une installation existante.
`LIBERTY_JWT_SECRET`	Signer les jetons de session.	Tout le monde est déconnecté et se reconnecte. Rien d'autre n'est perdu.

doctor (Docker ou Python) vérifie que les deux font au moins 32 caractères et que la clé maître déchiffre bien chaque mot de passe de pool. Chaque variable LIBERTY_* et POSTGRES_* peut aussi être lue depuis un fichier : LIBERTY_MASTER_KEY_FILE=/run/secrets/master_key (secrets Docker, Swarm ou Kubernetes).

Au démarrage du serveur

Les paramètres sont lus ; les références ${VARIABLE} des fichiers TOML sont remplacées par l'environnement.
Docker uniquement : les secrets fournis sous forme de fichiers sont lus, le propriétaire du volume de configuration et du dossier des applications est corrigé, puis le processus abandonne les droits root et s'exécute sous l'utilisateur liberty (uid 1000). Au premier démarrage sans applications sous licence, les fichiers de configuration par défaut sont copiés dans liberty-config — un fichier existant n'est jamais écrasé.
Docker uniquement : liberty-admin init-db crée les tables manquantes du framework et, au tout premier démarrage, l'utilisateur admin. Sur une installation Python, cette commande est lancée une fois à la main.
Les tables du framework sont comparées à la version du code : une colonne manquante est ajoutée et enregistrée dans Paramètres → History → Upgrades.
Les migrations de schéma en attente des applications sous licence sont signalées dans le journal ; la mise à jour ou migrate les applique (avec Docker, aussi au démarrage si LIBERTY_AUTO_MIGRATE=1).
Le serveur répond, même si la base du framework est encore injoignable — pour qu'un pool puisse être corrigé depuis Paramètres. /ready indique quand la base répond.

État et versions

URL	Répond	Utilisée par
`/health`	Le processus fonctionne.	Les sondes de vie.
`/ready`	La base du framework répond (`503` sinon).	Le contrôle de santé Docker — un ensemble dont la base est arrêtée apparaît unhealthy — et `liberty-ops start`, qui l'attend.
`/info`	Version et compteurs ; noms des connecteurs et des pools seulement pour un utilisateur connecté.	Vérifications rapides, support.
`/docs`, `/redoc`	La référence de l'API REST.	Les développeurs — voir API REST.

Versions, migrations en attente et dernière mise à jour sont regroupées par status — voir Exploitation.

Vue d'ensemble — l'installation Docker complète​

Trois façons de l'exécuter​

Emplacement de la configuration​

Emplacement de chaque élément​

Les deux secrets​

Au démarrage du serveur​

État et versions​