Donnée de départ et décision immédiate

La documentation d’ArcGIS Pro 3.6 décrit un environnement officiellement pris en charge dans la famille Windows x64, et non une installation native sous macOS : les exigences système d’ArcGIS Pro 3.6 doivent donc servir de référence avant tout achat ou abonnement. La conclusion est opérationnelle : ArcGIS Pro 3.6 ne s’installe pas nativement sur Mac. Avec un Mac Apple Silicon, la voie possible passe par une machine virtuelle Windows 11 ARM, mais les tâches ordinaires doivent être validées séparément des traitements qui dépendent d’AVX, de DirectX 12, du processeur graphique virtualisé ou des outils de deep learning. Pour ces derniers, il faut prévoir un environnement Windows x64 certifié.

Ce guide s’adresse aux étudiants qui doivent rendre une carte ou un projet de cours depuis un Mac Apple Silicon, aux chercheurs qui conservent des outils macOS tout en travaillant sur ArcGIS Pro, ainsi qu’aux équipes universitaires chargées de choisir entre virtualisation, Mac distant et station Windows dédiée.

La question n’est donc pas seulement « l’application démarre-t-elle ? ». Il faut vérifier si le projet s’ouvre, si la licence est reconnue, si les outils essentiels produisent le même résultat, si les chemins de fichiers restent reproductibles et si les livrables peuvent être exportés sans altération.

Installer sans confondre démarrage et environnement validé

La première étape consiste à distinguer trois niveaux de compatibilité.

  • Démarrage : ArcGIS Pro se lance et affiche son interface.
  • Fonctionnement ciblé : les outils nécessaires au cours ou à l’article scientifique s’exécutent sur les données réelles.
  • Validation du projet : les résultats, journaux, fichiers intermédiaires et exports peuvent être relus par un autre membre de l’équipe.

Un environnement Windows 11 ARM peut atteindre le premier niveau sans atteindre les deux suivants. Windows on Arm utilise des mécanismes d’émulation pour certaines applications x86, comme l’explique la documentation officielle sur l’émulation des applications x86 dans Windows 11 ARM. Cette couche supplémentaire peut devenir importante lorsque le projet utilise une extension, une bibliothèque Python compilée ou un traitement qui attend des instructions processeur particulières.

Sur Apple Silicon, la virtualisation doit également respecter les conditions de licence applicables à Windows. Les possibilités décrites dans la documentation officielle sur Windows 11 avec les Mac Apple Silicon doivent être vérifiées avant la création de la machine virtuelle. Il ne faut pas partir du principe qu’une licence macOS ou un compte universitaire autorise automatiquement Windows.

Une configuration cohérente doit donc prévoir :

  1. une machine virtuelle Windows 11 ARM créée avec une licence valide ;
  2. une installation d’ArcGIS Pro 3.6 provenant du canal autorisé par l’établissement ;
  3. un compte ou une licence ArcGIS vérifiée avant l’importation du projet ;
  4. un dossier de travail clairement séparé entre macOS et Windows ;
  5. une copie du projet de référence, afin que les essais ne modifient pas les données originales.

Le partage de dossiers doit rester limité aux fichiers qui doivent réellement circuler entre les deux systèmes. Les chemins absolus propres à macOS, les scripts qui appellent un exécutable local et les liens vers des lecteurs réseau peuvent casser dès que le projet change d’environnement.

Cartographie 2D et travaux de cours

La cartographie universitaire constitue généralement le meilleur premier scénario de validation. La consultation de couches, la symbolisation, l’édition géométrique, la création d’une mise en page et l’export d’une carte mobilisent moins directement les fonctions graphiques avancées qu’une scène 3D ou un modèle d’apprentissage profond. Cela ne constitue toutefois pas une garantie générale pour tous les projets.

Le test doit partir d’un échantillon représentatif : le fichier de projet réellement utilisé dans le cours, quelques couches avec leurs systèmes de coordonnées, les styles nécessaires, les polices employées dans la mise en page et une consigne d’export identique à celle du rendu final. Un projet vide ne permet pas de repérer les chemins rompus, les caractères mal rendus ou les dépendances absentes.

Le contrôle peut suivre cette séquence :

  • ouvrir le projet depuis une copie locale de la machine Windows ;
  • vérifier que chaque couche s’affiche au bon emplacement ;
  • contrôler le système de coordonnées de la carte et des données ;
  • modifier une entité, enregistrer, fermer puis rouvrir le projet ;
  • appliquer la symbologie et les étiquettes prévues ;
  • exporter le livrable dans le format demandé par l’enseignant ou l’équipe ;
  • comparer le résultat exporté avec la version de référence.

Le critère de réussite n’est pas une impression de fluidité de l’interface. Le projet doit pouvoir être rouvert, les données doivent rester complètes, les textes doivent conserver leur mise en forme et la licence doit rester active après une nouvelle connexion. Si seule la navigation est satisfaisante mais que l’export ou l’édition échoue, le scénario n’est pas validé.

Pour un étudiant qui doit seulement finaliser une carte thématique, cette voie peut être raisonnable. Pour une équipe qui doit conserver les fichiers dans un dépôt partagé, il faut en plus documenter les chemins, les noms de couches et la méthode de synchronisation. Une ressource comme un guide de dimensionnement de la mémoire pour un projet ArcGIS Pro peut compléter cette première estimation, sans remplacer le test sur le projet réel.

Géotraitement, Python et reproductibilité

Le risque augmente lorsque le travail repose sur ModelBuilder, ArcPy, des environnements conda personnalisés ou des bibliothèques tierces. ArcGIS Pro installe et gère un environnement Python propre à l’application ; la documentation d’installation de Python pour ArcGIS Pro et la documentation consacrée aux environnements conda doivent être consultées avant toute modification.

Le piège courant consiste à installer un paquet dans l’environnement Python général de macOS, puis à conclure qu’ArcPy devrait le trouver dans Windows. Les deux systèmes n’utilisent ni les mêmes chemins, ni les mêmes exécutables, ni nécessairement les mêmes extensions compilées. Une dépendance qui fonctionne dans un laboratoire Linux peut donc échouer dans Windows 11 ARM, même si le script Python paraît identique.

La validation doit utiliser un modèle ou un script représentatif, avec les données habituelles et les paramètres réellement employés dans l’article ou le mémoire. Il faut conserver :

  • les paramètres d’entrée et de sortie ;
  • le journal d’exécution ;
  • les fichiers intermédiaires ;
  • les messages d’erreur complets ;
  • la version de l’environnement Python ;
  • le résultat final à comparer avec une exécution de référence.

Quelques contrôles système peuvent aider à isoler l’architecture sans transformer l’article en tutoriel d’installation complet. Dans Windows, systeminfo permet de relever les informations générales de la machine, tandis que les commandes de l’environnement conda permettent d’identifier l’environnement actif. Dans ArcGIS Pro, le journal de géotraitement doit être exporté avec le projet de test. Ces éléments sont plus utiles qu’une simple capture de l’écran d’accueil.

Le point d’arrêt doit être défini avant les essais. Si le modèle appelle une fonction nécessitant AVX, une extension native indisponible, un composant graphique particulier ou un paquet qui ne peut pas être installé dans l’architecture utilisée, il vaut mieux cesser les corrections successives. Le passage à une station Windows x64 certifiée sera généralement plus prévisible que l’empilement de contournements difficiles à reproduire par les autres membres du laboratoire.

3D, télédétection et apprentissage profond

Les scènes 3D, la visualisation volumétrique, certains traitements de télédétection et les outils de deep learning doivent être évalués comme une catégorie distincte. Une carte 2D qui s’ouvre correctement ne permet pas de déduire qu’un modèle 3D, un rendu intensif ou une analyse raster lourde fonctionnera dans les mêmes conditions.

Les informations spécifiques au fonctionnement sur Mac sont regroupées dans la documentation officielle sur l’exécution d’ArcGIS Pro sur Mac. Elle signale notamment des restrictions liées à AVX, au processeur graphique virtualisé, à DirectX 12 et à certains outils de deep learning. Ces limites doivent être lues comme des critères de décision, et non comme de simples détails techniques.

Le scénario 3D doit donc être testé avec une scène représentative, les mêmes données et les mêmes opérations que dans le protocole de recherche. Le test doit mesurer séparément :

  • le temps de calcul produit par la machine ;
  • la stabilité du traitement ;
  • la qualité du rendu exporté ;
  • la réactivité de l’accès distant ou de la fenêtre virtualisée.

Cette séparation est indispensable. Une connexion distante peut rendre la manipulation visuellement lente alors que le calcul est correct. À l’inverse, une interface qui semble réactive peut masquer un traitement interrompu ou un résultat incomplet. Il ne faut pas confondre latence d’affichage et performance du moteur de géotraitement.

Pour un modèle de deep learning, une analyse répétée sur de grands volumes ou une scène 3D destinée à une soutenance, la recommandation par défaut est un poste Windows x64 certifié et doté des ressources graphiques attendues par le logiciel. La virtualisation sur Mac reste adaptée à une vérification exploratoire seulement si le projet ne dépend pas d’une fonction explicitement limitée.

Double environnement pour la recherche

Le Mac distant ne transforme pas ArcGIS Pro en application macOS. Son intérêt est différent : il peut conserver un environnement macOS complet pour les outils de recherche, d’audio, de vidéo ou de conception, tout en permettant de vérifier une machine Windows virtualisée lorsque le projet l’autorise. Cette approche est pertinente pour un chercheur qui doit passer entre traitement de données, préparation de figures, montage d’une présentation et contrôle d’un projet SIG.

Le partage des fichiers doit être conçu avant la location. Trois règles réduisent les erreurs :

  1. les données originales restent dans un emplacement de référence non modifié ;
  2. les fichiers de travail Windows et macOS possèdent des noms et des chemins documentés ;
  3. les scripts utilisent des chemins configurables plutôt que des chemins propres à une seule machine.

Git peut convenir aux scripts, aux fichiers de configuration et aux petits documents textuels. Les jeux de données volumineux exigent plutôt un stockage partagé ou un transfert contrôlé, avec vérification des fichiers reçus. Un projet ArcGIS Pro peut enregistrer des références vers des ressources qui ne suivent pas automatiquement le fichier de projet ; il faut donc vérifier les connexions, les styles, les géodatabases et les scripts associés.

Pour une chaîne macOS–Windows, le contrôle minimal porte sur la lecture des données, la conservation des coordonnées, l’exécution d’un script, l’écriture d’un résultat et l’ouverture de ce résultat sur l’autre système. Cette validation est aussi utile lorsque le Mac sert à préparer des fichiers audio ou vidéo liés à une présentation scientifique : les exports doivent rester lisibles et les chemins doivent être documentés au lieu d’être supposés identiques.

Liste de validation avant engagement

La liste suivante permet de décider rapidement si le scénario doit continuer sur un Mac virtualisé, passer sur Windows x64 ou rester en double environnement.

  • [ ] Le Mac utilisé possède une architecture Apple Silicon identifiée et la virtualisation Windows 11 ARM est autorisée.
  • [ ] La licence Windows et la licence ArcGIS Pro sont validées avec les droits du compte universitaire.
  • [ ] Le projet réel, et non un projet vide, s’ouvre avec ses couches, styles, polices et systèmes de coordonnées.
  • [ ] Une modification est enregistrée, puis retrouvée après fermeture et réouverture.
  • [ ] Le script ou le modèle principal s’exécute avec les mêmes paramètres d’entrée que dans le protocole de recherche.
  • [ ] L’environnement Python actif et les paquets indispensables sont documentés.
  • [ ] Les journaux, fichiers intermédiaires et résultats finaux sont conservés pour comparaison.
  • [ ] L’export final est vérifié dans le format demandé.
  • [ ] Les fonctions 3D, AVX, DirectX 12 ou deep learning nécessaires ont été testées explicitement.
  • [ ] La latence d’accès distant est distinguée du temps de calcul de la machine.
  • [ ] Un plan de retour vers une station Windows x64 existe si une fonction essentielle échoue.

Si les huit premiers contrôles sont positifs mais qu’un outil graphique ou d’apprentissage profond échoue, il ne faut pas présenter le projet comme validé. La bonne décision est alors de conserver le Mac pour les tâches macOS et de déplacer le calcul ArcGIS Pro vers un environnement Windows x64 approprié.

Questions fréquentes

Apple Silicon et installation directe

Un Mac Apple Silicon ne reçoit pas une version macOS native d’ArcGIS Pro 3.6. La voie réaliste est une machine Windows 11 ARM virtualisée, soumise aux limites documentées et à la licence Windows. Cette nuance est importante pour les étudiants qui voient l’application démarrer : le démarrage ne suffit pas à établir la prise en charge officielle du projet.

Limites de Windows 11 ARM

Windows 11 ARM peut exécuter certaines applications x86 par émulation, mais les dépendances natives et les fonctions graphiques ne sont pas toutes équivalentes. Les projets utilisant AVX, DirectX 12, un processeur graphique virtualisé ou le deep learning doivent être testés séparément. En cas d’échec sur une fonction indispensable, il faut revenir à Windows x64 plutôt que modifier indéfiniment l’environnement.

Analyse spatiale sur Mac

La virtualisation peut convenir à la cartographie, à la mise en page, à la consultation et à une partie de l’édition 2D. Elle est moins prévisible pour les traitements lourds, les scènes 3D et les extensions spécialisées. La décision doit reposer sur un jeu de données représentatif, un modèle réel et un export contrôlé, pas sur la seule ouverture de l’interface.

Travail d’un étudiant sans Mac

Un étudiant qui possède uniquement un Mac peut commencer par une validation Windows 11 ARM, puis utiliser son projet de cours comme test d’acceptation. Si la licence, l’édition, l’export et les outils principaux fonctionnent, cette voie peut suffire pour le devoir concerné. Si un outil central est bloqué, une station Windows x64 doit être recherchée sans attendre la date de rendu.

Mac distant ou station Windows

La station Windows x64 est préférable pour les calculs récurrents, les fonctions graphiques avancées et les outils soumis à des exigences matérielles précises. Le Mac distant est plus pertinent lorsqu’il faut conserver macOS, tester une chaîne multiplateforme ou limiter l’engagement à une période de validation. Les conditions de location d’un Mac distant pour un environnement de test doivent être confirmées avant toute installation de Windows.

Choix final et période d’essai

Le choix dépend donc du scénario, et non du seul fait de posséder un Mac. Pour une carte de cours, une édition 2D ou une mise en page, Windows 11 ARM virtualisé peut constituer une première voie économique, à condition que le projet réel passe la liste de validation. Pour un modèle ArcPy sensible à l’architecture, une scène 3D, une fonction DirectX 12, une dépendance AVX ou un outil de deep learning, une station Windows x64 certifiée est le choix le moins risqué.

Le Mac distant ajoute une valeur spécifique lorsque le laboratoire doit conserver macOS et ArcGIS Pro dans un même flux de travail. Par rapport à l’achat immédiat d’un poste dédié, il évite d’immobiliser un budget dans une machine qui pourrait ne servir qu’à un cours ou à une phase courte de validation. Par rapport à une station Windows permanente, il ne convient toutefois pas à tous les traitements lourds et dépend de la qualité de l’accès distant, du stockage et de l’autorisation de créer l’environnement virtuel.

Avant de choisir, il est préférable de confirmer auprès de RUVCLOUD que la machine distante autorise l’environnement Windows nécessaire, puis de retenir une période courte adaptée au projet. Le compte ArcGIS Pro, les outils indispensables, le script représentatif et l’export final doivent être vérifiés dès le début. Si une limitation officielle apparaît sur le calcul central, il faut interrompre cette piste et basculer vers un environnement Windows x64 certifié, plutôt que prolonger une solution qui ne pourra pas satisfaire le protocole de recherche. Les modalités de commande d’un Mac distant auprès de RUVCLOUD peuvent ensuite être examinées uniquement si le scénario double environnement a passé cette validation.