L'achat média agentique ne peut pas passer à l'échelle sans des fondations solides. Découvrez comment les acheteurs et les vendeurs y parviennent sur Databricks.

Le goulot d'étranglement de l'achat média aujourd'hui n'est pas le talent, c'est la coordination

Chaque jour, des milliards de dollars de publicité changent de mains via un processus qui n'a pratiquement pas changé depuis des décennies : e-mails, feuilles de calcul, PDF et appels téléphoniques. Un acheteur définit une campagne, puis des équipes qualifiées contactent les éditeurs, envoient des RFP, attendent les tarifs, comparent les kits média et négocient les prix avant de finalement finaliser un ordre d'insertion. Des personnes talentueuses passent la majeure partie de leur temps à coordonner la transaction au lieu de gérer le travail stratégique et créatif.

La friction provient de la fragmentation. Il n'existe pas de méthode standardisée pour découvrir l'inventaire, évaluer les audiences ou établir des relations de confiance entre les partenaires, de sorte que chaque connexion entre acheteur et vendeur devient une intégration sur mesure. Comme cette coordination prend des jours, les décisions sont souvent prises sur la base d'informations datant déjà de plusieurs heures ou jours. Les signaux d'inventaire, de tarification et d'audience évoluent en continu, et le temps qu'une campagne soit approuvée, la meilleure opportunité est parfois déjà passée.

L'essor des workflows agentiques offre à ces équipes l'opportunité d'éliminer la coordination manuelle et répétitive de l'équation afin de consacrer leur temps là où le jugement compte le plus : un ciblage plus précis, de meilleures créations et des campagnes non seulement plus rapides à lancer, mais aussi plus efficaces.

Pourquoi ce problème est enfin résoluble et pourquoi les standards sont importants

La dernière vague d'IA a créé des logiciels qui répondent. La prochaine vague crée des logiciels qui agissent — des agents qui poursuivent un objectif, prennent des décisions, appellent des outils et effectuent des transactions en votre nom. C'est précisément dans ce travail de coordination que l'achat média manuel se noie : lire un brief, rechercher des éditeurs, comparer les tarifs, négocier les prix, finaliser la commande. Pour la première fois, des systèmes multi-agents utilisant des LLM et des protocoles comme MCP peuvent exécuter cette boucle automatiquement.

Mais l'automatisation seule ne suffit pas. Les standards AAMP (Agentic Advertising Management Protocols) de l'IAB Tech Lab établissent un modèle de communication cohérent : un vocabulaire partagé pour l'inventaire et les audiences (AdCOM, les taxonomies), un protocole de transaction commun (deals OpenDirect, OpenRTB) et un modèle de registre pour la découverte et la confiance. Vous pourriez résoudre ce problème avec l'IA sans standards entre deux parties. Cependant, ce sont les standards qui permettent à l'ensemble du secteur d'évoluer ensemble, de sorte que n'importe quel agent acheteur conforme puisse effectuer des transactions avec n'importe quel agent vendeur conforme, de la même manière que n'importe quel navigateur peut charger n'importe quel site web.

Les standards ouverts définissent ce que les agents se disent entre eux. La question suivante est de savoir où ces agents s'exécutent réellement : leur état, leurs modèles, leur identité, leur gouvernance. C'est là que Databricks intervient.

Nous avons conçu un exemple d'achat et de vente média agentique entièrement sur Databricks. Des acheteurs et vendeurs autonomes se découvrent mutuellement, s'accordent sur un prix et concluent des transactions. Il est basé sur le SDK (Software Development Kit) open source officiel de l'IAB Tech Lab, ce qui évite tout verrouillage au niveau de la couche de protocole, et il est désormais disponible sous forme d'accélérateur que vous pouvez déployer avec une seule commande. Les instructions se trouvent à la fin du blog.

De quoi se compose un achat média agentique

Un achat média agentique est une transaction simple impliquant trois acteurs :

• Un acheteur : un annonceur (ou son agence) avec une campagne : un budget, les audiences à atteindre et un prix à ne pas dépasser.
• Des vendeurs : des éditeurs disposant d'un inventaire publicitaire, chacun avec un catalogue (un kit média de packages et de produits) et sa propre tarification.
• Un registre : un annuaire qui permet aux acheteurs de trouver des vendeurs et d'établir une relation de confiance en identifiant l'acheteur, ainsi que l'accès et les tarifs dont il bénéficie.

L'achat lui-même est une boucle courte : découvrir quels vendeurs disposent du bon inventaire, en fixer le prix et réserver la transaction (ou y renoncer). Aujourd'hui, cette boucle est en grande partie manuelle ; le changement que nous démontrons consiste à l'exécuter avec des agents d'IA des deux côtés.

Les agents de différentes entreprises ont besoin d'un langage partagé pour effectuer des transactions, et c'est là que les standards ouverts de l'IAB Tech Lab peuvent apporter de la valeur. Nous ne détaillerons pas leur SDK ici, mais nous nous concentrerons plutôt sur ce qu'il faut pour exécuter des agents acheteurs et vendeurs sur Databricks.

Un écosystème complet pour les agents acheteurs et vendeurs

Les agents complexes vont bien au-delà de simples requêtes adressées à un grand modèle de langage (LLM). Pour que ces agents puissent exécuter une transaction média, ce qui peut impliquer diverses tâches telles que la planification d'une audience, la répartition d'un budget, la découverte d'éditeurs, le respect d'un prix plafond et la réservation de la transaction, vous avez besoin d'un système qui gère :

• État : les briefs, les identités, les catalogues, les devis et les commandes qui doivent persister et être transactionnellement corrects.
• Modèles servis : les modèles de fondation gouvernés que les agents peuvent appeler, avec le modèle adapté à chaque tâche.
• Données gouvernées : les données de catalogue et d'audience sur lesquelles les agents raisonnent, avec des contrôles d'accès.
• Identité et confiance : qui est cet agent, et qu'est-il autorisé à voir et à faire ?
• Observabilité : une trace de chaque décision et appel d'outil, pour le débogage et l'audit.

Ce système peut être assemblé à partir d'un fournisseur de base de données, d'un hébergeur de modèles, d'un outil de gouvernance, d'une plateforme d'applications et d'un service de traçage. Sur Databricks, il s'agit d'une seule et même plateforme.

À quoi ressemble la bonne architecture ?

Commençons par un fait concernant ce marché : les acheteurs, les vendeurs et le registre sont des entités distinctes. Cela divise le problème en deux : comment les parties communiquent entre elles, et où chaque partie exécute réellement sa part de la transaction. Les protocoles ouverts répondent à la première question. Ils constituent le fil conducteur entre les parties, assurant la découverte, la négociation et le règlement, et s'arrêtent là. L'endroit où un agent s'exécute, conserve son état, prouve son identité et reste gouverné relève du rôle de la plateforme. Ainsi, chaque partie dispose d'une application autonome, construite sur Databricks Apps, qui possède son état, son identité et les modèles qu'elle exécute, et ne rencontre les autres que via les protocoles. Les sections qui suivent examinent ces éléments un par un et montrent pourquoi chacun d'eux y a sa place.

Databricks Model Serving : l'équipe d'agents

Sous le capot, l'agent acheteur est une « équipe » (crew), ou un groupe, d'agents spécialisés construits à l'aide de CrewAI. L'équipe travaille de manière hiérarchique sur trois niveaux, l'agent de niveau 1 pouvant déléguer des tâches aux agents de niveau 2, et ainsi de suite. Ces agents comprennent un gestionnaire de portefeuille de niveau 1 qui définit la stratégie et répartit le budget, des spécialistes de canaux de niveau 2 spécialisés dans l'achat d'un support spécifique, et des agents tactiques de niveau 3 qui planifient les audiences et exécutent l'achat. Ils s'exécutent sur les API Databricks Foundation Model et sont configurés pour utiliser les modèles Claude en fonction de la complexité de la tâche. L'utilisation de Databricks Unity AI Gateway pour exécuter ces agents permet de changer facilement le LLM qui alimente chaque agent sans rien modifier d'autre.

Lakebase : un état transactionnel pour les agents

Les agents ont besoin de deux choses de la part de leurs données : du contexte pour agir, et d'un endroit pour enregistrer ce qu'ils font. Notre acheteur lit ses briefs, chaque vendeur lit son catalogue d'inventaire et ses règles de tarification, et ils réenregistrent chaque commande réservée. C'est de l'OLTP classique, nous l'avons donc placé sur Lakebase, le Postgres serverless de Databricks, qui s'exécute juste à côté du lakehouse. Les agents lisent et écrivent l'état rapidement avec des garanties transactionnelles, et comme il s'agit de Postgres, les composants du vendeur s'y intègrent directement sans couche de données sur mesure. Et comme Lakebase est serverless, il s'adapte automatiquement à l'échelle en quelques millisecondes pour répondre aux pics de demande. Les agents n'arrivent pas à un rythme régulier, et les acheteurs peuvent se déployer vers de nombreux vendeurs à la fois sans provisionner de capacité au préalable.

Gouvernance : Lakebase aujourd'hui, Unity Catalog ensuite

Pour l'instant, cette démo utilise uniquement Lakebase. Dans le monde réel, Lakebase se situe entre deux frontières gouvernées de Unity Catalog. En entrée, les données sont hydratées depuis les tables Unity Catalog vers Lakebase — l'inventaire d'un vendeur et sa tarification basée sur des modèles de ML, les briefs de campagne d'un acheteur et les définitions d'audience. En sortie, l'état transactionnel produit par les agents — qui a acheté quoi, et à quel prix — est synchronisé avec votre environnement de reporting. Les deux directions s'exécutent sur des pipelines managés Databricks plutôt que sur des ETL fragiles écrits à la main. Cela en fait un aller-retour gouverné : Unity Catalog suit automatiquement la lignée de chaque hydratation et synchronisation, de sorte que vous pouvez toujours tracer quelles données ont été déplacées et où. Le lakehouse reste la source de vérité aux deux extrémités, et Lakebase est la couche opérationnelle d'accès rapide où les agents effectuent leurs transactions.

Identité et confiance

Les applications s'authentifient entre elles à l'aide d'OAuth — le mécanisme qui établit et vérifie l'identité revendiquée par chacune d'elles — et un registre attribue à chaque acheteur un niveau de confiance. Ce niveau détermine ce qu'un acheteur peut voir : un acheteur public inconnu n'obtient que des fourchettes de prix et ne peut pas effectuer de transaction ; un acheteur de confiance vérifié obtient les prix exacts et peut réserver. Modifiez le niveau de confiance de l'acheteur, et la même campagne qui était limitée aux fourchettes de prix peut désormais être réservée. Sur Databricks, cette gestion de l'identité est intégrée de manière native au fonctionnement actuel des applications et de l'accès aux données. Là où le SDK de référence de l'IAB requiert des clés API, nous utilisons simplement les principaux de service intégrés de la plateforme et OAuth pour nous authentifier selon les meilleures pratiques actuelles, sans rien de plus à développer.

Observabilité

Les équipes d'agents sont configurées pour le traçage MLflow, ce qui est facile à implémenter via un hook d'enregistrement automatique (autolog) CrewAI d'une seule ligne. Cela nous permet de capturer les étapes de raisonnement, les appels d'outils, les prix lus et la décision de réserver ou de passer de chaque exécution d'agent. Nous l'avons gardé optionnel pour la démo, mais c'est exactement ainsi que vous voudriez mettre en production, déboguer, ajuster et faire confiance à un système autonome en matière de contrôle budgétaire.

Découvrez l'application d'achat agentique en action

Suivons une exécution complète sur une campagne. Nous commençons par soumettre le brief de l'annonceur, qui dans ce scénario est un lancement de marque pour le troisième trimestre (Q3), avec un budget de 200 000 $ réparti sur les types de médias CTV et TV linéaire, et un plafond de CPM (coût pour mille) de 38 $. Ce brief est envoyé à l'application de l'acheteur, et l'équipe d'agents lance le processus d'achat.

1. Planifier le budget : Le Portfolio Manager lit le brief et répartit les dépenses entre les canaux, en allouant 120 000 $ à la CTV et 80 000 $ au linéaire.

2. Traduire l'audience : Un spécialiste associe les audiences en langage naturel du brief à des segments standards, validés par rapport à la taxonomie d'audience de l'IAB Tech Lab : \"fans de sport\" correspond à \"Sports Enthusiasts\" et \"acheteurs potentiels de voitures\" correspond à \"Auto Intenders\".

3. Découvrir les vendeurs : L'acheteur découvre les éditeurs dans le registre : le vendeur A (CTV) et le vendeur B (linéaire), ce qui confirme l'identité de l'acheteur et valide son niveau d'accès.

4. Évaluer le prix : Un Channel Specialist pour chaque canal consulte son vendeur via MCP, associe le segment d'audience à un produit disponible et lit le prix officiel.

5. Réserver ou passer : Une seule règle : réserver si le prix est égal ou inférieur au plafond de 38 $ et que l'audience du produit correspond ; sinon, passer son chemin.

Et ensuite ?

Ce que nous avons montré ici est le cœur de la transaction : les agents qui négocient. Mais cette même plateforme est également le meilleur endroit pour concevoir l'amont et l'aval : la création du brief de l'acheteur, les modèles de ML qui définissent la tarification des packages d'un vendeur, ainsi que les modèles et tableaux de bord utilisés pour estimer les revenus et les dépenses. Ce sont des problèmes dont les solutions dépendent de données gouvernées et du ML, qui résident tous deux nativement sur Databricks. Notre équipe s'engage à mettre à jour le dépôt, en veillant à ce qu'il évolue aux côtés de l'IAB Tech Lab à mesure que de nouvelles fonctionnalités AAMP sont publiées.

Déployez-le vous-même

Ce système est fourni sous forme d'accélérateur Databricks Automation Bundle. Clonez le dépôt, pointez la CLI Databricks vers votre espace de travail, puis exécutez une seule commande :

Utilisez cette commande pour créer et déployer les applications et les instances Lakebase, charger les données initiales et connecter l'acheteur aux vendeurs via le registre. Quelques minutes plus tard, vous disposez de deux agents vendeurs actifs, d'un registre et d'une console acheteur, le tout effectuant des transactions dans votre propre espace de travail.

À partir de là, personnalisez-le. Intégrez votre propre inventaire, vos règles de tarification et vos audiences, ou connectez la couche Lakebase à votre catalogue et à vos modèles réels. Prenez part à la transaction en tant qu'acheteur ou vendeur et observez la réaction des agents : modifiez un prix, changez le niveau de confiance d'un acheteur, ajoutez un vendeur et observez le déroulement de la négociation. Il s'agit d'un modèle fonctionnel conçu pour l'achat et la vente de médias par des agents autonomes.

Regardez la démo de 5 minutes, puis déployez l'accélérateur dans votre propre espace de travail.

(Cet article de blog a été traduit à l'aide d'outils basés sur l'intelligence artificielle) Article original