Comment installer napari 0.9.1 sur un Mac Apple Silicon : guide scientifique 2026

La fenêtre de napari s’ouvre, mais le plugin de segmentation ne se charge pas ou le fichier de microscopie reste illisible.

Le moyen le plus rapide est de choisir l’application Apple Silicon pour la simple visualisation et l’annotation, puis un environnement arm64 séparé avec conda-forge, napari 0.9.1 et Qt6 dès qu’un script, un plugin ou une reproduction de projet est nécessaire.

Dernière mise à jour : 4 septembre 2026. Les informations de version ont été vérifiées dans la documentation officielle d’installation de napari, les indications conda-forge et Python étant également contrôlées dans le guide officiel d’installation Python.

Cet article s’adresse aux trois profils suivants :

• aux étudiants qui veulent ouvrir, annoter et exporter des images sans administrer Python ;
• aux chercheurs qui doivent relier napari à un script, à Jupyter, à une segmentation ou à un traitement par lots ;
• aux équipes informatiques universitaires qui livrent un environnement reproductible sur un Mac local ou distant.

L’installation de napari 0.9.1 sur Mac Apple Silicon ne correspond pas à une seule procédure. La version du paquet Python, celle de l’application macOS autonome et celle d’un plugin peuvent évoluer séparément. La documentation de développement officielle indique napari 0.9.1 comme version centrale à vérifier à la date de rédaction et présente une voie arm64 avec conda-forge ; le paquet autonome macOS affiché sur la même documentation peut toutefois porter une autre version. Il ne faut donc pas déduire qu’un numéro affiché dans l’application est automatiquement celui du paquet Python.

Avant de télécharger quoi que ce soit, nous vous conseillons de noter quatre éléments :

• l’architecture du Mac : Apple Silicon arm64, et non une session forcée sous une autre architecture ;
• le format réel des données : image simple, série de plans, volume, format multicanal, Zarr ou données à plusieurs échelles ;
• la nécessité ou non d’exécuter du Python ou un carnet Jupyter ;
• la liste des plugins indispensables, avec leur plage de versions napari et Python.

Une fenêtre qui s’ouvre ne constitue donc qu’un test de démarrage. Pour une utilisation scientifique, il faut encore prouver que la couche d’image, le lecteur de fichier, le plugin, le traitement et l’export fonctionnent sur un échantillon représentatif.

Si votre objectif se limite à la consultation, à l’annotation et à l’export, l’application autonome est généralement la voie la moins coûteuse en temps d’administration. Depuis la page officielle des versions, sélectionnez explicitement le paquet macOS destiné à Apple Silicon, puis comparez le numéro affiché avec celui indiqué dans la page de publication. Ne confondez pas le nom du fichier téléchargé avec la version du paquet Python napari 0.9.1.

La procédure minimale est la suivante :

1. Ouvrez la page officielle d’installation et repérez le paquet macOS arm64, sans choisir une archive destinée à une autre architecture.
2. Installez l’application dans le dossier prévu par macOS, puis lancez-la une première fois avec le compte qui sera réellement utilisé au laboratoire.
3. Notez la version affichée dans l’application et conservez le nom exact du paquet dans le registre du projet.
4. Chargez un exemple officiel, puis une image expérimentale désidentifiée représentant les canaux, dimensions et métadonnées du projet.
5. Vérifiez séparément l’affichage des couches, l’annotation, la sauvegarde du projet et l’export du résultat.
6. Fermez et relancez napari afin de vérifier que la configuration ne dépend pas seulement de la première session.

La documentation officielle des couches napari distingue notamment les couches d’image et d’autres types de données ; cette distinction compte lorsque l’équipe valide une annotation ou une superposition. Une image qui semble correcte à l’écran peut néanmoins avoir été chargée comme une pile avec un ordre d’axes inattendu. Le contrôle doit donc porter sur les dimensions et non uniquement sur l’apparence visuelle.

Attention : si un plugin indispensable n’est pas pris en charge par l’environnement de l’application autonome, n’ajoutez pas au hasard des paquets dans son répertoire. Conservez cette installation comme référence graphique et passez à un environnement Python séparé.

Pour un chercheur qui manipule des scripts, des notebooks ou des paquets de traitement, l’environnement conda-forge est le choix le plus contrôlable. Il permet de conserver une pile isolée, de l’exporter et de la reconstruire sur un autre poste. Il ne rend pas pour autant toutes les dépendances compatibles : chaque plugin doit être contrôlé dans les limites qu’il documente.

Créez d’abord un environnement propre. Les commandes ci-dessous ne cherchent pas à installer une liste complète de bibliothèques ; elles servent à établir le socle de validation.

conda create -n napari-091-arm64 -c conda-forge python napari=0.9.1 pyqt
conda activate napari-091-arm64
python -c "import platform, sys, napari; print(platform.machine()); print(sys.version); print(napari.__version__)"
napari
conda env export --from-history > napari-091-arm64.yml

La commande platform.machine() doit être interprétée avec le contexte du poste et de l’environnement utilisés. Si elle révèle une architecture inattendue, ne poursuivez pas l’installation des plugins avant d’avoir corrigé le problème. De même, l’affichage de la version napari doit être réalisé depuis l’environnement activé, et non depuis un terminal qui utilise une autre installation Python.

Le paquet pyqt permet ici de sélectionner le backend Qt6 attendu par cette voie. Pour la question PyQt6 ou PySide6 sur Apple Silicon, la règle de décision est simple : utilisez le backend demandé par le plugin et par la documentation de votre environnement, puis ne remplacez pas Qt en cours de route dans l’environnement déjà validé. PyQt6 et PySide6 ne sont pas deux variantes à empiler ; ce sont des dépendances qui peuvent influencer les plugins et les interfaces.

L’export de l’environnement ne remplace pas un test de reconstruction. Sur un poste de laboratoire, créez une nouvelle copie avec le fichier YAML, activez-la et répétez le lancement ainsi que l’ouverture d’un échantillon. Cette étape détecte les dépendances installées manuellement mais absentes de la déclaration.

Pour les détails propres à l’installation Python et à conda-forge, appuyez-vous sur les indications de la documentation officielle conda-forge de napari, plutôt que sur une commande copiée depuis un forum dont l’architecture n’est pas précisée.

Un plugin installé mais absent du menu ne doit pas être considéré immédiatement comme un défaut de napari. Plusieurs causes sont possibles : installation dans un autre environnement, incompatibilité de version, manifeste incomplet, dépendance non résolue ou lancement depuis une autre architecture.

Pour comprendre pourquoi un plugin napari n’apparaît pas, procédez dans cet ordre :

1. Activez l’environnement qui lance réellement napari.
2. Vérifiez que le plugin a été installé dans ce même environnement.
3. Consultez son manifeste et son nom d’entrée, car le nom du paquet et le nom visible dans l’interface peuvent différer.
4. Redémarrez napari après l’installation, puis observez le journal de démarrage.
5. Lancez le diagnostic prévu par la documentation officielle de débogage des plugins.
6. Testez le plugin avec un fichier pour lequel son lecteur ou son algorithme est conçu.
7. Notez la version du plugin, la version napari, Python, Qt et le résultat obtenu.

Le format officiel du manifeste des plugins doit être consulté lorsque le plugin est découvert mais n’est pas exposé comme prévu. Pour un plugin de segmentation, la validation ne s’arrête pas à la présence d’un bouton : il faut vérifier le chargement de l’image, les paramètres, le type de sortie, la conservation des axes et l’export.

Les recommandations officielles concernant les dépendances des plugins insistent sur la nécessité de déclarer correctement la pile requise ; consultez les bonnes pratiques de développement napari lorsque votre équipe maintient un plugin interne. Si celui-ci impose une autre version du cœur, ne modifiez pas l’environnement de référence qui fonctionne déjà. Créez un environnement dédié, attribuez-lui un nom explicite et rédigez une note indiquant pourquoi les deux piles ne peuvent pas être fusionnées.

Liste de validation du plugin

• [ ] Le plugin est installé dans l’environnement qui lance napari.
• [ ] Son nom de paquet et son nom d’interface sont documentés.
• [ ] La version napari compatible est connue.
• [ ] La plage Python et le backend Qt sont connus.
• [ ] Un fichier représentatif est lu sans conversion manuelle non documentée.
• [ ] Le résultat du plugin est vérifié sur une image témoin.
• [ ] L’export est relu dans l’outil prévu par le projet.
• [ ] L’environnement approuvé n’a pas été modifié pour réparer un autre plugin.

Les projets de microscopie ne se limitent pas toujours à une petite image. Avec un volume, une série de plans, des données Zarr, Dask ou multiscales, trois niveaux doivent être séparés :

1. Le fichier est reconnu. Le lecteur identifie le format et crée les couches attendues.
2. Les données sont chargées à la demande. Le poste ne tente pas nécessairement de conserver tout le volume en mémoire.
3. La tâche interactive est réalisable. Les changements d’échelle, coupes, annotations ou superpositions restent utilisables pour le protocole réel.

La documentation officielle sur les couches d’image et les données multiscales fournit le cadre technique pour examiner ces cas. Conservez les preuves suivantes dans le dossier du projet :

• le journal de lecture ou le message de chargement ;
• les dimensions et axes observés ;
• la variation de mémoire relevée pendant l’ouverture ;
• une capture ou un export d’une coupe représentative ;
• le résultat d’une opération réellement utilisée par le laboratoire ;
• la méthode d’arrêt lorsque l’interaction devient instable.

Un délai de bureau distant ne doit pas être attribué automatiquement au moteur de rendu napari. Il peut provenir de la connexion, du protocole distant, du transfert de données ou de la charge du poste. Inversement, une session fluide sur une petite image ne prouve pas qu’un volume de recherche sera exploitable. Nous ne présentons donc aucune mesure de performance distante sans relevé réalisé sur la configuration concernée.

Si le laboratoire ne dispose d’aucun Mac, l’approche rationnelle consiste à transférer un échantillon désidentifié, à lancer napari sur un véritable Mac Apple Silicon distant, puis à valider le plugin et la tâche représentative avant toute décision d’équipement. Les données sensibles doivent rester conformes aux règles de l’établissement ; la session distante ne dispense pas de désidentifier les images ni de vérifier où sont stockés les fichiers temporaires.

Pour comparer les modalités disponibles, consultez les solutions Mac distantes de JEXCLOUD uniquement après avoir défini le protocole de validation. Si un laboratoire doit sélectionner une zone géographique de connexion, les pages Mac distant pour l’Europe et l’Amérique du Nord peuvent servir à examiner les options proposées, sans remplacer un test avec les données du projet.

La personne qui réussit l’installation sur son compte n’a pas encore livré une solution de laboratoire. Pour éviter un environnement impossible à reprendre, réunissez dans un même dossier :

• le fichier d’environnement exporté ;
• la version du cœur napari et celle de l’application autonome, si les deux sont conservées ;
• la liste des plugins, leurs versions et leurs sources ;
• la version Python et le backend Qt ;
• la provenance de l’échantillon désidentifié ;
• les commandes de lancement ;
• les captures ou journaux de validation ;
• la procédure d’export et de nettoyage des données.

Faites ensuite reconstruire l’environnement par un second compte. Contrôlez la connexion au Mac distant, le lancement sans intervention du créateur, la lecture d’un fichier témoin, l’exécution du plugin et la récupération du résultat. Cette vérification révèle les dépendances cachées dans le répertoire personnel ou les autorisations qui ne sont pas documentées.

Contrôle de livraison pour une équipe universitaire

• [ ] Un nouvel utilisateur peut ouvrir la session et trouver l’environnement.
• [ ] Le lancement utilise la bonne architecture et le bon backend Qt.
• [ ] Le fichier témoin est accessible sans exposer de données personnelles.
• [ ] Le plugin apparaît et produit un résultat contrôlable.
• [ ] Le projet ou l’export peut être récupéré par l’équipe.
• [ ] Les fichiers temporaires et les copies locales sont identifiés.
• [ ] Une procédure de retour existe si la version du plugin change.
• [ ] La décision de conserver un Mac distant, de migrer vers une plateforme existante ou de maintenir un fonctionnement mixte est écrite.

Cette dernière décision dépend du cycle du projet, du nombre d’utilisateurs et de la répétabilité de la tâche, non de la seule réussite de l’installation. Un environnement distant est pertinent pour une validation, une période de traitement ciblée ou une compatibilité Apple Silicon à prouver. Un poste local peut être plus logique lorsque le groupe exécute quotidiennement une charge lourde, utilise des interfaces physiques ou doit conserver des données dans une infrastructure institutionnelle précise.

Si la solution actuelle repose uniquement sur un poste Windows ou Linux, elle peut laisser trois angles morts : l’absence de macOS pour vérifier l’interface native, l’impossibilité de reproduire un plugin lié à cet environnement et le temps perdu à déplacer les images entre machines. Une machine virtuelle ou une installation non prévue par l’éditeur peut ajouter des problèmes d’architecture, de rendu et de gestion des fichiers, sans garantir la même expérience qu’un Mac réel.

Dans ce contexte, louer un Mac distant auprès de JEXCLOUD peut être plus cohérent que d’acheter immédiatement un appareil pour un besoin encore incertain : vous validez d’abord napari 0.9.1, le plugin, les fichiers représentatifs et l’interaction sur la période correspondant au projet. Si toutes les vérifications passent, vous pourrez comparer sereinement une location prolongée, un achat local ou un fonctionnement à deux plateformes. Si elles échouent, vous aurez identifié la limite technique avant d’engager le budget du laboratoire.

Pour une demande limitée à un test de compatibilité, à une remise de projet ou à quelques semaines d’analyse, examinez les modalités de location Mac de JEXCLOUD après avoir préparé la liste des plugins et des échantillons. En revanche, une location n’est pas forcément adaptée à une charge lourde permanente, à un besoin d’interface physique ou à une politique institutionnelle interdisant le traitement distant. La bonne séquence reste donc : définir les critères, tester sur un Mac Apple Silicon réel, consigner les résultats, puis choisir entre location, achat ou double environnement.

• Vérifier la compatibilité des applications macOS avec Rosetta sur Apple Silicon
• Choisir entre Mac et Windows pour apprendre et utiliser Python
• Évaluer un Mac distant pour les travaux étudiants et scientifiques