Les poids d’un modèle se téléchargent en une commande. La licence, elle, se lit en entier. Entre les deux se joue tout ce qu’une entreprise a le droit, ou non, de faire du modèle une fois le prototype passé en production.
Au sens strict, un LLM open source est un modèle dont la licence autorise à l’utiliser, l’étudier, le modifier et le redistribuer sans restriction de domaine d’usage. Le téléchargement libre ne suffit pas à cocher la case. La plupart des modèles vendus sous cette étiquette restent à poids ouverts, ce qui est utile, souvent suffisant, mais différent.
Le débat a des conséquences juridiques directes. Le 15 septembre 2026, The Register titrait « Open weights are not open source: why AI’s favorite label is under dispute ». L’Open Source Initiative (OSI), qui tient la définition de référence de l’open source logiciel, maintient de son côté une page dédiée pour corriger le malentendu, Open Weights: not quite what you’ve been told. Quand l’organisme qui a inventé le terme doit publier un démenti, l’étiquette a dérivé.
Les quatre conditions posées par l’OSI
L’OSI a publié une définition taillée pour les modèles, l’OSAID 1.0 (Open Source AI Definition). Elle exige quatre éléments réunis : le code d’entraînement, une information suffisante sur les données utilisées, les poids du modèle, et une licence qui n’impose aucune restriction de domaine d’usage.
Ce dernier critère est le plus discriminant, et le moins commenté. Une licence qui interdit l’usage militaire, l’usage médical ou l’usage au-delà d’un certain nombre d’utilisateurs peut être parfaitement raisonnable sur le fond. Elle n’est simplement pas open source, parce que l’open source ne choisit pas qui a le droit de s’en servir. C’est une liberté binaire, pas un curseur.
Sur un logiciel classique, la question ne se pose pas : le code source, c’est le logiciel. Sur un modèle, la matière première est ailleurs. Vous pouvez tenir les poids entre les mains sans rien savoir du corpus d’entraînement, sans pouvoir reproduire le résultat, et sans avoir le droit de le déployer partout.
Poids, code, données : trois briques qui s’obtiennent séparément
Trois briques circulent sous le même mot, et elles voyagent rarement ensemble.
- Les poids : le fichier de paramètres que vous chargez pour faire tourner le modèle chez vous. C’est ce que livrent la quasi-totalité des modèles dits ouverts.
- Le code d’entraînement : les scripts et recettes qui ont produit ces poids. Publié beaucoup plus rarement, et souvent partiellement.
- Les données : le corpus, ou à défaut sa description détaillée. C’est la brique la plus souvent manquante, pour des raisons de droit d’auteur autant que de secret industriel.
Avoir les poids vous donne déjà l’essentiel de ce que cherchent les équipes techniques : l’exécution sur votre infrastructure, le fine-tuning sur vos données, l’absence de dépendance à la disponibilité d’une API tierce. Cela ne vous donne ni la capacité d’auditer ce que le modèle a lu, ni la garantie de pouvoir l’utiliser dans n’importe quel contexte commercial. Les deux manques ne se compensent pas.
Trois familles de licences, trois niveaux de liberté
Dans la pratique, trois familles se partagent le terrain. Les licences logicielles classiques, MIT ou Apache 2.0, qui laissent les mains libres. Les licences maison, dites communautaires, écrites par l’éditeur pour son propre modèle. Les licences source-available ou recherche uniquement, qui autorisent à regarder et à expérimenter, jamais à vendre.
Quelques repères concrets, à traiter comme des exemples datés et non comme une règle : Llama reste diffusé sous sa Community License, assortie d’un seuil de 700 millions d’utilisateurs actifs mensuels au-delà duquel une licence commerciale doit être négociée. Qwen 3 et 3.5 sont sous Apache 2.0, mais d’autres versions de la même famille restent en source-available ou en recherche non commerciale. DeepSeek V4, publié le 23 avril 2026, est passé sous MIT.
L’hétérogénéité de ces trois lignes compte plus que leur contenu. Une même famille de modèles peut changer de licence d’une version à l’autre, dans les deux sens. Le nom de la marque ne vous dit rien du régime juridique. Il faut ouvrir le fichier de licence de la version précise que vous déployez, à chaque montée de version.
Les questions qui décident, et qui prennent dix minutes :
- L’usage commercial est-il autorisé sans contrepartie, ou conditionné à un seuil, à une déclaration, à un accord signé ?
- Existe-t-il une restriction de domaine : santé, défense, biométrie, décision automatisée ?
- Avez-vous le droit de redistribuer le modèle que vous avez fine-tuné, et sous quelle licence ?
- Les sorties du modèle peuvent-elles servir à entraîner un autre modèle, ou la licence l’interdit-elle ?
- Quelles obligations d’attribution ou de nommage pèsent sur votre produit final ?
La normalisation avance de son côté : la Linux Foundation pousse OpenMDW, une licence unique pensée pour couvrir d’un seul tenant le modèle, le code, les données et la documentation. NVIDIA a annoncé son adoption pour ses prochaines familles de modèles ouverts, Cosmos et Nemotron notamment. Un texte de référence largement adopté réglerait une bonne partie du flou ; aucun ne fait encore consensus.
L’exemption open source de l’AI Act est conditionnelle
Le règlement européen sur l’IA prévoit un régime allégé pour les modèles diffusés en open source. Beaucoup d’équipes en déduisent qu’un modèle ouvert les dispense des obligations documentaires. La lecture est trop rapide.
Ce régime suppose notamment une absence de monétisation, ce qui exclut de fait le modèle intégré dans une offre payante. Et il disparaît entièrement au-delà du seuil des modèles à usage général présentant un risque systémique, fixé à 10^25 FLOPs de calcul d’entraînement : à ce niveau, l’ouverture ne rachète rien, les obligations s’appliquent.
Autre malentendu fréquent : l’ouverture d’un modèle ne dit rien de la localisation des données. Ce qui protège vos données, c’est l’endroit où tournent les GPU et le contrat qui vous lie à celui qui les opère. Un modèle sous MIT servi depuis une infrastructure hors Union européenne ne vous met pas plus à l’abri qu’une API propriétaire. Le bénéfice de souveraineté vient de l’hébergement, que l’ouverture rend possible mais ne garantit pas.
Ouvert ou fermé : deux structures de coût opposées
Le calcul économique se pose rarement dans le bon sens. Une API facture au token, sans coût fixe : la facture suit l’usage, à la hausse comme à la baisse. Un modèle auto-hébergé inverse la structure, avec un coût fixe de GPU, de stockage et d’exploitation qui court que vous l’utilisiez ou non. L’un devient moins cher que l’autre à partir d’un volume, et ce point de bascule dépend de votre charge, pas d’un benchmark.
Ce que les comparatifs oublient : le temps d’ingénierie. Servir un modèle en production, surveiller la latence, gérer les montées de version, maintenir une chaîne d’évaluation, cela mobilise des compétences MLOps (exploitation de modèles en production) qui coûtent plus cher que les cartes graphiques.
Les critères qui font pencher la balance :
- Sensibilité des données : données de santé, RH ou juridiques traitées en volume, l’auto-hébergement s’impose.
- Besoin de spécialisation : un fine-tuning sur votre corpus métier suppose l’accès aux poids.
- Stabilité : un modèle téléchargé ne change pas sous vos pieds, une API peut évoluer ou disparaître.
- Volume et prévisibilité : charge forte et régulière pour l’auto-hébergement, usage irrégulier pour l’API.
- Plafond de qualité : sur les tâches les plus exigeantes, l’écart avec les meilleurs modèles fermés se paie en résultats.
Dans la majorité des cas, la réponse est mixte : un modèle ouvert sur les volumes répétitifs et les données sensibles, une API sur les tâches rares et difficiles. Cette répartition tire parti des deux structures de coût au lieu d’en subir une.
Deux issues restent ouvertes pour les mois qui viennent : l’OSAID s’impose comme le filtre que l’industrie accepte, ou le marketing continue d’appeler open source ce qui n’est qu’un téléchargement autorisé. Le rythme d’adoption d’OpenMDW par les éditeurs donnera un premier indice. D’ici là, un seul réflexe protège : ne jugez pas un modèle sur son étiquette, ouvrez son fichier de licence.
Questions frequentes
Quelle est la différence entre un LLM open source et un modèle à poids ouverts ?
Un modèle à poids ouverts se télécharge et s’exécute librement, mais sa licence peut restreindre l’usage commercial ou certains domaines d’application. Un LLM open source au sens de l’OSI ajoute le code d’entraînement, une information suffisante sur les données, et une licence sans restriction de domaine d’usage.
Llama est-il un modèle open source ?
Llama est diffusé sous une Community License propre à son éditeur, et non sous une licence open source reconnue. Elle impose notamment un seuil de 700 millions d’utilisateurs actifs mensuels au-delà duquel une licence commerciale distincte doit être obtenue.
Qu’exige la définition OSAID 1.0 de l’Open Source Initiative ?
L’OSAID 1.0 demande quatre éléments réunis : le code d’entraînement, une information suffisante sur les données utilisées, les poids du modèle, et une licence qui n’impose aucune restriction de domaine d’usage.
L’AI Act européen exempte-t-il automatiquement les modèles open source ?
Non. L’exemption est conditionnelle, notamment à l’absence de monétisation du modèle, et elle ne s’applique plus au-delà du seuil des modèles à usage général présentant un risque systémique, fixé à 10^25 FLOPs de calcul d’entraînement.
Un modèle ouvert garantit-il que les données restent en Europe ?
Non. La localisation des données dépend de l’endroit où le modèle est exécuté et du contrat passé avec l’hébergeur, pas de la licence. L’ouverture rend l’hébergement souverain possible, elle ne le fournit pas.
