Cody Schneider, cofondateur de l'agence de marketing Graph, ouvre un cours en direct enregistré par une affirmation : depuis quatre mois, il gère ses publicités Facebook « almost entirely through Claude Code » (en anglais dans l'original), c'est-à-dire presque entièrement avec Claude Code, grâce à un agent qui recherche des publicités, les fabrique, les publie, coupe les perdantes et promeut les gagnantes.[1] Voilà un agent qui mène une activité de l'entreprise plutôt que d'écrire du code, ce qui rend sa conception digne d'étude pour une entreprise qui ne vend pas de logiciels. Dans son montage, ce qui tient l'ensemble est une décision de plomberie : l'agent modifie le compte publicitaire par une porte et étudie les résultats par une autre.
Ce que l'agent fait vraiment.
Sans les noms d'outils, le travail se divise en cinq parties : trouver ce dont se plaint le client cible, en tirer des publicités, les publier, couper celles qui ne convertissent pas et mettre plus d'argent derrière celles qui convertissent. Schneider le construit d'abord sur son propre ordinateur avec un agent de programmation, puis le déploie sur un serveur où il tourne « on some type of cadence, whether it's hourly, whether it's daily » (en anglais dans l'original), c'est-à-dire selon une certaine cadence, à l'heure ou au jour.[1] Sa propre définition du résultat est simple : un agent est « software with a thinking loop with some type of live data stream » (en anglais dans l'original), soit un logiciel doté d'une boucle de réflexion et d'un flux de données en direct.[1]
Deux choses rendent la tâche plus difficile qu'un travail de programmation. L'agent touche à de l'argent chaque fois qu'il agit, et il passe par une plateforme qui a ses propres règles d'utilisation. Les deux influencent la conception.
Les écritures passent par l'API. Les lectures viennent d'un entrepôt.
L'agent reçoit une clé de la Marketing API de Meta, émise par une application de développeur privée et un utilisateur système dans Business Manager, et non par une application publique soumise à examen.[1] Schneider confie à cette clé exactement deux tâches : téléverser de nouveaux visuels publicitaires et gérer le compte (couper une publicité perdante, promouvoir une gagnante, déplacer des publicités d'un ensemble à l'autre). Vient ensuite l'avertissement sur lequel repose toute la construction : l'API n'est pas faite pour « doing the data analysis » (en anglais dans l'original), c'est-à-dire pour l'analyse de données.[1] Il donne deux raisons. Les deux se tiennent sans qu'on ait à croire son argumentaire de vente, mais la documentation de Meta n'appuie qu'une partie de la première.
- Meta limite le débit de la Marketing API par compte publicitaire.
Une passe d'analyse demande beaucoup de lectures. La documentation de Meta pondère les appels de la Marketing API par compte publicitaire : « a read API call is equal to 1 point, and a write API call is equal to 3 points » (en anglais dans l'original), c'est-à-dire qu'un appel de lecture vaut 1 point et un appel d'écriture, 3 points. Au-delà du plafond, les requêtes échouent avec une erreur de limitation et sont bloquées pendant une période déterminée.[2] Lectures et écritures puisent dans ce même pointage : un agent qui le dépense à produire des rapports peut se retrouver limité au moment précis où il doit mettre une publicité perdante en pause. Schneider va plus loin et prévient que marteler l'API peut faire bannir le compte publicitaire, « not because they're like against a coding agent interacting with it » (en anglais dans l'original), c'est-à-dire non pas parce qu'on s'oppose à ce qu'un agent de programmation interagisse avec elle, mais parce que le profil des appels contrevient aux conditions de l'API.[1] La page de Meta s'arrête avant cela : elle documente la limitation et indique que, lorsque des comptes publicitaires « generate a large amount of abnormal traffic » (en anglais dans l'original ; génèrent beaucoup de trafic anormal), elle va « temporarily reduce the API Rate Limit quota » (en anglais dans l'original ; réduire temporairement le quota de la limite de débit de l'API) de ces comptes.[2] Elle ne mentionne pas les bannissements ; considérez donc le risque de bannissement comme l'expérience de Schneider, et non comme une règle énoncée par Meta.
- Des lignes brutes ne sont pas une réponse.
Si l'on tire l'historique d'un compte par l'API, l'agent se retrouve, selon ses mots, à chercher « what do I do with a 100 million rows of data » (en anglais dans l'original), c'est-à-dire que faire de 100 millions de lignes de données.[1] Il énumère ce qui tourne mal quand un agent analyse directement des extractions d'API : des chiffres inventés, des résultats tronqués et des erreurs de pagination où des pages de résultats disparaissent.[1] Un entrepôt de données transforme les mêmes données en quelque chose à quoi l'agent peut poser une question.
La lecture passe donc par un pipeline (une chaîne de traitement qui achemine les données). Les résultats publicitaires, les analyses du site et les données du CRM ou de la boutique alimentent un seul entrepôt, et l'agent a un accès en requête à l'entrepôt, pas aux plateformes.[1] Le pipeline devient la seule chose qui lit l'API de la plateforme en grand volume, ce qui permet de le cadencer selon la limite de débit une seule fois, à un seul endroit. Les conseils de Meta vont dans le même sens : pour les gros extraits de rapports, elle recommande les requêtes asynchrones et groupées plutôt que de nombreux petits appels.[2]
La règle vaut au-delà des publicités. Tout agent qui travaille pour vous sur une API tierce à débit limité (un CMS, un système de réservation, une console de recherche) a intérêt à avoir une voie d'écriture étroite et une voie de lecture distincte qu'il peut interroger autant qu'il veut. Il y a aussi un avantage secondaire : la voie d'écriture est assez courte pour être énumérée, et une liste, on peut la journaliser et la réviser.
Pourquoi pas la base de données que vous avez déjà ?
À la période de questions, on lui demande si une base de données Supabase (Postgres en dessous) ferait l'affaire. Schneider admet qu'on pourrait y acheminer les données, mais il le déconseille : une requête sur 100 millions de lignes y « could take like literally minutes » (en anglais dans l'original ; pourrait littéralement prendre des minutes) et des millisecondes dans ClickHouse, l'entrepôt analytique qu'il nomme, parce que les deux sont « structurally like fundamentally different » (en anglais dans l'original ; fondamentalement différents dans leur structure).[1] Il ne montre aucun banc d'essai ; prenez donc ces chiffres comme l'impression d'un praticien. La direction est cependant classique. Une base de données courante stocke les données ligne par ligne, ce qui convient pour lire ou modifier un enregistrement à la fois. Un entrepôt analytique les stocke colonne par colonne, ce qui convient pour additionner un champ sur des millions d'enregistrements. « Quelles publicités ont fonctionné le mois dernier » est une question du second type.
Il énumère aussi les corvées qu'un pipeline maison doit gérer : respecter la limite de débit, supprimer les doublons quand la plateforme renvoie des morceaux qui se chevauchent, et tenir un modèle de données qui compte, selon son décompte, 42 tables pour les seules publicités Facebook.[1] Pour un petit compte, la vraie question est de savoir si vous avez déjà besoin de tout cela. La section ci-dessous sur construire ou acheter y revient.
Un aparté daté. Quand on lui demande si un serveur MCP pour Facebook Ads pourrait remplacer l'API directe, il rapporte qu'il n'exposait qu'une poignée de points de terminaison et qu'il pourrait « functionally break » (en anglais dans l'original ; casser sur le plan fonctionnel) à son volume d'appels, puis il ajoute « don't quote me on this » (en anglais dans l'original ; ne me citez pas là-dessus) : son dernier examen remontait à environ quatre semaines avant le cours.[1] C'est l'expérience d'une équipe à un moment précis ; vérifiez la liste actuelle des points de terminaison avant de choisir l'une ou l'autre.
Tester, promouvoir, retirer, remixer : une boucle avec des murs.
Le compte tourne en deux campagnes.[1] Une campagne de test contient plusieurs ensembles de publicités, chacun avec environ cinq publicités en concurrence pour le budget de cet ensemble. Schneider note que le système de diffusion de Meta fait maintenant l'essentiel du choix des gagnantes lui-même, en dirigeant le budget vers la publicité dont il s'attend à ce qu'elle convertisse. Une gagnante passe dans une campagne de gagnantes, où elle rivalise avec d'autres publicités éprouvées et où l'on surveille la fatigue publicitaire : le moment où le public l'a vue si souvent que les résultats chutent. Les perdantes sont mises en pause. Les gagnantes sont remixées (même idée, nouvelle exécution) et renvoyées en test. La vitesse d'un cycle dépend du budget par rapport au coût par résultat ; selon lui, de deux jours à une semaine.
Une boucle comme celle-là est le genre de processus opérationnel que les propriétaires veulent déléguer, et le genre qui déraille en silence, parce que chaque étape paraît raisonnable prise seule. La source décrit la boucle. Elle en dit beaucoup moins sur les murs autour. Voici les quatre garde-fous que nous mettrions en place avant de la laisser tourner sans surveillance ; ils relèvent de notre conception, pas de la sienne.
- Un plafond de dépenses que l'agent ne peut pas relever.
L'agent déplace le budget entre les publicités à l'intérieur d'un total fixé par une personne. Appliquez ce total dans le code de l'agent, pas seulement dans ses instructions, et fixez une limite de dépenses sur le compte publicitaire lui-même comme filet de sécurité.
→ l'agent dépense à l'intérieur du budget ; il ne le fixe jamais - Une courte liste d'écritures permises, journalisées.
Téléverser, mettre en pause, déplacer, réaffecter le budget sous le plafond. Tout le reste (une nouvelle campagne, un changement de public, la facturation) va à une personne sous forme de demande. Chaque écriture est consignée dans un journal avec la raison que l'agent a donnée.
- Une personne décide de ce qui compte comme une victoire.
L'agent optimise ce que le compte déclare comme conversion ; ce choix reste donc humain. Schneider conseille de commencer par un événement haut dans l'entonnoir, comme une inscription, parce que la plateforme a besoin de volume pour apprendre, puis de descendre plus profondément (une action clé dans le produit, ensuite le paiement) à mesure que le volume le permet, et de ne pas suivre plus d'environ cinq événements.[1]
- Une règle qui arrête toute la boucle.
Décidez d'avance ce qui met tout en pause : des dépenses en avance sur le plan, une série de publicités refusées, un pipeline brisé qui alimente l'agent en chiffres périmés. Notre exemple illustratif de la boucle emballée montre comment une boucle qui n'en a pas peut faire grimper une facture.
L'agent qui refait toujours la même publicité.
Le moment le plus utile du cours est un problème sur lequel, dit Schneider, son équipe travaille encore.[1] Laissé seul à faire tourner la boucle, l'agent « makes a lot of the same stuff unless you introduce like new DNA into the system » (en anglais dans l'original), c'est-à-dire fabrique beaucoup de la même chose à moins qu'on introduise du nouvel ADN dans le système.[1] On voit facilement comment. À chaque tour, il remixe ce qui a gagné au tour précédent, et les prochaines gagnantes sortent de ce bassin plus étroit. Laissez-le tourner assez longtemps sans que rien de neuf y entre, et le compte se remplit de variations sur quelques idées. Rien n'est brisé ; la boucle a fait ce pour quoi elle était récompensée.
Sa solution vient de l'extérieur de la boucle plutôt que de l'invite ou du modèle : les publicités des concurrents tirées des bibliothèques de publicités publiques de Facebook et de Google, et des vidéos courtes en tendance récupérées par un service tiers, injectées comme matière première du prochain lot.[1] Il se sert aussi des bibliothèques de publicités des concurrents pour le démarrage à froid : le premier lot pour une marque qui n'a encore aucune gagnante. En amont des deux, ses textes publicitaires partent de mots que les clients utilisent déjà : plaintes et souhaits recueillis sur des forums comme Reddit, plutôt que des avantages qu'un spécialiste du marketing a devinés.[1]
Le même phénomène se produit hors de la publicité. Tout agent qui s'améliore en réutilisant ses meilleurs résultats (objets de courriel, descriptions de produits, scripts de prospection) aura tendance à dériver vers l'uniformité, et le symptôme ressemble à de la stabilité, pas à un échec. Mettez une source de contenu nouveau à l'horaire, et vérifiez la variété des résultats, pas seulement leur performance.
Le faire vous-même, l'acheter ou le faire construire.
Quand on lui demande si un participant pourrait tout construire seul, entrepôt de données compris, Schneider répond que c'est « totally possible » (en anglais dans l'original ; tout à fait possible) : environ deux semaines pour obtenir quelque chose d'utilisable mais « monkey patched » (en anglais dans l'original ; rafistolé à coups de correctifs rapides), de quatre à six semaines pour quelque chose qu'il jugerait prêt pour l'entreprise, les jetons d'IA dépensés pour le construire représentant une grande part du coût.[1] Il dit aussi aux petits annonceurs qu'ils n'ont peut-être pas encore besoin de l'agent complet. Une personne qui fait tourner un agent de programmation sur son propre ordinateur, avec une clé d'API, économise déjà les heures de téléversement et de gestion manuelle des publicités, et le déploiement infonuagique peut attendre que le système fonctionne.[1] C'est un conseil contraire à son propre argumentaire, ce qui mérite qu'on le soupèse.
Si le compte est petit, son propre conseil est le départ économique : un agent de programmation sur votre machine, une clé limitée aux deux tâches d'écriture, et une personne qui révise chaque jour ce qu'il a fait. Ajoutez l'entrepôt quand les questions que vous posez dépassent ce que les rapports de la plateforme elle-même peuvent répondre, et le déploiement infonuagique quand la boucle tourne depuis assez longtemps pour que vous fassiez confiance à ses murs. Notre note sur l'ordre dans lequel l'autonomie se mérite parcourt la même échelle pour les agents en général.
Ce que cette note ne prétend pas.
Source d'un fournisseur, aucun résultat repris. Le cours vend le service qu'il décrit. Nous avons omis tous les chiffres de coût par résultat qu'il contient, parce qu'aucun n'est accompagné d'une base de comparaison ou d'une méthode.
Les règles de Meta, vérifiées là où nous le pouvions. La limite de débit par compte, la pondération des lectures et des écritures, la limitation, la réduction temporaire du quota en cas de trafic anormal et le conseil de grouper les gros extraits de rapports figurent dans la documentation de Meta. Le risque de bannissement d'un compte pour un trafic d'analyse est une affirmation du présentateur ; la page de Meta sur les limites de débit ne l'énonce pas.
Les vitesses de l'entrepôt sont une impression. « Des minutes contre des millisecondes » ne s'accompagne d'aucun banc d'essai. La différence entre stockage par lignes et stockage par colonnes qui la sous-tend est une connaissance générale ; les chiffres sont les siens.
Aucun dossier client. Nous n'avons pas exploité ce système pour un client. Les quatre murs sont la façon dont nous le concevrions, et la colonne « le faire construire » du tableau décrit la façon dont nous établissons nos soumissions, pas un délai de livraison mesuré.
Vous gérez des publicités et vous vous demandez si un agent pourrait prendre en charge les téléversements et le tri hebdomadaire ? Décrivez le compte par le formulaire de contact et vous recevrez gratuitement une première lecture écrite : ce que nous automatiserions d'abord et ce que nous laisserions à une personne. Les constructions d'agents comme celle-ci font partie de notre travail en assistants et agents.