npm ajoute un jeton qui prépare la publication sans pouvoir la déclencher
Le 18 septembre 2026, npm a ajouté aux jetons d’accès granulaires l’option Read and write (stage only). D’après l’annonce de GitHub, ce réglage autorise un workflow à préparer une version avec npm stage publish, mais lui interdit de la publier directement, même si le contournement de la 2FA est activé; le jeton conserve toutefois la capacité de déplacer des dist-tags et de déprécier des versions.
La version préparée ne devient publique qu’après son examen et son approbation par un mainteneur soumis à l’authentification à deux facteurs. Le relevé indépendant de Releasebot confirme le 18 septembre le caractère facultatif de ce nouveau réglage, l’absence de modification des jetons existants et l’objectif de supprimer en janvier 2027 la publication directe au moyen des jetons qui contournent la 2FA.
La CI s’arrête désormais avant la mise en ligne
Le nouveau jeton sépare la transmission technique du paquet de la décision de le rendre installable. La CI peut envoyer l’archive dans la zone de staging sans interaction humaine, mais elle ne possède plus l’autorité nécessaire pour franchir la dernière étape vers le registre public.
La documentation de npm sur la publication échelonnée exige npm CLI 11.15.0 ou une version ultérieure, Node.js 22.14.0 au minimum, la 2FA sur le compte et un droit de publication sur un paquet déjà présent dans le registre. La procédure ne permet donc pas de préparer la toute première version d’un nouveau paquet.
- Le workflow reçoit un jeton granulaire limité aux paquets nécessaires et configuré avec l’autorisation Read and write (stage only).
- Il exécute npm stage publish; l’archive est téléversée dans la zone d’attente, sans devenir publiquement disponible.
- Un mainteneur retrouve la préparation avec npm stage list, en consulte les informations avec npm stage view ou télécharge l’archive avec npm stage download.
- Après examen, il lance npm stage approve dans la CLI ou approuve la version sur npmjs.com, puis répond au contrôle 2FA.
La commande de préparation elle-même ne réclame pas de second facteur. Le contrôle de présence humaine est déplacé vers l’approbation finale: une exécution non interactive peut terminer le travail de CI, mais elle ne produit pas à elle seule une nouvelle version installable.
Une publication directe reste techniquement bloquée
Remplacer seulement le secret du workflow ne suffit pas. Si la chaîne conserve npm publish, npm refuse l’opération; il faut également modifier la commande pour employer npm stage publish. Cette distinction empêche qu’un jeton dérobé ou détourné serve directement à introduire une nouvelle version dans le registre.
Le contrôle ne certifie cependant pas le contenu du paquet. Il garantit qu’une personne autorisée doit intervenir avant la mise en ligne, mais la valeur de cette barrière dépend de l’examen réalisé: approuver systématiquement une archive sans la consulter réduirait l’étape humaine à une simple confirmation 2FA.
Le même partage des rôles fonctionne avec Trusted Publishing et OIDC. Dans ce cas, la CI utilise un identifiant de courte durée plutôt qu’un jeton permanent, tout en envoyant encore la version dans la zone d’attente; un mainteneur doit ensuite l’approuver avec la 2FA.
Le jeton garde des droits d’écriture sensibles
Stage only ne signifie pas lecture seule. Outre la préparation d’une nouvelle version, le jeton peut toujours déplacer des dist-tags et déprécier des versions dans les paquets auxquels il a accès. Ces actions ne créent pas une version publique, mais elles modifient l’état du registre et la façon dont les utilisateurs identifient ou installent les versions proposées.
La portée du secret reste donc déterminante. Le limiter aux seuls paquets nécessaires réduit les conséquences d’une compromission, mais l’approbation 2FA ne protège que le passage d’une préparation à une nouvelle version publique. Elle ne constitue pas une autorisation générale pour les autres écritures effectuées avec le jeton.
Cette frontière explique aussi pourquoi le jeton doit rester protégé comme tout identifiant disposant d’un accès en écriture. La nouvelle option retire un pouvoir précis à l’automatisation — publier directement une version — sans neutraliser les autres opérations permises par son périmètre.
Une coexistence avant le changement visé pour janvier 2027
L’ajout est facultatif: les jetons existants ne sont pas convertis et conservent pour l’instant leur capacité de publication directe. Les équipes peuvent donc migrer progressivement en créant un nouveau jeton, en remplaçant npm publish par npm stage publish et en organisant l’examen humain qui précède l’approbation.
Janvier 2027 demeure une cible annoncée pour le retrait de la publication directe avec les jetons granulaires configurés pour contourner la 2FA, et non une date de bascule plus précise. À ce stade, npm propose donc deux voies pour l’automatisation: Trusted Publishing avec OIDC, ou le jeton à préparation seule lorsque le workflow doit encore reposer sur un secret, dans les deux cas avec une approbation humaine pour une version placée en staging.
À lire aussi:
Abonnez-vous à notre newsletter
Recevez directement les dernières actualités sur le Web3, l’IA et les cryptomonnaies.