Vous avez probablement entendu dire que l'open source est synonyme de liberté totale. Pour l'intelligence artificielle générative, c'est un mythe dangereux qui peut coûter cher à votre entreprise. Utiliser un modèle comme LLaMA ou Mistral n'est pas aussi simple que de télécharger un fichier et de cliquer sur « exécuter ». Chaque ligne de code, chaque paramètre ajusté et chaque sortie générée sont soumis à des contrats juridiques stricts.
En juillet 2026, la frontière entre l'expérimentation technique et la violation de propriété intellectuelle est plus floue que jamais. Les entreprises ne se contentent plus d'utiliser ces outils ; elles les intègrent dans leurs produits financiers, médicaux ou juridiques. La question n'est plus seulement « cela fonctionne-t-il ? », mais « avons-nous le droit de le faire ainsi ? » Comprendre les licences, l'attribution et les œuvres dérivées n'est pas une formalité administrative, c'est la base même de la viabilité de votre projet d'IA.
Le paysage actuel des licences pour l'IA générative
Contrairement aux logiciels traditionnels où le code est visible et modifiable facilement, les modèles d'IA (LLMs) ajoutent une couche de complexité : les poids du modèle. Ces données numériques massives constituent l'esprit de l'IA. La manière dont vous pouvez utiliser ces poids dépend entièrement de la licence attachée au moment du téléchargement.
Aujourd'hui, trois grandes familles de licences dominent le marché de l'IA open source :
- Apache 2.0 : C'est la norme de facto pour les entreprises sérieuses. Elle permet l'utilisation commerciale sans restriction majeure, tant que vous respectez l'attribution. Des acteurs majeurs comme Mistral AI ou Google avec Gemma utilisent cette approche pour rassurer les clients.
- MIT / BSD-3 : Très permissives, elles imposent peu de contraintes autres que la mention de l'auteur original. Elles sont idéales pour les projets rapides mais offrent moins de protections contre les brevets que l'Apache 2.0.
- GPL (GNU General Public License) : Souvent appelée licence « virale », elle exige que si vous modifiez le logiciel et le redistribuez, votre version doit également être open source sous GPL. Pour une startup souhaitant garder son algorithme propriétaire, c'est généralement un non-non.
Il existe aussi des licences spécifiques à l'IA, comme la Responsible AI License utilisée par Meta pour certaines versions de LLaMA. Ces licences interdisent souvent l'utilisation du modèle pour des activités illégales ou nuisibles, introduisant une clause éthique contraignante absente des licences logicielles classiques.
Licence Apache 2.0 : Le standard de confiance pour l'entreprise
Pourquoi l'Licence Apache 2.0 est-elle devenue le choix privilégié des géants technologiques ? Parce qu'elle offre un équilibre parfait entre ouverture et protection juridique. Si vous déployez Mistral ou Mixtral dans votre infrastructure interne pour automatiser le service client, cette licence vous couvre largement.
Cependant, attention aux détails. L'Apache 2.0 impose deux obligations claires :
- L'attribution : Vous devez inclure une copie de la licence originale et citer les contributeurs initiaux. Cela signifie que si vous vendez un produit basé sur Mistral, vos mentions légales doivent refléter cette origine.
- La notification des modifications : Si vous changez quelque chose dans le code ou les scripts associés au déploiement, vous devez documenter ces changements de manière visible.
Un avantage crucial de cette licence réside dans sa clause de brevet. Elle protège explicitement les utilisateurs contre les poursuites en matière de brevets de la part des contributeurs. Dans un domaine où les brevets d'IA se multiplient à une vitesse effrénée, cette sécurité juridique vaut de l'or.
| Licence | Usage Commercial | Obligation d'Open Sourcer (Copyleft) | Protection Brevets |
|---|---|---|---|
| Apache 2.0 | Oui | Non | Oui (Claire) |
| MIT | Oui | Non | Non explicite |
| GPL v3 | Oui* | Oui (Si redistribution) | Oui |
| Propriétaire (ex: LLaMA ancien) | Souvent Non ou Limité | N/A | Variable |
*L'usage commercial est possible avec GPL, mais la redistribution du logiciel modifié oblige à ouvrir le code source, ce qui peut nuire au secret industriel.
Gérer les œuvres dérivées et le fine-tuning
C'est ici que la plupart des équipes techniques font des erreurs. Qu'est-ce qu'une œuvre dérivée dans le contexte de l'IA ? Si vous prenez un modèle pré-entraîné comme Gemma de Google et que vous l'affinez (fine-tuning) sur vos propres données clients pour créer un assistant juridique spécialisé, avez-vous créé une œuvre dérivée ? Juridiquement, oui. Vous avez modifié les poids du modèle original.
Sous une licence Apache 2.0, cela pose peu de problèmes tant que vous ne redistribuez pas le modèle lui-même publiquement. Mais si vous utilisez une licence copyleft comme la GPL, le fait de distribuer votre application utilisant ce modèle finetuné pourrait vous obliger à publier le code de votre application entière. C'est un risque majeur pour les startups.
Considérez le cas de OpenHermes développé par Nous Research. Ce modèle, excellent pour le traitement de scripts complexes, autorise l'usage commercial mais exige une attribution rigoureuse. Si vous intégrez OpenHermes dans un outil SaaS vendu à des avocats, vous devez garantir que l'utilisateur final sait qu'il utilise une technologie dérivée d'OpenHermes. Oublier cette étape peut entraîner des réclamations de retrait de contenu (takedown notices) ou pire, des litiges.
Une bonne pratique consiste à isoler l'IA. Au lieu de modifier le modèle central, utilisez-le via une API interne ou un conteneur Docker séparé. Cela permet de traiter les données sans nécessairement créer une œuvre dérivée complexe du point de vue du code applicatif, bien que la frontière légale reste débattue devant les tribunaux.
Attribution : Plus qu'un simple crédit
L'attribution n'est pas une formalité cosmétique. C'est une exigence contractuelle. Pour respecter correctement l'attribution dans un environnement d'entreprise :
- Maintenez un registre des composants tiers utilisés dans votre pile IA (BOM - Bill of Materials).
- Incluez les fichiers de licence originaux dans vos distributions logicielles.
- Assurez-vous que les notifications de modification soient visibles, par exemple dans les paramètres « À propos » de votre application.
Prenez l'exemple de h2oGPT, une plateforme open source combinant LLM et bases de documents. En l'utilisant, vous devez attribuer H2O.ai tout en gérant les licences des modèles LLM que vous y chargez. Une négligence ici peut invalider votre propre licence d'utilisation.
Sécurité des données vs Conformité Licence
Beaucoup d'entreprises choisissent l'open source pour éviter d'envoyer leurs données confidentielles vers les API cloud de OpenAI ou Anthropic. C'est un argument valide pour le RGPD (GDPR) ou HIPAA. Cependant, choisir un modèle open source ne dispense pas de vérifier sa provenance.
Les modèles légers comme Gemma 2B sont parfaits pour tourner localement sur du matériel abordable, réduisant les coûts et améliorant la latence. Mais assurez-vous que la version que vous téléchargez provient d'une source officielle (comme Hugging Face vérifié ou le site de Google). Les forks non officiels peuvent contenir des portes dérobées ou des violations de licence cachées.
De plus, certains modèles spécialisés, comme les variantes japonaises de LLaMA développées par Rinna, interdisent parfois explicitement l'usage commercial. Vérifier ces restrictions avant de lancer un projet international est critique. Une erreur de licence peut bloquer votre expansion géographique instantanément.
Alternatives commerciales et compromis
L'open source n'est pas toujours la meilleure solution de conformité. Pour les organisations disposant de budgets importants, les solutions commerciales comme Microsoft Copilot (intégré à M365) offrent une garantie de protection des données entreprise. Depuis septembre 2024, Microsoft assure que les données utilisées pour entraîner Copilot restent cloisonnées et ne servent pas à améliorer les modèles publics. C'est un niveau de conformité « clé en main » que l'open source ne fournit pas naturellement.
Le choix se résume souvent à ceci : voulez-vous la flexibilité totale et la maîtrise technique (open source avec gestion manuelle de la conformité) ou voulez-vous la tranquillité d'esprit juridique et la responsabilité fournisseur (commercial) ? Il n'y a pas de réponse universelle, seulement des arbitrages stratégiques.
Puis-je vendre un produit basé sur un modèle LLaMA ?
Oui, pour les versions récentes comme LLaMA 3, Meta autorise l'usage commercial. Cependant, vous devez respecter les conditions de leur licence spécifique, qui peut inclure des limitations basées sur le nombre d'utilisateurs mensuels actifs de votre application. Toujours lire la licence exacte fournie lors du téléchargement.
Quelle est la différence entre Apache 2.0 et MIT pour l'IA ?
Les deux permettent l'usage commercial et ne sont pas copyleft. La principale différence est que l'Apache 2.0 offre une protection explicite contre les litiges de brevets, ce qui est crucial dans l'industrie de l'IA où les brevets sont nombreux. Le MIT est plus court et plus simple, mais offre moins de garanties juridiques avancées.
Dois-je rendre mon code open source si j'utilise un modèle GPL ?
Seulement si vous redistribuez le logiciel modifié. Si vous utilisez le modèle GPL uniquement en interne dans votre entreprise sans le vendre ni le distribuer à des tiers, vous n'êtes généralement pas obligé d'ouvrir votre code. Cependant, dès que vous livrez le logiciel à un client, l'obligation de copyleft s'applique potentiellement à l'ensemble de l'application liée au modèle.
Comment gérer l'attribution dans une application SaaS ?
Créez une page dédiée « Mentions Légales » ou « Composants Tiers » accessible depuis les paramètres de votre application. Listez chaque modèle utilisé (ex: Mistral, Gemma), son auteur, et un lien vers sa licence. Ne cachez pas ces informations ; la transparence est une exigence de nombreuses licences permissives.
Est-ce que le fine-tuning crée toujours une œuvre dérivée ?
Juridiquement, c'est un sujet gris. Modifier les poids d'un modèle est considéré comme une modification substantielle de l'œuvre originale. La plupart des experts recommandent de traiter le modèle finetuné comme une œuvre dérivée et de respecter les obligations de la licence originale (attribution, partage des modifications si copyleft) pour minimiser les risques.