{"id":1210,"date":"2026-08-21T14:28:51","date_gmt":"2026-08-21T14:28:51","guid":{"rendered":"https:\/\/matforge.org\/?p=1210","raw":"https:\/\/matforge.org\/?p=1210"},"modified":"2026-08-21T14:28:51","modified_gmt":"2026-08-21T14:28:51","slug":"python-data-versioning-and-provenance-dvc-dvc-and-scientific-workflows","status":"publish","type":"post","link":"https:\/\/matforge.org\/fr\/python-data-versioning-and-provenance-dvc-dvc-and-scientific-workflows\/","title":{"rendered":"Versionnement et provenance des donn\u00e9es Python : DVC, DVC et flux de travail scientifiques","raw":"Versionnement et provenance des donn\u00e9es Python : DVC, DVC et flux de travail scientifiques"},"content":{"rendered":"<span class=\"span-reading-time rt-reading-time\" style=\"display: block;\"><span class=\"rt-label rt-prefix\">Reading Time: <\/span> <span class=\"rt-time\"> 21<\/span> <span class=\"rt-label rt-postfix\">minutes<\/span><\/span><h1>Versionnement et provenance des donn\u00e9es Python : DVC, DVC et flux de travail scientifiques<\/h1>\n<p>Le versioning des donn\u00e9es dans la simulation scientifique ne consiste pas \u00e0 suivre les changements de code &#8211; Git g\u00e8re d\u00e9j\u00e0 cela parfaitement. Il s&rsquo;agit de suivre la <strong>combinaison sp\u00e9cifique<\/strong> de fichier de donn\u00e9es, de validation de code et de fichier de param\u00e8tres produit un r\u00e9sultat particulier. Cette distinction est ce qui s\u00e9pare un workflow exp\u00e9rimental fragile d&rsquo;un pipeline de simulation reproductible.<\/p>\n<p>L&rsquo;outil le plus largement adopt\u00e9 pour cela est DVC (Data Version Control), qui \u00e9tend le mod\u00e8le de versionnement de Git pour g\u00e9rer les grands ensembles de donn\u00e9es et les \u00e9tapes de pipeline. Cet article couvre la mise en \u0153uvre pratique de DVC pour les workflows scientifiques \u2014 construction de pipelines avec <code>dvc.yaml<\/code>, isolation des param\u00e8tres avec <code>params.yaml<\/code>, int\u00e9gration HPC\/Slurm et suivi de provenance W3C \u00e9mergent. Chiffre d&rsquo;affaires, migration mat\u00e9rielle et cycles de vie de plusieurs ann\u00e9es.<\/p>\n<h2>Points \u00e0 retenir cl\u00e9s<\/h2>\n<ul>\n<li><strong>Valeur de base de DVC<\/strong>&nbsp;: les fichiers de pipeline (<code>dvc.yaml<\/code>) rendent les simulations sensibles aux d\u00e9pendances, donc <code>dvc repro<\/code> ne r\u00e9ex\u00e9cute que ce qui a chang\u00e9.<\/li>\n<li><strong>Reproductibilit\u00e9 versionnelle<\/strong>&nbsp;: les instantan\u00e9s de donn\u00e9es DVC relient les fichiers (<code>.dvc<\/code>), les validations de code (GIT) et les fichiers de param\u00e8tres (<code>params.yaml<\/code>) dans des unit\u00e9s d&rsquo;exp\u00e9rience reproductibles.<\/li>\n<li><strong>Int\u00e9gration HPC<\/strong>&nbsp;: enveloppes de planification par lots Slurm DVC pour l&rsquo;ex\u00e9cution du pipeline natif de cluster sans intervention manuelle<\/li>\n<li><strong>Normes de provenance<\/strong> : W3C Prov-JSON (YProv4ml) appara\u00eet comme un format interop\u00e9rable compl\u00e9mentaire aux emballages RO-Crate<\/li>\n<li><strong>DVC vs DataLad<\/strong>&nbsp;: choisissez DVC pour les exp\u00e9riences orient\u00e9es pipeline&nbsp;; Choisissez DataLad pour la conservation des donn\u00e9es \u00e0 long terme et les jeux de donn\u00e9es distribu\u00e9s<\/li>\n<\/ul>\n<h2>Pourquoi la version standard \u00e9choue pour les flux de travail de simulation<\/h2>\n<p>Git est excellent pour le suivi des changements de code. C&rsquo;est terrible pour suivre les changements de donn\u00e9es.<\/p>\n<p>Lorsque vous ex\u00e9cutez un calcul de relaxation DFT, Git ne peut pas stocker le fichier de structure cristalline <code>.xyz<\/code> r\u00e9sultant (souvent des dizaines de Mo). Vous pouvez le copier sur un lecteur partag\u00e9, ou ajouter son hachage SHA-256 dans un fichier texte ou compter sur la m\u00e9moire. Les trois approches se cassent lorsque la source de donn\u00e9es change, lorsque vous devez partager avec des collaborateurs qui n&rsquo;ont pas acc\u00e8s au lecteur partag\u00e9 ou lorsque vous revenez six mois plus tard et oubliez quel jeu de param\u00e8tres a produit la structure d&rsquo;\u00e9nergie la plus basse.<\/p>\n<p>Les outils de gestion des donn\u00e9es r\u00e9solvent ce probl\u00e8me en d\u00e9couplant <strong>Suivi des donn\u00e9es<\/strong> de <strong>Suivi de code<\/strong>. Ils stockent des fichiers r\u00e9els dans le stockage \u00e0 distance (Google Drive, S3, un NAS partag\u00e9 ou m\u00eame un autre r\u00e9f\u00e9rentiel Git) et enregistrent des fichiers pointeurs l\u00e9gers dans le r\u00e9f\u00e9rentiel Git. Les fichiers de pointeur &#8211; g\u00e9n\u00e9ralement de petits fichiers <code>.dvc<\/code> ou les r\u00e9f\u00e9rences de liens symboliques Git-annex &#8211; contiennent des m\u00e9tadonn\u00e9es (somme de contr\u00f4le, emplacement distant, balise de version) sans dupliquer les donn\u00e9es r\u00e9elles.<\/p>\n<p>Cette s\u00e9paration est importante pour les flux de travail de simulation, car le volume de donn\u00e9es \u00e9volue ind\u00e9pendamment du volume du code. Une seule campagne de simulation peut produire des milliers de fichiers de trajectoires, tandis que les scripts Python qui les g\u00e9n\u00e8rent restent \u00e0 quelques centaines de lignes.<\/p>\n<h3>L&rsquo;\u00e9cart de pipeline<\/h3>\n<p>La plupart des chercheurs commencent par le suivi ad hoc des donn\u00e9es&nbsp;: un script bash qui ex\u00e9cute les calculs en s\u00e9quence, avec des r\u00e9sultats copi\u00e9s dans un r\u00e9pertoire <code>results\/<\/code> et les nombres finaux coll\u00e9s dans une feuille Google. Cela fonctionne pour de petits projets. Il se d\u00e9compose lorsque&nbsp;:<\/p>\n<ol>\n<li><strong>R\u00e9ex\u00e9cuter avec diff\u00e9rents param\u00e8tres<\/strong> \u2014 Vous devez vous rappeler quel fichier <code>params.yaml<\/code> a \u00e9t\u00e9 utilis\u00e9 et r\u00e9ex\u00e9cuter uniquement les \u00e9tapes modifi\u00e9es<\/li>\n<li><strong>\u00c9checs de d\u00e9bogage<\/strong> : vous devez savoir si l&rsquo;erreur est n\u00e9e de la corruption des donn\u00e9es, des modifications de code ou des incompatibilit\u00e9s de param\u00e8tres.<\/li>\n<li><strong>Team Handoff<\/strong> \u2014 Un nouvel \u00e9tudiant ne peut pas reconstruire le pipeline \u00e0 partir d&rsquo;un script <code>bash<\/code> et d&rsquo;un dossier de fichiers orphelins.<\/li>\n<\/ol>\n<p>Le fichier de d\u00e9finition de pipeline de DVC (<code>dvc.yaml<\/code>) corrige cet \u00e9cart en d\u00e9clarant des \u00e9tapes avec des d\u00e9pendances et des sorties explicites. Chaque \u00e9tape est r\u00e9ex\u00e9cut\u00e9e uniquement lorsque ses d\u00e9pendances changent (<code>dvc repro &lt;stage&gt;<\/code>), rendant les campagnes de simulation consid\u00e9rablement plus efficaces lors de la r\u00e9ex\u00e9cution des calculs avec diff\u00e9rents param\u00e8tres.<\/p>\n<h2>Construction de pipeline DVC pour les flux de travail scientifiques<\/h2>\n<p>Un fichier de pipeline DVC est un document YAML d\u00e9claratif qui mappe la fa\u00e7on dont vos \u00e9tapes de simulation d\u00e9pendent les unes des autres. Voici un exemple concret pour un flux de travail scientifique sur les mat\u00e9riaux informatiques&nbsp;:<\/p>\n<pre><code class=\"language-yaml\"># dvc.yaml \u2014 DFT relaxation and energy calculation pipeline\n\nstages:\n  relax:\n    cmd: python src\/relax.py\n    deps:\n    - data\/raw_crystal_structure.xyz\n    - src\/relax.py\n    params:\n    - params.yaml\n    outs:\n    - results\/relaxed_structure.xyz\n\n  energy:\n    cmd: python src\/energy.py\n    deps:\n    - results\/relaxed_structure.xyz\n    - src\/energy.py\n    params:\n    - params.yaml\n    outs:\n    - results\/energies.txt\n    metrics:\n    - results\/energies.txt\n\n  visualize:\n    cmd: python src\/plot.py\n    deps:\n    - results\/energies.txt\n    - src\/plot.py\n    outs:\n    - figures\/energy_plot.png\n<\/code><\/pre>\n<p>Chaque \u00e9tape d\u00e9clare :<\/p>\n<ul>\n<li><strong><code>cmd<\/code><\/strong>&nbsp;: la commande qui g\u00e9n\u00e8re les sorties de cette \u00e9tape<\/li>\n<li><strong><code>deps<\/code><\/strong>&nbsp;: fichiers qui, s&rsquo;ils sont modifi\u00e9s, d\u00e9clenchent une r\u00e9ex\u00e9cution de cette \u00e9tape<\/li>\n<li><strong><code>params<\/code><\/strong>&nbsp;: fichiers de param\u00e8tres qui, s&rsquo;ils sont modifi\u00e9s, d\u00e9clenchent une r\u00e9ex\u00e9cution de cette \u00e9tape<\/li>\n<li><strong><code>outs<\/code><\/strong>&nbsp;: fichiers produits par cette \u00e9tape (suivi comme versions de donn\u00e9es)<\/li>\n<li><strong><code>metrics<\/code><\/strong>&nbsp;: les fichiers que DVC suit num\u00e9riquement pour la comparaison d&rsquo;exp\u00e9riences<\/li>\n<\/ul>\n<h3>Pourquoi <code>params.yaml<\/code> compte<\/h3>\n<p>Le fichier <code>params.yaml<\/code> isole les param\u00e8tres de simulation des scripts d&rsquo;ex\u00e9cution. Ceci est essentiel pour les workflows de la science des mat\u00e9riaux o\u00f9 le m\u00eame code de simulation s&rsquo;ex\u00e9cute des centaines de fois avec des param\u00e8tres diff\u00e9rents&nbsp;:<\/p>\n<pre><code class=\"language-yaml\"># params.yaml\nsimulator:\n  cutoff_energy: 500  # eV\n  kpoints: [8, 8, 8]\n  tolerance: 1e-6\n  \noptimization:\n  max_steps: 200\n  algorithm: ionic\n<\/code><\/pre>\n<p>Lorsque vous changez <code>tolerance<\/code> de <code>1e-6<\/code> \u00e0 <code>1e-8<\/code> et lancez <code>dvc repro<\/code>, le DVC d\u00e9tecte le <code>params.yaml<\/code> et r\u00e9ex\u00e9cute chaque \u00e9tape qui en d\u00e9pend. Le fichier <code>relaxed_structure.xyz<\/code> r\u00e9sultant obtient une nouvelle balise de version. L&rsquo;ancienne version reste disponible dans le cache &#8211; vous ne perdez pas les ex\u00e9cutions historiques.<\/p>\n<p>Pour les balayages de param\u00e8tres, vous pouvez utiliser <code>--set-param<\/code> pour remplacer les valeurs sans modifier le fichier&nbsp;:<\/p>\n<pre><code class=\"language-bash\">dvc exp run --set-param sim.tolerance=1e-8 --set-param sim.cutoff_energy=450\n<\/code><\/pre>\n<p>Cela cr\u00e9e une nouvelle branche d&rsquo;exp\u00e9rience, conservant \u00e0 la fois les ex\u00e9cutions originales et modifi\u00e9es dans l&rsquo;historique de votre pipeline.<\/p>\n<h2>Reproductibilit\u00e9 versionn\u00e9e \u2014 Contribution conceptuelle de DVC<\/h2>\n<p>Le blog de DVC (d\u00e9cembre 2021) a introduit la \u00ab\u00a0reproductibilit\u00e9 versionnelle\u00a0\u00bb comme la possibilit\u00e9 de recr\u00e9er non seulement un r\u00e9sultat, mais aussi l&rsquo;\u00e9tat exp\u00e9rimental <strong> exact<\/strong> qui l&rsquo;a produit. Cela distingue le DVC du versioning g\u00e9n\u00e9rique&nbsp;:<\/p>\n<ul>\n<li><strong>Versioning standard<\/strong> Suivi des modifications apport\u00e9es aux fichiers au fil du temps (objectif de Git)<\/li>\n<li><strong>Reproductibilit\u00e9 en versions<\/strong> Suivi de la version de donn\u00e9es sp\u00e9cifiques, de la validation du code et de la combinaison de fichiers de param\u00e8tres produit un r\u00e9sultat donn\u00e9 (objectif de DVC)<\/li>\n<\/ul>\n<p>DVC y parvient en reliant trois artefacts \u00e0 version ind\u00e9pendante :<\/p>\n<table>\n<thead>\n<tr>\n<th>Artefact<\/th>\n<th>Syst\u00e8me de gestion des versions<\/th>\n<th>Ce qu&rsquo;il suit<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><code>.dvc<\/code> Fichiers pointeurs<\/td>\n<td>PDV<\/td>\n<td>Version du fichier de donn\u00e9es + emplacement distant + somme de contr\u00f4le<\/td>\n<\/tr>\n<tr>\n<td>git commet<\/td>\n<td>cr\u00e9tin<\/td>\n<td>Version du code + message de validation + diff<\/td>\n<\/tr>\n<tr>\n<td><code>params.yaml<\/code><\/td>\n<td>cr\u00e9tin<\/td>\n<td>Version du fichier de param\u00e8tres + modifications au niveau du champ<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>La combinaison de ces trois cr\u00e9e une unit\u00e9 reproductible &#8211; une \u00ab\u00a0exp\u00e9rience versionnelle\u00a0\u00bb qui peut \u00eatre reconstruite isol\u00e9ment. Cela compte pour la simulation, car les exp\u00e9riences sont affin\u00e9es de mani\u00e8re it\u00e9rative. Les chercheurs ont besoin de savoir \u00ab\u00a0ce qui a fonctionn\u00e9\u00a0\u00bb et de pouvoir le reproduire sans relancer chaque \u00e9tape interm\u00e9diaire.<\/p>\n<h3>Implications pratiques<\/h3>\n<p>Lorsqu&rsquo;un examinateur demande les donn\u00e9es derri\u00e8re un chiffre publi\u00e9, vous pouvez fournir :<\/p>\n<ol>\n<li>Le hachage de commit git (version de code)<\/li>\n<li>La r\u00e9f\u00e9rence de fichier de pointeur <code>.dvc<\/code> (version de donn\u00e9es)<\/li>\n<li>le fichier <code>params.yaml<\/code> \u00e0 ce commit (version du param\u00e8tre)<\/li>\n<\/ol>\n<p>Combin\u00e9s, ces trois artefacts sont suffisants pour reproduire le r\u00e9sultat sur n&rsquo;importe quelle machine. Il s&rsquo;agit de la r\u00e9f\u00e9rence en mati\u00e8re de reproductibilit\u00e9 de simulation &#8211; bien au-del\u00e0 des conteneurs (qui fige les environnements de code) ou des r\u00e9f\u00e9rentiels Git nus (qui ne peuvent pas g\u00e9rer les donn\u00e9es volumineuses).<\/p>\n<h2>Exp\u00e9rimentez la file d&rsquo;attente et la gestion<\/h2>\n<p>La gestion des exp\u00e9riences de DVC (<code>dvc exp<\/code>) \u00e9tend le mod\u00e8le de pipeline pour prendre en charge les exp\u00e9riences simultan\u00e9es et en file d&rsquo;attente&nbsp;:<\/p>\n<pre><code class=\"language-bash\"># Run a single experiment with custom parameters\ndvc exp run -S sim.tolerance=1e-8\n\n# Queue multiple experiments\ndvc exp run --queue -S sim.tolerance=1e-8\ndvc exp run --queue -S sim.tolerance=1e-6\ndvc exp run --queue -S sim.tolerance=1e-5\n\n# Execute queued experiments\ndvc exp run\n<\/code><\/pre>\n<p>L&rsquo;indicateur <code>--queue<\/code> reporte l&rsquo;ex\u00e9cution, vous permettant de pr\u00e9parer plusieurs exp\u00e9riences et de les ex\u00e9cuter par lots de mani\u00e8re s\u00e9quentielle. Ceci est utile pour les exp\u00e9riences de calcul qui durent des heures ou des jours. Vous pouvez mettre en file d&rsquo;attente un balayage des param\u00e8tres du jour au lendemain sans lancer manuellement chaque ex\u00e9cution.<\/p>\n<p>Pour la comparaison d&rsquo;exp\u00e9riences, DVClive fournit le suivi des mesures en temps r\u00e9el&nbsp;:<\/p>\n<pre><code class=\"language-python\"># src\/metrics.py \u2014 DVCLive integration\nfrom dvclive import Live\n\nwith Live() as live:\n    for step in range(n_iterations):\n        result = run_step(step)\n        live.step = step\n        live.log(\"energy\", result[\"total_energy\"])\n        live.log(\"forces\", result[\"max_force\"])\n<\/code><\/pre>\n<p>Cela produit un tableau de bord de comparaison interactif o\u00f9 vous pouvez voir comment l&rsquo;\u00e9nergie et les forces \u00e9voluent \u00e0 travers les balayages de param\u00e8tres.<\/p>\n<h2>Ex\u00e9cution de pipelines DVC sur des clusters HPC<\/h2>\n<p>La plupart des scientifiques informatiques n&rsquo;ex\u00e9cutent pas de pipelines sur des ordinateurs portables. Ils les ex\u00e9cutent sur des clusters avec Slurm, PBS ou LSF. DVC s&rsquo;int\u00e8gre avec Slurm via le wrapper <code>srun<\/code>, permettant l&rsquo;ex\u00e9cution du pipeline natif de cluster&nbsp;:<\/p>\n<pre><code class=\"language-bash\"># Run a single pipeline stage with SLURM resource allocation\nsrun dvc repro -n relax --job slurm-job.sh\n\n# Run all pipeline stages on the cluster\nsrun dvc repro\n<\/code><\/pre>\n<p>L&rsquo;indicateur <code>--job<\/code> indique \u00e0 DVC d&rsquo;ex\u00e9cuter chaque \u00e9tape \u00e0 travers le planificateur de travaux de Slurm, en s&rsquo;occupant automatiquement&nbsp;:<\/p>\n<ul>\n<li>Allocation de ressources sp\u00e9cifiques au cluster (m\u00e9moire, CPU, n\u0153uds GPU)<\/li>\n<li>Ex\u00e9cution en mode batch sans intervention manuelle<\/li>\n<li>Mise en file d&rsquo;attente automatique des travaux pour les \u00e9tapes du pipeline<\/li>\n<li>Int\u00e9gration avec les syst\u00e8mes de fichiers et le stockage sp\u00e9cifiques aux clusters (Lustre, GPFS, BEEGFS)<\/li>\n<\/ul>\n<p>ARXIV 2505.06558v2 (septembre 2025) illustre cette int\u00e9gration pour les flux de travail des mat\u00e9riaux-sciences ex\u00e9cutant des calculs DFT sur les clusters HPC. L&rsquo;avantage principal est que <code>dvc repro<\/code> devient conscient des clusters &#8211; si une \u00e9tape \u00e9choue ou que ses d\u00e9pendances changent, SLURM g\u00e8re l&rsquo;allocation de ressources pour la r\u00e9ex\u00e9cution uniquement des \u00e9tapes n\u00e9cessaires.<\/p>\n<h3>Consid\u00e9rations relatives au stockage des clusters<\/h3>\n<p>Le stockage \u00e0 distance de DVC fonctionne bien avec les syst\u00e8mes de fichiers de cluster. Vous pouvez configurer DVC pour utiliser le syst\u00e8me de fichiers Lustre ou GPFS du cluster en tant que t\u00e9l\u00e9commande DVC&nbsp;:<\/p>\n<pre><code class=\"language-bash\"># Configure a cluster storage remote\ndvc remote modify cluster_storage token_url \"https:\/\/cluster-storage.example.com\"\n<\/code><\/pre>\n<p>Cela \u00e9vite la surcharge de copie des donn\u00e9es vers\/depuis le stockage externe en nuage et maintient le pipeline autonome dans la hi\u00e9rarchie de stockage du cluster.<\/p>\n<h2>Suivi de provenance W3C Prov-JSON<\/h2>\n<p>Alors que DVC suit les \u00e9tapes du pipeline et les versions de donn\u00e9es, il ne produit pas de graphe de provenance actionnable par la machine. Pour cela, vous avez besoin d&rsquo;une norme de provenance &#8211; et le format \u00e9mergent est le W3C Prov-JSON.<\/p>\n<p>YProv4ml (ARXIV juillet 2025) impl\u00e9mente la provenance W3C Prov-JSON avec des modifications de code minimales. Il capture :<\/p>\n<ul>\n<li><strong>Qui<\/strong> a ex\u00e9cut\u00e9 l&rsquo;exp\u00e9rience (identit\u00e9 de l&rsquo;utilisateur)<\/li>\n<li><strong>Quoi<\/strong>&nbsp;Donn\u00e9es et codes ont \u00e9t\u00e9 utilis\u00e9s (Source Provenance)<\/li>\n<li><strong>Comment<\/strong> L&rsquo;exp\u00e9rience s&rsquo;est d\u00e9roul\u00e9e (provenance d&rsquo;ex\u00e9cution)<\/li>\n<li><strong>Pourquoi<\/strong> (motivation facultative, li\u00e9e aux objectifs de recherche)<\/li>\n<\/ul>\n<p>La sortie est un graphe prov-json &#8211; un graphe dirig\u00e9 o\u00f9 les n\u0153uds repr\u00e9sentent les entit\u00e9s (fichiers, param\u00e8tres, commits de code) et les bords repr\u00e9sentent les relations (d\u00e9riv\u00e9es, produites par, utilis\u00e9es). Ce format permet :<\/p>\n<ul>\n<li><strong>Interop\u00e9rabilit\u00e9 entre les syst\u00e8mes de provenance<\/strong>&nbsp;: Prov-JSON est lisible par machine et peut \u00eatre interrog\u00e9e avec des bases de donn\u00e9es SparQL ou Graph.<\/li>\n<li><strong>Conformit\u00e9 des donn\u00e9es \u00e9quitables<\/strong>&nbsp;: les graphiques Prov-JSON satisfont aux principes \u00e9quitables en documentant la lign\u00e9e de donn\u00e9es et les conditions de r\u00e9utilisation<\/li>\n<li><strong>Collaboration interinstitutionnelle<\/strong>&nbsp;: Prov-JSON est une norme W3C, de sorte que les graphiques de provenance de diff\u00e9rentes institutions sont compatibles<\/li>\n<\/ul>\n<h3>Prov-JSON vs RO-Crate<\/h3>\n<p>Il est utile de distinguer Prov-JSON de RO-Crate, puisque les deux apparaissent dans les discussions sur la reproductibilit\u00e9 :<\/p>\n<table>\n<thead>\n<tr>\n<th>aspect<\/th>\n<th>ro-caisse<\/th>\n<th>Prov-json<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>But<\/td>\n<td>Format de package pour les m\u00e9tadonn\u00e9es riches<\/td>\n<td>Format de donn\u00e9es pour les graphiques de provenance<\/td>\n<\/tr>\n<tr>\n<td>Port\u00e9e<\/td>\n<td>Ensemble de donn\u00e9es enti\u00e8res + ressources associ\u00e9es<\/td>\n<td>Ligne d&rsquo;ex\u00e9cution et d\u00e9pendances<\/td>\n<\/tr>\n<tr>\n<td>Format<\/td>\n<td>JSON-LD<\/td>\n<td>JSON (norme PROV)<\/td>\n<\/tr>\n<tr>\n<td>interop\u00e9rabilit\u00e9<\/td>\n<td>Forfait autonome<\/td>\n<td>Bas\u00e9 sur des graphes, interrogeable<\/td>\n<\/tr>\n<tr>\n<td>Relations<\/td>\n<td>Compl\u00e9mentaire, non concurrent<\/td>\n<td><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>Ils abordent diff\u00e9rentes couches de reproductibilit\u00e9. RO-Crate regroupe votre jeu de donn\u00e9es avec des m\u00e9tadonn\u00e9es. Prov-JSON suit la lign\u00e9e de calcul de la fa\u00e7on dont cet ensemble de donn\u00e9es a \u00e9t\u00e9 produit. L&rsquo;utilisation des deux ensemble fournit une reproductibilit\u00e9 compl\u00e8te&nbsp;: \u00ab\u00a0voici les donn\u00e9es\u00a0\u00bb (ro-crate) plus \u00ab\u00a0voici comment elles ont \u00e9t\u00e9 produites\u00a0\u00bb (prov-json).<\/p>\n<h2>Quand utiliser les biblioth\u00e8ques DVC vs DataLad vs Prov<\/h2>\n<p>Le choix entre les biblioth\u00e8ques DVC, DataLad et Prov-Conformes d\u00e9pend de vos mod\u00e8les de flux de travail&nbsp;:<\/p>\n<table>\n<thead>\n<tr>\n<th>Crit\u00e8re<\/th>\n<th>PDV<\/th>\n<th>datalad<\/th>\n<th>Bibliaires Prov<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Cas d&rsquo;utilisation principal<\/td>\n<td>Exp\u00e9riences orient\u00e9es pipeline<\/td>\n<td>Curation \u00e0 long terme des donn\u00e9es<\/td>\n<td>Provenance \u00e0 la machine<\/td>\n<\/tr>\n<tr>\n<td>Taille des donn\u00e9es<\/td>\n<td>Fichiers volumineux (mod\u00e8les, simulations)<\/td>\n<td>Grands ensembles de donn\u00e9es distribu\u00e9es<\/td>\n<td>N\/A (focalis\u00e9 sur les m\u00e9tadonn\u00e9es)<\/td>\n<\/tr>\n<tr>\n<td>Mod\u00e8le d&rsquo;ex\u00e9cution<\/td>\n<td>Pipeline sur sc\u00e8ne (<code>dvc repro<\/code>)<\/td>\n<td>Bas\u00e9 sur la commande (<code>datalad run<\/code>)<\/td>\n<td>\u00e0 base de d\u00e9corateur<\/td>\n<\/tr>\n<tr>\n<td>Int\u00e9gration HPC<\/td>\n<td><code>srun dvc repro<\/code><\/td>\n<td>Native Git-Annex + SSH<\/td>\n<td>configurable<\/td>\n<\/tr>\n<tr>\n<td>Provenance de sortie<\/td>\n<td><code>.dvc<\/code> Fichiers + Historique des Git<\/td>\n<td>Liens symboliques git-annex + journal git<\/td>\n<td>Graphique Prov-JSON<\/td>\n<\/tr>\n<tr>\n<td>le mieux pour<\/td>\n<td>Pipelines de mat\u00e9riaux-sciences, balayages de param\u00e8tres<\/td>\n<td>Curation de r\u00e9f\u00e9rentiel \u00e0 long terme, conformit\u00e9 des offres<\/td>\n<td>Donn\u00e9es \u00e9quitables, provenance interinstitutionnelle<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<h3>DVC est fait pour vous si :<\/h3>\n<ul>\n<li>Votre workflow comporte plusieurs \u00e9tapes d\u00e9pendantes (relaxation \u2192 Calcul des propri\u00e9t\u00e9s \u2192 visualisation)<\/li>\n<li>Vous avez besoin de balayages de param\u00e8tres avec une r\u00e9ex\u00e9cution automatique<\/li>\n<li>Vous souhaitez suivre la combinaison de param\u00e8tres produit le r\u00e9sultat d&rsquo;\u00e9nergie la plus faible<\/li>\n<\/ul>\n<h3>Datalad est fait pour vous si :<\/h3>\n<ul>\n<li>Vous conservez un r\u00e9f\u00e9rentiel de jeux de donn\u00e9es \u00e0 long terme<\/li>\n<li>Vous avez besoin de liens symboliques Git-Annex pour une gestion efficace des fichiers volumineux<\/li>\n<li>Vous travaillez avec des ensembles de donn\u00e9es distribu\u00e9s entre les institutions<\/li>\n<li>Vous avez besoin de la conformit\u00e9 des soumissions (commune en neuroimagerie)<\/li>\n<\/ul>\n<h3>Les biblioth\u00e8ques conformes \u00e0 Prov vous conviennent si :<\/h3>\n<ul>\n<li>Vous avez besoin d&rsquo;une provenance \u00e0 la machine pour une conformit\u00e9 \u00e9quitable<\/li>\n<li>Vous voulez un graphe de provenance interrogeable pour la lign\u00e9e de donn\u00e9es<\/li>\n<li>Vous collaborez entre des institutions avec diff\u00e9rents syst\u00e8mes de provenance<\/li>\n<li>Vous publiez dans un r\u00e9f\u00e9rentiel de donn\u00e9es \u00e9quitable<\/li>\n<\/ul>\n<h2>Mettre en place \u2014 un flux de travail pratique<\/h2>\n<p>Voici un mod\u00e8le de flux de travail pratique qui combine tous les concepts ci-dessus&nbsp;:<\/p>\n<pre><code class=\"language-bash\"># 1. Initialize the repository\ngit init\ndvc init\n\n# 2. Add the data\ndvc add data\/raw_crystal_structure.xyz\n\n# 3. Run the pipeline\ndvc repro\n\n# 4. Check the results\ndvc metrics show results\/energies.txt\n\n# 5. Run experiments with different parameters\ndvc exp run -S sim.tolerance=1e-8 --set-param sim.cutoff_energy=550\n\n# 6. Push data and experiments to remote\ndvc push\ndvc exp push\ngit push origin main\n\n# 7. (Optional) Generate PROV-JSON provenance\npython src\/provenance.py --output provenance.json\n<\/code><\/pre>\n<p>Ce mod\u00e8le garantit que chaque r\u00e9sultat de simulation peut \u00eatre retrac\u00e9 vers sa version exacte des donn\u00e9es, sa validation de code et son fichier de param\u00e8tres. La sortie Prov-JSON (\u00e9tape 7) ajoute une couche de provenance actionnable par la machine au-dessus du pipeline DVC.<\/p>\n<h2>Erreurs courantes &#8211; ce qu&rsquo;il faut \u00e9viter<\/h2>\n<p><strong>Erreur&nbsp;1&nbsp;: version de tout <\/strong> \u2014 Ne pas ex\u00e9cuter <code>dvc add<\/code> sur chaque fichier de sortie. Ne suivez que les fichiers qui sont des entr\u00e9es dans les \u00e9tapes suivantes ou qui repr\u00e9sentent les r\u00e9sultats finaux. Les fichiers interm\u00e9diaires (comme les tableaux de force brutes) doivent rester dans Git ou \u00eatre enti\u00e8rement exclus. L&rsquo;ajout excessif cr\u00e9e du bruit de pipeline.<\/p>\n<p><strong>Erreur&nbsp;2&nbsp;: chemins de codage en dur<\/strong> \u2014 N&rsquo;utilisez pas de chemins absolus dans <code>dvc.yaml<\/code>. Utilisez des chemins relatifs afin que le pipeline fonctionne sur diff\u00e9rentes configurations de machines et de clusters.<\/p>\n<p><strong>Erreur&nbsp;3&nbsp;: M\u00e9langer les types de donn\u00e9es<\/strong> \u2014 Ne placez pas les param\u00e8tres de simulation et les points de contr\u00f4le du mod\u00e8le dans le m\u00eame fichier <code>.dvc<\/code>. Gardez les types de donn\u00e9es s\u00e9par\u00e9s pour \u00e9viter les conflits de cache.<\/p>\n<p><strong>Erreur&nbsp;4&nbsp;: ignorer la provenance<\/strong> \u2014 Les fichiers DVC seuls ne sont pas suffisants pour une conformit\u00e9 \u00e9quitable. Si votre \u00e9tablissement a besoin de graphiques de provenance, associez DVC \u00e0 une sortie Prov-JSON (YProv4ml) ou \u00e0 un emballage RO-crate.<\/p>\n<p><strong>Erreur&nbsp;5&nbsp;: Oublier <code>params.yaml<\/code><\/strong> \u2014 Si vous codez en dur les param\u00e8tres de vos scripts au lieu de les isoler dans <code>params.yaml<\/code>, le suivi des param\u00e8tres de DVC devient inutile. Utilisez toujours <code>params.yaml<\/code> pour les param\u00e8tres de simulation.<\/p>\n<h2>R\u00e9sum\u00e9<\/h2>\n<p>DVC transforme les flux de travail scientifiques \u00e0 partir de processus fragiles et d\u00e9pendant de la m\u00e9moire en pipelines d\u00e9terministes et sensibles aux d\u00e9pendances. L&rsquo;id\u00e9e cl\u00e9 est que <code>dvc.yaml<\/code> les fichiers de pipeline et <code>params.yaml<\/code> l&rsquo;isolation des param\u00e8tres cr\u00e9ent une \u00ab\u00a0reproductibilit\u00e9 versionnelle\u00a0\u00bb &#8211; la possibilit\u00e9 de reconstruire non seulement un r\u00e9sultat, mais aussi l&rsquo;\u00e9tat exp\u00e9rimental exact (data version + code commit + fichier de param\u00e8tre) qui l&rsquo;a produit. Cela va au-del\u00e0 des conteneurs (qui gelent les environnements de code) et au-del\u00e0 de Git (qui ne peuvent pas g\u00e9rer les grands ensembles de donn\u00e9es).<\/p>\n<p>Pour l&rsquo;int\u00e9gration de HPC, le wrapper de Slurm <code>srun<\/code> permet l&rsquo;ex\u00e9cution du pipeline natif du cluster sans intervention manuelle. Pour la provenance, le W3C PROV-JSON (YProv4ml) appara\u00eet comme un format interop\u00e9rable compl\u00e9mentaire \u00e0 l&#8217;emballage RO-crate, permettant une lign\u00e9e de donn\u00e9es actionnable qui r\u00e9pond aux exigences de conformit\u00e9 \u00e9quitables.<\/p>\n<p>Le choix entre les biblioth\u00e8ques DVC, DataLad et Prov-Conformes d\u00e9pend de vos mod\u00e8les de flux de travail&nbsp;: DVC pour les exp\u00e9riences orient\u00e9es pipeline, DataLad pour la conservation des donn\u00e9es \u00e0 long terme et les biblioth\u00e8ques Prov pour les graphes de provenance actionnables par la machine. La plupart des \u00e9quipes de simulation b\u00e9n\u00e9ficient de l&rsquo;utilisation de DVC pour l&rsquo;ex\u00e9cution du pipeline et de Prov-JSON pour le suivi de la provenance &#8211; les deux outils sont compl\u00e9mentaires et non concurrents.<\/p>\n<hr>\n<h2>Guides connexes<\/h2>\n<ul>\n<li><a href=\"\/reproducibility-workflows-beyond-containers-data-versioning-and-provenance-tracking\/\">Reproductibilit\u00e9 au-del\u00e0 des conteneurs<\/a> \u2014 Couvre les bases DVC, les emballages de provenance de la caisse RO et les mod\u00e8les de reproductibilit\u00e9 \u00e0 base de conteneurs<\/li>\n<li><a href=\"https:\/\/matforge.org\/managing-large-scale-pde-problems-strategies-solvers-and-hpc-case-studies\/\">Gestion des probl\u00e8mes de PDE \u00e0 grande \u00e9chelle<\/a> &#8211; Discute de la gestion des ressources de cluster et du HPC flux de travail<\/li>\n<li><a href=\"https:\/\/matforge.org\/verification-vs-validation-in-scientific-simulations-a-practical-guide\/\">V\u00e9rification vs validation dans les simulations scientifiques<\/a> &#8211; explique le contexte de reproductibilit\u00e9 plus large pour la simulation r\u00e9sultats&lt;\/fs_write_file&gt;<br \/> &lt;\/tool_call&gt;&nbsp;;<\/li>\n<\/ul>\n<p>&lt;tool_call&gt;<br \/> &lt;function=fs_write_file&gt;<br \/> &lt;parameter=content&gt;<\/p>\n<h1>Versionnement et provenance des donn\u00e9es Python : DVC, DVC et flux de travail scientifiques<\/h1>\n<p>Le versioning des donn\u00e9es dans la simulation scientifique ne consiste pas \u00e0 suivre les changements de code &#8211; Git g\u00e8re d\u00e9j\u00e0 cela parfaitement. Il s&rsquo;agit de suivre la <strong>combinaison sp\u00e9cifique<\/strong> de fichier de donn\u00e9es, de validation de code et de fichier de param\u00e8tres produit un r\u00e9sultat particulier. Cette distinction est ce qui s\u00e9pare un workflow exp\u00e9rimental fragile d&rsquo;un pipeline de simulation reproductible.<\/p>\n<p>L&rsquo;outil le plus largement adopt\u00e9 pour cela est DVC (Data Version Control), qui \u00e9tend le mod\u00e8le de versionnement de Git pour g\u00e9rer les grands ensembles de donn\u00e9es et les \u00e9tapes de pipeline. Cet article couvre la mise en \u0153uvre pratique de DVC pour les workflows scientifiques \u2014 construction de pipelines avec <code>dvc.yaml<\/code>, isolation des param\u00e8tres avec <code>params.yaml<\/code>, int\u00e9gration HPC\/Slurm et suivi de provenance W3C \u00e9mergent. Chiffre d&rsquo;affaires, migration mat\u00e9rielle et cycles de vie de plusieurs ann\u00e9es.<\/p>\n<h2>Points \u00e0 retenir cl\u00e9s<\/h2>\n<ul>\n<li><strong>Valeur de base de DVC<\/strong>&nbsp;: les fichiers de pipeline (<code>dvc.yaml<\/code>) rendent les simulations sensibles aux d\u00e9pendances, donc <code>dvc repro<\/code> ne r\u00e9ex\u00e9cute que ce qui a chang\u00e9.<\/li>\n<li><strong>Reproductibilit\u00e9 versionnelle<\/strong>&nbsp;: les instantan\u00e9s de donn\u00e9es DVC relient les fichiers (<code>.dvc<\/code>), les validations de code (GIT) et les fichiers de param\u00e8tres (<code>params.yaml<\/code>) dans des unit\u00e9s d&rsquo;exp\u00e9rience reproductibles.<\/li>\n<li><strong>Int\u00e9gration HPC<\/strong>&nbsp;: enveloppes de planification par lots Slurm DVC pour l&rsquo;ex\u00e9cution du pipeline natif de cluster sans intervention manuelle<\/li>\n<li><strong>Normes de provenance<\/strong> : W3C Prov-JSON (YProv4ml) appara\u00eet comme un format interop\u00e9rable compl\u00e9mentaire aux emballages RO-Crate<\/li>\n<li><strong>DVC vs DataLad<\/strong>&nbsp;: choisissez DVC pour les exp\u00e9riences orient\u00e9es pipeline&nbsp;; Choisissez DataLad pour la conservation des donn\u00e9es \u00e0 long terme et les jeux de donn\u00e9es distribu\u00e9s<\/li>\n<\/ul>\n<h2>Pourquoi la version standard \u00e9choue pour les flux de travail de simulation<\/h2>\n<p>Git est excellent pour le suivi des changements de code. C&rsquo;est terrible pour suivre les changements de donn\u00e9es.<\/p>\n<p>Lorsque vous ex\u00e9cutez un calcul de relaxation DFT, Git ne peut pas stocker le fichier de structure cristalline <code>.xyz<\/code> r\u00e9sultant (souvent des dizaines de Mo). Vous pouvez le copier sur un lecteur partag\u00e9, ou ajouter son hachage SHA-256 dans un fichier texte ou compter sur la m\u00e9moire. Les trois approches se cassent lorsque la source de donn\u00e9es change, lorsque vous devez partager avec des collaborateurs qui n&rsquo;ont pas acc\u00e8s au lecteur partag\u00e9 ou lorsque vous revenez six mois plus tard et oubliez quel jeu de param\u00e8tres a produit la structure d&rsquo;\u00e9nergie la plus basse.<\/p>\n<p>Les outils de gestion des donn\u00e9es r\u00e9solvent ce probl\u00e8me en d\u00e9couplant <strong>Suivi des donn\u00e9es<\/strong> de <strong>Suivi de code<\/strong>. Ils stockent des fichiers r\u00e9els dans le stockage \u00e0 distance (Google Drive, S3, un NAS partag\u00e9 ou m\u00eame un autre r\u00e9f\u00e9rentiel Git) et enregistrent des fichiers pointeurs l\u00e9gers dans le r\u00e9f\u00e9rentiel Git. Les fichiers de pointeur &#8211; g\u00e9n\u00e9ralement de petits fichiers <code>.dvc<\/code> ou les r\u00e9f\u00e9rences de liens symboliques Git-annex &#8211; contiennent des m\u00e9tadonn\u00e9es (somme de contr\u00f4le, emplacement distant, balise de version) sans dupliquer les donn\u00e9es r\u00e9elles.<\/p>\n<p>Cette s\u00e9paration est importante pour les flux de travail de simulation, car le volume de donn\u00e9es \u00e9volue ind\u00e9pendamment du volume du code. Une seule campagne de simulation peut produire des milliers de fichiers de trajectoires, tandis que les scripts Python qui les g\u00e9n\u00e8rent restent \u00e0 quelques centaines de lignes.<\/p>\n<h3>L&rsquo;\u00e9cart de pipeline<\/h3>\n<p>La plupart des chercheurs commencent par le suivi ad hoc des donn\u00e9es&nbsp;: un script bash qui ex\u00e9cute les calculs en s\u00e9quence, avec des r\u00e9sultats copi\u00e9s dans un r\u00e9pertoire <code>results\/<\/code> et les nombres finaux coll\u00e9s dans une feuille Google. Cela fonctionne pour de petits projets. Il se d\u00e9compose lorsque&nbsp;:<\/p>\n<ol>\n<li><strong>R\u00e9ex\u00e9cuter avec diff\u00e9rents param\u00e8tres<\/strong> \u2014 Vous devez vous rappeler quel fichier <code>params.yaml<\/code> a \u00e9t\u00e9 utilis\u00e9 et r\u00e9ex\u00e9cuter uniquement les \u00e9tapes modifi\u00e9es<\/li>\n<li><strong>\u00c9checs de d\u00e9bogage<\/strong> : vous devez savoir si l&rsquo;erreur est n\u00e9e de la corruption des donn\u00e9es, des modifications de code ou des incompatibilit\u00e9s de param\u00e8tres.<\/li>\n<li><strong>Team Handoff<\/strong> \u2014 Un nouvel \u00e9tudiant ne peut pas reconstruire le pipeline \u00e0 partir d&rsquo;un script <code>bash<\/code> et d&rsquo;un dossier de fichiers orphelins.<\/li>\n<\/ol>\n<p>Le fichier de d\u00e9finition de pipeline de DVC (<code>dvc.yaml<\/code>) corrige cet \u00e9cart en d\u00e9clarant des \u00e9tapes avec des d\u00e9pendances et des sorties explicites. Chaque \u00e9tape est r\u00e9ex\u00e9cut\u00e9e uniquement lorsque ses d\u00e9pendances changent (<code>dvc repro &lt;stage&gt;<\/code>), rendant les campagnes de simulation consid\u00e9rablement plus efficaces lors de la r\u00e9ex\u00e9cution des calculs avec diff\u00e9rents param\u00e8tres.<\/p>\n<h2>Construction de pipeline DVC pour les flux de travail scientifiques<\/h2>\n<p>Un fichier de pipeline DVC est un document YAML d\u00e9claratif qui mappe la fa\u00e7on dont vos \u00e9tapes de simulation d\u00e9pendent les unes des autres. Voici un exemple concret pour un flux de travail scientifique sur les mat\u00e9riaux informatiques&nbsp;:<\/p>\n<pre><code class=\"language-yaml\"># dvc.yaml \u2014 DFT relaxation and energy calculation pipeline\n\nstages:\n  relax:\n    cmd: python src\/relax.py\n    deps:\n    - data\/raw_crystal_structure.xyz\n    - src\/relax.py\n    params:\n    - params.yaml\n    outs:\n    - results\/relaxed_structure.xyz\n\n  energy:\n    cmd: python src\/energy.py\n    deps:\n    - results\/relaxed_structure.xyz\n    - src\/energy.py\n    params:\n    - params.yaml\n    outs:\n    - results\/energies.txt\n    metrics:\n    - results\/energies.txt\n\n  visualize:\n    cmd: python src\/plot.py\n    deps:\n    - results\/energies.txt\n    - src\/plot.py\n    outs:\n    - figures\/energy_plot.png\n<\/code><\/pre>\n<p>Chaque \u00e9tape d\u00e9clare :<\/p>\n<ul>\n<li><strong><code>cmd<\/code><\/strong>&nbsp;: la commande qui g\u00e9n\u00e8re les sorties de cette \u00e9tape<\/li>\n<li><strong><code>deps<\/code><\/strong>&nbsp;: fichiers qui, s&rsquo;ils sont modifi\u00e9s, d\u00e9clenchent une r\u00e9ex\u00e9cution de cette \u00e9tape<\/li>\n<li><strong><code>params<\/code><\/strong>&nbsp;: fichiers de param\u00e8tres qui, s&rsquo;ils sont modifi\u00e9s, d\u00e9clenchent une r\u00e9ex\u00e9cution de cette \u00e9tape<\/li>\n<li><strong><code>outs<\/code><\/strong>&nbsp;: fichiers produits par cette \u00e9tape (suivi comme versions de donn\u00e9es)<\/li>\n<li><strong><code>metrics<\/code><\/strong>&nbsp;: les fichiers que DVC suit num\u00e9riquement pour la comparaison d&rsquo;exp\u00e9riences<\/li>\n<\/ul>\n<h3>Pourquoi <code>params.yaml<\/code> compte<\/h3>\n<p>Le fichier <code>params.yaml<\/code> isole les param\u00e8tres de simulation des scripts d&rsquo;ex\u00e9cution. Ceci est essentiel pour les workflows de la science des mat\u00e9riaux o\u00f9 le m\u00eame code de simulation s&rsquo;ex\u00e9cute des centaines de fois avec des param\u00e8tres diff\u00e9rents&nbsp;:<\/p>\n<pre><code class=\"language-yaml\"># params.yaml\nsimulator:\n  cutoff_energy: 500  # eV\n  kpoints: [8, 8, 8]\n  tolerance: 1e-6\n  \noptimization:\n  max_steps: 200\n  algorithm: ionic\n<\/code><\/pre>\n<p>Lorsque vous changez <code>tolerance<\/code> de <code>1e-6<\/code> \u00e0 <code>1e-8<\/code> et lancez <code>dvc repro<\/code>, le DVC d\u00e9tecte le <code>params.yaml<\/code> et r\u00e9ex\u00e9cute chaque \u00e9tape qui en d\u00e9pend. Le fichier <code>relaxed_structure.xyz<\/code> r\u00e9sultant obtient une nouvelle balise de version. L&rsquo;ancienne version reste disponible dans le cache &#8211; vous ne perdez pas les ex\u00e9cutions historiques.<\/p>\n<p>Pour les balayages de param\u00e8tres, vous pouvez utiliser <code>--set-param<\/code> pour remplacer les valeurs sans modifier le fichier&nbsp;:<\/p>\n<pre><code class=\"language-bash\">dvc exp run --set-param sim.tolerance=1e-8 --set-param sim.cutoff_energy=450\n<\/code><\/pre>\n<p>Cela cr\u00e9e une nouvelle branche d&rsquo;exp\u00e9rience, conservant \u00e0 la fois les ex\u00e9cutions originales et modifi\u00e9es dans l&rsquo;historique de votre pipeline.<\/p>\n<h2>Reproductibilit\u00e9 versionn\u00e9e \u2014 Contribution conceptuelle de DVC<\/h2>\n<p>Le blog de DVC (d\u00e9cembre 2021) a introduit la \u00ab\u00a0reproductibilit\u00e9 versionnelle\u00a0\u00bb comme la possibilit\u00e9 de recr\u00e9er non seulement un r\u00e9sultat, mais aussi l&rsquo;\u00e9tat exp\u00e9rimental <strong> exact<\/strong> qui l&rsquo;a produit. Cela distingue le DVC du versioning g\u00e9n\u00e9rique&nbsp;:<\/p>\n<ul>\n<li><strong>Versioning standard<\/strong> Suivi des modifications apport\u00e9es aux fichiers au fil du temps (objectif de Git)<\/li>\n<li><strong>Reproductibilit\u00e9 en versions<\/strong> Suivi de la version de donn\u00e9es sp\u00e9cifiques, de la validation du code et de la combinaison de fichiers de param\u00e8tres produit un r\u00e9sultat donn\u00e9 (objectif de DVC)<\/li>\n<\/ul>\n<p>DVC y parvient en reliant trois artefacts \u00e0 version ind\u00e9pendante :<\/p>\n<table>\n<thead>\n<tr>\n<th>Artefact<\/th>\n<th>Syst\u00e8me de gestion des versions<\/th>\n<th>Ce qu&rsquo;il suit<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><code>.dvc<\/code> Fichiers pointeurs<\/td>\n<td>PDV<\/td>\n<td>Version du fichier de donn\u00e9es + emplacement distant + somme de contr\u00f4le<\/td>\n<\/tr>\n<tr>\n<td>git commet<\/td>\n<td>cr\u00e9tin<\/td>\n<td>Version du code + message de validation + diff<\/td>\n<\/tr>\n<tr>\n<td><code>params.yaml<\/code><\/td>\n<td>cr\u00e9tin<\/td>\n<td>Version du fichier de param\u00e8tres + modifications au niveau du champ<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>La combinaison de ces trois cr\u00e9e une unit\u00e9 reproductible &#8211; une \u00ab\u00a0exp\u00e9rience versionnelle\u00a0\u00bb qui peut \u00eatre reconstruite isol\u00e9ment. Cela compte pour la simulation, car les exp\u00e9riences sont affin\u00e9es de mani\u00e8re it\u00e9rative. Les chercheurs ont besoin de savoir \u00ab\u00a0ce qui a fonctionn\u00e9\u00a0\u00bb et de pouvoir le reproduire sans relancer chaque \u00e9tape interm\u00e9diaire.<\/p>\n<h3>Implications pratiques<\/h3>\n<p>Lorsqu&rsquo;un examinateur demande les donn\u00e9es derri\u00e8re un chiffre publi\u00e9, vous pouvez fournir :<\/p>\n<ol>\n<li>Le hachage de commit git (version de code)<\/li>\n<li>La r\u00e9f\u00e9rence de fichier de pointeur <code>.dvc<\/code> (version de donn\u00e9es)<\/li>\n<li>le fichier <code>params.yaml<\/code> \u00e0 ce commit (version du param\u00e8tre)<\/li>\n<\/ol>\n<p>Combin\u00e9s, ces trois artefacts sont suffisants pour reproduire le r\u00e9sultat sur n&rsquo;importe quelle machine. Il s&rsquo;agit de la r\u00e9f\u00e9rence en mati\u00e8re de reproductibilit\u00e9 de simulation &#8211; bien au-del\u00e0 des conteneurs (qui fige les environnements de code) ou des r\u00e9f\u00e9rentiels Git nus (qui ne peuvent pas g\u00e9rer les donn\u00e9es volumineuses).<\/p>\n<h2>Exp\u00e9rimentez la file d&rsquo;attente et la gestion<\/h2>\n<p>La gestion des exp\u00e9riences de DVC (<code>dvc exp<\/code>) \u00e9tend le mod\u00e8le de pipeline pour prendre en charge les exp\u00e9riences simultan\u00e9es et en file d&rsquo;attente&nbsp;:<\/p>\n<pre><code class=\"language-bash\"># Run a single experiment with custom parameters\ndvc exp run -S sim.tolerance=1e-8\n\n# Queue multiple experiments\ndvc exp run --queue -S sim.tolerance=1e-8\ndvc exp run --queue -S sim.tolerance=1e-6\ndvc exp run --queue -S sim.tolerance=1e-5\n\n# Execute queued experiments\ndvc exp run\n<\/code><\/pre>\n<p>L&rsquo;indicateur <code>--queue<\/code> reporte l&rsquo;ex\u00e9cution, vous permettant de pr\u00e9parer plusieurs exp\u00e9riences et de les ex\u00e9cuter par lots de mani\u00e8re s\u00e9quentielle. Ceci est utile pour les exp\u00e9riences de calcul qui durent des heures ou des jours. Vous pouvez mettre en file d&rsquo;attente un balayage des param\u00e8tres du jour au lendemain sans lancer manuellement chaque ex\u00e9cution.<\/p>\n<p>Pour la comparaison d&rsquo;exp\u00e9riences, DVClive fournit le suivi des mesures en temps r\u00e9el&nbsp;:<\/p>\n<pre><code class=\"language-python\"># src\/metrics.py \u2014 DVCLive integration\nfrom dvclive import Live\n\nwith Live() as live:\n    for step in range(n_iterations):\n        result = run_step(step)\n        live.step = step\n        live.log(\"energy\", result[\"total_energy\"])\n        live.log(\"forces\", result[\"max_force\"])\n<\/code><\/pre>\n<p>Cela produit un tableau de bord de comparaison interactif o\u00f9 vous pouvez voir comment l&rsquo;\u00e9nergie et les forces \u00e9voluent \u00e0 travers les balayages de param\u00e8tres.<\/p>\n<h2>Ex\u00e9cution de pipelines DVC sur des clusters HPC<\/h2>\n<p>La plupart des scientifiques informatiques n&rsquo;ex\u00e9cutent pas de pipelines sur des ordinateurs portables. Ils les ex\u00e9cutent sur des clusters avec Slurm, PBS ou LSF. DVC s&rsquo;int\u00e8gre avec Slurm via le wrapper <code>srun<\/code>, permettant l&rsquo;ex\u00e9cution du pipeline natif de cluster&nbsp;:<\/p>\n<pre><code class=\"language-bash\"># Run a single pipeline stage with SLURM resource allocation\nsrun dvc repro -n relax --job slurm-job.sh\n\n# Run all pipeline stages on the cluster\nsrun dvc repro\n<\/code><\/pre>\n<p>L&rsquo;indicateur <code>--job<\/code> indique \u00e0 DVC d&rsquo;ex\u00e9cuter chaque \u00e9tape \u00e0 travers le planificateur de travaux de Slurm, en s&rsquo;occupant automatiquement&nbsp;:<\/p>\n<ul>\n<li>Allocation de ressources sp\u00e9cifiques au cluster (m\u00e9moire, CPU, n\u0153uds GPU)<\/li>\n<li>Ex\u00e9cution en mode batch sans intervention manuelle<\/li>\n<li>Mise en file d&rsquo;attente automatique des travaux pour les \u00e9tapes du pipeline<\/li>\n<li>Int\u00e9gration avec les syst\u00e8mes de fichiers et le stockage sp\u00e9cifiques aux clusters (Lustre, GPFS, BEEGFS)<\/li>\n<\/ul>\n<p>ARXIV 2505.06558v2 (septembre 2025) illustre cette int\u00e9gration pour les flux de travail des mat\u00e9riaux-sciences ex\u00e9cutant des calculs DFT sur les clusters HPC. L&rsquo;avantage principal est que <code>dvc repro<\/code> devient conscient des clusters &#8211; si une \u00e9tape \u00e9choue ou que ses d\u00e9pendances changent, SLURM g\u00e8re l&rsquo;allocation de ressources pour la r\u00e9ex\u00e9cution uniquement des \u00e9tapes n\u00e9cessaires.<\/p>\n<h3>Consid\u00e9rations relatives au stockage des clusters<\/h3>\n<p>Le stockage \u00e0 distance de DVC fonctionne bien avec les syst\u00e8mes de fichiers de cluster. Vous pouvez configurer DVC pour utiliser le syst\u00e8me de fichiers Lustre ou GPFS du cluster en tant que t\u00e9l\u00e9commande DVC&nbsp;:<\/p>\n<pre><code class=\"language-bash\"># Configure a cluster storage remote\ndvc remote modify cluster_storage token_url \"https:\/\/cluster-storage.example.com\"\n<\/code><\/pre>\n<p>Cela \u00e9vite la surcharge de copie des donn\u00e9es vers\/depuis le stockage externe en nuage et maintient le pipeline autonome dans la hi\u00e9rarchie de stockage du cluster.<\/p>\n<h2>Suivi de provenance W3C Prov-JSON<\/h2>\n<p>Alors que DVC suit les \u00e9tapes du pipeline et les versions de donn\u00e9es, il ne produit pas de graphe de provenance actionnable par la machine. Pour cela, vous avez besoin d&rsquo;une norme de provenance &#8211; et le format \u00e9mergent est le W3C Prov-JSON.<\/p>\n<p>YProv4ml (ARXIV juillet 2025) impl\u00e9mente la provenance W3C Prov-JSON avec des modifications de code minimales. Il capture :<\/p>\n<ul>\n<li><strong>Qui<\/strong> a ex\u00e9cut\u00e9 l&rsquo;exp\u00e9rience (identit\u00e9 de l&rsquo;utilisateur)<\/li>\n<li><strong>Quoi<\/strong>&nbsp;Donn\u00e9es et codes ont \u00e9t\u00e9 utilis\u00e9s (Source Provenance)<\/li>\n<li><strong>Comment<\/strong> L&rsquo;exp\u00e9rience s&rsquo;est d\u00e9roul\u00e9e (provenance d&rsquo;ex\u00e9cution)<\/li>\n<li><strong>Pourquoi<\/strong> (motivation facultative, li\u00e9e aux objectifs de recherche)<\/li>\n<\/ul>\n<p>La sortie est un graphe prov-json &#8211; un graphe dirig\u00e9 o\u00f9 les n\u0153uds repr\u00e9sentent les entit\u00e9s (fichiers, param\u00e8tres, commits de code) et les bords repr\u00e9sentent les relations (d\u00e9riv\u00e9es, produites par, utilis\u00e9es). Ce format permet :<\/p>\n<ul>\n<li><strong>Interop\u00e9rabilit\u00e9 entre les syst\u00e8mes de provenance<\/strong>&nbsp;: Prov-JSON est lisible par machine et peut \u00eatre interrog\u00e9e avec des bases de donn\u00e9es SparQL ou Graph.<\/li>\n<li><strong>Conformit\u00e9 des donn\u00e9es \u00e9quitables<\/strong>&nbsp;: les graphiques Prov-JSON satisfont aux principes \u00e9quitables en documentant la lign\u00e9e de donn\u00e9es et les conditions de r\u00e9utilisation<\/li>\n<li><strong>Collaboration interinstitutionnelle<\/strong>&nbsp;: Prov-JSON est une norme W3C, de sorte que les graphiques de provenance de diff\u00e9rentes institutions sont compatibles<\/li>\n<\/ul>\n<h3>Prov-JSON vs RO-Crate<\/h3>\n<p>Il est utile de distinguer Prov-JSON de RO-Crate, puisque les deux apparaissent dans les discussions sur la reproductibilit\u00e9 :<\/p>\n<table>\n<thead>\n<tr>\n<th>aspect<\/th>\n<th>ro-caisse<\/th>\n<th>Prov-json<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>But<\/td>\n<td>Format de package pour les m\u00e9tadonn\u00e9es riches<\/td>\n<td>Format de donn\u00e9es pour les graphiques de provenance<\/td>\n<\/tr>\n<tr>\n<td>Port\u00e9e<\/td>\n<td>Ensemble de donn\u00e9es enti\u00e8res + ressources associ\u00e9es<\/td>\n<td>Ligne d&rsquo;ex\u00e9cution et d\u00e9pendances<\/td>\n<\/tr>\n<tr>\n<td>Format<\/td>\n<td>JSON-LD<\/td>\n<td>JSON (norme PROV)<\/td>\n<\/tr>\n<tr>\n<td>interop\u00e9rabilit\u00e9<\/td>\n<td>Forfait autonome<\/td>\n<td>Bas\u00e9 sur des graphes, interrogeable<\/td>\n<\/tr>\n<tr>\n<td>Relations<\/td>\n<td>Compl\u00e9mentaire, non concurrent<\/td>\n<td><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>Ils abordent diff\u00e9rentes couches de reproductibilit\u00e9. RO-Crate regroupe votre jeu de donn\u00e9es avec des m\u00e9tadonn\u00e9es. Prov-JSON suit la lign\u00e9e de calcul de la fa\u00e7on dont cet ensemble de donn\u00e9es a \u00e9t\u00e9 produit. L&rsquo;utilisation des deux ensemble fournit une reproductibilit\u00e9 compl\u00e8te&nbsp;: \u00ab\u00a0voici les donn\u00e9es\u00a0\u00bb (ro-crate) plus \u00ab\u00a0voici comment elles ont \u00e9t\u00e9 produites\u00a0\u00bb (prov-json).<\/p>\n<h2>Quand utiliser les biblioth\u00e8ques DVC vs DataLad vs Prov<\/h2>\n<p>Le choix entre les biblioth\u00e8ques DVC, DataLad et Prov-Conformes d\u00e9pend de vos mod\u00e8les de flux de travail&nbsp;:<\/p>\n<table>\n<thead>\n<tr>\n<th>Crit\u00e8re<\/th>\n<th>PDV<\/th>\n<th>datalad<\/th>\n<th>Bibliaires Prov<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Cas d&rsquo;utilisation principal<\/td>\n<td>Exp\u00e9riences orient\u00e9es pipeline<\/td>\n<td>Curation \u00e0 long terme des donn\u00e9es<\/td>\n<td>Provenance \u00e0 la machine<\/td>\n<\/tr>\n<tr>\n<td>Taille des donn\u00e9es<\/td>\n<td>Fichiers volumineux (mod\u00e8les, simulations)<\/td>\n<td>Grands ensembles de donn\u00e9es distribu\u00e9es<\/td>\n<td>N\/A (focalis\u00e9 sur les m\u00e9tadonn\u00e9es)<\/td>\n<\/tr>\n<tr>\n<td>Mod\u00e8le d&rsquo;ex\u00e9cution<\/td>\n<td>Pipeline sur sc\u00e8ne (<code>dvc repro<\/code>)<\/td>\n<td>Bas\u00e9 sur la commande (<code>datalad run<\/code>)<\/td>\n<td>\u00e0 base de d\u00e9corateur<\/td>\n<\/tr>\n<tr>\n<td>Int\u00e9gration HPC<\/td>\n<td><code>srun dvc repro<\/code><\/td>\n<td>Native Git-Annex + SSH<\/td>\n<td>configurable<\/td>\n<\/tr>\n<tr>\n<td>Provenance de sortie<\/td>\n<td><code>.dvc<\/code> Fichiers + Historique des Git<\/td>\n<td>Liens symboliques git-annex + journal git<\/td>\n<td>Graphique Prov-JSON<\/td>\n<\/tr>\n<tr>\n<td>le mieux pour<\/td>\n<td>Pipelines de mat\u00e9riaux-sciences, balayages de param\u00e8tres<\/td>\n<td>Curation de r\u00e9f\u00e9rentiel \u00e0 long terme, conformit\u00e9 des offres<\/td>\n<td>Donn\u00e9es \u00e9quitables, provenance interinstitutionnelle<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<h3>DVC est fait pour vous si :<\/h3>\n<ul>\n<li>Votre workflow comporte plusieurs \u00e9tapes d\u00e9pendantes (relaxation \u2192 Calcul des propri\u00e9t\u00e9s \u2192 visualisation)<\/li>\n<li>Vous avez besoin de balayages de param\u00e8tres avec une r\u00e9ex\u00e9cution automatique<\/li>\n<li>Vous souhaitez suivre la combinaison de param\u00e8tres produit le r\u00e9sultat d&rsquo;\u00e9nergie la plus faible<\/li>\n<\/ul>\n<h3>Datalad est fait pour vous si :<\/h3>\n<ul>\n<li>Vous conservez un r\u00e9f\u00e9rentiel de jeux de donn\u00e9es \u00e0 long terme<\/li>\n<li>Vous avez besoin de liens symboliques Git-Annex pour une gestion efficace des fichiers volumineux<\/li>\n<li>Vous travaillez avec des ensembles de donn\u00e9es distribu\u00e9s entre les institutions<\/li>\n<li>Vous avez besoin de la conformit\u00e9 des soumissions (commune en neuroimagerie)<\/li>\n<\/ul>\n<h3>Les biblioth\u00e8ques conformes \u00e0 Prov vous conviennent si :<\/h3>\n<ul>\n<li>Vous avez besoin d&rsquo;une provenance \u00e0 la machine pour une conformit\u00e9 \u00e9quitable<\/li>\n<li>Vous voulez un graphe de provenance interrogeable pour la lign\u00e9e de donn\u00e9es<\/li>\n<li>Vous collaborez entre des institutions avec diff\u00e9rents syst\u00e8mes de provenance<\/li>\n<li>Vous publiez dans un r\u00e9f\u00e9rentiel de donn\u00e9es \u00e9quitable<\/li>\n<\/ul>\n<h2>Mettre en place \u2014 un flux de travail pratique<\/h2>\n<p>Voici un mod\u00e8le de flux de travail pratique qui combine tous les concepts ci-dessus&nbsp;:<\/p>\n<pre><code class=\"language-bash\"># 1. Initialize the repository\ngit init\ndvc init\n\n# 2. Add the data\ndvc add data\/raw_crystal_structure.xyz\n\n# 3. Run the pipeline\ndvc repro\n\n# 4. Check the results\ndvc metrics show results\/energies.txt\n\n# 5. Run experiments with different parameters\ndvc exp run -S sim.tolerance=1e-8 --set-param sim.cutoff_energy=550\n\n# 6. Push data and experiments to remote\ndvc push\ndvc exp push\ngit push origin main\n\n# 7. (Optional) Generate PROV-JSON provenance\npython src\/provenance.py --output provenance.json\n<\/code><\/pre>\n<p>Ce mod\u00e8le garantit que chaque r\u00e9sultat de simulation peut \u00eatre retrac\u00e9 vers sa version exacte des donn\u00e9es, sa validation de code et son fichier de param\u00e8tres. La sortie Prov-JSON (\u00e9tape 7) ajoute une couche de provenance actionnable par la machine au-dessus du pipeline DVC.<\/p>\n<h2>Erreurs courantes &#8211; ce qu&rsquo;il faut \u00e9viter<\/h2>\n<p><strong>Erreur&nbsp;1&nbsp;: version de tout <\/strong> \u2014 Ne pas ex\u00e9cuter <code>dvc add<\/code> sur chaque fichier de sortie. Ne suivez que les fichiers qui sont des entr\u00e9es dans les \u00e9tapes suivantes ou qui repr\u00e9sentent les r\u00e9sultats finaux. Les fichiers interm\u00e9diaires (comme les tableaux de force brutes) doivent rester dans Git ou \u00eatre enti\u00e8rement exclus. L&rsquo;ajout excessif cr\u00e9e du bruit de pipeline.<\/p>\n<p><strong>Erreur&nbsp;2&nbsp;: chemins de codage en dur<\/strong> \u2014 N&rsquo;utilisez pas de chemins absolus dans <code>dvc.yaml<\/code>. Utilisez des chemins relatifs afin que le pipeline fonctionne sur diff\u00e9rentes configurations de machines et de clusters.<\/p>\n<p><strong>Erreur&nbsp;3&nbsp;: M\u00e9langer les types de donn\u00e9es<\/strong> \u2014 Ne placez pas les param\u00e8tres de simulation et les points de contr\u00f4le du mod\u00e8le dans le m\u00eame fichier <code>.dvc<\/code>. Gardez les types de donn\u00e9es s\u00e9par\u00e9s pour \u00e9viter les conflits de cache.<\/p>\n<p><strong>Erreur&nbsp;4&nbsp;: ignorer la provenance<\/strong> \u2014 Les fichiers DVC seuls ne sont pas suffisants pour une conformit\u00e9 \u00e9quitable. Si votre \u00e9tablissement a besoin de graphiques de provenance, associez DVC \u00e0 une sortie Prov-JSON (YProv4ml) ou \u00e0 un emballage RO-crate.<\/p>\n<p><strong>Erreur&nbsp;5&nbsp;: Oublier <code>params.yaml<\/code><\/strong> \u2014 Si vous codez en dur les param\u00e8tres de vos scripts au lieu de les isoler dans <code>params.yaml<\/code>, le suivi des param\u00e8tres de DVC devient inutile. Utilisez toujours <code>params.yaml<\/code> pour les param\u00e8tres de simulation.<\/p>\n<h2>R\u00e9sum\u00e9<\/h2>\n<p>DVC transforme les flux de travail scientifiques \u00e0 partir de processus fragiles et d\u00e9pendant de la m\u00e9moire en pipelines d\u00e9terministes et sensibles aux d\u00e9pendances. L&rsquo;id\u00e9e cl\u00e9 est que <code>dvc.yaml<\/code> les fichiers de pipeline et <code>params.yaml<\/code> l&rsquo;isolation des param\u00e8tres cr\u00e9ent une \u00ab\u00a0reproductibilit\u00e9 versionnelle\u00a0\u00bb &#8211; la possibilit\u00e9 de reconstruire non seulement un r\u00e9sultat, mais aussi l&rsquo;\u00e9tat exp\u00e9rimental exact (data version + code commit + fichier de param\u00e8tre) qui l&rsquo;a produit. Cela va au-del\u00e0 des conteneurs (qui gelent les environnements de code) et au-del\u00e0 de Git (qui ne peuvent pas g\u00e9rer les grands ensembles de donn\u00e9es).<\/p>\n<p>Pour l&rsquo;int\u00e9gration de HPC, le wrapper de Slurm <code>srun<\/code> permet l&rsquo;ex\u00e9cution du pipeline natif du cluster sans intervention manuelle. Pour la provenance, le W3C PROV-JSON (YProv4ml) appara\u00eet comme un format interop\u00e9rable compl\u00e9mentaire \u00e0 l&#8217;emballage RO-crate, permettant une lign\u00e9e de donn\u00e9es actionnable qui r\u00e9pond aux exigences de conformit\u00e9 \u00e9quitables.<\/p>\n<p>Le choix entre les biblioth\u00e8ques DVC, DataLad et Prov-Conformes d\u00e9pend de vos mod\u00e8les de flux de travail&nbsp;: DVC pour les exp\u00e9riences orient\u00e9es pipeline, DataLad pour la conservation des donn\u00e9es \u00e0 long terme et les biblioth\u00e8ques Prov pour les graphes de provenance actionnables par la machine. La plupart des \u00e9quipes de simulation b\u00e9n\u00e9ficient de l&rsquo;utilisation de DVC pour l&rsquo;ex\u00e9cution du pipeline et de Prov-JSON pour le suivi de la provenance &#8211; les deux outils sont compl\u00e9mentaires et non concurrents.<\/p>\n<hr>\n<h2>Guides connexes<\/h2>\n<ul>\n<li><a href=\"\/reproducibility-workflows-beyond-containers-data-versioning-and-provenance-tracking\/\">Reproductibilit\u00e9 au-del\u00e0 des conteneurs<\/a> \u2014 Couvre les bases DVC, les emballages de provenance de la caisse RO et les mod\u00e8les de reproductibilit\u00e9 \u00e0 base de conteneurs<\/li>\n<li><a href=\"https:\/\/matforge.org\/managing-large-scale-pde-problems-strategies-solvers-and-hpc-case-studies\/\">Gestion des probl\u00e8mes de PDE \u00e0 grande \u00e9chelle<\/a> &#8211; Discute de la gestion des ressources de cluster et du HPC flux de travail<\/li>\n<li><a href=\"https:\/\/matforge.org\/verification-vs-validation-in-scientific-simulations-a-practical-guide\/\">V\u00e9rification vs validation dans les simulations scientifiques<\/a> &#8211; explique le contexte de reproductibilit\u00e9 plus large pour la simulation r\u00e9sultats<\/li>\n<\/ul>\n","protected":false,"raw":"<h1>Versionnement et provenance des donn\u00e9es Python : DVC, DVC et flux de travail scientifiques<\/h1>\n<p>Le versioning des donn\u00e9es dans la simulation scientifique ne consiste pas \u00e0 suivre les changements de code - Git g\u00e8re d\u00e9j\u00e0 cela parfaitement. Il s'agit de suivre la <strong>combinaison sp\u00e9cifique<\/strong> de fichier de donn\u00e9es, de validation de code et de fichier de param\u00e8tres produit un r\u00e9sultat particulier. Cette distinction est ce qui s\u00e9pare un workflow exp\u00e9rimental fragile d'un pipeline de simulation reproductible.<\/p>\n<p>L'outil le plus largement adopt\u00e9 pour cela est DVC (Data Version Control), qui \u00e9tend le mod\u00e8le de versionnement de Git pour g\u00e9rer les grands ensembles de donn\u00e9es et les \u00e9tapes de pipeline. Cet article couvre la mise en \u0153uvre pratique de DVC pour les workflows scientifiques \u2014 construction de pipelines avec <code>dvc.yaml<\/code>, isolation des param\u00e8tres avec <code>params.yaml<\/code>, int\u00e9gration HPC\/Slurm et suivi de provenance W3C \u00e9mergent. Chiffre d'affaires, migration mat\u00e9rielle et cycles de vie de plusieurs ann\u00e9es.<\/p>\n<h2>Points \u00e0 retenir cl\u00e9s<\/h2>\n<ul>\n<li><strong>Valeur de base de DVC<\/strong>&nbsp;: les fichiers de pipeline (<code>dvc.yaml<\/code>) rendent les simulations sensibles aux d\u00e9pendances, donc <code>dvc repro<\/code> ne r\u00e9ex\u00e9cute que ce qui a chang\u00e9.<\/li>\n<li><strong>Reproductibilit\u00e9 versionnelle<\/strong>&nbsp;: les instantan\u00e9s de donn\u00e9es DVC relient les fichiers (<code>.dvc<\/code>), les validations de code (GIT) et les fichiers de param\u00e8tres (<code>params.yaml<\/code>) dans des unit\u00e9s d'exp\u00e9rience reproductibles.<\/li>\n<li><strong>Int\u00e9gration HPC<\/strong>&nbsp;: enveloppes de planification par lots Slurm DVC pour l'ex\u00e9cution du pipeline natif de cluster sans intervention manuelle<\/li>\n<li><strong>Normes de provenance<\/strong> : W3C Prov-JSON (YProv4ml) appara\u00eet comme un format interop\u00e9rable compl\u00e9mentaire aux emballages RO-Crate<\/li>\n<li><strong>DVC vs DataLad<\/strong>&nbsp;: choisissez DVC pour les exp\u00e9riences orient\u00e9es pipeline&nbsp;; Choisissez DataLad pour la conservation des donn\u00e9es \u00e0 long terme et les jeux de donn\u00e9es distribu\u00e9s<\/li>\n<\/ul>\n<h2>Pourquoi la version standard \u00e9choue pour les flux de travail de simulation<\/h2>\n<p>Git est excellent pour le suivi des changements de code. C'est terrible pour suivre les changements de donn\u00e9es.<\/p>\n<p>Lorsque vous ex\u00e9cutez un calcul de relaxation DFT, Git ne peut pas stocker le fichier de structure cristalline <code>.xyz<\/code> r\u00e9sultant (souvent des dizaines de Mo). Vous pouvez le copier sur un lecteur partag\u00e9, ou ajouter son hachage SHA-256 dans un fichier texte ou compter sur la m\u00e9moire. Les trois approches se cassent lorsque la source de donn\u00e9es change, lorsque vous devez partager avec des collaborateurs qui n'ont pas acc\u00e8s au lecteur partag\u00e9 ou lorsque vous revenez six mois plus tard et oubliez quel jeu de param\u00e8tres a produit la structure d'\u00e9nergie la plus basse.<\/p>\n<p>Les outils de gestion des donn\u00e9es r\u00e9solvent ce probl\u00e8me en d\u00e9couplant <strong>Suivi des donn\u00e9es<\/strong> de <strong>Suivi de code<\/strong>. Ils stockent des fichiers r\u00e9els dans le stockage \u00e0 distance (Google Drive, S3, un NAS partag\u00e9 ou m\u00eame un autre r\u00e9f\u00e9rentiel Git) et enregistrent des fichiers pointeurs l\u00e9gers dans le r\u00e9f\u00e9rentiel Git. Les fichiers de pointeur - g\u00e9n\u00e9ralement de petits fichiers <code>.dvc<\/code> ou les r\u00e9f\u00e9rences de liens symboliques Git-annex - contiennent des m\u00e9tadonn\u00e9es (somme de contr\u00f4le, emplacement distant, balise de version) sans dupliquer les donn\u00e9es r\u00e9elles.<\/p>\n<p>Cette s\u00e9paration est importante pour les flux de travail de simulation, car le volume de donn\u00e9es \u00e9volue ind\u00e9pendamment du volume du code. Une seule campagne de simulation peut produire des milliers de fichiers de trajectoires, tandis que les scripts Python qui les g\u00e9n\u00e8rent restent \u00e0 quelques centaines de lignes.<\/p>\n<h3>L'\u00e9cart de pipeline<\/h3>\n<p>La plupart des chercheurs commencent par le suivi ad hoc des donn\u00e9es&nbsp;: un script bash qui ex\u00e9cute les calculs en s\u00e9quence, avec des r\u00e9sultats copi\u00e9s dans un r\u00e9pertoire <code>results\/<\/code> et les nombres finaux coll\u00e9s dans une feuille Google. Cela fonctionne pour de petits projets. Il se d\u00e9compose lorsque&nbsp;:<\/p>\n<ol>\n<li><strong>R\u00e9ex\u00e9cuter avec diff\u00e9rents param\u00e8tres<\/strong> \u2014 Vous devez vous rappeler quel fichier <code>params.yaml<\/code> a \u00e9t\u00e9 utilis\u00e9 et r\u00e9ex\u00e9cuter uniquement les \u00e9tapes modifi\u00e9es<\/li>\n<li><strong>\u00c9checs de d\u00e9bogage<\/strong> : vous devez savoir si l'erreur est n\u00e9e de la corruption des donn\u00e9es, des modifications de code ou des incompatibilit\u00e9s de param\u00e8tres.<\/li>\n<li><strong>Team Handoff<\/strong> \u2014 Un nouvel \u00e9tudiant ne peut pas reconstruire le pipeline \u00e0 partir d'un script <code>bash<\/code> et d'un dossier de fichiers orphelins.<\/li>\n<\/ol>\n<p>Le fichier de d\u00e9finition de pipeline de DVC (<code>dvc.yaml<\/code>) corrige cet \u00e9cart en d\u00e9clarant des \u00e9tapes avec des d\u00e9pendances et des sorties explicites. Chaque \u00e9tape est r\u00e9ex\u00e9cut\u00e9e uniquement lorsque ses d\u00e9pendances changent (<code>dvc repro &lt;stage&gt;<\/code>), rendant les campagnes de simulation consid\u00e9rablement plus efficaces lors de la r\u00e9ex\u00e9cution des calculs avec diff\u00e9rents param\u00e8tres.<\/p>\n<h2>Construction de pipeline DVC pour les flux de travail scientifiques<\/h2>\n<p>Un fichier de pipeline DVC est un document YAML d\u00e9claratif qui mappe la fa\u00e7on dont vos \u00e9tapes de simulation d\u00e9pendent les unes des autres. Voici un exemple concret pour un flux de travail scientifique sur les mat\u00e9riaux informatiques&nbsp;:<\/p>\n<pre><code class=\"language-yaml\"># dvc.yaml \u2014 DFT relaxation and energy calculation pipeline\n\nstages:\n  relax:\n    cmd: python src\/relax.py\n    deps:\n    - data\/raw_crystal_structure.xyz\n    - src\/relax.py\n    params:\n    - params.yaml\n    outs:\n    - results\/relaxed_structure.xyz\n\n  energy:\n    cmd: python src\/energy.py\n    deps:\n    - results\/relaxed_structure.xyz\n    - src\/energy.py\n    params:\n    - params.yaml\n    outs:\n    - results\/energies.txt\n    metrics:\n    - results\/energies.txt\n\n  visualize:\n    cmd: python src\/plot.py\n    deps:\n    - results\/energies.txt\n    - src\/plot.py\n    outs:\n    - figures\/energy_plot.png\n<\/code><\/pre>\n<p>Chaque \u00e9tape d\u00e9clare :<\/p>\n<ul>\n<li><strong><code>cmd<\/code><\/strong>&nbsp;: la commande qui g\u00e9n\u00e8re les sorties de cette \u00e9tape<\/li>\n<li><strong><code>deps<\/code><\/strong>&nbsp;: fichiers qui, s'ils sont modifi\u00e9s, d\u00e9clenchent une r\u00e9ex\u00e9cution de cette \u00e9tape<\/li>\n<li><strong><code>params<\/code><\/strong>&nbsp;: fichiers de param\u00e8tres qui, s'ils sont modifi\u00e9s, d\u00e9clenchent une r\u00e9ex\u00e9cution de cette \u00e9tape<\/li>\n<li><strong><code>outs<\/code><\/strong>&nbsp;: fichiers produits par cette \u00e9tape (suivi comme versions de donn\u00e9es)<\/li>\n<li><strong><code>metrics<\/code><\/strong>&nbsp;: les fichiers que DVC suit num\u00e9riquement pour la comparaison d'exp\u00e9riences<\/li>\n<\/ul>\n<h3>Pourquoi <code>params.yaml<\/code> compte<\/h3>\n<p>Le fichier <code>params.yaml<\/code> isole les param\u00e8tres de simulation des scripts d'ex\u00e9cution. Ceci est essentiel pour les workflows de la science des mat\u00e9riaux o\u00f9 le m\u00eame code de simulation s'ex\u00e9cute des centaines de fois avec des param\u00e8tres diff\u00e9rents&nbsp;:<\/p>\n<pre><code class=\"language-yaml\"># params.yaml\nsimulator:\n  cutoff_energy: 500  # eV\n  kpoints: [8, 8, 8]\n  tolerance: 1e-6\n  \noptimization:\n  max_steps: 200\n  algorithm: ionic\n<\/code><\/pre>\n<p>Lorsque vous changez <code>tolerance<\/code> de <code>1e-6<\/code> \u00e0 <code>1e-8<\/code> et lancez <code>dvc repro<\/code>, le DVC d\u00e9tecte le <code>params.yaml<\/code> et r\u00e9ex\u00e9cute chaque \u00e9tape qui en d\u00e9pend. Le fichier <code>relaxed_structure.xyz<\/code> r\u00e9sultant obtient une nouvelle balise de version. L'ancienne version reste disponible dans le cache - vous ne perdez pas les ex\u00e9cutions historiques.<\/p>\n<p>Pour les balayages de param\u00e8tres, vous pouvez utiliser <code>--set-param<\/code> pour remplacer les valeurs sans modifier le fichier&nbsp;:<\/p>\n<pre><code class=\"language-bash\">dvc exp run --set-param sim.tolerance=1e-8 --set-param sim.cutoff_energy=450\n<\/code><\/pre>\n<p>Cela cr\u00e9e une nouvelle branche d'exp\u00e9rience, conservant \u00e0 la fois les ex\u00e9cutions originales et modifi\u00e9es dans l'historique de votre pipeline.<\/p>\n<h2>Reproductibilit\u00e9 versionn\u00e9e \u2014 Contribution conceptuelle de DVC<\/h2>\n<p>Le blog de DVC (d\u00e9cembre 2021) a introduit la \"reproductibilit\u00e9 versionnelle\" comme la possibilit\u00e9 de recr\u00e9er non seulement un r\u00e9sultat, mais aussi l'\u00e9tat exp\u00e9rimental <strong> exact<\/strong> qui l'a produit. Cela distingue le DVC du versioning g\u00e9n\u00e9rique&nbsp;:<\/p>\n<ul>\n<li><strong>Versioning standard<\/strong> Suivi des modifications apport\u00e9es aux fichiers au fil du temps (objectif de Git)<\/li>\n<li><strong>Reproductibilit\u00e9 en versions<\/strong> Suivi de la version de donn\u00e9es sp\u00e9cifiques, de la validation du code et de la combinaison de fichiers de param\u00e8tres produit un r\u00e9sultat donn\u00e9 (objectif de DVC)<\/li>\n<\/ul>\n<p>DVC y parvient en reliant trois artefacts \u00e0 version ind\u00e9pendante :<\/p>\n<table>\n<thead>\n<tr>\n<th>Artefact<\/th>\n<th>Syst\u00e8me de gestion des versions<\/th>\n<th>Ce qu'il suit<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><code>.dvc<\/code> Fichiers pointeurs<\/td>\n<td>PDV<\/td>\n<td>Version du fichier de donn\u00e9es + emplacement distant + somme de contr\u00f4le<\/td>\n<\/tr>\n<tr>\n<td>git commet<\/td>\n<td>cr\u00e9tin<\/td>\n<td>Version du code + message de validation + diff<\/td>\n<\/tr>\n<tr>\n<td><code>params.yaml<\/code><\/td>\n<td>cr\u00e9tin<\/td>\n<td>Version du fichier de param\u00e8tres + modifications au niveau du champ<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>La combinaison de ces trois cr\u00e9e une unit\u00e9 reproductible - une \"exp\u00e9rience versionnelle\" qui peut \u00eatre reconstruite isol\u00e9ment. Cela compte pour la simulation, car les exp\u00e9riences sont affin\u00e9es de mani\u00e8re it\u00e9rative. Les chercheurs ont besoin de savoir \"ce qui a fonctionn\u00e9\" et de pouvoir le reproduire sans relancer chaque \u00e9tape interm\u00e9diaire.<\/p>\n<h3>Implications pratiques<\/h3>\n<p>Lorsqu'un examinateur demande les donn\u00e9es derri\u00e8re un chiffre publi\u00e9, vous pouvez fournir :<\/p>\n<ol>\n<li>Le hachage de commit git (version de code)<\/li>\n<li>La r\u00e9f\u00e9rence de fichier de pointeur <code>.dvc<\/code> (version de donn\u00e9es)<\/li>\n<li>le fichier <code>params.yaml<\/code> \u00e0 ce commit (version du param\u00e8tre)<\/li>\n<\/ol>\n<p>Combin\u00e9s, ces trois artefacts sont suffisants pour reproduire le r\u00e9sultat sur n'importe quelle machine. Il s'agit de la r\u00e9f\u00e9rence en mati\u00e8re de reproductibilit\u00e9 de simulation - bien au-del\u00e0 des conteneurs (qui fige les environnements de code) ou des r\u00e9f\u00e9rentiels Git nus (qui ne peuvent pas g\u00e9rer les donn\u00e9es volumineuses).<\/p>\n<h2>Exp\u00e9rimentez la file d'attente et la gestion<\/h2>\n<p>La gestion des exp\u00e9riences de DVC (<code>dvc exp<\/code>) \u00e9tend le mod\u00e8le de pipeline pour prendre en charge les exp\u00e9riences simultan\u00e9es et en file d'attente&nbsp;:<\/p>\n<pre><code class=\"language-bash\"># Run a single experiment with custom parameters\ndvc exp run -S sim.tolerance=1e-8\n\n# Queue multiple experiments\ndvc exp run --queue -S sim.tolerance=1e-8\ndvc exp run --queue -S sim.tolerance=1e-6\ndvc exp run --queue -S sim.tolerance=1e-5\n\n# Execute queued experiments\ndvc exp run\n<\/code><\/pre>\n<p>L'indicateur <code>--queue<\/code> reporte l'ex\u00e9cution, vous permettant de pr\u00e9parer plusieurs exp\u00e9riences et de les ex\u00e9cuter par lots de mani\u00e8re s\u00e9quentielle. Ceci est utile pour les exp\u00e9riences de calcul qui durent des heures ou des jours. Vous pouvez mettre en file d'attente un balayage des param\u00e8tres du jour au lendemain sans lancer manuellement chaque ex\u00e9cution.<\/p>\n<p>Pour la comparaison d'exp\u00e9riences, DVClive fournit le suivi des mesures en temps r\u00e9el&nbsp;:<\/p>\n<pre><code class=\"language-python\"># src\/metrics.py \u2014 DVCLive integration\nfrom dvclive import Live\n\nwith Live() as live:\n    for step in range(n_iterations):\n        result = run_step(step)\n        live.step = step\n        live.log(\"energy\", result[\"total_energy\"])\n        live.log(\"forces\", result[\"max_force\"])\n<\/code><\/pre>\n<p>Cela produit un tableau de bord de comparaison interactif o\u00f9 vous pouvez voir comment l'\u00e9nergie et les forces \u00e9voluent \u00e0 travers les balayages de param\u00e8tres.<\/p>\n<h2>Ex\u00e9cution de pipelines DVC sur des clusters HPC<\/h2>\n<p>La plupart des scientifiques informatiques n'ex\u00e9cutent pas de pipelines sur des ordinateurs portables. Ils les ex\u00e9cutent sur des clusters avec Slurm, PBS ou LSF. DVC s'int\u00e8gre avec Slurm via le wrapper <code>srun<\/code>, permettant l'ex\u00e9cution du pipeline natif de cluster&nbsp;:<\/p>\n<pre><code class=\"language-bash\"># Run a single pipeline stage with SLURM resource allocation\nsrun dvc repro -n relax --job slurm-job.sh\n\n# Run all pipeline stages on the cluster\nsrun dvc repro\n<\/code><\/pre>\n<p>L'indicateur <code>--job<\/code> indique \u00e0 DVC d'ex\u00e9cuter chaque \u00e9tape \u00e0 travers le planificateur de travaux de Slurm, en s'occupant automatiquement&nbsp;:<\/p>\n<ul>\n<li>Allocation de ressources sp\u00e9cifiques au cluster (m\u00e9moire, CPU, n\u0153uds GPU)<\/li>\n<li>Ex\u00e9cution en mode batch sans intervention manuelle<\/li>\n<li>Mise en file d'attente automatique des travaux pour les \u00e9tapes du pipeline<\/li>\n<li>Int\u00e9gration avec les syst\u00e8mes de fichiers et le stockage sp\u00e9cifiques aux clusters (Lustre, GPFS, BEEGFS)<\/li>\n<\/ul>\n<p>ARXIV 2505.06558v2 (septembre 2025) illustre cette int\u00e9gration pour les flux de travail des mat\u00e9riaux-sciences ex\u00e9cutant des calculs DFT sur les clusters HPC. L'avantage principal est que <code>dvc repro<\/code> devient conscient des clusters - si une \u00e9tape \u00e9choue ou que ses d\u00e9pendances changent, SLURM g\u00e8re l'allocation de ressources pour la r\u00e9ex\u00e9cution uniquement des \u00e9tapes n\u00e9cessaires.<\/p>\n<h3>Consid\u00e9rations relatives au stockage des clusters<\/h3>\n<p>Le stockage \u00e0 distance de DVC fonctionne bien avec les syst\u00e8mes de fichiers de cluster. Vous pouvez configurer DVC pour utiliser le syst\u00e8me de fichiers Lustre ou GPFS du cluster en tant que t\u00e9l\u00e9commande DVC&nbsp;:<\/p>\n<pre><code class=\"language-bash\"># Configure a cluster storage remote\ndvc remote modify cluster_storage token_url \"https:\/\/cluster-storage.example.com\"\n<\/code><\/pre>\n<p>Cela \u00e9vite la surcharge de copie des donn\u00e9es vers\/depuis le stockage externe en nuage et maintient le pipeline autonome dans la hi\u00e9rarchie de stockage du cluster.<\/p>\n<h2>Suivi de provenance W3C Prov-JSON<\/h2>\n<p>Alors que DVC suit les \u00e9tapes du pipeline et les versions de donn\u00e9es, il ne produit pas de graphe de provenance actionnable par la machine. Pour cela, vous avez besoin d'une norme de provenance - et le format \u00e9mergent est le W3C Prov-JSON.<\/p>\n<p>YProv4ml (ARXIV juillet 2025) impl\u00e9mente la provenance W3C Prov-JSON avec des modifications de code minimales. Il capture :<\/p>\n<ul>\n<li><strong>Qui<\/strong> a ex\u00e9cut\u00e9 l'exp\u00e9rience (identit\u00e9 de l'utilisateur)<\/li>\n<li><strong>Quoi<\/strong>&nbsp;Donn\u00e9es et codes ont \u00e9t\u00e9 utilis\u00e9s (Source Provenance)<\/li>\n<li><strong>Comment<\/strong> L'exp\u00e9rience s'est d\u00e9roul\u00e9e (provenance d'ex\u00e9cution)<\/li>\n<li><strong>Pourquoi<\/strong> (motivation facultative, li\u00e9e aux objectifs de recherche)<\/li>\n<\/ul>\n<p>La sortie est un graphe prov-json - un graphe dirig\u00e9 o\u00f9 les n\u0153uds repr\u00e9sentent les entit\u00e9s (fichiers, param\u00e8tres, commits de code) et les bords repr\u00e9sentent les relations (d\u00e9riv\u00e9es, produites par, utilis\u00e9es). Ce format permet :<\/p>\n<ul>\n<li><strong>Interop\u00e9rabilit\u00e9 entre les syst\u00e8mes de provenance<\/strong>&nbsp;: Prov-JSON est lisible par machine et peut \u00eatre interrog\u00e9e avec des bases de donn\u00e9es SparQL ou Graph.<\/li>\n<li><strong>Conformit\u00e9 des donn\u00e9es \u00e9quitables<\/strong>&nbsp;: les graphiques Prov-JSON satisfont aux principes \u00e9quitables en documentant la lign\u00e9e de donn\u00e9es et les conditions de r\u00e9utilisation<\/li>\n<li><strong>Collaboration interinstitutionnelle<\/strong>&nbsp;: Prov-JSON est une norme W3C, de sorte que les graphiques de provenance de diff\u00e9rentes institutions sont compatibles<\/li>\n<\/ul>\n<h3>Prov-JSON vs RO-Crate<\/h3>\n<p>Il est utile de distinguer Prov-JSON de RO-Crate, puisque les deux apparaissent dans les discussions sur la reproductibilit\u00e9 :<\/p>\n<table>\n<thead>\n<tr>\n<th>aspect<\/th>\n<th>ro-caisse<\/th>\n<th>Prov-json<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>But<\/td>\n<td>Format de package pour les m\u00e9tadonn\u00e9es riches<\/td>\n<td>Format de donn\u00e9es pour les graphiques de provenance<\/td>\n<\/tr>\n<tr>\n<td>Port\u00e9e<\/td>\n<td>Ensemble de donn\u00e9es enti\u00e8res + ressources associ\u00e9es<\/td>\n<td>Ligne d'ex\u00e9cution et d\u00e9pendances<\/td>\n<\/tr>\n<tr>\n<td>Format<\/td>\n<td>JSON-LD<\/td>\n<td>JSON (norme PROV)<\/td>\n<\/tr>\n<tr>\n<td>interop\u00e9rabilit\u00e9<\/td>\n<td>Forfait autonome<\/td>\n<td>Bas\u00e9 sur des graphes, interrogeable<\/td>\n<\/tr>\n<tr>\n<td>Relations<\/td>\n<td>Compl\u00e9mentaire, non concurrent<\/td>\n<td><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>Ils abordent diff\u00e9rentes couches de reproductibilit\u00e9. RO-Crate regroupe votre jeu de donn\u00e9es avec des m\u00e9tadonn\u00e9es. Prov-JSON suit la lign\u00e9e de calcul de la fa\u00e7on dont cet ensemble de donn\u00e9es a \u00e9t\u00e9 produit. L'utilisation des deux ensemble fournit une reproductibilit\u00e9 compl\u00e8te&nbsp;: \"voici les donn\u00e9es\" (ro-crate) plus \"voici comment elles ont \u00e9t\u00e9 produites\" (prov-json).<\/p>\n<h2>Quand utiliser les biblioth\u00e8ques DVC vs DataLad vs Prov<\/h2>\n<p>Le choix entre les biblioth\u00e8ques DVC, DataLad et Prov-Conformes d\u00e9pend de vos mod\u00e8les de flux de travail&nbsp;:<\/p>\n<table>\n<thead>\n<tr>\n<th>Crit\u00e8re<\/th>\n<th>PDV<\/th>\n<th>datalad<\/th>\n<th>Bibliaires Prov<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Cas d'utilisation principal<\/td>\n<td>Exp\u00e9riences orient\u00e9es pipeline<\/td>\n<td>Curation \u00e0 long terme des donn\u00e9es<\/td>\n<td>Provenance \u00e0 la machine<\/td>\n<\/tr>\n<tr>\n<td>Taille des donn\u00e9es<\/td>\n<td>Fichiers volumineux (mod\u00e8les, simulations)<\/td>\n<td>Grands ensembles de donn\u00e9es distribu\u00e9es<\/td>\n<td>N\/A (focalis\u00e9 sur les m\u00e9tadonn\u00e9es)<\/td>\n<\/tr>\n<tr>\n<td>Mod\u00e8le d'ex\u00e9cution<\/td>\n<td>Pipeline sur sc\u00e8ne (<code>dvc repro<\/code>)<\/td>\n<td>Bas\u00e9 sur la commande (<code>datalad run<\/code>)<\/td>\n<td>\u00e0 base de d\u00e9corateur<\/td>\n<\/tr>\n<tr>\n<td>Int\u00e9gration HPC<\/td>\n<td><code>srun dvc repro<\/code><\/td>\n<td>Native Git-Annex + SSH<\/td>\n<td>configurable<\/td>\n<\/tr>\n<tr>\n<td>Provenance de sortie<\/td>\n<td><code>.dvc<\/code> Fichiers + Historique des Git<\/td>\n<td>Liens symboliques git-annex + journal git<\/td>\n<td>Graphique Prov-JSON<\/td>\n<\/tr>\n<tr>\n<td>le mieux pour<\/td>\n<td>Pipelines de mat\u00e9riaux-sciences, balayages de param\u00e8tres<\/td>\n<td>Curation de r\u00e9f\u00e9rentiel \u00e0 long terme, conformit\u00e9 des offres<\/td>\n<td>Donn\u00e9es \u00e9quitables, provenance interinstitutionnelle<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<h3>DVC est fait pour vous si :<\/h3>\n<ul>\n<li>Votre workflow comporte plusieurs \u00e9tapes d\u00e9pendantes (relaxation \u2192 Calcul des propri\u00e9t\u00e9s \u2192 visualisation)<\/li>\n<li>Vous avez besoin de balayages de param\u00e8tres avec une r\u00e9ex\u00e9cution automatique<\/li>\n<li>Vous souhaitez suivre la combinaison de param\u00e8tres produit le r\u00e9sultat d'\u00e9nergie la plus faible<\/li>\n<\/ul>\n<h3>Datalad est fait pour vous si :<\/h3>\n<ul>\n<li>Vous conservez un r\u00e9f\u00e9rentiel de jeux de donn\u00e9es \u00e0 long terme<\/li>\n<li>Vous avez besoin de liens symboliques Git-Annex pour une gestion efficace des fichiers volumineux<\/li>\n<li>Vous travaillez avec des ensembles de donn\u00e9es distribu\u00e9s entre les institutions<\/li>\n<li>Vous avez besoin de la conformit\u00e9 des soumissions (commune en neuroimagerie)<\/li>\n<\/ul>\n<h3>Les biblioth\u00e8ques conformes \u00e0 Prov vous conviennent si :<\/h3>\n<ul>\n<li>Vous avez besoin d'une provenance \u00e0 la machine pour une conformit\u00e9 \u00e9quitable<\/li>\n<li>Vous voulez un graphe de provenance interrogeable pour la lign\u00e9e de donn\u00e9es<\/li>\n<li>Vous collaborez entre des institutions avec diff\u00e9rents syst\u00e8mes de provenance<\/li>\n<li>Vous publiez dans un r\u00e9f\u00e9rentiel de donn\u00e9es \u00e9quitable<\/li>\n<\/ul>\n<h2>Mettre en place \u2014 un flux de travail pratique<\/h2>\n<p>Voici un mod\u00e8le de flux de travail pratique qui combine tous les concepts ci-dessus&nbsp;:<\/p>\n<pre><code class=\"language-bash\"># 1. Initialize the repository\ngit init\ndvc init\n\n# 2. Add the data\ndvc add data\/raw_crystal_structure.xyz\n\n# 3. Run the pipeline\ndvc repro\n\n# 4. Check the results\ndvc metrics show results\/energies.txt\n\n# 5. Run experiments with different parameters\ndvc exp run -S sim.tolerance=1e-8 --set-param sim.cutoff_energy=550\n\n# 6. Push data and experiments to remote\ndvc push\ndvc exp push\ngit push origin main\n\n# 7. (Optional) Generate PROV-JSON provenance\npython src\/provenance.py --output provenance.json\n<\/code><\/pre>\n<p>Ce mod\u00e8le garantit que chaque r\u00e9sultat de simulation peut \u00eatre retrac\u00e9 vers sa version exacte des donn\u00e9es, sa validation de code et son fichier de param\u00e8tres. La sortie Prov-JSON (\u00e9tape 7) ajoute une couche de provenance actionnable par la machine au-dessus du pipeline DVC.<\/p>\n<h2>Erreurs courantes - ce qu'il faut \u00e9viter<\/h2>\n<p><strong>Erreur&nbsp;1&nbsp;: version de tout <\/strong> \u2014 Ne pas ex\u00e9cuter <code>dvc add<\/code> sur chaque fichier de sortie. Ne suivez que les fichiers qui sont des entr\u00e9es dans les \u00e9tapes suivantes ou qui repr\u00e9sentent les r\u00e9sultats finaux. Les fichiers interm\u00e9diaires (comme les tableaux de force brutes) doivent rester dans Git ou \u00eatre enti\u00e8rement exclus. L'ajout excessif cr\u00e9e du bruit de pipeline.<\/p>\n<p><strong>Erreur&nbsp;2&nbsp;: chemins de codage en dur<\/strong> \u2014 N'utilisez pas de chemins absolus dans <code>dvc.yaml<\/code>. Utilisez des chemins relatifs afin que le pipeline fonctionne sur diff\u00e9rentes configurations de machines et de clusters.<\/p>\n<p><strong>Erreur&nbsp;3&nbsp;: M\u00e9langer les types de donn\u00e9es<\/strong> \u2014 Ne placez pas les param\u00e8tres de simulation et les points de contr\u00f4le du mod\u00e8le dans le m\u00eame fichier <code>.dvc<\/code>. Gardez les types de donn\u00e9es s\u00e9par\u00e9s pour \u00e9viter les conflits de cache.<\/p>\n<p><strong>Erreur&nbsp;4&nbsp;: ignorer la provenance<\/strong> \u2014 Les fichiers DVC seuls ne sont pas suffisants pour une conformit\u00e9 \u00e9quitable. Si votre \u00e9tablissement a besoin de graphiques de provenance, associez DVC \u00e0 une sortie Prov-JSON (YProv4ml) ou \u00e0 un emballage RO-crate.<\/p>\n<p><strong>Erreur&nbsp;5&nbsp;: Oublier <code>params.yaml<\/code><\/strong> \u2014 Si vous codez en dur les param\u00e8tres de vos scripts au lieu de les isoler dans <code>params.yaml<\/code>, le suivi des param\u00e8tres de DVC devient inutile. Utilisez toujours <code>params.yaml<\/code> pour les param\u00e8tres de simulation.<\/p>\n<h2>R\u00e9sum\u00e9<\/h2>\n<p>DVC transforme les flux de travail scientifiques \u00e0 partir de processus fragiles et d\u00e9pendant de la m\u00e9moire en pipelines d\u00e9terministes et sensibles aux d\u00e9pendances. L'id\u00e9e cl\u00e9 est que <code>dvc.yaml<\/code> les fichiers de pipeline et <code>params.yaml<\/code> l'isolation des param\u00e8tres cr\u00e9ent une \"reproductibilit\u00e9 versionnelle\" - la possibilit\u00e9 de reconstruire non seulement un r\u00e9sultat, mais aussi l'\u00e9tat exp\u00e9rimental exact (data version + code commit + fichier de param\u00e8tre) qui l'a produit. Cela va au-del\u00e0 des conteneurs (qui gelent les environnements de code) et au-del\u00e0 de Git (qui ne peuvent pas g\u00e9rer les grands ensembles de donn\u00e9es).<\/p>\n<p>Pour l'int\u00e9gration de HPC, le wrapper de Slurm <code>srun<\/code> permet l'ex\u00e9cution du pipeline natif du cluster sans intervention manuelle. Pour la provenance, le W3C PROV-JSON (YProv4ml) appara\u00eet comme un format interop\u00e9rable compl\u00e9mentaire \u00e0 l'emballage RO-crate, permettant une lign\u00e9e de donn\u00e9es actionnable qui r\u00e9pond aux exigences de conformit\u00e9 \u00e9quitables.<\/p>\n<p>Le choix entre les biblioth\u00e8ques DVC, DataLad et Prov-Conformes d\u00e9pend de vos mod\u00e8les de flux de travail&nbsp;: DVC pour les exp\u00e9riences orient\u00e9es pipeline, DataLad pour la conservation des donn\u00e9es \u00e0 long terme et les biblioth\u00e8ques Prov pour les graphes de provenance actionnables par la machine. La plupart des \u00e9quipes de simulation b\u00e9n\u00e9ficient de l'utilisation de DVC pour l'ex\u00e9cution du pipeline et de Prov-JSON pour le suivi de la provenance - les deux outils sont compl\u00e9mentaires et non concurrents.<\/p>\n<hr>\n<h2>Guides connexes<\/h2>\n<ul>\n<li><a href=\"\/reproducibility-workflows-beyond-containers-data-versioning-and-provenance-tracking\/\">Reproductibilit\u00e9 au-del\u00e0 des conteneurs<\/a> \u2014 Couvre les bases DVC, les emballages de provenance de la caisse RO et les mod\u00e8les de reproductibilit\u00e9 \u00e0 base de conteneurs<\/li>\n<li><a href=\"https:\/\/matforge.org\/managing-large-scale-pde-problems-strategies-solvers-and-hpc-case-studies\/\">Gestion des probl\u00e8mes de PDE \u00e0 grande \u00e9chelle<\/a> - Discute de la gestion des ressources de cluster et du HPC flux de travail<\/li>\n<li><a href=\"https:\/\/matforge.org\/verification-vs-validation-in-scientific-simulations-a-practical-guide\/\">V\u00e9rification vs validation dans les simulations scientifiques<\/a> - explique le contexte de reproductibilit\u00e9 plus large pour la simulation r\u00e9sultats&lt;\/fs_write_file&gt;<br> &lt;\/tool_call&gt;&nbsp;;<\/li>\n<\/ul>\n<p>&lt;tool_call&gt;<br> &lt;function=fs_write_file&gt;<br> &lt;parameter=content&gt;<\/p>\n<h1>Versionnement et provenance des donn\u00e9es Python : DVC, DVC et flux de travail scientifiques<\/h1>\n<p>Le versioning des donn\u00e9es dans la simulation scientifique ne consiste pas \u00e0 suivre les changements de code - Git g\u00e8re d\u00e9j\u00e0 cela parfaitement. Il s'agit de suivre la <strong>combinaison sp\u00e9cifique<\/strong> de fichier de donn\u00e9es, de validation de code et de fichier de param\u00e8tres produit un r\u00e9sultat particulier. Cette distinction est ce qui s\u00e9pare un workflow exp\u00e9rimental fragile d'un pipeline de simulation reproductible.<\/p>\n<p>L'outil le plus largement adopt\u00e9 pour cela est DVC (Data Version Control), qui \u00e9tend le mod\u00e8le de versionnement de Git pour g\u00e9rer les grands ensembles de donn\u00e9es et les \u00e9tapes de pipeline. Cet article couvre la mise en \u0153uvre pratique de DVC pour les workflows scientifiques \u2014 construction de pipelines avec <code>dvc.yaml<\/code>, isolation des param\u00e8tres avec <code>params.yaml<\/code>, int\u00e9gration HPC\/Slurm et suivi de provenance W3C \u00e9mergent. Chiffre d'affaires, migration mat\u00e9rielle et cycles de vie de plusieurs ann\u00e9es.<\/p>\n<h2>Points \u00e0 retenir cl\u00e9s<\/h2>\n<ul>\n<li><strong>Valeur de base de DVC<\/strong>&nbsp;: les fichiers de pipeline (<code>dvc.yaml<\/code>) rendent les simulations sensibles aux d\u00e9pendances, donc <code>dvc repro<\/code> ne r\u00e9ex\u00e9cute que ce qui a chang\u00e9.<\/li>\n<li><strong>Reproductibilit\u00e9 versionnelle<\/strong>&nbsp;: les instantan\u00e9s de donn\u00e9es DVC relient les fichiers (<code>.dvc<\/code>), les validations de code (GIT) et les fichiers de param\u00e8tres (<code>params.yaml<\/code>) dans des unit\u00e9s d'exp\u00e9rience reproductibles.<\/li>\n<li><strong>Int\u00e9gration HPC<\/strong>&nbsp;: enveloppes de planification par lots Slurm DVC pour l'ex\u00e9cution du pipeline natif de cluster sans intervention manuelle<\/li>\n<li><strong>Normes de provenance<\/strong> : W3C Prov-JSON (YProv4ml) appara\u00eet comme un format interop\u00e9rable compl\u00e9mentaire aux emballages RO-Crate<\/li>\n<li><strong>DVC vs DataLad<\/strong>&nbsp;: choisissez DVC pour les exp\u00e9riences orient\u00e9es pipeline&nbsp;; Choisissez DataLad pour la conservation des donn\u00e9es \u00e0 long terme et les jeux de donn\u00e9es distribu\u00e9s<\/li>\n<\/ul>\n<h2>Pourquoi la version standard \u00e9choue pour les flux de travail de simulation<\/h2>\n<p>Git est excellent pour le suivi des changements de code. C'est terrible pour suivre les changements de donn\u00e9es.<\/p>\n<p>Lorsque vous ex\u00e9cutez un calcul de relaxation DFT, Git ne peut pas stocker le fichier de structure cristalline <code>.xyz<\/code> r\u00e9sultant (souvent des dizaines de Mo). Vous pouvez le copier sur un lecteur partag\u00e9, ou ajouter son hachage SHA-256 dans un fichier texte ou compter sur la m\u00e9moire. Les trois approches se cassent lorsque la source de donn\u00e9es change, lorsque vous devez partager avec des collaborateurs qui n'ont pas acc\u00e8s au lecteur partag\u00e9 ou lorsque vous revenez six mois plus tard et oubliez quel jeu de param\u00e8tres a produit la structure d'\u00e9nergie la plus basse.<\/p>\n<p>Les outils de gestion des donn\u00e9es r\u00e9solvent ce probl\u00e8me en d\u00e9couplant <strong>Suivi des donn\u00e9es<\/strong> de <strong>Suivi de code<\/strong>. Ils stockent des fichiers r\u00e9els dans le stockage \u00e0 distance (Google Drive, S3, un NAS partag\u00e9 ou m\u00eame un autre r\u00e9f\u00e9rentiel Git) et enregistrent des fichiers pointeurs l\u00e9gers dans le r\u00e9f\u00e9rentiel Git. Les fichiers de pointeur - g\u00e9n\u00e9ralement de petits fichiers <code>.dvc<\/code> ou les r\u00e9f\u00e9rences de liens symboliques Git-annex - contiennent des m\u00e9tadonn\u00e9es (somme de contr\u00f4le, emplacement distant, balise de version) sans dupliquer les donn\u00e9es r\u00e9elles.<\/p>\n<p>Cette s\u00e9paration est importante pour les flux de travail de simulation, car le volume de donn\u00e9es \u00e9volue ind\u00e9pendamment du volume du code. Une seule campagne de simulation peut produire des milliers de fichiers de trajectoires, tandis que les scripts Python qui les g\u00e9n\u00e8rent restent \u00e0 quelques centaines de lignes.<\/p>\n<h3>L'\u00e9cart de pipeline<\/h3>\n<p>La plupart des chercheurs commencent par le suivi ad hoc des donn\u00e9es&nbsp;: un script bash qui ex\u00e9cute les calculs en s\u00e9quence, avec des r\u00e9sultats copi\u00e9s dans un r\u00e9pertoire <code>results\/<\/code> et les nombres finaux coll\u00e9s dans une feuille Google. Cela fonctionne pour de petits projets. Il se d\u00e9compose lorsque&nbsp;:<\/p>\n<ol>\n<li><strong>R\u00e9ex\u00e9cuter avec diff\u00e9rents param\u00e8tres<\/strong> \u2014 Vous devez vous rappeler quel fichier <code>params.yaml<\/code> a \u00e9t\u00e9 utilis\u00e9 et r\u00e9ex\u00e9cuter uniquement les \u00e9tapes modifi\u00e9es<\/li>\n<li><strong>\u00c9checs de d\u00e9bogage<\/strong> : vous devez savoir si l'erreur est n\u00e9e de la corruption des donn\u00e9es, des modifications de code ou des incompatibilit\u00e9s de param\u00e8tres.<\/li>\n<li><strong>Team Handoff<\/strong> \u2014 Un nouvel \u00e9tudiant ne peut pas reconstruire le pipeline \u00e0 partir d'un script <code>bash<\/code> et d'un dossier de fichiers orphelins.<\/li>\n<\/ol>\n<p>Le fichier de d\u00e9finition de pipeline de DVC (<code>dvc.yaml<\/code>) corrige cet \u00e9cart en d\u00e9clarant des \u00e9tapes avec des d\u00e9pendances et des sorties explicites. Chaque \u00e9tape est r\u00e9ex\u00e9cut\u00e9e uniquement lorsque ses d\u00e9pendances changent (<code>dvc repro &lt;stage&gt;<\/code>), rendant les campagnes de simulation consid\u00e9rablement plus efficaces lors de la r\u00e9ex\u00e9cution des calculs avec diff\u00e9rents param\u00e8tres.<\/p>\n<h2>Construction de pipeline DVC pour les flux de travail scientifiques<\/h2>\n<p>Un fichier de pipeline DVC est un document YAML d\u00e9claratif qui mappe la fa\u00e7on dont vos \u00e9tapes de simulation d\u00e9pendent les unes des autres. Voici un exemple concret pour un flux de travail scientifique sur les mat\u00e9riaux informatiques&nbsp;:<\/p>\n<pre><code class=\"language-yaml\"># dvc.yaml \u2014 DFT relaxation and energy calculation pipeline\n\nstages:\n  relax:\n    cmd: python src\/relax.py\n    deps:\n    - data\/raw_crystal_structure.xyz\n    - src\/relax.py\n    params:\n    - params.yaml\n    outs:\n    - results\/relaxed_structure.xyz\n\n  energy:\n    cmd: python src\/energy.py\n    deps:\n    - results\/relaxed_structure.xyz\n    - src\/energy.py\n    params:\n    - params.yaml\n    outs:\n    - results\/energies.txt\n    metrics:\n    - results\/energies.txt\n\n  visualize:\n    cmd: python src\/plot.py\n    deps:\n    - results\/energies.txt\n    - src\/plot.py\n    outs:\n    - figures\/energy_plot.png\n<\/code><\/pre>\n<p>Chaque \u00e9tape d\u00e9clare :<\/p>\n<ul>\n<li><strong><code>cmd<\/code><\/strong>&nbsp;: la commande qui g\u00e9n\u00e8re les sorties de cette \u00e9tape<\/li>\n<li><strong><code>deps<\/code><\/strong>&nbsp;: fichiers qui, s'ils sont modifi\u00e9s, d\u00e9clenchent une r\u00e9ex\u00e9cution de cette \u00e9tape<\/li>\n<li><strong><code>params<\/code><\/strong>&nbsp;: fichiers de param\u00e8tres qui, s'ils sont modifi\u00e9s, d\u00e9clenchent une r\u00e9ex\u00e9cution de cette \u00e9tape<\/li>\n<li><strong><code>outs<\/code><\/strong>&nbsp;: fichiers produits par cette \u00e9tape (suivi comme versions de donn\u00e9es)<\/li>\n<li><strong><code>metrics<\/code><\/strong>&nbsp;: les fichiers que DVC suit num\u00e9riquement pour la comparaison d'exp\u00e9riences<\/li>\n<\/ul>\n<h3>Pourquoi <code>params.yaml<\/code> compte<\/h3>\n<p>Le fichier <code>params.yaml<\/code> isole les param\u00e8tres de simulation des scripts d'ex\u00e9cution. Ceci est essentiel pour les workflows de la science des mat\u00e9riaux o\u00f9 le m\u00eame code de simulation s'ex\u00e9cute des centaines de fois avec des param\u00e8tres diff\u00e9rents&nbsp;:<\/p>\n<pre><code class=\"language-yaml\"># params.yaml\nsimulator:\n  cutoff_energy: 500  # eV\n  kpoints: [8, 8, 8]\n  tolerance: 1e-6\n  \noptimization:\n  max_steps: 200\n  algorithm: ionic\n<\/code><\/pre>\n<p>Lorsque vous changez <code>tolerance<\/code> de <code>1e-6<\/code> \u00e0 <code>1e-8<\/code> et lancez <code>dvc repro<\/code>, le DVC d\u00e9tecte le <code>params.yaml<\/code> et r\u00e9ex\u00e9cute chaque \u00e9tape qui en d\u00e9pend. Le fichier <code>relaxed_structure.xyz<\/code> r\u00e9sultant obtient une nouvelle balise de version. L'ancienne version reste disponible dans le cache - vous ne perdez pas les ex\u00e9cutions historiques.<\/p>\n<p>Pour les balayages de param\u00e8tres, vous pouvez utiliser <code>--set-param<\/code> pour remplacer les valeurs sans modifier le fichier&nbsp;:<\/p>\n<pre><code class=\"language-bash\">dvc exp run --set-param sim.tolerance=1e-8 --set-param sim.cutoff_energy=450\n<\/code><\/pre>\n<p>Cela cr\u00e9e une nouvelle branche d'exp\u00e9rience, conservant \u00e0 la fois les ex\u00e9cutions originales et modifi\u00e9es dans l'historique de votre pipeline.<\/p>\n<h2>Reproductibilit\u00e9 versionn\u00e9e \u2014 Contribution conceptuelle de DVC<\/h2>\n<p>Le blog de DVC (d\u00e9cembre 2021) a introduit la \"reproductibilit\u00e9 versionnelle\" comme la possibilit\u00e9 de recr\u00e9er non seulement un r\u00e9sultat, mais aussi l'\u00e9tat exp\u00e9rimental <strong> exact<\/strong> qui l'a produit. Cela distingue le DVC du versioning g\u00e9n\u00e9rique&nbsp;:<\/p>\n<ul>\n<li><strong>Versioning standard<\/strong> Suivi des modifications apport\u00e9es aux fichiers au fil du temps (objectif de Git)<\/li>\n<li><strong>Reproductibilit\u00e9 en versions<\/strong> Suivi de la version de donn\u00e9es sp\u00e9cifiques, de la validation du code et de la combinaison de fichiers de param\u00e8tres produit un r\u00e9sultat donn\u00e9 (objectif de DVC)<\/li>\n<\/ul>\n<p>DVC y parvient en reliant trois artefacts \u00e0 version ind\u00e9pendante :<\/p>\n<table>\n<thead>\n<tr>\n<th>Artefact<\/th>\n<th>Syst\u00e8me de gestion des versions<\/th>\n<th>Ce qu'il suit<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><code>.dvc<\/code> Fichiers pointeurs<\/td>\n<td>PDV<\/td>\n<td>Version du fichier de donn\u00e9es + emplacement distant + somme de contr\u00f4le<\/td>\n<\/tr>\n<tr>\n<td>git commet<\/td>\n<td>cr\u00e9tin<\/td>\n<td>Version du code + message de validation + diff<\/td>\n<\/tr>\n<tr>\n<td><code>params.yaml<\/code><\/td>\n<td>cr\u00e9tin<\/td>\n<td>Version du fichier de param\u00e8tres + modifications au niveau du champ<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>La combinaison de ces trois cr\u00e9e une unit\u00e9 reproductible - une \"exp\u00e9rience versionnelle\" qui peut \u00eatre reconstruite isol\u00e9ment. Cela compte pour la simulation, car les exp\u00e9riences sont affin\u00e9es de mani\u00e8re it\u00e9rative. Les chercheurs ont besoin de savoir \"ce qui a fonctionn\u00e9\" et de pouvoir le reproduire sans relancer chaque \u00e9tape interm\u00e9diaire.<\/p>\n<h3>Implications pratiques<\/h3>\n<p>Lorsqu'un examinateur demande les donn\u00e9es derri\u00e8re un chiffre publi\u00e9, vous pouvez fournir :<\/p>\n<ol>\n<li>Le hachage de commit git (version de code)<\/li>\n<li>La r\u00e9f\u00e9rence de fichier de pointeur <code>.dvc<\/code> (version de donn\u00e9es)<\/li>\n<li>le fichier <code>params.yaml<\/code> \u00e0 ce commit (version du param\u00e8tre)<\/li>\n<\/ol>\n<p>Combin\u00e9s, ces trois artefacts sont suffisants pour reproduire le r\u00e9sultat sur n'importe quelle machine. Il s'agit de la r\u00e9f\u00e9rence en mati\u00e8re de reproductibilit\u00e9 de simulation - bien au-del\u00e0 des conteneurs (qui fige les environnements de code) ou des r\u00e9f\u00e9rentiels Git nus (qui ne peuvent pas g\u00e9rer les donn\u00e9es volumineuses).<\/p>\n<h2>Exp\u00e9rimentez la file d'attente et la gestion<\/h2>\n<p>La gestion des exp\u00e9riences de DVC (<code>dvc exp<\/code>) \u00e9tend le mod\u00e8le de pipeline pour prendre en charge les exp\u00e9riences simultan\u00e9es et en file d'attente&nbsp;:<\/p>\n<pre><code class=\"language-bash\"># Run a single experiment with custom parameters\ndvc exp run -S sim.tolerance=1e-8\n\n# Queue multiple experiments\ndvc exp run --queue -S sim.tolerance=1e-8\ndvc exp run --queue -S sim.tolerance=1e-6\ndvc exp run --queue -S sim.tolerance=1e-5\n\n# Execute queued experiments\ndvc exp run\n<\/code><\/pre>\n<p>L'indicateur <code>--queue<\/code> reporte l'ex\u00e9cution, vous permettant de pr\u00e9parer plusieurs exp\u00e9riences et de les ex\u00e9cuter par lots de mani\u00e8re s\u00e9quentielle. Ceci est utile pour les exp\u00e9riences de calcul qui durent des heures ou des jours. Vous pouvez mettre en file d'attente un balayage des param\u00e8tres du jour au lendemain sans lancer manuellement chaque ex\u00e9cution.<\/p>\n<p>Pour la comparaison d'exp\u00e9riences, DVClive fournit le suivi des mesures en temps r\u00e9el&nbsp;:<\/p>\n<pre><code class=\"language-python\"># src\/metrics.py \u2014 DVCLive integration\nfrom dvclive import Live\n\nwith Live() as live:\n    for step in range(n_iterations):\n        result = run_step(step)\n        live.step = step\n        live.log(\"energy\", result[\"total_energy\"])\n        live.log(\"forces\", result[\"max_force\"])\n<\/code><\/pre>\n<p>Cela produit un tableau de bord de comparaison interactif o\u00f9 vous pouvez voir comment l'\u00e9nergie et les forces \u00e9voluent \u00e0 travers les balayages de param\u00e8tres.<\/p>\n<h2>Ex\u00e9cution de pipelines DVC sur des clusters HPC<\/h2>\n<p>La plupart des scientifiques informatiques n'ex\u00e9cutent pas de pipelines sur des ordinateurs portables. Ils les ex\u00e9cutent sur des clusters avec Slurm, PBS ou LSF. DVC s'int\u00e8gre avec Slurm via le wrapper <code>srun<\/code>, permettant l'ex\u00e9cution du pipeline natif de cluster&nbsp;:<\/p>\n<pre><code class=\"language-bash\"># Run a single pipeline stage with SLURM resource allocation\nsrun dvc repro -n relax --job slurm-job.sh\n\n# Run all pipeline stages on the cluster\nsrun dvc repro\n<\/code><\/pre>\n<p>L'indicateur <code>--job<\/code> indique \u00e0 DVC d'ex\u00e9cuter chaque \u00e9tape \u00e0 travers le planificateur de travaux de Slurm, en s'occupant automatiquement&nbsp;:<\/p>\n<ul>\n<li>Allocation de ressources sp\u00e9cifiques au cluster (m\u00e9moire, CPU, n\u0153uds GPU)<\/li>\n<li>Ex\u00e9cution en mode batch sans intervention manuelle<\/li>\n<li>Mise en file d'attente automatique des travaux pour les \u00e9tapes du pipeline<\/li>\n<li>Int\u00e9gration avec les syst\u00e8mes de fichiers et le stockage sp\u00e9cifiques aux clusters (Lustre, GPFS, BEEGFS)<\/li>\n<\/ul>\n<p>ARXIV 2505.06558v2 (septembre 2025) illustre cette int\u00e9gration pour les flux de travail des mat\u00e9riaux-sciences ex\u00e9cutant des calculs DFT sur les clusters HPC. L'avantage principal est que <code>dvc repro<\/code> devient conscient des clusters - si une \u00e9tape \u00e9choue ou que ses d\u00e9pendances changent, SLURM g\u00e8re l'allocation de ressources pour la r\u00e9ex\u00e9cution uniquement des \u00e9tapes n\u00e9cessaires.<\/p>\n<h3>Consid\u00e9rations relatives au stockage des clusters<\/h3>\n<p>Le stockage \u00e0 distance de DVC fonctionne bien avec les syst\u00e8mes de fichiers de cluster. Vous pouvez configurer DVC pour utiliser le syst\u00e8me de fichiers Lustre ou GPFS du cluster en tant que t\u00e9l\u00e9commande DVC&nbsp;:<\/p>\n<pre><code class=\"language-bash\"># Configure a cluster storage remote\ndvc remote modify cluster_storage token_url \"https:\/\/cluster-storage.example.com\"\n<\/code><\/pre>\n<p>Cela \u00e9vite la surcharge de copie des donn\u00e9es vers\/depuis le stockage externe en nuage et maintient le pipeline autonome dans la hi\u00e9rarchie de stockage du cluster.<\/p>\n<h2>Suivi de provenance W3C Prov-JSON<\/h2>\n<p>Alors que DVC suit les \u00e9tapes du pipeline et les versions de donn\u00e9es, il ne produit pas de graphe de provenance actionnable par la machine. Pour cela, vous avez besoin d'une norme de provenance - et le format \u00e9mergent est le W3C Prov-JSON.<\/p>\n<p>YProv4ml (ARXIV juillet 2025) impl\u00e9mente la provenance W3C Prov-JSON avec des modifications de code minimales. Il capture :<\/p>\n<ul>\n<li><strong>Qui<\/strong> a ex\u00e9cut\u00e9 l'exp\u00e9rience (identit\u00e9 de l'utilisateur)<\/li>\n<li><strong>Quoi<\/strong>&nbsp;Donn\u00e9es et codes ont \u00e9t\u00e9 utilis\u00e9s (Source Provenance)<\/li>\n<li><strong>Comment<\/strong> L'exp\u00e9rience s'est d\u00e9roul\u00e9e (provenance d'ex\u00e9cution)<\/li>\n<li><strong>Pourquoi<\/strong> (motivation facultative, li\u00e9e aux objectifs de recherche)<\/li>\n<\/ul>\n<p>La sortie est un graphe prov-json - un graphe dirig\u00e9 o\u00f9 les n\u0153uds repr\u00e9sentent les entit\u00e9s (fichiers, param\u00e8tres, commits de code) et les bords repr\u00e9sentent les relations (d\u00e9riv\u00e9es, produites par, utilis\u00e9es). Ce format permet :<\/p>\n<ul>\n<li><strong>Interop\u00e9rabilit\u00e9 entre les syst\u00e8mes de provenance<\/strong>&nbsp;: Prov-JSON est lisible par machine et peut \u00eatre interrog\u00e9e avec des bases de donn\u00e9es SparQL ou Graph.<\/li>\n<li><strong>Conformit\u00e9 des donn\u00e9es \u00e9quitables<\/strong>&nbsp;: les graphiques Prov-JSON satisfont aux principes \u00e9quitables en documentant la lign\u00e9e de donn\u00e9es et les conditions de r\u00e9utilisation<\/li>\n<li><strong>Collaboration interinstitutionnelle<\/strong>&nbsp;: Prov-JSON est une norme W3C, de sorte que les graphiques de provenance de diff\u00e9rentes institutions sont compatibles<\/li>\n<\/ul>\n<h3>Prov-JSON vs RO-Crate<\/h3>\n<p>Il est utile de distinguer Prov-JSON de RO-Crate, puisque les deux apparaissent dans les discussions sur la reproductibilit\u00e9 :<\/p>\n<table>\n<thead>\n<tr>\n<th>aspect<\/th>\n<th>ro-caisse<\/th>\n<th>Prov-json<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>But<\/td>\n<td>Format de package pour les m\u00e9tadonn\u00e9es riches<\/td>\n<td>Format de donn\u00e9es pour les graphiques de provenance<\/td>\n<\/tr>\n<tr>\n<td>Port\u00e9e<\/td>\n<td>Ensemble de donn\u00e9es enti\u00e8res + ressources associ\u00e9es<\/td>\n<td>Ligne d'ex\u00e9cution et d\u00e9pendances<\/td>\n<\/tr>\n<tr>\n<td>Format<\/td>\n<td>JSON-LD<\/td>\n<td>JSON (norme PROV)<\/td>\n<\/tr>\n<tr>\n<td>interop\u00e9rabilit\u00e9<\/td>\n<td>Forfait autonome<\/td>\n<td>Bas\u00e9 sur des graphes, interrogeable<\/td>\n<\/tr>\n<tr>\n<td>Relations<\/td>\n<td>Compl\u00e9mentaire, non concurrent<\/td>\n<td><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>Ils abordent diff\u00e9rentes couches de reproductibilit\u00e9. RO-Crate regroupe votre jeu de donn\u00e9es avec des m\u00e9tadonn\u00e9es. Prov-JSON suit la lign\u00e9e de calcul de la fa\u00e7on dont cet ensemble de donn\u00e9es a \u00e9t\u00e9 produit. L'utilisation des deux ensemble fournit une reproductibilit\u00e9 compl\u00e8te&nbsp;: \"voici les donn\u00e9es\" (ro-crate) plus \"voici comment elles ont \u00e9t\u00e9 produites\" (prov-json).<\/p>\n<h2>Quand utiliser les biblioth\u00e8ques DVC vs DataLad vs Prov<\/h2>\n<p>Le choix entre les biblioth\u00e8ques DVC, DataLad et Prov-Conformes d\u00e9pend de vos mod\u00e8les de flux de travail&nbsp;:<\/p>\n<table>\n<thead>\n<tr>\n<th>Crit\u00e8re<\/th>\n<th>PDV<\/th>\n<th>datalad<\/th>\n<th>Bibliaires Prov<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Cas d'utilisation principal<\/td>\n<td>Exp\u00e9riences orient\u00e9es pipeline<\/td>\n<td>Curation \u00e0 long terme des donn\u00e9es<\/td>\n<td>Provenance \u00e0 la machine<\/td>\n<\/tr>\n<tr>\n<td>Taille des donn\u00e9es<\/td>\n<td>Fichiers volumineux (mod\u00e8les, simulations)<\/td>\n<td>Grands ensembles de donn\u00e9es distribu\u00e9es<\/td>\n<td>N\/A (focalis\u00e9 sur les m\u00e9tadonn\u00e9es)<\/td>\n<\/tr>\n<tr>\n<td>Mod\u00e8le d'ex\u00e9cution<\/td>\n<td>Pipeline sur sc\u00e8ne (<code>dvc repro<\/code>)<\/td>\n<td>Bas\u00e9 sur la commande (<code>datalad run<\/code>)<\/td>\n<td>\u00e0 base de d\u00e9corateur<\/td>\n<\/tr>\n<tr>\n<td>Int\u00e9gration HPC<\/td>\n<td><code>srun dvc repro<\/code><\/td>\n<td>Native Git-Annex + SSH<\/td>\n<td>configurable<\/td>\n<\/tr>\n<tr>\n<td>Provenance de sortie<\/td>\n<td><code>.dvc<\/code> Fichiers + Historique des Git<\/td>\n<td>Liens symboliques git-annex + journal git<\/td>\n<td>Graphique Prov-JSON<\/td>\n<\/tr>\n<tr>\n<td>le mieux pour<\/td>\n<td>Pipelines de mat\u00e9riaux-sciences, balayages de param\u00e8tres<\/td>\n<td>Curation de r\u00e9f\u00e9rentiel \u00e0 long terme, conformit\u00e9 des offres<\/td>\n<td>Donn\u00e9es \u00e9quitables, provenance interinstitutionnelle<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<h3>DVC est fait pour vous si :<\/h3>\n<ul>\n<li>Votre workflow comporte plusieurs \u00e9tapes d\u00e9pendantes (relaxation \u2192 Calcul des propri\u00e9t\u00e9s \u2192 visualisation)<\/li>\n<li>Vous avez besoin de balayages de param\u00e8tres avec une r\u00e9ex\u00e9cution automatique<\/li>\n<li>Vous souhaitez suivre la combinaison de param\u00e8tres produit le r\u00e9sultat d'\u00e9nergie la plus faible<\/li>\n<\/ul>\n<h3>Datalad est fait pour vous si :<\/h3>\n<ul>\n<li>Vous conservez un r\u00e9f\u00e9rentiel de jeux de donn\u00e9es \u00e0 long terme<\/li>\n<li>Vous avez besoin de liens symboliques Git-Annex pour une gestion efficace des fichiers volumineux<\/li>\n<li>Vous travaillez avec des ensembles de donn\u00e9es distribu\u00e9s entre les institutions<\/li>\n<li>Vous avez besoin de la conformit\u00e9 des soumissions (commune en neuroimagerie)<\/li>\n<\/ul>\n<h3>Les biblioth\u00e8ques conformes \u00e0 Prov vous conviennent si :<\/h3>\n<ul>\n<li>Vous avez besoin d'une provenance \u00e0 la machine pour une conformit\u00e9 \u00e9quitable<\/li>\n<li>Vous voulez un graphe de provenance interrogeable pour la lign\u00e9e de donn\u00e9es<\/li>\n<li>Vous collaborez entre des institutions avec diff\u00e9rents syst\u00e8mes de provenance<\/li>\n<li>Vous publiez dans un r\u00e9f\u00e9rentiel de donn\u00e9es \u00e9quitable<\/li>\n<\/ul>\n<h2>Mettre en place \u2014 un flux de travail pratique<\/h2>\n<p>Voici un mod\u00e8le de flux de travail pratique qui combine tous les concepts ci-dessus&nbsp;:<\/p>\n<pre><code class=\"language-bash\"># 1. Initialize the repository\ngit init\ndvc init\n\n# 2. Add the data\ndvc add data\/raw_crystal_structure.xyz\n\n# 3. Run the pipeline\ndvc repro\n\n# 4. Check the results\ndvc metrics show results\/energies.txt\n\n# 5. Run experiments with different parameters\ndvc exp run -S sim.tolerance=1e-8 --set-param sim.cutoff_energy=550\n\n# 6. Push data and experiments to remote\ndvc push\ndvc exp push\ngit push origin main\n\n# 7. (Optional) Generate PROV-JSON provenance\npython src\/provenance.py --output provenance.json\n<\/code><\/pre>\n<p>Ce mod\u00e8le garantit que chaque r\u00e9sultat de simulation peut \u00eatre retrac\u00e9 vers sa version exacte des donn\u00e9es, sa validation de code et son fichier de param\u00e8tres. La sortie Prov-JSON (\u00e9tape 7) ajoute une couche de provenance actionnable par la machine au-dessus du pipeline DVC.<\/p>\n<h2>Erreurs courantes - ce qu'il faut \u00e9viter<\/h2>\n<p><strong>Erreur&nbsp;1&nbsp;: version de tout <\/strong> \u2014 Ne pas ex\u00e9cuter <code>dvc add<\/code> sur chaque fichier de sortie. Ne suivez que les fichiers qui sont des entr\u00e9es dans les \u00e9tapes suivantes ou qui repr\u00e9sentent les r\u00e9sultats finaux. Les fichiers interm\u00e9diaires (comme les tableaux de force brutes) doivent rester dans Git ou \u00eatre enti\u00e8rement exclus. L'ajout excessif cr\u00e9e du bruit de pipeline.<\/p>\n<p><strong>Erreur&nbsp;2&nbsp;: chemins de codage en dur<\/strong> \u2014 N'utilisez pas de chemins absolus dans <code>dvc.yaml<\/code>. Utilisez des chemins relatifs afin que le pipeline fonctionne sur diff\u00e9rentes configurations de machines et de clusters.<\/p>\n<p><strong>Erreur&nbsp;3&nbsp;: M\u00e9langer les types de donn\u00e9es<\/strong> \u2014 Ne placez pas les param\u00e8tres de simulation et les points de contr\u00f4le du mod\u00e8le dans le m\u00eame fichier <code>.dvc<\/code>. Gardez les types de donn\u00e9es s\u00e9par\u00e9s pour \u00e9viter les conflits de cache.<\/p>\n<p><strong>Erreur&nbsp;4&nbsp;: ignorer la provenance<\/strong> \u2014 Les fichiers DVC seuls ne sont pas suffisants pour une conformit\u00e9 \u00e9quitable. Si votre \u00e9tablissement a besoin de graphiques de provenance, associez DVC \u00e0 une sortie Prov-JSON (YProv4ml) ou \u00e0 un emballage RO-crate.<\/p>\n<p><strong>Erreur&nbsp;5&nbsp;: Oublier <code>params.yaml<\/code><\/strong> \u2014 Si vous codez en dur les param\u00e8tres de vos scripts au lieu de les isoler dans <code>params.yaml<\/code>, le suivi des param\u00e8tres de DVC devient inutile. Utilisez toujours <code>params.yaml<\/code> pour les param\u00e8tres de simulation.<\/p>\n<h2>R\u00e9sum\u00e9<\/h2>\n<p>DVC transforme les flux de travail scientifiques \u00e0 partir de processus fragiles et d\u00e9pendant de la m\u00e9moire en pipelines d\u00e9terministes et sensibles aux d\u00e9pendances. L'id\u00e9e cl\u00e9 est que <code>dvc.yaml<\/code> les fichiers de pipeline et <code>params.yaml<\/code> l'isolation des param\u00e8tres cr\u00e9ent une \"reproductibilit\u00e9 versionnelle\" - la possibilit\u00e9 de reconstruire non seulement un r\u00e9sultat, mais aussi l'\u00e9tat exp\u00e9rimental exact (data version + code commit + fichier de param\u00e8tre) qui l'a produit. Cela va au-del\u00e0 des conteneurs (qui gelent les environnements de code) et au-del\u00e0 de Git (qui ne peuvent pas g\u00e9rer les grands ensembles de donn\u00e9es).<\/p>\n<p>Pour l'int\u00e9gration de HPC, le wrapper de Slurm <code>srun<\/code> permet l'ex\u00e9cution du pipeline natif du cluster sans intervention manuelle. Pour la provenance, le W3C PROV-JSON (YProv4ml) appara\u00eet comme un format interop\u00e9rable compl\u00e9mentaire \u00e0 l'emballage RO-crate, permettant une lign\u00e9e de donn\u00e9es actionnable qui r\u00e9pond aux exigences de conformit\u00e9 \u00e9quitables.<\/p>\n<p>Le choix entre les biblioth\u00e8ques DVC, DataLad et Prov-Conformes d\u00e9pend de vos mod\u00e8les de flux de travail&nbsp;: DVC pour les exp\u00e9riences orient\u00e9es pipeline, DataLad pour la conservation des donn\u00e9es \u00e0 long terme et les biblioth\u00e8ques Prov pour les graphes de provenance actionnables par la machine. La plupart des \u00e9quipes de simulation b\u00e9n\u00e9ficient de l'utilisation de DVC pour l'ex\u00e9cution du pipeline et de Prov-JSON pour le suivi de la provenance - les deux outils sont compl\u00e9mentaires et non concurrents.<\/p>\n<hr>\n<h2>Guides connexes<\/h2>\n<ul>\n<li><a href=\"\/reproducibility-workflows-beyond-containers-data-versioning-and-provenance-tracking\/\">Reproductibilit\u00e9 au-del\u00e0 des conteneurs<\/a> \u2014 Couvre les bases DVC, les emballages de provenance de la caisse RO et les mod\u00e8les de reproductibilit\u00e9 \u00e0 base de conteneurs<\/li>\n<li><a href=\"https:\/\/matforge.org\/managing-large-scale-pde-problems-strategies-solvers-and-hpc-case-studies\/\">Gestion des probl\u00e8mes de PDE \u00e0 grande \u00e9chelle<\/a> - Discute de la gestion des ressources de cluster et du HPC flux de travail<\/li>\n<li><a href=\"https:\/\/matforge.org\/verification-vs-validation-in-scientific-simulations-a-practical-guide\/\">V\u00e9rification vs validation dans les simulations scientifiques<\/a> - explique le contexte de reproductibilit\u00e9 plus large pour la simulation r\u00e9sultats<\/li>\n<\/ul>\n"},"excerpt":{"rendered":"<p><span class=\"span-reading-time rt-reading-time\" style=\"display: block;\"><span class=\"rt-label rt-prefix\">Reading Time: <\/span> <span class=\"rt-time\"> 21<\/span> <span class=\"rt-label rt-postfix\">minutes<\/span><\/span>Versionnement et provenance des donn\u00e9es Python : DVC, DVC et flux de travail scientifiques Le versioning des donn\u00e9es dans la simulation scientifique ne consiste pas \u00e0 suivre les changements de code &#8211; Git g\u00e8re d\u00e9j\u00e0 cela parfaitement. Il s&rsquo;agit de suivre la combinaison sp\u00e9cifique de fichier de donn\u00e9es, de validation de code et de fichier [&hellip;]<\/p>\n","protected":false,"raw":""},"author":6,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_locale":"fr_FR","_original_post":"https:\/\/matforge.org\/?p=1058","iawp_total_views":4,"footnotes":""},"categories":[1],"tags":[],"class_list":["post-1210","post","type-post","status-publish","format-standard","hentry","category-simulation-modeling-projects","fr-FR"],"yoast_head":"<!-- This site is optimized with the Yoast SEO plugin v28.3 - https:\/\/yoast.com\/product\/yoast-seo-wordpress\/ -->\n<title>Versionnement et provenance des donn\u00e9es Python : DVC, DVC et flux de travail scientifiques - matforge.org<\/title>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/matforge.org\/fr\/python-data-versioning-and-provenance-dvc-dvc-and-scientific-workflows\/\" \/>\n<meta property=\"og:locale\" content=\"fr_FR\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Versionnement et provenance des donn\u00e9es Python : DVC, DVC et flux de travail scientifiques - matforge.org\" \/>\n<meta property=\"og:description\" content=\"Reading Time:  21 minutesVersionnement et provenance des donn\u00e9es Python : DVC, DVC et flux de travail scientifiques Le versioning des donn\u00e9es dans la simulation scientifique ne consiste pas \u00e0 suivre les changements de code &#8211; Git g\u00e8re d\u00e9j\u00e0 cela parfaitement. Il s&rsquo;agit de suivre la combinaison sp\u00e9cifique de fichier de donn\u00e9es, de validation de code et de fichier [&hellip;]\" \/>\n<meta property=\"og:url\" content=\"https:\/\/matforge.org\/fr\/python-data-versioning-and-provenance-dvc-dvc-and-scientific-workflows\/\" \/>\n<meta property=\"og:site_name\" content=\"matforge.org\" \/>\n<meta property=\"article:published_time\" content=\"2026-08-21T14:28:51+00:00\" \/>\n<meta name=\"author\" content=\"steven\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"\u00c9crit par\" \/>\n\t<meta name=\"twitter:data1\" content=\"steven\" \/>\n\t<meta name=\"twitter:label2\" content=\"Dur\u00e9e de lecture estim\u00e9e\" \/>\n\t<meta name=\"twitter:data2\" content=\"35 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\\\/\\\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\\\/\\\/matforge.org\\\/fr\\\/python-data-versioning-and-provenance-dvc-dvc-and-scientific-workflows\\\/#article\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/matforge.org\\\/fr\\\/python-data-versioning-and-provenance-dvc-dvc-and-scientific-workflows\\\/\"},\"author\":{\"name\":\"steven\",\"@id\":\"https:\\\/\\\/matforge.org\\\/#\\\/schema\\\/person\\\/8f690fb596d657b12994b83caa788f03\"},\"headline\":\"Versionnement et provenance des donn\u00e9es Python : DVC, DVC et flux de travail scientifiques\",\"datePublished\":\"2026-08-21T14:28:51+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\\\/\\\/matforge.org\\\/fr\\\/python-data-versioning-and-provenance-dvc-dvc-and-scientific-workflows\\\/\"},\"wordCount\":6262,\"commentCount\":0,\"articleSection\":[\"Simulation &amp; Projets de mod\u00e9lisation\"],\"inLanguage\":\"fr-FR\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\\\/\\\/matforge.org\\\/fr\\\/python-data-versioning-and-provenance-dvc-dvc-and-scientific-workflows\\\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/matforge.org\\\/fr\\\/python-data-versioning-and-provenance-dvc-dvc-and-scientific-workflows\\\/\",\"url\":\"https:\\\/\\\/matforge.org\\\/fr\\\/python-data-versioning-and-provenance-dvc-dvc-and-scientific-workflows\\\/\",\"name\":\"Versionnement et provenance des donn\u00e9es Python : DVC, DVC et flux de travail scientifiques - matforge.org\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/matforge.org\\\/#website\"},\"datePublished\":\"2026-08-21T14:28:51+00:00\",\"author\":{\"@id\":\"https:\\\/\\\/matforge.org\\\/#\\\/schema\\\/person\\\/8f690fb596d657b12994b83caa788f03\"},\"breadcrumb\":{\"@id\":\"https:\\\/\\\/matforge.org\\\/fr\\\/python-data-versioning-and-provenance-dvc-dvc-and-scientific-workflows\\\/#breadcrumb\"},\"inLanguage\":\"fr-FR\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\\\/\\\/matforge.org\\\/fr\\\/python-data-versioning-and-provenance-dvc-dvc-and-scientific-workflows\\\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\\\/\\\/matforge.org\\\/fr\\\/python-data-versioning-and-provenance-dvc-dvc-and-scientific-workflows\\\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\\\/\\\/matforge.org\\\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Versionnement et provenance des donn\u00e9es Python : DVC, DVC et flux de travail scientifiques\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\\\/\\\/matforge.org\\\/#website\",\"url\":\"https:\\\/\\\/matforge.org\\\/\",\"name\":\"matforge.org\",\"description\":\"\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\\\/\\\/matforge.org\\\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"fr-FR\"},{\"@type\":\"Person\",\"@id\":\"https:\\\/\\\/matforge.org\\\/#\\\/schema\\\/person\\\/8f690fb596d657b12994b83caa788f03\",\"name\":\"steven\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"fr-FR\",\"@id\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/d46cfcd83a298f27e8d66bfa035514fefca7652f26bd3ef7402f82b68a41ec0f?s=96&d=mm&r=g\",\"url\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/d46cfcd83a298f27e8d66bfa035514fefca7652f26bd3ef7402f82b68a41ec0f?s=96&d=mm&r=g\",\"contentUrl\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/d46cfcd83a298f27e8d66bfa035514fefca7652f26bd3ef7402f82b68a41ec0f?s=96&d=mm&r=g\",\"caption\":\"steven\"},\"url\":\"https:\\\/\\\/matforge.org\\\/author\\\/steven\\\/\"}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"Versionnement et provenance des donn\u00e9es Python : DVC, DVC et flux de travail scientifiques - matforge.org","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/matforge.org\/fr\/python-data-versioning-and-provenance-dvc-dvc-and-scientific-workflows\/","og_locale":"fr_FR","og_type":"article","og_title":"Versionnement et provenance des donn\u00e9es Python : DVC, DVC et flux de travail scientifiques - matforge.org","og_description":"Reading Time:  21 minutesVersionnement et provenance des donn\u00e9es Python : DVC, DVC et flux de travail scientifiques Le versioning des donn\u00e9es dans la simulation scientifique ne consiste pas \u00e0 suivre les changements de code &#8211; Git g\u00e8re d\u00e9j\u00e0 cela parfaitement. Il s&rsquo;agit de suivre la combinaison sp\u00e9cifique de fichier de donn\u00e9es, de validation de code et de fichier [&hellip;]","og_url":"https:\/\/matforge.org\/fr\/python-data-versioning-and-provenance-dvc-dvc-and-scientific-workflows\/","og_site_name":"matforge.org","article_published_time":"2026-08-21T14:28:51+00:00","author":"steven","twitter_card":"summary_large_image","twitter_misc":{"\u00c9crit par":"steven","Dur\u00e9e de lecture estim\u00e9e":"35 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/matforge.org\/fr\/python-data-versioning-and-provenance-dvc-dvc-and-scientific-workflows\/#article","isPartOf":{"@id":"https:\/\/matforge.org\/fr\/python-data-versioning-and-provenance-dvc-dvc-and-scientific-workflows\/"},"author":{"name":"steven","@id":"https:\/\/matforge.org\/#\/schema\/person\/8f690fb596d657b12994b83caa788f03"},"headline":"Versionnement et provenance des donn\u00e9es Python : DVC, DVC et flux de travail scientifiques","datePublished":"2026-08-21T14:28:51+00:00","mainEntityOfPage":{"@id":"https:\/\/matforge.org\/fr\/python-data-versioning-and-provenance-dvc-dvc-and-scientific-workflows\/"},"wordCount":6262,"commentCount":0,"articleSection":["Simulation &amp; Projets de mod\u00e9lisation"],"inLanguage":"fr-FR","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/matforge.org\/fr\/python-data-versioning-and-provenance-dvc-dvc-and-scientific-workflows\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/matforge.org\/fr\/python-data-versioning-and-provenance-dvc-dvc-and-scientific-workflows\/","url":"https:\/\/matforge.org\/fr\/python-data-versioning-and-provenance-dvc-dvc-and-scientific-workflows\/","name":"Versionnement et provenance des donn\u00e9es Python : DVC, DVC et flux de travail scientifiques - matforge.org","isPartOf":{"@id":"https:\/\/matforge.org\/#website"},"datePublished":"2026-08-21T14:28:51+00:00","author":{"@id":"https:\/\/matforge.org\/#\/schema\/person\/8f690fb596d657b12994b83caa788f03"},"breadcrumb":{"@id":"https:\/\/matforge.org\/fr\/python-data-versioning-and-provenance-dvc-dvc-and-scientific-workflows\/#breadcrumb"},"inLanguage":"fr-FR","potentialAction":[{"@type":"ReadAction","target":["https:\/\/matforge.org\/fr\/python-data-versioning-and-provenance-dvc-dvc-and-scientific-workflows\/"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/matforge.org\/fr\/python-data-versioning-and-provenance-dvc-dvc-and-scientific-workflows\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/matforge.org\/"},{"@type":"ListItem","position":2,"name":"Versionnement et provenance des donn\u00e9es Python : DVC, DVC et flux de travail scientifiques"}]},{"@type":"WebSite","@id":"https:\/\/matforge.org\/#website","url":"https:\/\/matforge.org\/","name":"matforge.org","description":"","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/matforge.org\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"fr-FR"},{"@type":"Person","@id":"https:\/\/matforge.org\/#\/schema\/person\/8f690fb596d657b12994b83caa788f03","name":"steven","image":{"@type":"ImageObject","inLanguage":"fr-FR","@id":"https:\/\/secure.gravatar.com\/avatar\/d46cfcd83a298f27e8d66bfa035514fefca7652f26bd3ef7402f82b68a41ec0f?s=96&d=mm&r=g","url":"https:\/\/secure.gravatar.com\/avatar\/d46cfcd83a298f27e8d66bfa035514fefca7652f26bd3ef7402f82b68a41ec0f?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/d46cfcd83a298f27e8d66bfa035514fefca7652f26bd3ef7402f82b68a41ec0f?s=96&d=mm&r=g","caption":"steven"},"url":"https:\/\/matforge.org\/author\/steven\/"}]}},"_links":{"self":[{"href":"https:\/\/matforge.org\/wp-json\/wp\/v2\/posts\/1210","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/matforge.org\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/matforge.org\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/matforge.org\/wp-json\/wp\/v2\/users\/6"}],"replies":[{"embeddable":true,"href":"https:\/\/matforge.org\/wp-json\/wp\/v2\/comments?post=1210"}],"version-history":[{"count":1,"href":"https:\/\/matforge.org\/wp-json\/wp\/v2\/posts\/1210\/revisions"}],"predecessor-version":[{"id":1380,"href":"https:\/\/matforge.org\/wp-json\/wp\/v2\/posts\/1210\/revisions\/1380"}],"wp:attachment":[{"href":"https:\/\/matforge.org\/wp-json\/wp\/v2\/media?parent=1210"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/matforge.org\/wp-json\/wp\/v2\/categories?post=1210"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/matforge.org\/wp-json\/wp\/v2\/tags?post=1210"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}