Que faire si JupyterLab 4.6 ne trouve pas le noyau Python en 2026 ?

Noyau Python absent ou incorrect dans JupyterLab 4.6 → vérifiez d’abord l’environnement Python du service, puis installez et enregistrez ipykernel depuis l’environnement voulu. Ne réinstallez pas JupyterLab avant d’avoir contrôlé la liste des noyaux et l’interpréteur réellement exécuté.

Cet article s’adresse aux étudiants dont la liste des noyaux est vide ou ne contient pas l’environnement attendu.
Les chercheurs qui ont changé de version Python ou d’environnement virtuel peuvent vérifier si leur Notebook utilise encore l’ancien interpréteur.
Les personnes chargées de maintenir des Mac d’analyse en laboratoire y trouveront une méthode de diagnostic et une trace de validation à conserver.

JupyterLab et le noyau Python : des composants distincts

Une page JupyterLab peut s’ouvrir même si le noyau Python d’un projet n’est pas disponible. L’interface, le service qui la fournit et le programme Python exécuté par le Notebook sont liés, mais ne désignent pas le même environnement. Le noyau choisi dans le Notebook est un processus lancé à partir d’une définition appelée kernelspec.

Il faut donc distinguer plusieurs états :

• le service JupyterLab démarre et affiche l’interface ;
• le service dispose d’une liste de noyaux enregistrés ;
• un Notebook sélectionne l’un de ces noyaux ;
• le processus du noyau démarre avec le Python attendu ;
• le code trouve les dépendances nécessaires à l’analyse.

Une réussite à une étape ne confirme pas automatiquement les suivantes. En particulier, saisir python dans un terminal et obtenir une version ne signifie pas que JupyterLab a découvert ou enregistré cet interpréteur. La documentation de JupyterLab sur les documents et les noyaux décrit la sélection et l’utilisation d’un noyau depuis un Notebook.

Avant toute modification, notez la manière dont le service a été démarré, la version affichée et l’environnement du projet concerné. La documentation stable de JupyterLab indique la version 4.6.5 au moment de la vérification éditoriale ; la page officielle des versions et modifications permet de contrôler que cette information n’a pas changé avant publication.

Repérer la portée du problème avant de modifier l’environnement

Le premier diagnostic consiste à déterminer si aucun noyau n’est visible ou si seul un environnement précis manque. Cette distinction évite de réinstaller des composants qui fonctionnent déjà.

Une kernelspec contient notamment une commande de lancement (argv), un nom d’affichage (display_name) et une indication de langage (language). Ces champs aident à comprendre ce que Jupyter tente de lancer ; le libellé visible dans le menu ne prouve pas que la commande vise le bon Python. Les références de Jupyter Client sur les noyaux et les kernelspecs détaillent cette structure.

Comparez les environnements avant d’agir :

Pour examiner les définitions connues du service, utilisez :

jupyter kernelspec list

La commande liste les noyaux accessibles dans le contexte où elle est exécutée. Si JupyterLab a été démarré depuis un autre environnement ou une autre session, ne supposez pas que la commande lancée dans un terminal séparé observe exactement la même configuration. Notez son résultat, puis comparez-le à l’environnement depuis lequel le service a été démarré. La documentation de configuration du serveur Jupyter aide à identifier les réglages du service lorsque le lancement est géré par une configuration.

À retenir : un Python accessible dans le terminal n’est pas nécessairement un noyau enregistré. La vérification utile porte sur la liste des kernelspecs associée au service, puis sur le chemin de l’interpréteur qu’elle lance.

Enregistrer le noyau de la bonne Python virtuelle

Si l’environnement du projet existe et que seul son noyau manque, installez ipykernel dans cet environnement. L’installation doit être exécutée avec le Python que le Notebook devra utiliser, et non avec un interpréteur choisi par défaut dans un autre terminal.

Procédez dans cet ordre :

1. Repérez le chemin de Python associé au projet et activez son environnement virtuel selon la méthode déjà utilisée par l’équipe.
2. Vérifiez que la commande python de cette session désigne bien l’interpréteur du projet.
3. Installez ipykernel dans cet environnement si le module n’y est pas disponible.
4. Enregistrez le noyau en utilisant le même interpréteur.
5. Actualisez ou relancez l’interface, puis vérifiez que le noyau apparaît dans le Notebook.
6. Ouvrez une cellule et contrôlez que l’interpréteur exécuté correspond au projet.

La documentation officielle d’IPython sur l’installation d’un noyau fournit la commande de référence. Une fois l’environnement activé, la forme générale est :

python -m ipykernel install --user --name nom_environnement --display-name "Python — projet"

Remplacez les deux noms par des valeurs explicites adaptées au projet. --name identifie le noyau enregistré ; --display-name contrôle l’étiquette présentée dans l’interface. Choisissez un libellé compréhensible pour les membres du laboratoire, mais ne vous fiez pas à ce texte pour identifier l’interpréteur. Après l’enregistrement, relancez jupyter kernelspec list et conservez le résultat.

Un environnement virtuel isole les paquets installés de ceux d’autres environnements ; sa configuration et son répertoire Python sont propres à son emplacement. La documentation Python consacrée à venv explique ce fonctionnement. Si le dossier de l’environnement a été déplacé ou supprimé après l’enregistrement, un kernelspec peut donc continuer à désigner un chemin qui n’est plus utilisable.

Pannes de lancement et erreurs d’interpréteur

Un noyau qui figure dans le menu peut encore échouer au démarrage. Dans ce cas, le problème n’est plus simplement « noyau absent ». Examinez la définition de noyau indiquée par jupyter kernelspec list, notamment la commande de lancement et le chemin de l’environnement. Si un projet a été déplacé, recréé ou nettoyé, l’ancien kernelspec peut pointer vers un exécutable inexistant.

Pour un diagnostic reproductible, évitez d’abord de réinstaller globalement Python ou de remplacer les dépendances du projet. Ces opérations peuvent masquer l’origine de la panne et rendre les résultats difficiles à comparer. Préférez une vérification minimale :

• le noyau choisi dans le Notebook est-il celui du projet ?
• le chemin de Python indiqué par le processus existe-t-il ?
• le noyau fonctionne-t-il avec une cellule simple ?
• les paquets requis sont-ils installés dans ce même environnement ?
• le service et l’environnement du noyau se trouvent-ils sur l’hôte attendu ?

Lorsque le Notebook démarre mais importe une mauvaise version d’un paquet, distinguez le démarrage du noyau de la validité scientifique de l’environnement. Exécutez dans une cellule :

import sys
print(sys.executable)
print(sys.version)

Comparez le chemin retourné à celui documenté pour le projet. Puis vérifiez les dépendances nécessaires à l’analyse avec les outils déjà employés dans l’environnement. Un nom tel que « Python — projet » peut être attribué à plusieurs interpréteurs : le chemin affiché par sys.executable est un indice plus fiable.

Si l’ancien Notebook doit désormais utiliser un nouvel environnement, sélectionnez le noyau nouvellement enregistré dans le Notebook, puis faites cette vérification avant de relancer les cellules de calcul. Le fichier du Notebook ne recrée pas à lui seul l’environnement Python et ne garantit pas que ses bibliothèques soient installées. Pour des travaux impliquant des données sensibles, effectuez les essais avec un extrait non sensible et suivez les règles de stockage de l’équipe.

Questions fréquentes sur les noyaux de JupyterLab

L’interface s’ouvre, mais aucun noyau Python n’apparaît

Exécutez jupyter kernelspec list dans le contexte du service actif. Si la liste ne contient aucun noyau adapté, cela ne signifie pas que Python est absent de la machine : cela indique que l’environnement recherché n’est pas disponible comme noyau pour ce service. Installez ipykernel dans l’environnement visé, enregistrez-le avec son interpréteur, puis vérifiez de nouveau la liste.

ipykernel est installé, mais l’environnement reste invisible

Vérifiez d’abord que l’installation a été faite avec le Python de l’environnement attendu. Une installation dans l’environnement du serveur, ou dans un autre Python, ne l’ajoute pas automatiquement au projet. Activez l’environnement concerné, enregistrez son noyau avec python -m ipykernel install, puis contrôlez que le service utilisé par JupyterLab voit ce kernelspec.

Le Notebook démarre, mais comment confirmer son interpréteur ?

Dans une cellule, affichez sys.executable et sys.version. Comparez le chemin obtenu à celui du projet ; vérifiez ensuite qu’une dépendance importante est importée depuis l’environnement prévu. Le nom montré dans le menu de JupyterLab est modifiable et peut être trompeur. Si le chemin n’est pas le bon, sélectionnez le noyau correct au lieu de modifier les paquets au hasard.

Un ancien Notebook doit utiliser un nouvel environnement

Enregistrez d’abord le nouvel environnement comme noyau et sélectionnez-le dans le Notebook. Contrôlez le chemin de l’interpréteur, puis testez une cellule courte et une dépendance importante avant de relancer l’analyse complète. Si l’environnement d’origine a été déplacé, ne réutilisez pas son ancienne définition sans vérifier son chemin de lancement : créez ou enregistrez le noyau correspondant à l’environnement réellement disponible.

Liste de vérification pour valider la réparation

Cochez chaque point avant de reprendre une analyse ou un travail de cours :

• [ ] La version et la commande de démarrage de JupyterLab sont consignées.
• [ ] jupyter kernelspec list montre le noyau attendu dans le contexte pertinent.
• [ ] Le Notebook utilise le noyau du projet, pas seulement un noyau portant un nom similaire.
• [ ] sys.executable indique le chemin de Python attendu.
• [ ] Les dépendances nécessaires au projet sont présentes dans cet environnement.
• [ ] Une cellule représentative s’exécute sans erreur avant le lancement complet.
• [ ] Le nom du noyau, l’environnement utilisé et les étapes de vérification sont consignés pour faciliter la reproduction.

Pour une équipe de recherche, cette trace est particulièrement utile lorsqu’un Notebook est partagé. Elle permet de séparer une erreur de code d’un écart d’environnement, et d’expliquer pourquoi un résultat ne se reproduit pas sur le poste d’un autre membre. La validation reste propre au projet : une cellule réussie ne garantit pas à elle seule la compatibilité de toutes les dépendances ou de toute la chaîne d’analyse.

Quand un Mac distant peut compléter le laboratoire

La réparation d’un noyau ne nécessite pas automatiquement un nouveau Mac. Si l’environnement du projet fonctionne déjà sur la machine disponible, conservez cette configuration et documentez-la. De même, la location d’un Mac ne corrige pas un kernelspec qui pointe vers un chemin périmé, un paquet manquant ou un mauvais interpréteur.

La question se pose plutôt lorsque le projet doit être vérifié dans macOS et que le laboratoire ne dispose pas d’un Mac exploitable. Dans ce cas, un Mac distant peut compléter des postes Linux ou Windows pour tester un environnement propre à macOS, sans remplacer les ressources existantes. Avant de choisir cette voie, vérifiez les modalités d’accès proposées, les conditions de transfert des données et les règles de sécurité applicables aux travaux de recherche. Les exemples d’usage d’un Mac à distance et les guides disponibles permettent d’évaluer les cas d’usage et les limites avant de déplacer un projet.

Les postes déjà disponibles évitent un coût de location, mais peuvent ne pas fournir l’environnement macOS requis ; ils peuvent aussi demander des ajustements de dépendances et ne reproduisent pas toujours le comportement à vérifier. À l’inverse, un Mac loué apporte un environnement macOS à évaluer sans achat immédiat, mais ne remplace ni la validation des kernelspecs, ni les contrôles de confidentialité, ni une machine locale si le projet exige un accès physique. Si une validation macOS ponctuelle est réellement nécessaire, consultez les modalités de HireVM et vérifiez que l’accès proposé convient à votre projet avant d’y transférer des données.

Questions fréquentes