J'ai entraîné un modèle JEPA pour mobile pour anticiper les orages en montagne

Pourquoi cet article

Il y a deux jours, j’ai publié Tout ce que vous avez toujours voulu savoir sur les World Models et JEPA, après avoir écouté Yann LeCun dans le podcast À la French. Poser le vocabulaire une bonne fois, comprendre le pari de Yann LeCun contre les LLM.

Sauf que la théorie ne tient pas la promesse tant qu’on n’a pas essayé soi-même. Alors j’ai fait ce que j’ai conseillé de faire dans le précédent article : j’ai creusé, en code cette fois. J’ai entraîné mon premier modèle TS-JEPA (Ennadir, Golkar, Sarra, 2025) pour un cas d’usage concret, l’alerte orage en randonnée. Puis je l’ai comparé sans complaisance à une baseline classique. Puis je l’ai fait tourner dans un téléphone.

Voici ce que j’y ai appris. Ce n’est pas ce que je pensais y trouver.

En une phrase

Un modèle d’IA de recherche, pensé pour un randonneur, doit finir dans son téléphone. Ce n’est pas le training qui décide si on y arrive. C’est tout ce qui vient après.

Le point de départ

Le projet s’appelle Taranis. Objectif : un outil souverain d’alerte orage qui tourne sur un capteur BLE porté par un randonneur. Pas d’API cloud interrogée par ma position GPS. Pas d’abonnement. Le modèle doit vivre dans le téléphone.

Choix du modèle : TS-JEPA, la première adaptation systématique de l’idée JEPA aux séries temporelles. Trois raisons apparentes :

Pré-entraînement sans étiquettes, utile pour la météo où les vraies étiquettes d’orage (foudre, code WMO) sont rares
Prédiction en espace latent, pas en valeurs brutes, donc robuste au bruit capteur
Architecture moderne, transformer léger, alignée sur ce que Yann LeCun défend dans les world models

Les données d’entraînement viennent de SYNOP Météo-France (public, licence Etalab). J’ai bâti un dataset de 1.9 million de fenêtres glissantes sur 62 stations françaises, quinze ans de recul, pas d’échantillonnage de trois heures. Pour l’étiquetage, j’ai croisé les codes WMO de temps significatif (17, 29, 91 à 99) avec un seuil de pluie horaire supérieur à 5 mm sur les six heures suivant la fenêtre, ce qui donne 1 137 événements orageux uniques sur le test 2024-2025. Le code source est sous licence AGPL-3.0 sur GitHub.

Ce que la littérature ne dit pas

Une fois le modèle entraîné, il fallait le comparer à un baseline honnête. Pas un baseline paille à faire tomber. Un vrai baseline classique, tel qu’un praticien statistique en 2020 l’aurait construit.

J’ai donc entraîné en parallèle :

HGB-3ch : HistGradientBoostingClassifier de scikit-learn (introduit en 2018), 17 features physiques calculées à la main sur trois canaux capteur (pression, température, humidité)
TS-JEPA-3ch : encoder transformer 3 couches, 64 dimensions latentes, pré-entraîné sans supervision sur 100 heures de contexte, sonde LogReg par-dessus

Sur le même jeu de test, mêmes seuils, mêmes 1 137 événements orageux uniques du test 2024-2025 :

Modèle	AUC	Détection ORANGE	Fausse alarme ORANGE
HGB-3ch (2018)	0.7734	90.7 %	26.8 %
TS-JEPA-3ch (2025)	0.7350	85.8 %	30.8 %

L’AUC (Area Under the ROC Curve) mesure la capacité du modèle à séparer les fenêtres orage et non-orage sur toutes les valeurs de seuil possibles : 1.0 est parfait, 0.5 équivaut à un tirage à pile ou face. En classification déséquilibrée comme les orages (2.6 % de prévalence), c’est la métrique la plus honnête parce qu’elle ne dépend pas d’un point de fonctionnement arbitraire.

HGB bat TS-JEPA de 4 points d’AUC. Le protocole tient sur bootstrap avec intervalle de confiance à 95 % (les IC ne se recouvrent pas), leave-one-station-out sur quatorze stations diverses (moyenne HGB 0.717, moyenne TS-JEPA 0.695), et un transfert cross-régime plaine vers montagne où HGB reste devant sur trois configurations sur quatre.

Sauf une. Le transfert plaine vers montagne, avec seulement trois canaux, montre TS-JEPA à 0.718 contre HGB à 0.694. C’est un point unique dans la matrice, mais il n’est pas insignifiant, il rejoint mon intuition originale (les modèles à représentations latentes devraient mieux généraliser hors distribution) et il pointe vers ce qui pourrait justifier TS-JEPA à l’avenir.

Partout ailleurs, l’algorithme de 2018 domine celui de 2025. Cette déception face au verdict était légitime. Ce n’est pas le résultat que je cherchais. J’ai eu un moment de doute. Est-ce que j’ai raté quelque chose ? J’ai tout revérifié : hyperparamètres, taille de fenêtre, protocole d’évaluation. Rien à sauver. JEPA sur trois canaux SYNOP surface, avec un encodeur transformer léger, ne fait tout simplement pas mieux qu’un gradient boosting bien nourri.

Mais cette déception m’a poussé à changer de question.

La nouvelle question

Puisque le training du modèle est essentiellement un problème résolu en 2018 pour ce genre de données, où est la valeur ajoutée ? Réponse que je n’attendais pas : dans le fait que le modèle tourne dans le téléphone du randonneur, dans le hameau où il est, sans backend, sans latence, sans dépendance au cloud et donc au réseau que l’on perd souvent dès la moyenne montagne.

Le training du modèle est le chapitre facile. Le vrai chantier est en aval.

Export ONNX dans le navigateur, jour 1

Première étape concrète du basculement : exporter les modèles vers un format que le navigateur peut exécuter.

HGB utilise scikit-learn 1.9 en 2026. Le converter officiel skl2onnx a un bug avec les attributs booléens dans les arbres HistGradientBoosting. Trois heures de patch monkey plus tard, j’ai pivoté : sérialiser directement les 200 arbres en JSON compact, écrire un évaluateur JavaScript de vingt lignes.

Fichier modèle : 438 KB
Évaluation JS : environ 1 ms par fenêtre sur un Pixel 10
Parité stricte avec Python : différence mesurée 0.00e+00 sur 200 fenêtres test

Zéro dépendance externe. Aucun runtime à charger. C’est plus léger qu’ONNX Runtime lui-même.

TS-JEPA utilise PyTorch 2.5. L’export via torch.onnx.export avec dynamo=False réussit du premier coup une fois onnxscript installé. Fichier ONNX 476 KB, poids inclus. Chargé dans le navigateur via onnxruntime-web (WASM + WebGL). Parité PyTorch vs ONNX Runtime : 4.47e-07. Inférence environ 5 ms par fenêtre sur mobile.

Total pour les deux moteurs : moins d’un mégaoctet. Deux modèles complets, prêts à l’inférence locale, aucun serveur nécessaire.

Le parallèle qui compte : SLM, agentic, et la qualité du harnais

Cette expérience TS-JEPA vs HGB fait écho à ce que le monde des LLM apprend depuis deux ans avec les Small Language Models et l’agentic.

La communauté a compris qu’un petit modèle de langage bien orchestré, avec du retrieval augmenté, du function calling propre, un agent loop bien réglé, peut battre un modèle propriétaire dix fois plus gros et cent fois plus cher. Ce n’est pas le modèle qui a évolué, c’est le harnais autour. La preuve la plus nette vient des benchmarks agentic : sur SWE-bench, GAIA, ou TAU-bench, deux équipes utilisant le même modèle sous-jacent peuvent avoir des scores qui varient de 20 à 60 %. La différence, c’est l’agent loop, le tool use, la gestion de la mémoire, la stratégie de retry, le prompt engineering, la sélection des exemples few-shot.

Le harnais, c’est l’ensemble du code non-modèle qui entoure l’appel d’inférence : ce qui prépare les données, ce qui les nettoie, ce qui décide quand appeler le modèle, ce qui interprète sa sortie, ce qui gère les erreurs, ce qui compose plusieurs appels. Dans le monde LLM, ça s’appelle un « agent framework » ou un « harness ». Anthropic, OpenAI, LangChain, Cognition, tout le monde s’y met parce que la valeur y accumule plus vite que dans les poids du modèle.

Mon expérience Taranis dit la même chose, appliquée à un modèle non-linguistique. Le TS-JEPA de 476 KB et le HGB de 438 KB sont deux modèles opposés en paradigme. Mais entre les deux et l’utilisateur, il y a le même harnais : la source de données (Open-Meteo avec la bonne variable de pression), la fenêtre glissante, la gestion du buffer IndexedDB, la géolocalisation qui se rafraîchit sans harceler l’utilisateur, la coexistence sensor local et cloud régional, l’i18n, le service worker qui propage les mises à jour, le déploiement HTTPS souverain.

Le harnais représente le gros du travail de cette expérimentation. Le training du modèle, quelques heures. Si je change de modèle demain, le harnais reste. Si je casse le harnais, aucun modèle ne peut plus servir. C’est un enseignement à garder en tête pour les prochaines expériences avec JEPA.

C’est ce qui rejoint la thèse de Yann LeCun autrement. Un world model n’est pas juste un réseau de neurones : c’est un système qui interagit avec un environnement. La simulation intérieure dont il parle est le harnais, appliqué à la robotique et à la planification. Le modèle est une brique, pas le tout. Et pour un praticien qui livre un produit, la qualité du harnais mesure la qualité du produit, pas la sophistication du modèle qui l’anime.

Le résultat mesuré, aujourd’hui

PWA installable en une commande sur Android Chrome, sur iOS via Bluefy, sur bureau via Edge
476 KB pour TS-JEPA, 438 KB pour HGB, 40 KB de code JavaScript
Inférence 5 à 10 ms par prédiction sur mobile, aucun serveur consulté
Zéro donnée utilisateur quitte le téléphone hors opt-in Open-Meteo et Nominatim
Autonomie complète hors ligne dès la première visite installée
Sélecteur de moteur live (HGB / TS-JEPA), pour que l’utilisateur choisisse
Rafraîchissement GPS automatique configurable, aligné sur l’usage terrain
Contexte régional Open-Meteo en complément, opt-in strict, jamais fallback silencieux
Cinq langues avec auto-détection navigateur

Le tout hébergé sur un simple sous-domaine, HTTPS Let’s Encrypt automatique, Caddy 2, aucune Function As A Service, aucune Cloud Function, aucune base de données managée. Empreinte serveur : négligeable. Coût mensuel : zéro marginal.

Ce que je retiens, en tant que praticien

Je voulais démontrer que TS-JEPA fait mieux que les baselines classiques sur un problème métier réel. La démonstration a échoué, honnêtement mesurée, honnêtement documentée. C’est important.

J’ai découvert quelque chose de bien plus intéressant en cours de route : il est parfaitement possible de faire vivre un modèle d’IA de recherche dans le téléphone d’un utilisateur, sans backend, sans latence, sans dépendance au cloud et donc au réseau que l’on perd souvent dès la moyenne montagne, avec un contrat de confidentialité par construction. Le paradigme JEPA n’était pas mon axe de valeur. La bascule vers l’inférence terrain, si.

Cette bascule tient une thèse qui rejoint celle de Yann LeCun mais par un chemin différent : le modèle qui accompagne un humain doit vivre à côté de lui, pas dans un data center. Pour Yann LeCun, c’est la voie vers l’intelligence artificielle du monde physique. Pour moi qui construis un outil d’alerte orage, c’est simplement le prix à payer pour ne dépendre d’aucun cloud américain.

Autre leçon, plus prosaïque : le training se fait en une semaine. Le passage produit prend un mois. Cette proportion, on n’en parle presque jamais dans la littérature. Elle mérite qu’on en parle.

Ce n’est pas fini

L’idée originale du projet, celle qui m’a poussé à commencer Taranis, c’est mieux prédire les orages localisés en montagne. Pas les orages génériques d’un test set français agrégé. Les orages qui piègent un randonneur sur un col dans les Écrins un après-midi d’août, quand la pression chute vite et que la convection devient violente en trente minutes.

Le modèle actuel n’y répond que partiellement. Il est entraîné sur des stations SYNOP majoritairement de plaine et de côte, où la dynamique est plus lente et plus lisible. En LOO cross-régime, TS-JEPA a montré son seul avantage sur la transition plaine vers montagne. C’est une piste, pas une conclusion.

Deux étapes concrètes m’attendent :

Le RuuviTag Pro arrive le 19 juillet. Le RuuviTag Pro est un petit capteur Bluetooth Low Energy fabriqué en Finlande, matériel et firmware open source, qui mesure toutes les secondes la pression atmosphérique, la température et l’humidité. Il est étanche IP67, il pèse 15 grammes, la pile CR2477 tient un an. Autrement dit, exactement ce dont un randonneur a besoin dans son sac à dos, à côté du corps, pour capter la vraie météo locale plutôt qu’une valeur interpolée depuis la station météo la plus proche à vingt kilomètres. À partir de sa réception, je passe du buffer Open-Meteo synthétique aux mesures BLE réelles, prises sur le randonneur lui-même. Le harnais est prêt à l’accueillir. Je m’attends à découvrir de nouveaux bugs terrain, à recalibrer les seuils sur les vraies distributions de pression capteur, et à mesurer pour la première fois la latence bout en bout d’une prédiction physique à partir d’une mesure physique dans le sac à dos.

ERA5 se télécharge en arrière-plan. La collecte est lente, plusieurs semaines à cause des limites CDS resserrées fin 2025, mais quand elle sera complète, j’aurai des canaux verticaux enrichis : température et vent à 500 hPa et 850 hPa, CAPE, géopotentiel. C’est là que je pense que TS-JEPA peut enfin briller. Un transformer sur trois canaux surface est un problème sous-dimensionné, ce que HGB gère par cœur. Un transformer sur dix canaux verticaux avec dynamique horaire est un tout autre régime. J’entraînerai un TS-JEPA enrichi, je le comparerai encore honnêtement à HGB sur ces mêmes canaux, et je publierai ce que je trouve. Peut-être que le verdict s’inverse. Peut-être que non. Dans les deux cas ça vaut le détour.

Cet article n’est pas une conclusion, c’est un point d’étape. Le carnet est ouvert, le code est ouvert, la PWA est en ligne. La suite s’écrira au fil des mesures.

Voir tourner en direct

PWA live : taranis.maudet.cloud (installer via « Ajouter à l’écran d’accueil »)
Code, AGPL-3.0 : github.com/mmaudet/taranis
Modèles ONNX + JSON téléchargeables via /models/ sur la PWA elle-même
Article précédent sur les world models et JEPA : Tout ce que vous avez toujours voulu savoir sur les World Models et JEPA

Aucune inscription, aucune télémétrie, aucun cookie. Vous êtes en Cantabrie ou dans le massif du Mont-Blanc, l’app vous dit ce que le modèle prédit pour votre position. C’est tout.