Architecture des données vers l'intelligence
Des données brutes aux décisions pilotées par l'agent : les données sont ingérées via des adaptateurs, une fédération sans copie et des collecteurs ; stockées brutes sur SQL et MPP ; abstraites en événements, profils, indicateurs et relations ; puis connectées via une ontologie pour l'agent IA.
Pourquoi les quatre niveaux sont-ils importants pour un agent IA ?
La performance d'un agent dépend de la qualité du contexte sur lequel il raisonne. La séparation de l'ingestion, du stockage brut, de l'abstraction et de l'ontologie confère au modèle une interface claire, contrôlée et connectée à tous les niveaux ; ses décisions sont ainsi justifiées, explicables et faciles à faire évoluer.
L'agent analyse le contexte, pas les lignes brutes.
Chaque couche fournit à l'agent une interface stable : événements, profils, indicateurs de performance et ontologie connectée. L'agent raisonne sur un contexte établi au lieu d'analyser et de fusionner des enregistrements bruts lors de l'inférence, ce qui garantit la reproductibilité de ses réponses.
Ingestion indépendante de la source
Comme la collecte constitue une couche distincte, le modèle ne dépend jamais de la manière dont un système est connecté. Ajoutez un adaptateur, fédérez un entrepôt de données existant ou exploitez l'interface ouverte API : tous les éléments ci-dessus présentent la même structure de données, ce qui garantit que les nouvelles sources n'affectent ni vos invites ni votre logique.
Une plateforme unique et cohérente
Les bases de données SQL et MPP restent synchronisées grâce à la capture des modifications, ce qui garantit que le contexte de l'agent repose sur une source unique et fiable, et non sur des copies divergentes. Les lectures opérationnelles et les analyses approfondies utilisent les mêmes enregistrements.
Vérité commerciale gouvernée
Les indicateurs sont définis de manière unique et fiable au sein d'une couche sémantique. Ainsi, les données sur lesquelles un agent se base sont identiques à celles affichées sur vos tableaux de bord. Les décisions restent explicables et auditables, contrairement aux agrégations ad hoc.
Relations explicites et traçables.
L'ontologie relie l'intention, le profil et la valeur commerciale, permettant ainsi de retracer une recommandation jusqu'à son contexte précis d'origine : les relations sont intégrées au modèle et ne sont pas recréées par l'agent à chaque appel.
Évolution sécurisée
Changez de modèle, ajoutez des sources de données ou modifiez le stockage via des contrats de couche stable. L'agent continue de traiter les mêmes abstractions, ce qui permet à l'intelligence de surface d'évoluer sans réécriture du code sous-jacent.
Des données brutes à une ontologie connectée
Chaque couche fournit à la couche supérieure une interface plus claire et mieux maîtrisée : ingestion, stockage brut, abstraction, puis l’ontologie sur laquelle l’IA agit. Ainsi, l’intelligence de surface évolue sans réécriture de l’architecture sous-jacente.
Couche d'ingestion des données
Collecte de données provenant de systèmes d’entreprise performants et ouverts.
Explorer cette couche →Adaptateurs de niveau entreprise
Adaptateurs prédéfinis pour les systèmes d'entreprise grand public : CDP, CRM, ERP, OMS et commerce.
Technologie zéro copie
Interrogez de grandes données d'entrepôt en place – pas de copie de données (Snowflake, Databricks, Data Cloud, Delta Sharing).
Collecteur de suivi des données
Suivi complet des événements web et mobiles et collecte des comportements via SDK
Données ouvertes API / SDK
API et SDK standardisés pour toute source personnalisée.
Couche de données brutes
Ingérez les données brutes et stockez-les dans des bases de données SQL et MPP avec synchronisation CDC en temps réel.
Explorer cette couche →Base de données SQL
Boutique structurée pour les transactions et les opérations.
Base de données MPP
Traitement massivement parallèle pour l'analyse à grande échelle.
Couche d'abstraction et de compréhension des données
Analyse des données brutes pour en extraire des modèles et des informations pertinentes.
Explorer cette couche →Profil utilisateur et étiquetage
Extraction des données brutes en étiquettes de membre et création de profils utilisateurs.
Modèle d'événements et reconnaissance d'intention
Analysez les comportements bruts en modèles d'événements et déduisez l'intention de l'utilisateur.
Extraction de métriques et vérité commerciale
Extraire des indicateurs clés de performance (KPI) à partir de données brutes et révéler la réalité métier.
Relation et affinité
Analysez les parrainages et les commandes sous forme de graphe de relations entre membres : liens convertis, hubs et foyers potentiels.
Affinité et similarité
Modéliser la similarité statistique à partir de données réelles : achats groupés de produits, affinité de catégorie et profils similaires.
Couche ontologie-actions
Liez l'intention, le profil et l'activité grâce au modèle d'entité utilisateur et permettez aux agents de prendre des décisions.
Explorer cette couche →Comment une simple action se transforme en décision
Les calques sont plus faciles à voir en mouvement. Voici un signal de vente au détail qui traverse les quatre – d'un clic brut à la prochaine meilleure action d'un agent.
Les actions d'un acheteur arrivent
Un membre consulte la même veste trois fois, l'ajoute à son panier, puis quitte le site sans l'acheter. Ces visites et ajouts au panier sont enregistrés par le système de suivi, en plus de l'historique des commandes provenant des systèmes de commerce et de CRM connectés.
Tout est présenté tel quel
Les événements et les enregistrements sont simultanément écrits sous forme de données brutes dans les bases de données SQL et MPP, et synchronisés grâce à la capture des modifications. Les mêmes informations sont ainsi disponibles pour une consultation opérationnelle et une analyse approfondie.
Les données brutes prennent tout leur sens
Le modèle d'événements interprète « vue répétée + panier, aucun achat » comme un signal d'intention forte ; des étiquettes la désignent comme membre à forte valeur ajoutée en fin de période d'inactivité ; la couche de métriques connaît déjà sa valeur vie client et son taux de conversion — une définition gouvernée pour chacun.
L'agent décide
L’ontologie relie l’intention, le profil et la valeur de l’utilisateur en une image cohérente. L’agent analyse ce contexte et décide d’une reconquête personnalisée avec une incitation limitée ; cette décision est traçable jusqu’aux signaux précis qui la sous-tendent.
Où se brancher
Vous travaillez sur les couches, pas sur l'infrastructure. Chaque couche inférieure correspond à une interface stable avec sa propre documentation : choisissez votre point de départ.
Connectez vos systèmes
Importez des données via des adaptateurs de produits, une fédération sans copie ou l'interface de données ouverte – pas de canaux sur mesure.
Guide d'intégration →Suivi du comportement web et mobile
Capturez les pages vues, les vues de produits, les recherches et les événements du panier avec le collecteur SDK au point d'interaction.
Suivi web →Consultez les indicateurs et profils contrôlés.
Interrogez la couche de métriques sémantiques et les profils des membres via les outils API et MCP — les définitions sont identiques partout.
MCP et indicateurs →Étendre le modèle
Diffusez des sources personnalisées via l'interface ouverte API, abonnez-vous aux webhooks sortants et modélisez des objets personnalisés.
API référence →Les questions qui déterminent l'architecture
Si nous standardisons votre couche sémantique et votre ontologie, comment éviter la dépendance à un fournisseur ?
Les couches sont des contrats, pas une boîte noire. Vos données brutes restent dans des bases de données SQL et MPP standard (ou dans votre propre entrepôt de données sans copie, que nous ne vous demandons jamais de copier). Vos définitions de métriques, d'étiquettes et d'identités sont déclaratives, versionnées et exportables dans un format que vous contrôlez. Vous conservez les données et les définitions ; l'abstraction repose sur des bases de données ouvertes plutôt que d'être enfermée dans un format propriétaire.
Où sont physiquement stockées nos données et qu'est-ce qui est réellement transféré lors d'une fédération sans copie ?
Pour les sources fédérées, la requête est envoyée à votre entrepôt de données (Snowflake, Databricks, Salesforce Data Cloud ou Delta Sharing) et lue sur place avec les identifiants que vous avez définis. Les tables brutes ne sont jamais dupliquées dans notre espace de stockage ; votre entrepôt reste donc le système de référence et ses contrôles d'accès et de localisation sont toujours applicables. Seul le résultat de la requête, et non les tables sous-jacentes, quitte votre périmètre. Les sources ingérées sont stockées dans un espace de stockage isolé au niveau du locataire, et les données de consentement et de confidentialité sont versionnées afin que les données réglementées soient gérées conformément aux politiques en vigueur et non de manière ad hoc.
Qui définit la signification d'une métrique et comment est-elle gérée pour des milliers d'utilisateurs ?
Les définitions des indicateurs sont centralisées dans une couche sémantique unique et gouvernée, et non dispersées entre tableaux de bord et carnets de notes. Chaque définition a un responsable ; les indicateurs certifiés nécessitent sa validation ; toute modification est examinée et versionnée avec un historique des modifications, et son cache est invalidé afin d’éviter la persistance de données obsolètes. C’est ce qui permet d’éviter le problème des « trois réponses différentes pour un même indicateur de performance clé » à l’échelle de l’organisation.
Comment nos données sont-elles isolées de celles des autres locataires, et quel est l'impact d'un seul bug ?
La portée du locataire est appliquée dans le flux de données ; il n’est pas nécessaire que le code de l’application se souvienne d’un filtre. L'accès aux métriques et aux profils s'effectue en lecture seule sur les vues de contrat propres à chaque locataire — une couche de sécurité qui filtre les données par locataire avant même qu'une requête n'accède à une ligne — de sorte que même une requête personnalisée ne peut pas accéder aux données d'un autre locataire ni aux tables brutes. L'isolation étant une propriété du chemin d'accès aux requêtes et non une compétence propre à chaque développeur, un bug applicatif ne se traduit pas par une vulnérabilité partagée entre les locataires.
Comment auditer et limiter une action effectuée par l'agent ?
Chaque action d’un agent est basée sur les abstractions gouvernées et l’ontologie, ce qui permet de remonter à l’intention, au profil et au contexte métrique précis utilisés, et non à une invite opaque. Les écritures qu’un agent peut effectuer sont limitées par des garde-fous et des limites de débit côté serveur. Les actions sensibles, telles que les incitations ou les dépenses, peuvent nécessiter une approbation humaine, et chaque action est consignée à des fins d’audit. L’agent raisonne sur la base de vos données de référence gouvernées et reste vérifiable, au lieu d’agir sur un contexte impossible à reconstituer.
Sur cinq ans, pourquoi une architecture en couches est-elle moins coûteuse à gérer que notre entrepôt de données associé à des solutions ponctuelles ?
Le coût récurrent d'une architecture entrepôt de données + outils de gestion des points réside dans l'intégration et la réconciliation : chaque nouvelle source nécessite une connexion spécifique, chaque outil redéfinit les indicateurs et l'identité, et votre équipe doit gérer les écarts entre eux. Séparer l'ingestion, le stockage, l'abstraction et l'ontologie permet de connecter une source, de définir un indicateur et de résoudre l'identité une seule fois ; tous les éléments supérieurs les réutilisent. Vous troquez une multitude d'intégrations fragiles et de définitions contradictoires contre un substrat unique et un ensemble de définitions cohérentes.
Privilégiez le contexte connecté aux données brutes.
Ingestion via des adaptateurs, une fédération sans copie, des collecteurs de suivi et une interface ouverte API/SDK ; stockage des données brutes dans une base de données SQL et MPP synchronisée avec CDC ; abstraction de ces données en modèles d'événements, chronologies, profils et indicateurs ; puis liaison via le modèle d'entité utilisateur afin que l'agent prenne des décisions en fonction du contexte connecté.
Connexe : la boucle de plateforme et le suivi Web SDK.