CSD Portfolio 2026.1.1 fonctionne-t-il sur macOS 27 ? Liste de contrôle universitaire 2026

Symptôme — CSD Portfolio 2026.1.1 démarre sur votre Mac, mais vous ne savez pas si votre laboratoire peut adopter macOS 27 sans risque.

Réponse rapide — au 30 septembre 2026, la documentation officielle répertorie macOS 14, 15 et 26 comme systèmes pris en charge, mais pas macOS 27. Ne validez donc pas une migration sur le seul critère du lancement : testez d’abord vos flux de travail dans un environnement isolé et attendez une confirmation officielle avant de basculer le poste de référence.

À qui s’adresse cette procédure ? Aux étudiants et chercheurs qui utilisent Mercury ou ConQuest pour leurs travaux de structure, ainsi qu’aux personnes chargées de vérifier les logiciels du laboratoire.
Elle est particulièrement utile si vos analyses, vos exports ou vos scripts doivent rester reproductibles après une mise à niveau.

SECTION 01Ce que les informations officielles permettent réellement de conclure

La page de compatibilité macOS de CCDC indique que CSD Portfolio 2026.1.1 prend en charge macOS 14, 15 et 26. Elle précise également que cette version inclut un binaire universel conçu pour les Mac à puce de la série M. macOS 27 n’y figure pas. Cette absence ne prouve pas que le logiciel ne peut pas démarrer ; elle signifie que vous ne disposez pas, dans cette page, d’une confirmation de prise en charge pour ce système.

La distinction compte pour l’acceptation en laboratoire :

• Installation ou démarrage réussi : le programme s’ouvre dans votre environnement. Cela ne vérifie ni tous les composants ni le traitement complet de vos fichiers.
• Version officiellement prise en charge : le système figure dans la documentation de l’éditeur. C’est un élément nécessaire pour une migration maîtrisée, mais cela ne remplace pas la validation de vos procédures locales.
• Flux de travail accepté : les tâches utiles à votre équipe aboutissent, les résultats sont contrôlés et les conditions de fonctionnement sont consignées.

Apple a annoncé macOS 27 en septembre 2026 et son relevé destiné aux développeurs indique la mise à jour macOS 27.0.1 publiée le 28 septembre 2026. Vous pouvez vérifier ces éléments dans le journal officiel des versions Apple. Ils renseignent sur la disponibilité du système, pas sur la compatibilité de CSD Portfolio.

Autre point important pour un Mac de la série M : le binaire universel de CSD Portfolio ne signifie pas que chacun de ses composants fonctionne nativement. Selon la documentation de compatibilité de CCDC, ConQuest utilise encore Rosetta dans la version 2026.1.1, contrairement aux composants concernés par le binaire universel. Traitez donc ConQuest comme une dépendance à tester à part, sans déduire son comportement de celui de Mercury.

CSD Portfolio 2026.1.1 est-il officiellement pris en charge sur macOS 27 ? D’après la page de prise en charge vérifiée pour cette procédure, macOS 27 n’est pas répertorié. La conclusion opérationnelle est « compatibilité non confirmée », et non « logiciel inutilisable » ou « compatibilité acquise ».

Pour préparer une décision sans confondre ces niveaux, consultez aussi la documentation des exigences système et plateformes prises en charge par CCDC. Avant de lancer vos essais, vérifiez que cette page et la page macOS reflètent toujours l’état officiel : une mise à jour peut modifier la décision à prendre, mais votre protocole de vérification reste nécessaire pour les usages propres au laboratoire.

SECTION 02Scénario : ouvrir une structure, l’examiner et livrer une figure

Ne commencez pas par un fichier choisi au hasard. Prenez un CIF représentatif, déjà associé à un résultat connu et dont vous êtes autorisé à utiliser une copie pour les essais. Conservez le fichier source, les paramètres pertinents, la figure de référence et le chemin d’export habituel. Le but est de vérifier le résultat du travail, pas seulement l’apparence générale de l’application.

Pour Mercury, contrôlez les opérations que votre équipe réalise effectivement : ouverture du CIF, affichage de la structure, manipulation de la vue, application des réglages utilisés dans le groupe, puis création et réouverture du fichier graphique exporté. Comparez le nouvel export à la référence avec une méthode adaptée à votre discipline : vérifiez au minimum que la représentation attendue, les annotations nécessaires et les informations destinées à la publication ou au rapport sont présentes. Un affichage apparemment correct ne suffit pas si l’export perd un élément utile.

Sur macOS 27, Mercury peut-il servir à consulter une structure et exporter les résultats ? La documentation disponible ne permet pas de répondre par une garantie générale pour ce système. Vous devez vérifier ces tâches dans votre environnement cible et considérer l’export obtenu comme un résultat à contrôler, non comme la preuve que toute la suite est compatible.

Procédez ainsi :

1. Choisissez une référence contrôlée. Identifiez un CIF représentatif et une sortie produite avec l’environnement que le laboratoire utilise actuellement. Retirez les données sensibles ou utilisez un exemple public si la politique de votre établissement l’exige.
2. Reproduisez la séquence habituelle. Ouvrez le fichier dans Mercury, réalisez les actions nécessaires à votre analyse et notez les réglages qui influent sur la vue ou l’export.
3. Vérifiez les étapes, pas seulement l’écran final. Relevez si l’ouverture, la manipulation et l’enregistrement aboutissent séparément. Si une étape échoue, conservez le message obtenu et le contexte de l’essai.
4. Contrôlez les fichiers livrables. Rouvrez les exports produits et comparez-les à la référence du laboratoire. Vérifiez également que les noms, formats et emplacements conviennent à la chaîne de traitement réellement utilisée.
5. Rejouez l’essai dans les conditions prévues. Si les chercheurs travaillent depuis une session distante, répétez les gestes essentiels dans cette session. Ne supposez pas que la qualité d’un affichage local prédit le confort ou la fiabilité d’une connexion distante.

Les cas d’usage créatifs demandent parfois un contrôle différent : une équipe qui prépare des figures de structure pour une présentation audio-visuelle ou une vidéo de communication scientifique peut dépendre de réglages de vue et d’exports plus précis qu’un simple examen des coordonnées. Dans ce cas, ajoutez un exemple de livrable représentatif aux fichiers de référence et faites-le examiner par la personne qui le réutilisera. Ce contrôle porte sur votre chaîne de production ; il ne transforme pas le système en version officiellement prise en charge.

SECTION 03Scénario : rechercher dans ConQuest et transmettre à Mercury

Un résultat de recherche qui apparaît dans ConQuest n’a pas encore été validé comme résultat transférable. Pour votre essai, partez d’une requête connue ou d’un exemple dont vous pouvez interpréter les correspondances. Notez les critères appliqués, puis vérifiez successivement l’exécution de la recherche, l’affichage des résultats et leur passage vers Mercury.

Le passage d’un composant à l’autre est un point de contrôle à part entière. La procédure CCDC de transfert des résultats de ConQuest vers Mercury décrit le chemin de transfert à suivre. Utilisez-la pour comparer les actions attendues avec celles observées dans votre installation, puis vérifiez que le document ouvert dans Mercury correspond bien aux résultats transmis. Le fait que la fenêtre cible s’affiche ne prouve pas, à lui seul, que les données reçues sont complètes.

Comment vérifier que les résultats de ConQuest ont bien été transmis à Mercury ? Contrôlez le contenu final dans Mercury, pas uniquement le message de réussite ou le changement de fenêtre. Comparez les structures ouvertes aux résultats attendus et conservez séparément les observations sur l’interface, l’attente pendant le transfert et le fichier ou l’état obtenu. Une durée constatée lors d’un essai ne doit pas être présentée comme une performance générale : elle dépend notamment de la recherche, des données et de l’environnement.

Sur un Mac de la série M, consignez aussi que ConQuest s’exécute par l’intermédiaire de Rosetta dans cette version, selon les informations officielles de CCDC. Cette différence d’architecture justifie une vérification distincte de la recherche et du transfert ; elle ne permet pas de prévoir à elle seule le comportement de votre requête ou le temps nécessaire. Pour que le résultat soit reproductible, indiquez la requête de référence, les fichiers obtenus, les messages visibles et toute condition particulière qui a modifié l’essai.

SECTION 04Scénario : appeler l’API Python et relancer les scripts du laboratoire

L’application de bureau et l’API Python correspondent à des chemins d’exécution différents. Un Mercury qui s’ouvre correctement ne prouve pas que votre script peut importer l’API, trouver le bon interpréteur ou utiliser les dépendances attendues. Avant de tester, relevez la méthode d’installation de l’API, l’origine de l’interpréteur et la version de CSD Portfolio requise ; comparez ces éléments aux instructions officielles d’installation du CSD Python API.

Pour un premier contrôle, utilisez un script minimal sur un fichier public ou une copie expurgée. Vérifiez que l’environnement Python ciblé lance le script, que les imports requis aboutissent et que la sortie correspond à un résultat connu. N’incluez pas de données personnelles ou de fichiers de recherche confidentiels dans un rapport de dépannage qui pourrait sortir du cadre prévu par votre établissement.

Si votre procédure repose sur un environnement ancien, des modules externes ou une architecture particulière, consignez ces conditions et validez-les séparément. Évitez de réinstaller ou de mettre à niveau toutes les dépendances en même temps : si le test change, vous ne sauriez plus quelle modification explique le résultat. Le contrôle utile consiste à comparer un environnement de référence et l’environnement cible avec le même script, le même jeu d’essai et les mêmes paramètres pertinents.

Dans votre compte rendu, séparez clairement trois constats : l’installation de l’API, l’exécution du script et la conformité du résultat scientifique ou technique à votre référence. Une exécution sans erreur ne démontre pas, en elle-même, que le résultat répond aux critères du projet. Si l’API constitue une étape critique du travail, son échec doit pouvoir bloquer l’adoption de macOS 27 même lorsque les usages graphiques de Mercury semblent satisfaisants.

SECTION 05Scénario : activer la licence et confirmer l’accès réseau

La licence doit être vérifiée dans le contexte réel de votre groupe. Les informations CCDC sur le fonctionnement du système de licences et sur les connexions réseau nécessaires aux applications de bureau permettent d’identifier les conditions à contrôler. Consultez-les avec le soutien informatique de votre établissement, en particulier si le poste est soumis à un filtrage réseau ou si l’activation dépend d’un service institutionnel.

Ne confondez pas trois questions : le Mac peut-il joindre les services nécessaires, le compte peut-il activer ou ouvrir le logiciel, et l’utilisation envisagée entre-t-elle dans les autorisations accordées à votre établissement ? Un test technique ne tranche pas les règles internes de licence. Demandez confirmation à la personne responsable des licences ou au service compétent ; ce guide ne constitue pas un avis juridique sur les droits d’utilisation.

Effectuez le contrôle avec le compte et le chemin réseau prévus pour le travail quotidien. Si l’activation réussit uniquement depuis le réseau du laboratoire, mais que l’équipe doit travailler ailleurs, cette différence doit figurer dans la décision. À l’inverse, un blocage réseau ne prouve pas une incompatibilité de macOS : il peut relever d’une règle de pare-feu, d’un accès indisponible ou d’un compte qui n’a pas été configuré pour le test. Notez le résultat et la cause identifiée avant de conclure.

SECTION 06Décider de la migration à partir de résultats vérifiables

Utilisez cette liste de contrôle avant de proposer une adoption de macOS 27. Cochez chaque point uniquement lorsque vous disposez d’un résultat conservé ou d’une confirmation vérifiable ; une impression favorable pendant une session ne suffit pas.

• [ ] Statut officiel vérifié : la documentation CCDC consultée au moment de la décision indique clairement si macOS 27 est pris en charge. Si le système reste absent, classez la compatibilité comme non confirmée.
• [ ] Mercury vérifié : votre CIF de référence s’ouvre, les actions de structure attendues aboutissent et l’export final a été rouvert puis comparé à la sortie de référence.
• [ ] ConQuest vérifié séparément : la recherche produit les correspondances attendues, les résultats sont visibles et leur transfert vers Mercury aboutit avec un contenu final contrôlé.
• [ ] API et scripts vérifiés : l’interpréteur, la méthode d’installation, les dépendances et la sortie du script correspondent aux conditions requises par le projet.
• [ ] Licence et réseau vérifiés : le compte de travail peut utiliser le logiciel dans l’environnement réseau prévu et l’autorisation d’usage a été confirmée par la personne compétente.
• [ ] Conditions de travail consignées : les fichiers d’essai, les versions, les messages d’erreur éventuels et les limites constatées sont conservés sans données confidentielles inutiles.

Choisissez ensuite la suite correspondant à vos cases :

• Si tous les contrôles sont concluants et que la documentation officielle répertorie macOS 27, planifiez une adoption progressive, après validation par le responsable logiciel du laboratoire.
• Si les essais représentatifs réussissent, mais que macOS 27 n’est pas encore répertorié, poursuivez uniquement dans un environnement isolé et pour un périmètre convenu. Conservez le poste de référence et ne présentez pas cet essai comme une prise en charge officielle.
• Si un composant essentiel échoue ou si les résultats divergent sans explication, suspendez la migration des postes de production. Reproduisez l’échec et attendez une correction ou une clarification avant de reprendre la décision.
• Si vous ne pouvez pas reproduire les usages importants ou obtenir une confirmation de licence, ne validez pas le changement. Réglez d’abord les conditions d’accès, d’autorisation ou de test.

Cette liste évite deux erreurs coûteuses : accepter macOS 27 parce qu’une fenêtre s’ouvre, ou rejeter le système sans avoir vérifié le travail réel. Gardez une trace brève mais exploitable : environnement, version de CSD Portfolio, fichiers d’essai, étapes, résultat attendu, résultat observé, compte utilisé et décision prise. Si la page officielle change, vérifiez à nouveau le statut avant de réutiliser cette conclusion.

Quels composants sur Mac à puce de la série M faut-il vérifier séparément ? Mercury, ConQuest, l’API Python, les transferts entre composants et le parcours de licence ne doivent pas être réunis en un test unique. CCDC distingue le binaire universel destiné aux Mac à puce de la série M et le fonctionnement de ConQuest sous Rosetta dans CSD Portfolio 2026.1.1 ; validez donc chaque partie dont dépend votre équipe.

Au moment de la publication, les informations examinées sont celles des pages officielles CCDC consacrées à la compatibilité macOS, aux versions prises en charge, aux licences et aux connexions réseau, ainsi que du journal Apple consacré à macOS 27. Vérifiez ces références avant toute décision institutionnelle : une mise à jour de la documentation peut modifier le statut de prise en charge, tandis que vos résultats d’essai restent propres aux fichiers et aux procédures du laboratoire.

Si votre environnement actuel repose uniquement sur Windows ou Linux, il peut convenir à une partie de vos calculs, mais il ne remplace pas à lui seul la vérification d’une application macOS. Emprunter ponctuellement un Mac local dépend de sa disponibilité et peut rendre les essais difficiles à répéter ; basculer directement le poste principal avant la validation expose, de son côté, les analyses en cours à une migration prématurée. Un Mac distant peut servir d’environnement isolé pour reproduire le parcours graphique et les transferts, à condition de contrôler au préalable l’accès aux données et de confirmer séparément les droits de licence. Consultez les conditions et tarifs des environnements Mac proposés par MACNOX pour évaluer cette option selon la durée et les besoins de votre essai. Ce choix ne garantit ni la compatibilité de CSD Portfolio ni l’autorisation d’utiliser une licence institutionnelle : si vos tâches exigent une charge durable ou des périphériques physiques reliés au poste, un Mac local géré par votre établissement sera plus adapté. Pour un test temporaire avant migration, vous pouvez aussi examiner les solutions Mac de MACNOX, puis faire confirmer par votre laboratoire que l’environnement et les données sont appropriés à l’essai.