LLM auto hébergées · 7 November 2026Open weights, open source, open data : ce que « open » veut vraiment dire pour votre LLM local en 2026
En 2026, le mot « open » est devenu un champ de bataille. Entre les annonces triomphales de Meta, Alibaba et DeepSeek, l’entrée en vigueur des obligations de transparence de l’EU AI Act et la publication de la définition Open Source AI (OSAID 1.0) par l’OSI, la confusion est totale. Ce dossier dissèque ce que les géants appellent « open » et ce que la loi, la communauté et les faits appellent réellement « open source », pour trancher une fois pour toutes ce que vous pouvez vraiment faire avec un LLM chez vous.
L’étiquette « open » ne veut plus rien dire
Il y a encore trois ans, la question semblait simple : un modèle était soit open source, soit propriétaire. En 2026, cette dichotomie a volé en éclats. Meta annonce « Llama 4 open source », Alibaba vend Qwen comme « open », DeepSeek clame son « open-weight » R1, et Moonshot AI a publié en juillet 2026 les poids de Kimi K3, présenté comme « le plus gros modèle IA ouvert au monde ». Pourtant, aucun de ces modèles ne satisfait à la définition stricte de l’open source telle que l’entend l’Open Source Initiative (OSI).
Le problème n’est pas nouveau, mais il a pris une ampleur inédite. En octobre 2024, l’OSI a publié la version 1.0 de l’Open Source AI Definition (OSAID), un référentiel qui exige bien plus que la simple mise à disposition des poids. Pour être qualifié d’« open source », un modèle doit fournir l’accès aux poids, au code d’entraînement et aux données d’entraînement. Or, la grande majorité des modèles populaires — Llama, Qwen, DeepSeek, Mistral, Gemma — ne publient que les poids, sous forme de fichiers .safetensors, tout en gardant secrets le code d’entraînement et les datasets.
Cette situation crée un fossé juridique et pratique béant. D’un côté, les entreprises et les bricoleurs téléchargent des modèles qu’ils croient « open source » et les intègrent dans des produits commerciaux. De l’autre, les licences qui accompagnent ces poids contiennent des clauses restrictives — seuils d’utilisateurs mensuels, interdictions de redistribution, exclusions géographiques — qui transforment ce qui semble être un cadeau en piège juridique. Et avec l’entrée en vigueur progressive des obligations de transparence de l’EU AI Act pour les modèles d’IA à usage général (GPAI), la distinction n’est plus seulement une question de pureté idéologique : c’est devenu un enjeu de conformité réglementaire.
Cette confusion n’est plus un débat de puristes. En septembre 2026, la question est montée jusqu’aux conseils d’administration : comme le résume Forbes dans une analyse du 11 septembre 2026, « open weights are not open source, and it matters now in the boardroom ». Autrement dit : ce qui passait pour une querelle sémantique entre développeurs est devenu un risque juridique et financier que les directions générales ne peuvent plus ignorer. Un modèle « open weights » que vous déployez en production n’offre ni les garanties de reproductibilité, ni la traçabilité des données, ni la liberté contractuelle d’un vrai logiciel open source.
Poids ouverts, code fermé : la nouvelle taxonomie de l’IA
Pour comprendre le paysage de 2026, il faut adopter une grille de lecture à trois niveaux, devenue le standard technique de l’écosystème — et que QuelLLM.fr a synthétisée le 27 août 2026 sous la forme d’une question simple : « poids ouverts, code ouvert, données ouvertes — ce que ces termes veulent dire et pourquoi presque aucun LLM n’est vraiment open-source ». La même grille est reprise et vulgarisée par Digital-m.fr dans son dossier « LLM open-weights : Llama, Mistral, Qwen et le vrai sens du mot open source », mis à jour le 16 juin 2026, qui martèle la formule clé : « open-weights signifie "téléchargeable", pas "open source" ».

Les modèles open-weights — c’est la catégorie la plus répandue. Llama 4 (sorti le 5 avril 2025), Qwen 3, DeepSeek R1/V3, Mistral, gpt-oss-120b et gpt-oss-20b (publiés le 5 août 2025) : tous permettent de télécharger les poids du modèle et de les exécuter sur sa propre infrastructure. Mais c’est à peu près tout. Le code d’entraînement reste secret, les données d’entraînement sont opaques, et la licence qui accompagne les poids impose des conditions d’utilisation spécifiques. C’est le modèle dominant, porté par des acteurs qui y voient un levier commercial et stratégique.
Les modèles open-source — beaucoup plus rares. Pour être qualifié ainsi selon l’OSI, un modèle doit fournir les poids, le code d’entraînement et les données d’entraînement. C’est le cas d’OLMo, développé par l’Allen Institute for AI, qui publie l’intégralité de sa chaîne de production, y compris le dataset Dolma. Pythia, d’EleutherAI, suit la même philosophie. Ces modèles sont les seuls à pouvoir légitimement arborer l’étiquette « open source » au sens de l’OSI.
Les modèles open-data — le graal, encore plus rare. Un modèle open-data va au-delà de l’open-source en publiant non seulement les données d’entraînement, mais aussi les scripts de prétraitement, les configurations d’entraînement complètes et les évaluations reproductibles. OLMo est souvent cité comme l’exemple le plus abouti de cette catégorie, atteignant un niveau de transparence que les géants commerciaux ne semblent pas près d’imiter.
Cette taxonomie n’est pas qu’académique. Elle a des conséquences concrètes. Un modèle open-weights comme Llama 4 peut être téléchargé et exécuté localement, mais vous ne saurez jamais quelles données ont servi à l’entraîner, ni comment il a été construit. Pour un usage personnel, cela peut suffire. Pour une entreprise soumise au RGPD ou à l’EU AI Act, c’est un problème majeur : comment garantir la conformité d’un système dont vous ignorez les données d’entraînement ?
OSAID 1.0 et EU AI Act : le grand fossé juridique de 2026
La publication de l’OSAID 1.0 par l’OSI en octobre 2024 a créé un référentiel strict, mais c’est l’EU AI Act qui a transformé cette distinction en enjeu de conformité. Le règlement européen, dont les obligations de transparence pour les modèles GPAI sont entrées en vigueur selon un calendrier échelonné entre 2025 et 2026, impose aux fournisseurs de modèles d’IA à usage général de publier un résumé détaillé du contenu utilisé pour l’entraînement. Cette exigence, inscrite à l’article 53, va bien au-delà d’une simple déclaration : elle exige une documentation substantielle sur les données, leur provenance, leur traitement.
Or, un modèle open-weights comme Llama 4 ou Qwen 3 ne satisfait pas à ces exigences. Meta et Alibaba ne publient pas leurs datasets d’entraînement, et ne fournissent qu’un résumé vague de leurs sources. Les modèles véritablement open-source comme OLMo, qui publient tout, y compris le dataset Dolma, sont structurellement mieux placés pour répondre aux exigences européennes.
Le fossé est donc double. Juridiquement, un modèle open-weights peut être utilisé en Europe, mais son fournisseur risque des sanctions pour non-conformité aux obligations de transparence. Pratiquement, un utilisateur qui déploie un tel modèle dans un contexte professionnel ne peut pas démontrer la conformité de sa chaîne de traitement, ce qui l’expose à des risques en cas de contrôle.
La situation est d’autant plus confuse que les dates d’application exactes font débat. Certaines sources évoquent une entrée en vigueur des obligations de transparence en août 2025, d’autres mentionnent une « checklist conformité » datée du 2 août 2026. Ce flou réglementaire n’arrange personne, et les entreprises qui veulent déployer des LLM en local se retrouvent face à un dilemme : adopter un modèle open-weights pratique mais potentiellement non conforme, ou un modèle open-source plus transparent mais souvent moins performant.
C’est précisément ce que documente un retour d’expérience publié le 5 septembre 2026 par qdna.fr : sur une plateforme d’IA locale adossée à un LLM open source, « confidentialité, permanence et maîtrise du modèle sont acquises, licence et seuil se gèrent ». La formulation est révélatrice : la technique n’est plus le point dur, la licence et les seuils le sont devenus. Pour une PME, la vraie question n’est plus « quel modèle fait tourner quoi », mais « quel modèle puis-je légalement faire tourner, et à partir de quel volume d’usage le coût change-t-il de nature ».
Cette bascule est désormais documentée par les médias spécialisés. Le Journal du Net, dans un article du 14 octobre 2026 intitulé « Héberger son propre LLM pour réduire la facture IA : faire le calcul », rappelle que « faire tourner une IA sur son propre serveur séduit de plus en plus de dirigeants » et que « le calcul de rentabilité dépend de deux paramètres » — le coût de l’infrastructure amortie d’un côté, le prix au token de l’API de l’autre. Autrement dit, la licence n’est qu’un des deux termes de l’équation économique ; l’autre est le coût réel de possession, que notre dossier sur le coût énergétique de l’IA locale chiffre précisément.
Apache 2.0, Llama, Qwen, DeepSeek : décrypter les licences ligne par ligne
La licence est le premier filtre à passer avant de télécharger un modèle. Et là, la diversité est déroutante. Voici un tableau comparatif des principales licences en vigueur en 2026 :

| Licence | Modèles concernés | Redistribution des poids | Fine-tuning | Usage commercial | Seuils / redevances |
|---|---|---|---|---|---|
| Apache 2.0 | Mistral (certains), gpt-oss-120b/20b, Qwen3-VL-32B | Libre, y compris modifié | Autorisé sans restriction | Autorisé sans restriction | Aucun |
| Llama Community License | Llama 4 (Meta) | Autorisé, mais conditions | Autorisé, mais conditions | Autorisé sous conditions | Seuil d’utilisateurs mensuels (MAU) au-delà duquel une licence commerciale est requise |
| Qwen License | Qwen 3 (Alibaba) | Autorisé, mais conditions | Autorisé, mais conditions | Autorisé sous conditions | Seuil MAU similaire à Llama |
| DeepSeek License | DeepSeek R1/V3 | Autorisé, mais conditions | Autorisé, mais conditions | Autorisé sous conditions | Seuil MAU et restrictions spécifiques |
| Licence personnalisée Kimi K3 | Kimi K3 (Moonshot AI) | Autorisé, mais conditions | Autorisé, mais conditions | Autorisé sous conditions | Seuil MaaS de 20 M$ de revenus, auto-hébergement requis au-delà |
| MiniMax H3 Community License | MiniMax H3 | Interdit dans 4 pays (États-Unis, UE, Royaume-Uni, Corée du Sud) | Interdit dans ces zones | Interdit dans ces zones | Exclusion géographique totale |
Le contraste avec Apache 2.0 est saisissant. Cette licence permissive, utilisée par Mistral pour certains de ses modèles et par OpenAI pour gpt-oss, n’impose aucune condition : vous pouvez faire ce que vous voulez des poids, y compris les modifier, les redistribuer, les intégrer dans un produit commercial, sans jamais payer de redevance ni demander d’autorisation.
Les licences propriétaires déguisées, en revanche, sont truffées de clauses qui font mal. Les seuils d’utilisateurs mensuels (MAU) sont le piège le plus classique : tant que votre application reste sous un certain nombre d’utilisateurs actifs mensuels, la licence est gratuite ; au-delà, vous devez négocier une licence commerciale avec l’éditeur. Les conditions de redistribution des poids modifiés sont tout aussi restrictives : certains contrats exigent que les versions fine-tunées soient publiées sous la même licence, d’autres interdisent purement et simplement la redistribution.
Le cas MiniMax H3, publié sur Hugging Face le 3 août 2026, illustre de manière spectaculaire les dérives possibles. Sa licence « MiniMax H3 Community License » exclut explicitement les États-Unis, l’Union européenne, le Royaume-Uni et la Corée du Sud de son « Territoire applicable ». Les sections I.3, I.5 et V.4 interdisent l’utilisation, l’exécution, la modification, la distribution et le déploiement des sorties générées localement dans ces zones. Selon Ryan Lee, Head of Developer Relations chez MiniMax, cette restriction américaine est directement liée à un litige actif en matière de droits d’auteur avec des studios hollywoodiens. Autrement dit : un modèle « open » que vous ne pouvez pas utiliser si vous vivez en Europe.
Ce cas n’est pas isolé dans sa logique, même s’il est extrême dans sa formulation. Le comparatif chinois publié le 5 septembre 2026 par Iatrust le confirme : « en 2026, le "meilleur" modèle chinois dépend du cas d’usage — chat, code, contexte long ou multimodal ». DeepSeek, Qwen, Kimi, GLM, MiniMax ne se distinguent pas seulement par leurs performances, mais par des régimes de licence qui rendent certains usages impossibles selon votre pays ou votre volume d’activité. Choisir un modèle, c’est désormais arbitrer entre performance, légalité et coût de possession.
Le tournant Mistral Large 4 : l’Europe entre dans le jeu open-weight
Longtemps, le débat « open vs open source » s’est joué entre acteurs américains et chinois. L’automne 2026 a rebattu les cartes avec l’arrivée d’un poids lourd européen. Le 6 octobre 2026, Mistral a officialisé Mistral Large 4, alias « Le Chonk », un modèle de frontière de 1 000 milliards de paramètres entraîné en Europe. Clubic rapporte que Mistral a lancé ce jour-là la préversion publique du modèle, avec une promesse forte : la publication des poids open-weight le 27 octobre 2026, soit à peine trois semaines plus tard. Presse-Citron souligne que Mistral « rattrape enfin la Chine en proposant l’un des meilleurs modèles d’IA » de la catégorie des technologies ouvertes, tandis que Numerama résume l’enjeu : alors que ses détracteurs l’annonçaient distancé par les modèles open source chinois et les géants américains, « Mistral fait son grand retour ».
Pour notre sujet, l’information est doublement importante. D’abord parce qu’elle prouve que la catégorie open-weight reste dynamique et que l’Europe y joue désormais un rôle de premier plan. Ensuite — et surtout — parce que la licence qui accompagnera ces poids sera déterminante. Un modèle de 1 000 milliards de paramètres publié en open-weight ne pourra pas être exécuté confortablement sur une machine domestique : il faudra soit un serveur multi-GPU, soit recourir à une version quantifiée agressive, soit passer par une API. La question de la licence (Apache 2.0 ? licence communautaire avec seuil MAU ?) décidera si une PME européenne peut l’intégrer dans un produit sans négocier. C’est exactement le type d’arbitrage que notre dossier « Faire tourner des LLM open source chez soi sans se ruiner : le guide PME 2026 » place au centre : le bon ratio perf/prix n’a de sens que si la licence autorise l’usage envisagé.
Il faut par ailleurs noter que la frontière entre « open-weight » et « open source » ne bouge pas d’un iota avec Mistral Large 4 : publier les poids ne signifie toujours pas publier le code d’entraînement ni les données. La définition OSAID 1.0 reste hors d’atteinte pour ce type de modèle. La nouveauté est commerciale et géopolitique, pas définitionnelle.
Ce que « open » change concrètement quand on fait tourner un LLM chez soi
Reste la question qui intéresse le lecteur de ce magazine : qu’est-ce que tout cela change pour celui qui veut faire tourner un LLM sur sa propre machine sans se ruiner ? La réponse tient en trois constats, tous documentés par nos dossiers techniques de 2026.

Premier constat : la technique n’est plus le verrou. Comme le détaille notre dossier « Faire tourner des LLM open source chez soi sans se ruiner : iGPU, mémoire unifiée et le vrai basculement de 2026 », les iGPU AMD RDNA3/RDNA4 et Intel Arc intégrés, couplés à la mémoire unifiée des mini-PC (Acer Ryzen AI Halo à 128 Go pour 3 999 $, AMD Gorgon Halo visant 192 Go et des modèles jusqu’à 200B+), ont fait tomber le dogme « il te faut une RTX ». Sur un Radeon 780M, un Llama 3 8B Q4 tourne à ~10-12 tok/s en Vulkan, un Mistral 7B Q4_K_M à ~8-11 tok/s, avec un gain Vulkan de +50 % et un bonus MMVQ de +12,9 %. Ce n’est pas de la production à grande échelle, mais c’est parfaitement utilisable pour un usage personnel ou une petite équipe.
Deuxième constat : le moteur d’inférence est devenu un choix stratégique. Notre dossier « Optimiser l’inférence LLM locale en 2026 » montre que les modèles open-weights de 2026 — Kimi K3, DeepSeek V4 Pro, Mistral Large 4 — tiennent désormais tête aux API propriétaires, et que « le vrai différenciateur n’est donc plus le choix du modèle » mais la façon de l’exécuter : quantification Q8/Q4/Q2, PagedAttention, continuous batching, speculative decoding, offloading. Le comparatif 2026 de PromptQuorum sur les moteurs d’inférence et runtimes locaux recense 48 outils (Ollama, LM Studio, Jan, llama.cpp, vLLM…) avec leurs licences, leur support GPU et leur compatibilité API OpenAI. Et llama.cpp est passé en v0.5.0 en 2026, avec un backend, des modèles et un serveur remaniés — un guide pratique d’installation et d’usage de l’API locale est disponible.
Troisième constat : la licence est devenue le vrai point dur. C’est la conclusion qui traverse tous nos dossiers. Un modèle open-weight téléchargeable ne vous autorise pas forcément à le redistribuer, à le fine-tuner pour un client, ni à le déployer dans l’UE. Le cas MiniMax H3 le démontre de façon caricaturale. À l’inverse, un modèle Apache 2.0 comme gpt-oss ou certains Mistral vous laisse une liberté totale. Entre les deux, les licences Llama, Qwen, DeepSeek et Kimi imposent des seuils MAU ou des conditions de redistribution qu’il faut lire avant de déployer.
C’est là que la définition OSAID 1.0 redevient utile, non comme label marketing mais comme grille d’audit : si un fournisseur ne publie ni code d’entraînement ni données, vous savez que vous ne pourrez pas démontrer la reproductibilité de votre chaîne, ni répondre sereinement à un audit RGPD ou AI Act. Les modèles réellement open-source (OLMo, Pythia) restent les seuls à offrir cette garantie — au prix, souvent, de performances inférieures aux modèles open-weight de frontière.
Le mot de la fin : « open » n’est pas un label, c’est un contrat
En 2026, la question n’est plus « ce modèle est-il open source ? » mais « qu’est-ce que sa licence m’autorise à faire, dans mon pays, à mon volume d’usage, avec mes obligations réglementaires ? ». Les trois niveaux d’ouverture — open-weights, open-source, open-data — ne sont pas une hiérarchie de qualité mais une hiérarchie de droits. Un modèle open-weights peut être excellent et parfaitement adapté à un usage personnel ; il devient un risque dès qu’on le déploie en production sans lire sa licence.
La bonne nouvelle, c’est que l’écosystème local n’a jamais été aussi mature : matériel à mémoire unifiée abordable, moteurs d’inférence optimisés, modèles de frontière open-weight publiés par des acteurs européens comme Mistral. La mauvaise, c’est que la complexité juridique a crû au moins aussi vite que les performances. Pour faire tourner un LLM chez soi sans se ruiner, il faut donc désormais deux compétences : savoir quantifier un modèle et savoir lire un contrat. La première est documentée partout dans ce magazine ; la seconde commence par une règle simple : « open » ne veut pas dire « open source », et « téléchargeable » ne veut pas dire « libre ».
Sources
- Forbes — « Open weights are not open source, and it matters now in the boardroom » (11 septembre 2026)
- Digital-m.fr — « LLM open-weights : Llama, Mistral, Qwen et le vrai sens du mot open source » (mis à jour le 16 juin 2026)
- QuelLLM.fr — synthèse « poids ouverts, code ouvert, données ouvertes » (27 août 2026)
- Iatrust — comparatif LLM & API IA (5 septembre 2026)
- qdna.fr — retour d’expérience plateforme d’IA locale (5 septembre 2026)
- Journal du Net — « Héberger son propre LLM pour réduire la facture IA : faire le calcul » (14 octobre 2026)
- Clubic — « Avec Mistral Large 4, l’IA française ose défier GPT-6 Astra et publiera ses poids à tous le 27 octobre » (6 octobre 2026)
- Presse-Citron — « Mistral Large 4 est officiel : la France rattrape enfin la Chine » (6 octobre 2026)
- Numerama — « Mistral relance la France dans la course à l’IA et dévoile "Le Chonk" » (6 octobre 2026)
- Generation-NT — « Mistral dévoile Mistral Large 4 avec 1 000 milliards de paramètres » (6 octobre 2026)
- PromptQuorum — comparatif des moteurs d’inférence et runtimes locaux 2026 (20 septembre 2026)
- Gyanaangan — « llama.cpp v0.5.0 in 2026: What Changed, How to Install, Run GGUF & Use the Local API » (27 septembre 2026)
- Techgenyz — « Windows ML: 2026 Updates for GGUF Models and Local AI » (9 octobre 2026)
- Microsoft Foundry on Windows Blog — « AI Development on Windows: from PyTorch and llama.cpp to Windows ML » (7 octobre 2026)
- PyTorch — « Introducing TorchTPU » (20 octobre 2026)
- Dossiers internes du magazine : « Optimiser l’inférence LLM locale en 2026 », « Faire tourner des LLM open source chez soi sans se ruiner : iGPU, mémoire unifiée et le vrai basculement de 2026 », « Faire tourner des LLM open source chez soi sans se ruiner : le guide PME 2026 », « Le vrai coût énergétique de l’IA locale », « AirLLM en 2026 ».
Article recherché et rédigé automatiquement · Magazine Electrosens