En résumé
Tout ce que vous produisez dans Linkr — projets, plugins, scripts, schémas, wiki — est versionnable et partageable. Deux mécanismes coexistent : l’export / import ZIP, disponible partout et sans installation, et l’intégration git, pour lier projets et espaces de travail à des dépôts distants.
Pourquoi le versioning compte
Une étude, un tableau de bord, un plugin d’analyse représentent un travail qu’on veut conserver, retrouver et transmettre. Sans versioning, chaque analyse repart de zéro et rien ne circule entre équipes. Linkr traite donc projets et espaces de travail comme des objets qu’on archive, partage et versionne — au même titre que du code.
Cela découle directement d’un principe vu au chapitre précédent : un projet est une arborescence de fichiers (entity.json, scripts/, cohorts/, dashboards/…). Versionner un projet, c’est versionner ces fichiers. Voir Espaces de travail et projets.
Deux façons de partager
Export / import ZIP
Télécharger un projet ou un espace de travail complet en archive, réimportable dans n’importe quelle instance Linkr. Disponible dans les deux modes, sans backend.
Intégration git
Lier un projet ou un espace de travail à un dépôt distant (GitLab, GitHub). Cloner, pousser et récupérer demandent le mode serveur.
L’export / import ZIP
C’est la voie la plus simple, disponible immédiatement. Vous téléchargez un projet — ou un espace de travail entier — sous forme d’archive ZIP, puis vous le ré-importez ailleurs. Ré-importer la même entité la met à jour sur place plutôt que d’en créer un double : chaque entité porte une identité qui la suit d’une instance à l’autre. C’est le moyen recommandé aujourd’hui pour sauvegarder son travail et le transmettre à un collègue ou à un autre centre.
L’export d’un espace de travail est granulaire : on choisit ce qu’on inclut (projets, wiki, schémas, bases, scripts SQL, ETL, alignements, plugins), et les identifiants de connexion des bases n’en font jamais partie : aucun mot de passe ne sort dans une archive.
L’intégration git
N’importe quelle entité — un projet, un espace de travail, mais aussi une collection de scripts SQL, un pipeline ETL ou un projet d’alignement — peut être liée à un dépôt git distant. Tout ce qui passe par git — cloner un dépôt à l’import, pousser (push), récupérer (pull) — demande le mode serveur, qui seul embarque un client git.
La récupération existe aujourd’hui pour les alignements de concepts, les schémas, les bases de données et les pipelines ETL. Pour un projet, un espace de travail et les autres entités, Linkr pousse mais ne récupère pas encore : un bandeau le signale dans l’onglet Dépôt Git.
Là où il existe, le pull se fait élément par élément : Linkr présente ce qui arrive du dépôt et vous décidez pour chaque entrée — accepter ou refuser. Ce que vous refusez reste à vous et repart comme une modification à pousser. Tant qu’une entrée n’a pas reçu de décision, le pull n’est pas terminé, et tant que le dépôt est en avance sur vous, le push est bloqué : on ne pousse jamais par-dessus le travail d’un autre sans l’avoir vu.
Les fichiers de données sont exclus par défaut : vous marquez explicitement ceux qui doivent être versionnés, fichier par fichier. Les gros fichiers peuvent passer par Git LFS.
Ce qui dépend du mode
L’export / import ZIP fonctionne partout, y compris dans le navigateur. Tout ce qui passe par git — cloner, pousser, récupérer — et la gestion multi-utilisateur demandent le mode serveur : un navigateur n’a pas de client git. Voir Modes de déploiement.
Le pattern des « liens git »
Comment partager un espace de travail contenant des dizaines de projets, sans tout dupliquer dans une archive géante ? Linkr utilise une approche inspirée des sous-modules git.
Quand un projet (ou un autre contenu) est lié à son propre dépôt git, l’export de l’espace de travail n’emporte pas son contenu complet : il n’emporte que ses métadonnées et un pointeur vers le dépôt. L’espace de travail devient alors un manifeste de liens plutôt qu’un gros bloc monolithique. Au moment du déploiement, chaque dépôt lié est cloné et le contenu complet est reconstitué.
1.L'export de l'espace de travail
Les éléments liés n'y laissent que leur fiche et un pointeur.
2.Un dépôt par élément lié
Chaque équipe y versionne à son rythme.
3.Linkr Portal
Clone chaque dépôt pointé et reconstitue le contenu.
4.Une instance pré-remplie
Un site statique, prêt à ouvrir.
L’intérêt est direct : chaque équipe versionne ses projets dans son propre dépôt, à son rythme, puis les relie dans un espace de travail partagé. On combine l’autonomie de chaque équipe et une vue d’ensemble mutualisée — sans copier les mêmes fichiers à dix endroits.
Déployer une instance pré-remplie : Linkr Portal
Le réassemblage de ces dépôts liés au moment du déploiement est pris en charge par un outil dédié, Linkr Portal : il agrège le code de Linkr et les dépôts de contenu, reconstitue les espaces de travail et publie une instance Linkr pré-remplie (par exemple sur GitLab ou GitHub Pages), avec séparation possible entre contenu public et privé. Son dépôt, linkr-portal, en décrit l’installation.
Tracer l’origine et les versions
Partager suppose de savoir d’où vient une ressource et comment elle a évolué. Les plugins portent pour cela une traçabilité intégrée.
La traçabilité des plugins
Chaque plugin conserve : une empreinte de contenu (un identifiant technique recalculé à chaque enregistrement, distinct du numéro de version lisible), son origine (créateur, organisation, dépôt), une éventuelle filiation (la version dont il a été dérivé) et un journal des changements. On sait ainsi précisément quelle version d’un plugin a produit un résultat, et retracer la lignée d’un plugin repris et adapté par un autre centre.
Collaborer
La collaboration repose d’abord sur les espaces de travail partagés : un conteneur commun où plusieurs personnes retrouvent les mêmes projets, bases, plugins et wiki. Voir Espaces de travail et projets.
En mode full-stack, un espace de travail a des membres avec des rôles — Lecteur, Éditeur, Propriétaire, ou un rôle personnalisé — qui déterminent qui peut consulter, modifier ou supprimer. Les projets héritent du rôle de l’espace de travail, et chacun peut le redéfinir pour une personne. Au-dessus, un administrateur de l’instance gère les comptes. Voir Membres et rôles et Authentification et permissions.
La standardisation, de bas en haut
Cette mécanique de partage sert une conviction : la standardisation en santé fonctionne mieux quand elle émerge du terrain que lorsqu’elle est décrétée à l’avance.
Chaque équipe commence par résoudre ses problèmes locaux — nettoyer ses données, aligner son vocabulaire, écrire ses scripts d’analyse. En partageant ensuite projets, plugins et alignements via git ou ZIP, les bonnes pratiques circulent, sont reprises et adaptées ailleurs. La standardisation se construit ainsi progressivement, par adoption, au lieu d’être imposée d’en haut.
Aucun effort ne se perd : data cleaning, alignement sémantique, scripts d’analyse — tout ce qui est produit pour une étude alimente la suivante.
C’est le pendant collaboratif de l’investissement cumulatif : la qualité et la réutilisabilité se construisent projet après projet, équipe après équipe.
Pour aller plus loin
- Espaces de travail et projets — le conteneur partagé et l’unité de travail.
- Alignement de concepts — évaluation — la revue multi-relecteur en pratique.
- Modes de déploiement — ce que débloque le mode full-stack.