Frontend web
Application web exécutée dans le navigateur : JavaScript, TypeScript compilé, WebAssembly, feuilles de style, polices, icônes.
Ce qui se passe réellement
| Question | Réponse |
|---|---|
| Un tiers reçoit-il le logiciel sous forme exécutable ? | Oui — le navigateur télécharge et exécute le code |
| Un tiers interagit-il avec lui par un réseau ? | Oui, mais c’est secondaire ici |
| Le composant est-il lié à votre code ? | Oui, statiquement, dans un seul fichier |
Le point que presque tout le monde manque. Un frontend web distribue du code source à chaque visiteur. Ce n’est pas un service : c’est une livraison de logiciel, à des milliers de destinataires anonymes, plusieurs fois par jour.
Une équipe qui se dit « vous faites du SaaS, la GPL ne vous concerne pas » a raison pour son backend et tort pour son frontend. C’est le même produit, mais deux régimes opposés.
Le verdict par famille
| Famille | Verdict | Raison |
|---|---|---|
| Permissive | ◐ | Autorisée, mais l’attribution survit mal au bundling : voir ci-dessous |
| Copyleft faible fichier (MPL, EPL) | ◐ | Réciprocité par fichier, mais le bundle dissout la notion de fichier |
| Copyleft faible bibliothèque (LGPL) | ○ | La liaison dynamique n’existe pas dans un bundle : traiter comme du copyleft fort |
| Copyleft fort (GPL) | ✕ | Distribution avérée : le source de l’œuvre combinée est dû à chaque visiteur |
| Copyleft réseau (AGPL) | ✕ | Cumul distribution + réseau |
| Source-available | ✕ | Le code est de toute façon livré au client, ce que ces licences n’anticipent pas |
| Contenu non commercial (CC-BY-NC) | ✕ | Fréquent sur les icônes et illustrations, et interdit dans un produit vendu |
Pourquoi le bundler aggrave tout
Dans une application native, la question de l’œuvre combinée se discute : liaison dynamique ? processus séparé ? interface stable ? Dans un frontend, la discussion n’a pas lieu.
Le bundler prend votre code et celui des dépendances, applique un tree-shaking, renomme les symboles, inline les fonctions, et produit un seul fichier. Il n’y a plus de frontière observable entre votre code et le composant tiers.
Conséquences :
- l’argument « vous ne faites que lier dynamiquement » est indisponible ;
- l’argument « ce sont des programmes séparés » est indisponible ;
- un composant GPL dans le graphe de dépendances contamine, en pratique, l’artefact livré.
La seule parade architecturale est l’isolement réel : charger le composant depuis une
origine distincte, dans un iframe ou un worker séparé, sans partage de code. C’est lourd,
et cela ne se décide pas après coup.
L’attribution, problème n° 1 des permissives
Les licences permissives exigent de conserver les mentions de copyright et de licence. La minification les supprime toutes.
Ce qu’il faut mettre en place :
| Mesure | Effet |
|---|---|
| Préservation des bannières de licence par le bundler | Conserve les blocs /*! … */ marqués comme à préserver |
Génération d’un fichier licenses.txt à la construction |
Depuis le SBOM, avec le texte complet des licences |
| Lien accessible depuis l’application | Pied de page, page « Mentions légales », « À propos » |
| Contrôle bloquant en CI | Échec de la construction si le fichier d’attributions n’est pas généré |
Sans ces quatre mesures, un frontend moderne est en violation de dizaines de licences permissives simultanément. C’est le manquement le plus répandu du domaine, et le plus simple à corriger.
Les pièges propres au frontend
Les cartes de source. Publier les source maps en production expose votre code source, et révèle du même coup la composition exacte du bundle. C’est souvent ainsi qu’une violation est constatée par un tiers.
Les polices. OFL-1.1 autorise la redistribution mais comporte une clause de nom
réservé : une police modifiée — sous-ensemble de glyphes, conversion de format,
renommage — ne peut pas conserver son nom d’origine. Le sous-ensemblage de police, pratique
courante d’optimisation, est une modification.
Les icônes et illustrations. C’est là que se trouvent les vrais problèmes.
CC-BY-NC interdit l’usage commercial ; CC-BY-SA impose le partage à l’identique de l’œuvre
dérivée ; CC-BY-ND interdit le recadrage et la recoloration. Un jeu d’icônes récupéré sans
vérification est un risque bien plus immédiat qu’une bibliothèque JavaScript.
Les dépendances de développement embarquées par erreur. Un composant destiné aux tests qui se retrouve dans le bundle de production entre dans le périmètre distribué.
Les scripts tiers chargés depuis un CDN. Ils ne sont pas distribués par vous — mais ils introduisent une dépendance externe qui pose d’autres questions, de sécurité cette fois.
WebAssembly. Un module compilé depuis du C ou du Rust emporte les licences de ses dépendances natives, invisibles dans le graphe des paquets JavaScript. Le SBOM du frontend doit couvrir la chaîne de compilation WebAssembly.
Ce que le CRA ajoute
Le frontend fait partie du produit. Ses composants doivent figurer au SBOM, au même titre que ceux du backend — et c’est rarement le cas dans les dispositifs que l’on rencontre, où l’inventaire s’arrête souvent aux dépendances serveur.
Les exigences de l’annexe I s’y appliquent aussi : minimisation des données, protection de l’intégrité, absence de vulnérabilité exploitable connue. Une dépendance JavaScript vulnérable livrée au navigateur est une vulnérabilité du produit.