Diligence M&A

Conformité des licences en M&A : ce dont les équipes de diligence ont vraiment besoin

Comment vendeurs et acheteurs évaluent le risque de licences tierces dans une opération, ce qu'un dump de lockfile n'est pas, et comment une page d'attestation révisée plus des exports satisfont la diligence sans improvisation de dernière minute.

Dernière mise à jour : 19 juillet 2026

Les fusions-acquisitions mettent le risque de licences tierces sous contrainte de temps. Les conseils, les équipes de diligence et les conseillers techniques doivent savoir quels composants open source et commerciaux sont livrés dans les produits de la cible, ce que chaque licence exige, et si le vendeur peut prouver que ce registre est à jour.

Ce guide est pratique, pas un conseil juridique. Il décrit à quoi ressemble une preuve opérationnelle "suffisante" dans une opération, les signaux d'alerte qui ralentissent la closing, et comment assembler un pack de diligence sans inventer un tableur ponctuel la semaine avant la signature.

Pourquoi les conseils M&A s'intéressent aux licences tierces

Le risque de licence est un risque de deal. Du copyleft non déclaré, une attribution manquante, ou une page publique qui ne correspond plus au build peuvent devenir des holdbacks, des décotes de prix, ou des programmes de remediation post-closing.

Les acheteurs demandent parce qu'ils héritent des produits livrés et des obligations qui les accompagnent. Les vendeurs qui maintiennent déjà un inventaire révisé répondent plus vite et avec moins de surprises.

Confirmez quels produits et quelles lignes de release sont dans le périmètre de l'opération.
Identifiez tôt le copyleft, le copyleft réseau et les conditions de SDK propriétaires.
Séparez les constats de sécurité de la divulgation des licences. La diligence a souvent besoin des deux, mais ce ne sont pas le même livrable.
Demandez si le registre est lié à ce qui est réellement livré, pas seulement à un scan du site marketing.

À quoi ressemble une preuve "suffisante"

Une preuve prête pour la diligence est un inventaire révisé pour chaque produit dans le périmètre, figé à une publication connue, avec le texte complet des licences et l'attribution lorsque c'est requis. Une page d'attestation destinée aux acheteurs plus des exports correspondants est la forme habituelle.

Un lockfile collé, un SBOM non révisé, ou un fichier NOTICE d'il y a trois ans est une entrée, pas une preuve. Une preuve signifie que quelqu'un a approuvé la représentation avant qu'elle ne quitte l'entreprise.

Inventaire limité au produit (direct et transitif selon votre politique).
Identifiants de licence révisés par un humain et texte complet joint.
Une URL stable ou un export généré à partir du même snapshot approuvé.
Une indication claire de la release ou de la date couverte par le registre.

Signaux d'alerte qui ralentissent les deals

La plupart des urgences partent des mêmes lacunes. Repérez-les avant que la demande de data room n'arrive.

Aucun n'implique que le deal échoue. Ils signifient que quelqu'un doit reconstruire un registre défendable sous pression de temps.

Composants GPL, LGPL ou AGPL non déclarés ou non résolus dans les builds livrés.
Fichiers NOTICE ou d'attribution obsolètes qui ne correspondent pas au lockfile actuel.
Un SBOM traité comme une divulgation terminée, sans texte de licence révisé.
Un seul tableur couvrant plusieurs produits sans périmètre par produit.
Pages publiques ou exports qui ne peuvent pas être rattachés à une approbation de publication.

Comment produire un pack de diligence

Construisez le pack à partir de la même boucle que vous devriez déjà exécuter pour les clients : importer ce qui est livré, le réviser, publier, puis exporter. N'inventez pas un processus parallèle réservé à la diligence la semaine de la signature.

Lorsque l'acheteur demande à la fois une URL et des fichiers, générez les deux à partir d'un même snapshot figé afin que la data room ne contienne pas de versions contradictoires.

Délimiter les produits
Listez chaque produit livré dans l'opération et la ligne de release couverte par la diligence.
Importer et réviser
Récupérez les lockfiles ou SBOM pour ces releases. Traitez les lignes à réviser avant tout partage.
Publier la page d'attestation
Figez un snapshot que les acheteurs peuvent rouvrir. Indiquez le produit et la date sur la page.
Exporter le pack
Joignez SPDX, CycloneDX, PDF ou NOTICE issus de la même publication lorsque le processus exige des fichiers.

Limites à énoncer clairement

Une page de conformité maintenue et des exports correspondants sont une infrastructure pour la diligence, pas un substitut au conseil juridique. Les licences à haut risque, les questions de distribution sortante et les indemnités spécifiques au deal nécessitent toujours une revue juridique.

SourceTrust aide les équipes à garder le registre opérationnel à jour, afin que les avocats débattent des quelques cas difficiles, pas d'un inventaire manquant.

Un SBOM suffit-il pour la diligence licences en M&A ?

En général, non à lui seul. Un SBOM identifie des composants. La diligence a encore besoin de licences révisées, du texte complet et d'un périmètre produit clair. Traitez le SBOM comme l'import, puis terminez la révision et la publication avant de partager.

Que doivent préparer les vendeurs avant un process letter ?

Par produit : un inventaire révisé à jour, une URL d'attestation ou une divulgation équivalente, et des exports issus du même snapshot. Savoir quelle release chaque fichier couvre fait gagner des jours lorsque la data room s'ouvre.

Que doivent demander les acheteurs dans la première liste de demandes ?

Demandez une preuve limitée au produit, liée aux builds de l'opération : une page maintenue ou un pack de divulgation, des fichiers SPDX ou CycloneDX correspondants si requis, et la confirmation que les lignes copyleft ont été révisées. Évitez d'accepter un seul tableur non daté comme complet.