Modèles ouverts contre modèles fermés : deux malentendus à démonter

Deux phrases reviennent constamment à propos des modèles chinois qui bousculent le marché : « ils sont open source » et « ils sont gratuits ».

Les deux sont fausses. Pas approximatives — fausses, au sens où elles décrivent des choses qui n'existent pas.

Cela ne retire rien à ce qui se passe réellement, et qui est considérable : des modèles téléchargeables atteignent aujourd'hui un niveau que personne ne leur prêtait il y a deux ans. Mais l'écart entre ce qu'on en dit et ce qu'ils sont produit des décisions coûteuses — des équipes qui basculent en pensant économiser et découvrent une facture d'infrastructure, ou qui s'appuient sur une licence qu'elles n'ont pas lue.

Reprenons depuis les fiches officielles.

Premier malentendu : « ouvert » n'est pas « open source »

Trois choses distinctes se cachent derrière le mot « ouvert », et la confusion est entretenue par à peu près tout le monde.

Les poids ouverts. Vous téléchargez le modèle entraîné et vous l'exécutez où vous voulez. C'est ce que proposent Kimi, DeepSeek et Qwen. C'est déjà énorme.

Le code ouvert. Le code d'entraînement et d'inférence est publié. Parfois vrai, partiellement.

Les données ouvertes. Le corpus d'entraînement est documenté et accessible. Pratiquement jamais.

Un modèle à poids ouverts est donc l'équivalent d'un logiciel dont on vous donnerait le binaire, pas les sources. Vous pouvez l'utiliser, le redistribuer, l'ajuster. Vous ne pouvez pas le reconstruire, ni auditer ce sur quoi il a été entraîné.

C'est la raison pour laquelle l'expression consacrée dans le milieu est « poids ouverts » et non « open source ». Employer la seconde, comme le font la plupart des articles, revient à promettre une transparence qui n'est pas livrée.

Les licences, dans le détail

Voici ce que nous avons pu vérifier sur les fiches officielles des éditeurs, et ce que nous n'avons pas pu.

Modèle	Licence	Statut de la vérification
Kimi K2 (Moonshot AI)	Modified MIT	✅ Fiche officielle
DeepSeek V4	MIT	⚠️ Concordant sur plusieurs sources, non vérifié à la source
Qwen 3.6 (Alibaba)	Apache 2.0	⚠️ Concordant sur plusieurs sources, non vérifié à la source

Le détail qui compte est dans la première ligne. La licence de Kimi n'est pas MIT : elle est « Modified MIT ». Le qualificatif n'est pas décoratif.

Une licence MIT classique est parmi les plus permissives qui existent — faites-en ce que vous voulez, conservez la mention de copyright, l'auteur ne garantit rien. Une licence MIT modifiée ajoute des clauses. Lesquelles, dans quel sens, avec quelles conséquences pour un usage commercial à grande échelle : cela se lit, et cela se lit avant de bâtir un produit dessus.

Nous n'entrerons pas dans l'interprétation juridique de ces clauses, qui n'est pas notre métier. Nous signalons qu'il y en a, ce que la formule « open source » escamote entièrement.

La règle pratique : avant tout usage professionnel, ouvrez le fichier LICENSE du dépôt officiel et lisez-le. Il fait rarement plus de deux pages. C'est la seule source qui engage.

Deuxième malentendu : « gratuit »

Aucun de ces modèles ne coûte de licence. Aucun n'est gratuit à faire tourner.

Et le piège technique est plus subtil qu'il n'y paraît.

Le piège des paramètres activés

Kimi K2 est un modèle à mélange d'experts. Sa fiche officielle indique mille milliards de paramètres au total, dont trente-deux milliards activés par token, répartis sur 384 experts dont huit sont sélectionnés à chaque étape, plus un expert partagé.

Beaucoup en concluent qu'il se comporte comme un modèle de 32 milliards de paramètres, et qu'il tiendrait donc sur une machine modeste.

C'est faux, et c'est l'erreur la plus coûteuse du domaine.

Les paramètres activés déterminent le calcul effectué à chaque token — c'est ce qui rend l'architecture rapide. Mais les mille milliards de paramètres doivent être présents en mémoire, car on ne sait pas à l'avance quels experts seront sollicités. Vous économisez du calcul, pas de la mémoire.

Concrètement : un modèle de cette taille ne tourne pas sur une carte graphique, ni sur deux. Il demande une infrastructure de serveur, avec ce que cela implique de coût d'acquisition ou de location, d'énergie et d'administration.

C'est précisément pour cette raison que les éditeurs publient aussi des versions plus petites. DeepSeek annonce une déclinaison Flash nettement plus légère que sa version Pro, Alibaba propose des modèles de quelques dizaines de milliards de paramètres. Ces déclinaisons-là sont réellement exécutables sur du matériel accessible — et ce sont elles, pas les vaisseaux amiraux, que la plupart des équipes devraient regarder en premier.

De combien de mémoire parle-t-on, concrètement ?

Le calcul est simple et personne ne le fait, alors faisons-le.

La mémoire nécessaire pour charger un modèle est, en première approximation, le nombre de paramètres multiplié par le nombre d'octets utilisés pour en stocker un. Cette seconde valeur dépend de la quantification : la précision à laquelle vous acceptez de dégrader les poids pour gagner de la place.

En 8 bits, comptez un octet par paramètre. En 4 bits, un demi-octet. Ajoutez ensuite une marge pour le contexte en cours de traitement, qui grandit avec la longueur des requêtes.

Appliquons cela aux modèles cités :

Modèle	Paramètres	≈ mémoire en 8 bits	≈ mémoire en 4 bits
Kimi K2	1 000 milliards	~1 000 Go	~500 Go
Une déclinaison de 27 milliards	27 milliards	~27 Go	~14 Go
Une déclinaison de 35 milliards	35 milliards	~35 Go	~18 Go

Les ordres de grandeur parlent d'eux-mêmes.

Le vaisseau amiral n'est pas pour vous. Un téraoctet de mémoire vive de calcul, c'est un ensemble de plusieurs serveurs spécialisés. Aucune organisation ne déploie cela pour tester une idée.

Les déclinaisons intermédiaires, en revanche, sont à portée. Quatorze gigaoctets en 4 bits, c'est une carte graphique haut de gamme grand public. Vingt-sept gigaoctets, c'est une carte professionnelle ou deux cartes grand public. Nous ne parlons plus de centre de données mais d'une machine sous un bureau.

C'est là que se joue l'essentiel de l'intérêt pratique des modèles ouverts, et c'est exactement l'inverse de ce que suggère la couverture médiatique, focalisée sur les modèles géants.

Deux mises en garde. La quantification n'est pas gratuite : descendre en précision dégrade la qualité, de façon variable selon les modèles et les tâches — testez plutôt que de supposer. Et la mémoire n'est qu'une condition nécessaire : un modèle qui tient en mémoire peut répondre trop lentement pour votre usage. La vitesse dépend de la bande passante mémoire, pas seulement de la capacité.

Le seuil de rentabilité, calculé proprement

La question n'est donc pas « est-ce gratuit ? » mais « à partir de quel volume l'auto-hébergement devient-il moins cher que l'API ? ».

Nous ne connaissons pas le coût de votre infrastructure — il dépend du fournisseur, de la région, de l'engagement de durée et du matériel. Nous ne l'inventerons donc pas. En revanche, nous connaissons les tarifs d'API officiels, et cela suffit à poser l'équation.

Appelons C le coût mensuel complet de votre infrastructure d'inférence : location ou amortissement du matériel, énergie, et le temps d'administration que personne ne compte jamais. Voici combien de tokens d'entrée ce budget vous achèterait chez les principaux fournisseurs, aux tarifs relevés le 7 août 2026 :

Si vous payiez l'API…	Volume mensuel couvert par un budget C
Gemini 3.6 Flash (1,50 $/M)	C ÷ 1,50 millions de tokens
Claude Opus 5 (5 $/M)	C ÷ 5 millions de tokens
GPT-5.6 Sol, contexte long (10 $/M)	C ÷ 10 millions de tokens

Prenons une infrastructure à 2 000 dollars par mois, ordre de grandeur plausible pour une machine correctement dimensionnée. Ce budget vous achèterait environ 1,3 milliard de tokens d'entrée chez Google, 400 millions chez Anthropic, 200 millions chez OpenAI en contexte long.

Traduisez en usage réel. Si votre équipe consomme moins de quelques centaines de millions de tokens par mois, l'API reste économiquement supérieure — et de loin, une fois comptés les jours-homme d'installation et de maintenance.

Au-dessus, l'équation bascule. Et elle bascule d'autant plus vite que votre charge est régulière : une infrastructure payée au mois coûte le même prix qu'elle tourne à 20 % ou à 90 % de sa capacité.

Faites le calcul avec vos vrais chiffres. Relevez votre consommation mensuelle réelle sur votre tableau de bord de facturation, demandez un devis d'infrastructure, comparez. L'exercice prend une heure et évite des décisions à cinq chiffres prises à l'intuition.

Ce qui a réellement changé

Voilà pour les malentendus. Reste ce qui est vrai, et qui est le plus intéressant.

Il y a deux ans, l'écart entre les meilleurs modèles ouverts et le sommet du marché fermé était béant. Il ne l'est plus. Sur une part significative des tâches courantes — rédaction, extraction, classification, code de complexité moyenne — les meilleurs modèles téléchargeables tiennent aujourd'hui la comparaison.

L'écart persiste sur les tâches les plus difficiles : raisonnement long, travail agentique autonome sur plusieurs heures, fiabilité sur les cas limites. Mais il s'est déplacé du « incomparable » vers le « discutable selon l'usage », ce qui est un changement de nature.

Nous n'appuyons pas cette appréciation sur des scores de benchmark, pour les raisons que nous exposons dans nos autres comparatifs : contamination des jeux de tests publics, et sensibilité des résultats au harnais d'évaluation. Nous l'appuyons sur ce qui se vérifie — les caractéristiques publiées, et le fait que des équipes sérieuses les mettent en production.

Le seul test qui vaille reste le vôtre, sur vos propres tâches.

Trois bonnes raisons de choisir un modèle ouvert

Le prix n'en fait pas partie, sauf à très grand volume. Les vraies raisons sont ailleurs, et elles sont solides.

Vos données ne sortent pas. C'est l'argument décisif, et il est rarement mis en avant. Un modèle exécuté sur votre infrastructure ne transmet rien à personne. Pour du code propriétaire, des dossiers médicaux, des documents juridiques ou des données soumises à des obligations de localisation, cela règle en une décision des problèmes autrement inextricables.

Le modèle ne disparaît pas. Les éditeurs retirent régulièrement leurs anciens modèles du service, avec des préavis qui vous imposent une migration. Un modèle que vous avez téléchargé fonctionnera dans cinq ans exactement comme aujourd'hui. Pour un produit dont le comportement doit rester stable — certification, reproductibilité, obligations contractuelles —, cette propriété n'a pas d'équivalent.

Le tarif ne peut pas augmenter. Il n'y a pas de tarif. Votre coût est celui de votre infrastructure, que vous maîtrisez. Aucune décision commerciale prise ailleurs ne peut doubler votre facture du jour au lendemain.

Trois raisons de ne pas le faire

L'honnêteté commande de présenter l'autre colonne, généralement absente des articles enthousiastes.

Les compétences. Déployer, optimiser et maintenir un service d'inférence est un métier. Il faut savoir dimensionner la mémoire, gérer la mise en file d'attente, surveiller la latence, appliquer les mises à jour. Si personne dans l'équipe ne l'a jamais fait, le coût réel du projet n'est pas celui du serveur — c'est celui de l'apprentissage, plus le risque d'exploitation.

L'écart persistant sur le haut du panier. Sur les tâches les plus exigeantes, les modèles fermés de tête gardent une avance. Si votre produit dépend précisément de ces tâches, l'économie est une fausse économie.

Le rythme. Un nouveau modèle sort toutes les quelques semaines. Une équipe qui auto-héberge doit décider quand migrer, tester la régression, gérer la transition. Avec une API, vous changez une chaîne de caractères.

Le cas francophone, et le cas africain

Un point que les comparatifs anglophones ne traitent jamais, et qui concerne directement une partie de nos lecteurs.

En Europe, la question de la localisation des données a une dimension réglementaire directe : traiter des données personnelles de résidents européens impose des contraintes que l'auto-hébergement lève d'un coup. Les grands fournisseurs proposent des options de résidence des données, mais avec des conditions et des couvertures variables, à vérifier au cas par cas.

En Afrique francophone, l'équation comporte un terme supplémentaire que personne ne mentionne : l'accès au paiement et la stabilité de la connexion. Souscrire une API étrangère suppose un moyen de paiement international accepté, et une liaison suffisamment fiable pour que chaque requête parte et revienne. Ce sont des contraintes réelles, pas théoriques, et elles pèsent parfois plus lourd que le tarif au token.

Un modèle exécuté localement — y compris une déclinaison modeste sur du matériel accessible — répond à ces deux contraintes à la fois. C'est un argument qui n'apparaît dans aucun comparatif rédigé depuis San Francisco, et qui est pourtant déterminant pour une partie du monde francophone.

Comment tester sans rien engager

Vous n'avez pas besoin d'acheter un serveur pour vous faire une opinion. Trois étapes, quelques dizaines de dollars.

Commencez par la version la plus petite. Les déclinaisons de quelques dizaines de milliards de paramètres tournent sur du matériel grand public ou sur une instance louée à l'heure. Elles suffisent à juger du comportement du modèle sur vos tâches, ce qui est la seule question à ce stade.

Passez ensuite par un hébergeur tiers. Plusieurs plateformes servent ces modèles via une API compatible. Vous testez la version complète sans installer quoi que ce soit, à un tarif qui n'a rien à voir avec le coût d'une infrastructure dédiée. Attention toutefois : vos données transitent alors par ce tiers, ce qui annule l'argument de confidentialité — c'est un test, pas une architecture.

N'installez chez vous qu'ensuite, et seulement si les deux premières étapes ont conclu. L'ordre inverse — acheter la machine puis découvrir que le modèle ne convient pas — est l'erreur classique.

Questions fréquentes

Les modèles chinois sont-ils un risque de sécurité ?

La question mérite d'être posée précisément. Un modèle téléchargé et exécuté sur votre infrastructure, sans accès réseau, n'envoie rien nulle part — c'est un fichier de poids, pas un service. Le risque de transmission de données concerne l'usage via une API hébergée, quel qu'en soit le pays. Restent les questions de biais et d'alignement, qui se posent pour tous les modèles et se testent sur vos propres cas.

Puis-je ajuster ces modèles sur mes données ?

Oui, c'est même l'un des principaux intérêts. Les licences permissives citées l'autorisent, sous réserve des clauses spécifiques à chacune. Techniquement, l'ajustement demande nettement moins de ressources que l'entraînement initial, mais reste un projet à part entière.

Que valent ces modèles en français ?

C'est une question à tester vous-même, systématiquement. Les performances multilingues varient beaucoup d'un modèle à l'autre, et les évaluations publiées portent massivement sur l'anglais. Prenez vingt textes représentatifs de votre usage réel et comparez à l'aveugle — c'est une demi-journée, et c'est la seule réponse fiable.

« Poids ouverts » veut-il dire que je peux vendre un produit basé dessus ?

Cela dépend de la licence, et c'est exactement pourquoi il faut la lire. Apache 2.0 et MIT l'autorisent largement. Une licence modifiée peut ajouter des restrictions sur l'usage commercial, le seuil d'utilisateurs ou l'attribution. Deux pages à lire avant d'engager un produit.

Faut-il choisir un camp ?

Non, et c'est le meilleur conseil de cet article. Les architectures les plus efficaces combinent : un modèle ouvert auto-hébergé pour les traitements de volume et les données sensibles, une API haut de gamme pour les tâches difficiles. Le choix se fait par tâche, pas par idéologie.

Ce qu'il faut retenir

Les modèles à poids ouverts ont changé le rapport de force, mais pas de la façon dont on le raconte.

Ils ne sont pas open source — vous recevez des poids, pas des sources ni des données, et les licences comportent des clauses qu'il faut lire. Ils ne sont pas gratuits — vous remplacez un coût variable par un coût fixe, et l'arbitrage ne bascule qu'au-delà d'un volume que vous pouvez calculer en une heure.

Ce qu'ils apportent réellement est ailleurs, et vaut mieux que les deux arguments qu'on leur prête : la maîtrise de vos données, la pérennité de votre outil, et l'indépendance vis-à-vis d'une grille tarifaire décidée sans vous.

Pour beaucoup d'organisations, ces trois propriétés justifient à elles seules l'effort. Pour beaucoup d'autres, l'API reste le choix rationnel. La seule erreur consiste à trancher sur un slogan.

---

Note de méthode

Les caractéristiques de Kimi K2 — licence Modified MIT, mille milliards de paramètres dont trente-deux milliards activés, architecture à 384 experts, fenêtre de contexte de 128 000 tokens — proviennent de la fiche officielle du modèle publiée par Moonshot AI.

Les licences de DeepSeek V4 (MIT) et Qwen 3.6 (Apache 2.0), ainsi que leurs nombres de paramètres, sont concordants sur plusieurs sources indépendantes mais nous n'avons pas pu les vérifier directement sur les dépôts officiels au moment d'écrire, l'accès automatisé à la plateforme d'hébergement ayant échoué. Nous les signalons comme tels dans le tableau plutôt que de les présenter comme établis. Vérifiez le fichier LICENSE du dépôt avant tout usage professionnel — c'est une opération d'une minute.

Les tarifs d'API utilisés dans le calcul de seuil de rentabilité proviennent des pages officielles d'Anthropic, d'OpenAI et de Google, relevées le 7 août 2026. Le coût d'infrastructure de 2 000 dollars mensuels est une hypothèse de travail explicite, destinée à illustrer la méthode, non un chiffre relevé : remplacez-le par votre devis.

Nous ne publions aucun score de benchmark, pour les raisons développées dans nos autres comparatifs.

Sources

• Fiche officielle Kimi K2-Instruct — Moonshot AI
• Collection officielle DeepSeek
• Tarification Anthropic — documentation officielle
• Tarification de l'API OpenAI — documentation développeurs
• Tarification de l'API Gemini — Google AI for Developers