[Carnet d’idées IA 02] Timestral : prévoir les chiffres de demain sans demander à un chatbot de deviner
Une introduction aux petits modèles temporels de Mistral : comprendre les prévisions probabilistes, leurs usages et un premier essai sur CPU assorti d'une comparaison honnête.
Le Carnet d’idées IA explore les idées et les possibilités concrètes des nouveaux modèles et outils d’IA.
La file du support de demain est un nombre avant de devenir un paragraphe. Vous cherchez peut-être à savoir s'il faut affecter une personne de plus, augmenter la capacité d'un serveur ou compléter la commande de stock habituelle pour le week-end. Une explication fluide n'est utile que si la prévision repose sur quelque chose de solide.
Timestral, présenté par Mistral AI le 15 octobre 2026, est une famille de modèles conçus pour prévoir des suites de nombres. Elle produit des prévisions probabilistes plutôt que des réponses de chat, prend en charge plusieurs séries liées et propose quatre tailles publiées : 5M, 28M, 123M et 209M paramètres. Annonce de Mistral
Cette introduction vous mène de cette description à un premier essai utile. Nous verrons quelles données fournir, comment lire une plage de prévision et comment comparer le modèle à une référence simple. Les exemples sont des exercices proposés : ils permettent d'essayer l'idée sans confondre illustration et résultat mesuré.
La page Timestral-5M de Mistral AI, capturée le 20 octobre 2026. L'écran identifie un checkpoint de prévision ; il ne montre pas un graphique issu d'une expérience réalisée pour cet article.
Une prévision commence par une horloge et une quantité
Une série temporelle enregistre une quantité à des instants successifs. Il peut s'agir de requêtes par minute, de commandes par jour ou de températures à intervalles réguliers. L'espacement fait partie du sens : 100 requêtes par minute et 100 requêtes par heure décrivent des systèmes très différents.
Avant de choisir le modèle, formulez la décision en une phrase. « Estimer le volume quotidien du support de demain pour organiser la permanence » est plus précis que « trouver des informations dans nos données ». La phrase définit la cible, l'horizon et l'action susceptible de changer.
Définissez ensuite ce que représente une observation. Un ticket créé aujourd'hui et un ticket résolu aujourd'hui sont des événements différents. Les réunir dans une colonne pratique peut masquer le goulet d'étranglement que vous souhaitiez comprendre.
Timestral intervient après cette définition. Il traite un historique numérique, mais l'équipe reste responsable de la signification des nombres. Un modèle ne peut pas réparer une cible qui passe discrètement des demandes aux tâches terminées au milieu du fichier.
La sortie utile est une plage sur laquelle agir
Une prévision ponctuelle fournit un nombre unique. Une prévision probabiliste décrit plusieurs niveaux possibles de la valeur future et aide à voir la marge autour de l'estimation centrale. La sortie publiée de Timestral comprend 21 quantiles par pas de temps prédit. Dépôt d'inférence
Imaginez un exercice où la médiane pour demain vaut 100 tickets et un quantile supérieur 140. Ces chiffres sont inventés, mais illustrent la décision : l'effectif ordinaire peut couvrir l'estimation centrale et un plan de secours une journée plus chargée. La prévision sert parce qu'elle change la préparation.
Le quantile n'est pas une promesse que la réalité restera sous une ligne. Il faut vérifier la calibration sur des prévisions historiques répétées. Si les observations dépassent beaucoup trop souvent la prévision annoncée au 90e percentile, ce niveau n'est pas une limite de planification fiable pour vos données.
La limite adaptée dépend aussi de la décision. La rupture de stock et un petit surplus n'ont pas le même coût. Une équipe peut donc agir selon un quantile supérieur à la médiane, tandis qu'une autre tâche peut accepter un plan moins coûteux et moins prudent.
Schéma explicatif original. La courbe et la plage sont inventées pour expliquer la fenêtre de prévision ; ce ne sont pas des sorties de Timestral.
Les signaux liés n'aident que si leur chronologie est respectée
Mistral décrit Timestral comme un modèle multivarié prenant en charge les covariables uniquement historiques et celles connues à l'avance. Autrement dit, il peut utiliser plusieurs signaux numériques liés et des informations dont les valeurs futures sont déjà disponibles. Description de la publication
Le calendrier d'ouverture d'un magasin est connu avant demain. Son chiffre de ventes réel de demain ne l'est pas. Un essai de prévision doit respecter cette différence, même si le tableur terminé contient commodément les deux colonnes.
Pour un exercice sur la capacité d'un serveur, un lancement de produit peut être programmé à l'avance, alors que le nombre exact de requêtes demeure inconnu. Pour un exercice sur les commandes, un indicateur de jour férié peut être disponible, mais le nombre final de commandes est la cible. Ces exemples illustrent la distinction ; ils ne décrivent pas une intégration déployée.
La météo montre une erreur facile à commettre. Un fichier historique peut contenir le temps réellement observé. Une vraie prévision n'aurait disposé que des prévisions météo disponibles à cette date. Évaluer avec l'observation ultérieure fournit au système une information qu'il n'aurait pas eue lors de la décision.
Commencez par le plus petit essai qui répond à une question
Le dépôt officiel propose une inférence autonome sur CPU ou GPU. Le parcours CPU rend le premier test accessible sans réduire les exigences matérielles à la taille du modèle. Les dépendances, les tenseurs chargés, la longueur de l'historique et le nombre de séries contribuent aussi à la mémoire nécessaire. Installation et utilisation
Pour découvrir l'interface, le checkpoint 5M est un point de départ raisonnable. C'est une suggestion pour un petit exercice, pas l'affirmation qu'il surpassera les plus gros modèles sur vos données. Faites d'abord fonctionner le pipeline avant de comparer les tailles.
- Ouvrez le dépôt officiel et examinez ses instructions d'installation et ses liens de licence. Travaillez dans un environnement Python séparé.
- Préparez une série à échantillonnage régulier. Gardez les horodatages et les unités dans le fichier source, même si le tableau transmis au modèle ne contient que des valeurs.
- Réservez les dernières observations comme horizon de test. Ne les incluez pas dans l'historique utilisé pour cette prévision.
- Chargez un checkpoint, demandez l'horizon choisi et examinez la prévision centrale ainsi que les quantiles.
- Comparez à une prévision simple calculée avec le même historique. Répétez à plusieurs dates de coupure antérieures avant de conclure.
Le dépôt documente cette installation, avec Python 3.10 ou ultérieur et PyTorch 2.4 ou ultérieur comme prérequis annoncés. L'installation récupère du code ; examinez et figez une révision si vous avez besoin d'un environnement reproductible.
python -m venv .venv
# Activate the environment using your shell's activation command.
python -m pip install "git+https://github.com/mistralai/timestral.git"
Voici une adaptation volontairement réduite de l'interface d'inférence documentée. Les valeurs sont des comptes quotidiens synthétiques ; ce code ne signifie pas que l'article a exécuté le modèle ou obtenu un résultat particulier.
import numpy as np
from timestral import TimestralForecaster
history = np.array([
80, 83, 85, 88, 96, 61, 58,
82, 84, 87, 91, 99, 64, 60,
85, 86, 89, 94, 102, 66, 63,
], dtype=np.float32)
model = TimestralForecaster.from_pretrained("mistralai/Timestral-5M")
forecast = model.forecast(history, prediction_length=7)
print(forecast.median)
print(forecast.quantile(0.9))
Trois semaines de données inventées suffisent à montrer l'API, pas à établir la performance sur un processus métier. Remplacez-les par une série suffisamment longue et bien comprise avant de décider. Examinez les observations manquantes et les événements inhabituels au lieu de transformer discrètement chaque trou en zéro.
Trois tâches montrent pourquoi prévoir diffère de générer du texte
La planification quotidienne du support relie prévision et effectifs. L'entrée peut être l'historique des tickets créés chaque jour, accompagné d'un calendrier de week-ends et de fermetures connues. Il faut vérifier si la prévision aide à préparer la capacité, notamment pour les journées chargées qu'une simple moyenne manque.
La planification des serveurs relie prévision et limite technique. Les requêtes par intervalle peuvent être la cible, mais les erreurs, la latence et la capacité supportée nécessitent toujours une surveillance séparée. Une prévision de demande ne prouve pas qu'une application résistera à une charge particulière.
La planification du stock relie prévision et délai de livraison. Si le réapprovisionnement prend plusieurs jours, prévoir seulement demain est un mauvais horizon. L'exercice utile couvre la période pendant laquelle la prochaine commande ne peut pas encore arriver et compare les conséquences des ruptures et des excédents.
Les trois exemples suivent le même schéma : définir la quantité, le moment de la décision et ce que la prévision change. Le modèle devient un instrument dans le processus. Cet instrument est plus facile à évaluer quand l'action visée est visible.
Comparez les prévisions au moment où elles auraient pu être faites
Un backtest recrée les occasions historiques de prévoir. Choisissez une date de coupure, ne fournissez que les informations antérieures et prévoyez l'intervalle suivant. Avancez cette date et recommencez sans laisser les observations futures influencer rétrospectivement le choix du modèle.
Partez d'une référence adaptée au motif observé. Pour un cycle hebdomadaire, la valeur du même jour de la semaine précédente peut être utile ; pour un processus stable à court horizon, la dernière valeur peut convenir. Aucune n'est automatiquement forte, mais toutes deux indiquent si la complexité supplémentaire est justifiée.
| Comparaison | Ce qu'il faut garder fixe | Ce que le résultat peut indiquer |
|---|---|---|
| Timestral contre une référence saisonnière | Cible, dates de coupure et horizon | Si le modèle réduit les erreurs importantes pour la décision |
| 5M contre un plus gros checkpoint | Préparation des données et évaluation | Si les ressources supplémentaires apportent assez de bénéfices |
| Avec et sans calendrier connu | Informations historiques disponibles à chaque coupure | Si le signal supplémentaire aide sans fuite d'informations futures |
| Médiane contre quantile de décision supérieur | Prévisions et hypothèses de coût métier | Comment change la règle de planification, plutôt que le modèle |
Gardez les périodes nulles ou presque nulles dans l'analyse. Une erreur en pourcentage devient difficile à interpréter quand la cible est minuscule. Utilisez des métriques adaptées et examinez les erreurs réelles à côté du score global.
Pour un pilote concret, un petit tableau des pires écarts enseigne souvent plus qu'une moyenne mise en avant. L'erreur venait-elle d'un intervalle manquant, d'un jour férié, d'une panne ou d'un véritable changement de demande ? La réponse indique s'il faut améliorer le pipeline, ajouter des informations ou revoir la méthode de prévision.
Schéma de backtest original. Chaque prévision utilise les informations disponibles à sa propre date de coupure ; les observations suivantes sont réservées à l'évaluation.
Des poids légers ne constituent qu'une partie du déploiement
Le dépôt distingue le code sous Apache 2.0 des poids publiés sous une Modified MIT license. Lisez les conditions réelles du checkpoint choisi : un dépôt ouvert et un modèle sous licence séparée sont des artefacts de distribution différents. Explication des licences du dépôt
Le téléchargement initial et l'inférence habituelle sont aussi des étapes distinctes. Le chargeur documenté peut utiliser un modèle local en cache, mais une application ne reste hors ligne que si tous ses composants le sont. Un modèle de prévision local n'empêche pas un autre élément du processus d'envoyer des données à un service distant.
En exploitation répétée, consignez le checkpoint qui a produit chaque prévision et la date de fin des données d'entrée. Sans cette coupure, un graphique peut passer pour une prévision alors qu'il intègre des observations ultérieures. Conservez les valeurs prédites inchangées pour les comparer ensuite au réel.
Un service de prévision doit aussi prévoir les données manquantes et les exécutions échouées. Présenter la prévision d'hier comme récente donne une impression trompeuse de bon fonctionnement. Affichez le dernier horodatage traité avec succès et décidez quand une référence simple vaut mieux qu'une sortie de modèle périmée.
Une prédiction plus rapide n'est utile que si la décision s'améliore
Mistral annonce une inférence adaptée au CPU et de bons résultats de benchmark pour la famille. Ce sont des raisons d'enquêter, pas des mesures de votre pipeline. Un temps publié pour le modèle n'inclut pas chaque lecture de fichier, calcul de variable, file d'attente ou graphique possible d'une application. Annonce du 15 octobre
La tentation habituelle est de consacrer le pilote au plus gros checkpoint qui fonctionne. La meilleure question est de savoir si la prévision arrive avant la décision et améliore les erreurs qui comptent. Une réponse un peu plus précise livrée après la clôture du planning a une valeur opérationnelle limitée.
Distinguez aussi amélioration numérique et amélioration de la politique. Une erreur moyenne plus faible peut laisser inchangées les journées de pointe les plus coûteuses. À l'inverse, un quantile supérieur mieux calibré peut améliorer la préparation même si la médiane bouge peu.
Décidez de ces critères avant de comparer les modèles. Le pilote peut alors aboutir à un choix utile : garder la référence, utiliser un petit checkpoint ou justifier une configuration plus exigeante. Chaque issue peut être la bonne si les preuves sont claires.
La prévision doit laisser une trace avant l'arrivée de demain
À notre avis, Timestral est intéressant parce qu'il rend une tâche numérique spécialisée accessible dans un parcours de modèle. Sa sortie peut servir de météo de la charge de travail : une attente centrale, une plage et une raison de se préparer. La valeur apparaît lorsque ces prévisions rencontrent une véritable décision de planification.
Commencez par une quantité et un horizon. Sauvegardez la prévision avant de connaître le résultat, puis comparez-la honnêtement à une solution simple. Vous transformerez une sortie de modèle prometteuse en expérience dont le résultat est réellement exploitable.
Sources et médias
Vérifié le 20 octobre 2026. Exemples et graphiques sont illustratifs, pas des résultats d'exécution du modèle. La capture de la fiche publique a été réalisée par l'auteur ; les schémas sont originaux. Consultez le registre des médias pour les sources et mentions de licence.
- Annonce de Mistral du 15 octobre 2026
- Code d'inférence officiel, installation et distinction des licences
- Checkpoint Timestral-5M
- Licence du checkpoint
Gardez ensemble la prédiction et le résultat
Conservez la définition des données, la coupure de prévision et les notes d'examen avec les liens sources originaux. Telli.sh peut vous aider à organiser ce dossier d'expérience. Créer un compte Telli.sh