Magazine LLM Opensource · 31 October 2026

Licences des LLM open-weight en 2026 : ce que « ouvert » autorise vraiment (Llama, DeepSeek, Qwen, GLM, Muse Spark, Kolibri)

En 2026, déployer un « modèle ouvert » est devenu un geste banal — et juridiquement piégeux. Entre les poids téléchargeables sous conditions, les licences Apache 2.0 trouées d’exceptions et les cadres de gestion du risque qui se cherchent encore, la différence entre « ouvert » et « propriétaire » tient souvent à une clause que personne n’a lue. Voici une grille pour s’y retrouver avant de fine-tuner, servir en API ou revendre.

Le mot « ouvert » ne veut plus rien dire — et c’est exactement le problème

Il existe aujourd’hui trois choses très différentes que tout le monde appelle « ouvert ». La première, le propriétaire, ne pose pas de problème de vocabulaire : on accède au modèle par une API, on ne télécharge rien, on ne modifie rien. La deuxième, l’open weights, consiste à publier les fichiers de poids, téléchargeables et exécutables localement — mais la licence qui les accompagne peut imposer des restrictions d’usage commercial, d’attribution ou sectorielles. La troisième, l’open source au sens strict, exige davantage : la disponibilité du code, des données d’entraînement (ou d’une description suffisante pour reproduire le modèle) et une licence sans restriction d’usage.

Le problème, c’est que très peu de grands LLM satisfont cette troisième définition. Comme le résume une analyse de DTS Conseil, la plupart des acteurs qui se disent « open source » publient en réalité des poids sous licence restrictive. Le cas de Kimi K3, lancé le 28 juillet 2026 par Moonshot AI, est emblématique : son rapport technique décrit l’architecture et les benchmarks, mais ne divulgue pas les corpus d’entraînement. On peut télécharger les poids, on ne peut pas reproduire le modèle — et c’est précisément ce que l’open source exige.

Cette distinction à trois niveaux — open-weights, open-source, open-data — est désormais largement documentée par l’écosystème technique francophone, qui rappelle que « open-weights signifie téléchargeable, pas open source » et que seuls quelques projets de recherche comme OLMo de l’Allen Institute for AI atteignent le niveau open-data, où poids, code et jeu de données d’entraînement sont tous accessibles (digital-m.fr). Pour le décideur, c’est la licence qui compte, bien plus que l’étiquette marketing.

Pourquoi cette confusion persiste-t-elle ? Parce qu’elle arrange beaucoup de monde. Pour un laboratoire, dire « open source » capte la sympathie de la communauté développeur, attire les contributions, facilite l’adoption en entreprise — tout en gardant la main sur les usages commerciaux, la redistribution et parfois la concurrence. Pour un acheteur, le mot « ouvert » suggère maîtrise, coût réduit, absence de lock-in. Entre les deux, il y a un vide juridique que les praticiens comblent à leurs risques.

Ce dossier part de cette confusion pour descendre dans le concret : ce que les licences de la vague actuelle autorisent réellement, comment un cadre de gestion du risque en six étapes tente de structurer le débat, et pourquoi les équipes qui migrent des API fermées vers des modèles ouverts se heurtent à des obstacles sous-estimés.

De l’Open Source Definition à l’OSAID : trente ans de malentendus

L’histoire commence en 1998, quand l’Open Source Initiative (OSI) formalise l’Open Source Definition : un logiciel est open source si sa licence permet l’usage libre, l’étude, la modification et la redistribution. Pendant vingt-cinq ans, cette grille fonctionne à peu près pour le logiciel classique. Elle se fracasse sur les modèles de langage.

En février 2023, Meta publie LLaMA 1 — d’abord sous licence de recherche, après une fuite des poids. Le geste inaugure une catégorie hybride : les poids circulent, mais la licence ne suit pas. Il faut attendre octobre 2024 pour que l’OSI publie l’Open Source AI Definition (OSAID) version 1.0, une tentative d’adapter les quatre libertés classiques aux modèles d’IA. La définition exige notamment l’accès aux données d’entraînement ou à une description suffisante pour reproduire le modèle, et une licence sans restriction d’usage. La Free Software Foundation critique le texte, jugé trop permissif sur la question des données et des libertés effectives.

Résultat : en 2026, presque aucun grand LLM ne satisfait l’OSAID. Llama 3.3 70B, par exemple, est explicitement classé comme non open source au sens strict de l’OSAID par ActuIA, malgré sa licence communautaire. Le flou n’est pas un accident : c’est un équilibre. Les laboratoires (Meta, Mistral, Alibaba, Z.ai) ont intérêt à publier des poids sans céder le contrôle ; les contre-pouvoirs (OSI, FSF, universités, régulateurs) tentent de clarifier, mais avec des moyens limités face à des acteurs qui pèsent des milliards.

Llama, DeepSeek, Qwen, GLM, Mistral, Gemma, Muse Spark, Kolibri : le décodage clause par clause

Entrons dans le texte. Ce qui suit distingue, pour chaque famille, cinq droits concrets : fine-tuner, redistribuer les poids, servir en API, distiller, et modifier la licence elle-même.

Llama (Meta). La Llama 3.3 Community License Agreement, qui couvre Llama 3.3 70B annoncé le 6 décembre 2024, autorise l’utilisation, la reproduction, la distribution, la création d’œuvres dérivées et les modifications. Mais elle impose trois contraintes : fournir une copie de l’accord avec toute distribution, afficher « Built with Llama » sur les produits dérivés, et — surtout — exiger une licence commerciale pour toute organisation dépassant 700 millions d’utilisateurs actifs mensuels. Ce seuil vise directement les hyperscalers. Pour une PME, il est inatteignable ; pour une grande plateforme, il change tout. La licence n’est donc pas open source : elle est source-available avec conditions.

Muse Spark Open (Meta). Le 15 octobre 2026, Meta a publié Muse Spark Open, présenté comme « le modèle open-weight américain le plus capable à ce jour », avec 816 milliards de paramètres totaux, 42 milliards actifs par token et un contexte d’un million de tokens, orienté codage et travail agentique (research.meta.ai, blockchain.news). C’est un signal fort : Meta continue d’occuper le terrain de l’open-weight haut de gamme. Attention toutefois — la communication de Meta parle d’« open-weight », pas d’open source, et les conditions exactes de la licence Muse Spark Open doivent être vérifiées avant tout déploiement commercial, comme pour toute la famille Llama. Le nom même du modèle (« Open ») ne préjuge pas du régime juridique.

DeepSeek. Les poids de DeepSeek-V3/R1 sont publiés sous licence MIT, l’une des plus permissives qui existent : fine-tuning, redistribution, usage commercial, tout est autorisé. C’est un choix rare et stratégiquement fort, qui a contribué à l’adoption massive de la famille. Attention toutefois : la licence MIT couvre les poids, pas nécessairement les conditions d’usage des sorties ou des services associés — un point à vérifier au cas par cas selon le canal de distribution.

Qwen (Alibaba). La plupart des tailles sont sous Apache 2.0, avec des exceptions selon les versions. Qwen 3 235B-A22B, classé n°1 des LLM open source en 2026 pour le raisonnement général et la programmation selon TECHSY, est distribué sous Apache 2.0 — ce qui en fait l’un des modèles les plus permissifs de sa catégorie. Apache 2.0 autorise tout, y compris la revente et la modification de la licence pour les dérivés.

GLM / Z.ai. Z.ai utilise une licence propre, avec des restrictions commerciales. GLM-5.3, modèle MoE de 753 milliards de paramètres lancé le 19 août 2026, s’impose en tête du benchmark CyberGym avec 84,5 %, devant Claude Sonnet 5 et GPT-5.6 Sol selon Aireiter. Les poids sont dits « différés » — un détail qui compte : la disponibilité n’est pas immédiate. La licence propre de Z.ai impose des conditions qu’il faut lire avant tout déploiement commercial.

Mistral. Modèle hybride : certains modèles sous Apache 2.0, d’autres sous licence de recherche. Il faut vérifier modèle par modèle, version par version.

Gemma (Google). Soumis aux Gemma Terms of Use, un texte distinct d’une licence open source classique, avec des clauses d’usage acceptable et des restrictions de redistribution.

Phi (Microsoft). Sous licence MIT, donc très permissive.

Kolibri (Aleph Alpha). Contre-exemple intéressant côté européen : Kolibri-1, publié le 3 octobre 2026, est un MoE de 78,1 milliards de paramètres (3,46 milliards actifs, soit ~4,4 % d’activation), sous Apache 2.0, avec un dépôt Hugging Face (Aleph-Alpha/Kolibri-1-BF16), des poids en BF16 et FP8, une fenêtre de contexte maximale de 1 048 576 tokens (recommandée en production autour de 262 144 tokens) et un focus allemand/anglais. C’est l’un des rares modèles frontière récents à conjuguer taille respectable et licence pleinement permissive — un argument de souveraineté européenne qui ne s’accompagne pas d’un piège contractuel.

Smaug (Abacus.AI). Abacus.AI a publié trois modèles open-weight Smaug pour les charges de travail agentiques, selon Unite.AI. La licence exacte n’est pas précisée dans les sources disponibles — un rappel que même les annonces récentes laissent parfois le juriste sur sa faim.

Nemotron 3.5 Transcribe (NVIDIA). Publié le 28 octobre 2026, ce modèle vocal open-weight de 30 milliards de paramètres (~4 milliards actifs) transcrit une quarantaine de langues, avec attribution des locuteurs et traduction, et s’accompagne d’un jeu de données audio de 463 062 heures (Granary v2). C’est un cas d’école de l’ambiguïté « open » : le modèle est bien open-weight, mais il ne fonctionne que sur des enregistrements, pas sur de l’audio en direct, et les conditions précises d’usage commercial doivent être vérifiées dans les termes NVIDIA (TechCrunch, The Next Web).

Famille	Licence	Fine-tuning	Redistribution	API commerciale	Distillation	Attribution
Llama 3.3	Community License	Oui	Oui (avec copie)	Oui (< 700 M MAU)	Selon conditions	« Built with Llama »
Muse Spark Open	Open-weight (conditions Meta à vérifier)	À vérifier	À vérifier	À vérifier	À vérifier	À vérifier
DeepSeek V3/R1	MIT	Oui	Oui	Oui	Oui	Non
Qwen 3	Apache 2.0	Oui	Oui	Oui	Oui	Non
GLM-5.3	Licence propre	À vérifier	Restreinte	Conditions	À vérifier	À vérifier
Mistral	Apache 2.0 / recherche	Variable	Variable	Variable	Variable	Variable
Gemma	Gemma Terms	Oui	Restreinte	Conditions	À vérifier	Oui
Phi	MIT	Oui	Oui	Oui	Oui	Non
Kolibri-1	Apache 2.0	Oui	Oui	Oui	Oui	Non
Nemotron 3.5 Transcribe	Open-weight (termes NVIDIA à vérifier)	À vérifier	À vérifier	À vérifier	À vérifier	À vérifier
Smaug	Non précisée	Non précisé	Non précisé	Non précisé	Non précisé	Non précisé

Ce que la licence change vraiment dans votre stack : fine-tuning, API, distillation, revente

Passons du texte juridique aux conséquences opérationnelles. Quatre scénarios reviennent constamment.

Fine-tuner un modèle sous licence restrictive et le déployer en SaaS. C’est le piège classique. Une équipe prend Llama 3.3, l’affine sur ses données propriétaires, déploie le résultat derrière un produit commercial. Rien dans la licence ne l’interdit a priori — sauf si l’organisation dépasse le seuil des 700 millions d’utilisateurs mensuels, ou si l’usage tombe dans les clauses d’usage acceptable. Mais l’obligation d’afficher « Built with Llama » s’applique, et la copie de licence doit suivre chaque distribution. Beaucoup d’équipes l’ignorent.

Redistribuer des poids dérivés. Un modèle affiné est une œuvre dérivée. Sa redistribution est autorisée par Llama, mais soumise aux mêmes obligations. Sous GLM ou Gemma, les restrictions peuvent être plus strictes. Sous Apache 2.0 (Qwen, Kolibri) ou MIT (DeepSeek, Phi), aucune question.

Distiller un modèle ouvert dans un modèle fermé — et l’inverse. La distillation consiste à entraîner un petit modèle sur les sorties d’un grand. Distiller les sorties d’un modèle sous licence restrictive pour créer un modèle concurrent peut violer les clauses d’usage acceptable, même si les poids sont téléchargeables. C’est un terrain juridique encore flou, mais les laboratoires commencent à le préciser dans leurs conditions.

Servir un modèle en API derrière un produit commercial. C’est là que les seuils et les clauses de non-concurrence mordent. Un modèle « ouvert » peut interdire la revente d’accès en tant que service, ou exiger une licence séparée au-delà d’un certain volume. La couche qui expose le modèle — le gateway — devient alors un point de contrôle contractuel autant que technique, comme le détaille notre dossier sur les LLM gateways en 2026.

Le point commun de ces pièges : ils ne sont pas techniques, ils sont contractuels. Et les équipes qui migrent des API fermées vers des modèles ouverts — un mouvement documenté par HackerNoon — les découvrent souvent trop tard, après avoir bâti une architecture sur un modèle dont la licence ne tient pas la charge.

Le cadre de gestion du risque en six étapes de Z.ai et Concordia AI : un début de grille

Face à ce maquis, une initiative mérite l’attention. Z.ai et Concordia AI ont proposé un cadre de gestion du risque des modèles open-weight en six étapes, rapporté par The Next Web. L’idée : structurer l’évaluation des risques liés à la publication et à l’usage de modèles ouverts, en couvrant l’audit, la conformité, l’usage acceptable et la traçabilité.

Ce que le cadre apporte : une séquence claire, utilisable comme checklist avant déploiement. Ce qu’il laisse de côté : la question des données d’entraînement (le point aveugle de l’OSAID), les seuils d’utilisateurs, et les clauses de non-concurrence propres à chaque licence. C’est un début, pas une solution. Mais pour un praticien, il fournit une trame : identifier le risque, l’évaluer, le documenter, le mitiger, le surveiller, le réviser. Appliqué à une licence, cela donne une méthode concrète — lire le texte, cartographier les droits accordés, vérifier les obligations, tester la conformité avant mise en production.

ZCode, DSpark, vLLM taïwanais : la rentrée 2026 en cas concrets

Trois cas de la rentrée 2026 montrent comment la licence influence l’adoption, l’infrastructure et la souveraineté.

ZCode. L’ouverture de ZCode par Z.ai a suscité une vérification immédiate des licences et des risques liés à l’usage commercial — un réflexe sain, mais qui illustre à quel point l’écosystème Z.ai reste dépendant d’une licence propre plutôt que d’une licence standard.

DSpark. Le cas DSpark rappelle que la disponibilité des poids n’est pas la disponibilité du droit : un modèle peut être téléchargeable sans que ses conditions d’usage commercial soient limpides.

vLLM et SGLang sur TPU. Le 20 octobre 2026, Google a annoncé les versions TPU de vLLM et SGLang, les deux moteurs d’inférence open source les plus utilisés pour servir des modèles ouverts (note.com). Ce n’est pas un sujet de licence au sens strict, mais c’est un changement d’infrastructure majeur : il élargit le choix matériel pour l’auto-hébergement de modèles open-weight, et donc la possibilité de rester maître de son déploiement. Le même jour, la pile d’inférence distribuée llm-d 1.0 a été présentée à la PyTorch Conference North America, avec une approche Kubernetes-native (Unite.AI). Pour les équipes qui servent des modèles sous Apache 2.0 ou MIT, ces briques réduisent le coût de la souveraineté technique — mais ne règlent rien au volet juridique.

Ce que la vague open-weight d’octobre 2026 change pour les licences

Le mois d’octobre 2026 a été dense, et il éclaire la question des licences sous un jour nouveau. Le 16 octobre, la vague open-weight a produit coup sur coup des modèles de 816, 560 et 120 milliards de paramètres — un rythme qui se heurte désormais à un mur de mémoire (the-agent-report.com). Muse Spark Open (816 Md, 42 Md actifs, contexte 1M) en est le symbole. Le 19 octobre, Inception a publié Mercury 3, un modèle à diffusion générant plus de 1 000 tokens par seconde avec un contexte d’un million de tokens (Unite.AI, mindstudio.ai). Le 21 octobre, une analyse détaillée en français en a expliqué les ressorts (ecclesieagazzi.com).

Pourquoi cela compte pour les licences ? Parce que la multiplication des modèles frontière open-weight — Meta, NVIDIA, Aleph Alpha, Inception — déplace le centre de gravité : les équipes ont désormais un choix réel entre plusieurs régimes juridiques pour un même niveau de capacité. Un modèle Apache 2.0 comme Kolibri-1 ou Qwen 3 permet de bâtir sans dépendance contractuelle ; un modèle sous licence propre comme GLM-5.3 impose un audit. La question n’est plus « quel est le meilleur modèle ? » mais « quel est le meilleur modèle que je peux légalement déployer dans mon contexte ? ». Et à mesure que les capacités se rejoignent, la licence devient un critère de sélection de premier rang.

Conclusion : trois réflexes avant de fine-tuner

Premier réflexe : lire la licence, pas le communiqué. « Open », « open-weight », « open source » ne sont pas interchangeables. Un modèle peut être téléchargeable et interdit à la revente en API.

Deuxième réflexe : cartographier les cinq droits — fine-tuner, redistribuer, servir en API, distiller, modifier la licence — pour chaque modèle candidat, et vérifier les seuils (700 M MAU chez Llama), les obligations d’attribution (« Built with Llama »), et les clauses d’usage acceptable.

Troisième réflexe : préférer une licence standard quand c’est possible. Apache 2.0 (Qwen, Kolibri) et MIT (DeepSeek, Phi) éliminent l’essentiel du risque juridique. Les licences propres (GLM, Gemma, Muse Spark) exigent un audit dédié — et parfois une négociation commerciale.

L’open-weight a gagné la production en 2026. Ce n’est plus le modèle qui bloque, c’est le contrat qui l’accompagne. Les équipes qui l’ont compris choisissent désormais leur modèle autant pour ses benchmarks que pour sa licence.

Sources

Article recherché et rédigé automatiquement · Magazine Electrosens

📬 Restez à la pointe

Recevez chaque semaine les nouveautés de ce magazine par email.

💬 Une remarque, une correction ?

Aidez-nous à améliorer cet article. Nous prenons en compte vos retours.

Open weights, open source, open flou : ce que la licence d’un modèle change vraiment pour votre stack