En résumé
Publier se fait en trois temps : renseigner l’identité de l’entité — auteur, organisation, version, licence —, la pousser dans un dépôt git public, puis demander son ajout au catalogue. Linkr garantit structurellement qu’aucun identifiant de connexion ni aucune donnée patient ne part avec, mais le reste des vérifications vous appartient.
Pourquoi publier
Un schéma de base, un alignement de codes vers un vocabulaire standard, un jeu de contrôles qualité : ce travail est long, et il est refait à l’identique dans chaque établissement. Le publier, c’est éviter cette répétition à ceux qui viendront après.
C’est aussi, pour un travail de recherche, une façon de rendre une méthode vérifiable. Une cohorte publiée avec ses critères se relit, se discute et se rejoue sur une autre population.
Publier ne diffuse pas vos données
Ce qui part, c’est votre travail : des définitions, des scripts, de la documentation. Les données patient sont exclues par construction — voir Import et export.
Étape 1 — renseigner l’identité
Une entité publiée sans auteur ni licence est difficilement réutilisable : on ignore à qui l’attribuer et ce qu’on a le droit d’en faire. Trois endroits à remplir avant de diffuser.
L’auteur et l’organisation
La fenêtre d’édition de l’entité porte un onglet Attribution, avec deux champs : Auteur et Organisation.
Les deux sont verrouillés par défaut et affichent la valeur d’origine en grisé. Le cadenas ouvre le choix — c’est délibéré : réattribuer un travail est un geste rare, qui doit être volontaire.
Déverrouiller vaut réattribution
Ouvrir le cadenas enregistre la valeur affichée, même si vous ne changez rien ensuite. Pour conserver l’auteur d’origine, laissez le champ verrouillé.
L'onglet Attribution n'apparaît qu'à la modification
À la création, l’auteur est forcément vous : il n’y a rien à réattribuer. L’onglet n’apparaît donc que lorsque vous éditez une entité existante.
L’ORCID, pour être cité
L’identifiant ORCID ne se saisit pas sur l’entité, mais sur votre profil. Il voyage ensuite automatiquement avec tout ce que vous publiez.
Il a une utilité concrète au-delà de la citation : c’est par l’ORCID qu’une autre instance de Linkr reconnaît l’auteur d’une entité importée, et vous crédite correctement au lieu de créditer la personne qui a importé.
La version
L’onglet Métadonnées porte un champ Version, au format semver — 0.1.0 par défaut — avec trois boutons qui proposent le numéro suivant.
Ce numéro compte au-delà de la propreté : le catalogue le compare à celui de la copie installée chez vos utilisateurs pour leur proposer une mise à jour. Une entité sans version ne signale jamais qu’elle a évolué.
Étape 2 — choisir une licence
Sans licence, personne n’a le droit de réutiliser votre travail. L’application le dit sans détour : « Aucune licence. Sans licence, personne n’a le droit de réutiliser ce contenu. »
Chaque entité a un onglet Licence et un bouton Choisir une licence, qui ouvre un choix de douze licences classées par famille, chacune résumée en une ligne.
| Famille | Ce qu’elle implique | Exemples |
|---|---|---|
| Permissive | Tout est permis, en gardant la mention de copyright. | MIT, Apache 2.0, BSD 3-Clause |
| Copyleft faible | Les fichiers modifiés restent ouverts, le reste se combine librement. | MPL 2.0 |
| Copyleft | Les œuvres dérivées doivent adopter la même licence. | GPL 3.0, AGPL 3.0, EUPL 1.2, CeCILL 2.1 |
| Données et contenus | Pensées pour des jeux de données et des documents plutôt que du code. | CC BY 4.0, CC BY-SA 4.0, ODbL 1.0 |
| Domaine public | Aucune condition. | CC0 1.0 |
Une treizième option, Licence personnalisée, vous laisse rédiger vos propres conditions en markdown — utile pour un usage interne à l’établissement, par exemple.
Quelle famille pour quoi
Pour un schéma, un pipeline ETL ou un plugin — du code —, les licences permissives et copyleft sont les plus adaptées. Pour un catalogue de données ou un jeu de données ouvert, les licences Creative Commons et ODbL sont faites pour cela. EUPL et CeCILL méritent un regard dans un contexte européen ou français, où elles sont juridiquement mieux assises.
Le texte choisi est enregistré tel quel et part dans l’export sous le nom LICENSE.md, que GitLab et GitHub reconnaissent et affichent automatiquement.
Le readme
Chaque entité porte aussi un readme, rédigé en markdown et exporté en README.md. C’est ce qu’un visiteur lit en premier sur le dépôt, et ce que le catalogue affiche.
Dites-y ce qu’un tableau de métadonnées ne peut pas dire : à quoi sert ce travail, sur quelles données il a été construit, ses limites connues, et ce qu’il faut adapter pour le reprendre ailleurs.
Étape 3 — publier dans un dépôt git
Une entrée de catalogue pointe vers un dépôt git : il faut donc que votre travail y soit d’abord.
Depuis le menu de l’entité, Versioning ouvre l’onglet Dépôt Git. Vous y donnez l’URL du dépôt et, s’il est privé, un jeton d’accès. Linkr vérifie le dépôt avant d’enregistrer, détecte la branche, puis Valider et pousser envoie le contenu.
Le dépôt doit être clonable publiquement
L’installation depuis le catalogue ne présente aucun identifiant : chaque instance doit pouvoir cloner le dépôt anonymement. Un dépôt privé produit une entrée que personne ne peut installer.
Linkr ne le vérifie pas à votre place — c’est le point à contrôler vous-même avant de proposer l’entrée. Le catalogue signalera après coup une entrée devenue Inaccessible.
Le jeton d'accès ne part jamais
Il est conservé pour vous, par hôte, et n’apparaît dans aucun export ni dans le dépôt. Voir Versioning git.
Étape 4 — demander l’ajout au catalogue
Le catalogue est un dépôt git qui contient un fichier de description par entité publiée. Y ajouter le vôtre se fait par une demande de fusion — une merge request — sur ce dépôt.
La page Catalogue porte le lien en bas de son en-tête : « Envie de partager votre travail ? Ouvrez une merge request sur… »
Votre fichier décrit l’entrée : son identifiant, son type, l’adresse et la branche du dépôt, son nom et sa description, l’auteur et l’organisation, la licence, la version et des étiquettes. Les entrées existantes servent de modèle.
Pourquoi une relecture plutôt qu'un bouton
Le catalogue est une étagère commune : ce qui y figure est installé en un clic par des équipes qui ne connaissent pas l’auteur. Le passage par une relecture est ce qui permet de vérifier que le dépôt est bien accessible et que l’entrée décrit ce qu’elle prétend.
Un assistant qui préremplirait ce fichier depuis l’entité est envisagé, mais n’existe pas aujourd’hui.
Ce que Linkr garantit, et ce qui reste à votre charge
Garanti par construction
- Aucun mot de passe, jeton, hôte ou nom de base ne part dans un export.
- Les fichiers de données sont exclus, sauf marquage explicite fichier par fichier.
- Une base exportée n’emporte aucune ligne.
- Les résultats d’exécution — effectifs, attrition — ne partent pas.
À vérifier vous-même
- Que le dépôt est bien public et clonable sans identifiants.
- Qu’aucun fichier marqué « à versionner » ne contient de données sensibles.
- Que vos scripts ne contiennent ni identifiants ni chemins internes.
- Que vous avez le droit de publier ce travail, selon les règles de votre établissement.
Une base de données publique se remplit à la main
Publier un jeu de données ouvert — des données synthétiques, une démonstration — suppose d’ajouter les fichiers au dépôt hors de Linkr. L’application n’écrit jamais de lignes dans un export, précisément pour qu’elle ne puisse pas devenir le chemin par lequel des données patient s’échappent.
Publier hors du catalogue
Tout ne mérite pas d’être indexé publiquement. Deux usages courants s’en passent :
- Un dépôt partagé sans entrée de catalogue — vos collègues l’importent par l’onglet Depuis Git, avec un jeton si le dépôt est privé. C’est la voie habituelle pour du contenu interne à un établissement.
- Un catalogue interne — un établissement peut faire pointer ses instances vers son propre index. Voir Catalogue communautaire.
Les plugins portent un réglage « Publication »
La fenêtre de réglages d’un plugin propose Publié ou Non publié. C’est une indication inscrite dans le plugin à destination du catalogue, pas un contrôle d’accès : elle ne restreint rien au sein de votre installation.
Pour aller plus loin
- Catalogue communautaire — ce que vos lecteurs verront.
- Import et export — ce que contient exactement une archive.
- Versioning git — lier un projet à un dépôt et y pousser.
- Entités et partage — l’identité de lignée, et pourquoi elle compte pour une entité publiée.