Un gestionnaire de paquets Python est un outil qui sert à installer, mettre à jour et supprimer des bibliothèques de code tierces pour vos projets. Les principaux outils de ce type sont pip, Poetry, PDM et uv, que je vous avais déjà présenté.
Voici un arbre de décision pour vous aider à choisir entre ces quatre outils, selon votre contexte de projet :
Je vous propose maintenant un tableau de comparaison, avec les infos à jour (notamment sur uv, qui évolue rapidement en ce moment) :
| Critère | pip | uv | Poetry | PDM |
|---|---|---|---|---|
| Mainteneur | Python Packaging Authority (PyPA), outil historique | Astral, racheté par OpenAI en mars 2026 pour l'intégrer à Codex | Communauté open source indépendante | Communauté open source indépendante |
| Écrit en | Python | Rust | Python | Python |
| Résolution des dépendances | Basique (resolver depuis 2020, moins robuste) | Résolveur dédié basé sur PubGrub (même algorithme que le gestionnaire de paquets de Dart) | Résolveur maison, fiable mais parfois lent | Résolveur maison, conforme PEP |
| Fichier de lock | Aucun natif (nécessite pip-tools) | uv.lock natif |
poetry.lock natif |
pdm.lock natif |
| Gestion des environnements virtuels | Manuelle (module venv séparé) |
Automatique via .venv, aucune activation manuelle nécessaire avec uv run |
Automatique | Automatique, ou PEP 582 sans venv |
| Gestion des versions Python | Aucune | Remplace complètement pyenv : télécharge et bascule entre versions de CPython | Aucune (délègue à pyenv) | Limitée |
| Vitesse | Référence de base (lente sur gros projets) | 10 à 100 fois plus rapide que pip, Poetry ou pipenv | Correcte, plus lente que uv | Correcte, plus lente que uv |
| Backend de build par défaut | — (setuptools en général) | uv_build, backend maison d'uv, par défaut depuis juillet 2025 (Hatchling avant) | poetry-core | pdm-backend (interchangeable) |
Conformité PEP 621 (pyproject.toml standard) |
Non applicable | Oui, natif | Partielle (section [tool.poetry] historique, PEP 621 en progression) |
Oui, strict |
| Publication sur PyPI | Via twine séparément |
uv publish intégré |
poetry publish intégré, très rodé |
pdm publish intégré |
| Écosystème / plugins | Immense (standard universel) | Aucun système de plugins pour l'instant | Large écosystème de plugins mûrs | Écosystème de plugins, plus modeste |
| Compatibilité pip | — | Interface uv pip pour migration progressive |
Limitée | Limitée |
| Cas d'usage idéal | Script isolé, compatibilité maximale, environnements contraints | Nouveau projet, monorepo, CI/CD, besoin de vitesse | Projet déjà en Poetry, équipe habituée à son workflow | Besoin de conformité PEP stricte ou de PEP 582 |
- uv est devenu le choix par défaut pour la majorité des nouveaux projets en 2026 : vitesse, outil tout-en-un. Son point faible reste l'absence de plugins et le fait qu'il soit encore en version 0.x (bien que jugé stable en production).
- Poetry garde l'avantage de la maturité : plus de plugins, plus de retours d'expérience, un workflow de publication très éprouvé.
- PDM reste un choix de niche pour qui veut coller strictement aux standards PEP ou utiliser PEP 582.
- pip n'a de sens aujourd'hui que pour un script isolé ou dans un contexte où on ne peut pas installer d'autres outils.
