Retour aux articles
· Intelligence artificielle · Jatniel Guzmán
Disponible en :
fr es

Pourquoi les modèles d’IA ouverts sont indispensables en 2026

Pourquoi les modèles d’IA ouverts sont indispensables en 2026

Pourquoi les modèles ouverts restent indispensables face à OpenAI, Anthropic et aux autres géants de l’IA

Pour son tout premier message publié sur X, Jensen Huang n’a pas annoncé une nouvelle carte graphique, un partenariat géant ou un énième record de performances chez NVIDIA.

Il a partagé une lettre en faveur des modèles d’intelligence artificielle ouverts.

Le choix n’est évidemment pas anodin.

NVIDIA vend les puces qui permettent d’entraîner et de faire tourner une grande partie des modèles actuels. Plus les entreprises, les chercheurs et les développeurs peuvent récupérer un modèle, l’installer sur leurs propres machines et l’adapter à leurs besoins, plus l’écosystème autour du matériel NVIDIA prend de l’importance.

Mais réduire cette lettre à une simple opération commerciale serait un peu facile, car le sujet dépasse largement les intérêts du fabricant.

La question est assez simple : veut-on que les meilleurs modèles d’intelligence artificielle restent accessibles uniquement à travers les serveurs de quelques entreprises, ou veut-on aussi pouvoir les télécharger, les étudier, les modifier et les faire tourner ailleurs ?

La réponse de Jensen Huang est plutôt raisonnable : nous avons besoin des deux.

Les modèles fermés avancent vite, mais nous n’en contrôlons presque rien

Les modèles proposés par OpenAI, Anthropic ou Google sont souvent les plus performants du marché.

Pour les utiliser, rien de très compliqué. On crée un compte, on récupère une clé API et l’on commence à envoyer des requêtes. Pas besoin d’acheter un serveur rempli de GPU, de choisir un moteur d’inférence ou de se demander comment faire tenir un modèle de plusieurs dizaines de milliards de paramètres dans la mémoire disponible.

Cette simplicité est un énorme avantage.

Pour ajouter rapidement une génération de texte, un assistant ou une analyse de documents dans une application web, une API reste souvent le choix le plus pragmatique.

Mais cette facilité a une contrepartie : le fournisseur garde la main.

Il peut modifier ses tarifs, remplacer un modèle, changer ses limites d’utilisation ou supprimer une version dont votre application dépend. Les données partent également sur une infrastructure extérieure, ce qui peut poser problème selon leur sensibilité, leur localisation ou les engagements pris auprès du client.

Et surtout, on ne sait pas réellement ce qui se passe à l’intérieur du modèle.

On peut lire une fiche technique, consulter quelques évaluations et tester son comportement. En revanche, on ne peut pas télécharger Claude ou GPT-5.6 pour l’analyser tranquillement sur son propre serveur.

OpenAI a fait un pas, Anthropic toujours pas

OpenAI a bien publié gpt-oss-20b et gpt-oss-120b en août 2025. Ces deux modèles peuvent être téléchargés, adaptés et exécutés localement ou sur une infrastructure privée. Le plus petit peut tourner avec environ 16 Go de mémoire, tandis que le plus gros vise plutôt des machines équipées d’un GPU de 80 Go.

C’était une bonne nouvelle, surtout venant d’une entreprise dont le nom contient encore le mot « Open ».

Le problème, c’est que les deux modèles de base n’ont pas vraiment été remplacés depuis. Pendant ce temps, OpenAI a continué à faire évoluer beaucoup plus rapidement sa gamme fermée. Sa page dédiée aux modèles ouverts présente toujours principalement gpt-oss-20b, gpt-oss-120b et leurs variantes orientées sécurité.

Anthropic va encore moins loin.

L’entreprise publie des travaux de recherche, des outils, des études sur le fonctionnement interne de Claude et des fiches détaillant ses choix de sécurité. Mais elle ne fournit aucun modèle Claude que l’on puisse télécharger et faire tourner librement chez soi ou sur son propre serveur.

C’est dommage, car Anthropic fait aujourd’hui partie des équipes les plus intéressantes dans le domaine, notamment pour le code et les agents autonomes.

Les chercheurs peuvent lire leurs publications. Les développeurs peuvent appeler leur API. Mais personne en dehors de l’entreprise ne peut réellement récupérer Claude pour le démonter, l’étudier ou l’adapter en profondeur.

Pendant ce temps, les laboratoires chinois enchaînent les sorties

DeepSeek, Qwen, Kimi et GLM occupent aujourd’hui une place énorme dans l’écosystème des modèles ouverts.

Ils publient régulièrement de nouvelles versions, des modèles spécialisés dans le code, le raisonnement ou l’utilisation d’outils, et permettent à toute une communauté de tester rapidement leurs travaux.

DeepSeek a par exemple continué à faire évoluer sa famille V3 avec des modèles capables de raisonner tout en appelant des outils, un point essentiel pour créer de vrais agents capables d’agir dans une application.

Cela produit un effet assez particulier.

Les entreprises américaines dominent encore une grande partie du marché commercial de l’IA, mais une bonne partie de l’expérimentation ouverte repose désormais sur des modèles venus de Chine.

Pour un développeur, l’origine du modèle n’est pas forcément le premier critère. Ce qui compte, c’est de pouvoir le tester, comparer ses résultats, lire sa licence et vérifier s’il peut répondre au besoin du projet.

Pour les États-Unis, le problème est évidemment plus stratégique. C’est précisément ce que cherche à mettre en avant la lettre partagée par Jensen Huang.

Ce que défend réellement la lettre

Le document compare l’arrivée des modèles ouverts à celle du logiciel libre dans les années 1980.

À l’époque, beaucoup d’entreprises considéraient encore que garder leur code secret constituait la meilleure façon de protéger leur avance. L’histoire a montré qu’un écosystème ouvert pouvait au contraire devenir la base d’une immense partie d’Internet, des serveurs, des outils de développement et des infrastructures modernes.

La lettre estime que l’intelligence artificielle se trouve aujourd’hui devant un choix comparable.

Un modèle ouvert permet à une entreprise, une université ou une équipe de recherche de partir d’une base existante au lieu d’entraîner un modèle depuis zéro. Elle peut ensuite le tester, l’adapter à son domaine et choisir où elle souhaite le faire tourner.

Le document insiste également sur plusieurs points :

  • éviter de dépendre entièrement d’un seul fournisseur ;

  • conserver le contrôle de ses données et de son infrastructure ;

  • permettre aux chercheurs d’étudier le comportement des modèles ;

  • faciliter la création de modèles spécialisés ;

  • renforcer la concurrence au lieu de concentrer l’IA entre quelques mains.

La lettre est notamment signée par NVIDIA, Microsoft, Meta, Dell, IBM, Mistral, Hugging Face, Mozilla, GitHub, Palantir, Perplexity, Replit et Y Combinator. OpenAI figure également parmi les signataires, ce qui rend l’absence d’une vraie nouvelle génération de gpt-oss encore plus intéressante à observer.

Pour un développeur, la différence devient très concrète

Prenons le cas d’un e-commerçant qui souhaite ajouter un assistant à son back-office Symfony.

L’objectif serait de permettre à son équipe de poser des questions sur le catalogue, les commandes, les procédures internes ou la documentation produit.

Avec une API externe, la mise en place peut être rapide.

L’application récupère les informations utiles, les envoie au modèle et affiche sa réponse. Le fournisseur s’occupe du matériel, des mises à jour et de la capacité nécessaire pour absorber les demandes.

En revanche, il faut accepter que certaines informations quittent l’infrastructure de l’entreprise. Il faut aussi suivre les coûts à chaque appel et rester dépendant des modèles proposés par le fournisseur.

Avec un modèle ouvert installé sur un serveur privé, les données peuvent rester chez le client.

On peut choisir précisément ce que le modèle a le droit de consulter, l’adapter au vocabulaire de l’entreprise et l’intégrer au système existant sans envoyer chaque question vers un service extérieur.

On peut également expérimenter beaucoup plus librement pendant le développement. Il n’y a pas de facture API pour chaque token généré, même si le calcul n’est évidemment pas gratuit : il faut payer la machine, l’électricité, l’hébergement et le temps passé à maintenir l’ensemble.

C’est là que le discours autour du « tout local » se heurte à la réalité.

Ouvert ne veut pas dire gratuit ni facile

Télécharger un modèle prend parfois quelques minutes. Le faire fonctionner correctement en production est une autre histoire.

Il faut choisir le bon format, quantifier le modèle si la mémoire disponible ne suffit pas, installer un moteur comme llama.cpp ou vLLM, gérer les mises à jour, surveiller les temps de réponse et sécuriser l’accès au serveur.

Il faut aussi vérifier la licence.

Un modèle disponible sur Hugging Face n’est pas automatiquement libre de toute restriction commerciale. Les termes changent d’un éditeur à l’autre et certains modèles imposent des conditions particulières.

Enfin, les performances ne sont pas toujours au niveau des meilleurs modèles fermés.

Un modèle local plus petit peut suffire pour classer des documents, extraire des données, résumer des fiches produit ou répondre à des questions bien cadrées. Il sera parfois beaucoup moins à l’aise sur un problème complexe, un gros dépôt de code ou une tâche demandant un raisonnement long.

Le bon choix n’est donc pas forcément de tout héberger soi-même.

Il consiste plutôt à utiliser le bon modèle pour le bon travail.

Un petit modèle local peut gérer les tâches répétitives et les données sensibles. Une API plus puissante peut être réservée aux demandes difficiles, après anonymisation ou filtrage des informations envoyées.

Cette approche hybride me paraît souvent beaucoup plus réaliste que le débat caricatural opposant systématiquement modèles ouverts et modèles fermés.

Les modèles ouverts posent aussi de vrais problèmes de sécurité

La lettre ne cache pas complètement ce point.

Une fois qu’un modèle est publié, son créateur ne peut plus décider qui l’utilise ni empêcher quelqu’un d’en produire une version modifiée. Il devient également très difficile de retirer le modèle ou de corriger toutes les copies déjà téléchargées.

Un modèle fermé permet au fournisseur de bloquer certains usages, de surveiller les abus et de modifier rapidement ses protections.

Avec un modèle ouvert, ces barrières peuvent être retirées.

Mais l’inverse est également vrai : un modèle fermé n’est pas automatiquement sûr simplement parce que son fonctionnement reste caché.

Il peut contenir des failles, avoir des comportements inattendus ou être détourné sans que des chercheurs indépendants puissent l’étudier sérieusement.

Les modèles ouverts permettent justement à davantage d’équipes de les tester, de chercher leurs faiblesses et de construire leurs propres protections. C’est le même débat que l’on retrouve depuis des années dans la sécurité informatique : cacher le fonctionnement d’un système ne suffit pas à le rendre solide.

Nous avons besoin des deux

Sur ce point, Jensen Huang a raison.

Les modèles fermés sont utiles. Ils permettent d’accéder immédiatement à de très bonnes performances sans construire toute l’infrastructure nécessaire derrière.

Les modèles ouverts sont tout aussi importants. Ils évitent que la recherche, l’expérimentation et une partie de l’économie de l’IA dépendent uniquement de quelques API privées.

Ils donnent aussi aux développeurs la possibilité d’apprendre autrement.

Faire tourner un modèle en local, tester différentes quantifications, modifier son comportement ou l’adapter à un domaine particulier permet de comprendre beaucoup plus de choses que le simple envoi d’une requête HTTP vers une boîte noire.

OpenAI a fait un premier pas avec gpt-oss, mais devrait maintenant aller plus loin et publier une nouvelle génération réellement alignée avec ses progrès récents.

Anthropic gagnerait également à proposer un Claude ouvert, même plus petit que ses modèles commerciaux. Ce serait utile aux chercheurs, aux développeurs et à tout l’écosystème qui s’est construit autour de Claude Code.

L’avenir de l’IA ne devrait pas se résumer à choisir entre trois abonnements et quatre API.

Il devrait aussi rester possible de télécharger un modèle, de le faire tourner sur sa propre machine, de comprendre ses limites et d’en construire quelque chose qui ne dépende pas entièrement de la prochaine décision d’un fournisseur.

Et pour cela, les modèles ouverts ne sont pas un petit bonus réservé aux passionnés.

Ils sont indispensables.

Document complet : Open Weights and American AI Leadership

Publication originale de Jensen Huang : voir le message publié sur X

Partager cet article