“On ne peut pas encore faire de prévisions, nous n’avons pas assez de données” est l’une des raisons les plus fréquentes pour lesquelles un projet prédictif ne démarre jamais. Cela semble responsable. C’est en général faux, ou du moins bien trop vague pour qu’on puisse agir, car la vraie réponse n’est pas un nombre fixe de lignes. Elle dépend du rythme de ce que vous cherchez à prévoir.
L’erreur cachée derrière cette excuse consiste à prendre le volume de données pour l’exigence réelle. Ce dont une prévision a vraiment besoin, c’est d’un historique suffisant pour voir le motif se répéter. Un signal dont le cycle est quotidien atteint ce point en quelques semaines. Un signal dont le cycle est annuel n’y arrive pas, quel que soit le nombre de relevés par seconde que vous collectez entre-temps. Saisissez bien cette distinction et vous pourrez en général démarrer bien plus tôt que vous ne le craigniez.
La règle qui compte : couvrir le cycle plusieurs fois
Une prévision apprend en voyant un motif se produire plus d’une fois. L’exigence est donc liée à votre plus long cycle significatif, pas à un nombre de lignes.
Si votre signal se répète chaque jour, charge énergétique, taux d’occupation, consommation d’eau, il vous faut au moins quelques semaines d’historique pour que le modèle voie plusieurs fois les formes des jours de semaine et du week-end. Si le cycle dominant est hebdomadaire, il vous faut deux ou trois mois. S’il est saisonnier sur l’année, il vous faut vraiment plus d’un an, et il n’y a pas de raccourci, car un modèle ne peut pas prévoir un été qu’il n’a jamais vu.
Une fréquence d’échantillonnage élevée ne remplace pas la durée couverte. Un million de relevés issus de trois jours ne montre toujours que trois jours au modèle. Pour la prévision, la couverture du calendrier l’emporte presque toujours sur le volume brut.
Plus de données n’est pas automatiquement mieux
Il existe un second piège, à l’opposé : accumuler des années d’historique et tout donner au modèle. Les vieilles données peuvent nuire. Si votre processus a changé, une ligne a été modernisée, un bâtiment rénové, une grille tarifaire modifiée, alors les données antérieures au changement apprennent au modèle un monde qui n’existe plus. Il prévoira le passé.
Une position pragmatique : utilisez assez d’historique pour couvrir votre cycle plusieurs fois, privilégiez les données récentes, et acceptez d’écarter tout ce qui précède un changement de régime connu. Un modèle entraîné sur la dernière période représentative bat en général un modèle entraîné sur tout ce qui existe depuis l’installation.
Vos besoins dépendent aussi du modèle
Les modèles plus simples ont davantage besoin de structure que de volume. Une référence saisonnière ou un ajustement Prophet peut produire une prévision utile à partir de quelques cycles de données propres. Les modèles d’apprentissage profond, un LSTM en particulier, font l’inverse : ils réclament beaucoup d’exemples pour apprendre des motifs non linéaires, et ils surapprennent gravement sur des historiques courts, produisant des absurdités pleines d’assurance.
C’est une raison de plus de commencer simplement. Au début d’un déploiement, quand l’historique est mince, un modèle saisonnier n’est pas seulement plus facile, il est plus adapté. Gardez les modèles gourmands en données pour le moment où vous aurez à la fois le volume et un besoin avéré.
Comment démarrer avant d’en avoir “assez”
Vous n’avez pas à attendre dans le noir pendant que les données s’accumulent. Mettez en production la prévision la plus simple dès que vous avez quelques cycles, une moyenne mobile, puis une référence saisonnière, et laissez-la tourner. Ses premières prédictions seront grossières. Ce n’est pas grave, car vous l’évaluez aussi : vous savez donc exactement à quel point elles sont grossières et vous regardez l’erreur diminuer à mesure que l’historique s’étoffe.
Faire tourner une prévision faible en conditions réelles vous apprend plus que d’attendre un jeu de données parfait. Elle fait remonter les problèmes de qualité des données, les trous et les dérives tant que les enjeux sont faibles, et elle donne aux opérateurs quelque chose auquel réagir et qu’ils peuvent corriger. Le jour où vous aurez assez d’historique pour un modèle sérieux, vous disposerez déjà d’une boucle opérationnelle où l’insérer.
La réponse courte
Un historique suffisant, cela veut dire quelques répétitions de votre plus long cycle important, pondéré vers les données récentes, coupé au dernier vrai changement de votre processus. Pour la plupart des signaux IoT à motif quotidien, cela se compte en semaines, pas en années. Commencez dès maintenant avec un modèle simple, évaluez-le, et faites-le évoluer quand les données le justifient.
La boucle qui rend tout cela facile, lire les données récentes, prévoir, évaluer, recommencer, s’exécute selon une planification dans TagoIO Analytics, pour que vous puissiez commencer à prévoir dès la semaine où vos capteurs entrent en service.
Vous pouvez aussi découvrir jusqu’où votre historique vous mène sans rien écrire. Connectez-vous à TagoIO Analytics sur sight.tago.io/login avec votre compte TagoIO, choisissez un signal et entraînez un modèle en quelques minutes. Il produit des prévisions et de la détection d’anomalies à partir des données dont vous disposez déjà, sans code et sans data scientist.
