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.
Un projet se pousse, mais ne se récupère pas encore
Pour un projet, la synchronisation ne va que dans un sens. Vous poussez vos modifications vers le dépôt ; celles faites sur le dépôt distant — par un collègue, par exemple — ne peuvent pas être rapatriées automatiquement. Un bandeau le rappelle dans l’onglet Dépôt Git. La récupération élément par élément a été désactivée : sur un projet, qui mêle tableaux de bord, cohortes, scripts et jeux de données, elle signalait des changements fantômes et écrasait du travail local.
Pour repartir de ce que contient le dépôt, Paramètres › Réinstaller reconstruit tout le projet depuis le dépôt. C’est tout ou rien — ce qui n’a pas été poussé est perdu —, et réservé à qui peut supprimer le projet.
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.