Marie a le notebook qui « marche chez elle ». Thomas l'ouvre : le kernel plante — mémoire insuffisante, version de pandas différente, chemin /Users/marie/... codé en dur. Le CTO découvre un export clients dans un dépôt Git public. Jupyter en équipe, ce n'est pas envoyer un fichier .ipynb par Slack : c'est une plateforme avec identité, ressources et gouvernance.
Un notebook local sur 32 Go de RAM n'est pas une infrastructure d'équipe. Dès que trois personnes partagent des données, des GPU ou des environnements réglementés, il faut centraliser l'authentification, isoler les ressources et tracer les accès. Mal déployé, JupyterHub devient un VPS où tout le monde a les mêmes droits. Bien déployé, c'est le pont entre exploration et pipelines de production.
Architecture minimale viable
Une installation d'équipe repose sur quelques composants non négociables :
| Composant | Rôle |
|---|---|
| JupyterHub | Connexion SSO/LDAP, lancement d'un notebook par utilisateur |
| Spawner | Docker ou Kubernetes — image reproductible |
| Stockage persistant | Espace par utilisateur ou par projet, pas disque éphémère seul |
| Secrets | Coffre-fort ou variables d'environnement injectées — jamais de clés API dans le notebook |
| Quota ressources | CPU, RAM, GPU maximum par utilisateur ou groupe |
L'hébergement varie selon la charge : VPS solide pour l'exploration CPU, machine GPU pour l'entraînement (voir location GPU), ou Kubernetes si l'équipe maîtrise déjà l'orchestration. Comparez les offres avec accès GPU et régions UE via l'annuaire et le comparateur.
Partage sans fuite de données
Versionnez les notebooks dans Git, mais strippez les outputs avant chaque commit (nbstripout ou hook pre-commit). Un notebook exporté avec des données clients en clair dans une cellule est une fuite RGPD en attente.
Limitez l'accès aux données : rôles lecture seule sur les bases de production, vues anonymisées, pas de dump complet « pour tester ». Désactivez le téléchargement massif si les données sont sensibles ; journalisez les exports avec horodatage et identité utilisateur.
Coupez les kernels inactifs (idle culler) pour libérer GPU et RAM — un notebook oublié ouvert depuis vendredi ne doit pas bloquer la file d'attente de l'équipe.
Pour les LLM internes, ne mélangez pas prompts confidentiels et notebooks partagés — voir héberger un LLM.
Erreurs fréquentes qui accélèrent le shadow IT
Quatre patterns reviennent dans presque chaque post-mortem :
- Un seul compte SSH partagé — même problème que l'accès SFTP équipe : personne n'est responsable, tout le monde est root.
- Notebook = production — un cron qui exécute un
.ipynbnon testé la nuit remplace une pipeline sans observabilité. - GPU allumé 24 h/24 pour de l'exploration pandas qui n'utilise que le CPU.
- Pas de sauvegarde du répertoire utilisateur sur un disque local unique.
Chacune de ces erreurs se corrige sans interdire Jupyter — en appliquant les mêmes exigences qu'à une API : identité, journaux, limites.
GPU, quotas et coût maîtrisé
Rarement faut-il un GPU par data scientist. JupyterHub planifie les jobs, applique des quotas par groupe, et libère la ressource après inactivité. Réservez les instances GPU coûteuses à l'entraînement lourd ; l'exploration de données (EDA) tourne souvent très bien en CPU.
Pour le training intensif, les instances spot ou à la demande complètent le Hub sans immobiliser du matériel 24 h/24. Documentez qui peut lancer un job GPU, combien de temps maximum, et comment alerter si la file dépasse un seuil.
Le sommet : Jupyter partagé sans gouvernance = shadow IT accéléré
Voici ce que l'enthousiasme pour les notebooks oublie de formaliser.
Comparez les hébergeurs avec accès GPU et hébergement en région UE sur l'annuaire avant d'acheter du matériel « pour Jupyter ».
Décider et avancer sans angle mort
Avant d'acheter un GPU ou de déployer un Hub :
- Comptez combien de notebooks doivent tourner simultanément, sur quelles données, avec quelle traçabilité.
- Choisissez JupyterHub + Docker dès que trois data users réguliers partagent ressources ou données réglementées.
- Fixez une image de base verrouillée et une politique Git (outputs stripés avant commit).
- Configurez des quotas CPU/RAM/GPU et un arrêt automatique des kernels inactifs.
- Auditez l'accès aux données comme pour tout système sensible — journaux, rôles, région UE.
- Testez la restauration du stockage persistant utilisateur avant de confier des datasets critiques.
Sans réponse claire à la première question, vous financez du chaos — pas de la science.
Questions fréquentes
JupyterLab local ou JupyterHub hébergé ?
Local pour l'exploration solo. Hub hébergé dès que plusieurs personnes partagent GPU, données réglementées ou besoin de traçabilité — sinon chacun copie des CSV par courriel et les versions divergent en une semaine.
Comment éviter qu'un notebook écrase la prod ?
Séparez les environnements (données de staging), accès base en lecture seule par défaut, secrets hors notebook (coffre-fort, variables d'environnement), revue obligatoire avant tout job planifié en cron.
Faut-il un GPU par data scientist ?
Rarement. Planification Hub, quotas GPU, instances spot pour l'entraînement lourd — le CPU suffit pour la majorité de l'exploration de données. Voir notre guide location GPU.
Notebooks et RGPD : quelles précautions ?
Pas de données personnelles en clair dans les cellules exportées, journaux d'accès, hébergement en région UE, purge des outputs committés par erreur dans Git. Traitez un notebook comme un document sensible, pas comme un brouillon jetable.
Avant d'acheter un GPU « pour Jupyter », demandez : combien de notebooks doivent tourner en même temps, sur quelles données, avec quelle trace ? Sans réponse, vous financez du chaos — pas de la science.