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 à toutes les entités 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.
.gitignore
**/*.csv**/*.parquet**/*.pq**/*.xlsx**/*.xls**/*.edits.json.cache/!datasets/ventilation_collection/ventilation_collection.csv!datasets/ventilation_collection/ventilation_collection.edits.json
Chaque cohorte, liste de concepts, tableau de bord ou fiche patient a son fichier JSON. Les scripts de l’IDE partent tels quels. Un jeu de données laisse dans datasets/_tree.json sa structure — colonnes, types, libellés, contraintes — et dans son dossier ses analyses, mais pas ses lignes. En mode serveur s’y ajoute environments/, la liste versionnée des packages Python et R ; les packages installés eux-mêmes restent sur la machine.
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
Tout fichier de données — CSV, Excel, Parquet — est exclu de l’export et du versioning, où qu’il se trouve : jeu de données, ou fichier de référence rangé dans les scripts de l’IDE. Le .gitignore généré les ignore tous.
Pour inclure un fichier précis, marquez-le : clic droit, Marquer pour le versioning, dans la barre latérale des jeux de données comme dans l’explorateur de l’IDE. Une ligne !chemin le réintègre alors dans le .gitignore. La décision se prend fichier par fichier, jamais globalement.
L'inverse existe pour le code
Un script part par défaut. Pour garder un fichier de code sur votre machine — un brouillon, un script qui contient un chemin local —, clic droit dans l’explorateur de l’IDE, Retirer du versioning : il disparaît de l’export et du dépôt.
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
La page Versioning et export a deux onglets.
Versioning et export
Contrôle de version et export de votre projet.
Export
Télécharger votre projet sous forme d'archive ZIP avec une arborescence compatible git.
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).
- Dépôt Git — l’onglet par défaut. Il connecte le projet à un dépôt distant (GitLab, GitHub…), pour l’historique et le travail à plusieurs. Il demande le mode serveur : en mode navigateur, l’onglet l’indique et ne propose rien d’autre.
- Export — 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. Il fonctionne dans les deux modes.
Récupérer le travail d'un collègue
Quand un collègue a poussé, l’onglet Dépôt Git présente ce qui arrive, élément par élément : un tableau de bord, une cohorte, un script, un champ de la description. Ce que vous et lui avez modifié à des endroits différents se fusionne ; un conflit se tranche à la main. Le détail est dans Versioning git.
Paramètres › Réinstaller reste le recours quand une copie locale est abîmée : il reconstruit tout le projet depuis le dépôt, et ce qui n’a pas été poussé est perdu.
Le reste est commun à toutes les entités
Connecter un dépôt, choisir une branche, sélectionner les fichiers à pousser, et choisir entre un dépôt unique ou un dépôt par élément : 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. Les bases de données, elles, ne voyagent pas : le projet n’emporte qu’un pointeur vers chacune, et l’import le relie à la base correspondante si l’instance d’arrivée la possède. Sinon, vous liez vos propres bases.
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 poussée, 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.