Le meilleur qui soit arrivé à Python en décennies est écrit en Rust

TL;DR : Les outils Python sont depuis des années un désastre fragmenté et lent. La révolution n’est pas venue de l’intérieur de l’écosystème : elle est venue de Rust. uv, Ruff et ty — tous écrits en Rust par Astral — ont remplacé une demi-douzaine d’outils et sont entre 10x et 100x plus rapides. À la fin, le culte de Ferris avait peut-être un peu raison.

Avez-vous déjà essayé d’expliquer à quelqu’un comment installer des dépendances en Python ?

“Utilise pip. Enfin, dans un virtualenv. Ou venv, qui est le nouveau. Mais si tu as plusieurs versions de Python, tu as besoin de pyenv. Et pour gérer le projet, utilise poetry. Ou pipenv. Ou pdm. Ou conda si tu fais de la science des données. Ah, et le lock file est généré par chaque outil dans un format différent. Et n’oublie pas setup.py. Enfin, maintenant c’est pyproject.toml. Enfin, parfois les deux.”

Si ça vous dit quelque chose, vous n’êtes pas seul. Randall Munroe y a consacré une bande de xkcd en 2018 — un diagramme spaghetti montrant toutes les façons dont Python peut être installé sur votre machine. Huit ans plus tard, la bande reste pertinente. Ou l’était, jusqu’à récemment.

Le cimetière des outils

Faisons l’inventaire. Pour monter un projet Python “moderne” avant 2024, il fallait combiner — au minimum — une sélection de ces pièces :

Huit outils — au minimum — pour ce qui dans d’autres écosystèmes fait un ou deux. Chacun avec sa configuration, son fichier de config, ses incompatibilités avec les autres. Installer poetry dans un virtualenv créé par pyenv_ qui à son tour utilise un Python installé par Homebrew qui s'avère avoir un autre pip` global qui… bon, vous voyez le genre.

Et le pire : tous les quelques années apparaissait un nouvel outil qui promettait d’unifier le tout. Pipenv allait être la solution. Puis poetry. Puis pdm. Le xkcd des standards prenant vie en boucle : “Nous avons 14 outils, c’est absurde. Je vais créer un outil unifié. Maintenant nous avons 15 outils.”

Et puis un crabe arriva

En 2022, un gars appelé Charlie Marsh — ex de Khan Academy et Spring Discovery — publia un linter Python appelé Ruff. Écrit en Rust.

La réaction de la communauté Python fut prévisible : “Génial, encore un linter”. Jusqu’à ce qu’ils voient les chiffres. Ruff était entre 10x et 100x plus rapide que Flake8. Pas 20% plus rapide. Pas deux fois plus rapide. Cent fois plus rapide. Dans une base de code importante, un linting qui prenait 30 secondes passait à 300 millisecondes.

Mais Ruff ne s’est pas contenté d’être un linter rapide. Il a avalé Flake8, Pylint, isort et Black. Un outil, un binaire, zéro dépendance Python. Il fait du linting, formatte, trie les imports. Et il le fait si vite que vous pouvez l’exécuter à chaque frappe de touche dans l’éditeur sans remarquer le lag.

Charlie a fondé Astral pour structurer le projet. Et il a recruté des gens intéressants : l’équipe comprenait les auteurs de ripgrep, bat et hyperfine — des outils de terminal en Rust qui avaient déjà prouvé que réécrire des utilitaires classiques en Rust n’était pas un mème, mais une amélioration objective.

uv : quand pip ressemble à une connexion par modem

En février 2024, Astral a lâché la bombe : uv. Un gestionnaire de paquets et projets Python. Écrit en Rust.

En termes clairs : uv remplace pip, pip-tools, pipx, poetry, pyenv, virtualenv et twine. Tout. Un seul binaire.

Je sais ce que vous pensez : “Ouais, ouais, encore un outil qui dit remplacer tout”. Mais les chiffres sont hallucinants :

Ce n’est pas un benchmark synthétique. C’est ce que vous remarquez au quotidien. Le pip install qui vous donnait le temps d’aller prendre un café se termine maintenant avant que vous lâchiez Entrée.

Et uv n’est pas seulement rapide. Il a des lock files reproductibles, résolution de dépendances multiplateforme, gestion des versions Python intégrée (uv python install 3.12 et c’est fini), et exécution de scripts et outils isolés (uvx ruff check .). Ce qui vous demandait cinq outils avant, uv le fait avec une commande.

ty : le dernier clou

Comme si uv et Ruff ne suffisaient pas, en décembre 2025 Astral a publié la beta de ty : un type checker pour Python. Écrit en Rust.

Les chiffres, encore une fois, sont obscènes :

Après avoir édité un fichier dans le repo de PyTorch, ty recalcule les diagnostics en 4.7 millisecondes. Pyright prend 386ms. Mypy… mieux vaut ne pas demander.

ty a des intersection types, du narrowing avancé et un language server avec autocomplétion, inlay hints et navigation de code. Ce n’est pas un jouet rapide : c’est un type checker complet qui, en plus, vole.

Le tableau qui fait mal

Mettons les chiffres côte à côte. Ce que vous aviez avant, ce que vous avez maintenant, et à quel point c’est plus rapide :

Cinq catégories. Huit outils hétérogènes ou plus remplacés par trois qui partagent écosystème, configuration et maintenance. Tous écrits en Rust. Tous d’Astral.

Ce n’est pas que Python : Ferris dévore le terminal

Et ce n’est pas un phénomène isolé à Python. Regardez ce qui s’est passé avec les outils de terminal classiques :

Chacun de ces outils suit le même schéma : vous prenez un utilitaire Unix classique qui n’a pas eu d’amélioration UX depuis 30 ans, vous le réécrivez en Rust avec des defaults modernes (couleurs, .gitignore, parallélisme), et le résultat est si supérieur que les gens changent en une après-midi.

L’ironie est savoureuse : les mêmes développeurs qui disaient “réécrire en Rust c’est un mème” utilisent ripgrep, bat, fd et eza quotidiennement. Sans s’en rendre compte, le culte de Ferris les a convertis.

Distribuer un binaire : l’épreuve de vérité

Et puis il y a la distribution. C’est là que la différence entre Python et Rust passe de “notable” à “obscène”.

En Python, pour distribuer un CLI à quelqu’un qui n’a pas Python installé, vous avez besoin de : setup.py + setup.cfg + pyproject.toml (lequel ? les trois, au cas où), twine pour uploader sur PyPI en priant que l’authentification ne plante pas, PyInstaller ou Nuitka ou cx_Freeze pour faire des binaires (qui ne marchent pas), un workflow de CI de 200 lignes que personne ne comprend, des manylinux wheels pour chaque version de Python, et à la fin l’utilisateur fait pip install et ça plante parce qu’il a Python 3.9 et vous avez compilé pour 3.12.

En Rust, voici ce que j’ai fait avec lql, un CLI que je viens de construire :

git tag v1.0.2 && git push origin v1.0.2

Une commande. Cinq minutes plus tard : 6 binaires compilés pour macOS (Apple Silicon + Intel), Linux (x86 + ARM + musl statique) et Windows. Installeurs générés automatiquement : curl | sh pour Mac/Linux, PowerShell pour Windows, MSI pour les IT, et une formule Homebrew publiée dans son tap. Tout, depuis un tag Git.

Le binaire pèse 4.7 MB. Sans runtime. Sans dépendances. Vous le copiez et ça marche. Essayez de faire ça avec Python sans vous choper un ulcère.

La cerise sur le gâteau : l’élève dépasse le maître

Voici ce qui m’a vraiment époustouflé.

Les meilleurs outils qui soient arrivés à Python dans la dernière décennie — uv, Ruff, ty — ne sont pas écrits en Python. Ils sont écrits en Rust. Le langage que les pythonistes regardaient de haut (“trop compliqué”, “ça c’est pour l’embarqué”, “borrow checker infernal”) s’est révélé être celui qui a réglé les problèmes que Python n’arrivait pas à régler par lui-même.

Pourquoi ? Parce que le goulot d’étranglement de ces outils n’est pas la logique — c’est la performance pure. Résoudre un graphe de dépendances avec des milliers de paquets, parser des millions de lignes de code en cherchant des erreurs, vérifier les types dans une codebase de cent mille lignes. Ce sont des problèmes de force brute où chaque milliseconde compte, et où la différence entre un langage interprété et un langage compilé avec zero-cost abstractions se ressent.

Python est génial pour écrire du software. Mais les outils qui construisent, analysent et maintiennent ce software ont besoin de la vitesse que Python ne peut pas donner. Et Rust, avec sa sécurité mémoire, son système de types et ses performances, s’avère être le complément parfait.

C’est comme si votre voiture était fantastique mais que les mécaniciens du garage utilisaient des outils en plastique. Un jour quelqu’un leur a donné des outils en acier inoxydable, et il s’avère que la voiture roule aussi bien mais que l’atelier fonctionne dix fois plus vite.

Le plot twist : OpenAI entre en scène

Si vous pensiez que l’histoire ne pouvait pas devenir plus intéressante : le 19 mars 2026 — il y a une semaine — OpenAI a annoncé l’acquisition d’Astral. L’entreprise derrière uv, Ruff et ty rejoint l’équipe Codex.

Astral a promis de maintenir les outils open source. Mais le mouvement en dit long : OpenAI n’a pas acheté Astral pour le linter. Il a acheté une équipe qui sait construire des outils de développement extrêmement rapides en Rust. Et il les veut pour que les agents IA écrivent et gèrent le code mieux.

La convergence est claire. Les outils qu’utilisent les humains pour développer en Python (uv, Ruff, ty) et les outils qu’utilisent les agents IA pour écrire du code (Codex) vont partager l’ADN. Et cet ADN est écrit en Rust.

Qu’est-ce que je fais lundi ?

Si vous n’utilisez pas encore uv, la migration est triviale :

# Installer uv
curl -LsSf https://astral.sh/uv/install.sh | sh

# Migrer un projet existant
cd mon-projet
uv init                     # crée pyproject.toml s'il n'existe pas
uv add requests flask       # ajoute des dépendances
uv sync                     # installe tout dans .venv
uv run python app.py        # exécute dans l'environnement

Si vous utilisez Flake8, Black ou isort, remplacez-les par Ruff :

uv tool install ruff
ruff check .               # linter
ruff format .              # formateur

Et si vous êtes courageux, essayez ty pour la vérification de types :

uv tool install ty
ty check .

Trois commandes. Trois outils. Adieu le cauchemar de huit configurations différentes.

Au final, le culte avait raison

Ça fait des années que j’entends “tu devrais le réécrire en Rust” comme qui entend pleuvoir. Le mème RIIR (Rewrite It In Rust) ressemblait au mantra d’une secte d’évangélistes avec des t-shirts de crabes. Qu’ils continuent, me disais-je, ils vont bien se lasser.

Ils ne se sont pas lassés. Et il s’avère qu’ils avaient un argument.

Tout ne doit pas être réécrit en Rust. Mais les outils de développement — linters, type checkers, gestionnaires de paquets, utilitaires de terminal — sont exactement le type de software où Rust brille : performance critique, exécution fréquente, tolérance zéro aux pannes. Et les résultats parlent d’eux-mêmes.

Python reste mon langage pour écrire du software. Mais les outils avec lesquels j’écris ce software, de plus en plus, sont écrits en Rust. Et ils fonctionnent mieux que tout ce que Python a construit pour lui-même en deux décennies.

Ferris, le crabe, vous demande pardon pour le borrow checker. Mais en échange il vous donne un pip install qui dure 300 millisecondes et qui marche. Je dirais que c’est un marché honnête.