GitHub généralise la conformité des licences open source dans les pull requests

Après une préversion publique ouverte en juin 2026, GitHub a annoncé le 16 octobre la disponibilité générale de la conformité des licences open source, réservée aux clients GitHub Enterprise Cloud disposant de GitHub Code Security. La fonctionnalité permet de définir une politique de licences à l’échelle de l’entreprise et de l’appliquer automatiquement sur chaque pull request qui ajoute ou modifie une dépendance.

#Le principe : une politique de licences appliquée au moment du merge

Une politique de licences définit quelles licences open source sont autorisées, lesquelles sont interdites, et lesquelles nécessitent une validation au cas par cas. Dès qu’une pull request introduit une dépendance non conforme, GitHub ajoute une annotation sur la pull request. Rien de nouveau dans le principe, mais la disponibilité générale ouvre la possibilité de rendre ce contrôle bloquant.

#Un nouveau type de condition dans les rulesets

La politique s’active via un repository ruleset, sur le même modèle que les conditions de code scanning déjà disponibles. Une organisation peut donc exiger que le contrôle de conformité des licences passe avant toute fusion, au même titre qu’elle exigerait une revue de code ou une suite de tests verte.

#Résoudre une annotation : trois chemins possibles

Quand une dépendance est signalée non conforme, une équipe dispose de trois options : retirer ou remplacer la dépendance, faire modifier la politique de licences par la personne habilitée, ou créer une exception ciblée sur ce paquet précis. Le nouveau rôle « Enterprise Open-Source License Manager » centralise justement l’examen de ces demandes d’exception, avec notification par e-mail et traitement depuis la console d’entreprise — un flux qui vient s’ajouter aux outils en ligne de commande que les équipes utilisent déjà pour auditer leurs dépendances.

# Vérifier la conformité d'un paquet via l'API REST du graphe de dépendances
gh api \
  -H "Accept: application/vnd.github+json" \
  /enterprises/ORG/dependency-graph/license-policy/check \
  -f ecosystem=npm \
  -f name=some-package \
  -f version=2.4.1

La politique de licences agit désormais comme n’importe quelle autre condition de ruleset : elle peut empêcher la fusion d’une pull request, au même titre qu’une vérification de code scanning ou une revue obligatoire.

GitHub met en avant un usage qui dépasse la seule gouvernance humaine : les nouveaux points de terminaison d’API permettent à des agents de codage automatisés de vérifier la conformité d’un paquet avant de l’ajouter à un projet. Une organisation qui structure déjà sa chaîne de déploiement autour de règles automatisées, par exemple via un pipeline d’auto-hébergement standardisé, trouve ici un levier supplémentaire pour fermer la boucle entre sécurité, conformité et vitesse de livraison.

#Ce que ça change pour les équipes qui gèrent beaucoup de dépendances

Pour une organisation qui gère des dizaines de dépôts, la différence avec la préversion tient surtout à l’automatisation de la gouvernance : audit log, rôle dédié, API pour les agents. Ce coût de suivi à l’échelle explique le positionnement sur l’offre Enterprise Cloud plutôt que sur les dépôts individuels.

#Ce qu’il faut retenir

La conformité des licences open source devient un contrôle de fusion à part entière chez GitHub, au même niveau que le code scanning. L’apport principal de la disponibilité générale tient à l’outillage de gouvernance : rôle dédié, audit log, API exploitable par des agents. La fonctionnalité reste cependant cantonnée à GitHub Enterprise Cloud, ce qui laisse les dépôts individuels et les petites équipes sans équivalent natif.

Pour aller plus loin : l’annonce officielle sur le GitHub Changelog.