Linkr
Accueil Ressources Outils Documentation Blog Démo
EN
  • Qu'est-ce que Linkr ?
  • Modes de déploiement
  • Démarrage rapide
  • Installation locale
  • Avec Docker
  • Installation manuelle
  • Client-only
  • Votre premier projet
  • Espaces de travail et projets
  • Le pipeline de données
  • Entités et partage
  • Versioning et collaboration
  • Vue d'ensemble
  • Projets
  • Wiki
  • Plugins
  • Membres et rôles
  • Paramètres
  • Schémas
  • Bases de données
  • Sous-bases dérivées
  • Qualité des données
  • Catalogue de données
  • Collections de scripts SQL
  • Pipelines ETL
  • Présentation
  • Projets d'alignement
  • Vue d'ensemble
  • Concepts cibles
  • Éditeur d'alignements
  • Suggestions
  • Évaluation
  • Export
  • Vue d'ensemble
  • Concepts
  • Cohortes
  • Données individuelles
  • Pipeline
  • Jeux de données
  • IDE
  • Applications web
  • Versioning
  • Vue d'ensemble
  • Onglets et widgets
  • Widgets intégrés
  • Widgets d'analyse
  • Cartes de contrôle (SPC)
  • Questionnaires et eCRF
  • Code R et Python
  • Filtres, paramètres et export
  • Vue d'ensemble
  • Mode présentation
  • Exporter un rapport
  • Agents
  • Fournisseurs de modèles
  • Skills
  • Créer du contenu via MCP
  • Import et export
  • Versioning git
  • Catalogue communautaire
  • Publier du contenu
  • Installation en production
  • Configuration
  • Authentification et permissions
  • Fichiers sur le serveur
  • Sauvegarde et restauration
  • Glossaire
  • Raccourcis clavier
  • Notes de version
Documentation Administration Configuration

Configuration

Les variables d'environnement d'une instance : la clé secrète, le dossier de données, les limites d'exécution de code, les modèles d'IA et les dépôts de packages.

En résumé

Une instance se configure par des variables d’environnement, toutes préfixées LINKR_. Trois comptent vraiment : la clé secrète, le dossier de données et l’origine autorisée. Les autres ajustent l’exécution de code, les modèles d’IA et les dépôts de packages. Les réglages modifiables dans l’application sont un sujet distinct, traité en fin de page.

Client Non disponible en mode client-only — cette fonctionnalité nécessite un backend. Backend Disponible avec le backend FastAPI.

Les trois qui comptent

Le reste a des valeurs par défaut raisonnables. Celles-ci, non.

LINKR_SECRET_KEY=<une chaîne aléatoire longue>   # obligatoire
LINKR_DATA_DIR=/var/lib/linkr                    # c'est cela qu'on sauvegarde
LINKR_CORS_ORIGINS=https://linkr.exemple.fr      # l'adresse publique réelle
LINKR_DEBUG=false

LINKR_DEBUG doit rester à false en production

Ce n’est pas qu’un réglage de confort : le mode debug est la seule chose qui autorise le démarrage avec la clé secrète d’exemple ou une origine en joker. Il change aussi le format des journaux, qui passent du JSON structuré à un affichage lisible à l’écran.

La clé secrète

Elle fait deux métiers à la fois, et c’est ce qui explique les précautions.

Elle signe les jetons de connexion

La changer déconnecte immédiatement tout le monde. Les mots de passe des comptes ne sont pas touchés : personne n’est enfermé dehors, chacun se reconnecte.

Elle chiffre les secrets au repos

La clé de chiffrement en est dérivée : il n’y a donc pas de second secret à gérer, mais changer l’un change l’autre.

Quatre choses sont chiffrées avec elle : les mots de passe des bases de données enregistrées, les secrets des connexions de l’IDE, les jetons d’accès git de chaque utilisateur, et les clés d’API des modèles d’IA.

Perdre la clé ne casse rien bruyamment — et c'est le piège

Le déchiffrement échoue en silence plutôt qu’en erreur. L’instance démarre, l’interface fonctionne, mais chaque mot de passe de base, chaque jeton git et chaque clé d’API devient illisible et devra être ressaisi à la main. Sauvegardez cette clé comme vous sauvegardez les données.

Le dossier de données

Une seule variable désigne l’endroit où tout est rangé. Le dossier est créé au premier démarrage.

ContenuCe que c’est
linkr.dbLa base applicative, quand vous n’en déclarez pas d’autre : comptes, projets, métadonnées.
_files/Les fichiers, rangés par empreinte : jeux de données, pièces jointes, imports. Deux fichiers identiques ne sont stockés qu’une fois.
projects/Un dossier de travail par projet : les scripts et les jeux de données, sous leurs vrais noms.
workspaces/, mapping-projects/…Les copies de travail git de chaque entité liée à un dépôt.
.cache/Les caches de packages R et Python, partagés par tous les projets. Reconstructible : on peut s’en passer dans une sauvegarde.
_tmp/Les envois en cours. Nettoyé automatiquement.

Jamais deux instances sur le même dossier

Le disque fait autorité, sans table de correspondance : deux instances partageant un dossier de données se marcheraient dessus.

Un nettoyage automatique passe au démarrage puis toutes les six heures : envois abandonnés, fichiers que plus rien ne référence, dossiers de projets supprimés.

La base applicative

Par défaut, un fichier SQLite rangé dans le dossier de données. Pour un usage multi-utilisateurs soutenu, PostgreSQL est recommandé :

LINKR_DATABASE_URL=postgresql+asyncpg://linkr:motdepasse@localhost:5432/linkr

Ce choix se fait à l'installation, pas après

Changer de moteur sur une instance en service ne déplace pas les données : l’instance repartirait d’une base vide. C’est pourquoi l’interface ne propose pas de basculer vers PostgreSQL — voir plus bas.

L’exécution de code

C’est la partie la plus sensible, et la plus ajustable.

LINKR_ENABLE_CODE_EXECUTION=false   # coupe l'exécution sur toute l'instance

Cet interrupteur prime sur les permissions

Quand il est à false, plus personne n’exécute de code, quels que soient les droits. L’IDE, les terminaux, les environnements de packages et le sélecteur de dossiers serveur sont refusés avec un message explicite. Désigner une base par son chemin reste possible : attacher des données en lecture n’est pas exécuter du code.

Les limites

VariableDéfautCe qu’elle limite
LINKR_EXECUTION_TIMEOUT_SECONDS120Une exécution interactive. Le compteur repart à chaque sortie affichée : un script bavard n’est pas interrompu.
LINKR_JOB_TIMEOUT_SECONDS1800Une tâche de fond. Contrairement au précédent, c’est une limite ferme.
LINKR_MAX_KERNELS_PER_USER5Les processus simultanés par utilisateur — sessions de code et terminaux confondus.
LINKR_SESSION_TIMEOUT_MINUTES60L’inactivité avant fermeture d’une session de code. La connexion de l’utilisateur n’est pas touchée.
LINKR_MAX_BUILD_CONCURRENCY2Les traitements longs simultanés sur le serveur : constructions d’environnements et tâches de fond partagent ce budget.
LINKR_MAX_UPLOAD_MB2048La taille d’un envoi. Le proxy livré plafonne plus bas — voir Installation en production.

Les dépôts de packages

Utile en réseau fermé, ou pour imposer un miroir d’établissement :

LINKR_PIP_INDEX_URL=https://pypi.interne.fr/simple
LINKR_R_REPOS=https://cran.interne.fr

Le dépôt R par défaut fournit des binaires

Il est réglé sur un miroir qui distribue des paquets déjà compilés pour Linux. Un miroir CRAN classique obligerait le serveur à compiler chaque paquet, ce qui allonge considérablement les constructions d’environnement.

Les modèles d’IA

L’assistant peut s’adresser à un modèle local ou distant, et la distinction est une décision de gouvernance.

LINKR_ALLOW_REMOTE_LLM=false   # valeur par défaut

Un modèle distant signifie que les requêtes — qui peuvent porter du contexte clinique — sortent de l’établissement. L’autorisation est donc à donner explicitement, et non à retirer.

Deux verrous indépendants, et c'est voulu

L’interrupteur d’instance répond à « l’établissement autorise-t-il les sorties ? ». Une seconde confirmation, par fournisseur déclaré, répond à « quelqu’un en prend-il la responsabilité ? » — la personne qui déclare un modèle distant doit cocher une phrase reconnaissant que les données quittent l’établissement, et son nom est enregistré. Les deux protègent de choses différentes.

Les modèles eux-mêmes se déclarent par espace de travail, dans l’interface, avec leur adresse et leur clé d’API. Les clés sont chiffrées et ne sont jamais renvoyées au navigateur. Toute adresse compatible avec l’API OpenAI convient — un modèle local servi sur la machine, ou un service hébergé.

Les adresses internes sont filtrées

Le serveur refuse de s’adresser à certaines adresses réservées ou de service, ce qui évite qu’un fournisseur déclaré serve à sonder le réseau interne depuis l’application.

Ce qui se règle dans l’application

Tout ne passe pas par des variables. La page Paramètres porte plusieurs onglets, chacun protégé par un droit :

  • Général — informations sur la base applicative.
  • Organisations, Utilisateurs, Rôles — voir Authentification et permissions.
  • Catalogue — le dépôt depuis lequel le catalogue est lu, pour pointer vers un catalogue interne. Voir Catalogue communautaire.
  • Sauvegarde & sync — importer, exporter et versionner les comptes, rôles et organisations.

L'onglet Général ne reconfigure pas le serveur

Le formulaire de base de données qu’il affiche est une commodité d’affichage conservée dans votre navigateur : il ne change pas la base utilisée par l’instance. Seule LINKR_DATABASE_URL le fait, suivie d’un redémarrage. PostgreSQL n’y est délibérément pas proposé, puisque changer de moteur en cours de vie n’emporte pas les données.

Chaque espace de travail a par ailleurs ses propres réglages — membres, étiquettes, environnements, assistant IA — décrits dans Paramètres de l’espace de travail.

Journaux et supervision

En production, les journaux sortent en JSON structuré sur la sortie standard : ils se récupèrent avec le collecteur de votre plateforme. En mode debug, ils passent à un affichage lisible à l’écran.

Ce qui n'existe pas

Il n’y a ni envoi de courriel — donc pas de réinitialisation de mot de passe par mail ni d’invitation : un administrateur attribue les mots de passe à la main —, ni fichier de journal ou rotation à configurer, ni métriques exposées. Pour surveiller l’instance, vous disposez seulement de l’adresse /api/v1/health, qui répond si le serveur est vivant.

Pour aller plus loin

  • Installation en production — où placer ces variables.
  • Sauvegarde et restauration — ce que le dossier de données implique.
  • Fichiers sur le serveur — délimiter ce que le sélecteur atteint.
  • Authentification et permissions — les droits qui ouvrent ces écrans.
PrécédentInstallation en productionSuivantAuthentification et permissions

Produit

  • Accueil
  • Démo

Ressources

  • Documentation
  • Ressources
  • Outils
  • Blog

Communauté

  • Code source Framagit
  • Code source Github

À propos

  • InterHop.org
  • Contact

2021–2026 InterHop — CC BY-NC-SA 4.0 (site) · GPLv3 (logiciel)