Votre équipe veut publier sa première bibliothèque JavaScript depuis son pipeline automatisé. Qui crée le paquet, qui examine son contenu et quand l’identité du pipeline devient-elle validée ? Les deux changements npm annoncés le 2 octobre 2026 rendent cette séquence plus importante. Un paquet prêt à être examiné et une configuration de confiance valide sont deux états différents.
Le premier paquet ajoute une étape au lancement
Notre article du 1er octobre sur les étapes et permissions de publication npm détaille la séparation des droits ; celui-ci examine les nouveaux paquets et le cycle de validation de confiance annoncé le 2 octobre.
Prenons une bibliothèque fictive, réservée à notre scénario. Son archive contient le code destiné aux autres applications. Le pipeline prépare cette archive, mais une personne doit pouvoir l’examiner avant qu’une version utilisable soit distribuée. La question n’est pas seulement « l’automatisation peut-elle publier ? » : il faut aussi savoir ce qu’elle peut préparer et qui décide de sa mise à disposition.
Le 2 octobre, npm a annoncé la possibilité de créer un nouveau paquet avec npm stage publish, depuis une session locale ou un jeton granulaire, y compris un jeton limité à la préparation. La version soumise entre dans une file d’examen et doit être promue par un mainteneur avant de devenir installable. La configuration du paquet et du trusted publishing peut ensuite être organisée. Annonce sur les nouveaux paquets.
Le staged publishing désigne cette publication en attente d’approbation. Le trusted publishing est un mécanisme séparé : il autorise un environnement automatisé identifié à agir sur le paquet. Vous pouvez donc avoir une archive en attente et une confiance non validée, ou une confiance valide avec une archive encore non approuvée. L’article examine ces états, plutôt que de réunir tout le lancement sous un bouton « publier ».
Le changement des 48 heures concerne la confiance non validée
L’autre annonce du 2 octobre porte sur les configurations de trusted publishing non validées. Elles expirent 48 heures après leur création. Une première publication réussie les valide et les soustrait à cette expiration. Un changement d’identité du dépôt ou du projet exige une nouvelle relation de confiance ; une modification ordinaire ne remet pas le compteur à zéro. Les configurations expirées restent visibles et doivent être recréées pour ouvrir une nouvelle fenêtre. Annonce npm sur l’expiration.
La même annonce précise le refus des jetons issus d’événements GitHub Actions issue_comment, en plus de la restriction déjà appliquée à pull_request_target. Un déclencheur de workflow décrit la situation dans laquelle le pipeline démarre. Ici, un contexte refusé ne devient pas autorisé parce que son archive a été approuvée. Restriction des contextes de publication.
Ne transformez pas les 48 heures en durée de vie de tous vos secrets ni en délai universel de promotion d’une version. Cette fenêtre concerne un état précis de la configuration. Le scénario exact qui valide la confiance doit être constaté dans votre processus : la seule présence d’une archive en attente ne suffit pas à le démontrer.
Dessiner le parcours avant de lancer l’automatisation
Écrivez une fiche avec le nom du paquet, son responsable, le dépôt attendu et la version de départ. Ajoutez le composant qui produit l’archive, la personne qui l’examine et celle qui peut la promouvoir. Une même personne peut occuper plusieurs rôles, mais ces décisions doivent rester identifiables.
La documentation npm consultée le 6 octobre décrit une version d’attente 0.0.0-stage créée lorsqu’un paquet n’existe pas encore. Ce placeholder est public ; la version soumise et son contenu restent en attente jusqu’à l’approbation. Le staging a donc un effet visible sur le registre avant la distribution de votre archive réelle. La documentation indique également npm CLI 11.15.0 ou plus récent et Node 22.14.0 ou plus récent. Documentation staged publishing.
Pour notre bibliothèque fictive, la première vérification consiste à comparer l’archive à ce qui devait être livré. Examinez les fichiers inclus, les dépendances et les scripts susceptibles de s’exécuter lors de l’installation. Faites cela dans un environnement isolé adapté à votre projet. Le fait qu’une archive provienne d’un pipeline connu n’établit pas que son contenu correspond à la demande.
Documentez ensuite le passage entre préparation et promotion. La personne qui approuve doit savoir quelle archive a été examinée et à quelle version elle correspond. Une preuve de relecture d’un autre fichier, même portant un nom proche, n’est pas une preuve pour cet artefact. Votre suivi peut utiliser une empreinte du fichier dans les traces privées, sans encombrer le message destiné aux utilisateurs.
Suivre les deux cycles de vie
La table ci-dessous est une méthode de suivi proposée, fondée sur les états de confiance annoncés. Elle ne décrit pas une interface npm inventée.
| État de la confiance | Signification à vérifier | Action de l’équipe |
|---|---|---|
| Non validée | Première publication réussie encore non constatée | Préparer la validation dans la fenêtre prévue |
| Validée | Première publication réussie observée | Surveiller l’identité et les autorisations |
| Expirée | Fenêtre de validation terminée | Recréer la relation après examen du motif |
| Identité changée | Dépôt ou projet différent | Examiner et établir la nouvelle relation |
À côté, tenez un suivi indépendant de l’archive : préparée, examinée, approuvée puis distribuée. L’expiration d’une confiance ne prouve pas qu’une version a été retirée. L’approbation d’une archive ne prouve pas qu’un autre pipeline est autorisé. En séparant ces états, vous pouvez identifier le bon responsable lorsqu’une opération échoue.
Pour le mécanisme d’identité, expliquez à l’équipe ce que signifie OpenID Connect, souvent abrégé OIDC : le pipeline présente une preuve liée à son contexte d’exécution, plutôt qu’un simple secret permanent copié partout. La décision utile demeure l’identité effectivement admise. Un label OIDC dans une configuration ne remplace pas l’examen du dépôt, du workflow et du déclencheur.
Ajoutez une alerte opérationnelle adaptée au lancement : qui remarque une configuration toujours non validée, où la date de création est-elle consignée et qui décide d’une recréation ? Ne recréez pas automatiquement les relations sans comprendre pourquoi elles expirent. Une difficulté de coordination entre préparation, revue et lancement pourrait sinon rester invisible.
Tester les refus avec un modèle local
Avant toute action sur un registre, vous pouvez construire une simulation locale des états. Elle reçoit une configuration fictive, une date de création et un résultat de publication fictif. Elle calcule si la relation est non validée, validée ou expirée selon votre modèle de l’annonce. Les horaires sont des entrées de test, pas des observations sur npm.
Préparez quatre cas : relation non validée dans la fenêtre, relation non validée après expiration, relation validée et identité modifiée. Pour chaque cas, indiquez la transition attendue et la décision qu’un responsable devra prendre. Cette simulation teste votre compréhension et votre procédure ; elle ne qualifie pas à elle seule le comportement du registre.
Ajoutez des refus liés à l’archive : contenu absent, version examinée différente de la version proposée, approbation manquante. Ajoutez aussi un contexte d’exécution interdit. Le message obtenu doit indiquer quelle dimension est en cause, sans afficher une preuve d’identité ou un secret. La réponse appropriée à une archive non revue n’est pas de modifier la confiance du pipeline.
Pour un essai ultérieur autorisé sur un registre, vérifiez d’abord l’espace de noms, les propriétaires et les effets de création publique. Les commandes citées dans cet article servent à identifier les mécanismes ; aucun paquet n’a été créé et aucune commande de préparation, publication ou promotion n’a été exécutée pour produire ce contenu.
Prévoir une reprise compréhensible
Si la fenêtre expire, commencez par la chronologie : quand la relation a-t-elle été créée, quel événement devait la valider et quelle observation manque ? Vérifiez si le pipeline a réellement atteint l’étape de publication, si son identité correspond et si le contexte est autorisé. La recréation intervient après cet examen, avec le responsable de lancement.
Si l’archive reste en attente, cherchez du côté de l’examen et de l’approbation. Ne forcez pas une publication directe uniquement pour débloquer un calendrier. La procédure doit préciser qui peut décider d’abandonner une version, corriger l’archive ou reprendre la séquence. Vous préservez ainsi l’utilité de la séparation des rôles.
Pour votre premier paquet, retenez cinq critères : artefact inspecté, identité revue, validation effectivement observée, droit de promotion attribué et procédure d’expiration documentée. Cette grille ne mesure aucun gain de sécurité global ; elle donne des décisions concrètes à vérifier. Quand un critère manque, terminez la préparation correspondante avant d’étendre le pipeline aux versions suivantes.
Le lancement devient plus facile à expliquer lorsque chacun sait distinguer « paquet créé », « contenu approuvé » et « confiance validée ». Les annonces du 2 octobre modifient ces passages, mais votre règle d’équipe fait tenir la séquence. Essayez d’abord de la parcourir avec des données fictives et des refus prévus : vous saurez ensuite quelles preuves recueillir dans un essai réel autorisé.
Sources et date de vérification
Sources ouvertes le 6 octobre 2026 : expiration de la confiance, création d’un nouveau paquet en staging et documentation npm. Les deux annonces datent du 2 octobre ; la documentation vivante fournit du contexte. Le scénario et la simulation sont proposés, sans publication réelle ni résultat revendiqué.