napari 0.10.0 en 2026 : valider les anciens plugins sur Mac ?

Votre ancien plugin napari se lance, mais son panneau est absent ou son interface ne répond plus après une mise à niveau ?

Action à retenir : ne remplacez pas l’environnement de l’équipe. Testez napari 0.10.0 dans un environnement isolé avec un moteur Qt6, puis validez les plugins indispensables et le flux d’analyse avant de décider. La version 0.10.0 a supprimé la prise en charge de Qt5 ; un plugin qui dépend de PyQt5 ne peut donc pas être considéré comme compatible sans vérification ni adaptation (notes de publication de napari 0.10.0).

Ce guide s’adresse aux étudiants et chercheurs qui analysent des images biologiques avec des plugins napari.
Il aide les responsables de plugins à vérifier les dépendances et le moteur Qt employé.
Les administrateurs de laboratoire y trouveront des critères pour autoriser une migration ou conserver l’environnement de référence.

Dernière vérification : 2 novembre 2026, à partir de la documentation officielle d’installation, des notes de publication de napari 0.10.0 et de la documentation d’installation des plugins.

Validation des anciens plugins napari 0.10.0 sur Mac : fixez les critères avant l’essai

Une fenêtre napari qui s’ouvre ne prouve ni que le plugin chargé est le bon, ni que l’analyse produit les résultats attendus. Séparez donc les critères d’acceptation en plusieurs niveaux : démarrage de l’application, disponibilité du moteur Qt6, découverte et chargement des plugins, puis exécution du flux scientifique et export des résultats.

Avant de commencer, définissez les tâches qui doivent absolument continuer à fonctionner. Pour une équipe de microscopie, il peut s’agir de lire un format d’image, d’ouvrir un panneau d’analyse, d’appliquer une opération de segmentation, de conserver les annotations et d’exporter un résultat exploitable dans le projet. Pour un travail de création audio ou vidéo reposant sur des images scientifiques, les critères peuvent également inclure la qualité des aperçus, les contrôles interactifs et l’enchaînement avec les outils de postproduction. Ces exigences doivent être écrites avant l’installation : elles empêchent de confondre une application fonctionnelle avec un environnement de recherche accepté.

Conservez aussi une référence exploitable de l’environnement actuel : version de napari, noms et versions des plugins, dépendances Qt, commandes d’installation et fichiers utilisés pour l’essai. La commande python -m pip freeze permet de consigner les paquets installés dans un environnement Python ; consultez la documentation de pip sur l’export de la liste des paquets pour vérifier son usage. Cet inventaire ne remplace pas les instructions de l’équipe, mais facilite la comparaison et le diagnostic.

Point de contrôle : gardez une copie de l’environnement de référence et évitez d’y installer la version candidate. Si un plugin indispensable échoue, vous devez pouvoir reprendre le travail sans reconstruire dans l’urgence les dépendances déjà utilisées.

Avant la migration, classez les plugins et leurs dépendances

Commencez par établir un inventaire des plugins effectivement utilisés dans vos projets, plutôt que de vous fier à une ancienne liste d’installation qui pourrait inclure des outils désormais inutilisés. Notez pour chacun son nom, sa version connue, sa source d’installation, la tâche qu’il prend en charge et les indications de compatibilité publiées par ses responsables.

Classez ensuite les outils en trois groupes. Les plugins indispensables correspondent à une étape qui n’a pas d’alternative validée dans le projet. Les plugins remplaçables peuvent être remplacés par une fonction déjà disponible ou par un outil alternatif approuvé par l’équipe. Enfin, les plugins facultatifs ne doivent pas bloquer la migration, mais leur absence doit être consignée si elle affecte les habitudes de travail.

Recherchez dans la documentation ou le dépôt du plugin des mentions explicites de PyQt5, PyQt6, PySide6, de la version de napari visée ou d’une contrainte de système. Les recommandations de développement du projet napari peuvent servir de repère pour examiner les indications fournies par les mainteneurs. Une mention de compatibilité constitue un indice, pas une acceptation automatique : votre installation peut dépendre d’autres paquets, de fichiers de configuration ou de comportements propres à votre projet.

Un plugin fondé sur PyQt5 peut-il être repris tel quel ?

Ne partez pas du principe qu’un ancien plugin est nécessairement incompatible, mais ne supposez pas non plus qu’il fonctionnera inchangé. napari 0.10.0 ne prend plus en charge Qt5 ; PyQt5 ne peut donc pas servir de moteur Qt pour cette version. Un plugin dont le code ou les dépendances imposent PyQt5 doit être examiné avec son mainteneur et testé dans l’environnement cible avant toute migration.

Distinguez une dépendance déclarée d’une dépendance réelle à l’exécution. Le manifeste du plugin, ses instructions d’installation et ses imports donnent des pistes, mais une installation qui se termine sans erreur ne démontre pas que les fonctionnalités du plugin sont utilisables. Si aucune déclaration claire n’existe, consignez le plugin comme « à vérifier » et faites l’essai pratique dans l’environnement isolé.

Première étape : préparez un environnement d’essai séparé

La documentation officielle de napari présente des voies d’installation différentes, dont une application autonome et une installation dans un environnement Python. Choisissez selon le besoin du laboratoire : l’application autonome peut faciliter une vérification rapide, mais elle peut ne pas inclure les plugins dont votre flux dépend. Pour un projet qui exige un ensemble précis de plugins Python, utilisez plutôt un environnement propre et contrôlé, en suivant la procédure officielle correspondant à la voie choisie et les indications d’installation des plugins.

Évitez d’ajouter les dépendances de test à l’environnement de production pendant que vous cherchez à comprendre une erreur. Un environnement séparé permet de savoir quels paquets ont été ajoutés pour napari 0.10.0 et de répéter l’essai sans toucher à la configuration que les collègues utilisent déjà. Sur un Mac Apple Silicon, notez également l’architecture de l’environnement et l’origine des paquets installés, mais ne concluez pas qu’une erreur vient de la puce uniquement parce qu’elle survient sur cette machine.

Procédez dans cet ordre :

1. Préservez le point de départ. Exportez la liste des paquets de l’environnement actuel et enregistrez les versions, les commandes d’installation et les fichiers de configuration réellement utilisés.
2. Choisissez la voie d’installation selon le test. Utilisez l’application autonome pour examiner son contenu et son comportement ; choisissez un environnement Python distinct si vous devez installer les plugins et dépendances du projet.
3. Installez napari 0.10.0 sans modifier l’environnement principal. Suivez la procédure officielle correspondant à la voie choisie et notez les commandes exécutées.
4. Vérifiez le moteur Qt disponible. Confirmez que l’environnement emploie PyQt6 ou PySide6 et qu’il ne repose pas sur PyQt5 comme moteur de napari 0.10.0.
5. Ajoutez les plugins un par un. Conservez le nom et la version de chaque paquet ajouté afin d’identifier lequel introduit une erreur ou un conflit.
6. Reproduisez les tâches prioritaires. Ouvrez les échantillons autorisés pour les tests et suivez les étapes définies par l’équipe, sans vous limiter au lancement de l’application.

Pourquoi l’application autonome ne montre-t-elle pas un plugin ?

L’absence d’un plugin dans l’application autonome ne permet pas à elle seule de conclure qu’il est incompatible avec napari 0.10.0. Le paquet peut simplement ne pas être inclus dans cette distribution ou nécessiter une installation distincte. Consultez les instructions officielles sur la recherche et l’installation des plugins, puis vérifiez si la méthode recommandée s’applique à la version de l’application que vous testez.

Dans votre compte rendu, séparez donc ces situations : plugin absent de l’application autonome, plugin installé mais non découvert, plugin découvert mais qui échoue au chargement, et plugin chargé dont l’interface ne répond pas correctement. Chaque cas appelle un diagnostic différent. Si le flux du laboratoire exige un environnement Python maîtrisé, utilisez cet environnement pour l’acceptation finale plutôt que de considérer la distribution autonome comme une reproduction complète du poste de travail.

Deuxième étape : vérifiez le moteur Qt et le chargement réel

Dans napari 0.10.0, le contrôle du moteur Qt est un point de passage, pas un détail technique à remettre à plus tard. Confirmez dans l’environnement de test que le moteur utilisé est PyQt6 ou PySide6, les deux voies indiquées pour le fonctionnement de napari après le retrait de Qt5. Vérifiez les dépendances déclarées par le plugin, puis examinez les messages de lancement et les journaux lorsque vous tentez de charger son interface.

Pour chaque plugin indispensable, consignez quatre résultats distincts : est-il détecté par napari ? Peut-il être importé et chargé ? Son panneau ou son interface s’ouvre-t-il ? Les commandes importantes fonctionnent-elles sur l’échantillon prévu ? Cette séparation évite d’enregistrer « fonctionne » alors que seul le nom du plugin apparaît dans l’interface.

Comment évaluer la compatibilité avec PyQt6 ?

Commencez par les consignes du mainteneur, puis confrontez-les au comportement de votre environnement de test. Recherchez des indications sur l’adaptation à PyQt6 ou PySide6 et sur les versions de dépendances exigées. Si le plugin charge correctement, testez aussi ses actions : les composants d’interface, les signaux et les fenêtres secondaires peuvent échouer alors que l’import initial paraît réussi.

Lorsqu’un message d’erreur apparaît, relevez le texte complet, le moment où il se produit et l’action qui le déclenche. Un échec d’importation peut provenir d’une dépendance absente ; une interface qui ne s’ouvre pas peut révéler une incompatibilité avec le moteur Qt ou un défaut propre au plugin. La documentation officielle de dépannage de napari aide à structurer cette investigation. N’attribuez pas d’emblée un échec à Apple Silicon : comparez les dépendances, l’architecture des paquets et les indications du mainteneur avant de retenir cette explication.

À consigner : distinguez toujours « application lancée », « plugin chargé » et « action de recherche exécutée ». Une capture de l’écran de démarrage n’est pas une preuve que l’analyse a été reproduite.

Troisième étape : acceptez le flux avec des échantillons représentatifs

La validation doit porter sur un échantillon que vous avez le droit d’utiliser pour les tests et qui représente les données du projet. Évitez de commencer avec un cas exceptionnel ou un fichier qui ne sert qu’à démontrer l’ouverture de napari : il ne révélera pas les étapes sensibles du flux réel. Définissez avec l’équipe les opérations indispensables, puis répétez-les dans l’ancien environnement et dans l’environnement candidat en conservant les mêmes entrées.

Contrôlez au minimum les points suivants, en adaptant la liste aux exigences du projet :

• L’image et ses métadonnées pertinentes sont lues sans avertissement qui affecte l’analyse.
• Les couches nécessaires apparaissent et les opérations de navigation ou de sélection attendues sont disponibles.
• Le plugin réalise les commandes essentielles dans l’ordre documenté par l’équipe.
• Les annotations, paramètres ou résultats intermédiaires requis sont conservés.
• L’export produit des fichiers exploitables par les étapes suivantes du projet.
• Un collègue peut comprendre les différences en consultant le compte rendu et les journaux associés.

Les couches d’images, de labels et d’autres données doivent être examinées selon leur rôle dans votre travail. La documentation napari sur les couches décrit les types de couches et leur fonctionnement ; elle peut vous aider à préciser ce que vous devez vérifier à l’écran. Mais la documentation de l’application ne définit pas à elle seule les critères scientifiques de votre laboratoire : ceux-ci doivent venir du protocole et des exigences du projet.

Pour comparer les sorties, précisez d’abord ce qui doit être identique et ce qui peut varier selon les paramètres approuvés. Vérifiez les dimensions, les métadonnées utiles, les annotations et les fichiers exportés selon la méthode de contrôle de votre équipe. Si les résultats diffèrent, conservez les deux sorties et recherchez l’étape où l’écart apparaît ; ne masquez pas une différence en modifiant les paramètres sans consigner cette modification.

Décidez de migrer, de limiter le changement ou de différer

Avant de modifier l’environnement partagé, faites une revue des résultats avec les personnes responsables des plugins et du flux scientifique. Utilisez cette liste comme outil de décision : chaque élément doit correspondre à une vérification effectivement réalisée, et non à une supposition basée sur la documentation.

• [ ] L’environnement de référence est conservé et son inventaire peut être consulté.
• [ ] La voie d’installation testée correspond aux besoins en plugins du projet.
• [ ] Le moteur Qt utilisé est PyQt6 ou PySide6, et la dépendance à Qt5 a été examinée.
• [ ] Chaque plugin indispensable est détecté, chargé et testé dans ses fonctions requises.
• [ ] Les étapes d’analyse définies par le projet ont été exécutées sur des données représentatives.
• [ ] Les sorties et les limites constatées ont été comparées puis consignées.
• [ ] Les personnes chargées de maintenir l’environnement ont accepté le plan de retour arrière.

Vous pouvez alors retenir l’une des décisions suivantes. Migration envisageable : les plugins indispensables et les opérations scientifiques satisfont les critères définis, et l’équipe sait recréer l’environnement validé. Migration avec restrictions : les tâches principales passent, mais une fonction non essentielle manque ; consignez cette limite et vérifiez que le projet peut l’accepter. Migration différée : un plugin indispensable ne se charge pas, l’interface échoue ou les résultats ne respectent pas les exigences ; gardez l’environnement connu et attendez une adaptation ou une solution approuvée.

Si aucun Mac n’est disponible, vérifiez d’abord les contraintes d’accès

Un Mac accessible à distance peut compléter un parc de laboratoire centré sur Linux ou Windows, mais son adéquation dépend de vos besoins réels : possibilité d’installer les dépendances, accès autorisé aux données de test, interactions nécessaires avec l’interface et conditions imposées par votre établissement. Avant de choisir cette voie, vérifiez si le projet exige des périphériques physiques, un accès local à des données sensibles ou une intégration particulière avec des ressources de l’université.

Pour comparer ces besoins, vous pouvez consulter les scénarios d’utilisation d’un Mac à distance et les étapes de prise en main. Ces informations vous aideront à déterminer si un essai distant est compatible avec votre protocole ; elles ne remplacent pas l’acceptation du plugin et des résultats sur vos propres échantillons. Si un environnement distant semble convenir, examinez les offres et périodes de location de CDNMac avant de décider, sans supposer qu’une configuration ou une capacité particulière est disponible tant qu’elle n’a pas été confirmée.

Pour napari 0.10.0, la décision doit rester fondée sur les tests : Qt6 disponible, plugins indispensables chargés, étapes d’analyse exécutées et résultats conformes aux critères du laboratoire. Si vous ne disposez pas d’un Mac, une location à distance peut éviter d’acheter une machine avant de savoir si elle répond à votre besoin ; elle n’est toutefois pas le meilleur choix si vous avez besoin d’un poste local permanent, d’une charge soutenue à long terme ou de connexions physiques spécifiques. Dans tous les cas, gardez l’ancien environnement tant que l’acceptation du nouveau n’est pas documentée.