En résumé
Un projet se sauvegarde comme toute autre entité : une archive ZIP, ou un dépôt git. Le mécanisme est commun aux neuf types et détaillé dans Versioning git ; cette page dit ce qui est propre au projet — ce que son export contient, et ce qu’il laisse derrière.
Ce que contient un projet exporté
L’export produit une arborescence de fichiers lisibles — du JSON et du Markdown — où chaque élément du projet a son fichier.
| Ce qui part | Sous quelle forme |
|---|---|
| Le projet | Ses métadonnées, son readme, sa licence, ses tâches et ses notes. |
| Les cohortes | Un fichier par cohorte : ses critères d’inclusion et d’exclusion. |
| Les listes de concepts | Un fichier par liste. |
| Les tableaux de bord | Un fichier par tableau de bord, avec ses onglets et ses widgets. |
| Les scripts de l’IDE | Vos fichiers R et Python, tels quels. |
| La structure des jeux de données | Les colonnes, leurs types, leurs libellés et leurs contraintes — sans les lignes. |
Le format compte : ces fichiers étant du texte, un outil de comparaison affiche exactement ce qui a changé entre deux versions d’une cohorte. Un critère ajouté se lit sur une ligne.
Les données ne partent pas par défaut
Les lignes de vos jeux de données sont exclues de l’export et du versioning. Ce qui part, c’est la structure : de quoi reconstituer la table, pas son contenu.
Pour inclure un fichier précis, marquez-le explicitement — clic droit sur le jeu de données, Marquer pour le versioning. La décision se prend fichier par fichier, jamais globalement.
Ce que « versionner un jeu de données » emporte vraiment
Marquer un fichier de données inclut aussi son journal de modifications — vos corrections de cellules. C’est cohérent : pour un recueil rempli à la main, le journal fait partie des données. Les deux partent ensemble, ou aucun.
Sauvegarder et versionner
L’onglet Export propose Télécharger ZIP : l’arborescence complète, prête à être archivée, envoyée, ou réimportée ailleurs. C’est le geste le plus simple, et il suffit souvent — archiver l’état d’un projet au moment d’une soumission, transmettre un travail à un collègue.
L’onglet Dépôt connecte le projet à un dépôt distant, pour l’historique et le travail à plusieurs.
Ces deux sorties sont communes à toutes les entités
Connecter un dépôt, synchroniser, récupérer le travail des autres, et choisir entre un dépôt unique ou un dépôt par élément : tout cela fonctionne de la même façon pour un projet, un pipeline ETL ou un espace de travail, et c’est décrit une fois pour toutes dans Versioning git et Import et export.
Ce qui ne part pas
Les données patient — sauf marquage explicite, fichier par fichier —, les mots de passe et jetons de connexion, et les résultats d’exécution : l’effectif d’une cohorte et son attrition dépendent de la base interrogée, pas de la définition, et chaque installation les recalcule.
Le pipeline n'est pas versionné non plus
Le schéma de la page Pipeline reste local tant que son exécution n’existe pas.
Importer un projet
Un ZIP se réimporte, et un dépôt git se clone. Vous retrouvez cohortes, tableaux de bord et scripts — et vous rebranchez vos propres bases de données, puisque les connexions ne voyagent pas.
C’est ce qui rend un projet Linkr réellement reproductible : un collègue d’un autre hôpital rejoue votre démarche sur ses données, sans que les vôtres aient quitté votre établissement.
Pour aller plus loin
- Versioning git — le dépôt, la synchronisation, et le choix d’un dépôt par élément.
- Import et export — les deux sorties, et ce que contient une archive.
- Jeux de données — marquer un fichier de données pour le versioning.
- Publier du contenu — aller plus loin que le partage de projet à projet.