Les modèles d'IA deviennent des commodités. Tant mieux.
Quand Qwen, DeepSeek ou Kimi rattrapent OpenAI à prix cassé, le problème n'est plus de choisir le modèle du mois. C'est de construire la plateforme qui permet de s'adapter.
La réunion commence avec un tableau. C'est rarement bon signe. Sur la première colonne, les noms rassurants: GPT, Claude, Gemini, Mistral. Sur la deuxième, les noms arrivés plus vite que le processus achat: DeepSeek, Qwen, Kimi, GLM. Ensuite viennent les scores. MMLU, GPQA, SWE-bench, HumanEval, un benchmark interne dont personne ne retrouve le script, et une colonne "prix" qui change tous les quinze jours.
Tout le monde regarde le tableau avec l'air de choisir une base de données pour les dix prochaines années. Sauf qu'on choisit le modèle qui va résumer des contrats, répondre à des conseillers, écrire du code, appeler des outils, manipuler des données sensibles, et expliquer six mois plus tard pourquoi il a pris une décision bizarre un mardi à 17 h 42.
Donc la question arrive, habillée comme une question raisonnable: "Quel est le meilleur modèle ?". Mauvaise question. Alors bon, elle est pas idiote, elle arrive juste beaucoup trop tôt.
Le meilleur modèle pour quoi ? Pour quelle donnée ? Avec quel budget, quelle latence ? Avec quel niveau de preuve ? Avec quel fallback ? Avec quelles contraintes de résidence, de licence, de support, Et surtout: qu'est-ce qu'on doit reconstruire si, dans trois mois, le meilleur modèle devient le troisième meilleur modèle avec une grille tarifaire insultante ?
À ce moment-là, le tableau ressemble moins à une stratégie IA qu'à un classement de pneus lu par quelqu'un qui n'a pas encore regardé la voiture.
Le benchmark du mois
Les benchmarks publics ont leur utilité (certe contestable) . Ils évitent au moins de discuter au pifometre. Ils montrent des tendances. Ils rappellent aussi que certains modèles absents de la shortlist du comité innovation tiennent la comparaison sur des tâches sérieuses. Mais un benchmark public n'est pas une décision de production.
Un score SWE-bench ne dit pas si le modèle respecte vos attentes, vos règles de sécurité, et votre dette technique qui a survécu à trois réorganisations. Un score de raisonnement ne dit pas si le modèle explique sa réponse avec les bonnes sources internes. Un prix au million de tokens ne dit pas combien vous paierez quand le système relit quatre fois le même PDF parce que personne n'a configuré le cache.
Le benchmark répond à une question de laboratoire: "que sait faire ce modèle dans ces conditions ?" L'entreprise pose une autre question: "que devient mon système quand ce modèle est mis dans une chaîne de responsabilité ?"
C'est moins sexy. C'est aussi là que les projets arrêtent de ressembler à des démos.
Le modèle n'est plus le produit
Pendant un moment, on a parlé des modèles comme si le modèle était le produit. C'était compréhensible. Les premiers sauts de capacité étaient suffisamment violents pour écraser tout le reste. Quand un système passe de "complète vaguement une phrase" à "raisonne, code, explique et résume", le cerveau humain a tendance à fixer le phare et oublier la route.
Cette phase se termine.
Le modèle devient une dépendance d'exécution. Une grosse dépendance, chère, sensible, parfois merveilleuse, parfois pénible. Mais une dépendance quand même. Comme une base de données, un provider cloud, un moteur de recherche, un runtime. On ne la choisit pas parce qu'elle a gagné une capture d'écran. On la choisit parce qu'on sait l'exploiter, la mesurer, la remplacer, et survivre à ses changements d'humeur.
Le vrai produit, pour une entreprise, n'est pas "nous utilisons le modèle X". C'est le système qui permet de répondre :
- Continuité
- pour ce cas d'usage, ces données passent par ce modèle, avec ce fallback, et l'échec est visible.
- Contrôle
- ce modèle peut appeler ces outils, avec ces droits, sous ces conditions, et pas un millimètre de plus.
- Preuve
- cette réponse a été produite avec ces sources, ces paramètres, cette version de prompt, cette version de modèle, à ce moment-là.
- Réversibilité
- si le fournisseur change ses prix, ses règles ou son niveau de service, on change le routage sans rouvrir tous les workflows au tournevis.
Le modèle est important. Le modèle seul est une pièce posée sur une table.
La Chine a cassé le confort du marché
DeepSeek a surtout eu le mérite de rendre la gêne impossible à cacher. Le papier DeepSeek-R1 a montré une trajectoire de raisonnement compétitive, ouverte à la discussion technique, avec une économie de moyens qui a forcé tout le monde à relire ses hypothèses sur le coût des modèles premium. On peut discuter les chiffres, les méthodes, la distillation, les dépendances matérielles. Très bien. Le point reste là: le marché a vu qu'une partie de la capacité qu'il croyait rare pouvait arriver ailleurs, vite, moins cher, et avec des poids disponibles.
Qwen a ajouté une autre forme de malaise. Le dépôt Qwen3 ne raconte pas seulement "Alibaba a publié des modèles". Il raconte qu'un acteur cloud chinois peut traiter les modèles ouverts comme une stratégie de distribution, d'écosystème et de pression concurrentielle. Un brief Stanford DigiChina / HAI décrit d'ailleurs un écosystème chinois de modèles à poids ouverts plus large que DeepSeek. Kimi, GLM, MiniMax et d'autres ont poussé dans la même direction: plus de modèles capables, plus de variantes, plus de pression sur les prix, plus de migraines pour les shortlists stables.
Pour etre tres clair, on ne parle pas de "Chine contre Occident". Cette lecture est trop confortable. Elle permet de transformer un problème d'architecture en débat géopolitique, donc de ne pas le résoudre.
La vraie leçon est plus froide: le modèle de fondation généraliste devient un marché concurrentiel. Pas parfaitement liquide. Pas totalement interchangeable. Pas sans risques. Mais concurrentiel. Et quand un marché devient concurrentiel, la marge se déplace. Elle quitte la pièce et va vers l'intégration, la distribution, les garanties, la conformité, le support, et la capacité à verrouiller le client sans que ça se voie trop.
En clair: le modèle devient une commodité. Les pièges, eux, montent d'un étage.
Les modèles premium gardent une place, pas un droit divin
Il serait absurde d'en conclure que les modèles premium ne servent plus à rien. Ils restent souvent les meilleurs sur les tâches difficiles, ambiguës, longues, multimodales, agentiques, ou simplement mal spécifiées. Quand le coût de l'erreur est élevé, il peut être parfaitement rationnel de payer le meilleur modèle disponible. Personne ne gagne des points d'architecture en remplaçant un modèle excellent par un modèle moins cher qui hallucine avec enthousiasme.
Mais il y a une différence entre "ce modèle est le meilleur pour ce problème" et "ce modèle devient le chemin par défaut de toute l'entreprise".
Le moat brut des modèles premium est fragile parce que la capacité diffuse. Elle est distillée. Elle est imitée. Elle est rattrapée par des modèles spécialisés. Elle est compressée par de meilleurs runtimes, du batching, du caching, des architectures MoE, des quantisations, des accélérateurs, et une guerre des prix. Les rapports d' Artificial Analysis suivent déjà cette chute du coût d'inférence à performance comparable. Les grilles tarifaires ressemblent de moins en moins à du marbre.
Les grands fournisseurs le savent. C'est pour ça que leur différenciation migre ailleurs: IDE, agents managés, cloud, sécurité, connecteurs, workflows, observability, compliance, support entreprise. Le modèle reste le moteur marketing, mais la capture se fait par la plateforme.
Ce n'est pas nouveau. Le cloud n'a pas gagné uniquement parce qu'il savait démarrer des VM. Il a gagné parce qu'il a construit autour des VM une forêt de services, de permissions, de facturation, de monitoring, de contrats, de formations, de certifications, et de dépendances dont personne ne sort un vendredi après-midi.
L'IA suit le même chemin. Avec plus de tokens et moins de pudeur.
Sans evals, la commoditisation ne sert à rien
Le fantasme de la commoditisation, c'est le bouton magique: aujourd'hui GPT, demain Qwen, vendredi DeepSeek, lundi un modèle local, le tout routé automatiquement comme un CDN. Dans la vraie vie, sans evals internes, ce bouton est un générateur d'incidents.
Une entreprise ne peut pas profiter de modèles interchangeables si elle ne sait pas mesurer ce qu'elle échange. Il faut des evals par workflow, pas seulement par modèle. Résumer un contrat fournisseur, répondre à un conseiller bancaire, extraire des informations d'un dossier sinistre, écrire une migration SQL, classer une demande RH, appeler un outil de ticketing: ce ne sont pas des variantes décoratives du même problème. Ce sont des chaînes de responsabilité différentes.
Une eval utile doit au moins répondre à quelques questions ennuyeuses :
- Qualité
- le modèle donne-t-il la bonne réponse, avec les bonnes sources, dans les cas normaux et les cas tordus ?
- Risque
- que fait-il quand il ne sait pas, quand les sources se contredisent, quand l'utilisateur pousse, quand l'outil interne refuse ?
- Coût
- combien coûte réellement le workflow complet, avec retrieval, contexte, retries, cache raté, logs, modération, fallback et supervision ?
- Opérabilité
- peut-on rejouer le cas, comprendre l'échec, comparer deux modèles, et expliquer le changement hors notebook ?
Sans evals, le modèle le moins cher est juste celui qui se trompe sans laisser de facture lisible.
Et sans evals, la négociation fournisseur ressemble à une partie de poker où vous ne connaissez pas vos cartes. Le vendor vous dit que son nouveau modèle est 30 % meilleur. Meilleur sur quoi ? Vos contrats ? Vos tickets ? Vos langues ? Vos règles de conformité ?
Tant que vous ne savez pas mesurer votre propre réalité, vous achetez celle du fournisseur.
La plateforme devient le vrai chantier
Si les modèles deviennent des dépendances routables, la plateforme GenAI interne devient le vrai produit. Pas le portail avec trois assistants et un logo en haut à gauche. La plateforme.
Elle doit porter l'identité, les permissions, les politiques de données, les prompts versionnés, les connecteurs, les journaux, les traces, les budgets, les caches, les evals, les fallbacks, les modèles autorisés, les modes dégradés, les exports d'audit, et les runbooks d'incident.
C'est là que la bataille entreprise se joue. Pas dans le prompt magique du directeur innovation. Pas dans le benchmark recopié dans PowerPoint. Dans le routage qui dit: cette demande peut partir vers un modèle premium parce que le risque est faible et la qualité attendue élevée ; celle-ci reste sur un modèle local ; celle-là passe par un modèle spécialisé ; celle-ci est bloquée parce que l'utilisateur demande à l'agent de faire quelque chose qu'il n'a pas le droit de faire.
L'agentique rend ce point encore plus brutal. Un chatbot qui hallucine une réponse, c'est déjà pénible. Un agent qui hallucine une action avec des droits internes, c'est un incident qui a mis une veste de productivité.
La question n'est donc pas "quel modèle raisonne le mieux ?" La question est: qui a le droit de raisonner avec quels outils, sur quelles données, avec quelle traçabilité, et quelle procédure de retour arrière quand le raisonnement part visiter le mur ?
Dans un grand compte régulé, l'IA générative n'est pas une collection de chats. C'est une couche d'exécution distribuée qui touche données, workflows, utilisateurs, décisions et preuves. Si cette couche n'a pas d'architecture, elle en aura une quand même. Simplement, elle sera composée de raccourcis, de contrats, de variables d'environnement, de prompts copiés, de connecteurs trop permissifs et de décisions prises par le dernier projet qui a livré une démo.
On appelle souvent ça "aller vite". Plus tard, on appelle ça "dette".
Ce que le comité devrait demander
La pire question est: "quel modèle avez-vous choisi ?" Elle n'est pas inutile. Elle est juste insuffisante au point d'être dangereuse quand elle arrive seule. Voici de meilleures questions :
- Données
- quels types de données peuvent aller vers quels modèles, dans quelles régions, sous quelles licences, avec quelles traces ?
- Routage
- comment décide-t-on entre modèle premium, modèle à poids ouverts, modèle local, modèle spécialisé, petit modèle, grand modèle, mode rapide, mode raisonnement ?
- Evals
- où sont les evals internes qui justifient ce routage, et qui les maintient quand les workflows changent ?
- Coût
- quel est le coût complet d'un workflow, pas seulement le prix du token affiché sur la brochure ?
- Réversibilité
- que se passe-t-il si un fournisseur double ses prix, ferme une option, modifie ses conditions, change son modèle par défaut, ou dégrade la latence ?
- Audit
- quels logs permettent de rejouer une réponse ou une action six mois plus tard, avec la version du modèle, du prompt, des sources et des outils appelés ?
- Agentique
- quels outils un agent peut-il appeler, avec quels droits, sous quelles limites, et comment coupe-t-on le circuit quand il se comporte mal ?
Ces questions sont moins glamour qu'un classement de modèles. Elles sont aussi beaucoup plus proches de la production.
Ce que ça change
La commoditisation des modèles est une bonne nouvelle pour les entreprises. Elle réduit le pouvoir magique du fournisseur unique. Elle rend les prix contestables. Elle oblige les plateformes à se différencier autrement que par une capture d'écran. Elle donne une chance aux architectures hybrides, aux modèles spécialisés, aux modèles locaux, et aux stratégies de routage qui évitent d'envoyer toute demande RH dans le même moteur que le copilote de développement.
Mais elle ne donne rien gratuitement.
Si vous n'avez pas de plateforme, la commoditisation devient juste plus de choix à mal gérer. Plus de modèles dans les slides. Plus de clauses à relire. Plus de providers dans les variables d'environnement. Plus de chemins de secours qui deviennent principaux parce que quelqu'un a oublié de supprimer un flag.
Le modèle devient le moteur. Très bien. Un moteur se change. Un moteur se compare. Un moteur se paie. Un moteur tombe en panne. L'entreprise, elle, doit construire la boîte de vitesses, les freins, le tableau de bord, le carnet d'entretien, et la procédure pour rentrer au garage sans finir dans le fossé.
Ce n'est pas moins ambitieux que "choisir le meilleur modèle". C'est juste beaucoup plus sérieux.