Prévision de séries temporelles en un seul appel SQL : le ai_forecast() de Databricks

Il y a une demande que toute équipe data a déjà entendue : « donne-moi une prévision de ventes pour le trimestre prochain ». Ça semble trivial, mais ça devient souvent un mini-projet — un notebook, le choix d'une bibliothèque, la comparaison de modèles, le backtest, l'enregistrement dans MLflow, la planification du job. Deux ou trois semaines plus tard, vous livrez un chiffre dont le métier avait besoin hier.

Le ai_forecast() de Databricks a été conçu pour raccourcir exactement ce chemin. C'est une fonction SQL qui renvoie une table (table-valued function) : vous pointez vers votre série temporelle, définissez l'horizon de prévision et récupérez les valeurs projetées avec leurs intervalles de confiance déjà inclus — sans entraîner de modèle, sans infrastructure de ML.

Cet article montre comment l'utiliser, ce que la fonction renvoie, et — tout aussi important — quand ne pas l'utiliser.

Le problème qu'il résout

La plupart des prévisions dans une entreprise ne sont pas un problème de recherche ; c'est un problème opérationnel. Quelqu'un a besoin d'un chiffre raisonnable, vite, pour planifier le stock, dimensionner une équipe ou boucler un budget. Dans ces cas, monter un pipeline de machine learning complet est disproportionné par rapport à la valeur de la question.

En même temps, l'alternative « rapide » traditionnelle — exporter vers un tableur et tracer une ligne de tendance — casse la gouvernance : les données sortent de l'environnement contrôlé, personne n'audite le calcul et chaque service utilise une méthode différente.

ai_forecast() se place au milieu : aussi rapide qu'une requête SQL, mais s'exécutant dans Unity Catalog, avec le lignage et les permissions préservés.

La syntaxe

La forme minimale a besoin de quatre choses : la table observée, l'horizon, la colonne de temps et la colonne de valeur.

-- prévision jusqu'à la fin de l'année
SELECT * FROM ai_forecast(
  observed  => TABLE(daily_sales),
  horizon   => '2026-12-31',
  time_col  => 'ds',
  value_col => 'sales'
);

Les paramètres principaux :

• observed — l'entrée d'entraînement, passée comme TABLE(...). Ce peut être une table, une vue ou une sous-requête.
• horizon — la fin (exclusive) de la prévision, sous forme de DATE, TIMESTAMP ou chaîne. La fonction projette de la dernière observation jusqu'à ce point.
• time_col — la colonne de temps (DATE ou TIMESTAMP).
• value_col — la colonne à prévoir (doit être convertible en DOUBLE). Elle accepte aussi un tableau de colonnes pour prévoir plusieurs séries à la fois.

Et les optionnels qui rapportent le plus au quotidien :

• group_col — une ou plusieurs colonnes de regroupement. Avec elle, vous générez une prévision indépendante par groupe (magasin, SKU, région) en un seul appel, sans boucle Python.
• prediction_interval_width — la largeur de l'intervalle de confiance (défaut 0.95).
• frequency — la granularité de la série (défaut auto).
• seed — une graine pour des résultats reproductibles.

Prévision par groupe

group_col est ce qui transforme la fonction de « jouet » en outil de production. Imaginez prévoir les ventes de 500 magasins :

SELECT * FROM ai_forecast(
  observed  => TABLE(SELECT ds, sales, store_id FROM daily_sales),
  horizon   => '2026-12-31',
  time_col  => 'ds',
  value_col => 'sales',
  group_col => 'store_id'
);

Chaque store_id reçoit son propre modèle et sa propre prévision, partitionnés automatiquement. Le résultat sort empilé, prêt à être matérialisé dans une table Delta ou à alimenter un tableau de bord.

Ce que la fonction renvoie

La sortie est une table avec la colonne de temps, la valeur prévue et les bornes de l'intervalle — quelque chose comme :

 ds           sales_forecast   sales_upper   sales_lower
 2026-10-01   1 240,5          1 410,2       1 070,8
 2026-10-02   1 255,9          1 428,7       1 083,1

Comme c'est du SQL, vous chaînez directement : matérialisez avec CREATE TABLE ... AS SELECT, joignez avec les valeurs réelles pour suivre l'erreur, ou exposez dans une vue pour la BI. Rien ne sort du lakehouse.

Pourquoi c'est important

Trois gains concrets :

1. Zéro pipeline de ML. La sélection du modèle est automatique. Vous ne choisissez pas entre ARIMA, Prophet ou gradient boosting — le service décide et ajuste. Cela abaisse la barrière d'entrée pour ceux qui sont forts en SQL mais ne vivent pas de la modélisation.

2. Passage à l'échelle par groupe sans code supplémentaire. Un seul appel couvre des centaines ou des milliers de séries. Ce qui était une boucle for sur les groupes avec parallélisation manuelle devient une ligne de group_col.

3. Gouvernance préservée. Parce qu'elle s'exécute comme une fonction native sur des données d'Unity Catalog, les mêmes permissions, le même lignage et le même audit que le reste de votre environnement s'appliquent. La prévision cesse d'être un script isolé sur la machine de quelqu'un.

Quand NE PAS l'utiliser

Être honnête sur les limites fait partie de la valeur :

• Quand le problème exige des features externes. Si la prévision dépend fortement du prix, des promotions, de la météo ou d'événements, un modèle dédié qui ingère ces variables surpassera une fonction automatique qui ne regarde que l'historique de la série elle-même.
• Quand vous avez besoin d'une explicabilité fine. Pour un chiffre qui va soutenir une décision réglementaire ou financière sensible, vous voudrez probablement contrôler et documenter la méthode.
• Séries très courtes ou très bruitées. Sans historique suffisant, toute méthode — automatique ou non — devine. La fonction ne fait pas de magie avec des données manquantes.

Pour tout le reste — l'immense majorité des demandes « j'ai besoin d'un chiffre pour planifier » — ai_forecast() livre en minutes ce qui coûtait un sprint.

Comment commencer

1. Assurez-vous d'avoir une table avec une colonne de temps (DATE/TIMESTAMP) et une colonne de valeur numérique, dans Unity Catalog.
2. Lancez la version minimale de la requête avec un horizon court pour valider le format de sortie.
3. Ajoutez group_col et ajustez prediction_interval_width selon le besoin.
4. Matérialisez le résultat dans une table Delta et planifiez un refresh — ou laissez-le en vue pour des requêtes à la demande.

C'est le genre de fonctionnalité qui change le coût de répondre à une question : de « ouvrir un projet » à « écrire une requête ».