Achats

Ce que les achats demandent réellement

Une preuve continue que les obligations de licence restent à jour, pourquoi les exports ponctuels deviennent obsolètes, et comment répondre quand les dépendances évoluent plus vite que vos documents.

Dernière mise à jour : 2 juillet 2026

Les équipes achats, sécurité fournisseurs et IT grand compte demandent une page de licences open source, une divulgation de licences tierces, ou une documentation de conformité des licences logicielles pendant la diligence. La demande arrive souvent sous la forme d'une simple ligne dans un appel d'offres : « Fournissez votre documentation de conformité des licences open source. »

Ils veulent la preuve que vous savez quels logiciels tiers et open source se trouvent dans le produit qu'ils achètent, et que vous pouvez produire des obligations de licence révisées à la demande. Ce guide explique comment répondre honnêtement quand votre inventaire change chaque semaine.

Confirmez le périmètre avant de répondre
Quel produit, quelle version, quel format. La divulgation est spécifique à chaque produit.
Vérifiez par rapport à ce que vous livrez réellement
Comparez le dossier à la version examinée ; résolvez d'abord les lignes non révisées.
Répondez avec un périmètre précis, sans surpromettre
Envoyez le dossier révisé, nommez la version qu'il reflète, décrivez comment vous le maintenez à jour.

Pourquoi un export ponctuel n'est-il jamais suffisant ?

Parce que les produits ne sont pas figés à une version : les ingénieurs fusionnent des mises à jour de dépendances, ajoutent des SDK, changent de polices, et font évoluer des paquets transitifs, souvent sans qu'une seule personne ne suive l'ensemble des obligations. Vous ne pouvez pas affirmer de façon fiable « voici tout ce qui tourne en production actuellement » à partir d'un tableur construit il y a des mois.

Un PDF, un fichier zip ou une pièce jointe SBOM est un instantané. Dès que quelqu'un livre une version avec de nouveaux paquets, cet instantané devient historique. Pas faux par malveillance, simplement dépassé. Les achats l'archivent, présument qu'il est à jour, et découvrent l'écart des mois plus tard lors d'un audit ou d'un renouvellement.

La véritable exigence n'est pas « envoyez une URL plutôt qu'un PDF ». Vous avez besoin d'un inventaire révisé rattaché à ce que vous livrez, mis à jour quand les dépendances changent, et partagé seulement une fois les verrous de publication franchis. Une page de conformité publique est une façon d'héberger ce dossier pour que les deux parties voient la même version. Les liens n'ont rien de magique ; c'est le dossier qui se trouve derrière qui est censé être mis à jour.

Que demandent réellement les achats ?

Ils veulent la preuve que vous maîtrisez opérationnellement vos obligations de licences tierces, pas que vous avez un jour lancé npm list sur un ordinateur portable. Les questionnaires utilisent des mots différents (page de licences open source, liste de logiciels tiers, divulgation OSS, nomenclature logicielle plus texte de licence), mais l'intention est similaire.

Une nomenclature logicielle seule ne satisfait souvent pas la demande. Les éléments minimaux d'un SBOM, tels que définis par la NTIA américaine, se concentrent sur l'identité des composants pour un usage de vulnérabilité et d'inventaire, pas sur une divulgation de licences révisée. Les réviseurs achats et juridique veulent tout de même le texte intégral des licences et une certaine confirmation que la liste reste alignée sur les versions.

Inventaire tiers et open source révisé pour le produit examiné.
Texte intégral des licences ou liens fiables, pas de simples identifiants SPDX sans texte.
Attribution et mention là où les licences les exigent.
Une clarté sur le produit, la version ou la date que reflète la divulgation.
Souvent une URL, un export ou une pièce jointe, selon ce que précise leur processus.
De plus en plus : comment vous maintenez le dossier à jour quand les dépendances changent.

Étape 1 : confirmez le périmètre avant de répondre

N'envoyez pas le pied de page de licence de votre site vitrine si l'acheteur évalue votre produit API, votre application mobile ou votre programme d'installation sur site. Chaque produit livré peut avoir besoin de son propre dossier de divulgation, ou d'une section clairement délimitée.

Demandez quel SKU, nom de produit, version ou date de version couvre la revue. La conformité des licences est spécifique à chaque produit. Envoyer la documentation du mauvais produit crée plus de travail que de ne rien envoyer du tout.

Quel produit ou SKU est examiné ?
Quelle version, tag de version ou date la divulgation doit-elle refléter ?
Veulent-ils une URL, un fichier d'export, ou les deux ?
La revue concerne-t-elle le SaaS, un logiciel installable, l'embarqué, ou tous les modèles de livraison ?
Qui est le public visé : les achats, le juridique, la sécurité, ou les trois ?

Étape 2 : vérifiez par rapport à ce que vous livrez réellement

Avant de répondre, vérifiez que le dossier correspond au build que reçoivent les clients. Pas la branche main, pas la machine locale d'un développeur, pas un inventaire que personne n'a révisé depuis le trimestre dernier.

Dans une équipe de plusieurs personnes, les dépendances évoluent sans notification centralisée. Un ingénieur fait une montée de version patch ; un autre ajoute un SDK d'analytique ; un paquet transitif change les métadonnées de licence dans le registre. Sans verrous d'import, de révision et de publication, personne ne sait que la divulgation est obsolète avant qu'un acheteur ne pose la question.

Comparez votre divulgation au lockfile, au SBOM ou à l'export de la version examinée. Contrôlez au hasard les composants copyleft, les SDK commerciaux, et tout ce qui est marqué en attente de révision. Si vous ne pouvez pas vérifier chaque ligne, corrigez l'écart ou soyez honnête sur le délai.

Importez depuis la branche de version ou l'artefact CI, pas depuis une liste manuelle obsolète.
Confirmez que chaque composant du périmètre a un texte de licence approuvé.
Résolvez les lignes non révisées avant de représenter le dossier en externe.
Vérifiez que le nom du produit sur la divulgation correspond à ce que l'acheteur achète.
Notez le tag de version ou la date que reflète l'inventaire, et indiquez-le dans votre réponse.

Étape 3 : répondez avec un périmètre précis, sans surpromettre

Envoyez ce qu'ils ont demandé (URL, export PDF, lot JSON) à partir du même instantané de publication approuvé. Indiquez quel produit et quelle version il couvre. Décrivez brièvement comment vous mettez à jour le dossier quand les dépendances changent : réimport, nouvelle révision, republication.

Ne laissez pas entendre une validation juridique, sauf si un juriste l'a approuvée. Ne dites pas « voici tout notre stack, pour toujours ». Dites ce qui a été révisé, pour quel produit, à quelle version, et que vous maintenez le dossier à mesure que la base de code évolue.

Si le dossier n'est pas prêt, donnez une date réaliste. Les achats préfèrent l'honnêteté à un instantané qui échoue à la revue parce que quelqu'un a fusionné cinq mises à jour de dépendances depuis que vous l'avez généré.

Commencez par le nom du produit et « divulgation de licences tierces » ou « conformité des licences open source ».
Indiquez la version, le tag ou la date que reflète l'inventaire.
Fournissez l'URL ou la pièce jointe demandée, à partir des mêmes données révisées.
Une phrase sur la maintenance : comment vous republiez quand les dépendances changent.
Proposez des exports si le questionnaire les exige, générés à partir du même instantané.

Erreurs courantes sous la pression des achats

Exporter une liste une fois et la réutiliser à chaque version. Présumer que personne n'a ajouté de paquets depuis le dernier appel d'offres. Envoyer un SBOM brut sans texte de licence révisé. Envoyer un PDF de trust center sur la sécurité qui ne liste jamais les licences tierces.

Affirmer que SOC 2 ou l'ISO 27001 couvre les obligations de licences open source (ce n'est généralement pas le cas). Traiter « nous utilisons de l'open source » comme une divulgation. Chacune de ces approches échoue quand l'acheteur compare votre réponse à ce qui est réellement livré, ou à ce qui a été livré deux sprints après votre réponse.

La solution est opérationnelle : inventaire à partir des éléments du build, révision humaine avant tout partage externe, mise à jour à chaque changement de dépendances. Pas un meilleur format de fichier.