Guides · IA open source

Licences IA open weight vs open source : ce que les entreprises peuvent vraiment utiliser

Par Loïc Jané·Mis à jour le 18 août 2026·10 min de lecture

L'essentiel : « ouvert » signifie des choses différentes en IA, et la différence compte commercialement. Le strict open source (approuvé OSI, comme Apache 2.0 ou MIT) et les poids ouverts (source-available, comme la licence communautaire Llama de Meta ou — pour la plupart des usages d'entreprise — la licence Kimi K3) permettent tous deux à une entreprise d'auto-héberger et d'utiliser un modèle commercialement dans presque tous les scénarios pratiques. Pour un déploiement interne, la licence est rarement le blocage ; la vraie tâche est de lire les termes exacts, de vérifier les conditions liées à l'échelle, et d'archiver le tout pour que votre DPO puisse le défendre. Ce guide décrypte les licences que vous croiserez réellement, et comment en examiner une en quelques minutes.

Poids ouverts vs open source : la distinction qui compte

L'industrie de l'IA a emprunté le mot « ouvert » au logiciel sans en importer la définition.

Le strict open source désigne la définition OSI : la licence est approuvée, chacun reçoit les mêmes droits, les dérivés et redistributions se font sous les mêmes termes. En pratique pour les modèles, cela signifie généralement Apache 2.0 ou MIT — des licences permissives qui autorisent l'usage commercial, la modification et la distribution avec peu de conditions. Les modèles publiés ainsi (plusieurs de Mistral, une partie de la famille Qwen d'Alibaba, beaucoup de modèles petits et intermédiaires) sont ce que l'IA a de plus proche de l'open source logiciel familier.

Poids ouverts (ou source-available) désigne quelque chose de plus étroit : les poids entraînés sont publics et vous pouvez les utiliser, mais sous une licence écrite pour l'occasion, qui peut ajouter des conditions — attribution à l'échelle, clause de model-as-a-service, ou champs d'utilisation restreints. La licence communautaire Llama de Meta et la licence Kimi K3 de Moonshot vivent ici. On les appelle souvent « open weight » plutôt qu'« open source » précisément parce qu'elles ne satisfont pas la définition OSI. Un exemple récent et parlant en août 2026 : le Qwen3.8-Max d'Alibaba (un modèle de 2 400 milliards de paramètres, 95 milliards d'actifs) est publié sous une licence dédiée Qwen3.8-Max License — des poids ouverts, mais une licence source-available, pas de l'open source OSI.

Le point pratique pour une entreprise : les deux catégories sont déployables commercialement, et les deux permettent l'auto-hébergement. La différence apparaît dans les petits caractères et les seuils d'échelle, pas dans la possibilité de démarrer.

Les licences que vous rencontrerez vraiment

Licence	Catégorie	Auto-hébergement commercial	À surveiller
Apache 2.0	Open source OSI	Oui, librement	Attribution dans les dérivés substantiels ; brevet
MIT	Open source OSI	Oui, librement	Attribution dans les copies ; sans garantie
Licence communautaire Llama	Poids ouverts / source-available	Oui	Seuils d'échelle (MAU) avant conditions ; pas de model-as-a-service sans accord au-delà des limites
Licence Kimi K3	Poids ouverts (dérivée du MIT)	Oui ; l'usage interne est explicitement exempté des conditions	Attribution au-delà de 100M MAU / 20 M$ de revenus ; accord séparé pour le model-as-a-service à grande échelle

C'est une carte, pas un avis juridique — lisez toujours le texte réel et, pour ce sur quoi vous bâtirez, faites-le confirmer par le conseil juridique. Mais remarquez le schéma : les licences OSI permissives sont sans friction, et les licences open weight le sont aussi à toute échelle d'entreprise réaliste. Les cas difficiles sont de niche (revendre le modèle lui-même à très grande échelle), pas le déploiement auto-hébergé courant.

Pourquoi les licences comptent plus à mesure que les modèles sortent

Nous vivons une période d'abondance de sorties open weight, et le risque de conformité n'est pas le modèle de pointe phare — les équipes lisent la fiche de ceux-là. Le risque, c'est l'assistant qu'un développeur a installé depuis un classement, dont personne n'a lu la licence. C'est dans ces déploiements informels que vivent réellement les problèmes de licence dans les entreprises.

Trois habitudes ferment cette brèche :

L'examen de licence fait partie de l'intégration. Chaque modèle qui touche des données d'entreprise voit sa licence lue, archivée, et ses obligations consignées — la même discipline que les scans de dépendances en génie logiciel.
Les clauses de champ d'utilisation sont lues au pied de la lettre. Un modèle rare restreint certains secteurs ou usages ; ce sont les petits caractères qui décident de son utilité pour votre cas.
La distribution est traitée séparément de l'usage interne. Servir le modèle à vos propres équipes est une chose ; l'exposer en service à des clients en est une autre, et c'est là que se déclenchent la plupart des conditions.

Ce que « usage interne » signifie en pratique

Pour l'immense majorité des déploiements Fleece — un modèle auto-hébergé derrière une passerelle, utilisé par vos propres équipes avec du RAG sur vos documents — l'usage interne est le scénario opérant, et c'est le plus léger sur toutes ces licences :

Apache 2.0 et MIT : aucune condition notable au-delà de l'attribution ; l'auto-hébergement interne est tout à fait ordinaire.
Licence Kimi K3 : l'usage interne est explicitement hors du champ des conditions liées à l'échelle — elle se comporte comme du MIT pour vos propres équipes.
Licence communautaire Llama : l'usage interne est permis et standard ; les conditions évoluent avec votre base d'utilisateurs si vous mettez le modèle derrière un produit.

Le moment où cela change, c'est si vous offrez le modèle en service à des tiers — c'est là que les clauses de model-as-a-service et les seuils de revenus entrent en jeu, et où l'appel au conseil juridique vaut le coup. Si vous intégrez un modèle dans un logiciel que vous vendez à des clients, les termes s'appliquent à votre produit, et c'est un autre échange (généralement toujours praticable).

Comment examiner une licence de modèle en quelques minutes

Lire le texte réel. Ouvrez le fichier de licence — accessible depuis la fiche Hugging Face ou le dépôt de l'éditeur. Les gros titres et articles paraphrasent et se trompent.
Répondre à trois questions : (1) L'usage commercial est-il permis ? (2) L'auto-hébergement et la modification sont-ils permis ? (3) Y a-t-il des conditions — attribution, seuils d'échelle, champs d'utilisation, model-as-a-service ? Si les trois sont nets, vous êtes déployable.
Confronter votre scénario aux conditions. « Permis » n'est pas « inconditionnel ». Vérifiez si votre plan d'usage (interne, produit client, service hébergé) déclenche une clause.
Archiver le tout. Conservez le texte de la licence, la version figée des poids et sa somme de contrôle. C'est ce qui permet à votre DPO de répondre « quel modèle, sous quels termes ? » lors d'un audit.

Les pièges classiques

Se fier à l'étiquette, pas à la licence. « Ouvert » et « gratuit » sont du marketing tant que vous n'avez pas lu les termes. Lisez le fichier.
Ignorer la différence entre usage interne et distribution. Servir vos propres équipes et livrer dans un produit client sont régis différemment.
Passer à côté de l'archivage. Une licence permissive exige quand même des versions figées, des sommes de contrôle et un texte archivé pour tenir face à un audit.
Supposer que les clauses de model-as-a-service ne comptent jamais. Elles comptent rarement pour l'auto-hébergement — et absolument si vous revendez l'accès au modèle à grande échelle. Sachez de quel côté de la ligne vous êtes.

Questions fréquentes

Quelle est la différence entre open weight et open source en IA ?

L'open source (Apache 2.0 ou MIT par exemple) désigne une licence approuvée OSI accordant les mêmes droits à tous, redistribution comprise sous les mêmes termes. Les poids ouverts (source-available) désignent des poids entraînés publics sous une licence écrite pour l'occasion, qui peut ajouter des conditions — comme la licence communautaire Llama de Meta ou la licence Kimi K3 de Moonshot. Les deux permettent l'usage commercial et l'auto-hébergement dans presque tous les scénarios d'entreprise réalistes ; la différence apparaît dans les conditions d'échelle et d'attribution, pas dans la possibilité de démarrer.

Mon entreprise peut-elle utiliser un modèle open weight commercialement ?

Dans presque tous les cas pratiques, oui. Les modèles Apache 2.0 et MIT sont librement utilisables commercialement. Les licences open weight permissives comme la licence Kimi K3 autorisent aussi l'usage commercial, avec des obligations qui ne se déclenchent qu'à échelle extrême (attribution au-delà de 100 millions d'utilisateurs mensuels ou 20 millions de dollars de revenus mensuels) — et l'usage interne en entreprise est explicitement exempté. La licence communautaire Llama autorise l'usage commercial dans des seuils d'échelle définis. Lisez la licence exacte de votre modèle, mais la réponse par défaut pour un déploiement interne auto-hébergé est « oui ».

La licence permet-elle l'auto-hébergement et le fine-tuning ?

Pour Apache 2.0, MIT et les licences open weight permissives (Kimi K3, Llama), l'auto-hébergement et le fine-tuning sont permis. C'est précisément ce qui rend les modèles open weight déployables sur votre propre infrastructure. Les conditions légères qui existent ciblent l'attribution et la redistribution à échelle extrême, pas l'usage interne et l'adaptation — c'est pourquoi un déploiement auto-hébergé est rarement le cas de licence difficile.

Un modèle open weight d'un éditeur chinois est-il un problème ?

Pas parce qu'il est open weight. Auto-hébergé, les poids tournent entièrement sur une infrastructure que vous contrôlez et l'éditeur ne voit jamais vos prompts, donc la question de souveraineté s'inverse. La diligence qui reste est l'examen de licence, la qualité des sorties sur vos tâches, et votre propre gouvernance — la même pour tout modèle, quelle que soit son origine. La question de licence porte sur les termes, pas sur le drapeau.

Ai-je besoin d'un avocat pour déployer un modèle ouvert dans mon entreprise ?

Pour un déploiement interne auto-hébergé sous Apache/MIT ou une licence open weight permissive, généralement non — lisez la licence et archivez-la. Faites intervenir le conseil juridique lorsqu'un modèle est intégré dans un logiciel que vous vendez à des clients, ou si vous comptez le servir à des tiers en tant que service, car c'est là que la distribution et les clauses de model-as-a-service deviennent pertinentes. Nous examinons ce point avec le DPO du client dans chaque déploiement.

Quels modèles ouverts sont réellement open source (Apache 2.0 ou MIT) ?

Les modèles Apache 2.0 et MIT incluent plusieurs modèles de Mistral et une partie de la famille Qwen d'Alibaba, plus de nombreux modèles plus petits entraînés et publiés sous licences permissives. Beaucoup de sorties récentes de pointe ou open weight utilisent plutôt des licences source-available. La licence est toujours indiquée sur la fiche modèle — vérifiez le fichier exact plutôt que de vous fier aux étiquettes de catégorie, car « ouvert » seul ne dit pas dans quel régime vous êtes.