En résumé
Une entité circule par deux mécanismes, et deux seulement : l’archive ZIP, qu’on télécharge et qu’on redépose, et le dépôt git, vers lequel on pousse et depuis lequel on clone. Le catalogue n’en est pas un troisième : c’est un annuaire de dépôts git, et installer une entrée revient à cloner son dépôt. Le geste est le même pour les dix types d’entités.
Deux façons de sortir une entité
Toute entité — un projet, un schéma, un pipeline ETL, un plugin — se manipule depuis le menu de sa carte, les trois points en haut à droite. Deux entrées, Exporter et Versioning, y mènent à deux routes distinctes, et le choix dépend de ce que vous voulez faire.
Exporter
Un fichier ZIP, tout de suite.
Pour archiver un état, envoyer un travail par courriel, joindre une annexe à un article. Un instantané, sans suite.
Versioning
Un dépôt git, dans la durée.
Pour garder un historique, travailler à plusieurs, publier. Vous poussez directement depuis Linkr — aucune archive à produire.
Versionner ne passe pas par le ZIP
Les deux entrées ouvrent le même écran à deux onglets, Dépôt Git et Export — une fenêtre pour la plupart des entités, la page Versioning et export pour un projet et pour l’espace de travail. Deux sorties possibles au même endroit, pas deux étapes d’une même opération. Pour versionner, vous liez l’entité à un dépôt et vous poussez — vous ne téléchargez jamais d’archive intermédiaire.
Le contenu envoyé est le même dans les deux cas : la même arborescence de fichiers texte. Voir Versioning git.
Ce que contient l’archive
Le ZIP porte le nom de l’entité. C’est une arborescence de fichiers texte, pas un format binaire opaque : on peut l’ouvrir, la lire, la déposer soi-même dans un dépôt, la joindre à un article.
.gitignore
**/*.csv**/*.parquet**/*.pq**/*.xlsx**/*.xls**/*.edits.json.cache/!datasets/ventilation_collection/ventilation_collection.csv!datasets/ventilation_collection/ventilation_collection.edits.json
Les fichiers de données restent en dehors
L’export ne contient pas vos données, et c’est délibéré : partager un tableau de bord ne doit jamais diffuser des dossiers patients par inadvertance.
L’exclusion porte sur les extensions de fichiers de données — CSV, Parquet, Excel — et sur le journal de modifications qui les accompagne. L’onglet Export d’un projet le rappelle : « Les fichiers de données sont exclus par défaut par sécurité. Pour inclure un jeu de données précis, marquez-le “à versionner” dans la barre latérale Datasets (clic droit). »
C’est là toute la méthode : il n’existe pas d’interrupteur global qui emporterait tout. Vous marquez les fichiers un par un — clic droit sur un jeu de données, Marquer pour le versioning — et une pastille signale ensuite ceux qui partiront.
Marquer un fichier emporte aussi son journal de modifications
Vos corrections de cellules voyagent avec le fichier, jamais séparément. C’est cohérent : pour un recueil rempli à la main, le fichier d’origine ne change pas et les valeurs saisies n’existent que dans ce journal.
Les identifiants de connexion ne sortent jamais
Aucun mot de passe, aucun jeton d’accès ne figure dans un export, et aucune option ne permet de les y mettre. Hôtes, ports, noms de base, comptes : rien de tout cela ne quitte la machine.
Une base exportée emporte son nom et son alignement de schéma — pas une seule ligne de données. La personne qui l’importe redéclare sa propre connexion et pointe vers ses propres fichiers.
Exporter un espace de travail entier
Un espace de travail s’exporte d’un bloc, depuis sa page Versioning et export, onglet Export. Une case par section, les sections de l’entrepôt regroupées, et pour les projets, les alignements et les pipelines ETL une case par élément : on peut en laisser un en dehors.
Export
Téléchargez le contenu du workspace sous forme d'archive ZIP. Sélectionnez les sections à inclure. Les informations de connexion et mots de passe ne sont jamais exportés ; les fichiers de données ne sont inclus que s'ils sont marqués pour le versioning.
Contenu complet du projet : README, scripts, tableaux de bord, cohortes, pipeline. Les fichiers de datasets ne sont inclus que s'ils sont marqués pour le versioning.
Toutes les pages wiki (Markdown), leur arborescence et les pièces jointes.
Entrées de bases : noms et mappings de schéma. Les informations de connexion et mots de passe ne sont jamais exportés.
Pipelines ETL complets avec tous leurs fichiers. Les fichiers de données ne sont inclus que s'ils sont marqués pour le versioning.
Une entité liée à git n'est pas recopiée dans l'archive
Si un élément est lié à un dépôt distant, l’export de l’espace de travail n’emporte que ses métadonnées et son lien — son contenu reste dans son dépôt. L’infobulle le dit : « Seules les métadonnées et le lien Git sont exportés. »
L’export de cette entité prise isolément contient en revanche tout son contenu. La réduction au pointeur ne concerne que les exports d’espace de travail.
Importer
Le bouton Importer d’une page de liste ouvre une fenêtre à trois onglets. Les deux premiers correspondent aux deux mécanismes ; le troisième est un raccourci vers le second, puisque le catalogue pointe vers des dépôts git.
Importer
Importez depuis un fichier ZIP ou clonez un dépôt Git.
- Téléverser un ZIP — une archive exportée depuis Linkr, glissée-déposée ou choisie. Fonctionne dans les deux modes.
- Depuis Git — un dépôt distant, cloné sur le serveur ; l’entité reste liée au dépôt. Cet onglet disparaît quand l’entité est déjà liée à un dépôt.
- Depuis le catalogue — le catalogue filtré sur le type que vous importez, présent seulement pour les types que le catalogue connaît. Installer clone le dépôt de l’entrée : mode serveur requis.
L’onglet Depuis Git attend trois champs : URL du dépôt, Branche, et Jeton — ce dernier seulement pour un dépôt privé. Puis Cloner et importer.
Les messages d'erreur de clonage sont précis, lisez-les
Ils distinguent quatre causes, ce qui évite de chercher au mauvais endroit : dépôt introuvable (l’URL), branche introuvable (le nom de branche), échec d’authentification (le jeton), erreur réseau (la connexion ou le proxy).
Quand l’élément existe déjà
C’est la situation courante dès qu’on travaille à plusieurs : vous réimportez une entité que vous avez déjà. Linkr ne tranche pas à votre place — une fenêtre L’élément existe déjà vous laisse le choix.
L'élément existe déjà
Un élément nommé « OMOP CDM 5.4 » existe déjà. Que souhaitez-vous faire ?
- Créer une copie — les deux versions coexistent. À choisir pour comparer, ou quand vous n’êtes pas sûr de vouloir perdre l’existant.
- Écraser — la version importée remplace la vôtre. À choisir quand l’import fait autorité : vous récupérez la version de référence d’un collègue.
Réimporter la même entité la met à jour, elle ne la duplique pas
Chaque entité porte un identifiant de lignée qui la suit d’une installation à l’autre. C’est ce qui permet à Linkr de reconnaître qu’il s’agit bien de la même entité revenue modifiée, et non d’une nouvelle. Voir Entités et partage.
Ce que l’import vous signale
L’import réussit rarement en silence total, et les messages méritent un coup d’œil.
- Version de Linkr trop ancienne — « Ce contenu nécessite Linkr 2.4.3 ou plus récent… » : l’entité a été exportée dans un format que votre version ne sait pas lire entièrement. L’import est refusé avant toute écriture, plutôt que de laisser une entité à moitié lue. Mettez Linkr à jour, puis importez de nouveau.
- Anomalies de format — l’entité est importée, mais Linkr a relevé des écarts au format attendu. Le message donne leur nombre. Un projet produit par une version plus ancienne, ou modifié à la main, passe souvent par là.
- Éléments liés à Git dont le contenu manque — un espace de travail importé peut contenir des entités réduites à leur pointeur, dont le dépôt est privé. Un panneau les liste, vous saisissez un jeton d’accès, et vous chargez chacune d’un bouton Cloner.
- Importé sans son organisation — l’organisation liée n’a pas pu être créée faute de droits. Un administrateur l’ajoute, puis vous la reliez depuis les paramètres de l’espace de travail.
Importer un projet écrase ses fichiers actuels
Depuis l’onglet Import d’un projet existant, l’avertissement est explicite : « Cela écrasera les fichiers actuels du projet. » Pour conserver les deux, importez plutôt comme un nouveau projet.
Ce qui change selon le mode
Mode serveur
Les trois provenances fonctionnent.
Le clonage s’exécute sur le serveur, ce qui donne accès aux dépôts privés et au catalogue.
Mode navigateur
Le ZIP fonctionne ; le clone git et l’installation depuis le catalogue, non.
Les deux supposent de cloner un dépôt git, ce que le navigateur seul ne sait pas faire. Vous pouvez en revanche parcourir le catalogue.
Voir Modes de déploiement pour savoir lequel vous utilisez.
Pour aller plus loin
- Catalogue communautaire — installer du contenu publié par d’autres équipes.
- Publier du contenu — préparer une entité pour qu’elle soit réutilisable.
- Versioning git — le dépôt git, et ce qui part d’un projet.
- Entités et partage — pourquoi les dix types s’exportent de la même façon.