J'ai utilisé pip
pendant des années.
Poetry en équipe.
Puis uv est arrivé.

Si vous écrivez du Python, vous installez des paquets. C'est tout. Ça devrait être d'un ennui total.

Sauf que l'outil qui installe ces paquets façonne en douce toute votre journée : votre vitesse, la facilité à passer votre travail à quelqu'un d'autre, et le nombre de fois où ça casse sur la machine d'un collègue. J'en ai traversé trois. Pip pendant des années. Puis poetry, quand je me suis mis à construire en équipe. Et depuis peu uv, pour démarrer mes projets IA : un pipeline RAG avec Supabase, un service de synthèse vocale, une démo de reconnaissance d'images. Voici ce que j'ai vraiment ressenti — pas ce que raconte la doc.

Pip : celui que vous connaissez déjà

Pip vient avec Python. Tous les tutoriels s'en servent, toutes les images Docker l'embarquent. Vous tapez pip install requests et vous êtes parti. Pour apprendre, pour un script, pour un outil d'un seul fichier, c'est encore la bonne réponse.

Le problème arrive plus tard. Pip ne retient pas vraiment les versions exactes avec lesquelles vous avez travaillé. Vous écrivez un requirements.txt, vous figez deux ou trois paquets, vous vous croyez à l'abri. Six mois plus tard, une sous-dépendance bouge sans prévenir, et votre code ne se comporte plus pareil. Aucun moyen propre, alors, de revenir exactement à l'état d'avant.

Au moins, pip est honnête sur ce qu'il est : un installeur de paquets. Ni un gestionnaire de projet, ni un verrou de versions. Pour ça, il faut mettre quelque chose par-dessus.

python -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt

Ma règle : pip convient aux petits scripts et aux notebooks. Dès qu'un projet a un nom et un avenir, j'en veux davantage.

Poetry : quand d'autres personnes arrivent

Poetry a été ma réponse pendant longtemps. La bascule s'est faite le jour où quelqu'un d'autre a cloné mon dépôt sans arriver à le lancer. C'est là qu'on comprend que « ça marche sur ma machine » est un passif, pas un argument.

Poetry règle ça. Il tient un vrai lockfile : la version exacte de chaque paquet, figée. Un nouveau collègue lance poetry install et se retrouve avec votre environnement, au paquet près. Fini le « mais tu avais quelle version de numpy ? ».

Il gère aussi le reste, sans cérémonie : il sépare les outils de dév — tests, linters — des paquets de production, pour que votre image livrée ne traîne pas de bagages inutiles. Il publie sur PyPI si vous sortez une bibliothèque. Et il parle aux serveurs de paquets privés sans faire d'histoires.

[tool.poetry.dependencies]
python = "^3.11"
fastapi = "^0.110"

[tool.poetry.group.dev.dependencies]
pytest = "^8.0"
ruff  = "^0.3"

Le coût est réel. Poetry est plus lent que pip, surtout au moment de résoudre les dépendances. Il a sa propre façon de faire, comptez un ou deux jours pour l'apprivoiser. Et certaines bibliothèques IA, qui bougent vite, publient des wheels qui le déroutent.

Ma règle : dès qu'un projet compte plus d'une personne, poetry justifie sa place.

Uv : la surprise

Uv, lui, m'a pris de court. Je ne cherchais pas un nouvel outil : pip et poetry me suffisaient largement. Puis je m'en suis servi pour générer des squelettes de projets IA. RAG avec Supabase. Synthèse vocale. Reconnaissance d'images. Et quelque chose a cloché.

C'était rapide. Pas « un peu plus rapide ». Beaucoup plus rapide. Des installations d'une minute sous poetry se bouclaient en quelques secondes. La première fois, j'ai cru qu'il avait sauté une étape.

La raison, en clair : uv est écrit en Rust, pas en Python. Il ne traîne pas pendant qu'il réfléchit. Il installe vos paquets, gère votre version de Python — adieu pyenv à côté — et vous rend un fichier de projet très proche de celui de poetry. Le tout dans un seul binaire.

Poetry, c'est installer un atelier. Uv, c'est un couteau bien aiguisé.

Deux façons de s'en servir. Si vous tenez à pip, tapez uv pip install requests : même comportement, en beaucoup plus rapide. Si vous voulez le mode projet complet, uv init puis uv add requests vous donnent un lockfile et un environnement géré, sans un octet de configuration en plus.

Les réserves, honnêtement : uv est plus jeune que les deux autres. Une poignée de vieux paquets le font encore trébucher. Et l'écosystème autour — tutoriels, réponses Stack Overflow, recettes de CI — court toujours derrière celui de poetry.

Ma règle : si je démarre quelque chose cette semaine, je prends uv en premier.

Alors lequel, et quand ?

Voici comment j'y pense aujourd'hui :

• Un script ponctuel ou un notebook ? Pip, et n'y pensez pas plus longtemps.
• Un nouveau prototype IA ? Uv. Les secondes gagnées s'accumulent quand vous itérez cent fois par jour.
• Livrer un service en équipe ? Poetry. Le lockfile et les groupes de dépendances sont remboursés dès le premier collègue qui clone le dépôt.
• Publier une bibliothèque sur PyPI ? Poetry aujourd'hui. Uv y arrive, vite.

L'outillage n'a rien de glamour. Personne n'a jamais été recruté pour avoir choisi uv plutôt que poetry. Mais les trente secondes gagnées à chaque installation, et les trois heures que vous ne passez pas à déboguer un environnement cassé, finissent par compter. Prenez celui qui va au projet que vous avez devant vous, pas celui qui gagne le débat le plus bruyant en ligne.

J'utilise toujours les trois. Simplement plus pour les mêmes choses qu'avant.