NVivo 15 s’ouvre sur votre Mac Apple Silicon, mais affiche une demande concernant Rosetta ?
Solution la plus rapide : vous pouvez poursuivre les vérifications sous macOS 27, mais ne prenez pas l’ouverture de l’application pour une preuve de compatibilité complète. Si votre analyse est en cours, conservez l’environnement déjà validé et testez toute mise à niveau sur une copie de projet.
Cet article s’adresse à vous si vous utilisez NVivo 15 sur Apple Silicon, si vous dirigez une étude qualitative en cours, ou si vous gérez les Mac d’un laboratoire universitaire. Il vous aide à choisir entre continuer, différer une mise à niveau et tester un environnement distinct.
Dernière vérification : 6 novembre 2026. Les informations ont été recoupées avec la documentation d’Apple sur Rosetta et les informations du développeur de NVivo sur la version Mac et les projets. Les indications de fonctionnement sous macOS 27 provenant d’un canal de support restent à distinguer d’une déclaration formelle de compatibilité.
Établir le statut avant de décider
La compatibilité de NVivo 15 avec macOS 27 dépend de trois choses qui ne doivent pas être confondues : la possibilité de lancer l’application, le fonctionnement de vos opérations de recherche et la prise en charge formelle de votre combinaison de versions.
Les informations de support disponibles indiquent que NVivo 15 et NVivo 14 peuvent fonctionner sous macOS 27, mais elles ne remplacent pas une matrice de compatibilité officielle à jour. Consultez les informations du développeur sur NVivo pour Mac et la communication de support relayée au sujet de macOS 27 : notez qui affirme quoi, ainsi que la date de mise à jour. Une indication de fonctionnement ne garantit ni l’absence d’erreur dans votre projet, ni le maintien de cette situation après une prochaine mise à jour système.
Pour Apple Silicon, le point de vigilance est Rosetta 2 : la version Mac actuelle de NVivo dépend de cette couche de traduction. Le développeur a indiqué prévoir une version native Apple Silicon avant macOS 28, sans en préciser le calendrier ni la forme de distribution. Il s’agit d’un projet annoncé, pas d’une version déjà publiée ni d’une garantie de migration sans interruption.
Apple précise que Rosetta reste disponible sous macOS 27 ou une version antérieure et que, à partir de macOS 28, elle ne prendra plus en charge les applications Intel dans leur usage général. Consultez la documentation officielle d’Apple sur Rosetta. Cette échéance rend risqué tout plan qui suppose que NVivo 15 pourra continuer à fonctionner de la même manière après le changement de système.
| Élément à vérifier | Ce que vous pouvez conclure | Ce que cela ne prouve pas |
|---|---|---|
| NVivo s’ouvre sous macOS 27 | Le lancement est possible dans cette configuration au moment du test | Que l’encodage, les requêtes et les exports sont fiables pour votre projet |
| Une demande Rosetta apparaît sur Apple Silicon | L’application utilise une dépendance à examiner et à documenter | Que la version native annoncée est disponible ou que votre établissement autorise l’installation |
| Un canal de support signale un fonctionnement | La combinaison a été signalée comme utilisable | Qu’elle figure dans une matrice officielle ou qu’elle soit garantie à long terme |
Pour une personne qui rédige sa thèse : préserver la continuité
Si vous êtes en train de coder des entretiens, de préparer un chapitre ou de livrer des résultats, ne changez pas de système uniquement parce que macOS 27 est disponible ou parce qu’une fenêtre vous propose Rosetta. Votre priorité est de garder une base reproductible : version de macOS, version de NVivo, architecture de la machine et état du projet doivent rester consignés.
Un projet NVivo est plus qu’un fichier qui s’ouvre. Les décisions de codage, les mémos, les requêtes et les exports font partie de votre méthode de travail ; ils doivent être revérifiés après un changement d’environnement. Le développeur documente également les questions d’ouverture de projets entre versions. Avant toute transition, lisez ses consignes sur les projets ouverts dans des versions différentes de NVivo. Ne présumez pas qu’un retour à une version précédente sera transparent.
Séparez aussi trois vérifications souvent amalgamées : la sauvegarde du projet, les conditions de votre licence et les règles de votre établissement concernant les logiciels ou les données de recherche. Une sauvegarde ne valide pas votre droit d’utiliser une version donnée ; une licence valide ne signifie pas que les données peuvent être déplacées vers un service externe.
Pour décider sans exposer le projet en cours, travaillez sur une copie non sensible. Notez les avertissements au démarrage, exécutez les tâches que vous utilisez réellement, puis comparez les résultats avec l’environnement de référence. Si vous ne pouvez pas établir une comparaison claire avant une échéance de thèse ou de publication, gardez l’environnement vérifié et remettez l’essai à une période moins critique.
Pour un responsable d’étude : distinguer nouveau projet et projet actif
Un nouveau projet offre davantage de latitude pour éprouver une configuration avant que l’équipe ne s’y engage. Un projet en cours, lui, porte déjà une histoire de décisions, de fichiers et de pratiques communes. Appliquez donc un niveau d’exigence différent selon son état.
| Situation de l’équipe | Décision à privilégier | Condition de passage |
|---|---|---|
| Nouvelle étude, aucune analyse commencée | Évaluer NVivo 15 sous macOS 27 dans un environnement de test | Les opérations habituelles passent sur un projet d’essai et les règles de licence sont confirmées |
| Étude active, environnement déjà validé | Conserver la base actuelle et différer la migration | Une copie du projet a été contrôlée et un retour à la base est possible |
| Projet à lancer, plan à long terme sur Apple Silicon | Suivre les annonces de version native et de compatibilité formelle | Le développeur a publié des informations suffisamment précises pour votre calendrier et votre licence |
| Option | Appréciation de décision | Motif |
|---|---|---|
| Continuer dans l’environnement déjà vérifié | Favorable pour un projet actif | Vous évitez une modification non testée pendant l’analyse |
| Migrer immédiatement le projet en cours | Prudence élevée | Le lancement seul ne valide pas le flux de travail ni le retour arrière |
| Attendre la version native et les informations formelles | Favorable pour une planification non urgente | Vous réduisez la dépendance au comportement de Rosetta, mais le calendrier n’est pas confirmé |
Pour le support informatique : traiter Rosetta comme une dépendance
Une alerte Rosetta n’est pas, à elle seule, un diagnostic de panne. Elle signale toutefois une dépendance qui doit être prise en compte dans la politique de mise à jour des Mac. Sur Apple Silicon, consignez le texte exact du message, la version de NVivo et celle de macOS, puis vérifiez si votre établissement autorise l’installation ou l’exécution de Rosetta dans cet environnement.
N’installez pas la couche de traduction à l’aveugle sur un poste administré. Il peut exister une procédure de gestion centralisée, une restriction de sécurité ou un responsable chargé de valider les logiciels. Si le système ne permet pas l’installation, transmettez au service informatique les versions relevées et le message exact ; évitez de contourner la politique de l’établissement avec un compte personnel ou un autre appareil.
Maintenez enfin deux registres distincts. Le premier décrit le constat technique : application lancée, fonctions testées, erreurs rencontrées, résultat des exports. Le second précise les responsabilités institutionnelles : licence, mises à jour autorisées, sauvegarde, stockage et accès aux données. Un constat de bon fonctionnement ne constitue pas une validation juridique ou institutionnelle.
Pour un groupe sans Mac local : tester sans transférer de données sensibles
Un Mac à distance peut être une piste pour éprouver un flux de travail macOS lorsque le laboratoire ne dispose pas de machine locale adaptée. Cela ne rend pas automatiquement NVivo accessible : l’autorisation logicielle, les règles de l’établissement, le mode de connexion et la sensibilité du projet restent à vérifier. Ne téléversez pas un projet de recherche confidentiel avant d’avoir obtenu les validations requises.
Procédez avec un projet fictif ou une copie dont les données ont été dépersonnalisées, si les règles de votre institution autorisent ce test. L’objectif est de contrôler les gestes essentiels et la remise des fichiers, pas de prétendre certifier l’ensemble de la configuration. Vous pouvez examiner les options de Mac à distance proposées par MACGPU après avoir clarifié les contraintes de votre projet ; la page ne remplace ni la confirmation de votre licence NVivo ni l’accord du responsable des données.
Suivre une procédure de validation avant toute migration
Utilisez cette liste avant de mettre à jour un Mac de recherche ou de déplacer un projet :
- [ ] Relevez la version exacte de macOS, le modèle de puce et la version de NVivo, puis conservez ces informations dans le journal de l’étude.
- [ ] Faites une sauvegarde vérifiable du projet et conservez une copie de référence qui ne sera pas ouverte dans le nouvel environnement.
- [ ] Confirmez avec le service compétent que la licence NVivo et l’usage de Rosetta sont autorisés sur la machine concernée.
- [ ] Ouvrez une copie du projet, pas l’unique fichier de travail ; consignez les alertes et les éventuelles demandes de conversion.
- [ ] Reproduisez les opérations de l’étude : ouvrez des sources, appliquez des codes, consultez les mémos et exécutez les requêtes que vous utilisez réellement.
- [ ] Enregistrez, fermez, rouvrez la copie, puis vérifiez les exports nécessaires à votre protocole.
- [ ] Comparez les fichiers produits avec la base de référence et consignez les écarts, même si l’application ne signale aucune erreur.
- [ ] N’autorisez la migration du projet actif qu’après accord de la personne responsable et après définition d’un retour à l’environnement précédent.
FAQ : Rosetta, mise à niveau et macOS 28
NVivo 15 peut-il continuer à fonctionner sous macOS 27 ?
Les informations relayées par le support font état d’un fonctionnement possible, mais votre résultat dépend de la configuration et des opérations réalisées. Ouvrez une copie du projet et vérifiez les étapes de votre méthode jusqu’à l’enregistrement et l’export. Tant que la compatibilité formelle n’est pas clairement documentée, traitez ce résultat comme une validation locale, pas comme une garantie pour tous les postes.
Comment réagir à l’invite Rosetta sur Apple Silicon ?
Vérifiez d’abord que votre service informatique autorise Rosetta, puis notez la version de NVivo et le message présenté. Si l’installation est permise, lancez le test avec une copie de projet et vérifiez le flux de travail complet. Si l’alerte persiste ou si l’installation est bloquée, transmettez les détails au support au lieu de désactiver des contrôles ou de contourner l’administration du Mac.
Que change macOS 28 pour les logiciels qui utilisent Rosetta 2 ?
Apple indique que Rosetta est disponible sous macOS 27 ou une version antérieure et qu’à partir de macOS 28 elle ne prendra plus en charge les applications Intel dans leur usage général. Le développeur de NVivo a annoncé une version native Apple Silicon avant cette échéance, mais le calendrier et le mode de distribution ne sont pas précisés. Prévoyez donc une nouvelle vérification avant de planifier la migration.
Faut-il mettre à jour pendant un projet qualitatif en cours ?
Si l’environnement actuel fonctionne et que votre projet est actif, gardez-le comme base jusqu’à la validation d’une copie dans un environnement distinct. Le test doit couvrir vos opérations habituelles et les livrables attendus, et non le seul lancement de NVivo. Avant de changer, confirmez également les sauvegardes, la licence et les règles de traitement des données de votre établissement.
Choisir le prochain test, pas une promesse de compatibilité
Pour un projet actif, la solution la moins risquée est de préserver l’environnement déjà vérifié et de tester macOS 27 sur une copie. Pour une nouvelle étude ou une planification à long terme, attendez des informations plus précises sur la version native et la compatibilité formelle avant de baser votre calendrier sur Rosetta. Les deux décisions peuvent être différentes au sein d’un même laboratoire, selon l’état de chaque projet.
Si vous ne disposez pas d’un Mac local, un Mac distant peut faciliter un essai encadré, mais il ne règle pas les questions de licence, de confidentialité ou de conformité de votre université. Après validation de ces points, vous pouvez consulter les solutions Mac à distance de MACGPU pour déterminer si un environnement temporaire convient à un test sur données non sensibles. Si votre équipe a besoin d’un poste stable en permanence ou d’interfaces physiques particulières, comparez aussi l’achat d’un Mac local et les ressources déjà administrées par votre établissement : la location n’est pas adaptée à tous les usages.