Ce que cette analyse peut vous dire, et ce qu'elle ne peut pas

Elle répond à une seule question précise : cette URL publique montre-t-elle des signes évidents de divulgation de licences tierces, ou des lacunes évidentes ? Elle aide les équipes qui n'ont jamais audité leur site vitrine à trouver des liens manquants, des redirections vers la page d'accueil, ou des pages de licences vides.

Pour les éditeurs SaaS, le site vitrine est souvent le premier endroit que regardent les acheteurs avant de demander la véritable page de conformité des licences du produit livré.

• Réponses HTTP sur les chemins courants de licence et de mention (/license, /legal, /oss, etc.).
• Si ces pages contiennent un texte de licence ou de mention tierce plausible, et non des coquilles vides.
• Certaines URL de scripts tiers visibles dans le HTML de la page d'accueil.
• Des redirections évidentes qui renvoient les chemins de licence vers des pages sans rapport.
• Liens manquants : pas de pied de page de licence, pas de mention open source, pas d'URL de conformité dans le plan du site.

Elle ne peut pas voir ce qui n'est pas sur la page publique : la conformité des licences d'un produit livré se trouve dans les éléments du build (lockfiles, SBOM, lots de version), pas sur votre page d'accueil. Une analyse propre ne veut pas dire que votre application mobile, votre programme d'installation de bureau ou votre backend API sont documentés.

L'analyse ne lit pas les dépendances npm transitives, ne vérifie pas les identifiants SPDX, ne confirme pas le texte intégral de chaque composant, et ne sait pas si un humain a approuvé la publication. Cet écart est important : le rapport OSSRA 2025 de Black Duck indique que les dépendances transitives ont causé près de 30 % des conflits de licence qu'il a détectés, et aucun d'entre eux n'est visible depuis une page d'accueil. Elle ne peut pas remplacer une divulgation de licences tierces rattachée à ce que vous livrez.

• Les dépendances embarquées dans les produits iOS, Android, de bureau ou embarqués, absentes du web public.
• Les paquets transitifs jamais chargés dans le JavaScript exposé au navigateur.
• Si les licences listées correspondent à ce qui est réellement livré dans le produit examiné.
• L'état d'approbation de la révision et de la publication : verrous, validations, journal d'audit.
• La conformité copyleft : offres de code source, code source correspondant, déclencheurs de distribution.
• Les polices, SDK et icônes non référencés sur l'URL analysée.
• Les composants strictement internes ou les modèles de livraison isolés (air-gapped).

L'analyse est un aperçu qui détecte des lacunes visibles sur une seule URL publique ; une page de conformité des licences est le dossier opérationnel : inventaire révisé, texte intégral des licences, attribution, une URL stable pour les achats, et des exports alignés sur vos versions.

Les équipes passent une analyse de surface en ajoutant un lien en pied de page vers une page de mention superficielle. Elles passent la diligence grand compte en maintenant une documentation de conformité des licences par produit, mise à jour à chaque changement de dépendances.

Si l'analyse détecte des lacunes, voyez-y une invitation à agir, pas un échec. Construisez un inventaire à partir des lockfiles ou des SBOM de ce que vous livrez réellement. Révisez les licences. Publiez une divulgation maintenue, à partager dans le format que la diligence demande.

Si l'analyse semble propre, demandez-vous tout de même si la page visible couvre le produit sous contrat. Les pieds de page de licence du site vitrine et les pages de conformité des licences du produit sont souvent des artefacts différents. Les deux peuvent être nécessaires ; seule l'une des deux satisfait une demande de divulgation de licences tierces sur le produit livré.