Mistral Timestral : la prévision des ventes et des stocks sur un simple CPU

Mistral Timestral, qu'est-ce que c'est ?

Timestral est la première famille de modèles de fondation de Mistral AI pour les séries temporelles, publiée le 15 octobre 2026. Un modèle de fondation est pré-entraîné une fois, sur un très grand corpus, puis utilisé tel quel. Timestral prévoit donc vos ventes, vos stocks ou votre consommation sans être entraîné sur vos données.

Il existe en quatre tailles : 5M, 28M, 123M et 209M paramètres. Il lit jusqu'à 32 768 pas d'historique et prévoit jusqu'à 1 024 pas d'un coup. Sa sortie n'est pas un chiffre unique : c'est une fourchette de 21 quantiles (des seuils de probabilité, du 1 % au 99 %).

Les poids sont sur Hugging Face, sous une licence MIT modifiée qui exclut les entreprises au-delà d'un seuil de chiffre d'affaires. Il tourne sur CPU, sans GPU.

Sauf mention contraire, les chiffres qui suivent viennent de l'annonce de Mistral, de ses fiches Hugging Face et de son dépôt GitHub. Je les ai relevés le 15 octobre 2026, sans rien tester.

Ce que Timestral change pour la prévision des ventes d'une PME

Une prévision des ventes part de l'historique. Les méthodes classiques, comme ARIMA ou la régression linéaire, s'ajustent série par série. Mistral le rappelle dans son annonce : elles n'apprennent que de l'historique de la série traitée.

Timestral a appris sur une grande variété de séries, en majorité synthétiques. Il applique ce qu'il a appris à une série qu'il n'a jamais vue. C'est ce que Mistral appelle le zero-shot.

Pour une PME, les ordres de grandeur tiennent large. Deux ans de ventes journalières font 730 pas, loin des 32 768 du contexte. Une prévision à 28 jours reste sous la limite de 1 024 pas par passe.

Trois entrées comptent pour des ventes :

• Plusieurs séries liées : les ventes de produits proches se prévoient ensemble, en tenant compte de leurs liens.
• Des covariables futures connues (des variables qu'on connaît à l'avance) : promotions planifiées, jours fériés, ouverture d'un magasin. Mistral cite le calendrier des fêtes et la météo prévue.
• Des covariables catégorielles : le jour de la semaine, un type de canal.

La fourchette change la décision de stock. La médiane est la valeur centrale : une chance sur deux d'être dépassée, selon le modèle. Le quantile à 90 % donne le niveau que les ventes ne devraient dépasser qu'une fois sur dix, selon le modèle. Je dimensionne un stock de sécurité sur ce second chiffre, pas sur la médiane.

« Premier sur trois benchmarks » : ce qui est vérifié au 15 octobre

Mistral affirme que son modèle 209M est premier sur GIFT-Eval, TIME et fev-bench, les trois principaux bancs d'essai publics du domaine. Mistral précise le périmètre : premier parmi les modèles pré-entraînés utilisés en zero-shot. Selon l'éditeur, le 209M bat TimesFM-3 et Falcon-2.0 avec moins de paramètres. Et le 28M bat Chronos-2, environ quatre fois plus grand, sur GIFT-Eval et TIME. Ce sont des déclarations de Mistral, sans validation indépendante à ce jour.

L'annonce dit que les résultats ont été soumis aux classements GIFT-Eval et TIME. Sur GitHub, Mistral a ouvert une demande de fusion par banc d'essai, fev-bench compris. Au 15 octobre, les trois sont encore ouvertes, dont la #234 de GIFT-Eval. Les mainteneurs ne les ont pas encore intégrées.

Les écarts sont minces. Sur GIFT-Eval, la fiche du 209M donne une MASE (erreur moyenne rapportée à celle d'une prévision naïve) de 0,658. Le suivant dans le tableau de la fiche, t0-gamma, est à 0,661. Plus bas vaut mieux.

Un détail invite à la prudence. La version française de l'annonce parle de modèles « 4M » et « 20M », et de résultats « en ligne » sur les classements. La version anglaise et les fiches disent 5M, 28M et « submitted ». Je m'en tiens à ces dernières.

Mistral promet un rapport technique complet. Il n'est pas publié au 15 octobre.

Sans GPU : ce que veulent dire 10 à 140 millisecondes

Le chiffre de Mistral a un périmètre précis : un CPU serveur à 8 threads, trois semaines d'historique au pas de 15 minutes, un jour à prévoir. Dans ce cas, l'éditeur annonce 10 ms avec le 5M et 140 ms avec le 209M.

Toujours selon l'éditeur, le 28M est cinq fois plus rapide que le 209M. Le 123M arrive à 0,2 % du score du 209M, pour les trois quarts de sa latence.

Les poids restent légers : 21 Mo pour le 5M, 111 Mo pour le 28M, 837 Mo pour le 209M, en fp32. Sur le papier, un serveur applicatif ordinaire suffit. Pour un recalcul nocturne de quelques milliers de références, la latence n'est pas le sujet.

La licence « MIT modifiée » : le seuil des 20 millions de dollars par mois

Le code du dépôt est sous Apache 2.0. Les poids, eux, sont sous une licence « Modified MIT » avec une clause d'exclusion.

La clause est nette. Vous perdez tout droit d'usage si le chiffre d'affaires mensuel consolidé de votre entreprise dépasse 20 millions de dollars le mois précédent. Cela fait 240 millions sur douze mois au même rythme : la plupart des PME en sont loin.

Trois points à lire de près :

• Les dérivés sont couverts : un modèle affiné à partir de Timestral reste soumis au seuil.
• L'employeur compte : le texte vise votre entreprise « ou celle de votre employeur ». Un prestataire salarié d'un grand groupe pourrait être concerné, même pour un client PME. C'est ma lecture, pas un avis juridique.
• Au-delà du seuil, on peut demander une licence commerciale, que Mistral accorde à sa seule discrétion. L'autre voie : ses services hébergés.

C'est la même licence que Devstral 2. Le texte est identique, seule l'année de la mention d'attribution change.

Brancher Timestral sur une application Java

Le seul chemin documenté est Python. Le dépôt fournit un paquet qui dépend de PyTorch, NumPy, safetensors et huggingface_hub, avec Python 3.10 et torch 2.4 au minimum.

Au 15 octobre, le dépôt ne contient aucun export ONNX. Je n'ai trouvé ni endpoint de prévision dans la référence de l'API Mistral, ni prix sur sa page de tarifs. La doc liste bien un identifiant timestral-1-0, en « Public Preview ». Pour une application Java, je passe donc par un petit micro-service Python.

# forecast_service.py : plausible, non exécuté
import numpy as np
from fastapi import FastAPI
from pydantic import BaseModel
from timestral import TimestralForecaster

app = FastAPI()
model = TimestralForecaster.from_pretrained("mistralai/Timestral-28M")

class ForecastRequest(BaseModel):
    history: list[float | None]   # ventes journalières, None = valeur manquante
    horizon: int = 28

@app.post("/forecast")
def forecast(req: ForecastRequest):
    context = np.array([np.nan if v is None else v for v in req.history])
    f = model.forecast(context, prediction_length=req.horizon)
    return {
        "p10": f.quantile(0.1).flatten().tolist(),
        "p50": f.median.flatten().tolist(),
        "p90": f.quantile(0.9).flatten().tolist(),
    }

from_pretrained, forecast, median et quantile viennent du README du dépôt. FastAPI est mon choix, pas celui de Mistral. Côté Spring, un RestClient suffit :

record ForecastRequest(List<Double> history, int horizon) {}
record ForecastResponse(List<Double> p10, List<Double> p50, List<Double> p90) {}

ForecastResponse prevision = RestClient.create("http://forecast:8000")
    .post().uri("/forecast")
    .body(new ForecastRequest(ventesJournalieres, 28))
    .retrieve()
    .body(ForecastResponse.class);

Je n'ai compilé ni exécuté aucun de ces deux blocs. Le README précise que l'option local_files_only=True lit les poids depuis le cache, sans réseau : utile pour un serveur sans accès sortant.

Pour adapter le modèle à vos données, Mistral oriente vers Forge, sa chaîne d'entraînement, déployable chez le client. La page de Forge renvoie vers un échange avec un expert : ce n'est pas un réglage en libre-service.

CERN et Mistral : un « Large Physics Model » encore à l'état d'intention

Le même jour, le CERN et Mistral ont signé une déclaration d'intention pour un partenariat de long terme. L'ambition affichée : un « Large Physics Model », présenté comme le premier modèle de fondation pour la physique des collisionneurs. Il serait entraîné sur des milliards de collisions proton-proton simulées.

Le communiqué du CERN ne donne ni calendrier ni budget. C'est une intention, pas un produit.

Que faire maintenant si vous prévoyez des ventes ou des stocks ?

Mon avis : Timestral rend la prévision probabiliste accessible à une PME sans GPU ni équipe de data science. Mais un classement public ne dit rien de vos ventes. Mistral l'écrit elle-même : les données de production peuvent être très différentes.

Trois actions :

1. Faire un backtest (rejouer le passé) : cachez vos trois derniers mois, prévoyez-les, et comparez à votre méthode actuelle, même un tableur.
2. Commencer par le 28M : il est rapide, léger, et vous passerez au 123M si l'écart le justifie.
3. Vérifier la licence avec votre direction juridique, surtout si votre groupe ou votre prestataire dépasse le seuil.

Si vous suivez aussi les modèles de langage de Mistral, j'ai fait le point sur Mistral Large 4 et son appel depuis Spring AI.

Vous voulez savoir si Timestral fait mieux que votre prévision actuelle ? Je développe en Java / Spring Boot depuis 2015. Réserver un appel de 30 minutes pour cadrer le backtest et le micro-service.