Jupyter : bonnes pratiques stockage/volumes (datasets, notebooks, backups)

Jupyter : bonnes pratiques stockage/volumes (datasets, carnets (.ipynb), backups)

Quand on déploie Jupyter en production, le vrai sujet n’est pas juste d’ouvrir un carnet (.ipynb) : c’est de ne jamais perdre ses carnets (.ipynb), datasets, modèles, exports et logs utiles. Avec Docker, c’est rapide à lancer… mais si vous stockez au mauvais endroit, un docker rm peut effacer votre travail.

Dans ce guide, on voit une approche simple et robuste pour :

• rendre le stockage persistant (carnets (.ipynb) + données),
• structurer vos dossiers (datasets vs carnets (.ipynb) vs sorties),
• gérer les permissions pour éviter les erreurs “Permission denied”,
• mettre en place des sauvegardes restaurables,
• et industrialiser ça proprement sur adgents.cloud (backups automatiques + rétention).

Pour le déploiement complet (HTTPS + auth + persistance), voir : [Déployer Jupyter en production : HTTPS, auth, stockage persistant](https://www.adgents.cloud/articles/deployer-jupyter-carnet (.ipynb)-production-https-auth-stockage-persistant).

1) Comprendre ce qui doit être persistant (et ce qui peut rester éphémère)

Avant de choisir un volume, listez clairement ce que vous voulez conserver :

À rendre persistant (recommandé)

• carnets (.ipynb) (.ipynb) et scripts (.py)
• Datasets (CSV/Parquet), assets, fichiers d’entrée
• Environnements applicatifs si vous les externalisez (ex: requirements.txt, environment.yml)
• Exports (rapports, figures, artefacts)

Peut rester éphémère

• Caches temporaires (pip, apt)
• Fichiers de travail non critiques

Sur adgents.cloud, la persistance se gère très bien avec des volumes + des backups automatiques : vous bénéficiez en plus d’une vraie stratégie “filet de sécurité” (rétention longue, restauration).

Lien utile pour sécuriser l’accès : [Sécuriser Jupyter : users, tokens, isolation, accès réseau (guide 2026)](https://www.adgents.cloud/articles/securiser-jupyter-carnet (.ipynb)-users-tokens-isolation-reseau-2026).

2) Choisir la bonne stratégie de volume : bind mount vs volume Docker

Vous avez deux options courantes :

Option A — Bind mount (répertoire hôte monté dans le conteneur)

Avantages : simple à comprendre, visible côté hôte, facile à sauvegarder. Inconvénients : attention aux permissions et aux chemins selon l’OS.

Exemple Docker (conceptuel) :

• Hôte : /data/jupyter
• Conteneur : /home/jovyan/work

Option B — Volume Docker “nommé”

Avantages : plus propre/portable, géré par Docker. Inconvénients : moins “visible” sans commandes Docker, sauvegardes à penser (export).

Pour une mise en production stable (et si vous voulez la simplicité), une bonne base est :

• un volume “work” pour carnets (.ipynb)/projets,
• un volume “data” pour datasets lourds,
• éventuellement un volume “outputs” pour exports.

Référence utile (documentation Docker) : Docker guide Jupyter (volumes).

3) Une organisation de dossiers qui évite le chaos

Une arborescence simple (et très efficace) :

• work/ : carnets (.ipynb), code, README
• data/ : datasets bruts + intermédiaires
• outputs/ : exports (CSV, images, PDF), modèles

Pourquoi c’est important :

• vous pouvez appliquer des règles de sauvegarde différentes (ex: outputs très fréquent, data moins fréquent si re-téléchargeable),
• vous maîtrisez les droits d’accès,
• vous facilitez la reprise par un collègue.

Sur adgents.cloud, vous pouvez garder ce modèle et ajouter un environnement “staging” pour tester (voir la page application : Jupyter sur adgents.cloud).

4) Permissions : l’erreur n°1 quand on monte des volumes

Le symptôme classique :

• Jupyter démarre, mais vous ne pouvez pas enregistrer un carnet (.ipynb)
• ou les cellules qui écrivent sur disque échouent

La cause : UID/GID de l’utilisateur qui exécute Jupyter dans le conteneur ≠ propriétaire du répertoire monté.

Bonnes pratiques :

• évitez de faire tourner Jupyter en root en production
• alignez les permissions du répertoire monté avec l’utilisateur du conteneur
• documentez la règle dans votre repo (README)

Pour une approche “production”, gardez aussi un reverse proxy et une auth robuste : [Sécuriser Jupyter (guide 2026)](https://www.adgents.cloud/articles/securiser-jupyter-carnet (.ipynb)-users-tokens-isolation-reseau-2026).

5) Backups : ce qui marche vraiment (et ce qui rassure à tort)

Une sauvegarde utile doit répondre à 2 questions :

• RPO : quelle perte de données maximale acceptable ?
• RTO : en combien de temps vous devez être de nouveau opérationnel ?

La méthode robuste

1. Sauvegarder le(s) volume(s) persistants
2. Versionner la config (compose / variables)
3. Tester une restauration régulièrement

Sur adgents.cloud, vous avez un avantage immédiat :

• backups automatiques (jusqu’à 1/h selon configuration)
• rétention longue (jusqu’à 10 ans)
• restauration simplifiée

Si vous partez de zéro, commencez par déployer correctement : [Déployer Jupyter en production](https://www.adgents.cloud/articles/deployer-jupyter-carnet (.ipynb)-production-https-auth-stockage-persistant).

6) Vidéo (FR) : comprendre les volumes persistants

Pour bien visualiser la différence entre conteneur et données persistantes :

7) Le “minimum viable” pour être serein

Si vous voulez une baseline simple et saine :

• 2 volumes : work (projet) + data (datasets)
• 1 répertoire outputs (dans work ou volume dédié)
• un reverse proxy + auth
• backups automatiques + une restauration testée

Si vous voulez aller vite, sans vous battre avec l’infra : essayez adgents.cloud (déploiement en 1 clic, facturation à l’heure, stop/start, backups automatiques et rétention longue).

➡️ Page application : Héberger Jupyter sur adgents.cloud