Présentation

Tu veux essayer pandas.

Puis NumPy.

Puis Jupyter.

Puis scikit-learn.

Un package réclame une bibliothèque native.

Un autre veut une version différente de Python.

Le troisième fonctionne parfaitement.

À condition, évidemment, de ne surtout plus toucher à rien.

C’est exactement le genre de situation auquel Anaconda Distribution tente de répondre.

Son idée n’est pas de remplacer Python.

Elle consiste plutôt à fournir un environnement Python déjà préparé pour les domaines où les dépendances deviennent rapidement plus compliquées que le simple fichier .py que l’on voulait écrire au départ.

Python, mais avec l’atelier déjà installé

Installer Python depuis python.org donne essentiellement le langage, sa bibliothèque standard et les outils fondamentaux.

Anaconda Distribution arrive avec une philosophie différente.

Elle rassemble notamment :

Python, le langage ;

conda, pour gérer packages et environnements ;

Anaconda Navigator, une interface graphique pour travailler avec ces environnements ;

Jupyter Notebook et JupyterLab, pour l’exploration interactive ;

ainsi qu’un ensemble important de bibliothèques destinées à la data science, au calcul scientifique, à la visualisation et au machine learning.

NumPy.

pandas.

SciPy.

Matplotlib.

Jupyter.

scikit-learn.

Et beaucoup d’autres.

L’idée est simple :

au lieu de construire progressivement un environnement scientifique, Anaconda fournit directement un atelier déjà équipé.

Cela représente davantage de poids sur le disque.

Mais aussi beaucoup moins de petites décisions à prendre avant de pouvoir commencer.

Anaconda n’est pas Python

Cette distinction est essentielle.

Python est le langage.

Anaconda Distribution est une distribution qui inclut Python et construit tout un environnement autour de lui.

On peut parfaitement utiliser Python sans Anaconda.

Avec venv et pip.

Avec uv.

Avec Poetry.

Avec conda installé autrement.

Avec Miniconda.

Avec Miniforge.

Ou avec de nombreux autres workflows.

Inversement, Anaconda utilise Python comme pièce centrale, mais ajoute une logique de gestion des packages qui va plus loin que le seul écosystème Python.

C’est là que conda devient important.

Conda : la vraie mécanique sous le capot

Conda est à la fois un gestionnaire de packages et un gestionnaire d’environnements.

Il est open source et fonctionne sur Windows, macOS et Linux.

Son intérêt particulier est qu’il ne se limite pas aux packages Python.

Un package conda peut embarquer :

bibliothèques système, exécutables, modules Python ou R, dépendances natives et autres composants nécessaires à l’exécution d’un logiciel.

Cela devient particulièrement intéressant dans le calcul scientifique.

Installer une bibliothèque Python pure est souvent relativement simple.

Installer une bibliothèque qui dépend de BLAS, LAPACK, CUDA, compilateurs, bibliothèques C/C++ ou autres composants natifs peut devenir beaucoup plus délicat.

Conda cherche à gérer cet ensemble comme un seul graphe de dépendances.

C’est l’une des raisons pour lesquelles Anaconda s’est installé si profondément dans la data science.

Distribution, conda et Miniconda : trois choses différentes

Le vocabulaire peut devenir rapidement confus.

Nom Rôle
Anaconda Distribution Distribution complète avec Python, conda, Navigator, Jupyter et de nombreux packages
conda Gestionnaire open source de packages et d’environnements
Miniconda Installateur minimal fourni par Anaconda avec conda, Python et quelques dépendances essentielles
Miniforge Distribution communautaire minimale de conda configurée autour de conda-forge

Cette distinction évite beaucoup de malentendus.

On peut vouloir conda sans vouloir toute Anaconda Distribution.

C’est précisément pour cela que Miniconda et Miniforge sont devenus populaires.

Anaconda Distribution choisit le confort du « beaucoup de choses déjà présentes ».

Miniconda choisit plutôt :

« donne-moi le moteur, j’installerai ce dont j’ai besoin ensuite ».

Un produit devenu plus large qu’un simple installateur Python

Anaconda a beaucoup évolué.

La Distribution desktop reste une pièce importante, mais elle vit désormais dans une plateforme plus vaste comprenant notamment des notebooks cloud, des services de packages, des outils de collaboration, Anaconda Assistant, des fonctions de sécurité et des offres destinées aux entreprises.

Les plans actuels se répartissent entre Free, Starter et Business.

Cette évolution change la manière de présenter Anaconda.

Historiquement, beaucoup de développeurs l’ont connu comme :

« le gros installateur Python pour la data science ».

Aujourd’hui, Anaconda essaie davantage de devenir une plateforme de développement et de gouvernance autour de Python, de la data et de l’IA.

La Distribution reste cependant la porte d’entrée la plus reconnaissable.

Fonctionnalités

Des environnements isolés pour chaque projet

Le principe des environnements conda est proche de celui des environnements virtuels Python, mais leur périmètre est plus large.

On peut créer :

conda create --name analyse python=3.14

Puis un autre environnement :

conda create --name ancien-projet python=3.11

Les deux peuvent vivre sur la même machine.

Chacun possède ses packages.

Sa version de Python.

Ses dépendances.

Ses bibliothèques natives.

On peut ensuite passer de l’un à l’autre avec :

conda activate analyse

C’est particulièrement utile quand plusieurs projets ne sont pas d’accord sur la définition exacte du mot « compatible ».

Ce qui arrive étonnamment souvent.

Installer plusieurs couches de dépendances en une seule opération

Avec conda :

conda install numpy pandas scipy

Le gestionnaire cherche des versions compatibles entre elles et avec l’environnement courant.

Il prend également en compte les dépendances liées à la plateforme.

L’intérêt devient particulièrement visible lorsqu’un package dépend de composants qui ne viennent pas exclusivement de Python.

Là où pip travaille avant tout dans l’écosystème des distributions Python, conda peut gérer un ensemble logiciel plus large.

C’est une différence importante.

Elle explique aussi pourquoi le choix entre pip et conda ne devrait pas toujours être traité comme un match de football.

Ils ne résolvent pas exactement le même problème.

Anaconda Navigator : conda sans vivre dans le terminal

Tout le monde n’a pas envie de commencer son exploration de Python avec :

conda env list

Anaconda Navigator fournit une interface graphique pour gérer une partie de l’environnement.

On peut notamment :

créer et sélectionner des environnements ;

rechercher et installer des packages ;

mettre à jour certains composants ;

lancer des applications comme JupyterLab ;

ouvrir des outils associés à différents environnements.

Navigator rend Anaconda particulièrement accessible aux personnes qui commencent en data science ou dans les notebooks.

Il permet de voir les environnements et packages comme des objets manipulables plutôt que comme une succession de commandes.

Ce n’est pas indispensable.

Mais pour certains utilisateurs, c’est précisément ce qui transforme la gestion des dépendances en quelque chose de moins abstrait.

Jupyter intégré à l’environnement

Anaconda Distribution inclut l’écosystème Jupyter.

Un notebook permet de mélanger :

code ;

résultats ;

texte ;

équations ;

visualisations ;

exploration interactive.

Cette manière de travailler correspond particulièrement bien à la data science et à la recherche.

On charge quelques données.

On exécute une cellule.

On regarde le résultat.

On modifie.

On produit un graphique.

On recommence.

L’environnement devient moins un programme linéaire qu’un carnet d’expérimentation exécutable.

Anaconda ne crée évidemment pas Jupyter.

Mais l’intégrer directement à la Distribution réduit fortement la distance entre l’installation et le premier notebook utilisable.

Des packages scientifiques préassemblés

La Distribution fournit un grand ensemble de packages testés pour fonctionner ensemble.

On retrouve des bibliothèques destinées à :

analyse de données ;

calcul numérique ;

visualisation ;

statistiques ;

machine learning ;

traitement du langage ;

notebooks ;

outillage scientifique.

Le metapackage Anaconda publié dans les canaux officiels dépasse aujourd’hui les 400 packages dans certaines configurations.

Le dépôt Anaconda donne accès à plusieurs milliers de packages supplémentaires.

Le vrai bénéfice n’est donc pas seulement la quantité.

C’est le travail effectué autour de leur construction, de leurs dépendances et de leur disponibilité sur plusieurs plateformes.

Channels : plusieurs sources pour les packages

Conda organise les repositories sous forme de channels.

Les canaux defaults pointent notamment vers les dépôts gérés par Anaconda.

Mais il existe d’autres sources.

La plus connue est probablement conda-forge.

Ce projet communautaire construit et distribue une immense collection de packages conda.

On peut installer depuis un canal particulier :

conda install --channel conda-forge package

Cette liberté est fondamentale.

Utiliser conda ne signifie pas nécessairement utiliser uniquement les packages construits par Anaconda.

Et c’est précisément là que la distinction entre conda, Anaconda Distribution et les repositories Anaconda devient essentielle.

Exporter et reproduire un environnement

Un environnement qui fonctionne sur une machine est utile.

Un environnement que l’on peut reconstruire ailleurs l’est davantage.

Conda permet d’exporter des informations sur les dépendances d’un environnement, notamment vers des fichiers YAML.

On peut ensuite créer un environnement à partir d’une spécification :

conda env create --file environment.yml

Cela facilite :

le partage entre collaborateurs ;

la reconstruction d’un environnement ;

le passage vers une autre machine ;

certains workflows CI/CD ;

la documentation des dépendances.

Mais la reproductibilité parfaite possède ses subtilités.

Des packages peuvent dépendre de la plateforme ou de l’architecture.

Un environnement exporté depuis Linux x86-64 n’est pas nécessairement une recette universelle parfaitement identique pour macOS ARM.

Le fichier d’environnement est une aide.

Pas une machine à voyager entre les systèmes sans aucune conséquence.

Python n’est pas la seule chose que conda sait gérer

Conda a été créé autour de Python, mais son modèle de packages ne lui est pas limité.

Il peut distribuer des éléments liés à :

R ;

C ;

C++ ;

Fortran ;

Java ;

ou différents exécutables et bibliothèques système.

Pour un scientifique ou un ingénieur, cette propriété peut être beaucoup plus importante qu’elle n’en a l’air.

Le notebook est écrit en Python.

Mais la pile qui le fait fonctionner peut traverser plusieurs langages avant d’arriver au processeur.

Anaconda essaie de transformer tout cela en une installation cohérente.

Une base adaptée aux GPU et au calcul scientifique

Les environnements de machine learning impliquent souvent :

framework ;

version de Python ;

bibliothèques système ;

runtime GPU ;

drivers ;

CUDA ;

packages complémentaires.

Tout ne peut pas être résolu automatiquement par Anaconda — notamment les drivers système eux-mêmes.

Mais conda peut simplifier une partie importante de la pile logicielle.

C’est historiquement l’une des raisons de sa popularité pour PyTorch, TensorFlow, RAPIDS et de nombreux environnements scientifiques.

Quand l’application dépend de beaucoup de composants compilés, le poids supplémentaire de conda peut devenir un avantage plutôt qu’un défaut.

Cas d’usage

Commencer la data science sans construire soi-même tout l’environnement

Tu veux suivre un cours.

Il demande Python.

NumPy.

pandas.

Jupyter.

Matplotlib.

scikit-learn.

Le tutoriel commence dans six minutes.

Ce n’est probablement pas le moment idéal pour découvrir les subtilités des wheels, ABI, compilateurs et environnements virtuels.

Anaconda Distribution fournit un raccourci.

Installer.

Lancer Navigator ou le terminal.

Ouvrir Jupyter.

Commencer.

Pour l’apprentissage, cette simplicité reste l’un de ses meilleurs arguments.

Séparer plusieurs projets scientifiques incompatibles

Un ancien projet dépend de Python 3.10.

Le nouveau utilise Python 3.14.

Un outil interne exige une version précise de NumPy.

Une expérimentation veut les dernières versions disponibles.

Créer plusieurs environnements conda permet de conserver ces projets côte à côte sans demander à une seule installation globale de résoudre leurs contradictions.

Chaque projet retrouve son petit univers.

Personne ne parle aux voisins.

La paix est préservée.

Préparer un environnement de machine learning

Tu veux tester un notebook avec PyTorch, pandas, JupyterLab et plusieurs bibliothèques scientifiques.

Le projet utilise aussi des dépendances compilées.

C’est exactement le terrain historique d’Anaconda.

Un environnement dédié peut contenir les versions nécessaires sans contaminer le reste du système.

Si une expérimentation devient inutilisable :

on supprime l’environnement.

On recommence.

C’est infiniment plus agréable que de découvrir six mois plus tard pourquoi modifier NumPy dans le Python global a détruit trois projets qui n’avaient rien demandé.

Donner le même point de départ à une équipe ou une formation

Une formation accueille vingt personnes.

Windows.

macOS.

Linux.

Différents niveaux techniques.

Le but du cours est d’analyser des données.

Pas de consacrer la première matinée à :

« Pourquoi pip ne trouve pas cette bibliothèque sur ton ordinateur ? »

Une distribution préassemblée peut réduire fortement cette friction initiale.

Dans un contexte professionnel, les outils de gestion, dépôts privés et fonctions de sécurité des offres supérieures peuvent ensuite pousser cette logique plus loin.

Travailler avec des bibliothèques difficiles à compiler localement

Certains packages Python reposent sur du code natif.

Si une wheel compatible existe, pip peut être parfaitement simple.

Si elle n’existe pas, l’histoire peut devenir plus sportive.

Compilateur.

Headers.

Bibliothèque système.

Versions.

Flags.

Et soudain ce petit pip install ressemble à un rite initiatique.

Les packages conda sont conçus pour embarquer davantage de ces dépendances.

Dans les environnements scientifiques et techniques, cela peut éviter une quantité non négligeable de bricolage local.

Utiliser Python sans vouloir apprendre immédiatement toute sa plomberie

Anaconda est souvent recommandée aux débutants parce qu’elle réduit le nombre de concepts nécessaires au départ.

Il n’est pas nécessaire de comprendre immédiatement :

où se trouve Python ;

quel pip correspond à quel environnement ;

comment installer Jupyter ;

comment créer un environnement ;

où se trouve la bibliothèque compilée qui manque.

On peut apprendre progressivement.

Cette simplification a cependant un prix : certaines personnes utilisent Anaconda pendant des années sans vraiment comprendre ce qui relève de Python, conda, Navigator ou Jupyter.

Le confort peut masquer l’architecture.

Ce n’est pas dramatique.

Mais il arrive un moment où connaître les couches devient utile.

Avis PANACHES

Anaconda résout un problème très réel.

Python est facile à installer.

Une pile scientifique Python complète et cohérente, beaucoup moins systématiquement.

Ce sont deux problèmes différents.

Anaconda s’est imposée en construisant un pont entre eux.

Sa force : rendre un environnement complexe banal

NumPy.

SciPy.

Jupyter.

pandas.

Bibliothèques natives.

Versions de Python.

Dépendances.

Environnements.

Tout cela peut être installé séparément.

Et aujourd’hui, les outils Python modernes rendent cette opération beaucoup plus facile qu’il y a dix ans.

Mais Anaconda possède encore une qualité importante :

elle transforme une pile scientifique relativement complexe en environnement presque ordinaire.

Créer.

Activer.

Installer.

Lancer le notebook.

Continuer.

Dans les domaines où les dépendances natives sont nombreuses, cette banalité possède une vraie valeur.

Mais l’écosystème Python a beaucoup changé autour d’elle

Il y a quelques années, la recommandation « installe Anaconda » était presque automatique dans de nombreux tutoriels de data science.

Aujourd’hui, le paysage est plus nuancé.

venv et pip se sont améliorés.

Les wheels sont beaucoup plus répandues.

pyproject.toml a structuré le packaging moderne.

uv a radicalement accéléré et simplifié de nombreux workflows Python.

Miniforge fournit une porte d’entrée plus minimale vers conda et conda-forge.

micromamba propose encore une autre approche.

Les conteneurs sont courants dans les environnements de production.

Anaconda n’est donc plus nécessairement le choix par défaut pour chaque développeur Python.

Et c’est une bonne chose.

Un outil n’a pas besoin d’être universel pour rester excellent dans son domaine.

Anaconda Distribution ou Miniconda ?

C’est probablement la question la plus pratique.

Si tu veux un environnement immédiatement rempli d’outils scientifiques, Anaconda Distribution est confortable.

Si tu sais déjà ce dont tu as besoin et préfères construire progressivement ton environnement, Miniconda est beaucoup plus légère.

On pourrait résumer ainsi :

Anaconda Distribution : cuisine équipée.

Miniconda : pièce vide avec les arrivées d’eau et d’électricité.

Les deux utilisent conda.

La différence tient surtout à ce qui est installé avant même que tu commences.

Et Miniforge ?

Miniforge devient particulièrement intéressant lorsqu’on veut :

conda ;

un installateur minimal ;

conda-forge comme source par défaut ;

et éviter que l’accès aux dépôts Anaconda entre dans l’équation commerciale.

Il est maintenu par la communauté conda-forge et n’est pas fourni par Anaconda.

Pour un développeur expérimenté qui veut surtout la mécanique conda sans la distribution Anaconda, c’est une alternative extrêmement crédible.

Son paradoxe : simplifier en installant beaucoup

Anaconda facilite le démarrage en apportant énormément de choses.

C’est précisément ce qui peut la rendre lourde.

Un environnement minimal construit avec uv ou Miniconda peut contenir uniquement :

Python ;

le gestionnaire ;

les cinq bibliothèques nécessaires.

Anaconda Distribution arrive avec un ensemble beaucoup plus vaste.

Pour l’apprentissage et l’exploration scientifique, c’est pratique.

Pour un petit service web de 30 Mo dont les seules dépendances sont FastAPI et HTTPX, beaucoup moins.

Le bon choix dépend donc de la densité réelle du projet.

Anaconda brille surtout quand le problème n’est plus seulement Python, mais tout ce qu’il faut faire cohabiter autour de Python.

Et en production ?

Anaconda peut participer à des workflows professionnels sérieux.

Mais installer la Distribution complète sur chaque serveur n’est pas nécessairement le modèle idéal.

Selon le contexte, on peut préférer :

environnements conda plus ciblés ;

Miniconda ;

Miniforge ;

conteneurs ;

repositories privés ;

solutions Anaconda Business ;

ou d’autres chaînes de packaging.

La Distribution est excellente comme poste de travail scientifique.

Elle ne doit pas être confondue avec une architecture de déploiement universelle.

Pour qui ?

Anaconda reste particulièrement pertinente pour :

débutants en data science ;

étudiants et chercheurs ;

scientifiques ;

analystes de données ;

équipes de machine learning ;

utilisateurs ayant de nombreuses dépendances natives ;

personnes préférant une GUI pour gérer environnements et packages.

Pour un développeur Python généraliste qui maîtrise déjà ses dépendances, un environnement plus minimal peut être plus agréable.

Et pour quelqu’un qui veut uniquement conda :

installer toute Anaconda Distribution n’est probablement pas nécessaire.

Points d’attention

Gratuit ne signifie plus « gratuit pour absolument tout le monde »

C’est le point qu’il faut comprendre avant le téléchargement.

Les conditions actuelles d’Anaconda autorisent notamment l’utilisation gratuite de la plateforme pour :

les particuliers dans le cadre d’un usage personnel et non commercial ;

certaines institutions académiques éligibles ;

certaines organisations de recherche ou à but non lucratif éligibles ;

les organisations commerciales comptant 200 employés ou prestataires au maximum, en tenant compte des affiliés selon les conditions d’Anaconda.

Au-delà de ce seuil, une organisation commerciale doit souscrire une offre Business lorsqu’aucune exemption ne s’applique.

Ce n’est donc plus simplement :

« Anaconda est gratuit. »

La bonne formulation est :

Anaconda possède des usages gratuits et des usages commerciaux soumis à licence.

Les tarifs concernent aujourd’hui une plateforme plus large

L’offre actuelle ne se limite plus à l’installateur desktop.

Les plans affichés comprennent :

Free : 0 $

Starter : 15 $ par utilisateur et par mois

Business : 50 $ par utilisateur et par mois, avec achat direct jusqu’à 15 sièges puis contact commercial pour davantage.

Selon le plan apparaissent ensuite davantage de stockage cloud, collaboration, notebooks, sécurité, gouvernance, repositories privés, SSO et fonctions destinées aux entreprises.

Il faut donc distinguer :

le logiciel local ;

l’accès aux dépôts ;

et les services de plateforme.

Mettre tout cela dans la même boîte nommée « Anaconda » est pratique commercialement.

Un peu moins lorsqu’on essaie de comprendre exactement ce qui est facturé.

Conda est open source ; Anaconda Distribution et ses services ne doivent pas être confondus avec lui

conda est open source.

De nombreux packages distribués par Anaconda sont eux-mêmes open source.

Jupyter est open source.

Python est open source.

Une grande partie de ce qui se trouve dans l’environnement Anaconda possède donc son propre code source et sa propre licence libre.

Mais cela ne signifie pas que l’offre Anaconda Distribution, les repositories et la plateforme Anaconda dans leur ensemble soient simplement un produit open source sans conditions commerciales.

Les Terms of Service d’Anaconda s’appliquent à l’utilisation de ses Offerings et de ses dépôts.

C’est pourquoi cette fiche classe la Distribution comme proprietary, tout en précisant qu’elle assemble énormément de composants open source.

Cette nuance est importante.

Miniconda n’annule pas automatiquement les règles des repositories Anaconda

Miniconda est un installateur minimal.

Son installation elle-même ne nécessite pas une licence commerciale simplement parce qu’une organisation dépasse 200 personnes.

Mais il est configuré par défaut pour accéder aux repositories Anaconda.

Et l’accès à ces dépôts peut déclencher les conditions commerciales.

Depuis juillet 2025, les versions récentes de Miniconda demandent d’ailleurs explicitement l’acceptation des Terms of Service lors de l’accès aux repositories concernés.

Installer Miniconda et utiliser defaults ne signifie donc pas automatiquement avoir contourné la question de licence.

Conda-forge possède une situation différente

Anaconda précise que les obligations de paiement de ses Terms of Service ne s’appliquent pas aux packages communautaires de conda-forge hébergés sur anaconda.org.

Anaconda héberge ces contenus, mais ne construit pas elle-même les packages conda-forge.

C’est l’une des raisons pour lesquelles Miniforge + conda-forge constitue une option particulièrement intéressante dans certaines organisations.

Le même outil de gestion d’environnements.

Une chaîne de distribution différente.

Encore une fois :

conda et Anaconda ne sont pas synonymes.

La Distribution est lourde

Les prérequis officiels annoncent au moins 5 Go d’espace disque pour télécharger et installer Anaconda Distribution.

Et ce n’est que le début.

Chaque nouvel environnement conda peut ajouter :

une version de Python ;

des bibliothèques natives ;

des packages scientifiques ;

des caches d’installation.

Plusieurs environnements de machine learning peuvent rapidement consommer des dizaines de gigaoctets.

Ce n’est pas nécessairement un problème sur une workstation moderne.

Mais pour un petit projet Python, il existe des solutions infiniment plus légères.

Ne transforme pas base en grenier

Anaconda possède un environnement base.

Il est tentant d’y installer progressivement :

Jupyter.

PyTorch.

TensorFlow.

Une bibliothèque trouvée mardi.

Un package expérimental vendredi.

Puis une dépendance ancienne nécessaire à un projet de 2021.

Six mois plus tard, base devient un musée interactif de conflits de versions.

Anaconda recommande elle-même de créer des environnements séparés pour les projets.

C’est probablement le meilleur conseil pratique de toute la fiche.

Garde base relativement propre. Crée un environnement pour chaque projet important.

Mélanger pip et conda demande de savoir ce que l’on fait

Il est possible d’utiliser pip dans un environnement conda.

Parfois, c’est même nécessaire lorsqu’un package n’existe pas dans les channels conda choisis.

Mais les deux gestionnaires ne suivent pas exactement les mêmes métadonnées ni le même modèle de résolution.

Installer avec conda.

Modifier avec pip.

Réinstaller avec conda.

Revenir à pip.

Peut finir par produire un environnement dont aucun gestionnaire ne possède complètement l’histoire.

En pratique, mieux vaut généralement :

installer autant que possible avec conda ;

puis utiliser pip pour ce qui reste nécessaire ;

et éviter ensuite de faire des allers-retours arbitraires.

Les channels ne sont pas interchangeables sans conséquences

defaults.

conda-forge.

Channels privés.

Repositories internes.

Un environnement peut utiliser plusieurs sources.

Mais les packages peuvent avoir été construits avec des chaînes de compilation, dépendances ou conventions différentes.

Mélanger des channels sans comprendre leur priorité peut provoquer des incompatibilités difficiles à diagnostiquer.

Pour beaucoup de projets, utiliser une stratégie cohérente — par exemple conda-forge avec priorité stricte — est plus prévisible que collectionner les channels comme des extensions de navigateur.

macOS Intel est désormais un cas à part

Anaconda Distribution 2025.06 a été annoncée comme la dernière version de la Distribution prenant en charge les Mac Intel osx-64.

Les versions récentes ciblent donc Apple Silicon côté macOS.

Un ancien Mac Intel peut toujours utiliser des versions historiques de la Distribution et certains packages existants.

Mais il ne faut plus s’attendre au même niveau de support pour les nouvelles releases.

Pour un parc matériel ancien, ce détail peut être décisif.

Windows 10 entre lui aussi dans la zone historique

La documentation Anaconda indique que le support des nouvelles releases de packages pour Windows 10 a pris fin le 30 juin 2026.

Cela ne signifie pas que toute installation Anaconda existante sous Windows 10 cesse soudainement de fonctionner le lendemain.

Mais l’écosystème récent se déplace vers les versions Windows encore supportées.

Au 8 août 2026, un nouveau poste destiné à un environnement Anaconda moderne a donc tout intérêt à partir sur Windows 11 plutôt que sur Windows 10.

Les architectures disponibles ne sont pas toutes équivalentes

Les versions actuelles ciblent principalement :

Windows x86-64 ;

macOS Apple Silicon ARM64 ;

Linux x86-64 ;

Linux ARM64.

Sur Linux ARM, Anaconda précise que certains builds ciblent des microarchitectures serveur comme Neoverse N1/N2.

Un Raspberry Pi ARM64 n’est donc pas automatiquement équivalent à un serveur Graviton simplement parce que les deux affichent aarch64.

Pour les petites machines ARM, vérifier les builds compatibles reste indispensable.

Les versions scientifiques privilégient parfois la stabilité plutôt que la dernière nouveauté

Anaconda construit et teste des ensembles de packages destinés à fonctionner ensemble.

Cette stratégie peut signifier qu’une bibliothèque disponible dans le repository Anaconda n’est pas toujours sa toute dernière version publiée sur PyPI ou conda-forge.

Ce n’est pas forcément du retard.

C’est souvent le compromis recherché entre :

nouveauté ;

compatibilité ;

stabilité ;

sécurité ;

reproductibilité.

Pour un chercheur qui veut absolument la feature sortie hier soir, ce compromis peut être frustrant.

Pour une équipe qui veut retrouver le même environnement demain matin, il peut être rassurant.

Un environnement n’est pas automatiquement reproductible sur toutes les plateformes

Un fichier environment.yml aide énormément.

Mais un environnement scientifique peut dépendre :

de l’OS ;

de l’architecture ;

des packages disponibles ;

des bibliothèques natives ;

du GPU ;

des drivers.

Exporter un environnement macOS puis exiger qu’il reconstruise exactement la même pile sous Linux n’est donc pas toujours réaliste.

Pour une reproductibilité forte, il faut penser au-delà de la simple liste de packages :

versions ;

channels ;

plateforme ;

architecture ;

et parfois conteneurisation.

Anaconda simplifie l’entrée, pas toutes les étapes qui viennent après

C’est probablement la limite la plus importante.

Anaconda peut rendre très simple :

l’installation de Python ;

la création d’un environnement ;

l’installation de packages ;

le lancement de Jupyter.

Mais elle ne supprime pas :

les incompatibilités ;

les dépendances difficiles ;

les problèmes de GPU ;

les différences d’architecture ;

les mises à jour cassantes ;

le packaging d’une application ;

le déploiement ;

la sécurité de la supply chain.

Elle retire beaucoup de friction.

Elle ne transforme pas l’écosystème scientifique en univers sans friction.

Et heureusement, peut-être.

Sinon les développeurs commenceraient à se demander quoi faire de leurs matinées.

Anaconda n’est pas la manière obligatoire d’utiliser Python. C’est une manière de rendre les environnements scientifiques complexes suffisamment ordinaires pour pouvoir enfin travailler avec eux.