Comment auditer la licence open source de vos dépendances en 7 étapes : guide complet pour les développeurs en 2026

Un projet Node.js moyen embarque entre 300 et 1 500 dépendances transitives. Chacune porte une licence — MIT, Apache 2.0, GPL, BSD, ISC, ou parfois des licences exotiques qui cachent des obligations légales lourdes. En 2026, avec l'entrée en application du Cyber Resilience Act européen et les débats sur le CLARITY Act américain, ignorer les licences de vos dépendances n'est plus une négligence — c'est un risque juridique mesurable. Que vous soyez développeur freelance à Paris, CTO d'une startup à Lyon, ou lead dev dans une ESN à Toulouse, ce guide vous donne les 7 étapes pour un audit complet, reproductible et automatisé.

Étape 1 : Inventorier toutes vos dépendances directes et transitives

La première erreur commise par la plupart des équipes est de ne vérifier que les dépendances directes — celles déclarées explicitement dans package.json, requirements.txt ou pom.xml. Or, chaque dépendance directe entraîne des dizaines de dépendances transitives, chacune avec sa propre licence. Un projet React typique avec 20 dépendances directes peut facilement atteindre 800 dépendances transitives.

Pour obtenir l'arbre complet de vos dépendances, utilisez les commandes natives de votre gestionnaire de paquets :

# Node.js / npm
npm ls --all --json > deps-tree.json

# Python / pip
pip install pipdeptree
pipdeptree --json > deps-tree.json

# Java / Maven
mvn dependency:tree -DoutputType=dot

# Go
go mod graph

Le résultat est un arbre de dépendances complet. Notez le nombre total — il sera votre référence pour vérifier que l'audit de licences couvre bien 100% des composants. Une équipe à Nantes avec laquelle nous avons travaillé a découvert que leur projet Next.js de 45 dépendances directes embarquait en réalité 1 247 dépendances transitives — dont 3 sous licence AGPL qu'ils n'avaient jamais repérées.

Étape 2 : Identifier les licences avec license-checker et ScanCode

Une fois l'inventaire des dépendances établi, il faut identifier la licence de chacune. Les métadonnées des paquets (champ license dans package.json) ne sont pas toujours fiables : certains paquets déclarent « MIT » dans leurs métadonnées mais incluent un fichier LICENSE contenant une licence différente.

license-checker est l'outil de référence pour l'écosystème Node.js. Il lit les métadonnées et les fichiers LICENSE de chaque dépendance :

# Installation
npm install -g license-checker

# Audit complet avec export CSV
license-checker --csv --out licenses-report.csv

# Audit avec filtre sur les licences problématiques
license-checker --failOn "GPL-2.0;GPL-3.0;AGPL-3.0"

# Format JSON pour traitement automatisé
license-checker --json --production > licenses.json

Pour une analyse plus approfondie qui va au-delà des métadonnées et scanne le contenu réel des fichiers, utilisez ScanCode Toolkit de nexB :

# Installation
pip install scancode-toolkit

# Scan complet d'un projet
scancode --license --copyright --json-pp scan-results.json ./node_modules/

# Scan ciblé sur les fichiers LICENSE uniquement
scancode --license --only-findings --json scan-licenses.json \
  --include "LICENSE*" --include "COPYING*" ./node_modules/

À Bordeaux, une startup fintech a découvert grâce à ScanCode que 4 de leurs dépendances déclaraient « MIT » dans package.json mais contenaient en réalité des fichiers LICENSE sous BSD-3-Clause avec clause publicitaire, imposant la mention du nom de l'auteur dans tout matériel publicitaire.

Étape 3 : Comprendre la matrice de compatibilité des licences

La compatibilité des licences est le cœur de l'audit. Deux licences sont « compatibles » lorsqu'un logiciel peut légalement combiner du code distribué sous l'une et l'autre. Le piège classique : la GPL est « virale » — tout code combiné avec du code GPL doit être distribué sous GPL. Si votre projet est propriétaire, une seule dépendance GPL peut vous obliger à ouvrir l'intégralité de votre code source.

Cette matrice est votre référence principale. Les cellules rouges sont des showstoppers : si votre projet est propriétaire et qu'une seule dépendance transitive est sous GPL ou AGPL, vous avez un problème juridique immédiat. Les cellules jaunes (LGPL) nécessitent une architecture spécifique (linkage dynamique) pour rester conformes.

Étape 4 : Détecter les licences à risque et les obligations cachées

Au-delà de la compatibilité, certaines licences imposent des obligations que la plupart des développeurs ignorent. Voici les principales à surveiller :

• AGPL 3.0 : même si votre logiciel fonctionne côté serveur sans distribution, vous devez fournir le code source à quiconque interagit avec le service via un réseau. C'est la licence la plus contraignante pour les applications SaaS.
• SSPL (Server Side Public License) : utilisée par MongoDB. Impose de publier le code source de tout le système offrant le service, pas seulement le composant sous SSPL. L'OSI ne la reconnaît pas comme open source.
• BSL (Business Source License) : utilisée par HashiCorp (Terraform, Vault). Gratuite pour un usage non productif, payante en production. Vérifiez les conditions de conversion vers open source.
• EUPL 1.2 : la licence de la Commission européenne. Compatible avec GPL mais méconnue — vérifiez les obligations de traduction dans votre langue officielle.
• Licences « custom » : certains projets utilisent des licences rédigées sur mesure. Signal d'alarme immédiat : faites analyser par un juriste.

Une équipe à Toulouse a découvert lors d'un audit que leur pile de monitoring utilisait trois niveaux de licences imbriquées : leur propre code (MIT) dépendait d'une librairie (Apache 2.0) qui dépendait elle-même d'un module de métriques sous SSPL. La SSPL au troisième niveau les obligeait potentiellement à publier l'intégralité de leur infrastructure de monitoring.

Étape 5 : Générer un SBOM avec les identifiants SPDX

Un SBOM (Software Bill of Materials) est l'équivalent logiciel d'une liste d'ingrédients. Il recense tous les composants de votre application, leurs versions, leurs licences (au format SPDX) et leurs dépendances. En 2026, le SBOM est devenu une exigence réglementaire en Europe (Cyber Resilience Act) et aux États-Unis (Executive Order 14028).

Syft (Anchore) et Trivy (Aqua Security) sont les deux outils de référence pour générer des SBOM :

# Syft — génération SBOM au format SPDX
syft . -o spdx-json > sbom-spdx.json

# Syft — format CycloneDX
syft . -o cyclonedx-json > sbom-cyclonedx.json

# Trivy — SBOM avec scan de vulnérabilités intégré
trivy fs --format spdx-json --output sbom.json .

# Vérifier que toutes les licences ont un identifiant SPDX valide
cat sbom-spdx.json | jq '.packages[] | select(.licenseConcluded == "NOASSERTION")'

Le format SPDX normalise les noms de licences. Plus de confusion entre « MIT License », « MIT », « The MIT License (MIT) » — l'identifiant unique est MIT. Vérifiez que chaque composant de votre SBOM a un identifiant SPDX valide. Les composants marqués NOASSERTION nécessitent une investigation manuelle.

Étape 6 : Établir une politique de licences acceptées

L'audit ponctuel ne suffit pas. Vous devez définir une politique de licences qui liste explicitement les licences autorisées, celles soumises à approbation, et celles interdites. Cette politique doit être documentée, partagée avec l'équipe, et appliquée automatiquement.

Voici un modèle de politique applicable à la plupart des projets commerciaux à Paris, Lyon, Nantes ou Bordeaux :

# .license-policy.yml — Politique de licences
allowed:
  - MIT
  - ISC
  - BSD-2-Clause
  - BSD-3-Clause
  - Apache-2.0
  - 0BSD
  - Unlicense
  - CC0-1.0
  - CC-BY-4.0
  - Python-2.0
  - BlueOak-1.0.0

review_required:
  - LGPL-2.1-only
  - LGPL-3.0-only
  - MPL-2.0
  - EUPL-1.2
  - CPAL-1.0

forbidden:
  - GPL-2.0-only
  - GPL-3.0-only
  - AGPL-3.0-only
  - SSPL-1.0
  - BSL-1.1
  - CC-BY-NC-4.0
  - CC-BY-NC-SA-4.0

Les licences dans review_required ne sont pas interdites mais nécessitent une approbation explicite. Par exemple, la LGPL est acceptable si vous utilisez la librairie en linkage dynamique, mais pas en intégration statique. La MPL 2.0 est acceptable si vous ne modifiez pas les fichiers couverts.

Étape 7 : Automatiser l'audit en CI/CD

L'audit de licences doit s'exécuter automatiquement à chaque pull request et à chaque build. Voici une configuration GitHub Actions complète :

# .github/workflows/license-audit.yml
name: License Audit
on:
  pull_request:
    paths:
      - 'package.json'
      - 'package-lock.json'
      - 'requirements.txt'
      - 'go.mod'

jobs:
  license-check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '22'

      - name: Install dependencies
        run: npm ci

      - name: Check licenses
        run: |
          npx license-checker \
            --failOn "GPL-2.0;GPL-3.0;AGPL-3.0;SSPL-1.0" \
            --excludePrivatePackages \
            --production

      - name: Generate SBOM
        run: |
          curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s
          ./bin/syft . -o spdx-json > sbom.json

      - name: Upload SBOM
        uses: actions/upload-artifact@v4
        with:
          name: sbom
          path: sbom.json

Cette configuration bloque toute PR qui introduit une dépendance sous licence interdite. Le SBOM généré est archivé comme artefact de build, ce qui vous donne une traçabilité complète pour chaque release.

Pour aller plus loin dans la sécurisation de votre pipeline, consultez notre guide Comment sécuriser vos dépendances npm contre les attaques supply chain et notre article sur l'audit des dépendances face aux attaques supply chain.

Workflow d'audit complet : de l'inventaire à l'automatisation

Questions fréquentes

Pour aller plus loin

• Comment sécuriser vos dépendances npm contre les attaques supply chain en 7 étapes — complément indispensable à l'audit de licences pour une sécurité complète de votre chaîne de dépendances.
• Comment auditer vos dépendances open source contre les attaques supply chain en 7 étapes — focus sur la sécurité technique (CVE, malware, typosquatting) plutôt que juridique.
• a16z CLARITY Act : la responsabilité développeur qualifiée de « kill shot » — pourquoi l'audit de licences est devenu une urgence réglementaire en 2026.

Sebastian

Juriste spécialisée en propriété intellectuelle et licences open source. Accompagne les startups et PME françaises dans la mise en conformité de leurs projets logiciels. Intervenante à Paris Open Source Summit et contributrice aux travaux de l'Open Source Initiative sur les licences européennes.