Les outils comptent plus que le modèle : la leçon du rapport Mozilla sur l'IA ouverte

Mozilla a publié son rapport « State of Open Source AI », qui agrège des benchmarks, des études externes et un sondage SlashData auprès de 1 410 développeurs (PDF). Le constat principal est remarquable : les modèles à poids ouverts ont presque rattrapé les modèles propriétaires. Mais ce qui rend ce rapport vraiment fascinant est ailleurs. Si l'écart de performance entre les deux familles de modèles n'a jamais été aussi faible, ce n'est pas la puissance du modèle qui décide de la réussite d'un projet IA. C'est tout ce qui l'entoure : le harnais, les outils, l'intégration et la manière dont on l'utilise.

Cet article s'inspire de l'analyse de Mickael Bazoge sur Next, qui détaille les chiffres du rapport et le contexte géopolitique.

Les modèles ouverts collent au peloton de tête

Les chiffres du rapport sont sans appel. Sur l'indice Artificial Analysis Intelligence, les quatre modèles les plus performants sont propriétaires et américains : Claude Opus 5 et Fable 5, GPT-5.6 Sol et Grok 4.6, avec des scores entre 61 et 63. Juste derrière, on trouve quatre modèles ouverts, tous chinois : Kimi K3, GLM-5.3, Qwen3.8 Max et GLM-5.3 Flash, entre 57 et 60. L'écart se mesure en points de benchmark, plus en capacités réelles.

Selon les études METR et Epoch reprises par Mozilla, les meilleurs modèles fermés accomplissent aujourd'hui des tâches longues d'environ 8 à 12 heures ; les meilleurs modèles ouverts rattrapent ce même niveau avec environ quatre mois de décalage. En pratique : pour tout ce qui doit être réalisé en moins de 8 heures, les deux familles s'en sortent déjà. La fenêtre où un modèle fermé apporte un avantage réel continue de se rétrécir.

Le modèle devient une commodité

L'argument du prix est encore plus parlant. Avec Kimi K3, un million de tokens en entrée coûte 30 % du prix de Fable 5. Sur OpenRouter, huit des dix modèles les plus utilisés d'août étaient à poids ouverts et DeepSeek V4 Flash a traité près de deux fois plus de tokens que le premier modèle fermé du classement. Sur Hugging Face, Qwen a été téléchargé 942 millions de fois en un mois.

Quand des modèles ouverts coûtent une fraction du prix d'un modèle de frontière cloud tout en atteignant 95 % de ses performances, le modèle cesse d'être l'avantage concurrentiel. Il devient une brique interchangeable, comme un moteur de base de données ou un compilateur. Personne ne choisit son stack technique uniquement sur la vitesse brute du compilateur.

Ce qui bloque n'est pas la puissance du modèle

C'est ici que le rapport devient vraiment intéressant. Mozilla a demandé aux développeurs pourquoi ils abandonnent les modèles ouverts. La réponse n'est ni le coût, ni la sécurité, ni la puissance brute. C'est le travail de maintenance au quotidien : mises à jour, complexité de déploiement, difficulté d'intégrer le modèle dans des systèmes existants, évaluation en conditions réelles.

Les chiffres de passage en production le montrent : dans les petites entreprises, modèles ouverts et fermés sont presque à égalité (53 % contre 54 %). L'écart se creuse avec la taille : 55 % contre 66 % dans les entreprises moyennes, 57 % contre 73 % dans les grandes. Ce n'est pas un plafond de capacités — c'est un déficit de finition, de produit « clé en main », de conformité et de responsabilité contractuelle.

Autrement dit : les modèles ouverts échouent rarement à cause de leurs benchmarks. Ils échouent parce que l'ensemble de l'expérience autour d'eux demande du travail que les modèles fermés prennent en charge. Le problème n'est pas le moteur. C'est le reste de la voiture.

L'outil fait le modèle

Cette lecture rejoint exactement ce que nous observons sur le terrain de l'IA locale. La formule popularisée par les frameworks agents modernes est éloquente : Modèle + Harnais = Agent. Le modèle réfléchit ; le harnais gère tout le reste — accès aux fichiers, commandes terminal, appels d'outils, mémoire de session, intégrations MCP, gestion du contexte.

Le signe le plus fort vient des acteurs eux-mêmes : quand DeepSeek a publié un projet open-source en août 2026, ce n'était pas un nouveau modèle mais un harnais, le DeepSeek Harness, capable de transformer n'importe quel LLM en agent fonctionnel. Les grands laboratoires, eux, verrouillent leurs produits finis sur leurs propres modèles. Les acteurs ouverts construisent l'outillage qui rend n'importe quel modèle utile.

Notre article sur l'incident OpenAI-Hugging Face en offre une illustration frappante. Quand l'équipe de sécurité de Hugging Face a dû analyser 17 000 événements d'attaque, les API des modèles commerciaux de pointe ont bloqué les requêtes — leurs garde-fous ne distinguent pas un analyste d'un attaquant. L'équipe s'est tournée vers un modèle open-weight exécuté sur sa propre infrastructure et l'analyse qui aurait pris des jours a été faite en une heure. Le modèle n'était pas plus intelligent que ceux qui ont refusé de répondre. Il était dans un environnement qui lui permettait de faire le travail.

Un modèle moyen outillé avec soin fait régulièrement mieux qu'un modèle de pointe mal outillé. C'est vrai pour le codage, où la qualité d'un éditeur outillé (recherche de code, exécution de tests, boucle de correction) pèse plus que quelques points d'indice. C'est vrai pour les agents, où la fiabilité vient de la boucle d'outils et de la vérification, pas seulement du raisonnement. C'est vrai pour le RAG, où la qualité de l'indexation et du découpage décide du résultat bien avant le choix du modèle.

Où les modèles fermés gardent encore l'avantage

Restons honnêtes : la fenêtre existe encore. Sur les tâches professionnelles à haute valeur ajoutée, Fable 5 conserve 92 points d'Elo d'avance sur Kimi K3 dans le benchmark GDPval-AA v2. Sur la recherche d'informations dispersées dans un très long contexte (un million de tokens), Gemini 3.1 Pro atteint 89 % quand le meilleur modèle ouvert mesure 41 %. Et les modèles fermés offrent un interlocuteur qui prend en charge une partie de la responsabilité.

Mais cette avance porte précisément sur des cas où le contexte et la finition comptent plus que la puissance brute — exactement le domaine où de bons outils comblent l'écart. Et elle se réduit d'environ quatre mois à chaque génération.

Ce que cela change pour l'IA locale

Pour les utilisateurs d'IA locale, le rapport se lit comme une validation. Si le modèle n'est plus le facteur limitant, inutile de courir après le plus gros modèle possible. La stratégie gagnante tient en quatre points :

1. Choisissez un modèle suffisant, pas le meilleur. Un modèle 7-14B suffit pour de l'édition de code ciblée, du résumé, de la classification ou des appels d'outils simples. Le surplus de performance d'un modèle de pointe ne se voit souvent pas une fois le modèle intégré dans un outil. Notre guide des modèles pour coder aide à dimensionner selon votre matériel.
2. Investissez le temps économisé dans le harnais. Un bon framework agent, des serveurs MCP bien choisis, une mémoire de session propre et des évaluations régulières transforment un modèle moyen en assistant réellement utile. C'est exactement le créneau des frameworks agents multi-fournisseurs comme DeepSeek Harness.
3. Soignez les appels d'outils. La fiabilité d'un agent local dépend d'abord de la qualité des appels d'outils : formats, schémas, gestion des erreurs. Les détails de configuration font plus de différence que le choix entre deux modèles voisins.
4. Routez intelligemment. Pour les 5 % de tâches qui exigent réellement un modèle de pointe, un flux hybride local et cloud garde le meilleur des deux mondes : le raisonnement lourd chez un fournisseur, les données sensibles et le quotidien sur votre machine.

Il y a aussi l'argument de souveraineté. Les poids ouverts tournent sur votre matériel, sans télémétrie ni kill switch et l'outillage qui les entoure — Ollama, frameworks agents, MCP — est lui-même open source. Vous n'êtes plus client d'un fournisseur : vous êtes l'opérateur de votre propre pile, exactement comme administrer ses propres serveurs GNU/Linux plutôt que louer un service fermé.

Faire tourner ces modèles avec Ollama

Les quatre modèles ouverts du peloton de tête sont disponibles sur Ollama. Kimi K3, GLM-5.3 et GLM-5.3 Flash n'y existent qu'en version cloud (hébergée par les serveurs d'Ollama, un compte est nécessaire) tandis que Qwen3.8 tourne entièrement en local :

# Via Ollama Cloud (compte requis)
ollama run kimi-k3:cloud
ollama run glm-5.3:cloud
ollama run glm-5.3-flash:cloud

# Qwen3.8 (27B) — entièrement en local, environ 18 Go sur disque
# Le modèle le plus récent du peloton, publié en septembre 2026
ollama run qwen3.8

Pour une stack 100 % locale, Qwen3.8 est donc le choix naturel des quatre — et il couvre l'essentiel des besoins courants. Notre guide des modèles pour coder vous aide à l'adapter à votre matériel.

En résumé

Le rapport Mozilla confirme une bascule : la performance du modèle n'est plus le facteur différenciant. Les modèles ouverts sont à 57-60 quand les modèles fermés sont à 61-63, pour une fraction du prix et ils traitent déjà plus d'un tiers des tokens en production. Ce qui sépare un projet qui fonctionne d'un projet qui échoue, c'est le travail autour du modèle : le harnais, les outils, l'intégration et l'évaluation.

La conclusion pratique est simple. Arrêtez de comparer des tableaux de benchmarks et regardez votre outillage. Un modèle local bien outillé, avec de bons appels d'outils, un contexte bien géré et des évaluations honnêtes, fera plus pour votre productivité que le dernier modèle de pointe consulté via une API. Le modèle est une commodité. L'outil, c'est votre avantage.