Le tournant des langages de programmation IA : pourquoi Mojo et Rust défient la domination de Python

En décembre 2025, Modular a publié « The Path to Mojo 1.0 », visant une sortie courant 2026. Pour un langage de programmation, une version 1.0 est l’équivalent d’une introduction en bourse — une déclaration que le langage est prêt pour la production et là pour durer. Chris Lattner, le créateur de Swift et de LLVM, a passé trois ans à construire un langage qui promet quelque chose que la communauté IA avait cessé d’espérer : la lisibilité de Python avec la vitesse du C. Les benchmarks soutenant cette promesse ne sont pas modestes. Sur des charges de travail computationnelles spécifiques, Mojo a démontré des accélérations de 35 000x par rapport à Python. Sur du matériel plus puissant, ce chiffre dépasse les 68 000x.

En bref : La domination de Python dans l’IA est contestée sur deux fronts : Mojo offre une syntaxe compatible Python avec des performances rivalisant avec le C++, tandis que Rust devient discrètement le langage de l’infrastructure ML en production. Pendant ce temps, Python lui-même évolue — le GIL est devenu optionnel en 3.13 et officiellement supporté en 3.14 — mais l’écosystème se fragmente peut-être plus vite qu’il ne peut s’adapter.

Ces chiffres semblent absurdes jusqu’à ce que l’on comprenne d’où ils viennent. Python est un langage typé dynamiquement et interprété. Il n’a jamais été conçu pour le type de calcul numérique en boucle serrée qui définit les charges de travail IA modernes. Le Global Interpreter Lock (GIL) empêchait le vrai multithreading. La surcharge de l’interpréteur ajoutait de la latence à chaque opération. Pendant des décennies, la communauté IA a contourné ces limitations en écrivant le code critique en performance en C, C++ ou Fortran, puis en l’enveloppant dans des bindings Python. NumPy, PyTorch, TensorFlow — ils sont tous Python en surface et C/C++ en dessous.

Mojo pose une question simple : et s’il n’était plus nécessaire de recourir au contournement ?

Mojo : syntaxe Python, performance système

Mojo n’est pas un remplacement de Python. C’est un surensemble de Python — ou aspire à l’être. Le code écrit en Python devrait, en théorie, s’exécuter dans Mojo. Mais Mojo ajoute des fonctionnalités que Python a délibérément exclues : le typage statique, la gestion manuelle de la mémoire, les opérations SIMD (Single Instruction Multiple Data) et l’accès direct au matériel. Ces ajouts permettent à Mojo de compiler en code machine qui s’exécute sur CPU et GPU avec la même efficacité que du C++ optimisé à la main.

Le pedigree de Lattner confère au projet une crédibilité qu’un langage de startup typique n’aurait jamais. Il a créé LLVM, l’infrastructure de compilation qui sous-tend pratiquement toute la chaîne d’outils des langages de programmation modernes. Il a créé Swift, qui a remplacé Objective-C comme langage principal pour le développement Apple. Il comprend, peut-être mieux que quiconque, ce qu’il faut pour construire un langage que les développeurs adoptent réellement.

Les revendications de performance, bien que faisant les gros titres, nécessitent du contexte. L’accélération de 68 000x provient de l’exécution de l’algorithme de Mandelbrot sur une instance h3-standard-88 Intel Xeon avec du parallélisme au niveau matériel et des optimisations SIMD — des fonctionnalités auxquelles le Python pur ne peut pas accéder mais que tout langage compilé peut exploiter. Un portage direct de code Python vers Mojo a obtenu une accélération de 89x ; l’emploi d’optimisations spécifiques au problème a poussé ce chiffre à 26 000x. Une attente plus réaliste pour les charges de travail typiques est une amélioration de 10x à 1 000x pour les tâches computationnellement lourdes, ce qui reste transformateur pour les charges de travail IA où les entraînements peuvent prendre des jours ou des semaines.

Exécuter du code Python inchangé dans Mojo — sans aucune optimisation spécifique à Mojo — atteint environ 12x d’amélioration de vitesse. Ce gain de performance gratuit provient de la compilation seule, avant que le développeur n’écrive une seule ligne de code spécifique à Mojo. Ajouter des fonctionnalités spécifiques à Mojo comme la vectorisation SIMD peut pousser cela à 900x par rapport à Python et 9x plus rapide que NumPy.

Le défi auquel Mojo fait face n’est pas technique. Il est écologique. La domination de Python dans l’IA repose non pas sur le langage lui-même mais sur son écosystème de bibliothèques. PyTorch, TensorFlow, Hugging Face Transformers, scikit-learn, pandas, NumPy — ces bibliothèques représentent des décennies de travail accumulé par des milliers de contributeurs.

Modular répond à cela par l’interopérabilité Python, permettant aux programmes Mojo d’appeler directement les bibliothèques Python. En février 2026, Modular a acquis BentoML, un framework de serving de modèles utilisé par plus de 10 000 organisations dont plus de 50 entreprises du Fortune 500. L’acquisition signale que l’écosystème commence à se coaliser autour de la vision de Mojo. Mais construire un écosystème de bibliothèques se mesure en années, pas en mois.

La bibliothèque standard de Mojo a été publiée en open source sous licence Apache 2, avec plus de 750 000 lignes de code open source et une communauté de plus de 50 000 membres. Lattner s’est engagé à ouvrir le code du compilateur Mojo d’ici la fin de 2026.

Rust : le langage de l’infrastructure

Tandis que Mojo cible le chercheur et le data scientist — les personnes qui écrivent les architectures de modèles et les boucles d’entraînement — Rust conquiert une couche différente de la pile IA. Il devient le langage de l’infrastructure ML : les moteurs d’inférence, les systèmes de serving de modèles, les pipelines de données et les couches d’abstraction matérielle qui se situent entre le code Python du chercheur et le matériel réel.

Ce n’est pas un hasard. L’inférence IA à grande échelle est fondamentalement un problème de programmation système. Vous avez besoin de sécurité mémoire (un seul dépassement de tampon dans un système de serving peut planter l’ensemble du service), de performances prévisibles (les pics de latence dans les pipelines d’inférence coûtent de l’argent) et de concurrence efficace (servir des milliers de requêtes d’inférence simultanément nécessite des modèles de threading que Python ne peut tout simplement pas fournir).

Hugging Face a construit Candle, un framework ML minimaliste pour Rust optimisé pour l’inférence plutôt que l’entraînement. Candle supporte les modèles basés sur les transformers et est conçu pour les environnements serverless et edge où les binaires légers et la faible latence comptent. Il élimine Python des charges de travail de production entièrement, supprimant la surcharge de l’interpréteur et les goulots d’étranglement liés au GIL. Candle n’essaie pas de remplacer PyTorch pour la recherche. Il remplace les piles d’inférence basées sur Python en production.

Le framework Burn adopte une approche plus large. Construit entièrement en Rust par l’équipe de Tracel AI, Burn fonctionne à la fois comme bibliothèque de tenseurs et framework de deep learning. Son compilateur JIT, désormais propulsé par MLIR et LLVM via l’intégration CubeCL, supporte les backends CPU et GPU avec fusion automatique de kernels, auto-tuning et programmation GPU multiplateforme via CUDA et WebGPU. Burn peut importer des modèles ONNX via son crate burn-onnx, ce qui signifie que les chercheurs peuvent entraîner en PyTorch et déployer en Burn sans réécrire leurs modèles.

L’adoption de Rust en entreprise pour l’infrastructure IA s’accélère. L’utilisation commerciale de Rust a augmenté de 68,75 % entre 2021 et 2024, les entreprises du Fortune 500 pariant leur infrastructure sur la sécurité mémoire. Microsoft a accéléré sa migration de C/C++ vers Rust pour les systèmes critiques en sécurité après que les données ont montré que 70 % des vulnérabilités de sécurité provenaient d’une utilisation mémoire non sécurisée. Cloudflare a construit Infire, un moteur d’inférence LLM personnalisé écrit en Rust, en 2025. Dans les benchmarks, le framework Burn avec CUDA a atteint 97 % des performances de PyTorch+CUDA sur le modèle Phi-3 avec 30 % de surcharge mémoire en moins.

Python contre-attaque : le GIL est enfin mort

Les mainteneurs de Python ne sont pas restés inactifs pendant que les concurrents tournaient autour. Python 3.13, sorti en octobre 2024, a rendu le GIL optionnel pour la première fois de l’histoire du langage via un build free-threaded expérimental. Python 3.14, sorti le 7 octobre 2025, a fait passer le Python free-threaded d’expérimental à officiellement supporté, avec l’implémentation de la PEP 703 entièrement complétée.

L’impact est substantiel. Le code personnalisé de multiplication matricielle multi-threadé s’exécute presque 10 fois plus vite avec le GIL désactivé — 4,56 secondes contre 43,95 secondes. Les tâches limitées par les E/S utilisant des pools de threads sont plus de 3 fois plus rapides dans le build free-threaded. Les threads du PyTorch DataLoader peuvent désormais opérer en vrai parallèle. NumPy et pandas peuvent traiter des blocs de données simultanément. Les pipelines d’ingénierie de features qui étaient précédemment bloqués par le GIL peuvent maintenant s’échelonner sur les coeurs CPU disponibles.

Mais la suppression du GIL n’est pas une solution miracle. La surcharge du runtime free-threaded, bien que dramatiquement réduite d’environ 40 % en 3.13 à 5-10 % en 3.14, n’est toujours pas nulle. Le Python 3.14 standard s’exécute toujours avec le GIL activé par défaut ; vous devez télécharger ou compiler une version free-threaded séparée. Et la migration de l’écosystème prendra des années. Les bibliothèques doivent être testées et validées pour la sécurité des threads. Les extensions C doivent être auditées. Des comportements qui étaient accidentellement sûrs sous le GIL peuvent devenir dangereux sans lui.

La suppression du GIL résout la limitation de performance la plus fondamentale de Python, mais elle ne comble pas l’écart avec les langages compilés. Un programme Python free-threaded reste un programme interprété, typé dynamiquement. Il est plus rapide qu’avant, mais il n’est pas rapide de la manière dont Mojo, Rust ou C++ le sont.

Julia : le concurrent du calcul scientifique

Julia mérite d’être mentionné comme le quatrième acteur de ce paysage, bien que sa trajectoire soit différente des autres. Conçu de zéro pour le calcul scientifique, Julia offre une syntaxe proche de Python, une notation mathématique semblable à MATLAB et des performances approchant le C lorsqu’il est compilé en JIT. Julia 1.12 est sorti le 7 octobre 2025, et depuis 2025, Google Colab supporte officiellement Julia nativement.

Julia a trouvé sa niche dans les domaines où performance computationnelle et expressivité mathématique se croisent : modélisation climatique, bio-informatique, découverte de médicaments, ingénierie financière et simulation physique. Son système de dispatch multiple — où le même nom de fonction peut se comporter différemment selon les types de tous ses arguments — est particulièrement bien adapté au calcul scientifique où les opérations sur les matrices, vecteurs et tenseurs doivent être à la fois expressives et efficaces.

Mais Julia a du mal à sortir du monde académique pour s’imposer dans le développement IA/ML grand public. Son écosystème de paquets, bien qu’en croissance, reste une fraction de celui de Python. La compilation JIT introduit une pénalité de latence à la première exécution (le problème du « time to first plot ») qui frustre les workflows interactifs. Et les bibliothèques d’apprentissage automatique, bien que techniquement impressionnantes, manquent de l’élan communautaire et du soutien d’entreprise dont jouissent PyTorch et TensorFlow.

L’argument de l’écosystème

La leçon la plus importante de l’histoire des langages de programmation est que la performance brute détermine rarement quel langage l’emporte. FORTRAN est plus rapide que Python pour le calcul numérique. C++ est plus rapide pour tout. Ils ont perdu face à Python dans l’espace IA non pas parce qu’ils étaient des langages inférieurs mais parce que Python avait de meilleures bibliothèques, une meilleure documentation, un meilleur support communautaire et une barrière à l’entrée plus basse.

Cet argument de l’écosystème fonctionne dans les deux sens. Il protège la position actuelle de Python : personne ne va réécrire PyTorch en Mojo l’année prochaine. Mais il contraint aussi l’avenir de Python : les contournements qui ont rendu Python viable pour l’IA — écrire le code critique en performance en C/C++ et l’envelopper — créent une architecture fragile où le calcul réel se fait dans un langage que la plupart des data scientists ne peuvent ni lire ni modifier.

La stratégie de compatibilité Python de Mojo est la réponse la plus intelligente à ce problème. Si Mojo peut exécuter du code Python existant tout en offrant un gradient progressif vers de meilleures performances — écrivez en Python, puis optimisez les boucles critiques en Mojo sans quitter le même fichier — il pourrait capturer l’écosystème sans nécessiter une migration en bloc. C’est, grosso modo, la manière dont Swift a capturé l’écosystème d’Objective-C. Lattner applique le même playbook.

L’approche de Rust est différente et tout aussi valide. Plutôt que de concurrencer Python au niveau du chercheur, il remplace C/C++ au niveau de l’infrastructure. C’est sans doute le changement le plus conséquent. Le code qui s’exécute en production — servant des millions de requêtes d’inférence, traitant des données d’entraînement à grande échelle, gérant des clusters GPU — a toujours été écrit en langages système. Si ce code migre de C/C++ vers Rust, la communauté IA gagne la sécurité mémoire et les garanties de concurrence sans sacrifier la performance.

Ce que cela signifie pour les développeurs

La recommandation pratique en 2026 est simple : apprenez Python en profondeur, parce qu’il ne disparaîtra pas en tant que lingua franca de la recherche et du prototypage IA. Mais apprenez aussi un langage système. Si vous voulez optimiser les modèles IA et rester dans l’écosystème Python, surveillez de près Mojo à mesure qu’il approche la version 1.0. Si vous voulez construire de l’infrastructure de production, apprenez Rust.

L’ère où Python était le seul langage qui comptait pour l’IA touche à sa fin. Ce qui le remplace n’est pas un autre langage unique mais une pile polyglotte où différents langages servent différentes couches. Python pour la recherche et le prototypage. Mojo pour le code de modèle critique en performance. Rust pour l’infrastructure. Les développeurs qui prospéreront dans cet environnement seront ceux qui peuvent travailler à travers ces couches plutôt que de se spécialiser dans une seule.

Sources et lectures complémentaires

• The Path to Mojo 1.0 — Modular Blog
• BentoML Is Joining Modular — BentoML Blog
• What’s New in Python 3.14 — Python Official Documentation
• Candle: A New Machine Learning Framework for Rust — Hugging Face GitHub
• Burn: A Next-Generation Deep Learning Framework for Rust — Tracel AI
• Rust’s Enterprise Breakthrough Year — Rust Trends
• From Swift to Mojo and High-Performance AI Engineering with Chris Lattner — The Pragmatic Engineer
• Rust for AI and Machine Learning in 2025 — Andrew Odendaal