La correction est une architecture, pas une feature

La correction est une architecture, pas une feature

Chaque vendor d'analytics et d'IA dans la marketing tech vous dit que ses chiffres sont exacts. La partie exacte n'est pas la revendication. La partie exacte est de savoir si l'architecture peut la livrer. La plupart ne le peuvent pas.

Cette page est pour les buyers techniques, CTOs, et quiconque essaie d'évaluer si un vendor Operations AI (nous inclus) a réellement le substrat pour revendiquer la correction. C'est aussi pour nos investisseurs, qui continuent à demander ce qu'il y a en dessous. Écrit par Rick, qui l'a construit.

La version courte : il y a trois engagements architecturaux qui séparent l'infrastructure Operations AI de tout le reste. Aucun n'est une décoration. Tous les trois doivent être vrais dès le jour un, parce que les ajouter plus tard signifie reconstruire le produit.

Pourquoi « exact » est le mauvais mot

Presque chaque vendor de données marketing dit qu'il est exact. Triple Whale, Northbeam, Whatagraph, Looker, Hex. Les plateformes elles-mêmes (Meta, Google, TikTok) disent qu'elles sont exactes. Ils ne peuvent pas tous avoir raison, parce qu'ils rapportent des chiffres différents pour les mêmes campagnes.

Le pattern est cohérent. Un vendor tire des données de providers en amont, applique des transformations, rend un chiffre. Le chiffre est fidèle à l'entrée. L'entrée était déjà fausse, parce qu'elle a été pré-agrégée par la plateforme avec des hypothèses que le vendor ne contrôle pas.

« Exact » dans ce frame veut dire « nous n'avons pas introduit de nouvelles erreurs ». C'est une faible barre. La barre qui compte : est-ce que l'architecture a empêché que les erreurs soient introduites en amont en premier lieu ?

C'est la différence entre l'exactitude comme revendication de feature et la correction comme propriété architecturale.

Les trois engagements architecturaux

L'infrastructure Operations AI exige que trois choses soient vraies. Ce ne sont pas des features. Ce sont des décisions architecturales prises au jour un du produit qui ne peuvent être ajoutées plus tard sans reconstruire.

1. Infrastructure sémantique générative (chiffres corrects by construction)

L'approche naïve pour combiner les données providers : tirer des métriques pré-agrégées de l'API de chaque plateforme, normaliser les plages de dates, rendre dans les dashboards. C'est ce que font 95% des outils d'analytics marketing.

Le problème : les métriques pré-agrégées sont déjà fausses. Meta calcule le ROAS en utilisant son propre modèle d'attribution. Google en utilise un différent. Quand vous moyennez leurs valeurs ROAS pré-agrégées à travers les périodes ou campagnes, vous moyennez des moyennes, avec des hypothèses implicites sur le poids qui ne survivent pas à un examen.

L'infrastructure sémantique générative renverse ça :

• Tirer les événements source, pas les métriques pré-agrégées. Événements de conversion bruts, événements de spend, événements d'impression.
• Les normaliser dans un modèle sémantique partagé. « Campaign » signifie la même chose que la source soit Meta, Google, ou TikTok.
• Calculer les métriques dérivées (CTR, CPM, ROAS, MER, ROAS-par-cohorte, etc.) à partir de la formule à chaque fois. Ne jamais moyenner un chiffre déjà moyenné.
• Rendre les formules explicites et inspectables. La même formule produit le même chiffre, partout où elle est utilisée, avec des entrées traçables.

C'est de l'ingénierie peu glamour. C'est aussi la différence entre des chiffres qui sont corrects by construction et des chiffres qui ont l'air corrects la plupart du temps.

Nous appelons cette couche « générative » parce que les métriques sont générées à la demande à partir des données source, pas stockées et livrées depuis un cache. C'est aussi pourquoi vous pouvez demander à Nylo « ROAS par cohorte d'audience par semaine pour Q1 » et obtenir une réponse défendable, même si personne n'a pré-construit cette coupe.

2. Raisonnement d'agents sur un modèle de domaine, pas sur les API providers

L'approche naïve pour l'IA dans le marketing : câbler un LLM directement aux API providers (API Meta, API Google, etc.) et le laisser raisonner dessus. C'est ce que font la plupart des « assistants marketing IA » aujourd'hui.

Le problème : les agents qui raisonnent sur les providers entremêlent le raisonnement avec la forme de données du provider. Quand Meta change son API (ce qu'il fait, régulièrement), l'agent casse. Quand vous ajoutez Pinterest, vous réentraînez l'agent pour la forme de Pinterest. L'agent est marié aux providers.

Le raisonnement sur modèle de domaine renverse ça :

• Construire un modèle de domaine partagé (campagnes, audiences, KPIs, funnels, produits, clients). Les données des providers alimentent le modèle après normalisation.
• Les agents raisonnent sur le modèle, pas sur les providers. « Pourquoi la campagne X a sous-performe ? » obtient une réponse en raisonnant sur le modèle de campagne unifié, pas en lisant l'API campagne de Meta directement.
• Quand vous étendez à un nouveau provider, le modèle s'étend ; l'agent hérite de l'extension. Quand vous étendez à une nouvelle verticale (pricing, inventaire), la couche d'agents suit.

C'est pourquoi nous utilisons un pattern Domain-Driven Design sous le capot. Il sépare les préoccupations proprement. Les agents voient la réalité métier. Les intégrations providers sont de la plomberie.

La conséquence pratique : quand Meta casse quelque chose le trimestre prochain, les agents ne le remarquent pas. Quand vous voulez étendre du marketing au pricing, la couche d'agents est réutilisable. La plupart des outils IA verticaux reconstruisent depuis zéro dans ce scénario.

3. Execution-ready dès le jour un

L'approche naïve pour les outils IA marketing : livrer l'analyse et la recommandation, laisser l'action aux humains dans un autre outil (Meta Ads Manager, Google Ads, etc.). C'est ce que font la plupart des produits « AI-powered marketing ».

Le problème : ça a l'air responsable. Ça crée en fait un écart structurel. La recommandation vit dans un produit. L'action vit dans un autre. Les humains comblent l'écart, lentement, manuellement, avec friction.

L'architecture execution-ready renverse ça :

• Les intégrations qui font rentrer les données sont les mêmes intégrations qui envoient les décisions. Lire les données Meta et écrire les ajustements de budget Meta partagent l'infrastructure.
• Le système peut prendre des actions (avec validation humaine, ou déclenchement auto sur règles pré-approuvées). Ce n'est pas un outil de workflow séparé câblé des mois plus tard.
• La décision et l'action partagent le même modèle de domaine. Auditable, traçable, réversible.

Le disclaimer honnête : nous déployons l'exécution channel par channel. Aujourd'hui particulièrement fort sur le pacing budgétaire Google Ads. Plus de channels dans les mois à venir. Personne d'honnête ne prétend que tout est closed-loop au jour un. Mais l'architecture le supporte au jour un, ce qui est la différence entre un produit qui aura le closed-loop dans 12 mois et un produit qui devra être reconstruit pour avoir le closed-loop dans 12 mois.

Pourquoi ces trois ensemble comptent

N'importe lequel de ces engagements est intéressant. Les trois ensemble sont la catégorie.

• Correction sémantique sans raisonnement d'agents : vous avez des chiffres propres, pas d'aide pour les interpréter. (Outils BI, légèrement upgradés.)
• Raisonnement d'agents sans correction sémantique : vous avez un assistant IA articulé faisant des déclarations confiantes sur des données fausses. (La plupart des produits « IA pour marketing ».)
• Les deux sans exécution : vous avez une bonne analyse piégée dans un outil de visionnage. Les décisions se passent ailleurs. (La plupart des outils d'analytics.)

L'Operations AI est la convergence. Les trois engagements architecturaux, simultanément, dès le jour un. Cette convergence est ce que nous voulons dire quand nous disons que la correction est une architecture : la propriété émerge de la façon dont le système est construit, pas d'une validation après coup.

C'est aussi l'argument de défendabilité pour les investisseurs. Chaque engagement individuellement est difficile à construire. Les trois ensemble créent un moat parce que ajouter rétroactivement n'importe lequel d'eux dans un système construit sans signifie reconstruire le produit. Les entreprises dont l'architecture a commencé avec « IA sur données pré-agrégées » ne peuvent pas ajouter l'infrastructure sémantique en dessous sans casser leur produit existant.

Comment évaluer les vendors qui revendiquent Operations AI (nous inclus)

Si vous shoppez pour de l'infrastructure Operations AI, voici la checklist de diligence en trois questions :

1. « Montrez-moi comment vous calculez le ROAS pour une campagne spécifique sur le dernier trimestre. » Un vendor avec infrastructure sémantique générative peut vous montrer les événements source, la normalisation, et la formule. Un vendor sans ça vous montre le dashboard.
2. « Comment votre agent sait-il ce que 'sous-performant' veut dire ? » Un vendor avec raisonnement sur modèle de domaine peut vous montrer le modèle métier que l'agent référence. Un vendor sans ça vous montre un prompt.
3. « Le système peut-il prendre une action dans Google Ads là maintenant ? » Un vendor avec architecture execution-ready peut faire la démo d'un ajustement de budget avec validation, de bout en bout. Un vendor sans ça vous dit que c'est sur la roadmap.

Trois questions, quinze minutes, vous saurez si l'architecture est réelle.

Nous passons les trois. D'autres vendors le feront aussi dans les 12-24 prochains mois à mesure que la catégorie mûrit. Les questions de diligence restent pertinentes.

Ce que nous ne revendiquons pas

La clarté compte ici.

• Nous ne revendiquons pas que chaque channel est closed-loop aujourd'hui. Le pacing budgétaire Google Ads l'est. D'autres channels se déploient.
• Nous ne revendiquons pas que la correction sémantique résout la philosophie d'attribution. ROAS réconcilié contre vérité de marge est toujours un modèle. Le modèle est transparent et inspectable. C'est la revendication honnête la plus forte.
• Nous ne revendiquons pas que les agents sont plus intelligents que votre meilleur PM. Ils sont plus cohérents que votre PM moyen et plus disponibles que n'importe lequel d'eux. C'est la valeur.

Si un vendor revendique plus que cela honnêtement, posez les trois questions de diligence.

Questions fréquentes

Est-ce juste un data warehouse plus fancy ? Non. Un data warehouse est du stockage et de la requête. L'infrastructure Operations AI inclut la correction sémantique, le raisonnement d'agents, et l'exécution. Le warehouse est un élément (principalement caché) du stack.

L'architecture importe-t-elle à mon CMO ? Indirectement. Le CMO se soucie de savoir si le chiffre ROAS qu'on lui montre est défendable en board meeting. L'architecture est ce qui le rend défendable. Le CTO ou buyer technique s'en soucie directement.

Pourquoi publier ça ? Ça n'aide pas les concurrents ? Possiblement. Les engagements architecturaux sont difficiles à ajouter rétroactivement, donc l'avance compte plus que le secret. Et si les concurrents construisent au même standard, le marché pour l'Operations AI grandit, ce qui nous aide.

Est-ce brevetable ? Probablement certaines parties. Nous ne menons pas avec le patent-pending comme défendabilité. Les brevets sont une case à cocher. La correction architecturale est le moat.

Quelle est l'architecture de référence la plus proche pour comparer ? L'approche de Stripe pour l'infrastructure de paiements est la plus proche en esprit. Ils ont construit la correction dans le modèle de données au niveau du substrat, puis tout le reste (API, dashboard, agent) en hérite. Notre approche est le même pattern appliqué aux décisions marketing.

Voyez l'architecture en action

Si vous évaluez l'infrastructure Operations AI et voulez faire de la vraie diligence sur l'architecture, un appel de 30 minutes avec Rick (notre CTO) est le chemin le plus rapide. Il fera la démo des trois engagements en direct.

Réserver 30 minutes

Plus sur le frame catégorie : Qu'est-ce que l'Operations AI ? | Operations AI vs Dashboards

---

L'Operations AI est la catégorie que nous construisons chez Nylo. Marketing aujourd'hui, operations dans chaque domaine data-driven de l'entreprise demain. Si vous êtes un buyer technique ou un investisseur et voulez pousser sur n'importe laquelle de ces revendications architecturales, nous voulons entendre ce que vous pensez.