Prévisions (bêta)
Ouvrez Data science → New forecast (science des données → nouvelle prévision) pour prévoir l’évolution d’une mesure à partir d’une source SQL connectée. Décrivez la mesure et l’horizon, vérifiez le plan proposé, choisissez vos règles de validation, puis examinez le premier résultat avant de le publier. Un pipeline conserve cette définition et ses exécutions pour vous permettre de les retrouver et de les actualiser.
Ce guide suit les ventes nettes mensuelles d’Acme en EUR, avec une prévision d’octobre à décembre à partir des mois terminés jusqu’à septembre 2026. Les commandes de l’application sont en anglais. Sélectionnez une capture pour l’ouvrir en taille réelle.
Avant de commencer
- Connectez-vous à l’application Datarelix.
- Disposez d’une connexion à une base de données active avec accès en lecture aux tables ou à la vue de reporting. Si vous ne gérez pas cet accès, demandez au responsable de la base de fournir la connexion et de confirmer la définition des ventes.
- Rendez les tables pertinentes disponibles dans la sélection du schéma. Des descriptions de colonnes précises aident à choisir les bonnes dates et mesures.
- Prévoyez un historique daté et une mesure numérique. Un horizon plus long et les comparaisons saisonnières demandent davantage d’historique ; la vérification des données détermine ce que l’historique retenu permet.
La prévision nécessite actuellement SQL. Les connexions Kusto et Elasticsearch sont exclues du sélecteur. Les connexions avec authentification déléguée de l’utilisateur via Microsoft Entra ou Databricks sont également exclues ; demandez au responsable de la connexion une méthode compatible et adaptée. Les connexions en pause ne sont pas proposées.
1. Décrire la prévision
Ouvrez Data science dans la barre latérale, puis New forecast. Dans Where is the data? (où sont les données ?), sélectionnez votre connexion. Dans What do you want to know? (que voulez-vous savoir ?), saisissez :
Prévoir les ventes nettes mensuelles d’Acme en EUR pour les trois prochains mois. Exclure les commandes annulées et utiliser uniquement les mois terminés.
How far ahead (optional) (horizon facultatif) attend un nombre de périodes, pas une date. Saisissez 3 ; Per (optional) (périodicité facultative) permet de choisir Month (mois). Vous pouvez laisser ces champs vides si la demande précise déjà l’horizon et la fréquence, puis vérifier le plan.
Dans Anything the AI should know? (optional) (précisions facultatives), indiquez les définitions qui modifient le résultat :
Les ventes nettes sont hors taxes et incluent les remboursements enregistrés. Utiliser UTC. Un mois absent indique des données manquantes, pas des ventes nulles.
Choisissez Draft the plan (préparer le plan). Cette action prépare la requête et vérifie les données sources ; elle n’entraîne pas encore de modèle. Une demande de prévision dans la conversation principale peut aussi proposer un brouillon à ouvrir dans ce parcours.
2. Vérifier le plan et les données
Dans Check the plan (vérifier le plan), contrôlez la mesure, l’unité, l’agrégation, la période, le regroupement, l’horizon, les exclusions et le fuseau horaire. Pour Acme, le plan doit indiquer les ventes nettes en EUR, additionnées par mois, sur trois mois à venir, à partir de périodes terminées.
Si des questions de clarification apparaissent, répondez et attendez la mise à jour du plan et de la vérification. Continue (continuer) reste indisponible tant que des questions ou des problèmes bloquants subsistent.
The data can support this forecast (les données permettent cette prévision) signifie que les contrôles préalables ont réussi. Ce statut ne garantit pas une prédiction exacte. Lisez aussi les problèmes signalés, les modèles admissibles et le nombre de fenêtres de validation.
Examiner la requête et la définition
Développez Inspect and customize (examiner et personnaliser) pour consulter le SQL, les correspondances de colonnes, les transformations, les variables et les paramètres de validation et des modèles. Un analyste doit confirmer la période, la définition des ventes et l’absence de duplication des montants par les jointures.
Une requête agrégée doit renvoyer une ligne par période et segment. Préservez la mesure convenue : un décompte mensuel déjà calculé en SQL est une valeur de décompte, pas un ensemble de transactions à compter de nouveau. Les requêtes sur des lignes brutes utilisent l’agrégation choisie pour construire les périodes.
Examinez particulièrement ces réglages :
| Réglage | Point à vérifier |
|---|---|
| Colonnes de date, de cible et de groupe | La date représente la période ; la cible est numérique ; le regroupement produit les segments voulus. |
| Périodes manquantes | Utilisez zéro uniquement si l’absence d’enregistrement signifie une activité nulle. L’interpolation estime les lacunes ; écarter des observations manquantes ne prouve pas une activité nulle. |
| Périodes terminées et fuseau horaire | Évitez de comparer un mois courant partiel à des mois historiques entiers. |
| Fenêtres de validation | Chaque test apprend sur l’historique antérieur puis prédit une période ultérieure. Un horizon plus long peut réduire le nombre de tests disponibles. |
| Intervalle de prévision | Le niveau choisi est un objectif ; examinez la couverture mesurée après l’exécution. |
| Variables externes | Les variables historiques nécessitent un décalage suffisant ; les variables connues à l’avance nécessitent des valeurs aux dates prévues. Mentionner une promotion ne fournit pas ces valeurs. |
Après une modification, choisissez Check the data again (revérifier les données). L’édition efface le résultat de la vérification précédente ; continuez après la réussite du nouveau contrôle. Consultez rédiger et vérifier les requêtes pour la revue SQL.
3. Choisir les validations, l’effort et les actualisations
Choisissez Continue, donnez un Name (nom) reconnaissable au pipeline et sélectionnez votre niveau d’intervention :
| Choix | Comportement |
|---|---|
| Let it run (laisser fonctionner) | Vous validez la prévision initiale et les changements du modèle ou de sa configuration. Les actualisations courantes de la configuration acceptée peuvent être publiées automatiquement. |
| Review every result (examiner chaque résultat) | Chaque résultat proposé attend votre approbation avant publication. |
| Review everything (tout examiner) | Vous approuvez chaque plan d’exécution et chaque publication proposée. |
Les modifications importantes de la définition nécessitent une validation quel que soit le réglage. Vous pouvez aussi cocher Also show me the plan before the first run (one time) (examiner le plan avant la première exécution uniquement), sans modifier les règles permanentes.
Dans How much effort? (quel effort ?), choisissez Quick, Standard ou Thorough (rapide, standard ou approfondi). Les cartes indiquent des plafonds d’expériences et de minutes de calcul, pas un délai promis ni une garantie de précision. Les familles admissibles comprennent Seasonal baseline, Prophet, Chronos-2, Random forest et LightGBM ; les données, la disponibilité et l’allocation déterminent les essais exécutés.
Dans Keep it fresh (maintenir à jour), choisissez Only when I ask, Every day, Every week ou Every month (à la demande, chaque jour, semaine ou mois). Les actualisations planifiées commencent après la publication d’une prévision. Les requêtes sources peuvent entraîner des frais auprès de votre fournisseur de base de données ou de cloud.
Choisissez Create and start (créer et démarrer), ou Create and plan (créer et préparer) si vous avez demandé une approbation préalable. Un plan en attente propose Approve, Adjust, Ask for an explanation et Cancel (approuver, ajuster, demander une explication et annuler). Examinez le lot d’essais proposé et son plafond avant de l’approuver.
4. Examiner et publier le résultat
La barre du pipeline indique Source → Data check → Learn → Review → Forecast → Keep fresh (source, vérification, apprentissage, revue, prévision et actualisation). Le premier résultat attend votre décision. Fermer le navigateur ne l’approuve pas ; revenez au pipeline pour reprendre la revue.
Vérifiez les éléments suivants :
- Accuracy (précision) : une valeur plus faible de la métrique d’erreur est préférable. La MAE exprime l’erreur absolue moyenne dans l’unité de la cible, pas un pourcentage de précision.
- Référence saisonnière : répéter la saison précédente peut être le meilleur choix disponible. Un modèle plus complexe ne garantit pas une amélioration.
- Consistency and weak spots (régularité et points faibles) : examinez les différences entre tests historiques et segments.
- Range coverage (couverture de l’intervalle) : comparez la couverture observée à l’objectif. Un objectif de 90 % ne garantit pas que les observations futures seront dans l’intervalle 90 % du temps.
- Things to know (points à connaître) : lisez l’interprétation, les constats non concluants et la fin de l’historique. Les résultats passés ne permettent pas d’établir l’effet d’un événement métier absent des données.
Choisissez Publish candidate (publier le candidat) pour en faire le résultat courant du pipeline. Keep current model (conserver le modèle actuel) garde le modèle déjà publié ; à la première exécution, aucun modèle n’existe encore et ce choix laisse donc le pipeline sans prévision publiée. Ask for an explanation permet de questionner la recommandation avant de décider.
« Publier » signifie ici sélectionner le résultat courant dans votre compte. Cette action ne crée pas de page publique et ne partage pas la prévision avec vos collègues.
5. Lire, actualiser et améliorer la prévision
Refresh (actualiser) relit la source et réentraîne la configuration acceptée. Improve (améliorer) explore d’autres configurations dans le périmètre et l’allocation autorisés. Un changement de modèle ou de configuration nécessite une revue avant publication ; une recherche sans meilleure configuration peut conserver le modèle actuel.
Dans Details (détails), ouvrez Runs (exécutions) pour consulter les résultats passés, Inspect and customize pour examiner ou modifier la spécification et les résultats des essais, ou Settings (paramètres) pour modifier les règles de validation, l’allocation de calcul et la fréquence d’actualisation. Enregistrez les changements permanents avec Save settings (enregistrer). Utilisez Pause pipeline pour suspendre les nouvelles exécutions et Activate pipeline pour les reprendre.
La planification des prévisions est distincte de l’actualisation des tableaux de bord, qui est manuelle. Demander une validation supplémentaire pour une opération ne réécrit pas les règles enregistrées du pipeline.
Résoudre les problèmes
| Situation | Action |
|---|---|
| Aucune connexion utilisable | Vérifiez que la connexion est active, utilise SQL et possède une méthode d’authentification compatible. |
| Historique insuffisant | Réduisez l’horizon ou ajoutez de l’historique. Examinez le segment le plus court en cas de regroupement. |
| Périodes dupliquées ou résultat plafonné | Corrigez l’agrégation et les jointures, ou réduisez le périmètre pour récupérer toute la série. N’entraînez pas sur un résultat tronqué. |
| Dates de fin différentes entre segments | Recherchez les données tardives ou manquantes. Les segments doivent couvrir la même dernière période ; ne remplissez par zéro que si le sens métier le justifie. |
| Variables futures manquantes | Fournissez les valeurs aux dates et segments prévus, ou révisez la variable et sa disponibilité. |
| Plan modifié, progression bloquée | Choisissez Check the data again et résolvez les nouveaux problèmes. |
| Exécution en attente de validation | Ouvrez le pipeline et prenez la décision demandée. Attendre ne vaut pas approbation. |
| Aucun score de validation exploitable | Examinez les valeurs réelles manquantes, l’horizon et les fenêtres de validation. Sans candidat évalué, aucune prévision ne peut être publiée. |
| Échec de l’actualisation | Vérifiez la connexion, le schéma et la dernière exécution. Un résultat ancien ne constitue pas une actualisation réussie. |
Pour les choix de définition des ventes de ce parcours, consultez prévoir les ventes mensuelles depuis votre base.