Il faut séparer trois informations souvent mélangées dans les discussions.

D’abord, IBM documente SPSS Statistics 32.0.0, son installation macOS et ses procédures d’autorisation. La documentation IBM consacrée à SPSS Statistics 32 constitue la référence pour la version actuellement disponible.

Ensuite, une discussion de la communauté officielle IBM sur la compatibilité Apple Silicon mentionne un projet de version native avec SPSS 32.0.1 en septembre 2026. Il s’agit d’une indication de feuille de route, pas d’une garantie de publication. Tant que le téléchargement officiel, les notes de version et l’architecture du paquet ne sont pas vérifiables, vous ne devez pas présenter cette échéance comme acquise.

Enfin, l’architecture d’une application ne se déduit pas de son nom commercial. Apple explique dans son guide de vérification de l’architecture d’une application comment distinguer une application Intel, arm64 ou Universal. Cette vérification devra porter sur SPSS lui-même, mais également sur les extensions et les processus associés.

Rosetta n’est donc pas un échec de votre installation. C’est une solution de continuité. En revanche, elle ajoute une dépendance à surveiller. Apple indique que la prise en charge générale des applications Intel se prolonge jusqu’à macOS 27, tandis que macOS 28 ne conservera qu’une fonction limitée pour certains anciens jeux. Cette évolution justifie une stratégie de migration, mais ne transforme pas SPSS 32.0.0 en version inutilisable aujourd’hui.

À retenir : une date annoncée dans une feuille de route ne doit jamais devenir la date de remise de votre mémoire. Pour un travail noté ou soumis, la date de votre projet prime sur la promesse d’une version future.

Un environnement statistique ne se résume pas à l’application visible dans le dossier Applications. Il comprend la version exacte, le type de licence, les extensions, les paramètres de sortie, les scripts et les fichiers de données. Remplacer uniquement le programme peut donc créer une différence difficile à expliquer plusieurs semaines plus tard.

Les risques les plus fréquents sont les suivants :

• une extension Python ou R peut rester dépendante d’Intel alors que le programme principal devient arm64 ;
• une licence individuelle peut ne pas autoriser l’usage distant ou le partage entre plusieurs utilisateurs ;
• un export vers PDF, Excel, CSV ou un format graphique peut produire une différence d’encodage ou de mise en page ;
• une syntaxe SPS peut appeler un module installé localement que l’administrateur a oublié de documenter ;
• un fichier SAV peut être analysé avec des options différentes de celles utilisées lors d’une première soumission.

La liste officielle des correctifs SPSS 32.0 doit être consultée lorsqu’un comportement anormal apparaît. Elle ne remplace pas une validation sur vos propres données. Un résultat reproductible dans un exemple générique ne prouve pas que votre chaîne de recherche est prête.

Exemple de terrain : un mémoire qui ne peut pas attendre

Imaginez un étudiant qui termine une analyse de questionnaire et doit répondre à une demande de son directeur de recherche. Le fichier SAV est stable, la syntaxe SPS est archivée et les tableaux ont déjà été relus. Dans ce cas, installer une version expérimentale ou attendre septembre 2026 n’apporte aucun bénéfice immédiat. Le bon choix consiste à terminer l’analyse, exporter les résultats et enregistrer les informations de l’environnement.

À l’inverse, une équipe qui prépare une nouvelle salle de travaux dirigés dispose d’un autre calendrier. Elle peut réserver une machine pilote, tester SPSS 32.0.0 sous Rosetta, puis préparer une seconde image pour SPSS 32.0.1. Elle évite ainsi de transformer la rentrée en migration générale non testée.

La base de référence doit utiliser un véritable échantillon du projet, et non une simple ouverture réussie de SPSS. Sélectionnez un fichier qui couvre les opérations réellement utilisées par votre équipe : importation, nettoyage, procédure statistique principale, graphique, export et exécution d’une syntaxe.

Procédez dans cet ordre :

1. Relevez l’état exact du poste. Notez la version SPSS, la version de macOS, le modèle de licence et le mode de lancement observé. Ne déduisez pas l’architecture uniquement de la présence d’une puce M1, M2, M3 ou M4.
2. Archivez les éléments du projet. Conservez le fichier SAV, la syntaxe SPS, les scripts Python ou R, les dictionnaires de variables et les extensions utilisées. Ajoutez les réglages d’affichage et d’export.
3. Exécutez le scénario de référence. Importez les mêmes données, lancez les mêmes commandes et exportez les mêmes tableaux et graphiques. Si une analyse dépend d’un tirage aléatoire, consignez la graine utilisée.
4. Conservez les preuves. Enregistrez les journaux, les sorties et les fichiers intermédiaires. La comparaison sera impossible si vous ne gardez que le résultat final en PDF.
5. Définissez un seuil d’arrêt. Si une procédure donne un résultat différent, si une extension refuse de se charger ou si l’export devient illisible, arrêtez la migration. Ne corrigez pas simultanément les données, les scripts et la version du logiciel.
6. Classez les éléments critiques. Séparez les fonctions indispensables à la thèse des outils secondaires. Une extension de mise en forme peut attendre ; un module qui modifie le modèle statistique ne le peut pas.

Pour un laboratoire, ajoutez une vérification administrative. La procédure IBM pour les licences utilisateur autorisées ne répond pas aux mêmes besoins que la procédure IBM pour les licences concurrentes. Vous devez donc confirmer le nombre d’utilisateurs, le serveur de licences éventuel, les droits d’accès à distance et les règles de l’établissement.

Expérience de déploiement : ne validez jamais une image de salle informatique avec le seul compte administrateur. Un étudiant peut rencontrer un problème de chemin, de licence ou d’extension que le compte de préparation ne révèle pas.

Le jour où SPSS 32.0.1 apparaît officiellement, ne lancez pas immédiatement une mise à niveau sur votre poste principal. Utilisez d’abord trois sources : la page de téléchargement IBM, les notes de version et les exigences système. Vérifiez la version affichée, la date de publication, la plage de versions macOS prise en charge et la nature du paquet.

Le nom du fichier ou une mention commerciale ne suffit pas pour prouver une exécution native. Dans les informations de l’application, cherchez une architecture arm64 ou Universal. Contrôlez ensuite les composants secondaires. Un programme principal arm64 peut encore appeler une extension Intel, un interpréteur Python, un module R ou un processus auxiliaire qui exige Rosetta.

La licence doit aussi être revue. Une migration technique ne modifie pas automatiquement vos droits d’utilisation. Pour un établissement, vérifiez les conditions de la licence existante, la coexistence de l’ancienne version et de la nouvelle, ainsi que la possibilité d’utiliser une machine distante. En cas de contradiction, la documentation d’installation IBM de la version publiée prévaut sur les habitudes du laboratoire.

Pendant la première semaine, travaillez sur une copie isolée. Réutilisez exactement le même SAV, la même syntaxe SPS, les mêmes paramètres de sortie et, pour les analyses concernées, la même graine aléatoire. Comparez les éléments qui peuvent être négligés dans une vérification rapide :

• valeurs et arrondis des tableaux statistiques ;
• ordre et intitulés des variables ;
• graphiques, polices et caractères accentués ;
• exports PDF, CSV, Excel et formats d’image ;
• exécution des scripts Python et R ;
• chargement des extensions et modules personnalisés ;
• journaux d’erreur et messages d’avertissement.

Si le programme principal est natif mais qu’une extension critique reste incompatible, votre environnement n’est pas migré. Notez le problème dans un fichier minimal reproductible : données réduites, syntaxe courte, extension concernée et message exact. Consultez ensuite les correctifs IBM avant de choisir entre trois actions : continuer le pilote, revenir à l’environnement de référence ou attendre une correction.

La bonne question n’est pas « la fenêtre s’ouvre-t-elle ? », mais « le résultat de recherche reste-t-il explicable et reproductible ? ». Pour une publication, une variation graphique mineure peut être acceptable ; une différence dans les coefficients, les degrés de liberté ou les valeurs de significativité exige une investigation avant toute adoption.

Utilisez les conditions suivantes comme outil de décision :

• Si votre cours, votre soutenance ou votre réponse aux reviewers intervient avant la publication officielle de SPSS 32.0.1, choisissez SPSS 32.0.0 dans l’environnement déjà validé. Archivez l’état du poste et ne remplacez pas votre seule installation.
• Si vous avez un Mac Apple Silicon neuf, aucun projet urgent et une équipe capable de tester, préparez un environnement parallèle. N’effacez l’ancien poste qu’après la comparaison des résultats et des extensions.
• Si la version 32.0.1 est officiellement disponible, mais que l’architecture ou les exigences macOS restent ambiguës, reportez la bascule générale et installez-la uniquement sur une machine pilote.
• Si SPSS fonctionne, mais que Python, R ou une extension essentielle échoue, revenez à la version de référence. La compatibilité du programme principal ne suffit pas.
• Si votre établissement prépare macOS 28 ou une image durable pour plusieurs années, commencez la migration avant le déploiement général. La fenêtre de compatibilité Rosetta ne doit pas devenir une dépendance permanente.
• Si vous n’avez aucun Mac Apple Silicon disponible pour les essais, demandez d’abord si votre licence universitaire autorise une utilisation distante, puis utilisez une machine indépendante pour la validation au lieu d’acheter immédiatement du matériel.

Pour une équipe qui doit simplement expérimenter pendant une période limitée, une machine Mac distante pour un environnement de test peut servir de poste pilote. Cette option ne remplace pas une analyse de licence : l’autorisation de l’établissement doit être obtenue avant l’accès distant.

SPSS 32 est-il déjà natif sur Apple Silicon ?

La sortie de SPSS 32.0.0 est confirmée, mais elle ne prouve pas que le paquet actuellement disponible est arm64 ou Universal. La version native est évoquée dans une discussion officielle IBM comme une évolution prévue avec SPSS 32.0.1. Attendez les notes de version et vérifiez l’application installée avant de modifier votre procédure de déploiement.

Rosetta est-il obligatoire sur un Mac équipé d’une puce Apple ?

Pas nécessairement pour chaque composant, mais il peut rester indispensable si SPSS ou une extension fonctionne en Intel. Vérifiez l’architecture de l’application et des dépendances. Une installation qui démarre sans message d’erreur peut tout de même utiliser un composant traduit. Documentez cette situation dans votre base de migration afin de savoir ce qui devra être remplacé.

Faut-il patienter avant d’installer SPSS 32.0.0 ?

Non, si vous avez un travail avec une échéance ou si votre environnement actuel est stable. Installez la version prise en charge, conservez les fichiers de référence et planifiez une comparaison ultérieure. Attendre n’a de sens que pour un poste pilote sans urgence, lorsque vous pouvez accepter un retour arrière et consacrer du temps à la validation.

Les anciens projets doivent-ils être recalculés après le passage au natif ?

Oui, au moins sur un échantillon représentatif. Rejouez les syntaxes et comparez les sorties, notamment pour les extensions, les scripts et les exports. Ne réécrivez pas vos données en même temps que le logiciel. Sinon, vous ne saurez pas si une différence vient de SPSS, d’un module, d’un encodage ou d’une transformation de données.

Pour un étudiant qui possède déjà un Mac fonctionnel, conserver SPSS 32.0.0 jusqu’à la fin du projet est souvent le choix le moins risqué. Pour un laboratoire, le double environnement est plus exigeant, mais il protège la reproductibilité : une image ancienne pour les analyses en cours, une image pilote pour la version native et un protocole commun de comparaison.

Si votre équipe ne dispose d’aucun M Series Mac pour réaliser cette validation, l’achat immédiat n’est pas forcément rationnel. Il immobilise un budget, nécessite une configuration durable et ne résout pas automatiquement la question des licences ou des extensions. Une période de location auprès de KVMNODE peut être plus adaptée lorsque vous devez seulement exécuter une campagne de tests, vérifier un SAV et comparer des exports pendant une durée définie. Vous pouvez consulter les options de Mac distant disponibles pour un laboratoire, puis vérifier avec votre établissement si cet usage respecte la licence SPSS.

Cette solution a aussi ses limites : elle convient moins à une charge lourde permanente, à un besoin d’interface physique, à des périphériques spécialisés ou à une équipe qui doit conserver la machine pendant plusieurs années. Dans ces cas, l’achat d’un Mac local ou un déploiement institutionnel reste plus cohérent.

La décision finale doit donc réunir quatre preuves : votre échéance de recherche, la cohérence des résultats, la compatibilité des extensions et le périmètre de la licence. Tant que SPSS 32.0.1 n’est pas officiellement publié et validé sur votre workflow, poursuivez vos travaux avec SPSS 32.0.0 ; lorsque le paquet sera disponible, migrez par double environnement, puis généralisez seulement après la régression complète.