Modèles open-source / poids ouverts : c'est quoi, et pourquoi le mot « open » est piégé

On te vend « l’IA open-source » comme une évidence morale : ouvert = bien, fermé = mal. Sauf que le mot « open » recouvre trois réalités différentes qu’on mélange en permanence, et cette confusion coûte cher quand tu choisis sur quoi bâtir ton produit. Télécharger Llama ne te donne pas la recette pour le refaire. Faire tourner Mistral chez toi ne veut pas dire que c’est gratuit. Et la licence « ouverte » que tu n’as pas lue t’interdit peut-être l’usage exact que tu vises. Cette page tranche les trois cas — poids ouverts, vraiment open-source, propriétaire — et répond à la seule question qui compte pour un founder : qu’est-ce que ça change concrètement pour ton coût, ton contrôle et tes données ?

Les trois cas qu’on confond tout le temps

Avant tout choix, il faut séparer trois choses que le marketing fond dans un seul mot. Un LLM, c’est trois objets distincts : les poids (les milliards de paramètres ajustés à l’entraînement), le code qui sert à l’entraîner et le faire tourner, et les données sur lesquelles il a appris. Selon ce qu’on te donne, tu es dans un cas radicalement différent.

1. Poids ouverts (open-weights). On te donne les poids, point. Tu télécharges un fichier de plusieurs gigaoctets, tu le charges sur ta machine ou ton serveur, et le modèle tourne. C’est le cas de Llama (Meta), Mistral (français), DeepSeek (chinois), Gemma (Google). Tu peux l’utiliser, le fine-tuner, l’héberger. Mais tu ne sais pas exactement avec quelles données il a été entraîné, et tu ne pourrais pas le reproduire de zéro.

2. Vraiment open-source. On te donne les poids plus le code d’entraînement plus la description (idéalement l’accès) aux données. Là, quelqu’un d’autre pourrait, en théorie, refaire le modèle. C’est rare. Des projets comme OLMo (Allen Institute) ou la lignée Pythia jouent ce jeu. La quasi-totalité des modèles qu’on appelle « open-source » dans la presse n’en sont pas — ce sont des open-weights.

3. Propriétaire (fermé). Tu n’as ni poids, ni code, ni données. Tu y accèdes uniquement à travers une API : tu envoies du texte, tu reçois une réponse, le modèle reste chez le fournisseur. C’est GPT (OpenAI), Claude (Anthropic), Gemini (Google, côté API). Tu loues l’intelligence, tu ne la possèdes pas.

La ligne de partage opérationnelle est nette : dans les cas 1 et 2, le modèle peut tourner sur ta machine ; dans le cas 3, jamais. Tout le reste découle de là.

Pourquoi « open-weights » n’est pas « open-source » (la nuance qui fâche)

C’est le point que 90 % des articles ratent, et il a déclenché une vraie bagarre de définitions dans le secteur.

Un logiciel open-source classique, c’est du code source que tu peux lire, modifier, recompiler et redistribuer. La transparence est totale : tu vois comment c’est fait. Avec un modèle à poids ouverts, tu reçois le résultat de l’entraînement — un gros tas de nombres — mais pas la recette. La métaphore juste : « Open-weights », ce n’est pas « open-source » : on te donne le moteur, pas les plans de l’usine ni la liste des ingrédients. Tu peux faire rouler la voiture, tu ne peux pas la reconstruire, et tu ne sais pas exactement ce qu’il y a dans le réservoir.

Pourquoi ça compte au-delà de la sémantique :

• Tu ne peux pas auditer les données. Un modèle dont tu ignores le corpus d’entraînement peut porter des biais, des données sous copyright ou des informations personnelles que tu ne verras jamais. « Ouvert » ne veut pas dire « transparent ».
• Tu ne peux pas le reproduire. Si Meta arrête Llama demain, tu gardes les poids déjà téléchargés, mais personne ne peut régénérer la suite. La dépendance au fournisseur est réduite, pas supprimée.
• Le mot est devenu un argument marketing. En octobre 2024, l’Open Source Initiative — l’organisme qui fait autorité sur la définition d’« open source » — a publié sa définition de l’« IA open source » (version 1.0), qui exige un accès suffisant aux informations sur les données d’entraînement pour pouvoir reconstruire le modèle. Sous ce critère, la plupart des modèles vendus comme « open source » (Llama en tête) ne le sont pas. D’où la bataille.

Le terme honnête pour Llama, Mistral et DeepSeek est donc « poids ouverts » (open-weights), pas « open-source ». Si quelqu’un te vend « notre IA open-source » sans pouvoir te montrer les données d’entraînement, traduis mentalement par « open-weights » et ajuste tes attentes.

Qui est qui : Llama, Mistral, DeepSeek vs GPT, Claude

La carte du terrain, sans le hype.

Côté poids ouverts (téléchargeables, hébergeables) :

• Llama (Meta) — la famille qui a popularisé l’open-weights grand public. Licence « communautaire » maison, pas une licence open-source classique : usage très large mais avec des clauses (notamment un seuil au-delà duquel les très gros acteurs doivent demander une licence).
• Mistral (Paris) — l’acteur français, apprécié pour des modèles compacts et performants. Une partie de ses modèles sort sous licence Apache 2.0 (vraiment permissive, usage commercial libre), d’autres sous licence plus restrictive. Ça dépend du modèle.
• DeepSeek (Chine) — a marqué le début 2025 en sortant son modèle de raisonnement DeepSeek-R1 (janvier 2025) à poids ouverts sous licence MIT, très performant, en bousculant l’idée qu’il fallait des budgets démesurés. Point de vigilance évident pour certains usages : provenance et hébergement des données si tu utilises leur API plutôt que tes propres poids.

Côté propriétaire (API uniquement) :

• GPT (OpenAI), Claude (Anthropic), Gemini (Google) — souvent en tête sur les tâches les plus exigeantes, accessibles seulement via API. Tu paies au token, tu n’héberges rien, le fournisseur gère l’infra et les mises à jour.

La nuance qui évite l’erreur de débutant : « propriétaire » ne veut pas dire « moins bon » et « ouvert » ne veut pas dire « libre de droits ». Les meilleurs modèles propriétaires gardent souvent une avance sur les tâches difficiles, et plusieurs modèles « ouverts » traînent des licences qui restreignent l’usage commercial. Le clivage ouvert/fermé est un axe stratégique du secteur, pas un classement de qualité.

Ce que ça change vraiment pour un founder (coût, contrôle, privacy)

Voilà le cœur du sujet. Quatre arbitrages concrets, pas une posture idéologique.

Le coût. L’API a un coût marginal : tu paies chaque appel au token, ça grimpe linéairement avec ton volume. Les poids ouverts ont un coût fixe : tu loues ou achètes des GPU, et une fois l’infra en place, chaque requête supplémentaire coûte presque rien. Conséquence : à faible volume, l’API est imbattable (zéro infra à gérer) ; à très gros volume et requêtes prévisibles, le self-hosting peut diviser la facture. Mais attention au calcul caché — un GPU qui tourne H24 te coûte même quand personne n’appelle, et l’économie d’inférence est un vrai métier (on l’a creusé dans l’édition Cerebras vs Nvidia).

Le contrôle. Avec l’API, le fournisseur peut déprécier un modèle, changer ses prix, modifier son comportement ou ses filtres du jour au lendemain — ton produit subit. Avec des poids téléchargés, le modèle est figé chez toi : il ne change que si tu le décides. Tu maîtrises les versions, tu peux le fine-tuner en profondeur, le déployer hors ligne ou dans un environnement air-gapped. C’est le vrai argument de l’open-weights, souvent plus déterminant que le coût.

La privacy et la conformité. C’est l’argument massue pour beaucoup de produits FR/EU. Avec une API étrangère, tes données (et celles de tes clients) transitent par les serveurs d’un tiers — un sujet sensible pour le RGPD, la santé, le juridique, le secteur public. Avec un modèle auto-hébergé, les données ne quittent jamais ton périmètre. Pour un usage soumis au secret professionnel ou à des contraintes de souveraineté, ça peut être non négociable.

Le self-hosting, sans angélisme. Héberger un modèle, ce n’est pas « gratuit et libre ». C’est de l’ops : provisionner des GPU, gérer la montée en charge, la latence, les mises à jour de sécurité, la supervision. Tu échanges une facture d’API contre une dette d’infrastructure et une équipe pour la porter. Pour beaucoup de petites équipes, l’API reste le bon choix précisément parce qu’elle externalise ce fardeau.

Comment choisir sans se faire avoir par le mot « open »

Une grille de décision plutôt qu’un dogme. Pose-toi ces questions dans l’ordre.

1. Tes données peuvent-elles sortir de ton périmètre ? Si non (santé, légal, souveraineté, secret pro), tu vises le self-hosting d’un modèle à poids ouverts. La question est tranchée avant même de parler de qualité.
2. As-tu une équipe capable de gérer du GPU en production ? Si non, l’API est probablement ton point de départ rationnel, quitte à migrer plus tard. Ne paie pas une dette d’ops que tu ne peux pas porter.
3. Ton volume est-il élevé, stable et prévisible ? Si oui, fais le calcul self-hosting vs API sur 12 mois — l’amortissement d’une infra peut basculer la décision. Si ton volume est faible ou erratique, l’API gagne presque toujours.
4. As-tu lu la licence du modèle « ouvert » que tu vises ? C’est le piège récurrent. Vérifie : usage commercial autorisé ? Restrictions sur certains domaines ? Seuil au-delà duquel il faut une licence payante ? Une licence Apache 2.0 ou MIT est vraiment permissive ; une « licence communautaire » maison ne l’est pas forcément.
5. As-tu besoin du tout meilleur modèle, ou d’un modèle assez bon ? Pour les tâches les plus dures, un modèle propriétaire de pointe garde souvent l’avantage. Pour une tâche bien bornée, un modèle ouvert plus petit, éventuellement fine-tuné, peut suffire largement — et coûter bien moins.

La stratégie gagnante pour beaucoup de produits n’est d’ailleurs pas binaire : prototyper vite sur API, puis migrer les volumes sensibles ou massifs vers un modèle auto-hébergé quand le besoin et l’équipe sont mûrs. L’ouvert et le fermé ne sont pas deux camps, ce sont deux étapes possibles du même produit.