Le choix d’un gestionnaire de paquets JavaScript pèse sur la durée de vie d’un projet bien plus qu’il n’y paraît : format de verrouillage des dépendances, vitesse d’installation en intégration continue, compatibilité avec le registre npm, support des monorepos. En 2026, le paysage a bougé sur ces quatre fronts à la fois, avec une réécriture majeure de pnpm et une consolidation de la place de Bun et Deno dans les usages professionnels.
npm, le socle qui reste la référence
Fourni par défaut avec Node.js, npm demeure le point d’entrée de la majorité des projets et le registre auquel tous les autres outils accèdent. Sa résolution de dépendances écrite en JavaScript reste plus lente que celle de ses concurrents, particulièrement sensible sur les installations à froid d’un grand nombre de paquets, mais sa universalité et l’absence de toute installation supplémentaire en font un choix par défaut raisonnable pour un projet simple ou une équipe qui ne veut pas ajouter d’outillage.
pnpm 12, une base réécrite en Rust
La version 12 de pnpm marque une rupture technique : le cœur de l’outil a été réécrit en Rust tout en conservant la compatibilité avec les commandes, options et formats de pnpm 11. Le gain se mesure surtout sur les installations répétées, celles qui bénéficient du cache local et d’un node_modules déjà en place. Les nouvelles versions 12.x ont aussi étendu les catalogs au protocole workspace:, ajouté des indicateurs de sécurité de chaîne d’approvisionnement sur remove et update, et introduit pnpm pipeline pour orchestrer les tâches d’un monorepo à la manière d’un job d’intégration continue.
Pour une équipe déjà organisée en monorepo avec des outils en ligne de commande standardisés, cette réécriture change peu les habitudes de travail tout en réduisant le temps passé à attendre une installation dans un pipeline de déploiement.
Bun, la vitesse comme argument central
Bun aborde le problème différemment : plutôt qu’un gestionnaire de paquets posé sur Node.js, c’est un exécutable unique écrit en Zig qui embarque runtime, bundler, testeur et gestionnaire de paquets. Son installateur s’appuie sur un nombre d’appels système nettement réduit par rapport à npm et sur un format de verrouillage binaire, ce qui explique les écarts de performance constatés dans plusieurs bancs d’essai publiés en 2026 sur des installations à froid comme sur des projets de grande taille. La contrepartie reste la compatibilité : Bun couvre l’essentiel de l’API Node.js, mais certains paquets natifs ou scripts d’installation avancés restent des cas particuliers à tester avant une migration complète.
Deno, la fin de l’isolement vis-à-vis de npm
Deno a longtemps cultivé un écosystème séparé de npm, avant d’y renoncer largement à partir de sa branche 2.x. Les préfixes npm: permettent désormais d’utiliser des paquets du registre npm sans fichier package.json, tout en conservant le modèle de permissions explicites qui a fait la réputation de l’outil sur la sécurité par défaut. Deno reste minoritaire en entreprise, mais son support de workspace et sa compatibilité npm en font une option crédible pour un nouveau projet qui veut limiter la surface de confiance accordée aux scripts d’installation.
Le format de verrouillage des dépendances ne se convertit pas automatiquement d’un outil à l’autre : changer de gestionnaire de paquets en cours de projet est une migration, pas un simple changement de commande.
Comparatif synthétique
| Outil | Approche | Format de lockfile | Compatibilité npm | Cas d’usage recommandé |
|---|---|---|---|---|
| npm | Résolution en JavaScript, fourni avec Node.js | package-lock.json (JSON) | Native | Projet simple, équipe sans outillage supplémentaire |
| pnpm 12 | Cœur réécrit en Rust, store de dépendances partagé | pnpm-lock.yaml (YAML) | Totale | Monorepo, équipe recherchant stabilité et rapidité sur cache |
| Bun | Runtime et gestionnaire natifs écrits en Zig | bun.lock (binaire ou JSONC) | Large, quelques cas particuliers | Installations fréquentes, sensibilité forte à la vitesse |
| Deno 2.x | Runtime sécurisé par permissions, spécificateurs npm: | deno.lock (JSON) | Via préfixe npm: | Nouveau projet, priorité donnée à la sécurité par défaut |
Installer un projet avec chacun des quatre outils
# npm (fourni avec Node.js)
npm install
# pnpm (via Corepack, recommandé pour figer la version)
corepack enable
pnpm install
# Bun
curl -fsSL https://bun.sh/install | bash
bun install
# Deno, avec compatibilité npm
deno install
Sécurité de la chaîne d’approvisionnement
Le choix d’un gestionnaire de paquets n’est pas qu’une question de vitesse : c’est aussi une question de confiance accordée à des scripts d’installation exécutés automatiquement. npm exécute par défaut les scripts postinstall de chaque paquet, ce qui a servi de vecteur à plusieurs attaques de la chaîne d’approvisionnement ces dernières années. pnpm bloque ces scripts par défaut depuis sa version 10 et exige une autorisation explicite via pnpm approve-builds, une différence qui pèse lourd sur un projet dépendant de centaines de paquets tiers. Deno pousse cette logique plus loin avec un modèle de permissions qui s’applique au runtime lui-même, pas seulement à l’installation. Bun, de son côté, a ajouté des indicateurs de sécurité mais conserve un comportement plus proche de npm sur l’exécution des scripts.
Pour une équipe qui gère plusieurs dépôts clients, ce critère mérite autant d’attention que la vitesse d’installation : un incident de sécurité lié à une dépendance compromise coûte largement plus cher que les quelques secondes économisées sur un pipeline de déploiement.
Monorepos et intégration aux outils de build
Le choix du gestionnaire de paquets se double souvent d’un choix d’orchestrateur de tâches pour les monorepos, comme Turborepo ou Nx. Les quatre outils exposent des workspaces compatibles avec ces orchestrateurs, mais le niveau d’intégration varie : pnpm reste la référence pour les monorepos volumineux grâce à son store de dépendances partagé, qui évite de dupliquer les paquets communs sur disque. Bun progresse rapidement sur ce terrain mais certains plugins d’orchestrateurs le prennent encore en charge de façon partielle. npm et Deno couvrent les cas simples sans étendre ces performances aux très grands monorepos.
Comment choisir sans se tromper
Le critère de vitesse d’installation ne devrait jamais être le seul arbitrage. Une équipe qui déploie plusieurs dizaines de fois par jour depuis une intégration continue gagnera davantage à optimiser le cache d’un outil déjà en place qu’à migrer vers un nouveau gestionnaire pour quelques secondes gagnées. À l’inverse, un projet neuf, sans dette d’outillage, peut choisir pnpm ou Bun sans coût de migration à assumer.
Pour un développeur freelance qui jongle avec plusieurs projets clients de tailles différentes, la priorité va généralement à la stabilité et à la compatibilité la plus large : pnpm reste le choix le plus sûr. Pour une startup qui optimise son temps de build en intégration continue sur un seul produit, Bun peut justifier son adoption si les tests de compatibilité sont concluants. Pour une équipe qui construit un nouveau service isolé avec une exigence de sécurité forte, Deno mérite d’être évalué avant d’écarter l’option par habitude.
Ce qu’il faut retenir
npm reste le choix par défaut légitime pour un projet simple. pnpm 12 a gagné en performance sans rien perdre de sa stabilité pour les monorepos. Bun continue de faire de la vitesse son principal argument de vente, avec une compatibilité qui s’améliore mais qui mérite d’être testée avant une bascule complète. Deno, enfin, a rendu sa compatibilité npm suffisante pour devenir une option raisonnable au-delà de son public historique.
Sur les projets clients gérés au quotidien, changer de gestionnaire de paquets rapporte rarement ce qu’on en attend : le temps gagné à l’installation se perd souvent dans les ajustements de scripts, de pipelines et d’habitudes d’équipe. Le vrai signal à suivre en 2026 n’est pas la course à la vitesse, mais la convergence progressive de tous ces outils vers un même registre npm et un même socle de compatibilité — Simon Janvier.
Pour aller plus loin : documentation officielle pnpm, « What’s different in pnpm 12 ».
