Migration Rosetta des logiciels scientifiques avant macOS 28

Apple indique que Rosetta restera disponible comme solution générale de traduction des applications Intel jusqu’à macOS 27, tandis que les versions ultérieures ne conserveront qu’une partie destinée à certains anciens jeux. (documentation Apple sur l’environnement Rosetta)

Symptôme : votre logiciel scientifique, votre plug-in audio ou votre outil en ligne de commande fonctionne encore grâce à Rosetta, mais personne ne sait si toute la chaîne supportera macOS 28.

Solution la plus rapide : en 2026, inventez votre migration en trois temps : inventoriez les composants Intel, testez une installation native sur un environnement Apple Silicon séparé, puis conservez macOS 27 tant que la reproduction des résultats n’est pas validée.

Dernière mise à jour : 16 août 2026. Les informations sur Rosetta, macOS 27 et la transition Apple Silicon ont été vérifiées à partir de la documentation Apple sur l’environnement de traduction Rosetta, de l’assistance Apple consacrée aux applications Intel et des documents officiels des éditeurs cités.

SECTION 01À qui s’adresse cette feuille de route ?

Cette procédure concerne les étudiants, doctorants et chercheurs qui dépendent encore d’une application Intel, d’un ancien plug-in, d’un pilote matériel ou d’un binaire compilé pour x86_64.

Elle s’adresse également aux personnes qui administrent un Mac partagé dans un laboratoire, ainsi qu’aux équipes qui développent des outils de recherche et doivent vérifier leur comportement sur Apple Silicon avant une mise à niveau système.

Ne traitez pas cette migration comme une simple mise à jour d’application. Dans un environnement scientifique, une installation peut sembler correcte tout en échouant au moment de charger un plug-in, de compiler une extension, de lire un ancien format de fichier ou de reproduire exactement une analyse déjà publiée.

SECTION 02Ce que la fin de Rosetta change réellement

Une application qui s’ouvre n’est pas nécessairement compatible

Dans le Finder, la commande « Lire les informations » permet de distinguer trois cas :

Application (Apple silicon) : le programme est compilé pour arm64 et peut s’exécuter nativement ;
Application (Universal) : le paquet contient des versions Apple Silicon et Intel ;
Application (Intel) : le programme dépend encore de la traduction Rosetta sur un Mac Apple Silicon.

Apple précise aussi qu’une application Universal peut être forcée à s’ouvrir avec Rosetta pour utiliser un ancien plug-in ou une extension Intel. Cette option peut donc masquer une dépendance qui n’apparaît pas dans l’architecture principale de l’application. (assistance Apple sur les applications Intel)

La conséquence est importante pour votre migration des logiciels scientifiques avant macOS 28 : vous devez examiner l’ensemble du processus, et non seulement l’icône du logiciel.

Un traitement peut dépendre simultanément :

de l’application graphique ;
d’un plug-in ou d’une extension ;
d’un script d’installation ;
d’une bibliothèque dynamique ;
d’un compilateur externe ;
d’un outil lancé depuis le Terminal ;
d’un pilote ou d’une extension système ;
d’un format de données ancien.

Rosetta traduit le processus dans son ensemble. Apple indique qu’un même processus ne peut pas mélanger librement du code arm64 et du code x86_64. Un plug-in Intel peut donc imposer que l’application entière soit lancée sous Rosetta, même si son programme principal est déjà Universal. (documentation Apple sur les limites architecturales de Rosetta)

Les composants bas niveau sont les plus exposés

Rosetta ne traduit pas toutes les catégories de logiciels. La documentation Apple exclut notamment les extensions de noyau et les applications de machines virtuelles qui virtualisent des plateformes x86_64. (documentation Apple sur Rosetta et les composants non traduits)

Pour un laboratoire, cela crée au moins trois risques différents :

Risque de lancement : l’application ne s’ouvre plus ou affiche une alerte dès la mise à niveau ;
Risque fonctionnel : l’application s’ouvre, mais un module, un export ou une interface matérielle ne fonctionne plus ;
Risque scientifique : le traitement s’exécute, mais les résultats, les paramètres ou la chaîne de reproductibilité diffèrent.

Le troisième risque est souvent le plus difficile à détecter. Un outil d’analyse audio peut encore lire un fichier mais perdre un module de traitement. Un logiciel de vidéo ou de design peut ouvrir un projet tout en remplaçant silencieusement une police, un codec ou un plug-in. Une chaîne de bio-informatique peut produire un fichier de sortie sans signaler qu’une dépendance externe n’a pas été chargée.

SECTION 03Phase actuelle : l’inventaire des dépendances Intel

Le registre de migration à créer

Ne commencez pas par installer une nouvelle version du système. Commencez par créer un registre exploitable par une autre personne du laboratoire.

Pour chaque logiciel ou composant, consignez :

le nom exact et la version actuellement utilisée ;
la personne responsable du projet ;
l’origine de l’installation ;
l’architecture détectée ;
la licence ou le compte nécessaire ;
les plug-ins, modules et extensions associés ;
les formats d’entrée et de sortie ;
les scripts ou commandes externes appelés ;
le matériel éventuellement utilisé ;
la dernière version officiellement compatible avec votre système ;
l’existence d’une version Apple Silicon ou Universal ;
le niveau de criticité pour les expériences en cours.

Vous pouvez attribuer à chaque ligne un niveau simple :

Critique : l’expérience ne peut pas être relancée ailleurs et aucun remplacement n’est disponible ;
Important : une alternative existe, mais elle doit être validée sur des données comparables ;
Secondaire : le composant peut être remplacé ou retiré sans affecter les résultats principaux.

Cette classification doit être fondée sur l’impact réel du projet, pas sur la popularité du logiciel. Un ancien outil utilisé une seule fois par mois peut être plus critique qu’une application quotidienne si une thèse dépend de ses fichiers propriétaires.

Comment repérer une dépendance à Rosetta ?

Commencez par sélectionner chaque application dans le Finder, ouvrez « Lire les informations » et vérifiez la ligne « Type ». Pour une application Universal, contrôlez également si l’option « Ouvrir avec Rosetta » est activée.

Complétez cette vérification par l’examen des composants installés dans les dossiers utilisés par votre domaine. Pour l’audio, vérifiez notamment les plug-ins VST, Audio Units et ARA. Pour le traitement d’image, contrôlez les modules d’importation, les extensions et les composants de prévisualisation. Pour les outils de développement scientifique, recherchez les bibliothèques, exécutables et extensions compilés séparément.

Vous pouvez aussi analyser les binaires depuis le Terminal avec des commandes comme file ou lipo -info, puis conserver la sortie dans votre registre. L’objectif n’est pas de produire un rapport technique décoratif, mais de pouvoir répondre à cette question : « Quel élément précis empêcherait cette expérience de fonctionner sans Rosetta ? »

Pour les applications que vous développez, Apple fournit également une méthode programmatique permettant de déterminer si un processus s’exécute sous traduction, avec le paramètre sysctl.proc_translated. (documentation Apple sur la détection d’un processus traduit)

Expérience de terrain : ne concluez jamais qu’un logiciel est natif uniquement parce qu’il démarre. Vérifiez au moins un parcours complet avec ouverture des données, exécution du traitement, export du résultat et relecture du fichier produit.

SECTION 04Première détection : les preuves à réunir

Les documents des éditeurs priment sur les suppositions

Après l’inventaire local, consultez la documentation actuelle de chaque éditeur. Recherchez précisément les mentions « Apple Silicon », « native », « Universal », « Rosetta », « Intel Mac », « plug-in compatibility » et « supported macOS versions ».

Ne déduisez pas la compatibilité d’un logiciel à partir d’un autre logiciel du même domaine. Le fait qu’un environnement statistique soit natif ne prouve pas que ses extensions, bibliothèques compilées ou interfaces externes le soient également.

MATLAB constitue un exemple utile de dépendance à vérifier séparément. MathWorks indique que la version native Apple Silicon est disponible à partir de MATLAB R2023b, mais précise aussi que certains produits, toolboxes et support packages ne sont pas disponibles sur Apple Silicon. MathWorks indique par ailleurs que MATLAB R2025b est la dernière version prenant en charge les Mac Intel, tandis que R2026a et les versions suivantes ne sont plus disponibles pour cette plateforme. (exigences officielles de MATLAB pour Apple Silicon)

Cet exemple ne permet pas de conclure pour les autres logiciels. Il montre seulement pourquoi votre registre doit distinguer :

le programme principal ;
les extensions officielles ;
les modules expérimentaux ;
les compilateurs ;
les interfaces avec du matériel ;
les scripts d’automatisation.

Le cas des outils audio, vidéo et design

Les projets de recherche ne sont pas limités aux logiciels de calcul. Les laboratoires qui produisent des enregistrements, des vidéos de protocole ou des supports de visualisation peuvent dépendre de plug-ins anciens, de codecs ou de modules propriétaires.

Dans un workflow audio, testez la chaîne complète : importation d’un enregistrement, chargement du plug-in, traitement, rendu et réouverture du projet. Dans un workflow vidéo, ajoutez les codecs, les sous-titres, les profils colorimétriques et l’export vers le format utilisé par l’équipe. Pour le design scientifique, vérifiez les polices, les bibliothèques de symboles, les scripts et les formats destinés à la publication.

Cette étape évite un faux positif fréquent : l’application principale est Apple Silicon, mais le plug-in critique reste Intel. Dans ce cas, le logiciel peut fonctionner uniquement avec « Ouvrir avec Rosetta », ou refuser le chargement du module lorsque le processus est lancé nativement.

SECTION 05Première semaine : l’environnement Apple Silicon isolé

Ne remplacez pas l’environnement qui produit vos résultats

Installez la version native dans un environnement séparé du Mac qui sert encore aux expériences. Vous devez pouvoir revenir à l’état validé sans restaurer précipitamment toute la machine.

L’environnement de test peut être un Mac Apple Silicon dédié, une installation distincte lorsque cela correspond à votre politique informatique ou une machine distante administrée séparément. Pour un besoin temporaire, un Mac distant peut également servir à isoler les essais, à condition de vérifier à l’avance le système disponible, les droits administrateur, l’accès réseau et le délai de mise à disposition.

Une solution distante ne remplace pas automatiquement un poste local. Elle convient mieux à une validation logicielle, à une installation reproductible ou à un test qui ne dépend pas d’un instrument connecté physiquement. Elle est moins adaptée à une expérience nécessitant une carte d’acquisition, un dongle, une caméra spécialisée ou une latence très faible.

Le protocole de test minimal

Utilisez un jeu de données public ou une copie désensibilisée d’un projet réel. Ne testez pas uniquement une démonstration fournie par l’éditeur : elle peut éviter précisément les fonctions qui posent problème dans votre laboratoire.

Enregistrez :

la version du système ;
la version de chaque composant ;
la méthode d’installation ;
les dépendances téléchargées ;
les permissions demandées ;
les commandes utilisées ;
les journaux d’exécution ;
les fichiers générés ;
les erreurs et avertissements ;
la personne qui a confirmé le résultat.

Pour R, MATLAB et les outils avec extensions compilées, traitez séparément le programme, les packages, les toolboxes, les bibliothèques natives et les compilateurs externes. Une installation réussie ne constitue pas une validation tant qu’un jeu de données représentatif n’a pas traversé toute la chaîne.

SECTION 06Avant la mise à niveau : la régression en double environnement

Le protocole de comparaison

Exécutez le même scénario dans l’environnement Intel actuel et dans l’environnement Apple Silicon natif. Conservez les mêmes fichiers d’entrée, les mêmes paramètres, la même version des données de référence et, lorsque c’est possible, les mêmes scripts.

Comparez quatre éléments :

la capacité à terminer le traitement ;
la présence ou l’absence de fonctions clés ;
la structure et l’intégrité des fichiers de sortie ;
la possibilité de reproduire les résultats attendus.

Ne cherchez pas seulement une égalité binaire parfaite. Certains calculs numériques peuvent présenter de petites différences liées à l’architecture, aux bibliothèques ou à l’ordre des opérations. En revanche, une différence dans le nombre d’échantillons, les métadonnées, les coefficients, les annotations ou les étapes appliquées doit être expliquée avant l’autorisation de migrer.

Pour un outil de développement scientifique, ajoutez la compilation, les tests automatisés et l’exécution sur une nouvelle installation. Pour une chaîne audio, ajoutez l’écoute comparative et la vérification des paramètres du plug-in. Pour un workflow vidéo ou design, comparez les exports finaux, les polices, les couleurs et les éléments liés.

Apple rappelle que les différences architecturales peuvent affecter le comportement de code dépendant d’hypothèses matérielles, de fonctions intrinsèques ou de valeurs codées en dur. Les équipes qui développent leurs propres outils doivent donc tester les chemins de calcul sensibles, et pas seulement l’interface graphique. (documentation Apple sur les différences architecturales)

La checklist de décision

Utilisez cette liste avant de demander la mise à niveau du Mac principal. Chaque case doit être cochée par la personne responsable du logiciel ou du projet concerné.

[ ] Le programme principal est Apple Silicon ou Universal, et sa version est officiellement supportée.
[ ] L’option « Ouvrir avec Rosetta » n’est pas nécessaire pour les fonctions critiques.
[ ] Les plug-ins, extensions, bibliothèques dynamiques et outils en ligne de commande ont été vérifiés séparément.
[ ] Les scripts d’installation et d’automatisation fonctionnent dans l’environnement natif.
[ ] Les données historiques s’ouvrent sans conversion destructive.
[ ] Un jeu de données représentatif termine le traitement sans fonction manquante.
[ ] Les fichiers de sortie, métadonnées et paramètres sont comparables à ceux de l’environnement Intel.
[ ] Les outils externes, compilateurs, pilotes et interfaces matérielles ont reçu une validation distincte.
[ ] Une procédure de retour vers l’environnement validé a été documentée.
[ ] La personne responsable de l’expérience a signé le résultat de la régression.

Si toutes les cases critiques sont cochées, choisissez la migration native Apple Silicon.

Si seules les cases liées à un composant secondaire ne sont pas cochées, remplacez ce composant ou retirez-le du workflow, puis répétez le test avant la mise à niveau.

Si une case critique concernant un plug-in, un pilote, une bibliothèque ou un résultat scientifique reste vide, conservez l’environnement macOS 27 vérifié et interdisez la mise à niveau automatique du poste concerné.

Si le test est incomplet parce que vous ne disposez pas d’un Mac Apple Silicon séparé, créez d’abord un environnement de validation isolé, local ou distant, plutôt que d’utiliser le poste qui produit les résultats officiels.

Si les résultats diffèrent sans explication reproductible, arrêtez la migration, archivez les journaux et demandez une analyse au responsable du logiciel ou de la méthode.

SECTION 07Le jour de l’autorisation : migrer, doubler ou attendre

Critères de mise à niveau

Vous pouvez autoriser la migration lorsque les éléments suivants sont vérifiés :

le logiciel principal possède une version supportée ;
les plug-ins critiques sont natifs ou officiellement compatibles ;
les bibliothèques et outils en ligne de commande ont été contrôlés ;
les scripts d’installation et d’automatisation fonctionnent ;
les données existantes s’ouvrent sans conversion destructive ;
les exports ont été comparés ;
les utilisateurs responsables ont validé le scénario ;
une procédure de retour est disponible.

L’absence d’un seul élément ne signifie pas toujours qu’il faut bloquer toute l’équipe. Elle signifie que vous devez décider au niveau du projet, avec une trace écrite.

Trois conclusions sont possibles :

Migration native : tous les composants critiques sont validés et l’ancien environnement n’est plus nécessaire ;
Transition à double environnement : les nouveaux projets utilisent Apple Silicon, tandis que les expériences historiques ou les plug-ins restants utilisent macOS 27 ;
Mise à niveau différée : une dépendance essentielle reste Intel sans remplacement fiable.

Le cas des plug-ins Intel sans version native

Si un plug-in Intel n’a pas de version Apple Silicon, vérifiez d’abord s’il est réellement indispensable. Certaines fonctions peuvent être remplacées par un module natif, un export intermédiaire ou un script différent, mais cette décision doit être testée sur vos données.

Si le plug-in est indispensable, conservez le poste ou l’environnement qui a déjà produit des résultats vérifiés. Une application Universal lancée avec Rosetta peut parfois continuer à charger des modules Intel, mais cette solution dépend du cycle de vie de Rosetta et ne doit pas être confondue avec une stratégie durable. Apple recommande de mettre à jour les applications, plug-ins, extensions et modules complémentaires pour Apple Silicon afin d’améliorer la compatibilité future. (recommandations Apple pour les applications et modules complémentaires)

SECTION 08Maintien à long terme de la feuille de migration

Ne recréez pas votre inventaire à chaque nouvelle version du système. Ajoutez plutôt une colonne de suivi indiquant :

la dernière date de vérification ;
la source consultée ;
la version testée ;
la personne qui a validé ;
le résultat de la régression ;
la prochaine condition à surveiller.

Réexaminez la liste lorsqu’un éditeur publie une nouvelle version, lorsqu’un plug-in change de format ou lorsque Apple modifie ses informations de compatibilité. La question n’est pas seulement de savoir si macOS 28 est installé, mais si votre chaîne scientifique entière reste maîtrisée.

Les anciennes données ne deviennent pas automatiquement illisibles parce que le système change. Le risque apparaît lorsque l’application qui sait les ouvrir, le plug-in qui les interprète ou le composant qui les exporte n’est plus disponible. Conservez donc les fichiers d’entrée, les sorties de référence, les versions logicielles et les paramètres nécessaires à la reproduction.

Si votre laboratoire ne possède pas de Mac Apple Silicon disponible pour les essais, vous pouvez consulter les options de Mac distant proposées par MACNOX afin de créer un environnement séparé, avec les droits et le système nécessaires à votre protocole. Pour estimer la durée d’un test ou comparer une validation ponctuelle avec un usage plus long, reportez-vous aussi aux modalités de location Mac de MACNOX.

SECTION 09Quand un Mac distant est-il pertinent pour la migration ?

Un environnement loué à distance est particulièrement utile lorsque vous devez :

tester une version native sans interrompre le Mac du laboratoire ;
reproduire un projet désensibilisé ;
vérifier une installation Homebrew et ses dépendances ;
comparer une application Intel avec sa version Apple Silicon ;
valider une chaîne audio, vidéo ou design sans acheter immédiatement une nouvelle machine ;
permettre à plusieurs membres d’un projet de suivre la même procédure à distance.

Il est moins approprié lorsque votre expérience dépend d’un instrument USB spécifique, d’une carte d’acquisition locale, d’un écran calibré ou d’un transfert de données massif que votre politique de sécurité interdit.

Avant de louer, confirmez le système proposé, les permissions disponibles, la méthode d’accès, le stockage, les règles de transfert de données et la durée nécessaire à votre protocole. Pour un projet impliquant des données sensibles, utilisez uniquement une copie désensibilisée et faites valider le flux par votre établissement.

Pour une équipe qui doit simplement vérifier une migration, le coût organisationnel d’un environnement isolé peut être inférieur au risque d’interrompre un poste partagé. Vous pouvez consulter les solutions de test Mac à distance de MACNOX, puis décider si l’essai doit rester temporaire ou s’intégrer à votre plan de transition.

Votre environnement actuel — Mac Intel conservé sans plan de remplacement, poste partagé mis à niveau trop tôt ou machine virtuelle qui ne reproduit pas toutes les fonctions macOS — présente trois défauts réels : il entretient une dépendance à une architecture en retrait, il complique la reproduction des expériences et il ne révèle pas toujours les incompatibilités des plug-ins ou pilotes. Une location MACNOX peut offrir un environnement Apple Silicon séparé pour valider vos logiciels, vos scripts et vos données avant de toucher au poste principal. Ce n’est pas une réponse universelle aux besoins matériels, mais c’est une option cohérente lorsque votre priorité est de tester sans immobiliser l’expérience en cours.