Par Elisha Bajemon, Ingénieur IA chez TW3 Partners. Dernière mise à jour : 24 octobre 2026.

En bref

Dans TW3Cast, maintenir un système de prévision consiste à modifier une table après vérification sur l’historique d’entraînement, sans réentraînement global. La publication de Nathan Thierry et André-Louis Rochet sur arXiv, du 16 septembre 2026, décrit un système de recherche évalué sur le benchmark public GIFT-Eval. Son architecture repose sur deux petits fichiers, une table de routage et un index des experts, accompagnés de points de contrôle, les états sauvegardés des modèles. Un expert peut être ajouté, remplacé ou retiré par un changement de ligne ; sur une nouvelle source, le tournoi sélectionne d’abord un modèle par défaut sans entraînement. Les auteurs signalent un écart inférieur à 1 % entre un modèle en mémoire et sa version rechargée, ainsi que des seuils dépendants des données du benchmark. Pour une DSI, cette conception offre une méthode de maintenance à examiner, avec des exigences d’archivage et de vérification propres à chaque version.

1. Que livre-t-on concrètement ?

Le système décrit livre une table de routage, un index des experts et leurs points de contrôle. Une table de routage désigne ici un fichier qui associe une configuration de prévision aux experts à utiliser et à leurs poids respectifs. La configuration réunit une source de données, une fréquence et un horizon de prévision.

Selon la publication TW3Cast du 16 septembre 2026, le routage est calculé à l’avance, puis figé. Le dépôt TW3-Partners-OS/TW3-Cast, vérifié le 9 octobre 2026, contient les fichiers suivants.

FichierRôle documenté
router.csvAssocier une configuration à un expert ou à un mélange, avec les poids correspondants
experts.jsonIndiquer la famille d’architecture de chaque expert
base_models.jsonFixer les révisions des modèles de base à charger

Les points de contrôle sont distribués dans la publication des modèles sur Hugging Face. Pour produire une prévision, le système recherche la configuration dans la table, exécute les experts retenus, puis calcule une moyenne pondérée et triée de leurs quantiles. Ces quantiles décrivent plusieurs niveaux de la distribution prévue. La formule des « deux petits fichiers » désigne le routage et l’index ; le manifeste des modèles de base complète le matériel de reproduction.

2. Comment ajoute-t-on, remplace-t-on ou retire-t-on un expert ?

L’intégration d’un expert se traduit par un changement de ligne après son admission sur le backtest. Le backtest est une évaluation rétrospective : le système utilise des portions de l’historique pour mesurer comment les candidats auraient prévu la suite.

Dans la publication TW3Cast du 16 septembre 2026, cette évaluation est découpée dans la période d’entraînement. Le candidat entre dans le routage s’il bat le modèle retenu par le tournoi, selon le critère de sélection. Un candidat refusé laisse le système livré inchangé. Les auteurs décrivent ainsi chaque amélioration comme une modification vérifiée individuellement, avec un travail de spécialisation de quelques minutes par candidat dans leur expérimentation.

Aucun réentraînement global n’intervient dans cette architecture. Cela laisse place à l’entraînement local d’un nouvel expert, puis à son évaluation. La propriété d’amélioration porte sur le critère mesuré au backtest ; son maintien sur les données futures reste à vérifier.

Notre recommandation est de conserver, avec chaque modification, la mesure qui justifie l’admission et la version remplacée. L’équipe chargée de l’exploitation peut alors relire la décision et préparer un retour à la version antérieure.

3. Que se passe-t-il sur une nouvelle source de données ?

Le tournoi construit un backtest sur l’historique disponible et sélectionne un modèle par défaut sans entraîner de nouveau modèle. C’est le comportement décrit dans la publication TW3Cast du 16 septembre 2026, avec les mêmes garde-fous que pour les sources déjà traitées.

La spécialisation intervient ensuite si l’équipe décide de la tenter. Le candidat est construit à partir de l’historique de la source, puis confronté au tournoi. Son admission dépend du résultat de cette comparaison.

Le rapport technique du dépôt, dans son état du 9 octobre 2026, prévoit aussi de reprendre un spécialiste existant lorsque les données sont proches d’un domaine déjà couvert, comme l’énergie ou la météo. Il propose, si nécessaire, de le confronter au tournoi avant déploiement.

Pour une adaptation en entreprise, nous recommandons de documenter ce rapprochement : source concernée, fréquence, horizon attendu et période utilisée pour l’évaluation. Le choix d’un spécialiste devient ainsi une hypothèse mesurable sur les données de l’organisation.

4. Quels garde-fous protègent la prévision servie ?

Des contrôles par fenêtre limitent les changements de modèle, et un contrôle d’alignement vérifie le rattachement des prévisions importées. La publication TW3Cast du 16 septembre 2026 distingue leurs fonctions.

Le premier contrôle examine le contexte de la fenêtre à prévoir. Le modèle par défaut ne cède sa place que si toutes les conditions concordent. Son erreur doit dépasser le seuil fixé ; le candidat de remplacement doit atteindre le gain moyen minimal requis, faire mieux sur chacun des segments examinés et améliorer la qualité probabiliste. Un contrôle des transitions de régime peut bloquer le changement. Les auteurs indiquent que ce mécanisme est conçu pour basculer rarement.

Les spécialistes disposent d’un contrôle anti-catastrophe distinct. Ses seuils élevés réservent le repli vers les modèles génériques aux défaillances manifestes d’une fenêtre.

Enfin, le contrôle d’alignement utilise une corrélation pour vérifier que des prévisions importées correspondent aux bonnes fenêtres. Le rejet intervient lorsque la corrélation médiane passe sous 0,30. Les auteurs rapportent trois déclenchements pendant leurs campagnes, chacun associé à un défaut réel d’alignement, et aucun sur un import correctement aligné.

La même publication impose de produire les chiffres publiés à partir de fichiers sauvegardés puis rechargés, les artefacts. Cette règle relie l’évaluation aux fichiers qui pourront ensuite servir les prévisions.

5. Comment auditer une table de routage ligne par ligne ?

L’audit consiste à relier chaque ligne à sa décision mesurée, puis aux artefacts qui produisent la prévision. Selon la publication TW3Cast du 16 septembre 2026, le routage privilégie cette traçabilité en limitant les possibilités d’adaptation : les choix sont figés après l’évaluation. Au moment de prévoir, seuls les deux garde-fous par fenêtre peuvent encore modifier le modèle servi.

La publication des modèles sur Hugging Face contient bien, au 9 octobre 2026, le fichier decisions/tournament_decisions.csv. Dans la discussion de soumission sur GitHub, le 21 septembre 2026, les auteurs précisent que ce fichier fournit le modèle sélectionné sur le backtest et le nombre de bascules par fenêtre pour les configurations servies par tournoi. Ils indiquent également que le code de sélection lui-même reste non publié.

Nous recommandons de structurer la revue autour de la chaîne suivante : décision, ligne de routage, artefact chargé, prévision obtenue, mesure reproduite. Le fichier de décisions permet d’examiner les choix consignés ; l’accès au code de sélection reste un point à traiter pour qui veut reprendre toute la procédure.

6. Quelles limites une DSI doit-elle connaître ?

La reproductibilité dépend de la conservation des artefacts, et les seuils restent liés au périmètre de l’évaluation. La publication TW3Cast du 16 septembre 2026 documente plusieurs limites précises.

Dans une bibliothèque de base, un mode d’enregistrement du modèle a produit un écart inférieur à 1 % entre la version en mémoire et celle rechargée. Un expert a donc été réévalué après rechargement. Les auteurs mentionnent également un expert dont les poids moyennés entre initialisations n’ont pas été conservés. Il est livré sous forme de quantiles vérifiés : ses prévisions sont reproductibles, son entraînement ne l’est pas à partir de ces fichiers.

Les auteurs ont figé les paramètres réglés lors du méta-backtest, leur évaluation temporelle des règles de sélection. Ces paramètres restent dépendants du mélange de fréquences et de domaines de GIFT-Eval. Les auteurs signalent aussi qu’une rupture brutale de régime entre entraînement et test mettrait en défaut l’hypothèse de continuité sur laquelle repose leur sélection.

Dans la discussion GitHub du 21 septembre 2026, l’équipe rapporte avoir recalculé 17 lignes sur 97 : elles provenaient d’une ancienne version dont les artefacts sources avaient été perdus. La soumission a été mise à jour avec les résultats reproductibles depuis le matériel publié.

Enfin, au 9 octobre 2026, la rubrique licence du dépôt de code TW3-Cast ne déclare aucune licence propre au code ; elle renvoie aux licences d’origine des modèles de base. Avec le code de sélection non publié, ce point doit être clarifié avant une reprise du système.

7. Comment reprendre ces principes dans un système de prévision d’entreprise ?

Notre recommandation de cabinet est de traiter chaque changement de routage comme une livraison documentée. Cette lecture s’appuie sur la traçabilité par ligne exposée dans la publication TW3Cast du 16 septembre 2026.

  • Versionner ensemble la table, l’index des experts, les révisions des modèles de base et les points de contrôle.
  • Exiger une mesure datée pour chaque changement, avec l’historique utilisé et le critère d’admission.
  • Recharger les artefacts avant l’évaluation de livraison, puis conserver les prévisions et les mesures obtenues.
  • Archiver les éléments sources de chaque version pour pouvoir rejouer la décision et la livraison.

La fiche de TW3 Partners consacrée à la prévision de production photovoltaïque, sans date de publication affichée, décrit un autre système. Elle documente un moteur en conteneur Docker, un protocole figé avant évaluation et un rapport généré par le code, puis la livraison du moteur à l’équipe de déploiement. Le rapprochement porte sur ces principes de livraison et de vérification. Cette réalisation reste distincte du système de recherche TW3Cast.

FAQ

Qu’est-ce qu’une table de routage ?
C’est le fichier qui indique quel expert, ou quel mélange d’experts, servir pour une configuration et avec quels poids. Cette définition correspond à router.csv dans la publication TW3Cast du 16 septembre 2026.

Faut-il tout réentraîner pour améliorer le système ?
Dans TW3Cast, l’intégration d’un expert admis modifie une ligne sans réentraînement global. La publication du 16 septembre 2026 distingue cette opération de l’entraînement local du candidat et de sa vérification sur le backtest.

Le système prend-il des décisions en production ?
Le routage est figé avant le calcul des prévisions. La publication du 16 septembre 2026 prévoit toutefois deux garde-fous par fenêtre, dont les seuils sont fixes, capables de modifier le modèle servi.

Comment vérifier qu’une prévision importée correspond à la bonne période ?
TW3Cast utilise un contrôle de corrélation entre les prévisions importées et les fenêtres attendues. Le seuil de rejet documenté dans la publication du 16 septembre 2026 est une corrélation médiane inférieure à 0,30.

Peut-on reproduire exactement une prévision publiée ?
Le README du dépôt, vérifié le 9 octobre 2026, indique que la reproduction exacte des lignes soumises passe par les quantiles servis et archivés. Le script predict.py recalcule depuis les points de contrôle ; les variantes de contexte utilisées lors du service rendent sa correspondance avec la soumission approximative.

Quelle longueur d’historique faut-il pour une nouvelle source ?
La publication du 16 septembre 2026 décrit un backtest construit sur l’historique disponible, sans fixer de minimum universel. Nous recommandons de définir la période retenue en fonction de la fréquence, de l’horizon et des régimes à évaluer.

Pour aller plus loin

Sources