JupyterLab 4.6.4 : que faire si l’accès au Mac distant échoue ? 2026

La page JupyterLab reste blanche ou le navigateur signale que le site est inaccessible.

Pour un accès individuel, gardez le Jupyter Server limité à l’adresse locale du Mac distant et passez par un tunnel SSH ; ne désactivez pas l’authentification et n’exposez pas directement un serveur sans protection. Pour un usage collectif, évaluez une architecture multiutilisateur au lieu de partager un seul serveur personnel.

Ce guide s’adresse aux étudiantes et étudiants dont le laboratoire n’a pas de Mac et qui doivent exécuter des analyses ou des projets de cours dans macOS. Il concerne aussi les chercheurs confrontés à une erreur d’accès ou à une interruption, ainsi que les personnes chargées du support technique d’un groupe de recherche.

Dernière vérification : 30 septembre 2026, d’après la documentation stable de JupyterLab, les références officielles de Jupyter Server et les documents OpenSSH cités ci-dessous.

Avant de modifier la configuration, identifiez l’endroit où la connexion échoue

Une page qui ne s’affiche pas ne signifie pas forcément que le calcul scientifique a échoué. Il faut séparer trois éléments : le navigateur, qui affiche l’interface ; le processus Jupyter Server, qui fournit cette interface ; et le noyau, qui exécute le code du notebook. Ces composants peuvent se trouver à des endroits différents. Avec un Mac distant, le serveur et le noyau fonctionnent sur le Mac, tandis que le navigateur est généralement ouvert sur l’ordinateur du laboratoire.

Le premier indice est l’adresse saisie dans le navigateur. Une adresse locale ouverte sur le poste Windows ou Linux ne vise pas automatiquement le Mac distant. Elle peut correspondre à un service lancé sur l’ordinateur de laboratoire, ou à aucun service. À l’inverse, un navigateur qui affiche la page de connexion a déjà atteint une partie du service : l’erreur peut alors porter sur l’authentification plutôt que sur l’accès réseau.

Avant toute modification, consignez l’adresse utilisée, le texte intégral de l’erreur, la méthode de connexion et l’heure approximative de l’incident. Ne copiez pas un lien contenant un jeton dans un ticket public ou un canal partagé. Ce lien peut inclure un secret d’accès.

Sur le Mac distant, vérifiez d’abord si le processus répond localement. La commande ci-dessous interroge le service depuis la machine où il s’exécute :

jupyter server list

La sortie doit indiquer les serveurs connus de l’utilisateur et leurs adresses d’accès. Si aucun serveur n’apparaît, ou si le processus s’est arrêté, le navigateur ne peut pas corriger ce problème. Si le serveur est listé, mais que l’accès distant échoue, poursuivez le diagnostic côté réseau. La documentation de JupyterLab et de son lancement permet de vérifier les instructions officielles correspondant à la version installée. La version 4.6.4 figure dans la documentation stable de référence au moment de la vérification.

Pour déterminer si le défaut est côté service ou côté liaison, comparez le résultat obtenu sur le Mac avec celui du navigateur de laboratoire. Une réponse locale positive, suivie d’un échec depuis le poste client, oriente vers l’adresse d’écoute, le tunnel, un mandataire réseau ou un filtrage institutionnel. Une absence de réponse locale oriente plutôt vers le processus, sa configuration ou ses journaux. Évitez de changer plusieurs paramètres à la fois : sinon, le test suivant ne permet plus d’identifier la cause.

Si le Mac répond localement, vérifiez l’écoute avant d’ouvrir le réseau

Jupyter Server peut être actif sans accepter les connexions directes provenant d’autres machines. Une écoute limitée à l’adresse locale est une mesure de protection, pas la preuve d’un démarrage incomplet. Pour un accès individuel, c’est généralement le comportement à conserver : le poste client passe par un tunnel SSH, qui transporte la connexion sans rendre l’interface accessible à tout le réseau.

Le serveur n’écoute que sur l’adresse locale : comment le poste de laboratoire peut-il le joindre ?

En créant un tunnel SSH entre le poste de laboratoire et le Mac distant, le navigateur peut atteindre le service local du Mac par le port local du poste. Le transfert de port est une fonction documentée d’OpenSSH ; les options exactes doivent correspondre au nom d’hôte et au compte autorisés dans votre environnement.

L’exemple suivant suppose que Jupyter Server écoute sur le port 8888, valeur de configuration à confirmer dans les références officielles des paramètres de Jupyter Server. Le port doit être remplacé si votre serveur utilise une autre valeur.

ssh -N -L 8888:localhost:8888 nom_utilisateur@mac-distant

L’option -L demande à SSH de transférer un port local vers une adresse et un port du côté distant ; le manuel OpenSSH décrit le transfert de ports. Gardez cette session ouverte pendant le test. Dans le navigateur du poste client, ouvrez ensuite l’adresse locale associée au port transféré, par exemple http://localhost:8888, puis fournissez le moyen d’authentification attendu par le serveur. Le nom mac-distant est un exemple à remplacer par l’adresse réellement fournie par l’administrateur.

Si le tunnel ne s’établit pas, n’essayez pas encore de modifier Jupyter. Vérifiez séparément que le poste client atteint le Mac par SSH, que le compte est autorisé et que le nom d’hôte est correct. Si la connexion SSH fonctionne, mais que la page reste inaccessible, contrôlez la valeur du port local, le port d’écoute du serveur et l’adresse saisie dans le navigateur. Un tunnel actif vers le mauvais port ne rend pas JupyterLab accessible.

Ne remplacez pas automatiquement l’écoute locale par une écoute sur toutes les interfaces réseau. Cela peut contourner le symptôme tout en exposant le service à des connexions non souhaitées. La documentation de sécurité de Jupyter Server avertit des risques liés à l’accès public à un serveur individuel. Si un tunnel SSH n’est pas autorisé ou praticable sur le réseau du laboratoire, demandez à l’équipe informatique quelle voie d’accès est approuvée.

Comparez les méthodes de connexion selon le risque et le besoin

Le choix ne se résume pas à « ouvrir le port ou non ». Il dépend du nombre d’utilisateurs, des règles réseau et de la manière dont les données sont traitées. Le tableau compare les options de diagnostic et d’accès ; il ne remplace pas la politique de sécurité de l’établissement.

Cette comparaison évite deux erreurs fréquentes. La première consiste à traiter une restriction réseau comme un défaut de Jupyter. La seconde consiste à considérer qu’un accès techniquement possible est nécessairement autorisé pour des données de recherche. Un tunnel chiffre et transporte une connexion ; il ne constitue pas une validation de la conformité du projet.

Quand l’interface apparaît, distinguez le jeton du problème de navigateur

Une page de connexion ou une redirection répétée indique que le navigateur atteint probablement une interface, mais ne prouve pas que l’authentification est correcte. Jupyter Server utilise l’authentification par jeton par défaut selon sa documentation officielle de sécurité. Une configuration peut toutefois avoir été modifiée ; vérifiez donc l’état réel du serveur au lieu de supposer que tous les environnements fonctionnent de la même façon.

Le tunnel SSH est établi, mais JupyterLab refuse l’accès : que contrôler ?

Sur le Mac, récupérez les informations d’accès à partir de la commande de liste des serveurs et des journaux disponibles. Vérifiez si l’adresse correspond au processus actuellement lancé. Un jeton affiché auparavant peut ne plus être valide si le serveur a redémarré ou si son état a changé. N’utilisez pas un ancien lien enregistré dans l’historique du navigateur sans vérifier qu’il correspond encore au serveur actif.

Il faut également distinguer quatre cas : un jeton absent ou incorrect ; un jeton périmé ; une configuration par mot de passe ; et un problème de session du navigateur. Essayez l’adresse locale qui passe par le tunnel dans une fenêtre privée, sans diffuser l’URL d’accès. Si cette fenêtre accepte l’authentification alors que la session habituelle boucle, le problème peut provenir de cookies ou d’un état de session conservé. Si le refus persiste, confrontez les journaux du serveur avec la méthode d’authentification configurée.

Ne désactivez pas l’authentification pour « voir si la page s’ouvre ». Cette expérience peut transformer un problème de connexion en exposition du service. La documentation sur les serveurs Jupyter accessibles publiquement explique pourquoi un serveur individuel ne doit pas être traité comme une application publique prête à accueillir des utilisateurs. Après correction, refaites un essai avec une authentification active ; un affichage réussi sans contrôle d’identité n’est pas un test d’accès satisfaisant.

Les paramètres de chemins, de mandataire ou de chiffrement peuvent aussi produire des redirections incohérentes. Si l’accès passe par une URL institutionnelle ou un mandataire inverse, vérifiez que le chemin demandé correspond bien à la configuration du service. Pour HTTPS, l’adresse utilisée par le navigateur et le certificat présenté doivent être cohérents. Consultez la documentation officielle correspondant à cette architecture ; une règle de port universelle ne peut pas convenir à tous les réseaux de campus.

Si l’erreur indique une connexion interrompue, comparez le moment de l’incident aux journaux du serveur et à l’état du tunnel. Une perte du tunnel, une fermeture de session SSH ou une interruption imposée par le réseau ne signifie pas nécessairement que le noyau de calcul a cessé d’exister. Avant de relancer le serveur, vérifiez si le processus répond encore et si le notebook a conservé ses modifications. Pour un mandataire ou un pare-feu institutionnel, faites confirmer par l’administrateur le chemin autorisé plutôt que d’essayer des ouvertures de ports sans rapport avec le plan réseau.

Pour un groupe, un serveur personnel ne remplace pas une architecture multiutilisateur

Un serveur utilisé par une seule personne et un service destiné à tout un laboratoire ne sont pas interchangeables. Avec un serveur personnel partagé, plusieurs personnes peuvent se retrouver à utiliser le même contexte de fichiers, à modifier des ressources communes ou à perturber un noyau en cours d’exécution. La présence d’une page accessible aux membres du groupe ne crée pas automatiquement des comptes distincts ni une séparation des espaces de travail.

Pour un besoin collectif, évaluez une plateforme qui gère les identités et les serveurs individuels. JupyterHub décrit le fonctionnement de ses serveurs utilisateur, tandis que sa documentation de sécurité des applications et des utilisateurs précise les enjeux de séparation. Cela ne signifie pas que JupyterHub convient à chaque laboratoire : l’hébergement, l’administration, les mises à jour et les règles de l’établissement doivent être évalués.

Avant d’inviter d’autres personnes sur un environnement, clarifiez qui peut lire les fichiers, arrêter des processus ou consulter les sorties de notebook. Déterminez aussi si chaque personne a besoin de son propre noyau et si les données peuvent être copiées sur la machine concernée. Une connexion distante n’est pas une preuve que le traitement répond aux règles de l’université. Les données sensibles, les jeux de données sous accord ou les résultats non publiés nécessitent l’approbation des responsables compétents.

Validez le parcours complet avec une tâche scientifique minimale

Une page qui se charge ne suffit pas à certifier un environnement de recherche. Le test doit vérifier l’accès, l’identité, le noyau, l’enregistrement et le comportement après une interruption. Choisissez un notebook reproductible et non sensible. Il peut contenir une cellule de calcul simple, une lecture d’un fichier de test et l’enregistrement d’un résultat dans un dossier prévu à cet effet.

Procédez dans cet ordre :

• Sur le Mac, confirmez que Jupyter Server fonctionne et notez la méthode d’authentification active.
• Depuis le poste Windows ou Linux, établissez le tunnel SSH ou le trajet approuvé par l’établissement.
• Ouvrez l’adresse correspondant au tunnel et confirmez que l’authentification est bien demandée.
• Lancez le noyau, exécutez une cellule déterministe et vérifiez que le résultat apparaît dans le navigateur.
• Enregistrez le notebook, contrôlez que le fichier existe à l’emplacement prévu sur le Mac, puis rouvrez-le.
• Fermez proprement le navigateur ou le tunnel, reconnectez-vous et vérifiez l’état du fichier et du noyau avant de reprendre le travail.

Conservez un relevé utile au dépannage : adresse d’accès sans secret, méthode de connexion, état du processus, résultat du test du noyau et emplacement du fichier. N’ajoutez pas le jeton, un mot de passe ou des données de recherche à un journal partagé. Si le test échoue, consignez l’étape exacte qui échoue et arrêtez-vous à cette couche. Par exemple, un notebook qui s’exécute localement sur le Mac mais pas après connexion distante appelle une enquête sur le tunnel ou l’interface, pas une réinstallation immédiate de l’environnement scientifique.

Si la page ne s’ouvre pas, quel contrôle faut-il faire en premier ?

Vérifiez d’abord que Jupyter Server est actif sur le Mac et notez l’adresse affichée par la commande de liste des serveurs. Si le service répond localement, comparez ensuite l’adresse du navigateur et le chemin réseau. Si le service ne répond pas sur le Mac lui-même, traitez le démarrage ou la configuration avant le tunnel.

Le serveur est limité à l’adresse locale : faut-il l’exposer au réseau du laboratoire ?

Pas par défaut. Pour un usage individuel, un tunnel SSH permet de conserver une écoute locale, sous réserve que le réseau et les règles de l’établissement autorisent SSH. Si cette voie est bloquée, demandez à l’équipe informatique de définir une méthode approuvée plutôt que d’ouvrir toutes les interfaces.

Un tunnel établi garantit-il que le jeton est encore valable ?

Non. Le tunnel confirme seulement qu’un chemin de transport a été établi ; il ne valide ni le jeton, ni la session du navigateur, ni la configuration du serveur. Consultez l’état courant du service et vérifiez sa méthode d’authentification sans publier les informations d’accès.

Plusieurs membres du groupe peuvent-ils partager le même serveur personnel ?

Une page accessible à plusieurs personnes ne fournit pas, à elle seule, des identités séparées, des espaces isolés ou des noyaux indépendants. Pour un travail réellement collectif, évaluez une plateforme multiutilisateur et faites approuver le traitement des données par l’établissement. Un serveur personnel exposé à un groupe ne doit pas être considéré comme un service partagé sécurisé.

Pour des analyses isolées, une session personnelle peut suffire si le chemin de connexion, l’authentification et la sauvegarde ont été testés. Pour une équipe qui a besoin de comptes séparés, de ressources partagées ou de règles de données précises, le bon choix est une plateforme institutionnelle conçue pour ce fonctionnement. Si l’environnement de recherche nécessite réellement macOS et que le laboratoire ne dispose pas de Mac, un Mac distant peut éviter l’achat immédiat d’une machine, mais il ne résout pas à lui seul les restrictions de réseau, les contraintes de conformité ou le besoin d’administration collective. La page des options de Mac distant de SFTPMAC et les informations tarifaires de SFTPMAC permettent d’examiner les modalités disponibles avant de décider.

Le recours à un Mac loué est donc à envisager si le projet a besoin d’un environnement macOS ponctuel ou pour une période définie, et si l’accès distant satisfait le test minimal décrit ici. Il est moins adapté à un calcul lourd et continu qui exige une machine dédiée, à un protocole nécessitant des interfaces physiques locales ou à un groupe qui doit partager des données sans cadre d’administration validé. En revanche, si l’alternative actuelle impose de dépendre d’un poste personnel rarement disponible, de transférer constamment des fichiers entre systèmes ou d’abandonner les tests propres à macOS, un environnement distant peut simplifier le parcours de travail. Avant de retenir cette solution, validez l’authentification, l’enregistrement des notebooks et les règles de traitement des données avec le responsable du projet.