La bataille entre modèles d’IA propriétaires et modèles ouverts change de nature. Pendant longtemps, les grands modèles fermés d’OpenAI, Anthropic, Google ou d’autres laboratoires dits « frontier » ont semblé hors d’atteinte. Ils dominaient les classements, les usages professionnels et l’imaginaire collectif autour de l’intelligence artificielle générative.
Mais un signal devient difficile à ignorer : selon plusieurs acteurs de l’écosystème open source et cloud native, les modèles à poids ouverts ne seraient plus qu’à quatre à cinq mois de retard sur les meilleurs modèles fermés, tout en pouvant coûter nettement moins cher à grande échelle. Dans certains scénarios d’inférence intensive, l’écart de coût pourrait atteindre un facteur dix, voire davantage selon l’infrastructure retenue.
Ce constat ne signifie pas que les entreprises doivent abandonner du jour au lendemain les API propriétaires. Il invite plutôt à poser une question stratégique : paie-t-on réellement l’intelligence du modèle, ou surtout l’écosystème commercial qui l’entoure ?
Une révolution plus discrète que spectaculaire
L’IA ouverte avance souvent moins bruyamment que les annonces des grands laboratoires privés. Pourtant, son évolution rappelle des bascules déjà observées dans l’histoire du logiciel : Linux face à Windows, MySQL face à Oracle, Kubernetes face à certaines offres d’orchestration propriétaires, ou encore Android dans le mobile.
Dans ces précédents, les solutions ouvertes ont d’abord été perçues comme moins intégrées, moins pratiques ou moins adaptées à l’entreprise. Puis elles ont rattrapé leur retard, attiré les développeurs, imposé des standards et, dans certains cas, dépassé les piles propriétaires en adoption ou en flexibilité.
Le même scénario pourrait se rejouer avec l’IA générative. Les modèles fermés gardent une avance sur certains benchmarks, sur la qualité globale de l’expérience développeur et sur des outils d’entreprise prêts à l’emploi. Mais cette avance se réduit. Et lorsque l’écart fonctionnel devient marginal, le coût par token, la portabilité, la confidentialité et le risque de verrouillage prennent beaucoup plus de poids.
Ce que les entreprises paient vraiment avec les grands modèles fermés
Boris Renski, fondateur et CEO d’Apelogic, estime que les grands laboratoires d’IA entretiennent une forme de peur autour de modèles supposés uniques, extrêmement dangereux ou proches d’une intelligence générale artificielle. Selon lui, cette narration détourne l’attention d’un point plus concret : les modèles ouverts progressent rapidement et deviennent suffisamment performants pour de nombreux usages d’entreprise.
Son analyse est directe : dans beaucoup de cas, les clients ne paient pas uniquement pour la capacité brute du modèle, mais pour des fonctionnalités d’entreprise qui l’enveloppent. Parmi elles :
- l’intégration avec les fournisseurs d’identité et les annuaires d’entreprise ;
- les connecteurs vers les outils internes et les protocoles émergents comme MCP ;
- l’observabilité, les journaux, les métriques et les contrôles de conformité ;
- le routage intelligent entre modèles ;
- la mémoire, les garde-fous et la gestion des workflows agentiques ;
- le support commercial, les contrats de service et les garanties opérationnelles.
Ces fonctions sont utiles, parfois indispensables. Mais elles ne relèvent pas toujours de l’intelligence fondamentale du modèle. Elles peuvent aussi être construites au-dessus de modèles ouverts, via une architecture interne ou des plateformes spécialisées.
Le risque de verrouillage : le nouveau scénario à la Oracle ?
Le débat ne porte pas seulement sur le prix immédiat. Il concerne aussi le verrouillage fournisseur. Une entreprise qui signe un contrat pluriannuel avec un fournisseur de LLM propriétaire peut rapidement intégrer ce modèle au cœur de ses processus : support client, recherche interne, génération de code, analyse documentaire, automatisation métier, outils d’aide à la décision.
Plus ces usages se multiplient, plus la migration devient complexe. Les prompts, les évaluations, les chaînes d’agents, les connecteurs, les politiques de sécurité et les comportements attendus sont souvent calibrés pour un modèle spécifique. Changer de fournisseur n’est alors plus une simple modification d’API.
Jonathan Bryce, directeur exécutif de la Cloud Native Computing Foundation, résume l’enjeu : payer beaucoup plus cher pour quelques mois d’avance n’est pas nécessairement une stratégie d’IA durable. Comme les classements évoluent vite, les développeurs ont intérêt à concevoir des applications capables de changer de modèle et de matériel sans devoir tout reconstruire.
La bonne question à poser avant un contrat LLM
Avant de s’engager fortement avec un fournisseur fermé, une équipe technique devrait poser quelques questions simples :
- Peut-on remplacer le modèle sans réécrire toute l’application ?
- Les prompts et les évaluations sont-ils portables ?
- Les données sensibles quittent-elles l’environnement contrôlé de l’entreprise ?
- Quels journaux sont conservés par le fournisseur, et pendant combien de temps ?
- Le coût reste-t-il acceptable si l’usage est multiplié par dix ou par cent ?
- Existe-t-il un plan B avec un modèle ouvert ou auto-hébergé ?
Le coût des tokens devient un sujet de direction générale
À petite échelle, la facture d’un modèle propriétaire peut sembler raisonnable. Le problème apparaît lorsque l’usage passe du prototype à la production massive. Les applications agentiques, les assistants internes, les analyses documentaires longues ou les workflows de génération de code peuvent consommer des volumes considérables de tokens.
La société Featherless, spécialisée dans l’inférence serverless, affirme avoir fortement réduit les coûts d’inférence de classe frontier en optimisant le modèle ouvert chinois Z.ai GLM 5.2 sur une infrastructure cloud privée AMD. Selon ses estimations, pour une équipe consommant environ 100 milliards de tokens par mois à pleine utilisation, la facture annuelle atteindrait environ 1 557 600 dollars avec GPT-5.5 et 1 506 000 dollars avec Claude Opus 4.8.
Dans le scénario présenté par Featherless, une option en cloud privé basée sur GLM 5.2 reviendrait à un tarif annuel fixe d’environ 90 000 dollars, soit plus de 1,46 million de dollars d’économies par an pour une équipe utilisant fortement l’inférence.
Ces chiffres doivent être interprétés avec prudence, car ils dépendent de nombreux paramètres : niveau d’utilisation réel, prix négociés, latence, disponibilité matérielle, taille des contextes, tokenizer, architecture applicative et coût d’exploitation. Mais ils illustrent une tendance claire : à grande échelle, le coût du token peut devenir un poste budgétaire majeur.
Modèles ouverts : de quoi parle-t-on exactement ?
Dans le débat public, les termes « open source », « open weight » et « modèle ouvert » sont souvent mélangés. Pourtant, ils ne désignent pas toujours la même réalité.
Open source
Un projet open source donne accès au code source sous une licence permettant l’étude, la modification et la redistribution, avec des conditions précises. Dans l’IA, l’open source complet est plus complexe, car un modèle repose aussi sur des données d’entraînement, des scripts, des poids, une méthode de pré-entraînement et des choix d’alignement.
Open weight
Un modèle à poids ouverts rend accessibles ses poids, ce qui permet de l’exécuter, de l’ajuster ou de l’héberger sur sa propre infrastructure. Cela ne signifie pas toujours que les données d’entraînement, le code complet ou la méthode exacte de construction sont disponibles.
Pourquoi cette distinction compte
Pour une entreprise, le point décisif n’est pas seulement idéologique. Il s’agit de savoir si le modèle peut être déployé dans un environnement contrôlé, audité, optimisé et remplacé si nécessaire. Un modèle open weight peut déjà offrir une grande liberté opérationnelle, même s’il n’est pas open source au sens strict.
GLM 5.2, AMD et la fin du réflexe Nvidia-only ?
L’un des aspects intéressants du cas Featherless concerne le matériel. L’entreprise indique avoir optimisé GLM 5.2 sur une infrastructure cloud privée AMD, alors que l’écosystème de l’IA générative reste très associé aux GPU Nvidia.
Isaac Gemal, responsable des relations développeurs chez Featherless, reconnaît que le déploiement n’a pas été trivial. La demande pour GLM 5.2 aurait dépassé les prévisions, rendant l’allocation des ressources GPU plus difficile au départ. L’entreprise explique avoir travaillé avec Tensorwave pour améliorer les déploiements de grands modèles sur cette infrastructure.
Ce point est important pour le marché : si les modèles ouverts deviennent plus portables entre différentes architectures matérielles, les entreprises gagnent en pouvoir de négociation. Elles peuvent optimiser entre coût, disponibilité, performance et souveraineté, au lieu de dépendre d’un seul fournisseur de modèle ou d’un seul type de matériel.
La confidentialité reste un critère déterminant
La question des journaux et de la conservation des données revient souvent dans les usages professionnels de l’IA. Les grands fournisseurs promettent généralement de ne pas entraîner leurs modèles sur les données clients dans certains cadres contractuels, mais les politiques de logging, d’abus, de sécurité ou de conservation peuvent comporter des exceptions.
Pour Isaac Gemal, les développeurs doivent lire attentivement les conditions liées aux requêtes considérées comme problématiques ou « unsafe ». Dans certains cas, des données peuvent être conservées plus longtemps pour analyse, modération ou sécurité, selon les règles internes du fournisseur.
Ce n’est pas nécessairement rédhibitoire, mais cela impose une gouvernance claire. Pour les secteurs réglementés comme la santé, la finance, l’industrie ou le secteur public, la possibilité d’exécuter un modèle dans un environnement privé peut devenir un avantage majeur.
Bonnes pratiques pour limiter le risque
- Éviter d’envoyer des données personnelles ou secrets d’entreprise dans des prompts non contrôlés.
- Mettre en place une couche de filtrage et de masquage avant l’appel au modèle.
- Centraliser les appels LLM via une passerelle interne plutôt que laisser chaque équipe utiliser sa propre clé API.
- Conserver des traces d’audit côté entreprise, indépendamment du fournisseur.
- Tester régulièrement des modèles alternatifs pour maintenir une capacité de migration.
Que disent les développeurs qui testent ces modèles au quotidien ?
Les benchmarks sont utiles, mais ils ne suffisent pas. Les développeurs évaluent surtout les modèles sur des tâches concrètes : recherche technique, génération de composants, résolution de problèmes algorithmiques, écriture de tests, refactorisation, documentation ou exploration d’architecture.
Kacper Michalik, ingénieur logiciel chez Screen Studio en Pologne, a comparé GLM 5.2 avec des modèles fermés comme Claude Opus 4.8 dans des travaux réels. Sur des recherches de stack data engineering, il estime que GLM 5.2 a fourni des résultats similaires, voire meilleurs dans certains cas, avec une capacité à élargir le sujet et à produire des éléments visuels utiles.
Sur un problème de type entretien technique, il observe des différences de style : GPT aurait bien détaillé le raisonnement sans forcément fournir de code, Claude aurait donné une réponse claire mais plus concise, tandis que GLM aurait proposé un compromis avec une explication structurée et une solution Python fonctionnelle.
Il note aussi que GLM 5.2 a généré correctement un composant de formulaire React avec Zod et TypeScript, typé proprement et doté d’erreurs de validation claires. En revanche, le modèle n’a pas été irréprochable sur une demande plus ambitieuse : créer une scène 3D avec React et TypeGPU dans un seul fichier. Le rendu n’a pas fonctionné comme attendu, et des limites d’usage ont également été rencontrées.
Les modèles ouverts sont-ils vraiment dix fois moins chers ?
La réponse courte : pas toujours. Le facteur dix dépend du volume, du modèle, du fournisseur, du matériel, du taux d’utilisation et du mode de déploiement.
Phil Whittaker, staff engineer chez Umbraco, nuance l’affirmation. Il estime que les modèles open weight sont bien proches des modèles frontier, avec un retard de l’ordre de quatre à cinq mois, mais que l’écart de coût ne peut pas être généralisé. Selon lui, passer par un fournisseur tiers peut réduire les coûts, mais les différences de tokenizers entre modèles peuvent limiter les gains. Dans certains cas, la réduction pourrait être bien inférieure à 90 %.
L’auto-hébergement est une autre option, mais il suppose des investissements initiaux : serveurs, GPU, réseau, stockage, supervision, sécurité, maintenance, mises à jour et expertise interne. Une entreprise qui ne dispose pas déjà d’une équipe infrastructure solide peut sous-estimer cette charge.
Autrement dit, le calcul doit intégrer le coût total de possession, pas seulement le prix affiché par million de tokens.
Les trois scénarios les plus réalistes
- API propriétaire : simple à intégrer, très performante, mais potentiellement coûteuse et verrouillante à grande échelle.
- Modèle ouvert via fournisseur tiers : compromis entre flexibilité et simplicité, avec une économie variable selon les volumes.
- Auto-hébergement ou cloud privé : contrôle maximal, coûts optimisables à grande échelle, mais complexité opérationnelle plus élevée.
Sécurité, origine des modèles et souveraineté : le débat reste ouvert
Un autre sujet sensible concerne l’origine des modèles. Plusieurs modèles ouverts performants viennent de Chine, ce qui soulève des questions de sécurité, de conformité, de contrôle et de dépendance géopolitique.
Le risque n’est pas identique selon le mode d’usage. Se connecter directement à une API hébergée par un fournisseur étranger n’a pas les mêmes implications que télécharger des poids, les auditer autant que possible, les exécuter dans une infrastructure privée et contrôler les flux de données.
La prudence est donc nécessaire, mais elle ne doit pas conduire à une conclusion simpliste. Les modèles ouverts peuvent aussi renforcer la souveraineté lorsqu’ils permettent d’éviter l’envoi de données sensibles vers une API fermée et distante. Tout dépend de la chaîne complète : licence, hébergement, supervision, sécurité applicative, filtrage des données et gouvernance interne.
Le futur de l’IA d’entreprise se jouera peut-être au-dessus du modèle
À mesure que les modèles deviennent plus performants et plus interchangeables, la valeur pourrait se déplacer vers ce que certains appellent le « harness » : l’ensemble des outils qui pilotent le modèle.
Ce niveau inclut :
- la qualité des prompts système ;
- les outils accessibles au modèle ;
- la récupération augmentée par génération, ou RAG ;
- les bases vectorielles et les index documentaires ;
- les évaluations automatiques ;
- les règles de sécurité ;
- la mémoire applicative ;
- la capacité à router chaque requête vers le bon modèle.
Dans ce contexte, le meilleur choix n’est pas forcément d’utiliser le modèle le plus avancé pour toutes les tâches. Une architecture mature peut employer un petit modèle rapide pour les demandes simples, un modèle ouvert spécialisé pour certaines opérations internes, et un modèle frontier propriétaire uniquement pour les tâches qui justifient son coût.
Ce que les équipes tech devraient faire maintenant
Pour les entreprises et les développeurs, l’enjeu n’est pas de choisir un camp de manière dogmatique. Il s’agit de construire une stratégie qui évite la dépendance excessive, maîtrise les coûts et préserve la capacité d’innovation.
Quelques actions concrètes peuvent être engagées dès maintenant :
- Créer un banc d’essai interne avec plusieurs modèles propriétaires et ouverts sur les mêmes cas d’usage.
- Mesurer la qualité réelle sur des tâches métier, pas seulement sur des benchmarks publics.
- Suivre le coût par workflow, plutôt que le simple coût par token.
- Isoler la couche modèle derrière une abstraction technique pour faciliter les remplacements.
- Évaluer la latence et pas uniquement la qualité de réponse.
- Tester la confidentialité avec des scénarios réalistes de données sensibles.
- Prévoir une stratégie multi-modèles pour éviter de confier toute la chaîne de valeur à un seul fournisseur.
Conclusion : l’IA ouverte n’a plus besoin d’être parfaite pour devenir stratégique
Les modèles ouverts ne dominent pas encore systématiquement les meilleurs modèles fermés. Ils peuvent être moins rapides, moins pratiques à exploiter, plus complexes à déployer et parfois moins stables sur certains usages avancés. Mais ils progressent vite, deviennent compétitifs sur de nombreuses tâches et changent l’équation économique de l’IA d’entreprise.
Si l’écart de performance se mesure en quelques mois tandis que l’écart de coût se mesure en multiples, les directions techniques ne peuvent plus ignorer l’option ouverte. Le choix le plus robuste ne sera probablement ni 100 % propriétaire ni 100 % open weight, mais une architecture capable d’orchestrer plusieurs modèles selon les besoins.
La vraie course ne consiste donc plus seulement à savoir quel laboratoire possède le meilleur modèle du moment. Elle consiste à savoir quelles entreprises sauront construire une infrastructure IA portable, observable, sécurisée et économiquement soutenable.