GitHub généralise la conformité des licences par règles et bloque le merge des dépendances non conformes
Le 16 octobre 2026, GitHub rend disponible en version générale la conformité des licences open source : un ruleset exige des résultats conformes avant le merge et bloque toute pull request qui ajoute une dépendance sous licence non acceptable. Pour les entreprises qui gouvernent déjà leurs dépendances, c’est le passage de l’audit a posteriori à la politique appliquée dans la CI.
16 octobre 2026. GitHub rend disponible en version générale la conformité des licences open source, après une preview publique ouverte en juin. Une condition de merge. C’est le cœur du mécanisme : un ruleset peut désormais exiger des « résultats de conformité des licences avant le merge ». Un rôle dédié. GitHub introduit au passage le rôle prédéfini Enterprise Open-Source License Manager. Pourquoi c’est important : la conformité des licences cesse d’être un audit que l’on fait après coup — elle devient une politique d’entreprise qui bloque le merge, dans la CI, au même titre qu’un check de code scanning.
Le mécanisme : un ruleset qui bloque le merge
La fonctionnalité s’appuie sur un socle qui existait déjà, la dependency review action, mais l’étend d’un cran : elle introduit une politique de licences à l’échelle de l’entreprise. On active cette politique en ciblant des dépôts avec un ruleset qui utilise une nouvelle condition, « Require license compliance results before merging » — la même logique que les conditions de code scanning existantes.
Le déroulement est simple. Quand un développeur ouvre une pull request qui ajoute ou modifie des dépendances, les contrôles de licence vérifient automatiquement que chaque dépendance nouvelle ou modifiée porte une licence acceptable. Si ce n’est pas le cas, la pull request est annotée d’un message pour chaque dépendance non conforme, et le merge est bloqué.
Trois issues s’offrent alors au développeur : retirer ou remplacer la dépendance, modifier la politique de licences, ou créer une exception de paquet. C’est exactement la bonne granularité : on ne bloque pas pour bloquer, on force une décision explicite et tracée. Soit le code change, soit la politique change, soit quelqu’un assume une exception — mais rien ne passe en silence.
Le détail qui compte est que le blocage vit dans le ruleset, donc dans la configuration versionnée et gouvernée, pas dans un script maison qu’un seul ingénieur connaît. La politique de licences devient un artefact d’entreprise, au même niveau que les règles de protection de branche.
Un rôle dédié : Enterprise Open-Source License Manager
La conformité des licences n’est pas seulement un garde-fou technique, c’est une décision de gouvernance — et GitHub lui donne enfin un acteur. Le nouveau rôle prédéfini Enterprise Open-Source License Manager se délègue à des individus ou à des équipes chargés de relire et d’approuver les demandes de clôture : les exceptions de paquets, les modifications de politique, les litiges de licence.
Les gestionnaires de politique reçoivent des notifications par e-mail sur les demandes en attente et les traitent depuis la console d’entreprise. C’est un vrai changement de posture par rapport à l’époque où la conformité des licences se réglait par un tableur partagé et une réunion trimestrielle. Ici, la décision est tracée, datée et rattachée à un responsable, et elle s’applique immédiatement à l’ensemble des dépôts concernés.
Pour une entreprise soumise à des obligations de conformité — la Cyber Resilience Act européenne en tête, qui impose une traçabilité de la SBOM — ce rôle transforme une obligation diffuse en processus nommé. On sait qui a autorisé quoi, quand, et pourquoi.
Ce qui est nouveau depuis la preview de juin
La version générale ne se contente pas de retirer l’étiquette « preview ». Quatre améliorations méritent d’être relevées, parce qu’elles changent la portée de l’outil.
D’abord, les informations de licence sont désormais disponibles pour les clients GitHub Enterprise Cloud avec résidence des données. Non seulement la fonctionnalité de conformité s’active chez eux, mais le graphe de dépendances et les exports SBOM se remplissent de données de licence — un prérequis pour les organisations qui ne peuvent pas héberger leurs métadonnées hors d’une région donnée.
Ensuite, les changements de politique de licences émettent des événements d’audit log, intégrables dans les systèmes d’enregistrement externes. La politique n’est plus une boîte noire : chaque modification laisse une trace que le SIEM ou l’outil de conformité peut consommer.
Enfin, deux endpoints API complètent le dispositif. Les premiers permettent de télécharger, mettre à jour et remplacer la politique de licences de l’entreprise par programmation. Le dernier — et le plus prospectif — vérifie si un paquet est conforme à la politique. Ce dernier endpoint est explicitement pensé pour que les agents de codage évitent de recommander ou d’incorporer des paquets qui violent la politique de licences de l’organisation.
La portée exacte, et ce qui reste dehors
Bornons la fonctionnalité. La conformité des licences est disponible pour les clients GitHub Enterprise Cloud, y compris avec résidence des données, et exige que GitHub Code Security soit activé sur les dépôts concernés. Ce n’est pas une fonctionnalité grand public : elle vise les organisations qui ont déjà un règlement de licences à faire respecter, pas le développeur individuel.
Il faut aussi comprendre ce que l’outil ne fait pas. Il détecte les licences et bloque les non-conformités, mais il ne résout pas les conflits de licence — déterminer si une GPLv3 et une Apache 2.0 sont compatibles dans un même binaire reste un travail d’analyse humaine. Il ne remplace pas non plus un conseil juridique : la politique d’entreprise encode des décisions prises en amont, elle ne les fabrique pas.
Autre limite pratique : la qualité de la détection dépend de la précision des métadonnées de licence dans le graphe de dépendances. Un paquet dont la licence est mal déclarée ou absente du registre peut passer entre les mailles, ou au contraire déclencher un faux blocage qu’il faudra traiter par une exception. La conformité automatisée vaut ce que vaut le graphe qui l’alimente.
Un cas concret : la GPL dans une politique « MIT only »
Prenons un exemple pour fixer les idées. Une entreprise édite un service en licence propriétaire et a codé sa politique sur une règle simple : aucune dépendance copyleft. Un développeur ajoute une bibliothèque sous GPLv3 pour résoudre un problème d’horodatage. Dès l’ouverture de la pull request, le ruleset déclenche le contrôle de licence, détecte la GPLv3 et bloque le merge, en annotant la pull request d’un message qui pointe la dépendance fautive.
Le développeur a alors trois options concrètes : remplacer la bibliothèque par une alternative sous MIT ou Apache 2.0, demander une exception de paquet au License Manager — qui devra la justifier et l’approuver depuis la console — ou modifier la politique si la GPLv3 est en réalité acceptable dans ce contexte précis. Dans tous les cas, la décision est tracée dans l’audit log, et l’incident ne se redécouvre pas six mois plus tard lors d’un audit de conformité.
C’est ce scénario qui sépare la conformité « par politique » de la conformité « par vigilance » : la vigilance oublie, la politique bloque.
Verdict
Si votre entreprise gère des dépendances sous GitHub Enterprise Cloud et a une politique de licences explicite, activez la conformité par rulesets dès maintenant : le coût de mise en place est une condition de merge, et le bénéfice est un blocage systématique que personne ne contourne par oubli. Si vous êtes soumis à la Cyber Resilience Act ou à une traçabilité SBOM, la combinaison graphe de dépendances + exports SBOM + audit log couvre une part réelle de vos obligations, sans pipeline maison. Si vous déployez des agents de codage, branchez-les sur l’endpoint de vérification de conformité : c’est la façon la plus propre d’empêcher un agent de proposer un paquet sous licence incompatible. La conformité des licences ne devient pas triviale le 16 octobre — elle devient exécutable, et c’est précisément ce qui lui manquait pour sortir du tableur.