Modèles IA « ouverts » : la licence peut bloquer votre croissance commerciale

Un modèle d’IA qualifié d’« ouvert » peut être utilisé dans un produit commercial uniquement si la licence de sa version précise autorise votre mode d’exploitation. L’accès aux poids ou au code ne garantit ni le droit de redistribuer le modèle, ni l’absence de conditions susceptibles de bloquer le déploiement lorsque l’entreprise grandit.

Avant l’intégration, traduisez donc le texte de licence en décisions concrètes : hébergement ou livraison au client, modification et publication d’un dérivé, attribution, seuils de revenus ou d’audience, droits de brevet et disponibilité des éléments nécessaires pour changer de modèle. La réponse dépend de l’artefact, de sa version et de ce que votre produit en fera.

« Ouvert » ne décrit pas à lui seul vos droits

Le terme peut désigner des poids téléchargeables, du code d’inférence public, une licence autorisant la modification ou un ensemble plus complet comprenant le code d’entraînement et des informations sur les données. Ces situations n’accordent pas nécessairement les mêmes libertés juridiques ni la même capacité technique à maintenir un dérivé.

Séparez deux questions. La première est contractuelle : pouvez-vous utiliser, modifier, héberger et redistribuer chaque composant dans les conditions prévues ? La seconde est opérationnelle : disposez-vous du code, des paramètres et d’informations suffisamment précises sur l’entraînement pour comprendre le système, le modifier ou le remplacer ? Une réponse positive à l’une ne résout pas automatiquement l’autre.

Vérifiez également les textes incorporés par référence, comme une politique d’utilisation acceptable. Une autorisation commerciale peut rester conditionnée au respect de cette politique, même si les poids sont librement accessibles au téléchargement.

La vérification à effectuer avant l’intégration

Conservez avec la décision une copie de la licence, la fiche officielle du modèle, la version téléchargée et les politiques annexes. Une page de présentation ou la mention « open model » dans un dépôt ne remplace pas le texte qui accorde effectivement les droits.

1. Identifier tous les artefacts. Relevez le nom et la version du modèle, puis distinguez les poids, le code d’inférence, le tokenizer, les bibliothèques, les jeux de données et les outils d’adaptation. Ils peuvent relever de licences différentes.
2. Décrire l’exploitation prévue. Précisez si le modèle restera sur vos serveurs, si le client recevra un logiciel qui l’embarque, si les poids seront livrés ou si un modèle dérivé sera publié. Un droit d’utilisation ne suffit pas à établir un droit de redistribution.
3. Relever les obligations de livraison. Cherchez la copie de licence à joindre, les fichiers NOTICE, les mentions d’attribution, les avis de modification et les règles de nommage. Placez chaque obligation dans le processus de publication correspondant.
4. Calculer les seuils sur le bon périmètre. Notez la métrique, la période, la date d’appréciation et les entités incluses : société, affiliés, groupe ou produits exploités pour son compte.
5. Examiner brevets et marques séparément. Une licence de droit d’auteur ne confère pas nécessairement un droit général sur les marques ou tous les brevets pertinents. Repérez aussi les clauses qui mettent fin à une concession en cas de contentieux.
6. Mesurer la dépendance technique. Inventoriez le code d’entraînement et d’inférence, les paramètres, les méthodes de filtrage et les informations sur les données. Si ces éléments manquent, estimez le coût d’une adaptation ou d’une migration avant de retenir le modèle.

Apache 2.0 et MIT modifiée : deux trajectoires commerciales

Le texte de la licence Apache 2.0 accorde notamment des droits de reproduction, de création de dérivés, de sous-licence et de distribution. La redistribution reste soumise à plusieurs conditions : fournir la licence, signaler les fichiers modifiés, conserver les avis pertinents et reproduire les attributions du fichier NOTICE lorsqu’il existe.

Apache 2.0 comprend aussi une concession de brevet limitée aux revendications des contributeurs nécessairement enfreintes par leurs contributions, seules ou combinées à l’œuvre concernée. Ce n’est donc pas une garantie générale contre tout risque de brevet. La licence ne donne pas non plus un droit général d’utiliser les marques du concédant.

Le nom de la famille de licence ne suffit toutefois pas. Les conditions de Mistral AI indiquent que la plupart de ses modèles ouverts sont proposés sous Apache 2.0, mais que certains relèvent d’une licence MIT modifiée. Pour ces derniers, une entreprise dont les revenus mensuels dépassent 20 millions de dollars doit obtenir une licence commerciale ou utiliser le modèle via Mistral Studio.

Il faut donc vérifier la fiche du modèle effectivement choisi, et non extrapoler la licence d’un autre modèle du même éditeur. Même sous le seuil, l’architecture doit anticiper le coût et le délai d’une licence commerciale ou d’un remplacement si les revenus progressent.

Llama 4 : un seuil calculé à la date de sortie

La licence communautaire de Llama 4, effective depuis le 5 avril 2025, accorde des droits limités d’utilisation, de reproduction, de distribution, de création de dérivés et de modification. Lors de certaines redistributions, elle impose notamment de fournir une copie de l’accord, d’afficher la mention « Built with Llama » et de conserver l’avis d’attribution prévu dans les copies des matériaux.

Sa condition commerciale ne se déclenche pas simplement le jour où l’application intégrant Llama atteint une audience donnée. Si, à la date de sortie de la version de Llama 4, les produits ou services proposés par ou pour le licencié ou ses affiliés comptaient plus de 700 millions d’utilisateurs actifs mensuels pendant le mois civil précédent, une licence distincte doit être demandée à Meta. Les droits de l’accord ne peuvent pas être exercés tant que Meta ne les a pas expressément accordés.

Le périmètre inclut donc davantage que la seule application qui utilisera le modèle et peut concerner les affiliés. Pour une société appartenant à un grand groupe, le calcul doit être validé avant l’intégration, avec la date de sortie de la version conservée dans le dossier.

Faire survivre la décision à la croissance

La revue doit produire une fiche rattachée à la version déployée : usages autorisés, composants redistribués, obligations d’attribution, politiques annexes, seuils, périmètre de calcul et éléments techniques disponibles. Elle doit aussi indiquer l’événement qui impose une nouvelle analyse, par exemple un changement de modèle, une fusion-acquisition ou l’approche d’un seuil de revenus.

Pour chaque condition susceptible de devenir incompatible, définissez à l’avance l’alternative : négociation d’une licence commerciale, passage par le service hébergé de l’éditeur ou migration vers un autre modèle. Isoler le modèle derrière une interface interne et conserver des tests de remplacement réduit le coût technique de cette décision.

Cette méthode ne transforme pas une revue produit en avis juridique. Elle permet cependant d’écarter avant le déploiement les choix dont les droits, les obligations ou les seuils ne correspondent déjà pas au produit — et d’éviter qu’une licence acceptable au démarrage devienne ensuite un frein commercial.