En résumé
Presque tout ce que vous créez dans Linkr est une entité : un projet, un schéma, un pipeline ETL, un plugin… Neuf types, mais une seule forme — une arborescence de fichiers avec la même fiche d’identité à la racine. Exporter, versionner, publier : ces opérations fonctionnent de la même manière sur les neuf, et c’est ce qui donne à chaque entité une identité qui survit au voyage d’une instance à l’autre.
Neuf types, une seule forme
Un projet et un plugin n’ont rien en commun sur le fond. Pourtant, du point de vue du partage, ils posent les mêmes questions : qui l’a fait, sous quelle licence, dans quelle version, et comment le retrouver si on me le renvoie modifié ?
Linkr répond à ces questions une fois pour toutes. Les neuf types d’entités partagent la même structure.
Les deux conteneurs, que vous connaissez déjà : ils emportent tout ce qu’ils contiennent.
Espace de travail
Le conteneur partagé, avec ses projets et ses ressources communes. S’exporte en entier.
Projet
Une étude, un suivi : ses cohortes, ses analyses, ses tableaux de bord et son code.
Les cinq ressources de l’entrepôt, rangées dans l’Entrepôt de données de l’espace de travail et mutualisées entre les projets. Ce sont elles qui gagnent le plus à circuler : un schéma OMOP ou un jeu de règles de qualité vaut pour tout le monde.
Schéma
La description d’une source : ses tables, ses colonnes, et comment Linkr doit les lire.
Projet d’alignement
Le travail de correspondance entre vos codes locaux et un vocabulaire standard.
Pipeline ETL
La transformation qui convertit une source vers un modèle cible, OMOP par exemple.
Règles de qualité
Un jeu de contrôles à passer sur des données pour en mesurer la fiabilité.
Catalogue de données
La documentation des variables d’un entrepôt : ce que chacune signifie, d’où elle vient.
Collection de scripts SQL
Des requêtes réutilisables, organisées en dossiers, partagées entre projets.
Et l’outillage, qui étend Linkr lui-même.
Plugin
Une analyse empaquetée, configurable et réutilisable, qui devient un widget.
Chacune s’exporte en une arborescence de fichiers : des fichiers JSON de configuration, vos contenus, votre documentation. Ce que vous voyez à l’écran, ce que contient l’archive ZIP et ce qui part dans un dépôt git sont une seule et même chose. Voir Espaces de travail et projets.
La fiche d’identité
À la racine de chaque entité se trouve un fichier entity.json. C’est sa fiche d’identité : il dit de quel type d’entité il s’agit, comment elle s’appelle, qui l’a produite et sous quelles conditions elle est réutilisable.
{
"type": "project",
"name": { "fr": "Réanimation — mortalité", "en": "ICU — mortality" },
"description": { "fr": "Suivi de la mortalité en réanimation" },
// … le contenu propre au type : ici les cohortes, les tableaux de bord …
"createdBy": "Ada Lovelace",
"createdByDetails": { "orcid": "0000-0000-0000-0001" },
"organization": { "name": { "fr": "CHU de Rennes" }, "type": "hospital" },
"lineageId": "a3f1c2…",
"parentLineageId": null,
"version": "1.2.0",
"license": { "id": "MIT", "name": "MIT License" }
}Quatre blocs se suivent toujours dans cet ordre : ce que c’est, le contenu propre au type, par qui elle a été produite, puis comment elle est publiée.
Deux conséquences pratiques. D’abord, l’identité précède le contenu : en ouvrant le fichier, on voit d’abord à quoi on a affaire, pas une mêlée de données. Ensuite, Linkr sait lire une entité sans savoir à l’avance ce que c’est — il lit le champ type et en déduit le reste. C’est ce qui rend l’import universel : vous déposez une archive, Linkr reconnaît son contenu.
L’identité qui survit au voyage
C’est le point le moins visible et le plus utile. Imaginez : vous publiez un jeu de règles de qualité, un collègue l’installe, l’améliore, vous le renvoie. Quand vous le ré-importez, que doit faire Linkr ?
Sans identité stable, il créerait un doublon — deux jeux de règles au même nom, et à vous de démêler. Chaque entité porte donc un identifiant de lignée qui la suit partout : ré-importer la même entité la met à jour sur place.
Identité de lignée
Ce qui fait qu’une entité reste elle-même en changeant d’instance. Elle voyage avec l’export.
Identifiant local
La clé interne de votre instance. Elle ne quitte jamais la machine : chaque instance attribue la sienne.
Une entité issue d’une autre garde aussi une trace de son parent. Imaginez : vous publiez votre projet, code d’analyse compris. Un autre centre le récupère, l’applique à ses propres patients, corrige un biais que vous n’aviez pas vu, ajoute une variable d’ajustement. Son projet sait de quel projet il descend — et le vôtre reste le vôtre.
C’est ce qui permet de suivre une filiation sans confondre l’original et ses variantes : chacun peut retracer d’où vient une analyse, et comparer deux versions d’une même méthode appliquées à deux populations.
L’auteur, l’institution et la licence
Une entité partagée sans auteur ni licence est difficilement réutilisable : on ignore à qui l’attribuer et ce qu’on a le droit d’en faire. Chaque entité porte donc trois informations complémentaires.
- L’auteur — la personne, avec son identifiant ORCID si elle en a un, ce qui rend le travail citable.
- L’organisation — l’institution qui publie. Elle est rangée à côté de l’auteur, et non près de la version, parce qu’il s’agit d’une co-signature et non d’un détail d’emballage.
- La licence — sous quelles conditions un tiers peut reprendre le travail.
Chaque entité peut aussi porter son README et ses images d’illustration. C’est ce qui s’affiche quand quelqu’un la découvre dans le catalogue.
Trois façons de faire circuler une entité
Ces fondations servent trois façons de la faire circuler, traitées chacune dans sa page.
L’archive
Un fichier ZIP à télécharger puis ré-importer ailleurs. La voie la plus simple, disponible même dans le navigateur.
Le dépôt git
Lier une entité à un dépôt distant pour suivre son historique et travailler à plusieurs dans la durée.
Le catalogue
Publier pour la communauté, ou installer ce que d’autres ont publié, en un clic.
Les données ne partent pas par défaut
Exporter une entité n’emporte pas les fichiers de données qu’elle contient : ils sont exclus par défaut, et vous marquez explicitement ceux qui doivent voyager. C’est une protection délibérée — partager un tableau de bord ne doit jamais diffuser des données patients par inadvertance. Voir Import et export.
Pour aller plus loin
- Espaces de travail et projets — les deux niveaux dans lesquels ces entités se rangent.
- Versioning et collaboration — pourquoi Linkr s’appuie sur git plutôt que sur un format propriétaire.
- Publier du contenu — préparer une entité pour qu’elle soit réutilisable par d’autres.