GitHub a annoncé le 16 octobre 2026 la disponibilité générale de son dispositif de conformité aux licences open source. L’objectif : repérer les dépendances dont la licence ne respecte pas la politique d’une organisation avant qu’une modification soit fusionnée dans son code. [1]
Une fonction réservée aux environnements éligibles
Cette disponibilité concerne GitHub Enterprise Cloud, y compris les environnements avec résidence des données, pour les dépôts disposant de GitHub Code Security. Il ne s’agit donc pas d’une fonction automatiquement accessible à tous les comptes GitHub. L’annonce mentionne également des améliorations de l’audit et des interfaces de programmation pour consulter ou mettre à jour les politiques. [1]
Du signalement au blocage des modifications
La documentation explique que les règles peuvent être définies à différents niveaux : entreprise, organisation ou dépôt. Elles s’appuient sur des identifiants de licences SPDX. Le contrôle porte sur les dépendances détectées, y compris les dépendances transitives : celles qu’un composant utilise lui-même, sans avoir été forcément ajouté directement par l’équipe. [2]
Le mode Active peut empêcher la fusion d’une demande de modification non conforme. Le mode Evaluate sert à observer les résultats sans appliquer ce blocage de conformité. Une nuance compte toutefois : si les protections de branche exigent la résolution des commentaires de revue, ces commentaires peuvent quand même empêcher la fusion, même en mode Evaluate. [2]
Les exceptions restent une décision explicite
Une alerte ne déclenche pas automatiquement une demande de dérogation. Le développeur peut remplacer ou retirer le composant, ou demander une exception à un responsable habilité. Cette séparation distingue le constat produit par l’outil et la décision de l’organisation. Elle évite de confondre « une dépendance a été détectée » avec « son utilisation a été autorisée ». [2]
Un contrôle utile, pas un certificat juridique
Le guide de conformité open source de FINOS rappelle une distinction importante : il faut identifier le logiciel, sa licence et la manière dont il est utilisé. Une même bibliothèque peut soulever des questions différentes selon son intégration ou sa distribution. L’étiquette « open source » ne signifie donc pas absence de conditions. [3]
Le contrôle automatique facilite le tri et la traçabilité, mais il ne remplace pas l’examen des obligations dans leur contexte. Lorsque les conditions sont complexes, FINOS souligne l’intérêt d’une expertise adaptée. Pour les équipes, cela invite à traiter les exceptions comme des décisions documentées, plutôt que comme un bouton permettant simplement de faire disparaître un avertissement. [3]
Enfin, cette annonce concerne les licences. Il ne faut pas la lire comme une garantie que les composants retenus sont exempts de failles, ni comme une certification juridique de l’ensemble d’un produit : ce sont des questions distinctes du respect d’une politique interne de licences.
Sources
[1] GitHub — Annonce de disponibilité générale, 16 octobre 2026. Consultée le 17 octobre 2026.
[2] GitHub Docs — Fonctionnement du contrôle des licences, documentation consultée le 17 octobre 2026.
[3] FINOS — Guide de conformité open source, section introductive sur les licences et les usages, consulté le 17 octobre 2026.
Crédit photographique
Photo d’illustration d’archive, sans lien avec cette version de GitHub : Tirza van Dijk, 17 janvier 2016, via Unsplash et Wikimedia Commons. Photo originale — CC0 1.0. Version redimensionnée à 1280 × 853 pixels, sans recadrage.
.jpg){kind=link}