Comment réviser un inventaire tiers avant publication

Parce que l'import vous dit seulement ce qui est présent, pas si les métadonnées de licence sont fiables : les registres de paquets étiquettent parfois mal les licences, les fournisseurs changent leurs conditions, et les dépendances transitives introduisent du copyleft inattendu. Un fichier d'inventaire tiers est une entrée, pas une page de conformité terminée.

L'ampleur du phénomène est documentée, et ce sont exactement les cas que l'import automatisé ne peut pas résoudre seul.

Les verrous de révision existent pour que vous ne puissiez pas publier une URL de conformité des licences qui en dit plus que ce que votre équipe a vérifié. Les achats et les auditeurs considèrent la page publique comme votre représentation des obligations de licences tierces.

Partez des artefacts rattachés au build que vous livrez : package-lock.json, pnpm-lock.yaml, yarn.lock, go.mod, Cargo.lock, pom.xml, Gemfile.lock, un SBOM CycloneDX depuis la CI, ou des exports de votre outil SBOM existant. Marquez chaque ligne en attente de révision jusqu'à ce que quelqu'un confirme la licence.

Limitez l'import à un seul produit. Les entreprises multi-produits ont besoin de pages de conformité des licences séparées, ou de sections clairement distinctes, par produit livré. Mélanger les inventaires crée des erreurs de divulgation.

• Importez les lockfiles ou SBOM depuis la branche de version, pas depuis main si elle diverge.
• Incluez les polices, icônes, SDK et ressources embarquées que votre politique exige.
• Signalez les doublons et fusionnez les entrées qui font référence au même composant.
• Enregistrez la date d'import et l'empreinte du fichier source pour le journal d'audit.
• Ne publiez pas automatiquement. Chaque entrée démarre non révisée.

Pour chaque ligne, confirmez que l'identifiant de licence correspond à l'usage réel, pas seulement aux métadonnées de package.json. Repérez les déclencheurs de copyleft. Joignez le texte intégral de la licence. Documentez explicitement les exclusions.

Les réviseurs se concentrent sur la GPL, la LGPL, l'AGPL, les SDK propriétaires, et les composants avec des données de licence manquantes ou contradictoires. Ces lignes bloquent la publication tant qu'elles ne sont pas résolues.

• Faites correspondre la licence à sa source : fichier LICENSE du dépôt, accord fournisseur, ou identifiant SPDX confirmé par un humain.
• Ajoutez le texte intégral de la licence au dossier avant de marquer comme approuvé.
• Signalez le copyleft, le copyleft réseau (AGPL) et les licences personnalisées pour une revue par le juridique ou l'ingénierie senior.
• Résolvez les conflits (le registre indique MIT, le dépôt indique Apache) avant d'approuver.
• Documentez les composants exclus du produit livré, et pourquoi.
• Exigez un second approbateur pour les licences à haut risque, si votre politique en définit un.

Ne publiez que lorsque les verrous sont franchis : aucune ligne non révisée, texte intégral joint, périmètre du produit clair, URL stable. La page de conformité des licences publique contient les mêmes données que vos exports. Un seul inventaire révisé, plusieurs sorties.

Les pages de divulgation de licences tierces doivent se charger sans authentification, lister les composants clairement, et inclure le texte intégral des licences que les achats peuvent rechercher et copier. C'est ce que recherchent les revues en environnement grand compte.

• Bloquez la publication si un composant du périmètre n'a pas de texte de licence approuvé.
• Générez l'URL publique et vérifiez-la en navigation privée avant de la partager en externe.
• Exportez les lots JSON, d'attribution et de divulgation à partir du même instantané approuvé.
• Enregistrez qui a approuvé la publication et à quel tag de version elle correspond.

La conformité des licences n'est pas un exercice ponctuel. De nouvelles dépendances, des montées de version et des changements de licence arrivent à chaque sprint. Les contrôles de dérive comparent les lockfiles ou SBOM actuels à votre dernière publication approuvée, et signalent les différences avant que les clients ne les remarquent.

Quand l'inventaire change, relancez les verrous de révision. Mettez à jour la page de conformité des licences. N'envoyez des URL mises à jour aux achats qu'une fois la nouvelle publication approuvée, pas dès que l'import se termine.

• Exécutez des contrôles de pipeline ou de CI à chaque pull request, tag ou version.
• Signalez les nouveaux paquets non révisés avant la version, selon votre politique.
• Réapprouvez les composants copyleft quand le modèle de liaison ou de distribution change.
• Conservez le journal d'audit : import, révision, publication, événements de dérive.