Infrastructure
npm : Node Package Manager. « Gestionnaire de paquets de Node », par analogie avec une centrale d'achat qui stocke des milliers de pièces détachées et les livre à la demande, avec toutes les pièces dont elles dépendent.
Trois choses sous un nom : npm désigne à la fois l'outil en ligne de commande livré avec Node.js, le registre public qui héberge les paquets et l'entreprise qui l'exploite. Officiellement, le projet affirme d'ailleurs que « npm » n'est pas un sigle, malgré l'usage courant.
Manifeste et lockfile : Le fichier package.json déclare les dépendances avec des plages de versions ; package-lock.json fige l'arbre exact résolu. On versionne le second si on veut que deux installations produisent le même résultat.
Dépendances transitives : Chaque paquet tire ses propres dépendances, qui tirent les leurs. Vingt ans de métier apprennent que le dossier node_modules finit toujours par peser plus lourd que l'application, et par contenir du code que personne dans l'équipe n'a jamais lu.
Surface d'attaque : Les scripts d'installation (preinstall, postinstall) s'exécutent sur la machine avec les droits de l'utilisateur. Typosquatting, compte de mainteneur compromis ou paquet abandonné puis repris : le registre est une cible classique d'attaque sur la chaîne d'approvisionnement.
Ce qui arrive si on s'en passe
Sans gestionnaire de paquets, chaque bibliothèque est copiée à la main dans le projet, et ses propres dépendances doivent être retrouvées une par une. Aucun registre ne note alors la version exacte de chaque pièce. Sans fichier de verrouillage (package-lock.json), deux installations successives peuvent produire des arbres différents, et il devient impossible de savoir ce qui tournait à une date donnée. L'empreinte d'intégrité que npm vérifie au téléchargement disparaît aussi : un fichier modifié en chemin ou sur un miroir est accepté sans contrôle. La commande npm audit, qui compare l'arbre installé aux avis de sécurité publiés, n'a plus rien à analyser. Une dépendance vulnérable passe donc inaperçue, surtout si elle est indirecte. Enfin, pour appliquer un correctif, il faut retrouver à la main chaque copie concernée, ce qui allonge la durée pendant laquelle la faille reste exploitable.
Explication de la marmotte
Quand on écrit un programme, on ne refait pas tout soi-même : on réutilise des morceaux déjà écrits par d'autres, un peu comme on achète de la farine au lieu de moudre son propre blé. npm, c'est à la fois un immense magasin en ligne rempli de ces morceaux gratuits et le livreur qui va les chercher. Tu lui donnes ta liste de courses, il rapporte tout, y compris ce dont tes ingrédients ont eux-mêmes besoin pour fonctionner. Très pratique, mais attention : si quelqu'un glisse un ingrédient pourri dans le magasin, il arrive aussi dans ta cuisine sans que tu l'aies vu.
Où ce terme est utilisé
- Maîtriser le risque des dépendances transitives (npm, pip, Maven, Go) (4 occurrences)
- JavaScript et SQL côté web, ce qu'il faut savoir des deux langages (3 occurrences)
- Sécuriser les mises à jour automatiques de dépendances et semver (3 occurrences)
- CICD-SEC-3 : abus de la chaîne de dépendances (2 occurrences)
- La chaîne d'approvisionnement logicielle (2 occurrences)
- Slopsquatting, paquets inventés par les assistants de code IA (2 occurrences)
- ASI04 : chaîne d'approvisionnement agentique (1 occurrence)
- Hermes Agent, le harnais d'agent autonome de Nous Research (1 occurrence)
- Installer et utiliser Codex, l'agent de code d'OpenAI (1 occurrence)
- Installer et utiliser GitHub Copilot en mode agent (1 occurrence)
