Fonctionnalité en construction
Cette fonctionnalité n'est pas encore disponible. Voici ce qui est prévu, pour que vous puissiez juger si elle couvrira votre besoin — et nous dire si ce n'est pas le cas.
État — conception arbitrée
Disponibilité prévue — mode serveur uniquement
En résumé
L’assistant n’embarque aucun modèle : c’est l’établissement qui décide lequel l’anime. Un modèle local garde tout à l’intérieur ; un modèle distant fait sortir les requêtes et se trouve derrière deux verrous indépendants. La configuration est réservée au propriétaire de l’espace de travail, et la clé d’accès, une fois enregistrée, n’est plus jamais restituée.
Pourquoi c’est vous qui choisissez
Linkr ne propose pas « son » modèle. Les requêtes de l’assistant portent sur des données de santé : décider où elles partent revient à décider de leur confidentialité. Cette décision appartient à votre établissement, pas à l’éditeur du logiciel.
Un fournisseur de modèle est donc une configuration que vous ajoutez : une adresse, un nom de modèle, éventuellement une clé d’accès. Elle appartient à l’espace de travail, et seul son propriétaire peut la créer ou la modifier.
Local ou distant
Toute la question tient dans l’adresse du point d’accès.
Modèle local
Un modèle qui tourne sur vos machines — Ollama, vLLM, ou tout point d’accès compatible.
Les requêtes ne quittent jamais l’établissement. L’assistant peut alors travailler sur des données cliniques sans restriction particulière : le garde-fou, c’est l’endroit où tourne le modèle.
Modèle distant
Un service hébergé par un tiers — Mistral, OpenAI, ou autre.
Les requêtes sortent de l’établissement. Les lignes de données ne sont pas transmises : seuls la structure et les agrégats le sont, et un bandeau API externe reste affiché partout où le modèle apparaît.
Le caractère local n’est pas déclaré par celui qui configure : Linkr le déduit de l’adresse. Une adresse en localhost, en 127.0.0.1 ou sur un réseau privé est locale ; tout le reste est distant. On ne peut donc pas faire passer un service externe pour interne en cochant une case, ni transformer après coup un fournisseur local en distant pour contourner le contrôle.
Quelles données, quel modèle
Le choix ne dépend pas d’une préférence, mais de ce que contient l’instance.
Une instance sans donnée sensible — un modèle distant est envisageable
Rien n’empêche d’installer Linkr sur votre ordinateur personnel pour développer, apprendre ou préparer une méthode, à condition qu’elle ne contienne que des données synthétiques ou publiques — aucune donnée de patient. Dans ce cas, un modèle hébergé par un tiers ne fait sortir que du code et des structures.
Une instance avec des données patients — le modèle doit être local
Le modèle devient alors un composant de la chaîne de traitement des données de santé. Il relève du même niveau de sécurité que les données elles-mêmes et que les environnements depuis lesquels on y accède : hébergé dans la même enceinte, soumis aux mêmes règles.
Travailler sur deux instances est donc un usage parfaitement légitime : l’une chez vous pour la mise au point, l’autre dans l’établissement pour les données réelles. La méthode voyage de l’une à l’autre — c’est précisément ce que permet l’export d’un projet.
Les deux verrous
Un modèle distant est protégé par deux mécanismes indépendants, qui ne se remplacent pas parce qu’ils protègent de choses différentes.
Le verrou de l’instance
Un réglage au niveau du serveur interdit purement et simplement les modèles distants, et il est actif par défaut. L’administrateur ferme la porte une fois pour toutes : personne ne peut ensuite activer un modèle externe, même par erreur. C’est la garantie la plus forte du dispositif.
La reconnaissance explicite
Si l’instance l’autorise, créer un fournisseur distant demande une confirmation nominative, enregistrée avec son auteur et sa date. Quelqu’un engage sa responsabilité, et cela laisse une trace vérifiable.
Le premier protège l’institution — une politique, pas une bonne volonté. Le second identifie la personne qui a pris la décision. L’un sans l’autre laisserait un trou.
Autoriser un modèle selon l’usage
Un même modèle n’est pas également bon partout : tel modèle compact suffit à composer un tableau de bord et se révèle faible pour écrire du code.
L’autorisation se fait donc par usage : vous indiquez, pour chaque modèle, où il a le droit d’être proposé — les tableaux de bord, l’IDE, et ainsi de suite. Les utilisateurs ne voient que les modèles autorisés à l’endroit où ils travaillent.
La clé d'accès ne ressort jamais
Une clé enregistrée est chiffrée et n’est plus jamais restituée, même à celui qui l’a saisie : l’interface indique seulement qu’une clé existe. Pour la remplacer, on en saisit une nouvelle ; pour la conserver, on laisse le champ vide.
Ce qui n’est pas encore tranché
- Le choix du modèle par l’utilisateur parmi ceux autorisés, plutôt qu’un modèle imposé par surface.
- La conduite à tenir quand un modèle devient indisponible en cours de conversation.
Pour aller plus loin
- Agents — ce que l’assistant fait de ce modèle, et ce qu’il ne pourra jamais faire.
- Configuration — les réglages d’instance, dont l’interdiction des modèles distants.