Clé de licence
Le framework est pleinement utilisable sans licence. Chaque concept de la documentation — connecteurs, dictionnaire, écrans, menus, tableaux de bord, graphiques, jobs, authentification — fonctionne sur l'ensemble de fonctionnalités ouvertes sur une installation neuve.
Une clé de licence déverrouille un ensemble organisé d'intégrations supplémentaires : quelques connecteurs de qualité production (bases de données propriétaires, API personnalisées), des apps client livrées et des fonctionnalités avancées. La clé est définie dans Paramètres → Framework → Licence et son statut en direct est exposé sur la page dédiée Paramètres → Licence.
Vue d'ensemble
Paramètres → Licence
L'onglet dédié Licence est en lecture seule et expose l'état actuel.
| Champ | Source |
|---|---|
| Statut | Acceptée / Rejetée — <raison> / Non configurée. |
| Client | Le claim customer du JWT. |
| Édition | Le claim edition. |
| Expire | Le claim exp. Une puce d'avertissement apparaît 30 jours avant l'expiration. |
| Connecteurs sous licence | Liste issue de features.connectors de la clé. Un point rouge apparaît à côté des entrées qui ne sont pas réellement définies dans l'installation. |
| Apps sous licence | Même forme pour features.apps. |
| Plafond utilisateurs | Compte d'utilisateurs courant + plafond, avec une échelle de couleur 90% / 95% / 100%. |
| Droits IA | Fournisseurs autorisés + plafond quotidien de messages + usage courant. |
| ↻ Revérifier | Relit la clé depuis l'environnement et revérifie la signature sans redémarrage. |
L'onglet est gouverné par license:read.
Installer une clé
La clé est enregistrée dans l'environnement de l'hôte (en dehors du disque). Dans Paramètres → Framework → Licence, le champ Clé de licence enregistre le nom de la variable d'environnement qui porte le JWT, et non le JWT lui-même :
| Champ | Effet |
|---|---|
| Clé de licence | Référence à la variable d'environnement. Par défaut ${LIBERTY_LICENSE_KEY}. |
| Chemin de clé publique | Surcharge facultative de la clé publique livrée. Utile lors de l'exécution avec une autorité de signature privée (partenaires OEM qui re-signent des clés). |
Installer une nouvelle clé sur un hôte :
- Exporter le JWT sous la variable d'environnement :
export LIBERTY_LICENSE_KEY="eyJhbGciOi…". - Redémarrer le framework, ou cliquer ↻ Revérifier sur l'onglet Licence — le framework relit la variable et revalide la signature sans redémarrage complet.
Le journal de démarrage imprime une ligne de confirmation :
INFO liberty.licensing license accepted — customer="Acme Corp" edition="enterprise" expires=2026-05-19T00:00:00Z
Une mauvaise clé journalise l'échec et continue ; le framework entre en mode restreint :
WARN liberty.licensing license rejected — reason="signature invalid"
WARN liberty.licensing running in restricted mode — licensed features disabled
En mode restreint :
- Chaque connecteur marqué Sous licence est masqué — il n'apparaît pas dans le catalogue, dans la liste des outils IA ni dans un menu.
- Les apps livrées dans le
features.appsde la clé n'enregistrent pas leur contenu. - L'onglet Licence affiche la raison du rejet et une bannière apparaît à travers l'en-tête.
- Chaque autre concept (connecteurs ouverts, écrans, menus, tableaux de bord, jobs, authentification) continue de fonctionner.
Le mode restreint est le mode par défaut sur une installation neuve sans clé — ce n'est pas un état d'erreur, c'est le mode non sous licence.
Ce que contient un connecteur sous licence
Dans Paramètres → Connecteurs, chaque entrée a une bascule Sous licence. Quand elle est active, le connecteur ne charge que si son identifiant est présent dans le features.connectors de la clé. En mode restreint, la page Connecteurs liste le connecteur comme Verrouillé — requiert la licence <id> avec le reste de sa définition grisé.
C'est ce qui gouverne les connecteurs fournisseur livrés (JD Edwards, SAP, Snowflake, …). Le mécanisme est ouvert — les clients peuvent marquer leurs propres connecteurs Sous licence et livrer des clés à leurs propres clients s'ils distribuent des apps personnalisées.
Vérifier une clé hors-ligne
La CLI liberty-license vérifie une clé sans démarrer le framework :
.venv/bin/liberty-license verify "$LIBERTY_LICENSE_KEY"
# license accepted
# customer="Acme Corp" edition="enterprise"
# expires=2026-05-19T00:00:00Z (in 30 days)
# features.connectors: [jdedwards, sap, snowflake]
# features.apps: [nomajde, nomasx-1]
Sort en code non-zéro avec le diagnostic sur les clés mauvaises / expirées / à audience incorrecte. Voir Référence CLI → liberty-license pour chaque option.
Rotation et renouvellement
Une clé de renouvellement s'installe ainsi :
- Exporter le nouveau JWT sous la variable d'environnement sur chaque hôte.
- Redémarrer le framework, ou cliquer ↻ Revérifier.
Pour les installations à haute disponibilité :
| Phase | Action |
|---|---|
| 30 jours avant l'expiration | Demander la clé de renouvellement au fournisseur. La puce Expire de la clé actuelle passe au jaune. |
| 7 jours avant l'expiration | Installer la nouvelle clé sur chaque réplique via votre outil de gestion des secrets. |
| À l'expiration | L'ancienne clé est naturellement rejetée ; la nouvelle prend le relais. Aucun redémarrage requis car la mise à jour glissante du secret a déjà eu lieu. |
Modes d'échec
L'onglet Paramètres → Licence expose directement le diagnostic. Rejets courants :
| Texte de statut | Cause | Résolution |
|---|---|---|
signature invalid | Mauvaise clé publique, JWT altéré. | Vérifier à nouveau la clé. En cas d'autorité de signature partenaire, définir Chemin de clé publique sur sa clé. |
expired (2026-04-30) | Horodatage exp dépassé. | Installer une clé renouvelée. |
audience mismatch | Le JWT a été émis pour un autre produit. | Confirmer que le fournisseur a envoyé une clé Liberty. |
malformed | La variable d'environnement ne contient pas un JWT valide (espace en trop, troncature accidentelle). | Réexporter la clé avec soin — copier depuis la source à l'identique. |
user cap reached | Le features.users.max de la clé correspond au compte d'utilisateurs actuel. | Demander un plafond plus large, ou désactiver les utilisateurs inactifs. |
Permissions
L'onglet Licence est gouverné par license:read (consultation) et license:write (revérifier, changer le chemin de clé publique). Le sous-formulaire Framework → Licence est gouverné par settings:framework.
Conseils et bonnes pratiques
- Traiter la clé comme une configuration, pas comme un secret profond. Elle est signée et vérifiable côté récepteur ; la coller dans un fil Slack ne compromet rien. La conserver dans le gestionnaire de secrets par hygiène tout de même.
- Définir Chemin de clé publique uniquement quand c'est nécessaire. Le défaut fonctionne pour les clés émises par Nomana-IT — la surcharge concerne uniquement les déploiements partenaires / OEM.
- Surveiller la puce d'expiration à 30 jours. Renouveler tard signifie une courte fenêtre où les connecteurs sous licence disparaissent de l'interface.
- Ne jamais éditer une clé à la main. Un seul changement de caractère invalide la signature ; demander une nouvelle clé au fournisseur à la place.
- Garder l'ensemble de fonctionnalités ouvertes auto-suffisant. Une installation bien conçue devrait rester utile en mode restreint — utiliser les connecteurs sous licence pour la différenciation, pas pour le flux principal.
Sous le capot
Le contenu de la licence est conservé en mémoire uniquement après la lecture de la variable d'environnement. Le formulaire Paramètres → Framework enregistre le nom de la variable d'environnement + le chemin de clé publique facultatif ; le JWT lui-même n'atterrit jamais sur disque. Les paramètres sont enregistrés dans config/app.toml sous la section [license].
Pour aller plus loin
- Authentification — JWT pour les utilisateurs (mécanisme différent, même format JWT).
- Rôles et permissions —
license:readet le reste de la famillesettings:*. - Configuration → Variables d'environnement —
LIBERTY_LICENSE_KEYdans le contrat d'environnement.