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). Le clonage à l’import fonctionne partout ; le push / pull demande 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 l’on peut retirer les identifiants de connexion des bases pour ne jamais exporter de mots de passe.
L’intégration git
Un projet, un espace de travail — mais aussi une collection de scripts SQL, un pipeline ETL ou un projet d’alignement — peuvent être liés à un dépôt git distant. Le clonage (récupérer un dépôt à l’import) fonctionne en mode client-only. Le push et le pull demandent le mode serveur, qui seul embarque un client git.
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 et le clonage git à l’import fonctionnent partout, y compris dans le navigateur. Le push / pull 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é.
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 installation sera détaillée dans la section Administration (à venir).
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, l’espace de travail aura des membres avec des rôles — administrateur, éditeur, lecteur — qui déterminent qui peut modifier, publier ou seulement consulter. Cette gestion des droits et l’authentification relèvent du backend et sont prévues, pas encore disponibles.
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.