Un historique de commandes peut alimenter l’analyse des volumes, une application de consultation et un modèle de prévision. Les trois exploitent des produits, des quantités et des dates. L’analyse agrège plusieurs années de données, l’application répond à une requête ciblée et le modèle prédictif utilise les informations disponibles à la date de chaque prévision.
L’architecture d’une plateforme de données relie ces usages autour de modèles partagés. L’intégration des sources, les identifiants et l’historique forment une base commune ; les modes de calcul et de publication restent adaptés à chaque application. Une nouvelle fonctionnalité peut ainsi réutiliser les données préparées tout en disposant de sa propre interface.
L’exemple des commandes servira de fil conducteur. Il décrit des choix de conception transposables à d’autres données, sans supposer une organisation particulière ni présenter un déploiement client.
Des sources aux modèles partagés
Le logiciel de gestion enregistre l’en-tête, les lignes, les produits, les prix et les statuts d’une commande dans son modèle transactionnel. L’entrepôt reconstruit ces relations pour l’analyse, avec une granularité explicite. Une ligne de commande, un changement de statut et un produit sont des objets distincts, même lorsqu’un export les rassemble.
Les données reçues conservent leurs identifiants d’origine et leur date de collecte. Les transformations rapprochent ensuite les références entre systèmes et produisent des tables de faits et de dimensions. Une dimension produit peut porter les classifications successives d’un article ; les faits décrivent les quantités commandées à une date donnée. Cette séparation rend possibles plusieurs lectures du même historique.
Une réalisation sur Google Cloud peut conserver les fichiers dans Cloud Storage, charger les données brutes dans BigQuery et exécuter les transformations SQL avec dbt. Airflow organise les dépendances et les exécutions. Le diagramme distingue cette préparation commune des trois voies de restitution.
Ce découpage distingue la transformation des sources de la publication vers les applications. Les modèles partagés conservent le catalogue de produits et ses identifiants pour relier les représentations utilisées par les différentes applications.
Un historique exploitable pour l’analyse et la prévision
Supposons qu’un produit change de famille en septembre. Une analyse peut appliquer la classification actuelle à toutes les commandes, ou conserver celle qui était en vigueur à chaque vente. Les deux lectures répondent à des questions différentes. Le modèle les rend explicites grâce aux périodes de validité des versions. Les snapshots dbt proposent notamment un mécanisme d’historisation des lignes modifiées ; leur fréquence de capture détermine les changements effectivement observés.
L’entraînement prédictif distingue la date d’un événement de la date à laquelle son information est devenue disponible. Une correction reçue en octobre peut concerner une commande de juillet. L’utiliser pour simuler une prévision produite en août introduirait une connaissance du futur. La constitution des jeux d’entraînement tient donc compte des dates de disponibilité, en plus des dates métier. La documentation Feast sur les jointures temporelles illustre cette différence et les précautions liées aux corrections tardives.
Chaque version publiée identifie la période couverte et les transformations utilisées. Des contrôles de schéma, d’unicité et de relations entre tables précèdent sa mise à disposition. Les tests de données dbt permettent d’exprimer une partie de ces règles. Ces tests couvrent les assertions implémentées. La vérification de complétude compare aussi les périodes, les enregistrements ou les totaux attendus avec ceux des sources.
Le flux représente la publication d’un jeu de données. L’entraînement, l’évaluation et la mise en service d’un modèle prédictif possèdent ensuite leur propre cycle. Une mise à jour de l’historique ne déclenche pas automatiquement le remplacement du modèle utilisé en production.
Des interfaces pour les applications et l’IA
Les modèles partagés deviennent accessibles par plusieurs interfaces. Le tableau de bord interroge les faits et leurs dimensions pour calculer les agrégats. Le traitement prédictif reçoit des variables calculées sur une période définie. L’application consulte une vue de lecture indexée, publiée dans PostgreSQL et exposée par une API .NET dans l’exemple illustré.
Une couche sémantique complète ce dispositif lorsque plusieurs outils partagent les mêmes mesures. Elle associe aux entités leurs relations et les règles de calcul. La couche sémantique de dbt expose ces définitions aux outils analytiques et aux applications ; son intégration MCP les rend également accessibles à des assistants d’IA. Une question sur les quantités commandées peut s’appuyer sur une mesure définie, avec ses dates et ses exclusions.
L’API exécute le calcul défini dans la couche sémantique. L’assistant sélectionne la mesure, les filtres et la période à partir de la demande. La réponse gagne à présenter ces éléments avec la date d’actualisation. Les permissions s’appliquent dans le service de données, indépendamment des instructions adressées au modèle.
Les résultats prédictifs suivent la même logique de publication. Une prévision enregistrée comprend sa valeur, son horizon, la date de calcul et la version du modèle. L’application peut la rapprocher des quantités observées en conservant la distinction entre observation et estimation. La plateforme relie ainsi les données historiques au logiciel qui exploite le résultat.
Des traitements adaptés à chaque usage
Un agrégat sur cinq ans, la lecture d’une commande et le calcul d’une prévision imposent des profils d’exécution différents. L’entrepôt convient aux parcours analytiques étendus. Une base de lecture dédiée peut servir les requêtes ciblées d’une application, avec ses index et son dimensionnement. La séparation des modèles de lecture et d’écriture décrit ce principe, ainsi que le travail de synchronisation qu’il introduit.
Dans l’architecture présentée, l’API publie des données préparées et des prévisions. Les opérations qui créent ou modifient une commande restent dans le système transactionnel qui en porte les règles. Le rafraîchissement de la copie de lecture possède son propre délai ; l’application affiche l’état et la date des données qu’elle consulte.
Le choix entre lots planifiés et flux d’événements découle de ce délai de publication. Une synthèse quotidienne peut employer un traitement nocturne. Une vue actualisée fréquemment demande une autre chaîne d’alimentation. Les deux peuvent partager les identifiants, les définitions et les transformations de référence, avec des ressources d’exécution séparées.
La séparation entre ingestion, modèles et interfaces de publication fournit des points d’intégration identifiés pour une nouvelle source, un modèle prédictif, une interface mobile ou une mesure analytique. Chaque extension dispose de modèles et d’interfaces identifiés sur lesquels s’appuyer. L’entrepôt fournit les historiques partagés aux requêtes analytiques et aux services logiciels qui les utilisent.