Licence RAG

Serveur de licences du parc Ocade RAG

Signaux du parc Supervision

Licences

0 active

0 active0 suspendue0 révoquée

Vérifications

0 site actif

appels de vérification cumulés

Catalogue plugins

0 plugin

0 licence équipée · gouvernance par liste blanche

Chargement...

Catalogue plugins

Miroir du groupe GitLab plugins-ocade-rag. Le toggle « Disponible » rend un plugin proposable (axe global, distinct des droits par licence).

Aucun plugin. Cliquez sur « Synchroniser GitLab » pour remonter le catalogue.

Guide technique complet — fonctionnement, anti-triche, variables & pièges

Chaque instance RAG Platform (le « produit », ex. rag.autocade2.fr) vérifie sa licence en appelant POST /api/verify de ce serveur avec sa LICENCE_KEY (variable Coolify). La réponse fait autorité — elle vit dans cette base, le client n'y a pas accès et ne peut pas se réactiver lui-même. La plateforme revérifie au boot, toutes les ~30 min, et de façon paresseuse sur le chemin chaud.

1. Les 4 statuts

active	Tout fonctionne, mises à jour autorisées.
suspended	L'outil fonctionne (HTTP 200, `valid:true`) mais `updates:false` → badge + bannière ambre « Licence suspendue ». Ne bloque jamais l'usage.
revoked	L'instance se bloque (403 sur le chat) si le mode ENFORCE est actif. Pour une rupture de contrat.
expired	Comme `revoked`, automatique au passage de `expires_at`.

2. OBSERVE vs ENFORCE — l'interrupteur de blocage

Depuis le 2026-06-11, la plateforme est en ENFORCE par défaut : une licence révoquée/expirée bloque le chat (403) sans qu'aucune variable ne soit à poser. Le badge/bannière s'affichent comme avant.

Pour désactiver le blocage (mode observation — débloquer tout le monde sans redéployer une autre version) : poser LICENCE_ENFORCE=0 sur l'app RAG INTERFACE + redeploy. suspended ne bloque jamais (seul revoked/expired bloque).

Le client n'est pas bloqué malgré la révocation ? Deux causes : (1) l'instance tourne une version antérieure au 2026-06-11 (avant le blocage par défaut) → Redeploy la dernière version ; (2) la variable LICENCE_ENFORCE est restée à 0 (mode observation) → la retirer (ou la passer à 1) dans la section « Environment Variables » (PAS « Preview Deployments »), « Available at Runtime », puis Redeploy. Signe que c'est bon : badge rouge ET le chat renvoie 403.

3. Suspendre / Révoquer / Réactiver

Suspendre (retard de paiement, litige doux) → bouton Suspendre → statut suspended. L'outil tourne toujours, badge ambre côté client. Pour couper réellement les mises à jour : désactiver aussi la deploy key GitLab (voir §7).
Révoquer (fin de contrat) → bouton Révoquer → statut revoked → en ENFORCE, le chat renvoie 403 dans ~1 min (ou au reload côté client). Désactiver aussi la deploy key pour bloquer les màj de contournement.
Réactiver → bouton Réactiver → active (le client retrouve l'accès en ~1 min) + réactiver la deploy key si tu l'avais coupée.

4. Toutes les variables d'environnement

App	Variable	Rôle
LICENCE RAG	`SUPABASE_DB_URL`	OBLIGATOIRE — sinon les auto-migrations ne s'appliquent pas (voir §8).
LICENCE RAG	`LICENCE_SIGN_KEY`	Clé privée Ed25519 → le serveur signe ses réponses (anti faux-serveur).
RAG INTERFACE	`LICENCE_KEY`	La clé de licence du client (celle créée ici).
RAG INTERFACE	`LICENCE_ENFORCE`	Plus besoin de la poser — blocage actif par défaut (403) généré nativement. Mettre `0` seulement pour désactiver (mode observation).
RAG INTERFACE	`LICENCE_REQUIRE_SIG`	`1` = refuse les réponses NON signées (ferme le faux serveur). À poser après LICENCE_SIGN_KEY (voir §5).
RAG INTERFACE	`LICENCE_INSTANCE_ID`	Optionnel — ID stable de l'instance (sinon aléatoire à chaque boot ; utile pour la géoloc/anomalies).

5. Anti-triche : signatures Ed25519 (ordre CRITIQUE)

Sans signature, un client malin pointe LICENCE_VERIFY_URL vers un faux serveur renvoyant valid:true. La signature ferme ce trou : le serveur signe, la plateforme exige + vérifie avec la clé publique embarquée. L'ordre évite de bloquer un client légitime (clé publique sur la plateforme AVANT que le serveur ne signe) :

Redéployer RAG INTERFACE (récupère la nouvelle clé publique embarquée).
Poser LICENCE_SIGN_KEY sur LICENCE RAG → redeploy. Le serveur signe.
Vérifier que /api/verify renvoie une sig non nulle et valide.
Poser LICENCE_REQUIRE_SIG=1 sur RAG INTERFACE → redeploy. Faux serveur bloqué.

6. Détection d'anomalies (section en haut du dashboard)

Le dashboard recalcule à chaque chargement, à partir des vérifications (qui portent IP, pays, instance_id) :

Partage de clé : une même clé vue depuis ≥3 instances distinctes sur 24 h.
Multi-pays : clé vérifiée depuis ≥3 pays distincts.
Instance muette : licence active qui vérifiait régulièrement puis s'est tue >48 h (vérification peut-être retirée du code = triche).

Les anomalies apparaissent en rouge en haut ; bouton Acquitter pour les retirer. E-mail proactif : à venir (nécessite une config SMTP sur ce serveur).

7. Ce que le client voit

Sur suspended : badge ambre « Licence suspendue » + bannière (partout) + page /licence au clic. Sur revoked : badge rouge « Licence révoquée » + bannière rouge. La page /licence explique le statut et donne le contact contact@ocadefusion.fr.

8. Pièges critiques

SUPABASE_DB_URL obligatoire sur LICENCE RAG : le repli RPC des auto-migrations ne fonctionne pas sur cette base (la fonction exec_migration n'y existe pas). Sans cette variable, toute nouvelle migration échoue en silence (ex. le statut suspended renverra une 500 au suspend). Format : postgresql://postgres:PWD@supabase-db-…:5432/postgres.

Deploy key : par convention coolify-rag-<client> (champ deploy_key_hint = aide-mémoire). La désactiver coupe les mises à jour immédiatement (levier le plus rapide, indépendant du statut).

9. Limites assumées (« solide pragmatique 95 % »)

Le client a la main sur son code et son Coolify. Un client déterminé peut retirer la vérification du code source ou poser LICENCE_ENFORCE=0 → imbloquable à 100 %. La parade : la deploy key (coupe les màj) + la détection d'anomalies (l'instance muette le trahit) + la traçabilité des vérifications. Reculer l'horloge pour étendre la grâce 7 j est bloqué (anti-rollback).

Guide marketplace plugins — fonctionnement, mode pilote, propagation

Le marketplace distribue des plugins (extensions de l'outil RAG) aux instances clientes, par licence et de façon contrôlée. Chaque instance ne reçoit que ce à quoi sa licence lui donne droit, sans jamais accéder au code source privé.

1. Principe — 1 repo GitLab = 1 plugin

Chaque plugin est un repo GitLab privé du groupe PLUGINS-OCADE-RAG. Le bouton « Synchroniser GitLab » (section Catalogue plugins) remonte ces repos dans le Catalogue (lecture du manifest : nom, description, version).

Deux axes distincts contrôlent la distribution :

Toggle « Disponible » (catalogue) = le plugin est proposable globalement (axe global, ON/OFF pour tous).
Droits PAR LICENCE (bouton « Plugins » sur une ligne) = on coche quels plugins cette licence reçoit.

2. Ce que l'instance reçoit réellement

Une instance ne reçoit que les plugins « Disponible » ET accordés à sa licence(l'intersection des deux axes ci-dessus). La liste est fournie par l'endpoint signé entitlements, que l'instance interroge :

environ une fois par jour et au démarrage (boot) de l'instance ;
à chaque invalidation — le compteur plugins_rev (renvoyé par /api/verify) change et l'instance se rafraîchit ;
immédiatement via le bouton « Forcer le refresh » (une licence) ou « ↻ Rafraîchir tous les sites » (toutes les licences) → propagation en ~1 min.

3. Mode pilote — tester avant de propager

Une licence marquée « Pilote » (toggle sous le bouton « Plugins », badge Pilote sur sa ligne) reçoit la dernière version de chaque plugin (le head_ref, dernier commit) en avant-première. Toutes les autres licences reçoivent la version « publiée » — une réf figée (published_ref), qui ne bouge pas tant qu'on ne publie pas.

Le bouton « Publier » sur un plugin (catalogue) fige la version courante comme publiée(head → published) et la propage à toutes les instances (le pilote, lui, est déjà sur head). Les sites l'installent en ~1 min.

Le badge « MAJ en attente » (catalogue) signale qu'une version plus récente existe (head ≠ publié) mais n'a pas encore été publiée : seul le pilote la voit pour l'instant.

4. Sécurité — le code privé n'est jamais exposé

L'instance ne voit jamais le code source GitLab : elle télécharge le plugin via un relais de ce serveur de licence. Le token GitLab reste côté serveur et n'est jamais transmis au client.
Les réponses d'autorisation (endpoint entitlements) sont signées Ed25519 : un faux serveur de licence local ne peut pas fabriquer une liste d'autorisations acceptée.
Le droit est revérifié en direct au moment du téléchargement : même si une instance connaît le nom d'un plugin, le relais refuse si la licence n'y a plus droit (« disponible » ET « accordé »).