JULIA 1.13 SUR MAC APPLE SILICON
installation, guide de recherche 2026

Vous voyez Julia démarrer, mais un paquet scientifique ou une bibliothèque externe refuse ensuite de se charger sur votre Mac Apple Silicon.

La solution la plus sûre consiste à installer Julia 1.13 avec juliaup, à vérifier l’architecture réellement exécutée, puis à créer un environnement indépendant avec Project.toml et Manifest.toml. Pour un ancien projet, ne remplacez pas immédiatement l’installation existante : conservez-la et effectuez la régression dans un environnement Julia 1.13 séparé.

Cet article s’adresse aux chercheurs qui disposent surtout d’un poste Windows ou Linux, mais doivent valider un projet Julia sur macOS arm64. Il convient également aux équipes qui migrent un ancien article ou protocole expérimental, ainsi qu’aux services informatiques universitaires chargés de fournir un environnement reproductible et accessible à distance.

Dernière mise à jour : 19 septembre 2026. Les informations de version ont été vérifiées à partir des pages officielles de téléchargement, d’installation et de publication de Julia ; les règles d’environnement proviennent de la documentation officielle de Pkg.

Point de départ : version, canal et architecture

Au 19 septembre 2026, Julia 1.13.0, publiée le 9 septembre 2026, est indiquée par le projet officiel comme la version stable actuelle. Une construction macOS destinée aux processeurs Apple Silicon est disponible, et la méthode d’installation généralement recommandée pour un usage courant passe par juliaup plutôt que par une source tierce susceptible de fournir une ancienne construction. Vous pouvez contrôler ces éléments sur la page officielle des téléchargements manuels de Julia et la documentation d’installation pour macOS.

La commande qui lance Julia ne constitue toutefois pas une preuve suffisante. Un terminal peut appeler une ancienne installation, un binaire Intel sous Rosetta ou une autre version ajoutée précédemment au PATH. Commencez donc par conserver une trace exploitable :

which julia
type -a julia
juliaup status
julia --version
julia -e 'println(Sys.ARCH)'

Vous cherchez trois informations distinctes :

• le chemin du programme effectivement appelé ;
• le canal sélectionné par juliaup ;
• la version et l’architecture déclarées par Julia.

Pour Julia 1.13, l’architecture attendue sur une installation native Apple Silicon est généralement aarch64. Si le résultat indique x86_64, ne concluez pas immédiatement que vos paquets sont défectueux : vous êtes peut-être en train d’exécuter une construction Intel, ou votre terminal fonctionne dans un contexte de compatibilité. La [documentation officielle des plateformes Julia](https://julialang.org/downloads/platform/) décrit les constructions disponibles et leurs conditions d’utilisation.

Julia 1.13 doit-elle être installée avec juliaup ou avec un fichier DMG ? Pour un nouveau projet de recherche, choisissez d’abord juliaup, car il rend le canal actif visible et facilite la coexistence de plusieurs versions. Le téléchargement manuel peut être pertinent pour une machine contrôlée par une politique informatique stricte, pour une installation hors ligne préparée par l’administrateur ou pour une construction précise validée par votre équipe. Dans ce cas, consignez le fichier utilisé, son empreinte si votre procédure l’exige, son architecture et le chemin final ; ne mélangez pas ensuite cette installation avec une autre entrée Julia ajoutée au PATH.

La distinction entre stable, version à support prolongé, ancienne version imposée par un projet et version de développement doit être faite avant l’installation. Une version stable convient à un nouveau projet. Une version plus ancienne doit rester disponible si un article publié, un cours ou une analyse réglementée dépend de son graphe de paquets. Une version de développement ne doit pas devenir la base d’un résultat scientifique sans protocole de validation spécifique.

Architecture arm64 : symptômes et preuves

Sur Apple Silicon, le problème le plus coûteux n’est pas toujours Julia lui-même. Un paquet peut être résolu correctement, puis échouer lorsque Pkg télécharge un artifact, charge une bibliothèque C ou Fortran, ou lance un exécutable externe. Le symptôme typique est donc trompeur : Pkg.add semble fonctionner, mais l’import ou le premier calcul échoue.

Examinez l’architecture sur plusieurs niveaux :

uname -m
file "$(which julia)"
julia -e 'println(Sys.MACHINE)'
julia -e 'println(Sys.ARCH)'

Pour une dépendance externe connue, utilisez également :

file /chemin/vers/le/binaire

Ces commandes répondent à des questions différentes. uname -m décrit le contexte du noyau et du terminal. file donne l’architecture du fichier ciblé. Sys.ARCH décrit la construction Julia en cours. Une cohérence complète entre ces résultats est préférable avant d’instancier un environnement scientifique.

Les artifacts sont importants parce qu’ils peuvent transporter une bibliothèque précompilée propre à une plateforme. La documentation officielle des Artifacts de Julia explique ce mécanisme et ses conséquences pour les dépendances binaires. Si un paquet ne propose pas encore l’artefact arm64 attendu, réinstaller le même paquet ne résoudra pas nécessairement le problème.

N’utilisez pas Rosetta comme correctif par défaut. Vous pouvez l’envisager uniquement lorsqu’une dépendance ancienne n’a réellement pas de voie arm64 documentée et que vous pouvez isoler cette contrainte. Dans ce cas, séparez le terminal, la version Julia, les bibliothèques externes et l’environnement du reste de vos projets. Un mélange silencieux entre arm64 et x86_64 rend les erreurs difficiles à reproduire, notamment lorsque Python, R, MATLAB, FFmpeg ou une bibliothèque de calcul intervient dans le même flux audio, vidéo ou scientifique.

Arrêtez la migration si l’un de ces éléments reste inexpliqué :

• Julia indique x86_64 alors que vous attendiez arm64 ;
• un binaire externe a une architecture différente sans justification écrite ;
• l’échec concerne un artefact absent plutôt qu’un simple chemin local ;
• vous ne pouvez pas reproduire le problème dans un projet minimal.

juliaup, Shell et chemins concurrents

Un terminal qui affiche « commande introuvable » ou qui continue de lancer Julia 1.10 après l’installation de Julia 1.13 signale souvent un problème de chemin, pas un problème de paquet scientifique. Les profils zsh, bash, les terminaux intégrés d’un éditeur et les sessions SSH peuvent également charger des configurations différentes.

Procédez dans cet ordre :

1. Ouvrez un nouveau terminal et exécutez type -a julia, which julia et juliaup status.
2. Notez le chemin retourné avant de modifier un fichier de configuration.
3. Comparez le résultat dans Terminal, dans votre éditeur et dans une session SSH si vous utilisez un Mac distant.
4. Vérifiez le canal par défaut avec juliaup status, puis sélectionnez explicitement le canal nécessaire selon la syntaxe présentée par la documentation d’installation.
5. Relancez le terminal et répétez les mêmes commandes.
6. Seulement après cette vérification, retirez une entrée obsolète du PATH ou corrigez votre profil Shell.

N’effacez pas indistinctement votre dossier personnel Julia, vos préférences ou vos environnements pour « repartir de zéro ». Cette méthode peut supprimer les informations nécessaires au diagnostic et ne protège ni Project.toml, ni Manifest.toml, ni les scripts de l’équipe. Archivez d’abord le code, les fichiers de projet, les données de test et la sortie des commandes de version.

Si vous utilisez un accès distant, vérifiez aussi que la commande lancée par SSH n’hérite pas d’un environnement différent de celui de votre session graphique. Un projet qui fonctionne dans une fenêtre locale mais pas dans une tâche distante peut simplement recevoir un autre PATH, un autre répertoire courant ou des variables absentes. Pour préparer cette étape, vous pouvez aussi consulter les options de commande d’un Mac Apple Silicon distant et vérifier que la méthode d’accès retenue correspond à votre besoin de terminal ou de session graphique.

Paquets scientifiques et réseau universitaire

Une erreur pendant Pkg.instantiate() doit être classée selon le premier échec utile, et non selon la dernière ligne affichée. Quatre niveaux sont fréquents :

• accès au registre des paquets ;
• connexion au serveur de paquets ;
• téléchargement d’un dépôt Git ;
• récupération ou construction d’un artefact.

Ajoutez également les échecs locaux : certificat, proxy, autorisation d’écriture, compilateur ou bibliothèque système. Les [fichiers TOML utilisés par Pkg](https://pkgdocs.julialang.org/dev/toml-files/) permettent ensuite de distinguer la description du projet du verrouillage exact des dépendances.

Pour un diagnostic initial, activez le projet et demandez l’instanciation sans lancer votre analyse complète :

julia --project=. -e 'using Pkg; Pkg.instantiate()'
julia --project=. -e 'using Pkg; Pkg.status()'

Si le réseau universitaire intercepte HTTPS, exige un proxy ou applique une politique de certificats, transmettez le domaine, l’heure, le message d’erreur et la commande à l’administrateur réseau. Ne conseillez pas de désactiver la vérification TLS ou de contourner le pare-feu : vous transformeriez un problème d’accès en risque pour les données et les dépendances.

Commencez avec un paquet scientifique minimal, puis exécutez une opération représentative. La réussite de using Pkg ne prouve pas que votre chaîne de calcul est utilisable. Pour un projet de biologie, de statistiques, de simulation ou de traitement audio, sélectionnez une entrée suffisamment petite pour être rejouée rapidement, mais assez proche du protocole réel pour révéler les bibliothèques binaires et les fichiers de données concernés.

Que faire si un paquet scientifique refuse de s’installer après la mise à niveau ? Relevez le premier message d’erreur, l’architecture, la version Julia, le contenu de Project.toml et le résultat de Pkg.status(). Testez ensuite le même paquet dans un nouveau projet vide. S’il échoue aussi, consultez la documentation et les problèmes du paquet concerné ; s’il fonctionne dans le projet vide, recherchez plutôt une contrainte ou un conflit dans le graphe de dépendances de votre ancien projet. Ne remplacez pas au hasard les versions verrouillées.

Projets reproductibles et migration contrôlée

L’environnement global est acceptable pour une expérimentation rapide, mais il ne doit pas porter seul un article, un cours évalué ou un pipeline de laboratoire. Créez un répertoire propre pour chaque étude :

mkdir projet-julia-113
cd projet-julia-113
juliaup default 1.13
julia --project=. -e 'using Pkg; Pkg.activate("."); Pkg.instantiate()'

Dans la pratique, activez le projet depuis Julia ou depuis le gestionnaire de paquets, puis vérifiez que Project.toml et Manifest.toml se trouvent bien dans le répertoire attendu. Le premier décrit les dépendances directes ; le second conserve une résolution plus précise, utile pour reproduire une analyse. Les règles officielles de gestion des environnements détaillent ce découpage.

Avant toute migration, faites une copie en lecture seule de l’ancien projet :

cp Project.toml Project.toml.ancien
cp Manifest.toml Manifest.toml.ancien

Adaptez les chemins à votre organisation et sauvegardez aussi les scripts, les paramètres, les données publiques ou désensibilisées et les résultats de référence. Pour un projet qui doit rester exécutable avec plusieurs versions Julia, utilisez des Manifest distincts lorsque cela est nécessaire ; la documentation consacrée aux Manifest selon la version de Julia décrit cette possibilité.

La compatibilité ne se juge pas uniquement avec using MonPaquet. Comparez au minimum :

• une sortie numérique connue ;
• une graine aléatoire fixée lorsque le protocole l’autorise ;
• le nombre de lignes ou d’observations après traitement ;
• un fichier exporté et son format ;
• la liste et l’état des dépendances ;
• le temps de première exécution séparément du temps des exécutions suivantes.

Une différence numérique ne signifie pas automatiquement que Julia 1.13 est fautive. Elle peut provenir d’un changement de bibliothèque, d’un ordre de calcul parallèle, d’un fichier d’entrée différent ou d’une précision implicitement définie. C’est précisément pourquoi l’ancien environnement doit rester disponible jusqu’à la fin de la comparaison.

Comment conserver les dépendances d’un ancien projet avec Julia 1.13 ? Ne réécrivez pas son Manifest.toml sur place. Conservez l’ancien couple Project.toml–Manifest.toml, créez un répertoire de migration et laissez Julia 1.13 résoudre un environnement séparé. Si les deux versions doivent rester utilisables, documentez explicitement quelle version lance quelle étude et conservez un manifeste par ligne de compatibilité.

Validation graphique et tâches longues

Une installation réussie dans le REPL ne garantit pas le fonctionnement d’un poste de recherche. Validez séparément le calcul terminal, l’intégration avec VS Code ou un carnet, l’affichage graphique, la lecture-écriture de fichiers et la continuité d’une tâche longue.

Pour un contrôle réaliste, utilisez un jeu de données public ou désensibilisé et consignez les étapes suivantes :

1. activation du projet ;
2. instanciation complète des dépendances ;
3. premier lancement à froid ;
4. génération d’un graphique ou d’un fichier de résultats ;
5. fermeture puis reconnexion ;
6. reprise ou relance d’une tâche longue ;
7. comparaison avec la sortie de référence.

À distance, une fenêtre graphique peut dépendre de la méthode de connexion et de la configuration du bureau. Un accès SSH convient très bien à un calcul non interactif, mais il ne remplace pas la vérification d’un graphique ou d’un flux audio-vidéo. Un accès VNC ou une session graphique distante permet de contrôler l’affichage, les dialogues de fichiers et l’éditeur, avec une attention particulière à la latence et à la reprise après déconnexion.

Un Mac distant peut-il exécuter une tâche Julia avec interface graphique ? Oui, si la session graphique, les paquets et les bibliothèques d’affichage sont correctement disponibles ; cela doit être vérifié sur votre tâche réelle, et non déduit d’une simple addition dans le REPL. Testez l’ouverture d’une figure, son export, la lecture du fichier produit et la reconnexion après fermeture de la session.

Décision avant migration

Utilisez les conditions suivantes plutôt qu’une décision fondée sur la seule présence de Julia dans le terminal :

• Si le projet est nouveau, l’architecture est arm64, juliaup expose Julia 1.13 et le test minimal passe, choisissez Julia 1.13 avec un projet dédié.
• Si l’ancien article produit encore ses résultats et que ses paquets ne sont pas tous validés, conservez l’environnement historique et créez une seconde voie Julia 1.13.
• Si Julia est arm64 mais qu’une dépendance externe reste Intel, isolez cette dépendance ou revenez à la version documentée ; n’activez pas Rosetta pour toute la machine.
• Si l’instanciation échoue sur le réseau avant tout téléchargement, faites corriger le proxy ou les certificats par l’établissement avant de modifier les paquets.
• Si les résultats, les graphiques et la reprise après déconnexion sont identiques aux références, poursuivez la migration.
• Si l’écart n’est pas expliqué ou si une dépendance critique n’a aucune voie arm64, arrêtez la migration et maintenez le double environnement.

Les points de contrôle ci-dessous résument les choix les plus fréquents : <

Situation observée	Décision recommandée	Preuve attendue
Nouveau projet sans dépendance héritée	Julia 1.13 avec juliaup	Version, architecture et projet local vérifiés
Article ancien reproductible uniquement avec une version antérieure	Double environnement	Ancien manifeste conservé et nouveau manifeste séparé
Paquet compatible mais artefact arm64 absent	Suspendre la migration	Erreur d’artefact documentée et dépendance identifiée
Réseau universitaire bloquant HTTPS	Corriger l’accès réseau	Diagnostic transmis à l’administrateur, sans contournement TLS
Calcul terminal validé mais graphique non testé	Ne pas déclarer l’environnement prêt	Figure, export et reconnexion contrôlés
Résultats divergents sans cause identifiée	Retour temporaire à l’environnement de référence	Comparaison des données, graines et dépendances

La question du coût doit venir après cette validation technique. Acheter un Mac donne un accès permanent et local, mais immobilise un budget, demande une maintenance et ne résout pas automatiquement les problèmes de dépendances. Un poste Windows ou Linux existant reste souvent excellent pour le calcul principal, mais il ne fournit pas la preuve d’un comportement macOS arm64. Un Mac distant ajoute une étape de connexion et dépend de la qualité du réseau, tout en permettant de tester une vraie plateforme sans modifier l’ordinateur de laboratoire. <

Option	Atout pour un projet Julia	Limite à vérifier	Choix pertinent si…
Mac local	Accès direct aux outils graphiques et aux fichiers	Achat, maintenance et disponibilité d’une machine Apple Silicon	Vous utilisez macOS quotidiennement et durablement
Poste Linux ou Windows seul	Intégration avec le parc existant et les serveurs	Ne valide pas les artefacts macOS arm64	Votre projet ne dépend pas de macOS
Mac distant loué	Validation ciblée, accès root et environnement macOS réel	Latence, transfert de données et durée de la session	Vous devez tester Julia 1.13 sans achat immédiat
Rosetta pour tout l’environnement	Peut dépanner une ancienne dépendance Intel	Architecture mélangée et diagnostic moins fiable	Une dépendance critique n’a réellement aucune alternative arm64

Conclusion opérationnelle

Julia 1.13 sur Mac Apple Silicon est un choix raisonnable pour un nouveau projet lorsque juliaup, l’architecture arm64, le réseau et les dépendances ont été vérifiés séparément. Pour une étude existante, la bonne méthode n’est pas de remplacer l’ancien environnement, mais de comparer deux voies avec leurs propres fichiers de projet, résultats, graphiques et conditions d’exécution. Vous ne devez déclarer la migration terminée qu’après une tâche scientifique représentative.

Si votre laboratoire ne possède aucun Mac, votre poste Linux ou Windows peut rester la base du travail, mais il présente trois limites concrètes : il ne révèle pas les artefacts macOS, il ne valide pas l’affichage propre à macOS et il peut masquer une dépendance Intel jusqu’au jour de la publication. À l’inverse, l’achat immédiat d’un Mac crée une dépense et une contrainte de maintenance alors que votre besoin peut se limiter à une campagne de régression. Dans ce cas, louer un Mac distant pour un environnement scientifique permet de tester le même projet Julia 1.13 sur une machine Apple Silicon réelle, puis de décider avec des résultats plutôt qu’avec une hypothèse.

Avant la connexion, préparez Project.toml, Manifest.toml, les données autorisées et votre grille de résultats. Vous pourrez alors utiliser une session courte pour vérifier l’installation, l’instanciation, le calcul, le graphique et la reprise après déconnexion. Si la validation est concluante, vous choisirez ensuite entre poursuivre la location, acheter une machine ou conserver un fonctionnement Linux–macOS à deux voies ; si elle échoue, vous aurez isolé le problème sans compromettre l’environnement de référence.