Test macOS Tahoe 26 : compatibilité scientifique

Le démarrage n’est pas un critère d’acceptation

Un logiciel qui ouvre sa fenêtre ou affiche son aide en ligne de commande n’est pas encore validé. Le lancement prouve seulement que le point d’entrée de l’installation fonctionne dans les conditions observées. Il ne prouve ni que les extensions sont chargeables, ni que les fichiers sont accessibles, ni que le calcul produit une conclusion scientifique identique.

Avant le premier test, le responsable doit donc fixer quatre états distincts :

Les données d’entrée, les fichiers de sortie attendus, la graine aléatoire, les versions de dépendances et les conditions d’échec doivent être écrits avant l’exécution. Le terme « dernière version » est trop vague pour un procès-verbal : il faut inscrire séparément la version de macOS Tahoe 26, celle du logiciel scientifique, celle de l’interpréteur ou du compilateur et celle des bibliothèques critiques.

Un logiciel scientifique peut-il être déclaré compatible dès qu’il démarre ?
Non. Le minimum raisonnable est de faire passer un scénario représentatif de bout en bout, puis de vérifier les sorties, les journaux, les extensions, les fichiers produits et le comportement après interruption. Une installation réussie doit être classée « installable », jamais « validée ».

Première étape : figer la matrice de référence

La comparaison doit partir d’un environnement qui produit déjà un résultat accepté par l’équipe. Il peut s’agir d’un serveur Linux, d’une station Windows ou d’une ancienne machine macOS, mais la référence doit être décrite avec suffisamment de précision pour être reconstruite.

Cette préparation est particulièrement importante pour les analyses numériques, la bio-informatique, le traitement audio et vidéo ou les outils de visualisation. Une image qui paraît identique à l’écran peut cacher une différence dans un fichier exporté ; un modèle qui converge peut néanmoins utiliser une bibliothèque différente ; un projet audio peut s’ouvrir sans que l’interface avec un périphérique soit réellement opérationnelle.

Pour les outils développés en interne, la matrice doit inclure au moins un test d’installation propre, un test de commande sans interface graphique, un test de projet réel et un test de réouverture après redémarrage.

Deuxième étape : vérifier Apple Silicon, Intel et Rosetta

La présence d’un Mac équipé d’Apple Silicon ne signifie pas que tous les composants s’exécutent nativement. Le programme principal, les outils en ligne de commande, les bibliothèques dynamiques, les extensions et les modules installés séparément peuvent avoir des architectures différentes.

La documentation officielle explique qu’un binaire universel contient des tranches arm64 et x86_64, tandis qu’un exécutable limité à x86_64 est lancé sous Rosetta sur Apple Silicon. Elle précise également que les modules chargés dans un même processus ne peuvent pas mélanger librement du code arm64 et x86_64. Voir la documentation Apple sur les binaires universels et l’environnement de traduction Rosetta.

Pour examiner un exécutable, la commande suivante fournit une première preuve :

file /chemin/vers/outil
lipo -archs /chemin/vers/outil

Sortie indicative :

/chemin/vers/outil: Mach-O 64-bit executable arm64
arm64

Ou, pour un binaire universel :

x86_64 arm64

Il faut répéter l’opération sur les fichiers réellement exécutés, et non seulement sur l’application visible dans le Finder :

find MonApplication.app -type f \( -perm -111 -o -name "*.dylib" \) -print

Le rapport doit distinguer les cas suivants :

• natif Apple Silicon : le composant possède une tranche arm64 et s’exécute sans traduction ;
• natif Intel : le composant est limité à x86_64 et dépend de Rosetta ;
• universel : les deux architectures sont présentes, mais les extensions chargées doivent encore être contrôlées ;
• architecture inconnue ou incompatible : le fichier n’est pas chargeable dans le contexte prévu.

Comment vérifier qu’un logiciel scientifique prend réellement en charge Apple Silicon ?
Il faut combiner trois éléments : l’annonce officielle du projet, l’inspection des binaires et l’exécution du scénario critique sur une machine Apple Silicon. La mention « fonctionne sur Mac » ne suffit pas, car elle peut désigner uniquement une version Intel exécutée sous Rosetta.

Rosetta peut être utile pour un contrôle transitoire, mais elle ne doit pas masquer une dépendance non maintenue. Apple indique que macOS Tahoe 26 est la dernière version prenant en charge les Mac Intel et que Rosetta est prévue pour accompagner la transition jusqu’à macOS 27, avec des limites pour certains exécutables, notamment les extensions noyau et les applications de virtualisation x86_64. Ces limites doivent être reportées dans la décision, et non reléguées dans une note secondaire.

Les dépendances et les autorisations doivent être testées séparément

L’installation d’un paquet ne prouve pas que ses dépendances sont conformes. Pour un outil Python ou R, le test doit vérifier l’interpréteur utilisé, l’architecture des paquets compilés, les variables d’environnement et le fichier de verrouillage. Pour un projet C ou C++, il faut examiner les bibliothèques dynamiques, les chemins de recherche, les options du compilateur et la signature du produit.

Un contrôle de base peut être enregistré ainsi :

sw_vers
uname -m
which python3
python3 --version
otool -L /chemin/vers/outil

Sortie à conserver dans le journal :

ProductVersion: 26.x
arm64
/usr/bin/python3
Python 3.x.x

Les valeurs exactes doivent provenir de la machine testée et ne doivent pas être remplacées par une valeur générique dans le rapport final.

Les autorisations doivent être vérifiées pour cinq actions :

1. premier lancement de l’application ;
2. accès aux fichiers de données et aux répertoires de sortie ;
3. appel depuis le terminal ou un script ;
4. exécution d’une tâche en arrière-plan ;
5. reprise après fermeture ou redémarrage.

Lorsqu’une alerte de sécurité bloque un binaire, le message original doit être conservé. Une procédure de contournement ne doit être appliquée que si elle est documentée par la source officielle du système ou du logiciel, avec une indication claire de son périmètre. Une commande copiée depuis un forum ne constitue pas une politique d’acceptation.

Troisième étape : comparer les résultats, pas seulement le temps d’exécution

Le cœur d’une validation scientifique est la cohérence de la sortie. Le même jeu de données doit être traité dans l’environnement de référence puis sur macOS Tahoe 26, avec la même commande, les mêmes paramètres et, lorsque le logiciel le permet, la même graine aléatoire.

La comparaison doit couvrir :

• les fichiers de résultats ;
• les journaux et codes de retour ;
• les valeurs manquantes et les valeurs extrêmes ;
• les métadonnées ;
• les figures exportées ;
• les rapports finaux ;
• les écarts numériques intermédiaires si le projet les expose.

Il ne faut pas imposer une tolérance unique à tous les logiciels. Une variation flottante bénigne dans une visualisation ne se juge pas comme une variation qui change une classification, un appel de variant, une mesure audio ou une conclusion statistique. Le seuil doit venir de la documentation du logiciel, de la méthode scientifique ou d’une décision validée par l’équipe.

Un contrôle d’intégrité simple peut compléter la comparaison :

shasum -a 256 resultat-macos.dat
shasum -a 256 resultat-reference.dat
diff -u journal-reference.txt journal-macos.txt

Si les sommes diffèrent, cela ne signifie pas automatiquement que le calcul est faux. Il faut ensuite comparer le contenu selon le format : lignes numériques, ordre des éléments, précision affichée, horodatage, identifiant de machine ou informations non déterministes.

Comment diagnostiquer des résultats différents entre Linux, Windows et macOS ?
La recherche doit suivre une progression contrôlée : vérifier d’abord les versions et les fichiers d’entrée, puis les dépendances compilées, les paramètres régionaux, l’ordre parallèle, la graine aléatoire et enfin les différences d’architecture. Une différence qui apparaît uniquement avec une bibliothèque native ou un module x86_64 doit être isolée dans un scénario minimal avant toute conclusion sur le système.

Pour les chercheurs qui développent un outil, le dépôt doit conserver la commande complète, les fichiers de verrouillage et l’identifiant du jeu de données. Une simple capture d’écran n’offre pas assez de matière pour une revue ou une reproduction ultérieure.

Les tests automatisés filtrent les erreurs, mais ne remplacent pas l’acceptation réelle

Les tâches automatisées sont utiles pour détecter rapidement une erreur de compilation, un paquet absent, une commande invalide ou une régression élémentaire. Les exécuteurs macOS documentés par GitHub proposent des images Intel et arm64, mais les images -latest ne sont pas nécessairement identiques à la version la plus récente publiée par l’éditeur du système. La documentation signale aussi des différences de capacités entre architectures et l’absence de certaines fonctions réseau ou d’identification matérielle sur les exécuteurs arm64. Voir la référence officielle des exécuteurs hébergés.

Un flux automatisé peut ressembler à ceci :

name: validation-macos

on:
  push:
  pull_request:

jobs:
  test-macos:
    runs-on: macos-26
    steps:
      - uses: actions/checkout@v4
      - name: Vérifier l’architecture
        run: uname -m
      - name: Exécuter les tests
        run: ./scripts/test-scientifique.sh
      - name: Archiver les journaux
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: journaux-macos
          path: logs/

L’automatisation macOS peut-elle remplacer un vrai Mac pour l’acceptation ?
Non. Elle peut constituer le premier filtre, mais elle ne couvre pas nécessairement l’interface graphique complète, les autorisations interactives, la reconnexion distante, les périphériques audio, les instruments USB, les accélérations graphiques ou les comportements après une longue session. Une tâche automatisée peut donc être « verte » alors que le workflow réel échoue.

Lorsque le laboratoire ne possède pas de Mac, le séquencement recommandé est le suivant :

1. exécuter les tests unitaires et d’intégration dans l’environnement automatisé ;
2. identifier les dépendances ou fonctions qui nécessitent une session graphique ;
3. vérifier les résultats sur un Mac Apple Silicon réel ;
4. répéter le scénario après interruption, reconnexion et redémarrage ;
5. conserver les journaux et décider du niveau de mise à disposition.

Un guide de construction d’une matrice de test scientifique sans Mac local peut servir de point de départ pour organiser les environnements, les responsables et les preuves attendues.

Quatrième étape : tester l’interaction distante et les tâches longues

Une validation à distance doit reproduire l’usage réel, pas seulement l’ouverture d’une fenêtre. Il faut contrôler la saisie au clavier, le presse-papiers, le transfert de fichiers, l’affichage d’un graphique, l’appel d’un terminal, la fermeture de session et la reconnexion.

Les cas audio et vidéo méritent une attention particulière. Un outil de traitement audio peut fonctionner avec des fichiers importés tout en échouant lors de l’accès à une interface audio locale. De même, un logiciel de vidéo peut produire un rendu correct sans offrir le même comportement avec une caméra, un écran externe ou une accélération graphique particulière.

Les instruments de laboratoire connectés par USB, série ou réseau doivent être classés à part. Un Mac distant peut être adapté à l’analyse de fichiers déjà collectés, mais il ne remplace pas automatiquement une station située physiquement à côté d’un spectromètre, d’une carte d’acquisition ou d’un contrôleur.

Pour une tâche qui dure plusieurs heures, le journal doit préciser :

• si le processus reste actif après la fermeture du client distant ;
• si le résultat partiel est conservé ;
• si la reconnexion permet de retrouver l’état de la tâche ;
• si le fichier de journal reste complet ;
• si une coupure réseau est distinguée d’un plantage logiciel.

La latence est un problème d’usage ; un échec de chargement de bibliothèque est un problème de compatibilité. Les deux événements ne doivent pas être consignés sous la même cause.

La décision finale doit suivre des conditions explicites

Une fois les indicateurs collectés, la conclusion peut être formulée avec trois niveaux :

• Accepté : le workflow critique fonctionne, les résultats sont justifiés, les dépendances sont documentées et les essais de reprise sont satisfaisants ;
• Accepté sous conditions : une dépendance Rosetta, une autorisation manuelle ou une limite d’interaction subsiste, mais elle est connue, reproductible et compatible avec l’usage prévu ;
• Non accepté pour le moment : une sortie scientifique diverge sans explication, une extension essentielle ne se charge pas, une tâche longue ne peut pas être récupérée ou une fonction matérielle indispensable est absente.

La décision peut être prise avec les règles suivantes :

• Si le programme est natif Apple Silicon, les dépendances sont identifiées et les résultats concordent, alors poursuivre vers l’acceptation complète.
• Si le programme fonctionne seulement sous Rosetta mais que les résultats et les extensions sont validés, alors accepter sous condition et documenter la dépendance.
• Si une bibliothèque essentielle est uniquement x86_64 et refuse de se charger, alors revenir à une version de dépendance compatible ou suspendre la livraison.
• Si les tests automatisés réussissent mais que l’interaction graphique, l’audio, la vidéo ou l’équipement distant n’est pas équivalent, alors organiser une validation sur un Mac réel.
• Si le résultat diffère et que l’écart n’est pas expliqué par la méthode scientifique ou la documentation du logiciel, alors classer le logiciel « non accepté », même si l’installation et le lancement sont réussis.

Le guide sur les dépendances Apple Silicon des logiciels scientifiques peut compléter cette étape lorsque le problème vient d’un mélange de bibliothèques natives et Intel.

Fiche de clôture à copier dans le registre d’acceptation

Logiciel :
Version du logiciel :
Version exacte de macOS Tahoe 26 :
Modèle du Mac :
Architecture : arm64 / x86_64 / universelle
Statut Rosetta : non requis / requis / non vérifié
Interpréteur ou compilateur :
Fichier de verrouillage :
Jeu de données et somme SHA-256 :
Commande complète :
Fonctions testées :
Résultats comparés :
Écarts observés :
Autorisations demandées :
Test graphique :
Test terminal :
Test transfert de fichiers :
Test audio, vidéo ou périphérique :
Test après déconnexion :
Test après redémarrage :
Journaux archivés :
Décision : accepté / accepté sous conditions / non accepté
Conditions et responsable du suivi :
Date de réexamen :

Si l’environnement actuel est un serveur Linux ou une station Windows, il peut rester excellent pour le calcul quotidien, l’automatisation et le stockage. Ses limites apparaissent toutefois lorsqu’il faut vérifier le comportement macOS natif, les autorisations graphiques, les bibliothèques Apple Silicon, Rosetta, les extensions de bureau ou une chaîne audio et vidéo conçue pour Mac. Une machine virtuelle ne reproduit pas toujours les mêmes contraintes, tandis qu’un pipeline automatisé ne couvre pas les manipulations interactives.

Après conception de la matrice, le choix le plus rationnel pour un laboratoire sans Mac est donc souvent de louer temporairement un véritable poste distant avec des droits complets, d’exécuter l’acceptation finale pendant la période prévue, puis de décider seulement ensuite s’il faut acheter une machine dédiée. NodeMini permet d’examiner cette option pour un besoin temporaire de test, de validation ou de reproduction, sans confondre une location ponctuelle avec une solution adaptée à une charge permanente ou à un instrument physique local.