Le marché des modèles d’intelligence artificielle téléchargeables a suffisamment évolué pour que de nombreuses entreprises n’aient plus à dépendre systématiquement d’une API propriétaire. En juillet 2026, il existe des options capables de s’exécuter sur un ordinateur portable, une seule GPU professionnelle ou un cluster complet. Cependant, le choix ne doit pas se baser uniquement sur le modèle en tête du dernier tableau publié sur les réseaux sociaux.

Les clés des modèles d’IA ouverts en 20 secondes

• De nombreux modèles qualifiés d’ouverts publient leurs poids, mais pas les données ni l’ensemble du processus d’entraînement.
• Licences comme Apache 2.0 ou MIT facilitent souvent leur utilisation commerciale.
• Un modèle plus petit peut offrir un meilleur rapport coût, vitesse et stabilité.
• La décision doit se fonder sur des tests personnels, le matériel disponible, la confidentialité et la licence.

Les poids peuvent être téléchargés gratuitement, mais cela ne rend pas l’inférence gratuite. Faire fonctionner un modèle nécessite de la mémoire, de la capacité de calcul, du stockage, de l’électricité, du personnel technique et un système capable de gérer plusieurs utilisateurs sans dégrader la réponse.

Il est aussi essentiel de considérer la finalité. Un assistant interne pour consulter la documentation n’a pas nécessairement besoin du même modèle qu’un agent chargé de modifier des dépôts, d’interpréter des images ou de résoudre des problèmes mathématiques. Choisir systématiquement le modèle le plus volumineux ne transfère souvent que le coût de l’API vers le centre de données, sans amélioration proportionnelle.

Ouvert ne signifie pas toujours code source ouvert

L’expression « modèle en circuit fermé open source » est parfois utilisée à outrance. Dans beaucoup de cas, le fabricant permet de télécharger les paramètres entraînés, d’exécuter et d’adapter le modèle, mais ne publie pas les données d’entraînement, le code complet, les critères de filtrage ni les points de contrôle intermédiaires.

L’Open Source Initiative (OSI) considère qu’un système d’IA ouvert doit permettre de l’utiliser, de l’étudier, de le modifier et de le partager. Pour garantir ces libertés, il faut aussi disposer d’informations suffisantes sur les données, le code utilisé pour l’entraînement et l’exécution, ainsi que sur les paramètres finaux. Selon cette définition, beaucoup de modèles populaires sont en réalité des modèles de poids ouverts, sans open source complet.

Cette distinction n’est pas seulement académique. Une entreprise peut télécharger un modèle et en obtenir une utilisation commerciale légitime, sans pouvoir reproduire son processus d’entraînement. Pour certains projets, cela suffit, mais cela n’offre pas le même niveau de transparence qu’une publication intégrale.

OLMo 3, développé par l’Allen Institute for AI, est une des propositions parmi les plus ouvertes. Le projet publie des poids, des jeux de données, des outils de nettoyage, du code d’entraînement, des évaluations et des artefacts issus des différentes phases. Sa famille comprend des variantes de 7 000 et 32 000 millions de paramètres destinés à un usage général, à la conversation et au raisonnement.

Il faut vérifier la licence avant d’intégrer un modèle dans un produit. Apache 2.0 et MIT permettent généralement d’utiliser, de modifier et de distribuer le logiciel avec peu de restrictions, tout en précisant clairement attribution et brevets. Les licences propriétaires peuvent imposer des limites géographiques, des conditions pour de grandes plateformes, des politiques d’utilisation ou des restrictions liées à l’entraînement de modèles concurrents.

Même au sein d’une même famille, des modèles peuvent avoir des conditions différentes. Il ne suffit pas de savoir que « Qwen est open » ou que « Mistral permet de télécharger ses modèles » : il faut examiner précisément la licence de la version, le dépôt d’où il provient et les conditions pour le déploiement.

Les modèles adaptés à chaque niveau de matériel

Le haut du marché est dominé par des architectures de mélangeurs d’experts, appelées MoE. Ces modèles contiennent des centaines de milliards de paramètres, mais n’activer qu’une fraction pour traiter chaque jeton. Cela réduit le calcul par rapport à un modèle dense de même taille, sans simplifier automatiquement le déploiement ni stocker moins de poids.

GLM-5.2, de Z.ai, est l’un des modèles les plus ambitieux disponibles sous licence MIT. Il offre une fenêtre de contexte d’un million de jetons et cible la programmation, les agents et les tâches longues. Cette capacité permet d’intégrer de vastes référentiels ou collections documentaires, même si l’utilisation de la fenêtre n’assure pas que le modèle exploite parfaitement toutes les informations présentes.

DeepSeek-V3.2 maintient une position forte en raisonnement et utilisation d’outils. Son dépôt publie les poids sous licence MIT et utilise un mécanisme d’attention dispersée conçu pour réduire le coût des contextes longs. Ses 685 milliards de paramètres le placent loin d’une configuration domestique classique, et il s’exécute généralement sur une infrastructure spécialisée ou via un fournisseur.

Mistral Large 3 utilise 675 milliards de paramètres totaux actifs environ 41 milliards. Distribué sous Apache 2.0, il propose des formats compressés, mais la documentation recommande un déploiement sur des systèmes de type Blackwell ou des nœuds avec huit GPU A100 ou H100. Il ne s’agit pas d’un modèle à installer sur n’importe quel serveur inutilisé.

OpenAI propose également dans ce segment gpt-oss-120b et gpt-oss-20b, publiés sous licence Apache 2.0. Le premier fonctionne sur une GPU de 80 Go de mémoire, la version de 20 milliards peut, quant à elle, tourner dans un espace réduit à 16 Go via sa quantification MXFP4. La seconde est davantage accessible pour les stations de travail et équipements haut de gamme.

Qwen3.6-35B-A3B se positionne en taille intermédiaire. Bien qu’il comporte environ 35 milliards de paramètres, il active une fraction moindre par jeton et supporte texte et images. Distribué par Alibaba sous licence Apache 2.0, il constitue une alternative intéressante pour ceux qui souhaitent un modèle multimodal adaptable, sans demander la puissance des modèles de plusieurs centaines de milliards de paramètres.

Google a conçu Gemma 4 pour couvrir depuis les appareils mobiles jusqu’aux ordinateurs personnels. La famille comprend des variantes E2B et E4B axées sur l’efficacité, ainsi que des modèles de 12 000, 26 000 et 31 000 millions de paramètres pour le raisonnement et les charges multimodales. Google a aussi publié des versions optimisées par entraînement quantifié pour réduire la consommation mémoire.

Microsoft maintient la famille Phi pour les scénarios où le volume et l’exécution locale sont prioritaires sur la performance brute. Phi-4-mini dispose de 3 800 millions de paramètres, étend le multilinguisme et intègre des appels de fonctions. La famille, publiée sous licence MIT, cible des applications locales et des appareils sans connexion constante au cloud.

Mistral propose également Ministral 3 en tailles de 3, 8 et 14 milliards de paramètres. Ces versions incluent la compréhension d’images et des variantes adaptées aux instructions ou au raisonnement, toutes sous licence Apache 2.0. Elles conviennent pour des stations de travail, systèmes périphériques ou appareils où un modèle de grande taille ne serait pas économiquement viable.

Ce spectre montre pourquoi il n’existe plus un seul modèle ouvert recommandé pour tout. Les modèles petits offrent une moindre latence, peuvent gérer plus d’utilisateurs par GPU et sont plus faciles à mettre à jour. Les grands apportent davantage de capacité pour les tâches complexes, mais nécessitent des investissements en infrastructure, parallélisation et systèmes d’inférence spécialisés.

Comment choisir sans faire du coût une surcharge

La première étape consiste à définir un test concret. Une équipe souhaitant résumer des contrats doit préparer des documents représentatifs, des questions courantes et des réponses validées par des experts. Pour la programmation, il faut disposer de référentiels, de cas réels, de tests automatisés et de tâches qui exigent de comprendre plusieurs fichiers.

Les résultats publiés par les fabricants servent de base à une première sélection, mais ne remplacent pas l’évaluation propre. Un modèle peut exceller en test SWE-bench mais être faible pour suivre des conventions dans un code spécifique. Un autre peut donner de bons résultats en anglais, mais perdre en précision en français ou en termes juridiques.

L’évaluation doit couvrir la qualité, la latence, le nombre de tokens par seconde, la mémoire utilisée, le coût par requête et le pourcentage de réponses nécessitant une correction. Il est aussi utile de vérifier la capacité à suivre des instructions, la stabilité du format JSON, l’utilisation d’outils et la tendance à générer des données inventées.

La longueur du contexte mérite un test spécifique. Charger un million de tokens peut être techniquement possible, mais lent, coûteux ou peu précis. Beaucoup d’applications privilégient un système de génération augmentée par récupération (RAG), qui sélectionne uniquement les fragments pertinents avant de consulter le modèle.

La quantification permet de réduire la taille des poids via des formats à moindre précision. Un modèle de 20 ou 30 milliards de paramètres peut ainsi fonctionner sur une GPU grand public, mais cette réduction peut impacter la qualité, notamment en raisonnement, mathématiques ou génération structurée. Chaque quantification doit être testée comme une version distincte.

La confidentialité locale n’est pas assurée automatiquement. Faire tourner les poids sur un serveur propre évite d’envoyer des requêtes au fournisseur, mais l’application, l’environnement, les extensions ou outils de télémétrie peuvent continuer à transmettre des données. Il faut examiner toute la chaîne.

Pour expérimenter sur un ordinateur personnel, des applications comme Ollama ou LM Studio facilitent le démarrage. Sur serveur, vLLM ou SGLang proposent des interfaces compatibles API, la gestion de lots et une meilleure utilisation des GPU. Le bon choix dépend du modèle, de l’architecture et de la charge attendue.

Lorsque le volume est irrégulier, une API hébergée peut être plus économique que plusieurs GPU allumés en permanence. L’hébergement en propre se justifie quand la charge est constante, que la confidentialité est primordiale, qu’il faut personnaliser le modèle ou que la taille nécessite d’amortir le matériel.

Le modèle ne doit pas être figé à vie. La rapidité des publications impose de découpler l’application de la technologie d’inférence, via des interfaces stables. Ainsi, une entreprise peut tester de nouvelles versions ou remplacer le modèle sans tout refaire.

L’opportunité en 2026 ne consiste pas à télécharger le plus gros modèle disponible. Elle réside dans la capacité à choisir entre familles ouvertes, à héberger où cela convient, et à changer quand une autre solution offre meilleure qualité ou moindre coût. Cette liberté ne génère des économies que si elle s’accompagne de tests internes, de vérification des licences et d’une estimation complète de l’infrastructure nécessaire.

Questions fréquentes

Quel est le meilleur modèle ouvert pour une utilisation sur un ordinateur personnel ?

Cela dépend de la mémoire disponible et de la tâche. Phi-4-mini, ainsi que les versions petites de Gemma 4 et Ministral 3, sont légers, tandis que gpt-oss-20b ou Qwen3.6 nécessitent des équipements avec plus de mémoire et une quantification adaptée.

Les modèles à poids ouverts peuvent-ils être utilisés à des fins commerciales ?

Souvent oui, mais il faut vérifier la licence de chaque version. Apache 2.0 et MIT autorisent généralement une utilisation commerciale étendue, alors que les licences propriétaires peuvent imposer des restrictions.

Le téléchargement d’un modèle supprime-t-il le coût lié à l’utilisation de l’IA ?

Non. Même si le paiement par API diminue ou disparaît, il reste des coûts liés aux GPU, à l’électricité, au stockage, à la gestion, à la sécurité et à la maintenance.

Un modèle local est-il préférable à une API dans le cloud ?

Le modèle local offre davantage de contrôle sur les données et la configuration. Une API peut être plus simple et économique pour un usage faible ou variable. Le choix dépend du volume, de la confidentialité et des ressources techniques disponibles.