Linkr
Accueil Ressources Outils Documentation Blog Démo
EN
  • Qu'est-ce que Linkr ?
  • Modes de déploiement
  • Démarrage rapide
  • Installation locale
  • Votre premier projet
  • Espaces de travail et projets
  • Le pipeline de données
  • Versioning et collaboration
  • Schémas WIP
  • Bases de données WIP
  • Qualité des données WIP
  • Pipelines ETL WIP
  • Alignement de concepts
  • Présentation
  • Projets d'alignement
  • Vue d'ensemble
  • Concepts cibles
  • Éditeur d'alignements
  • Suggestions
  • Évaluation
  • Export
  • Catalogue de données WIP
  • Cohortes WIP
  • Données individuelles WIP
  • Jeux de données WIP
  • Collections de scripts WIP
  • IDE WIP
  • Tableaux de bord
  • Rapports WIP
  • Créer un plugin WIP
  • Vue d'ensemble
  • Onglets et widgets
  • Widgets intégrés
  • Code R, Python et SQL
  • Filtres, réglages et export
  • Wiki WIP
  • Versioning WIP
  • Installation en production WIP
  • Authentification et permissions WIP
  • Configuration WIP
  • Sauvegarde et restauration WIP
  • Glossaire WIP
  • Notes de version WIP
Documentation Concepts fondamentaux Versioning et collaboration

Versioning et collaboration

Comment Linkr versionne et partage le travail : export ZIP, intégration git, espaces de travail partagés et standardisation bottom-up.

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.

Client Disponible en mode client-only — tout fonctionne dans le navigateur, sans backend. Backend Backend (FastAPI) en cours de développement.

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 (project.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 dès aujourd’hui ; le push / pull complet arrive avec le mode full-stack.

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. À l’import, Linkr réattribue des identifiants neufs pour éviter toute collision avec le contenu existant. 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 dès aujourd’hui en mode client-only. Les opérations complètes de push / pull et de branches côté serveur relèvent du mode full-stack, en cours de développement.

Ce qui est disponible aujourd'hui

En mode client-only, le partage repose sur l’export / import ZIP et le clonage git à l’import. Le versioning git complet (push / pull, branches, historique côté serveur) et la gestion multi-utilisateur sont prévus avec le backend. 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.
PrécédentLe pipeline de donnéesSuivantSchémas

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)