Partir d’une décision, pas du modèle.
Une prévision n’a de valeur que si quelqu’un prend une meilleure décision grâce à elle. Avant de parler d’architecture, formulez la question à laquelle elle doit répondre, et la personne qui s’en servira.
- « Ce compresseur s’éloigne-t-il de son comportement habituel ? »Pour le responsable maintenance, qui décide d’une inspection.
- « Quelle sera la consommation électrique de demain ? »Pour la personne qui organise la production ou suit les achats d’énergie.
- « Combien de pièces d’usure prévoir le mois prochain ? »Pour le magasin et les achats, qui dimensionnent le stock.
Le bon point de départ
« Être prévenu quand la température du palier sort de sa plage habituelle, compte tenu du planning » est un besoin plus précis que « mettre de l’IA dans l’usine ».
Notez aussi le pas de temps et l’horizon utiles : l’heure suivante pour une alerte, la journée pour l’énergie, plusieurs semaines pour un stock. Timestral calcule jusqu’à 1 024 pas d’un coup, soit un peu plus de dix jours au pas de 15 minutes ; au-delà, il enchaîne les calculs par blocs.
Réunir des données que l’on peut croire.
Les mesures existent souvent déjà, mais elles sont réparties entre plusieurs systèmes. Commencez par l’inventaire de ce qui est disponible pour la question choisie.
- Mesures des capteurs
- Historien, supervision, automates via OPC UA ou MQTT
- Planning de production
- MES, ERP ou planning partagé
- États des machines
- Supervision, MES, journaux d’équipe
- Historique des pannes
- GMAO, bons d’intervention, rapports
Vérifiez ensuite quelques points simples sur un extrait de plusieurs semaines :
- Un pas de temps régulier, ou une règle claire pour s’y ramener, par exemple une moyenne par quart d’heure.
- Des horodatages cohérents entre les systèmes, fuseau horaire et changement d’heure compris.
- Des trous signalés comme tels : Timestral accepte les valeurs manquantes, à condition qu’elles ne soient pas remplacées par des zéros.
- Les remplacements de capteurs, recalibrages et changements de recette, qui modifient le comportement d’une série.
- Un historique suffisant. Mistral illustre ses mesures avec trois semaines au pas de 15 minutes pour prévoir la journée suivante ; le modèle peut lire jusqu’à 32 768 pas, soit environ onze mois à ce rythme.
Préparez en même temps les informations de contexte : planning, arrêts programmés, état des machines. Ce sont elles qui évitent au modèle de confondre un changement prévu avec une anomalie.
Tester sur l’historique avant de brancher quoi que ce soit.
Un modèle pré-entraîné peut être évalué tout de suite, sans phase d’apprentissage. La méthode la plus simple est le test rétrospectif : se placer à une date passée, demander une prévision, puis la comparer à ce qui s’est réellement produit. On répète l’opération sur plusieurs semaines, en incluant des périodes calmes et des incidents connus.
La prévision fait-elle mieux que l’existant ?
Comparez-la à ce que l’équipe utilise aujourd’hui : un seuil fixe, la moyenne de la semaine précédente, l’expérience du responsable. Un modèle qui ne fait pas mieux qu’une règle simple n’a pas sa place dans l’atelier.
La plage annoncée est-elle fiable ?
Si le modèle annonce une plage de 5 % à 95 %, la mesure réelle doit s’y trouver environ neuf fois sur dix. Si elle en sort beaucoup plus souvent, la plage est trop étroite et les alertes seront trop nombreuses. Si elle n’en sort presque jamais, la plage est peut-être trop large pour signaler un écart à temps.
Quelle taille de modèle suffit ?
Comparez un petit modèle, celui de 28 millions de paramètres, avec le plus grand. Sur les bancs d’essai publiés par Mistral, l’écart entre les deux reste limité, et le petit modèle est environ cinq fois plus rapide. Sur des milliers de capteurs, la différence se voit sur le serveur.
Pour l’équipe technique
# pip install git+https://github.com/mistralai/timestral.git
from timestral import TimestralForecaster
modele = TimestralForecaster.from_pretrained(
"mistralai/Timestral-28M",
local_files_only=True, # poids déjà téléchargés sur le serveur
)
# historique : (séries, variables, temps), NaN pour une mesure manquante
# 2016 pas = trois semaines au pas de 15 minutes
prevision = modele.forecast(historique, prediction_length=96) # 24 heures
basse = prevision.quantile(0.05)
haute = prevision.quantile(0.95)D’après l’exemple du dépôt mistralai/timestral. Python 3.10 et PyTorch 2.4 au minimum ; aucune carte graphique n’est nécessaire.
Une architecture simple, à côté des données.
Pour un premier essai, il n’est pas nécessaire de transformer le système d’information. Le modèle peut tourner dans un petit service, sur un serveur de l’usine ou une machine virtuelle, et échanger avec l’existant par des interfaces simples.
Exemple d’architecture sur site
- CollecterLire les mesures dans l’historien ou la supervision, et le planning dans le MES ou l’ERP.
- PréparerRamener les séries au même pas de temps, marquer les trous, joindre les états des machines.
- PrévoirAppeler Timestral à intervalle régulier sur le processeur du serveur, et enregistrer chaque prévision.
- ComparerConfronter les nouvelles mesures à leur plage prévue et appliquer les règles métier.
- SignalerAfficher l’écart dans un tableau de bord, prévenir la bonne personne, créer si besoin une demande dans la GMAO.
Quelques choix techniques facilitent la suite :
Figer la version du modèle. Timestral est en préversion. La bibliothèque permet de désigner une révision précise des poids, pour que les prévisions restent comparables d’un mois à l’autre.
Travailler hors ligne. Une fois téléchargés, les poids sont lus localement. Cela convient aux réseaux de production isolés d’Internet.
Conserver les prévisions. Enregistrer ce que le modèle avait prévu, et pas seulement l’alerte, permet de comprendre une décision après coup et de suivre la qualité dans la durée.
Exposer un résultat simple. Le service de prévision est écrit en Python ; le reste de vos outils n’a pas à changer. Une API interne suffit pour que le tableau de bord, l’outil de suivi ou la GMAO récupèrent les écarts.
Une alerte n’est utile que si quelqu’un sait quoi en faire.
La prévision informe ; elle ne doit pas piloter seule une machine. Un écart doit arriver chez une personne identifiée, avec le contexte nécessaire : la courbe, la plage attendue, l’état de la machine et le planning.
Prévoyez dès le départ comment cette personne indique ce qu’elle a constaté : fausse alerte, usure confirmée, intervention réalisée. Ces retours servent à ajuster les règles d’alerte et, plus tard, à décider s’il faut adapter le modèle à vos données. Mistral propose cette adaptation dans Forge, son offre d’entraînement sur données propres, déployable chez le client.
Une règle simple
Commencer en mode observation : les alertes sont enregistrées et relues par l’équipe, mais ne déclenchent aucune action automatique.
Un pilote en quatre étapes.
- Choisir un périmètre. Un équipement ou une ligne, une question, une personne qui utilisera le résultat.
- Tester sur l’historique. Extraire plusieurs mois de données, comparer Timestral à la pratique actuelle et vérifier la fiabilité de la plage.
- Faire tourner en parallèle. Plusieurs semaines en mode observation, sur le serveur du site, avec une relecture régulière des écarts par l’équipe.
- Décider. Étendre à d’autres équipements, ajuster les règles, adapter le modèle, ou arrêter si la prévision n’apporte rien.
Arrêter fait partie des issues possibles. Un pilote réussi est un pilote qui permet de décider sur des faits.
Avant de passer à l’échelle, vérifiez la licence des poids : elle ne couvre pas les entreprises dont le chiffre d’affaires mensuel consolidé dépasse 20 millions de dollars. Le détail est dans le décryptage de Timestral.
Pour préparer un premier échange
Cinq informations suffisent.
L’équipement concerné, la question posée, les systèmes où se trouvent les mesures, leur pas de temps et la personne qui recevra les alertes. Avec ces éléments, on peut évaluer la faisabilité d’un essai.
Préparer mon briefSources
- Dépôt de code mistralai/timestral sur GitHub
- Fiche du modèle Timestral-209M sur Hugging Face
- Mistral AI, annonce de Timestral, 15 octobre 2026
- Documentation Mistral, Timestral 1.0
Informations relevées le 19 octobre 2026. Timestral étant en préversion, vérifiez la documentation à jour avant un déploiement.