Votre équipe prépare une nouvelle version d'un paquet npm. Le pipeline doit fabriquer l'archive, un mainteneur doit vérifier ce qui part au registre, puis quelqu'un décide quand les utilisateurs qui installent latest la reçoivent. Ces trois gestes ont des effets différents. Les changements annoncés par npm en septembre 2026 permettent de mieux les distribuer entre identités et équipes, à condition de regarder les droits réels de chaque identité.
Préparer, publier, puis promouvoir : trois décisions
Le 18 septembre, GitHub a annoncé pour npm des jetons granulaires « Read and write (stage only) ». Un workflow muni de ce jeton peut soumettre une version avec npm stage publish pour examen. Le jeton ne peut pas publier directement cette nouvelle version avec npm publish, même si une dérogation à l'authentification à deux facteurs avait été configurée. Un mainteneur examine et approuve ensuite la sortie avec une authentification à deux facteurs. Ce mécanisme place une décision humaine entre la préparation automatisée et la mise à disposition de la version.
La publication rend un numéro de version disponible dans le registre. La promotion concerne souvent un autre objet : un dist-tag, ou étiquette de distribution. Par exemple, latest pointe vers la version que beaucoup d'installations récupèrent par défaut. Déplacer cette étiquette peut changer ce que reçoivent les utilisateurs, sans créer une nouvelle archive. Ainsi, une équipe peut avoir publié une version et décider plus tard de la promouvoir. Cette distinction aide à désigner un responsable pour chaque étape.
Le 30 septembre, une seconde annonce npm a ajouté une permission facultative Allow npm dist-tag aux configurations de trusted publishing. Ce mode reconnaît un workflow au moyen d'OpenID Connect (OIDC), un échange d'identité qui évite de conserver un jeton d'accès long dans la CI. La permission permet d'agir sur les dist-tags avec des identifiants de courte durée. Elle est désactivée par défaut, pour les configurations nouvelles comme existantes. Elle est indépendante de la publication directe : une configuration destinée au staging peut aussi recevoir ce droit de promotion si l'équipe le lui accorde.
Lire les droits, pas seulement le nom du jeton
« Stage-only » peut donner une impression de pouvoir très limité. La publication du 18 septembre précise pourtant que ces jetons conservent d'autres droits d'écriture sur le paquet, notamment le déplacement des dist-tags et la dépréciation de versions. Ils ne doivent donc pas être traités comme des jetons en lecture seule. S'il est compromis, un tel jeton peut agir sur ce que les consommateurs installent, même sans publier une nouvelle version.
La permission OIDC de gestion des tags demande la même attention. Elle ne s'active pas seule, mais npm indique qu'une opération est autorisée si le jeton OIDC entrant correspond à une des configurations disposant de cette permission. Lors d'une revue de sécurité, l'inventaire doit donc porter sur toutes les configurations reconnues pour le paquet, et pas uniquement sur celle que l'équipe croit utiliser pour la promotion. Les anciennes opérations de dist-tag par jeton restent possibles ; l'arrivée d'OIDC ne les désactive pas.
Voici une matrice de conception à remplir pour votre paquet. La colonne de résultat est volontairement laissée ouverte : aucun test n'a été exécuté sur votre registre.
| Étape | Identité proposée | Capacité attendue | Vérification à consigner |
|---|---|---|---|
| Préparation | Workflow de construction | Créer l'archive et soumettre une version au staging | Archive, provenance, commande et statut observé. |
| Validation | Mainteneur autorisé | Examiner l'archive et approuver avec 2FA | Décision, identité et trace d'approbation. |
| Publication | Configuration ou mainteneur désigné | Rendre disponible la version validée | Numéro, empreinte et réponse du registre. |
| Promotion | Identité distincte si possible | Déplacer latest, next ou beta selon la règle |
Tag avant/après et autorisation utilisée. |
Cette matrice sépare les responsabilités ; elle ne prescrit pas une structure universelle. Une petite équipe peut confier plusieurs étapes aux mêmes personnes, mais elle doit alors savoir quelles permissions elles cumulent. Une grande équipe peut appliquer une séparation stricte pour les paquets dont la diffusion a un effet important.
Concevoir une chaîne de publication vérifiable
Commencez par l'archive. Avant l'approbation, le mainteneur doit pouvoir identifier le commit source, la version annoncée, le contenu du paquet et les scripts susceptibles de s'exécuter chez les consommateurs. Comparez l'archive soumise à celle issue du processus de construction attendu. La validation humaine n'a de valeur que si elle porte sur l'artefact effectivement publié, pas sur un simple intitulé de version.
Choisissez ensuite le chemin technique. Selon l'annonce npm du 18 septembre, le staging par jeton nécessite un paquet existant avec un accès de publication, la 2FA activée sur le compte, npm CLI 11.15.0 ou plus et Node.js 22.14.0 ou plus. Vérifiez ces prérequis dans votre environnement de qualification. L'annonce précise aussi que cette nouveauté est facultative et ne modifie pas les jetons existants ni leur capacité de publication directe. Une migration exige donc une action explicite sur les secrets et les commandes du workflow.
Pour la promotion, décidez qui peut déplacer chaque dist-tag et à quel moment : après des tests d'installation, après une validation métier ou immédiatement après publication. Limitez Allow npm dist-tag aux configurations qui doivent vraiment réaliser cette opération. Définissez aussi un retour arrière : identifier le numéro de version stable précédent, savoir qui peut remettre le tag et garder la preuve du changement. Un retour de tag ne supprime pas la version problématique et ne remplace pas la gestion des consommateurs qui auraient déjà installé celle-ci.
Tester les refus et documenter les exceptions
Sur un paquet ou un registre de démonstration, vérifiez les cas attendus et les refus : le jeton de staging soumet-il une version ? Une tentative de publication directe est-elle refusée ? Une configuration OIDC sans la permission de dist-tag est-elle incapable de déplacer latest ? Une configuration autorisée peut-elle le faire dans le cadre prévu ? N'exécutez aucune publication réelle pour illustrer ces contrôles. Inscrivez les réponses observées, la date et les identités de test dans la matrice ; ne remplacez pas ces preuves par le nom d'une permission.
Terminez par l'inventaire des jetons longs encore présents : paquet visé, étendue, propriétaire, date de rotation et raison de leur maintien. Certains peuvent rester nécessaires ; npm indique explicitement que la gestion des tags par jeton continue de fonctionner. Pour le cadre général des secrets CI et d'OIDC, l'article Partitech sur les droits de publication depuis une pull request apporte le contexte antérieur à ces nouveautés.
Au 1er octobre 2026, la décision pratique est simple : choisissez séparément l'identité qui prépare, celle qui approuve et celle qui fait pointer latest. Vérifiez ensuite les droits résiduels, en particulier sur les dist-tags. La séparation annoncée par npm offre des outils ; seule votre configuration et vos tests montrent quelle séparation existe effectivement dans votre chaîne.