La question n’est plus de savoir si un modèle ouvert peut rivaliser avec un modèle propriétaire, mais dans quelles tâches concrètes il y parvient et à quel coût réel. En 2025, de nombreuses équipes ont migré une partie de leur stack d’IA vers des poids téléchargeables et ont découvert deux choses : que les économies sur l’API ne compensent pas toujours le coût de l’infrastructure, et que la licence compte plus qu’il n’y paraît lorsque le produit passe en production.
Vous ne trouverez pas ici un classement à plat. Vous trouverez quelles familles de modèles ouverts obtiennent des résultats défendables, où elles restent en deçà face aux modèles payants et comment décider selon des critères qui survivront à la prochaine sortie.
La carte réelle : ce que signifie « open source » dans les modèles de langage
Avant de comparer, il convient de dissiper une ambiguïté qui engendre des décisions erronées. Presque aucun modèle dit ouvert ne répond à la définition stricte de l’OSI. Ce que l’on trouve habituellement, ce sont des poids téléchargeables sous des licences d’usage communautaire qui imposent des restrictions : limites d’utilisateurs mensuels, interdiction d’usage concurrentiel, obligation d’afficher le nom du modèle dans l’interface ou clauses d’évolution commerciale.
Cela a une conséquence pratique : un modèle peut être gratuit pour prototyper et coûteux — juridiquement — à mesure qu’il grandit. La famille Llama est l’exemple classique de licence avec seuil d’utilisateurs ; Qwen et DeepSeek publient une bonne partie de leurs poids sous Apache 2.0, ce qui facilite l’intégration commerciale sans friction juridique ; Mistral combine des licences Apache sur ses petits modèles avec des licences de recherche sur les grands. Avant de choisir sur la base de benchmarks, vérifiez la licence du modèle précis que vous allez déployer, et non celle du dépôt en général.
Modèles ouverts qui méritent un essai en 2025
Llama (Meta) reste le standard de facto de l’écosystème. Son avantage n’est pas la performance brute mais la maturité de l’outillage : quantifications prêtes à l’emploi, prise en charge dans Ollama, vLLM et llama.cpp, et une communauté qui résout les questions rapidement. La variante 8B est un cheval de bataille pour la classification, l’extraction et les résumés ; les tailles supérieures rivalisent en raisonnement mais exigent un matériel rarement présent sur le poste d’un développeur.
Qwen a gagné du terrain sur les tâches multilingues et de code. Ses petites versions surprennent en génération de SQL et en compréhension d’instructions au format strict, et la licence Apache sur bon nombre de ses poids élimine le débat juridique. Dans les tests d’extraction de données structurées à partir de texte désordonné, un modèle Qwen de taille moyenne suffit souvent là où un grand modèle propriétaire serait surdimensionné.
DeepSeek a démontré qu’un laboratoire disposant de moins de ressources peut publier des modèles compétitifs en raisonnement mathématique et en code. La contrepartie est l’opacité sur les données d’entraînement et la nécessité de valider les biais dans les domaines réglementés.
Mistral maintient une proposition européenne avec de bons résultats sur les tâches d’instruction et une communauté active autour de ses formats de quantification.
Gemma (Google) propose des poids ouverts avec une approche conservatrice en matière de sécurité, utile lorsque vous avez besoin d’un modèle qui ne génère pas de contenu problématique par défaut, bien que sa licence comporte également des conditions d’utilisation.
Là où le modèle ouvert gagne sans discussion
Il existe des scénarios où la comparaison n’a même pas de sens, car le propriétaire ne peut pas offrir ce dont vous avez besoin.
Des données qui ne peuvent pas sortir de votre infrastructure
Si vous traitez des dossiers médicaux, des dossiers juridiques ou des données personnelles soumises à une réglementation stricte, envoyer des prompts à une API externe exige une analyse des risques que de nombreux services juridiques n’approuvent pas. Un modèle ouvert exécuté en local élimine le transfert de données. Il n’élimine pas la responsabilité : vous devez toujours enregistrer quel modèle vous avez utilisé, avec quelle version et quels prompts, car la traçabilité est aussi une obligation.
Volume élevé et prévisible
Lorsque votre charge est constante et que le modèle tient sur un GPU que vous possédez déjà, le coût marginal par token tend vers zéro. Un cas typique : classer des milliers de tickets quotidiens dans des catégories fixes. Un modèle de 7-8B quantifié en 4 bits tourne sur un GPU grand public et accomplit cette tâche avec une précision qui, après un léger ajustement fin avec vos propres exemples, égale celle de modèles propriétaires bien plus grands sur ce domaine étroit. La clé est que la tâche soit circonscrite ; si vous avez besoin de raisonnement ouvert, le calcul change.
Latence maîtrisée et sans dépendance vis-à-vis de tiers
Pour les applications interactives où 300 ms de plus ruinent l’expérience, ou pour les produits qui ne peuvent pas se permettre une panne du fournisseur, le déploiement propre offre le contrôle. Il impose aussi l’obligation de le surveiller, ce que beaucoup d’équipes sous-estiment.
Là où le modèle payant reste l’option raisonnable
L’honnêteté oblige à le dire : en raisonnement complexe à plusieurs étapes, en suivi d’instructions longues et dans les tâches nécessitant un contexte de centaines de milliers de tokens, les modèles propriétaires de frontière conservent leur avantage. Un modèle ouvert de taille moyenne peut écrire une fonction correcte ; lui demander de raisonner sur un dépôt entier et de proposer une refactorisation cohérente produit souvent des résultats fragiles.
Il y a aussi un facteur qui apparaît rarement dans les comparatifs : le coût de maintenance. Choisir un modèle ouvert implique de versionner les poids, de gérer les mises à jour, de mettre en place une évaluation continue et d’assumer qu’un jour la communauté cessera de maintenir la quantification que vous utilisez. Ce travail a un prix en heures d’ingénierie qui, dans les petites équipes, dépasse les dépenses d’API pendant des mois.
Une erreur courante que j’ai vue se répéter
Des équipes qui migrent vers un modèle ouvert parce qu’il obtient un bon score sur un benchmark public et découvrent ensuite que leur cas d’usage concret — par exemple, extraire des champs de factures scannées avec des modèles hétérogènes — échoue systématiquement. Le benchmark mesurait le raisonnement général, pas la capacité à respecter un schéma JSON avec des champs imbriqués et des valeurs nulles. La leçon : constituez un ensemble d’évaluation avec 50 à 100 exemples réels de votre domaine avant de décider. Si le modèle ouvert ne passe pas ce test, l’économie est fictive.
Comment comparer sans tomber dans le bruit des classements
Les leaderboards changent chaque semaine et mélangent des tâches qui ne se ressemblent pas. Une approche plus utile consiste à construire votre propre matrice de décision autour de quatre axes :
- Licence et conformité : permet-elle un usage commercial sans seuils ? exige-t-elle une attribution ? que se passe-t-il si vous dépassez un certain volume ?
- Adéquation au matériel : tient-il sur votre GPU avec la quantification dont vous avez besoin ? quel débit réel obtenez-vous avec vLLM ou llama.cpp ?
- Qualité dans votre domaine : résultats sur votre ensemble d’évaluation, pas sur MMLU.
- Coût total : API face à infrastructure plus heures de maintenance.
Un détail technique qui fait la différence et que l’on néglige : la quantification dégrade certaines tâches plus que d’autres. La génération créative supporte bien 4 bits ; le raisonnement mathématique et l’extraction précise de données souffrent davantage. Tester la même tâche avec le modèle en fp16 et en quantifié vous dira si l’économie de VRAM justifie la perte.
Stratégie hybride : ce qui fonctionne en pratique
La dichotomie gratuit contre payant est trompeuse. L’architecture la plus performante dans les projets réels combine les deux : un petit modèle ouvert pour le gros du trafic (classification, filtrage, résumés courts, réponses de FAQ) et un modèle propriétaire en secours pour les requêtes que le petit dérive en raison d’une faible confiance. Ce schéma réduit le coût sans sacrifier la qualité dans les cas difficiles, et il est plus facile à justifier auprès du business qu’une migration totale.
Il convient aussi de rappeler que « gratuit » n’existe pas en inférence : quelqu’un paie l’électricité, le GPU et le temps de celui qui maintient le déploiement. La bonne question n’est pas lequel est gratuit, mais lequel a un coût total moindre pour votre volume et votre équipe.
Ce qu’il faut surveiller dans les prochains mois
Le rythme de publication des poids ouverts ne ralentit pas, et l’écart avec les modèles de frontière se réduit sur certaines tâches tandis qu’il se maintient sur d’autres. Deux fronts méritent l’attention : les licences, qui tendent à se durcir lorsque le modèle devient populaire, et les outils d’évaluation, qui restent le maillon faible. Un modèle sans bon système d’évaluation propre est une boîte noire avec une bonne presse.
S’il fallait résumer le critère : testez d’abord les modèles ouverts sur des tâches circonscrites et mesurables, réservez les propriétaires à ce qui exige un raisonnement large, et ne prenez aucune décision sans un ensemble d’évaluation construit avec vos propres données. C’est la seule comparaison qui ne devient pas obsolète le mois suivant.