Il est 01:40 et le worker d'extraction de factures tourne sans souci. Le problème, c'est la ligne de coût dans le log des jobs : quelques centaines de PDF, chacun avec un bon de livraison scanné agrafé, et chaque appel part vers le seul modèle choisi par quelqu'un lors d'un sprint planning il y a dix-huit mois. Personne n'est revenu sur ce choix, parce que le nom du modèle traîne à six endroits, dont deux dans un prompt builder qui formate aussi les dates. C'est à cette codebase que je pense cette semaine, alors que Mistral sort Large 4. Ma position : le modèle est un travail tout à fait respectable, mais pour nous, l'intérêt principal de cette sortie, c'est l'argument qu'elle fournit pour construire des applis PHP où changer de modèle tient en une ligne de config, pas en un refactoring.

Commence par les chiffres, parce qu'ils plaident contre le choix de Large 4 sur des critères généraux. Sur l'Artificial Analysis Intelligence Index, il atterrit à 38. MiMo-V2.6-Pro de Xiaomi est à 46, GLM-5.3 Max à 45, et Sonnet 5.5 et Opus 5.5 d'Anthropic montent à 56 et 58 en effort maximal. La comparaison la plus cruelle, c'est GPT-6 Luna Max : lui aussi à 38, il coûte environ $0.07 par tâche de l'index contre à peu près $1.13 pour Large 4, avec environ 140 millions de tokens en sortie là où le modèle de Mistral en brûle près de 200 millions. Même score, une facture standardisée à peu près seize fois plus lourde. Si ta seule question est de savoir quel endpoint te donne le plus de raisonnement par euro, la réponse est ailleurs, et je ne vais pas prétendre le contraire.

C'est l'objection la plus solide, et elle mérite d'être prise au sérieux. La plupart d'entre nous qui construisons du SaaS sur Laravel ou Symfony n'avons aucune clause de souveraineté dans nos contrats. On a un budget, un objectif de latence et un product owner qui veut que la fonction de résumé arrête d'inventer des noms de clients. Pour cette équipe, brancher un modèle à 38 points au tarif le plus élevé est un mauvais calcul, et la fidélité à un labo européen ne paiera pas la facture. Petite nuance à la nuance : l'index utilise les tarifs catalogue de Mistral, $1.36 par million de tokens en entrée et $4.18 par million en sortie, alors que la preview publique tourne actuellement à moitié prix, $0.68 et $2.09. C'est moins cher, mais on reste très loin du territoire de Luna.

C'est là que mon avis diverge. Le score global est une moyenne sur dix évaluations, et ton application n'est pas une moyenne. Large 4 atteint environ 59.9% sur AutomationBench, les workflows multi-étapes façon e-mails et tableurs, ce qui le place à quelques points de GLM-5.3 Max à 62% et à peu près au niveau de MiMo à 59%. Sur l'évaluation documentaire GDP.pdf d'Artificial Analysis, il obtient 19% là où GLM-5.3 Max plafonne à 11%. Il accepte nativement les images grâce à un encodeur visuel de 1,6 milliard de paramètres, alors que le GLM-5.3 hébergé par Mistral ne traite que du texte. Mon job de bons de livraison se soucie exactement de ce segment-là et pas du tout des maths de compétition. Un modèle peut perdre au classement et rester le bon choix pour une file d'attente donnée.

Et regarde ce que fait Mistral lui-même. Sa propre plateforme sert déjà GLM-5.3 de Z.ai, sans modification, à côté du modèle phare maison. L'éditeur te dit, sous forme de produit, que le bon modèle dépend de la tâche et du mois. Si l'entreprise qui a entraîné un modèle de 1,05 billion de paramètres, dont 49 milliards actifs par étape, sur environ 4 000 GPU Grace Blackwell, est à l'aise pour envoyer ses clients vers les poids d'un concurrent, alors nos applis peuvent bien traiter le nom du modèle comme une variable d'environnement. Concrètement : une interface pour l'appel, un mapping par tâche dans la config, et une fixture d'évaluation de vingt ou trente vraies entrées que tu relances à chaque nouvelle sortie. Du PHP ennuyeux. Exactement celui qu'on sait bien faire.

Reste le client qui, lui, a la clause. Secteur public, santé, un fournisseur industriel qui refuse qu'un log de diagnostic quitte l'UE. Pour lui, la vraie nouvelle, ce sont les poids ouverts que Mistral annonce pour plus tard ce mois-ci, parce qu'un modèle que tu peux faire tourner sur une infra que tu contrôles change la discussion avec les achats bien plus que n'importe quel score d'index. Le saut depuis Medium 3.5, qui obtenait 14 sur le même index, jusqu'à 38, c'est ce qui rend cette option enfin exploitable pour des workloads d'agents. Il y a un an, j'aurais dit à ce genre de client d'accepter un modèle nettement plus faible ou une API étrangère. Aujourd'hui, l'écart est un arbitrage coût et qualité que tu peux mesurer sur tes propres fixtures.

Donc je ne te dis pas de passer à Large 4, et je ne te dis pas non plus de l'ignorer. Je te dis que cette sortie révèle combien de nos intégrations sont incapables de se poser la question à moindre coût. Si tester un nouveau modèle t'oblige à toucher un prompt builder, un DTO et trois classes de service, tu ne le benchmarkeras jamais, et tu continueras à payer pour cette décision de sprint planning indéfiniment. Fais du modèle une valeur modifiable, garde un petit jeu de tests honnête, et laisse chaque job désigner son gagnant. Certains mois ce sera Mistral, et bien d'autres mois, non.

Où places-tu la limite dans ta propre stack : est-ce que tu routes par tâche avec une table de correspondance en acceptant la maintenance de prompts en plus, ou est-ce que tu standardises sur un seul fournisseur et tu absorbes l'écart de coût pour garder une codebase plus simple ?