Modèles d'IA open-weight vs open-source : ce que vous obtenez réellement

Le fait qu'un modèle soit téléchargeable ne le rend pas automatiquement open source.

Le fait que son code source soit disponible sur GitHub non plus.

Et un modèle publié sous une licence logicielle connue ne vous indique pas, en soi, si le système d'IA complet est open source.

La terminologie entourant l'IA ouverte est devenue inhabituellement floue. « Open source », « modèle ouvert » et « poids ouverts » sont souvent utilisés comme s'ils décrivaient la même chose.

Ce n'est pas le cas.

La distinction la plus simple est la suivante :

Modèle à poids ouverts
Vous pouvez obtenir les paramètres appris du modèle, généralement sous forme de fichiers de points de contrôle. Ce que vous êtes autorisé à faire avec ces poids dépend de la licence.

IA open source
Selon la définition actuelle de l'Open Source Initiative, vous avez besoin de libertés plus larges pour utiliser, étudier, modifier et partager l'IA, ainsi que d'un accès à la forme privilégiée pour la modification, incluant les paramètres du modèle, le code pertinent et des informations suffisamment détaillées sur les données d'entraînement.

Cette distinction ne concerne pas seulement la terminologie.

Elle détermine si vous pouvez :

• exécuter le modèle sur votre propre GPU
• inspecter son architecture
• le fine-tuner
• le quantifier
• redistribuer le résultat
• l'utiliser à des fins commerciales
• reproduire son entraînement
• créer un autre modèle à partir de celui-ci
• comprendre l'origine de ses données d'entraînement

Ces droits ne sont pas regroupés automatiquement sous prétexte que le modèle dispose d'un bouton de téléchargement.

Que sont les poids d'un modèle ?

Un réseau de neurones apprend des milliards de paramètres numériques au cours de son entraînement.

Ces paramètres constituent les poids.

Un dépôt de modèle peut contenir des fichiers tels que :

model-00001-of-00004.safetensors
model-00002-of-00004.safetensors
model-00003-of-00004.safetensors
model-00004-of-00004.safetensors

Ces fichiers contiennent l'état numérique appris du modèle.

Si vous disposez de l'architecture, de la configuration, du jetonneur, du logiciel d'inférence et des poids compatibles, vous pouvez généralement exécuter l'inférence sans avoir besoin du jeu de données d'entraînement original ou du cluster d'entraînement.

C'est pourquoi la publication des poids est lourde de conséquences.

Elle permet aux utilisateurs de s'approprier le modèle entraîné, indépendamment de l'entreprise qui l'a créé.

Vous pouvez potentiellement l'exécuter :

sur votre poste de travail

sur votre propre serveur

sur un GPU cloud loué

au sein de votre propre application

derrière votre propre API

au lieu d'envoyer chaque requête au fournisseur du modèle original.

C'est une forme substantielle d'ouverture.

Ce n'en est toutefois qu'une seule couche.

Que signifie « poids ouverts » ?

Il n'existe aucune définition juridique universelle unique de « poids ouverts » équivalente à la définition de l'Open Source pour les logiciels.

En pratique, ce terme signifie généralement que les paramètres du modèle entraîné sont disponibles pour être téléchargés et utilisés par des personnes extérieures au développeur original, selon des conditions définies.

Ces conditions peuvent être très permissives.

Elles peuvent aussi être restrictives.

Deux modèles peuvent être décrits avec précision comme ayant des poids ouverts tout en vous accordant des droits très différents.

Par exemple, Black Forest Labs décrit explicitement FLUX.1 [dev] comme ayant des « poids ouverts », alors que son modèle est régi par une licence limitant l'utilisation du modèle lui-même à des fins non commerciales et non liées à la production, sauf obtention de droits supplémentaires.

Donc :

poids ouverts

signifie pas signifie :

utilisation sans restriction

Cela signifie que vous avez accès aux poids.

Consultez la licence pour savoir ce que vous pouvez en faire.

Que signifie l'IA open source ?

L'Open Source Initiative a publié la version 1.0 de sa Définition de l'IA open source en tant que définition stable pour appliquer les principes établis de l'open source aux systèmes d'IA.

Selon cette définition, un système d'IA open source doit offrir aux utilisateurs la liberté de :

1. Utiliser le système à toute fin, sans avoir à demander d'autorisation.
2. Étudier son fonctionnement et inspecter ses composants.
3. Modifier le système à toute fin.
4. Partager le système, modifié ou non, à toute fin.

Mais ces libertés ne suffisent pas si les éléments nécessaires pour les exercer sont manquants.

La définition de l'OSI précise que la forme privilégiée pour modifier un système d'apprentissage automatique doit inclure trois grandes catégories :

Informations sur les données
Code
Paramètres

C'est ce qui distingue l'IA open source de la simple mise en ligne du code d'inférence sur GitHub.

L'open source ne signifie pas nécessairement publier chaque fichier d'entraînement

Il y a ici une nuance importante.

La définition de l'IA open source ne dit pas simplement :

Téléchargez l'intégralité du jeu de données d'entraînement.

Les données d'entraînement peuvent contenir des éléments qui ne peuvent pas être redistribués légalement ou techniquement.

Au lieu de cela, la définition exige des informations suffisamment détaillées sur les données pour qu'une personne qualifiée puisse construire un système substantiellement équivalent.

Cela inclut des informations telles que :

• les données utilisées
• la provenance
• la portée et les caractéristiques
• la manière dont les données ont été obtenues
• la manière dont elles ont été sélectionnées
• procédures d'étiquetage
• traitement et filtrage
• listes de données d'entraînement accessibles au public
• emplacements de données tierces disponibles ailleurs

La définition de l'OSI exige séparément le code d'entraînement et d'inférence pertinent ainsi que les paramètres du modèle sous des licences ouvertes appropriées.

Il s'agit d'une norme plus utile que ces deux extrêmes :

les poids suffisent

ou :

chaque octet de données d'entraînement doit être mis en ligne

Aucun des deux ne saisit la question réelle :

Les gens disposent-ils de ce dont ils ont besoin, et de la liberté juridique, pour comprendre et modifier le système de manière significative ?

Une version d'IA comporte plusieurs couches différentes

Il est utile de cesser de parler d'un modèle comme s'il s'agissait d'un seul fichier.

Une version d'IA moderne peut inclure :

Le terme « ouvert » peut s'appliquer différemment à chaque ligne.

‍

‍

Vous pourriez avoir :

poids ouverts
+
code d'inférence ouvert
+
recette d'entraînement fermée
+
données d'entraînement non divulguées
+
licence de modèle personnalisée

C'est une version tout à fait envisageable.

La qualifier simplement d'« ouverte » occulte des informations utiles.

« Open-weight » est souvent le terme le plus précis

Si vous savez que les poids d'un modèle sont accessibles au public, mais que vous n'avez pas établi que la version complète répond à une définition spécifique de l'open source, open-weight est généralement la description la plus prudente.

Cela exprime exactement ce que vous savez.

Les poids sont disponibles.

Cela n'implique pas que :

• les données d'entraînement sont suffisamment documentées
• le pipeline d'entraînement est reproductible
• la licence est approuvée par l'OSI
• l'usage commercial est sans restriction
• la redistribution est illimitée
• chaque composant du modèle est disponible

La précision est utile ici car ces questions influencent les décisions de déploiement.

Une licence permissive sur les poids ne règle pas toute la question

Considérez un dépôt de modèle dont le point de contrôle est publié sous :

Licence Apache 2.0

Cela peut accorder aux utilisateurs de larges droits sur l'artefact couvert par cette licence.

Cela ne prouve pas automatiquement que :

l'ensemble du système d'entraînement
=
IA Open Source

selon la définition de l'OSI.

Vous devriez toujours examiner :

• le code
• les informations sur les données
• les paramètres du modèle
• les conditions couvrant ces composants

Le même principe s'applique aux artefacts sous licence MIT.

Une licence logicielle vous indique les droits dont vous disposez sur le matériel qu'elle couvre.

Elle ne fait pas apparaître par magie des informations d'entraînement non publiées.

Qwen illustre le cas d'un modèle sous licence permissive

Les dépôts actuels du modèle Qwen3.6 tels que Qwen3.6-27B-FP8 sont distribués sous licence Apache 2.0.

Cela offre aux développeurs une base de licence familière et permissive pour les artefacts du modèle publié.

C'est l'une des raisons pour lesquelles Qwen est intéressant pour :

• l'auto-hébergement
• les services d'inférence
• la quantification
• les applications commerciales
• le réglage fin

sous réserve, bien entendu, de la licence réelle et de toute autre obligation applicable.

C'est également l'environnement de modèle de base derrière notre guide Qwen3.6-27B RTX 5090.

Mais l'expression :

les poids de Qwen sont sous Apache 2.0

et l'expression :

l'ensemble du système d'entraînement de Qwen satisfait à toutes les exigences de la définition de l'IA open source

sont deux affirmations différentes.

Le premier peut être établi à partir du dépôt.

Le second nécessite un audit plus approfondi.

DeepSeek-R1 accorde des droits inhabituellement étendus sur ses poids publiés.

DeepSeek indique que son dépôt R1 et ses poids de modèle sont sous licence MIT.

Son dépôt officiel autorise explicitement l'utilisation commerciale, la modification, les produits dérivés et la distillation, sous réserve de la situation des licences des modèles sous-jacents utilisés pour certaines variantes distillées.

Cela confère aux développeurs une grande liberté pratique concernant les artefacts publiés.

Cependant, il convient de distinguer deux questions distinctes :

Quels droits la licence des poids m'accorde-t-elle ?

et :

Le système d'IA dans son ensemble répond-il à une définition spécifique de l'open source ?

Ne confondez pas la première réponse avec la seconde.

Pour le déploiement, la première question peut suffire.

Pour débattre du caractère techniquement « Open Source » d'une IA, la seconde est également nécessaire.

Notre guide sur les tailles des modèles DeepSeek-R1 et le matériel requis traite de ce qui se passe lorsque vous essayez réellement d'exécuter ces poids.

Llama démontre pourquoi « poids disponibles » et « open source » ne sont pas synonymes.

Meta distribue les poids du modèle Llama et le code associé, mais sous sa propre licence Llama Community License plutôt que sous une licence de logiciel open source permissive standard.

Pour Llama 4, la licence accorde de larges droits d'utilisation, de reproduction, de distribution, de modification et de création d'œuvres dérivées, mais elle intègre également une politique d'utilisation acceptable et contient des conditions commerciales supplémentaires pour les organisations dépassant les 700 millions d'utilisateurs actifs mensuels.

Cela a son importance au regard de la définition de l'IA Open Source de l'OSI, car la liberté exigée par l'OSI inclut explicitement :

utiliser le système à toute fin et sans avoir à demander d'autorisation.

Ainsi, selon cette définition, une licence imposant des restrictions sur le domaine d'utilisation n'est pas équivalente à une IA Open Source sans restriction.

Cela ne rend pas Llama inaccessible.

Cela ne le rend pas inutilisable commercialement pour les organisations ordinaires.

Cela signifie que modèle à poids ouverts ou disponible ouvertement est plus précis que de supposer que chaque version téléchargeable de Llama appartient à la même catégorie de licence que le logiciel Apache-2.0.

Notre guide des exigences GPU pour Llama 3.3 70B renvoie donc à la licence Llama applicable plutôt que de considérer le terme « ouvert » comme une dispense de lecture.

FLUX.1 [dev] rend cette distinction impossible à ignorer

Black Forest Labs qualifie lui-même FLUX.1 [dev] de modèle à poids ouverts .

Ses poids sont téléchargeables après acceptation des conditions.

Cependant, sa licence de modèle restreint l'utilisation du modèle et de ses dérivés à des fins non commerciales dans le cadre de la licence standard, une licence distincte étant requise pour toute autre utilisation.

Cela nous donne un exemple clair :

Poids disponibles ?
Oui.

Pouvez-vous les inspecter et les exécuter vous-même ?
Oui, dans le cadre de la licence.

Est-ce que « open weight » signifie automatiquement une utilisation commerciale illimitée du modèle ?
Non.

La licence accorde séparément des droits plus étendus sur les contenus générés selon ses propres termes, ce qui nous rappelle une fois de plus que :

les droits sur le modèle

et :

les droits sur le résultat

peuvent également être différents.

Notre guide GPU pour FLUX.1 [dev] traite donc l'octroi de licence comme un élément central du choix du modèle, et non comme une simple note de bas de page.

Wan 2.2 illustre une autre version permissive

L'équipe Wan publie les modèles Wan 2.2 sous licence Apache 2.0 et déclare ne revendiquer aucun droit sur le contenu généré, tout en rappelant aux utilisateurs qu'ils restent responsables du respect de la licence et des règles applicables.

Cela rend les artefacts du modèle disponibles beaucoup plus faciles à exploiter commercialement qu'un point de contrôle sous licence non commerciale.

Et cela a de l'importance si vous souhaitez :

• héberger le modèle vous-même
• modifier le flux de travail
• créer un service vidéo
• distribuer les modifications du modèle

Mais une fois de plus, une licence Apache sur le modèle publié témoigne des droits couvrant ces artefacts.

Une classification stricte de l'IA Open Source exige toujours de savoir ce qui a été publié d'autre concernant le système d'entraînement.

Notre guide ComfyUI pour Wan 2.2 couvre l'aspect infrastructure.

Ces modèles se situent donc sur un spectre, et non dans deux catégories bien distinctes

Une comparaison plus utile est la suivante :

Le tableau ne contient délibérément pas de colonne simple indiquant :

‍

‍

Open source : oui/non

car le faire correctement selon une définition rigoureuse nécessiterait d'examiner bien plus que la simple licence associée aux fichiers de poids.

C'est précisément là tout l'intérêt.

L'accès par API n'est ni open source ni open weight

Il existe une autre catégorie souvent confondue avec l'ouverture :

l'accès par API.

Supposons que vous puissiez appeler :

POST /v1/chat/completions

et recevez les résultats d'un modèle.

Vous avez accès aux capacités du modèle.

Vous n'avez pas nécessairement accès à :

• ses poids
• son architecture
• son tokenizer
• son code source
• sa méthode d'entraînement
• ses données d'entraînement
• la possibilité de l'exécuter ailleurs

Le fournisseur peut :

• modifier le modèle
• le retirer
• modifier la tarification
• modifier les limites de débit
• restreindre les zones géographiques
• modifier l'API
• supprimer l'accès

Cela peut tout de même constituer un excellent produit.

Cela représente tout simplement un niveau de contrôle différent.

Les modèles à poids ouverts modifient la relation avec l'infrastructure

Lorsque les poids sont disponibles et que la licence autorise l'usage prévu, vous pouvez apporter le modèle à l'infrastructure plutôt que de devoir confier vos données à un fournisseur de modèles imposé.

Cela crée des opportunités de choix.

Vous pouvez décider :

du GPU
du moteur d'inférence
de la région
de la quantification
de la limite de contexte
du modèle de mise à l'échelle
de la couche API

Par exemple, une même famille de modèles peut être déployée via :

• vLLM
• Ollama
• TensorRT-LLM
• SGLang
• un autre moteur d'exécution compatible

Vous pouvez l'héberger sur votre propre machine ou via un service tel que la location de GPU/CPU avec Hivenet, qui prend explicitement en charge les charges de travail d'IA open source et à poids ouverts.

Cette portabilité est l'un des avantages les plus concrets des poids ouverts.

L'auto-hébergement vous donne le contrôle de l'infrastructure, pas de nouveaux droits de licence

Cette distinction est facile à oublier.

Supposons qu'une licence de modèle interdise une utilisation particulière.

Le télécharger sur votre propre GPU ne supprime pas cette restriction.

Pas plus que :

l'exécuter hors ligne

ou :

le quantifier

ou :

le placer derrière votre propre API

La propriété de l'infrastructure et la licence du modèle sont des couches distinctes.

Vous pouvez avoir un contrôle total sur le serveur tout en restant lié par la licence du modèle.

Répondez toujours aux deux questions :

Puis-je techniquement l'exécuter ?

et :

Suis-je autorisé à l'utiliser de cette manière ?

La seconde n'est pas un problème de GPU.

La quantification soulève également la question du modèle dérivé

Supposons que vous preniez un point de contrôle BF16 pour produire une version NVFP4, AWQ, GPTQ ou GGUF.

Vous avez transformé le modèle.

Le résultat technique peut être considérablement plus léger.

La licence originale reste importante.

Pouvez-vous redistribuer la version quantifiée ?

Pouvez-vous l'utiliser à des fins commerciales ?

L'attribution est-elle nécessaire ?

Le dérivé doit-il conserver la licence originale ?

Le nom du modèle doit-il comporter une mention spécifique ?

Ces réponses dépendent des conditions applicables.

Ceci est particulièrement important pour les projets publiant des quantifications prêtes au déploiement plutôt que pour un simple usage privé du modèle.

Les poids ouverts sont particulièrement utiles pour la quantification

Si le modèle n'est disponible que via une API, vous ne pouvez généralement pas décider :

Je souhaite ceci en NVFP4.

Vous utilisez l'implémentation fournie par le prestataire.

Avec des poids accessibles, vous pouvez potentiellement :

• produire un point de contrôle 4 bits
• préserver les couches sensibles en FP8
• comparer la qualité par rapport au BF16
• ajuster la précision du cache KV
• optimiser pour Blackwell
• choisir le moteur de service

C'est ce type de contrôle qui sous-tend des projets tels que HivenetQuant, où des points de contrôle quantifiés orientés déploiement peuvent être publiés pour les modèles dont les licences sous-jacentes autorisent ces dérivés.

Notre explication sur le NVFP4 détaille comment le changement de précision peut permettre de faire passer un modèle d'un matériel multi-GPU à une seule RTX 5090.

Les poids ouverts permettent également une évaluation indépendante

Les modèles accessibles uniquement par API peuvent être évalués.

Mais le fournisseur contrôle l'implémentation du service.

Les poids ouverts permettent aux chercheurs et aux développeurs de faire varier bien plus d'éléments du système :

précision
moteur d'exécution
GPU
taille de lot
échantillonnage
moteur d'attention
contexte
affinage

Cela facilite la question suivante :

Le modèle est-il lent ?

ou :

Cette configuration de service est-elle lente ?

Ce sont deux questions différentes.

Les poids ouverts vous permettent de modifier la seconde sans changer le premier.

Les poids ouverts ne garantissent pas la reproductibilité

Supposons que vous receviez :

final-model.safetensors

Vous pouvez exécuter le modèle finalisé.

Pouvez-vous le recréer à partir de zéro ?

Pas nécessairement.

Pour reproduire le modèle de manière significative, vous pourriez avoir besoin de :

• l'architecture
• des données d'entraînement exactes ou d'informations suffisantes sur les données
• le prétraitement
• la création du tokenizer
• le code d'entraînement
• paramètres de l'optimiseur
• planification du taux d'apprentissage
• initialisation
• mélange de données
• étapes post-entraînement
• données de préférence
• configuration RL
• méthodologie d'évaluation

Un point de contrôle est le résultat du processus.

Ce n'est pas le processus lui-même.

C'est l'une des raisons pour lesquelles l'Open Source AI Definition va au-delà des poids lorsqu'elle décrit la forme privilégiée pour la modification.

Le code source seul ne garantit pas non plus la reproductibilité

Inversons maintenant la situation.

Une entreprise publie :

train.py

mais ne publie pas :

• les poids
• des informations significatives sur les données d'entraînement
• la configuration exacte
• le pipeline post-entraînement

C'est également incomplet.

Vous en savez un peu plus sur la façon dont le système a été conçu.

Il est possible que vous ne soyez toujours pas en mesure d'exécuter, d'inspecter ou de modifier le système entraîné de manière utile.

L'IA ouverte nécessite donc de penser en termes de composants plutôt que de se demander si « la source » existe.

Au fait, que signifie « source » pour un réseau de neurones ?

Pour les logiciels traditionnels, le code source est généralement la forme privilégiée que les humains modifient.

Compilez-le et vous obtenez un exécutable.

Un réseau de neurones entraîné est différent.

Le code d'inférence peut ne faire que quelques centaines de lignes.

Le comportement qui intéresse les gens provient en grande partie de :

milliards de paramètres appris

créés par :

le code d'entraînement
+
les données
+
la puissance de calcul

Si vous publiez la classe Python mais retenez les paramètres appris, vous n'avez pas publié ce que les utilisateurs reconnaissent comme étant le modèle.

Si vous ne publiez que les paramètres appris, vous avez publié le comportement entraîné sans nécessairement publier la manière dont il a été produit.

C'est pourquoi l'application directe de la terminologie logicielle à l'IA devient complexe.

Le terme « modèle ouvert » est utile mais vague

Une autre expression courante est :

modèle ouvert

Cela peut signifier presque tout, allant de :

une publication de recherche entièrement reproductible

à :

des poids téléchargeables après acceptation d'une licence personnalisée

À moins que le contexte ne le précise, ce terme est moins informatif que :

poids sous licence Apache-2.0

modèle sous licence MIT

modèle à poids ouverts sous licence non commerciale

IA Open Source selon l'OSI

Un langage précis est un meilleur langage.

« Code source disponible » est une autre analogie utile

Le logiciel fait déjà la distinction entre :

open source

et :

code source disponible

Un logiciel à code source disponible expose son code mais utilise des conditions qui ne satisfont pas à la définition de l'Open Source.

L'IA a de plus en plus besoin d'un instinct similaire.

La transparence d'un artefact et la liberté juridique d'utilisation sont deux choses distinctes.

Ainsi, un modèle peut être :

transparent mais restreint

ou :

sous licence permissive mais incomplètement documenté

ou :

avec des poids disponibles mais un entraînement fermé

L'ouverture est multidimensionnelle.

L'usage commercial mérite une vérification spécifique

Si votre entreprise prévoit de générer des revenus grâce à un modèle, ne déduisez pas de droits commerciaux de :

disponible sur Hugging Face

ou :

téléchargement gratuit

Vérifiez la licence.

Les exemples actuels démontrent pourquoi :

Qwen3.6
Dépôt de modèle sous licence Apache-2.0.

DeepSeek-R1
Dépôt et poids sous licence MIT, avec une autorisation explicite d'usage commercial pour R1 et des réserves liées aux licences héritées pour certains modèles distillés.

Llama 4
Licence communautaire personnalisée avec politique d'utilisation et conditions commerciales supplémentaires.

FLUX.1 [dev]
Poids ouverts sous une licence de modèle non commerciale pour l'octroi standard.

Wan 2.2
Modèles Apache-2.0.

« Téléchargeable » n'est pas une catégorie de licence.

Les droits de modification sont importants si vous effectuez un réglage fin

Le réglage fin modifie les poids du modèle.

L'entraînement LoRA aussi.

La distillation aussi.

La quantification aussi.

Avant d'effectuer l'une de ces opérations pour une charge de travail en production, répondez à ces questions :

1. Puis-je modifier le modèle ?
2. Puis-je utiliser la modification à des fins commerciales ?
3. Puis-je le redistribuer ?
4. Quelle attribution doit l'accompagner ?
5. Doit-il porter un nom particulier ?
6. Le dérivé hérite-t-il de conditions particulières ?
7. Puis-je utiliser le modèle ou ses sorties pour entraîner un autre modèle ?

Différentes licences répondent à ces questions de différentes manières.

Notre guide de fine-tuning LoRA couvre les aspects techniques.

La licence détermine si ce flux de travail technique est autorisé pour l'usage que vous envisagez.

La redistribution peut être un facteur important, même si vous ne publiez jamais de modèle.

Imaginez que vous développiez une application de bureau contenant un point de contrôle (checkpoint) de modèle.

Vous distribuez alors le modèle.

Ou bien vous créez un conteneur que vous envoyez à vos clients.

Ou encore, vous publiez un point de contrôle quantifié sur Hugging Face.

Ou vous remettez un modèle affiné à un client.

Ces situations diffèrent de l'exécution privée du modèle sur votre propre infrastructure.

Une licence peut les traiter de manière distincte.

C'est une raison supplémentaire pour laquelle la question « Puis-je utiliser ce modèle ? » est trop vague.

Demandez-vous ce que vous comptez réellement faire.

Héberger un modèle sous forme d'API peut également avoir ses propres implications.

Supposons que vous fassiez tourner un modèle à poids ouverts via vLLM et que vous exposiez :

/v1/chat/completions

à vos clients.

Il est possible que vous ne leur donniez jamais les fichiers de poids.

Mais vous utilisez le modèle dans le cadre d'un service commercial.

L'autorisation dépend de la licence.

Une licence de poids non commerciale ne devient pas adaptée à un usage commercial simplement parce que les utilisateurs interagissent via HTTP au lieu de télécharger le point de contrôle.

Le mécanisme de diffusion ne modifie pas les conditions sous-jacentes.

Les modèles à poids ouverts peuvent toujours prendre en charge l'IA privée

C'est là que la disponibilité du modèle devient opérationnellement importante.

Si une licence compatible l'autorise, l'auto-hébergement d'un modèle à poids ouverts permet à une organisation de contrôler :

• où l'inférence est exécutée
• où les invites sont traitées
• quelle version du modèle est déployée
• quand les mises à niveau ont lieu
• quels journaux sont conservés
• quel logiciel de service est utilisé
• quels chemins réseau sont disponibles

Cela peut s'avérer utile pour l'IA privée, les charges de travail réglementées, les données internes et les déploiements sensibles à la juridiction.

Hivenet prend en charge les charges de travail open source et à poids ouverts via du calcul GPU/CPU autogéré et des chemins d'inférence gérés.

Mais la confidentialité et la souveraineté sont des propriétés de l'ensemble du déploiement, et non de la licence du modèle seule.

Un modèle sous licence Apache envoyé à une API tierce laisse toujours vos choix d'infrastructure entre les mains de ce fournisseur d'API.

L'open source et la souveraineté sont liés mais ne sont pas identiques

Les modèles ouverts permettent de réduire la dépendance envers un fournisseur unique.

Cela peut améliorer :

• la portabilité
• le pouvoir de négociation
• la capacité d'inspection
• la facilité de déploiement
• le choix de l'infrastructure

Cependant, un modèle ouvert exécuté sur une infrastructure que vous ne contrôlez pas peut tout de même engendrer :

• des questions de juridiction
• des préoccupations liées au transfert de données
• des dépendances de service
• des dépendances d'observabilité
• des dépendances de disponibilité

De même, un modèle propriétaire exécuté entièrement au sein d'une infrastructure contrôlée peut répondre à certaines exigences de souveraineté tout en échouant sur d'autres.

Ainsi :

modèle ouvert

et :

IA souveraine

ne doivent pas non plus être utilisés comme des synonymes.

Chacun résout une partie du problème de contrôle.

Une liste de contrôle utile pour l'ouverture

Avant de qualifier un modèle d'IA d'« open source », ne vous contentez pas de vérifier si vous pouvez le télécharger.

1. Les poids sont-ils disponibles ?

Pouvez-vous obtenir les paramètres entraînés ?

2. Le modèle peut-il être utilisé à n'importe quelle fin ?

Recherchez les restrictions commerciales, de domaine d'application, d'échelle ou d'utilisation acceptable.

Si vous vous référez à la définition de l'OSI, ce point est particulièrement important, car l'absence de restriction d'usage est l'une des libertés fondamentales requises.

3. Pouvez-vous le modifier ?

La licence autorise-t-elle le réglage fin (fine-tuning), la quantification, l'adaptation et d'autres dérivés ?

4. Pouvez-vous le redistribuer ?

Que se passe-t-il si vous publiez le point de contrôle original ou une version modifiée ?

5. Le code source pertinent est-il disponible ?

Ne vous limitez pas à un simple script de démonstration d'inférence.

Qu'en est-il de :

• l'entraînement
• le prétraitement
• l'évaluation
• l'architecture
• le tokenizer
• le post-entraînement

6. Les données d'entraînement sont-elles suffisamment documentées ?

Une personne qualifiée peut-elle comprendre ce qui a été utilisé et comment cela a été assemblé ?

7. Les artefacts sont-ils soumis à des conditions d'ouverture appropriées ?

Un dépôt Git public peut toujours contenir des licences restrictives.

8. Existe-t-il des licences héritées ?

Un modèle affiné ou distillé peut hériter des obligations ou des restrictions d'un modèle de base.

9. Existe-t-il des politiques d'utilisation distinctes ?

La licence d'un modèle peut intégrer des conditions supplémentaires par renvoi.

10. Quels droits s'appliquent aux résultats ?

Ne présumez pas que les droits sur le modèle et sur ses résultats sont identiques.

Cette liste de contrôle en dix points vous en dit bien plus qu'un simple badge :

OUVERT

Comment décrire un modèle avec précision

Si vous rédigez de la documentation, des travaux de recherche ou du contenu marketing, utilisez la description la plus précise et la plus restreinte possible.

Au lieu de :

Nous utilisons des modèles d'IA open source.

envisagez :

Nous utilisons des modèles d'IA open source et à poids ouverts.

Ou, lorsque vous faites référence à un modèle spécifique :

Les poids de Qwen3.6 sont disponibles sous licence Apache 2.0.

Ou :

FLUX.1 [dev] est un modèle à poids ouverts publié sous la licence non commerciale de Black Forest Labs.

Ou :

Les poids de Llama sont disponibles sous la licence Llama Community License de Meta.

Ces phrases fournissent aux lecteurs des informations exploitables.

« Modèle d'IA ouvert » ne le fait souvent pas.

Quels critères privilégier lors du choix d'un modèle ?

L'ouverture est une dimension parmi d'autres dans la sélection d'un modèle.

Une décision de mise en production nécessite également :

la qualité
la licence
les exigences matérielles
la latence
le débit
le contexte
la prise en charge de la quantification
la prise en charge du déploiement
la prise en charge du réglage fin
la maturité opérationnelle

Un modèle sous licence permissive qui offre de piètres performances pour votre tâche n'est pas un bon choix de déploiement.

Un modèle brillant dont la licence vous interdit l'usage n'est pas non plus une bonne solution de déploiement.

Et un modèle à poids ouverts de 400 milliards de paramètres nécessitant une infrastructure bien au-delà de votre budget n'est pas utile simplement parce que vous pouvez le télécharger.

La liberté des modèles doit se confronter à la réalité opérationnelle.

Les poids ouverts sont précieux car ils créent des options

L'argument le plus solide en faveur des poids ouverts n'est pas idéologique.

Il est pratique.

Si les poids et la licence le permettent, vous pouvez choisir :

modèle
↓
précision
↓
matériel
↓
moteur d'exécution
↓
région
↓
API

au lieu d'accepter ces six éléments comme un service fournisseur indissociable.

Vous pouvez exécuter un modèle quantifié plus petit sur une seule RTX 5090.

Vous pouvez répartir un modèle 70B sur plusieurs GPU avec le parallélisme de tenseurs.

Vous pouvez modifier la précision du cache KV .

Vous pouvez utiliser PagedAttention et le traitement par lots continu pour le déploiement en production.

Vous pouvez affiner un modèle avec LoRA.

Cette capacité à séparer le modèle de l'infrastructure est l'un des avantages les plus importants offerts par les poids ouverts.

Mais les poids ouverts ne constituent pas l'aboutissement ultime de l'ouverture

La publication des poids fournit à la communauté l'artefact entraîné.

Un processus de développement réellement ouvert peut offrir bien plus aux utilisateurs :

• la possibilité de comprendre comment il a été créé
• la possibilité de reproduire une grande partie de celui-ci
• la possibilité d'étudier les choix de données
• la possibilité de modifier le processus d'entraînement
• la possibilité de distribuer des versions améliorées
• la liberté légale d'effectuer ces actions à quelque fin que ce soit

C'est pourquoi la distinction entre l'IA à poids ouverts et l'IA open source mérite d'être préservée.

« Poids ouverts » n'est pas une insulte.

Cela décrit quelque chose de réellement utile.

Qualifier cela d'open source alors que le reste des exigences est inconnu revient simplement à perdre une information importante.

FAQ sur l'IA à poids ouverts vs l'IA open source

Qu'est-ce qu'un modèle d'IA à poids ouverts ?

Un modèle à poids ouverts rend les paramètres du modèle entraîné accessibles à tous. La licence détermine ce que les utilisateurs sont autorisés à faire avec ces poids.

Qu'est-ce qu'un modèle d'IA open source ?

Selon la définition de l'IA open source de l'Open Source Initiative, une IA open source doit offrir aux utilisateurs la liberté d'utiliser, d'étudier, de modifier et de partager le système à quelque fin que ce soit, et fournir un accès à la forme privilégiée pour la modification, incluant les informations sur les données pertinentes, le code et les paramètres.

Les modèles à poids ouverts sont-ils open source ?

Pas nécessairement. La publication des poids ne satisfait qu'une partie des exigences de la définition de l'IA open source de l'OSI.

Les modèles open source sont-ils toujours à poids ouverts ?

Selon la définition de l'OSI, les paramètres font partie de la forme privilégiée pour la modification ; par conséquent, un modèle d'IA open source doit rendre les paramètres pertinents disponibles sous des conditions appropriées.

« Poids ouverts » signifie-t-il gratuit ?

Cela signifie généralement que les paramètres sont accessibles sous licence, mais cette licence peut comporter des restrictions. La disponibilité ne garantit pas une utilisation commerciale ou une redistribution sans restriction.

« Poids ouverts » signifie-t-il que l'utilisation commerciale est autorisée ?

Non. FLUX.1 [dev], par exemple, se décrit explicitement comme un modèle à poids ouverts mais utilise une licence non commerciale pour l'octroi du modèle standard.

Un modèle à poids ouverts peut-il avoir une licence propriétaire ?

Oui. Un développeur peut rendre des poids accessibles au public sous sa propre licence personnalisée tout en conservant la propriété et en imposant des conditions d'utilisation.

Llama est-il open source ?

Les poids et les ressources associées à Llama sont disponibles sous la licence personnalisée Llama Community License de Meta. Les conditions de Llama 4 incluent une politique d'utilisation acceptable et des conditions commerciales spécifiques pour les organisations dépassant un seuil de 700 millions d'utilisateurs actifs mensuels (MAU). Selon une définition exigeant une utilisation sans restriction à toute fin, cela diffère sensiblement d'une licence open source conventionnelle.

DeepSeek-R1 est-il open source ?

DeepSeek décrit R1 comme étant open source et publie son dépôt ainsi que les poids du modèle sous licence MIT, avec de larges autorisations de modification et d'utilisation commerciale. Déterminer si une définition plus stricte de l'IA open source au niveau du système s'applique nécessite d'examiner l'ensemble des artefacts d'entraînement et des informations sur les données publiés, et non la licence des poids seule.

Qwen est-il open source ?

Les dépôts actuels de Qwen3.6, tels que Qwen3.6-27B-FP8, publient les artefacts du modèle sous licence Apache 2.0. Cela confère de larges droits sur ces artefacts, mais la classification de l'IA open source au niveau du système nécessite d'aller au-delà de la simple licence des poids.

FLUX.1 [dev] est-il open source ?

Black Forest Labs décrit FLUX.1 [dev] comme étant à poids ouverts (open-weight). Sa licence de modèle standard restreint l'utilisation du modèle et de ses dérivés à des fins non commerciales, sauf obtention de droits distincts ; le terme « à poids ouverts » est donc plus précis.

Wan 2.2 est-il open source ?

Wan 2.2 publie ses modèles sous licence Apache 2.0. Une classification plus large de l'IA open source au niveau du système nécessite toujours de prendre en compte les autres artefacts et informations sur les données spécifiés par la définition.

La licence Apache 2.0 rend-elle un modèle d'IA open source ?

Apache 2.0 est une licence de logiciel open source approuvée par l'OSI, mais l'appliquer aux poids d'un modèle ne démontre pas en soi que l'ensemble du système d'IA répond à la définition de l'IA open source. La définition au niveau du système prend également en compte le code, les paramètres et les informations sur les données d'entraînement.

La licence MIT rend-elle un modèle d'IA open source ?

MIT est une licence de logiciel open source, mais la même distinction s'applique. Une licence permissive sur des poids ou du code publiés ne permet pas de savoir si tous les composants requis par une définition de l'IA open source ont été rendus publics.

Un modèle d'IA open source doit-il publier l'intégralité de son jeu de données d'entraînement ?

Pas nécessairement. La définition de l'OSI exige des informations suffisamment détaillées sur les données, incluant leur provenance, leur traitement, leur filtrage et des listes des données accessibles. Elle tient compte du fait que certaines données d'entraînement ne peuvent pas être redistribuées en tant que telles.

Les poids d'un modèle sont-ils du code source ?

Non. Les poids d'un modèle sont des paramètres numériques appris. Le code source décrit les opérations logicielles. Les deux peuvent constituer des éléments importants d'un système d'IA.

Puis-je exécuter un modèle à poids ouverts localement ?

En général, oui, si vous disposez du matériel compatible et que la licence autorise l'usage prévu. Les exigences matérielles peuvent toutefois rendre les modèles à poids ouverts volumineux peu pratiques sur un ordinateur standard.

Puis-je héberger moi-même un LLM à poids ouverts ?

Oui, lorsque la licence le permet et que vous disposez d'une infrastructure suffisante. L'auto-hébergement vous permet de choisir le GPU, la pile de service, la région, la configuration réseau et la version du modèle.

Puis-je affiner un modèle à poids ouverts ?

Techniquement, souvent oui. Sur le plan juridique, vérifiez la licence du modèle pour confirmer que la modification et l'usage prévu du dérivé sont autorisés.

Puis-je quantifier un modèle à poids ouverts ?

Techniquement, les poids accessibles peuvent souvent être quantifiés. La redistribution ou l'utilisation commerciale du point de contrôle résultant dépend toujours de la licence du modèle sous-jacent.

Une API d'IA est-elle à poids ouverts ?

Non, à moins que le fournisseur ne publie séparément les poids du modèle. L'accès par API vous donne accès à l'inférence, pas nécessairement à l'artefact du modèle.

Pourquoi la différence entre open source et poids ouverts est-elle importante ?

Parce qu'elle détermine ce que vous pouvez inspecter, modifier, reproduire, redistribuer, auto-héberger et utiliser commercialement. Elle affecte également la facilité avec laquelle vous pouvez déplacer le modèle entre différents fournisseurs d'infrastructure plutôt que de dépendre d'une seule API hébergée.

Quel terme dois-je utiliser si je ne suis pas sûr ?

Si vous savez seulement que les poids du modèle sont disponibles, appelez-le à poids ouverts. Utilisez IA open source lorsque vous pouvez établir quelle définition vous appliquez et que la version publiée la respecte réellement.

‍