Le marketing agentique en 2026 : les quatre éléments qu'un système doit exposer

Réponse courte : le marketing agentique est un travail marketing réalisé par un logiciel qui choisit lui-même sa prochaine étape puis l'exécute. C'est à peu près là que l'accord s'arrête. Nous avons récupéré les onze pages remontées pour ce terme et ses variantes le 18 août 2026, et huit d'entre elles ne mentionnent jamais le protocole, l'appel d'outils ou l'appel de fonctions — c'est-à-dire la couche où un agent cesse d'être une fenêtre de chat et devient quelque chose capable de modifier votre communauté, votre campagne ou vos fiches clients. Cet article définit donc le marketing agentique par les quatre éléments qu'un système doit exposer avant qu'un agent puisse réaliser le moindre travail marketing, cite le Model Context Protocol sur les raisons pour lesquelles les étiquettes que ces systèmes publient sur eux-mêmes ne sont pas dignes de confiance, et évalue la surface agentique de Zealy au regard de cette définition, y compris la partie où nous échouons.

Divulgation : Zealy publie cette page et Zealy vend le produit dont elle parle. Zealy est une plateforme de communauté et de quêtes. Deux de ses fonctionnalités sont des agents au sens défini dans cet article : un serveur MCP qu'une IA externe peut piloter, et un évaluateur IA intégré au produit. Les trois apparaissent ci-dessous. Tout ce qui concerne la surface agentique de Zealy est de première main : lu dans le dépôt de Zealy, exécuté contre le propre serveur de Zealy par nos soins, audité par personne d'autre. Lisez-le avec le scepticisme que vous appliqueriez à tout fournisseur décrivant son propre produit.

Dernière vérification : 18 août 2026.

Qu'est-ce que le marketing agentique ?

Le marketing agentique est un travail marketing effectué par un logiciel qui choisit sa propre prochaine action vers un objectif au lieu de suivre un flux de travail dessiné par une personne. Un système n'est qualifié que lorsqu'il expose quatre éléments : des outils nommés plutôt qu'une zone de chat, un moyen de les découvrir avant d'agir, une frontière d'approbation délibérée et une frontière de confiance sur ce qui revient.

Cette définition est la nôtre, et elle est délibérément construite à partir du mécanisme plutôt que de l'ambition. Chaque définition publiée que nous avons lue décrit ce que le logiciel cherche à faire. Aucune ne décrit ce qui doit être vrai de votre stack avant qu'il puisse le faire. Voici les quatre parties, dans l'ordre où un système doit les satisfaire.

1. Des outils nommés, pas une zone de texte. Un agent a besoin d'opérations avec des noms, des arguments et des formes de retour, des choses comme create_campaign, list_members et send_message, car un modèle qui ne peut produire que de la prose ne peut produire que de la prose. Le Model Context Protocol est la manière courante actuelle de publier une telle liste, et ses outils sont ce qu'il appelle contrôlés par le modèle : le modèle de langage les découvre et les invoque lui-même, en fonction du contexte et du prompt de l'utilisateur. Sans cette couche, vous avez un assistant de rédaction. C'est un produit utile ; ce n'est pas celui-ci.
2. La découverte avant l'action. L'agent doit pouvoir demander ce qui existe et ce que fait chaque chose, avant de s'engager sur quoi que ce soit. Une intégration codée en dur où un humain a déjà choisi les trois appels est de l'automatisation avec un modèle attaché à la copie.
3. Une frontière d'approbation choisie à dessein. Chaque action s'arrête pour une personne ou non, et quelque part une règle décide laquelle. La règle peut être stricte ou souple. Ce qu'elle ne peut pas être, c'est non examinée.
4. Une frontière de confiance sur ce qui revient. Les résultats d'outils sont des données écrites par d'autres : membres, clients, formulaires, pages aspirées. Si une chaîne renvoyée peut convaincre l'agent de passer à son prochain appel d'outil, vous avez construit un système qui prend ses instructions de quiconque remplit votre champ de soumission de quête.

Deux conséquences en découlent, et c'est la raison pour laquelle nous avons pris la peine d'écrire une définition. Tout ce qui manque la première partie est un chatbot avec un meilleur marketing. Et tout ce qui manque la troisième partie n'a pas pris de décision sur l'autonomie — elle lui est arrivée. Une frontière d'approbation que vous n'avez pas choisie n'est pas une position de conception, c'est un accident qui ne vous a encore rien coûté.

Les définitions existantes, et où chacune trace la ligne de l'autonomie

Les définitions publiées s'accordent sur le fait qu'un agent planifie et agit de lui-même, et divergent sur la part d'implication humaine qui peut subsister. Vlerick Business School autorise une intervention minimale. Braze décrit des systèmes qui perçoivent, décident et agissent. Young Urban Project et Netcore placent tous deux la ligne à l'approbation humaine à chaque étape. Forrester sépare entièrement les agents de l'IA agentique.

Lisez la colonne du milieu avant celle de droite. Qui définit la catégorie vous dit beaucoup sur l'endroit où la ligne est placée.

Chaque chaîne de la colonne de droite a été comparée au texte brut de la page liée telle que récupérée le 18 août 2026, plutôt que lue dans un résultat de recherche. Six pages qui se classent sur ce terme n'ont pas pu être lues du tout. Salesforce, IBM, Gartner et BCG ont renvoyé 403 à chaque tentative, et McKinsey et Adobe ont expiré. Aucune d'elles n'est citée ici.

Trois des pages tracent aussi une frontière exploitable avec un terme voisin, et ce sont les trois seules que nous avons jugées dignes d'être conservées.

Face à l'automatisation marketing. Treasure Data écrit que « le marketing agentique est plus étroit que le marketing IA et distinct de l'automatisation marketing », car « l'automatisation marketing exécute des workflows fixes, définis par l'humain ». Le critère n'est pas de savoir si un logiciel agit sans vous. Votre outil d'emailing le fait déjà. Le critère est de savoir si la séquence d'étapes a été choisie à l'avance par une personne.

Face à l'IA générative. Optimove le présente comme un contraste entre deux déclencheurs : « L'IA générative crée du contenu à partir de prompts humains », tandis que « l'IA agentique agit de manière autonome sans attendre de prompts ». En forme de prompt contre en forme d'objectif, ce qui est une vraie distinction et rarement respectée.

Face à un assistant. La phrase la plus tranchante écrite par quiconque dans cet ensemble appartient à Docket Arjun Pillai : « Un assistant attend un utilisateur, aide sur une tâche et vit à l'intérieur d'un workflow humain. » Sa moitié agent est : « Un agent agit vers un objectif, prend des décisions encadrées, déclenche des workflows et possède une partie de l'exécution sous supervision. » Un passage distinct sur la même page fournit le mécanisme qui manque à cette phrase : les humains « définissent les objectifs, les règles d'escalade, les contraintes de sujet et les seuils d'approbation. L'agent opère dans ces limites. Quand quelque chose sort de ces limites, il escalade. » L'escalade est la frontière d'approbation de notre définition, décrite du point de vue de l'agent.

Un désaccord mérite d'être imprimé plutôt que lissé. Forrester, sur une page sur les cas d'usage des agents IA avec Craig Le Clair nommé dessus, sépare les deux termes que toutes les pages fournisseurs ci-dessus traitent comme interchangeables : les agents IA fonctionnent selon des « règles prédéfinies », tandis que « l'IA agentique introduit une autonomie et une adaptabilité plus larges ». Avertissement honnête sur cette citation — c'est une page d'atterrissage de podcast, pas une note de recherche publiée, et nous la citons comme le cadrage d'un cabinet d'analystes plutôt que comme des conclusions.

La couche que huit des onze définitions omettent

Sur les onze pages que nous avons récupérées pour ce terme le 18 août 2026, huit ne mentionnent jamais le Model Context Protocol, l'appel d'outils ou l'appel de fonctions. Cette couche est la différence entre un modèle qui vous rédige un brief de campagne et un modèle qui peut créer une quête, bannir un membre ou rediriger votre flux d'événements ailleurs.

Les huit qui ne mentionnent aucune de ces chaînes : braze.com, cdp.com, docket.io, forrester.com, netcore.ai, tofuhq.com, vlerick.com et youngurbanproject.com. Sur les trois restantes, hubspot.com mentionne le Model Context Protocol mais n'est pas une page définitionnelle. Optimove est celle qui nous a marqués : la chaîne MCP n'apparaît sur sa page que dans le menu de navigation, sous la forme « The Optimove MCP », et jamais dans le corps de l'article expliquant la catégorie. Un fournisseur qui livre un serveur MCP, dont son propre explicatif du marketing agentique n'atteint jamais ce qu'il livre. C'est une affirmation sur onze pages un jour donné, pas sur toute la catégorie — mais elle s'est vérifiée pour chaque page que nous avons contrôlée.

Deux pages de l'ensemble nomment bien la couche manquante, et toutes deux le font bien.

Duncan Lennox de HubSpot écrit: « Mais les agents ne cliquent pas dans les tableaux de bord ni ne naviguent dans les interfaces ; ils appellent des API, lisent des sorties structurées et agissent. » La même page définit le périmètre comme « ce que les agents peuvent lire, écrire et sur quoi ils peuvent agir », ce qui est la bonne unité. Pas « peut-il faire du marketing », mais quels noms et quels verbes.

Real Story Group, un cabinet de recherche martech qui vend des évaluations de fournisseurs, fournit la phrase qui clôt le débat. Dans un article sur MCP daté du 11 juin 2025, l'analyste principal Scott Simmons le qualifie de « couche d'abstraction d'API universelle conçue pour les agents IA », et en tire la conclusion qu'un agent n'est « aussi puissant que ce que le fournisseur choisit d'exposer ».

Cette dernière proposition est tout l'argument. Le marketing agentique n'est pas une propriété du modèle que vous avez choisi. C'est une propriété de la surface que vos fournisseurs publient. Si les outils sont en lecture seule, votre agent fait des rapports. S'il n'y a pas d'outils, votre agent rédige des textes. La question de la capacité et la question de l'achat sont la même question, ce qui explique pourquoi les définitions qui sautent cette couche sont si agréables à lire et si difficiles à mettre en pratique. Si vous voulez la vue d'ensemble des canaux sur lesquels un agent agirait, notre pilier marketing web3 les couvre ainsi que leur coût.

Pourquoi une liste d'outils est une preuve et une étiquette d'outil n'est qu'un indice

Le Model Context Protocol répond à la question de ce qu'un agent peut vous faire en vous disant de lire la liste d'outils du serveur, puis dit aux clients de ne pas faire confiance à ce que cette liste dit d'elle-même. La note qui le dit se trouve dans le schéma plutôt que dans la prose, ce qui explique en partie pourquoi si peu de gens l'ont lue.

Voici le passage, tiré de l' ToolAnnotations interface du schéma de la spécification à la révision 2026-07-28 :

NOTE : toutes les propriétés de ToolAnnotations sont des indices. Ils ne garantissent pas une description fidèle du comportement de l'outil (y compris des propriétés descriptives comme title).

Et sur le même sujet, depuis la page des outils:

Pour la confiance, la sécurité et la sûreté, les clients DOIVENT considérer les annotations d'outils comme non fiables, sauf si elles proviennent de serveurs de confiance.

Prenez un instant pour mesurer cela. La réponse du protocole à « comment puis-je savoir ce que cet objet peut me faire » est : lisez la liste. Sa toute prochaine instruction est : la liste est une déclaration de la partie que vous évaluez. Les noms et schémas des outils sont structurants, car le modèle les appelle et le serveur doit les honorer. Les étiquettes de risque qui leur sont attachées sont la description par le serveur de son propre comportement.

Il existe quatre telles étiquettes — readOnlyHint, destructiveHint, idempotentHint et openWorldHint — et deux d'entre elles, destructiveHint et openWorldHint, valent truepar défaut. Un outil non étiqueté est donc présumé destructif et présumé toucher le monde extérieur, ce qui est le bon choix et l'inverse de ce que la plupart des gens attendent.

Celle qui compte pour une définition du marketing agentique est destructiveHint, à cause de ce qu'elle ne demande pas. Elle sépare l'écrasement de l'ajout. Le préjudice est un autre axe et le schéma n'a aucune colonne pour lui, si bien qu'un appel purement additif peut être la chose la plus lourde de conséquences qu'un agent fasse à votre stack et rester étiqueté de la manière sûre par un serveur agissant en toute bonne foi. Ce que chaque indicateur signifie en pratique, et à quoi ressemble une vraie fiche une fois les valeurs par défaut appliquées, se trouve dans le guide juste à côté.

C'est aussi la version honnête de ce que les marketeurs appellent le « agent washing ». Young Urban Project le nomme précisément : « L'échec le plus courant est le agent washing, qui consiste à prendre une automatisation ou un chatbot existant et à le rebaptiser agentique sans ajouter la couche de planification ou de décision en dessous », et ajoute que « la démo est scénarisée pour masquer exactement l'écart qui compte ». Une liste d'outils est bien plus difficile à scénariser qu'une démo. C'est aussi le seul artefact de toute cette catégorie qu'un acheteur peut vérifier sans la coopération du fournisseur, ce qui explique pourquoi nous avons écrit un guide séparé sur comment énumérer les outils de n'importe quel serveur MCP avant de s'y connecter.

Où se situe la frontière d'approbation, et qui est censé la placer

Le Model Context Protocol indique qu'un humain devrait toujours être dans la boucle avec la capacité de refuser les invocations d'outils, et il le dit à l'application cliente, sous forme de SHOULD plutôt que de MUST. Rien dans le protocole n'oblige le serveur auquel vous vous connectez. L'emplacement de votre frontière d'approbation est un choix que quelqu'un a fait, et souvent pas vous.

La phrase exacte :

Pour la confiance, la sécurité et la sûreté, il DEVRAIT toujours y avoir un humain dans la boucle avec la capacité de refuser les invocations d'outils.

La même section de sécurité demande aux clients de « Montrer les entrées d'outils à l'utilisateur avant d'appeler le serveur, afin d'éviter une exfiltration de données malveillante ou accidentelle » et de « Valider les résultats d'outils avant de les transmettre au LLM ». Les deux s'adressent au client : la chose qui tourne de votre côté, le Claude ou ChatGPT ou le harnais interne qui héberge le modèle. Donc, en lecture simple du protocole, la sécurité de votre marketing agentique est le travail de votre client, et le serveur auquel vous vous êtes connecté ne vous doit rien au-delà d'une liste d'outils honnête.

La catégorie le sait et ne sait pas trop quoi en faire. Les guides fournisseurs définissent régulièrement un agent par l'absence d'une personne puis, plus bas sur la même page, vous disent où remettre la personne ; nous démontons l'une de ces pages dans un agent IA peut-il vraiment gérer votre communauté. Les deux moitiés sont sincères. La définition est écrite pour le marché et l'instruction est écrite pour le déploiement, et l'écart entre les deux est là où se prend réellement chaque décision concrète sur l'autonomie.

La version qui vaut la peine d'être défendue n'est ni « l'autonomie totale » ni « tout approuver ». C'est que la frontière est un réglage par décision avec un coût des deux côtés, et que le mécanisme qui l'applique est lui-même un logiciel qui peut échouer — comme l'a montré la défaillance de modération Discord plus tôt cette année, où l'étape de revue humaine existait dans la conception publiée et un bug l'a retirée du parcours. Nous avons écrit sur ce que cela implique pour laisser un agent gérer une communauté séparément, car cela mérite plus qu'une clause.

Il existe aussi désormais une réponse mesurée à la question de savoir quels appels méritent le verrou, et ce n'est pas celle que donne l'intuition. SABER: Small Actions, Big Errors — Safeguarding Mutating Steps in LLM Agents, par Alejandro Cuadron, Pengfei Yu, Yang Liu et Arpit Gupta, soumis le 26 novembre 2025, étudie où la trajectoire d'un agent utilisant des outils qui tourne mal vous coûte réellement. Il rapporte que « En revanche, les déviations dans les actions non mutantes ont peu ou pas d'effet. » La phrase juste avant donne l'autre côté : chaque déviation supplémentaire dans une action mutante réduit les chances de succès jusqu'à 92 % sur l'un de ses deux domaines et jusqu'à 96 % sur l'autre, pour les modèles de pointe. L'échec se concentre dans les appels qui changent l'état.

La conclusion de conception est peu glamour et peu coûteuse : verrouillez les écritures, laissez les lectures tranquilles, et cessez de traiter le « human in the loop » comme un unique bouton avec un seul réglage. Le serveur de Zealy fonctionne justement ainsi, et nous devons être clairs : nous ne l'avons pas déduit de cet article — l'article est arrivé après la conception et la confirme, ce qui est plus faible qu'une ingénierie guidée par les preuves et plus fort que rien. Une réserve accompagne la citation : SABER documente des erreurs d'annotation dans le benchmark sur lequel il s'appuie et en publie une version corrigée, ce qui est une bonne raison de ne pas citer d'anciens scores de benchmarks d'agents-outils comme s'ils décrivaient encore les modèles actuels. L'autre raison d'être prudent avec un chiffre unique ici est que la défaillance d'un agent est en grande partie un problème de variance — la recherche multi-tours divise la dégradation en une perte mineure d'aptitude et une forte hausse de l'instabilité, ce qui est un problème de gestion différent d'un modèle simplement pas assez bon.

Le même schéma « laissé à l'implémenteur » se retrouve un niveau plus bas, à la quatrième partie de notre définition. Nous avons téléchargé sept pages de spécification et de sécurité le 18 août 2026 et les avons parcourues : le modèle de menace de la spécification est un modèle de menace d'autorisation et de transport, couvrant le confused deputy, le passthrough de jetons, la falsification de requête côté serveur et un serveur local compromis, entre autres, tandis que l'attaque au niveau du modèle est laissée aux implémenteurs. Sur les pages que nous avons téléchargées, l'expression « prompt injection » n'apparaît pas ; les quatre occurrences de « injection » dans le document de bonnes pratiques de sécurité sont le cross-site scripting, l'injection de commandes shell et l'exécution de code à distance. Ce n'est pas une critique d'une spécification de transport, qui a le droit de délimiter son périmètre. C'est une affirmation sur la moitié du problème que vous héritez dès que vous connectez quelque chose, et sur pourquoi une frontière de confiance sur les données renvoyées doit être le travail explicite de quelqu'un plutôt qu'une propriété supposée du protocole.

Zealy échoue à sa propre définition, et c'est ici que

Selon les définitions les plus strictes de cet article — « sans qu'un humain approuve chaque étape individuelle » de Young Urban Project et « sans exiger l'approbation humaine à chaque étape » de Netcore — Zealy ne fait pas de marketing agentique. Chaque écriture via la surface d'agent de Zealy s'arrête pour une personne, et les écritures sont désactivées jusqu'à ce qu'un opérateur les active.

Nous préférons le dire plutôt que de perdre l'argument plus tard. Voici la grille d'évaluation complète face à nos propres quatre parties, de première main et non auditée.

Les quatre sont présentes, ce qui est la partie facile. La troisième est réglée dans le mauvais sens pour le label. Le serveur de Zealy place la barrière d'approbation côté serveur, ce qui est plus que ce que le protocole exige d'un serveur et plus qu'une définition stricte du marketing agentique ne le permet. La surface d'outils elle-même est assez vaste pour mériter un audit — 72 outils nommés au moment où nous les avons comptés — mais le nombre n'est pas l'essentiel. Le réglage l'est.

Nous ne pouvons pas non plus revendiquer la cohérence sur l'ensemble du produit. Zealy livre aussi un évaluateur IA qui clôt une demande de quête de lui-même, sans personne dans ce chemin : la même entreprise, le réglage opposé, sur une décision qui touche au fait qu'un membre soit payé. Les deux choix sont défendables ; ce que nous ne pouvons honnêtement pas dire, c'est qu'il existe une réponse unique à l'échelle de l'entreprise sur le degré d'autonomie approprié.

Alors retirons le label. Ce que Zealy offre réellement, c'est une surface lisible par un agent avec une étape de validation humaine, ce qui est un nom ennuyeux pour ce que la plupart des équipes devraient vouloir en premier. Si vous voulez les mécanismes de connexion, la documentation d'intégration MCP fait référence et cet article ne les reprend délibérément pas ; si vous voulez la surface plus ancienne et plus large en dessous, la documentation API la couvre. Et si vous n'avez jamais utilisé le produit, ce qu'est Zealy est le chemin le plus court.

Ce qu'il faut demander avant d'acheter quelque chose appelé marketing agentique

Demandez la liste d'outils. Un fournisseur qui vend du marketing agentique peut soit vous montrer les opérations nommées auxquelles un agent a accès, avec les permissions associées, soit il ne peut pas. Tout le reste — le langage de planification, le langage de poursuite d'objectifs et la démo — est compatible avec un chatbot relié à un formulaire, et Young Urban Project a un nom pour cela.

Cinq questions, dans l'ordre qui vous donne le plus d'informations pour le moins de temps de réunion :

1. « Quelles opérations l'agent obtient-il, par leur nom ? » Si la réponse est une phrase de capacité plutôt qu'une liste, vous avez votre réponse. Si c'est une liste, lisez-la pour les verbes. Lire, écrire, supprimer, envoyer, publier, payer.
2. « Lesquelles peuvent agir sans moi ? » Pas « y a-t-il un humain dans la boucle » : cette question reçoit un oui de tout le monde. Demandez quels appels précis se passent de la personne, et qui a choisi cette répartition.
3. « Qu'advient-il du texte écrit par un client quand l'agent le lit ? » Vous demandez si les résultats d'outils sont traités comme des données ou comme des instructions potentielles. Un fournisseur qui y a réfléchi répondra immédiatement, car c'est le mode de défaillance qui empêche ses ingénieurs de dormir.
4. « Que signifient vos étiquettes de risque ? » Vérifiez ensuite la réponse par rapport à la spécification plutôt qu'au dossier commercial, et demandez quels sont les paramètres par défaut — la plupart des gens les devinent à l'envers.
5. « Que ne peut-il pas faire ? » Une liste de limites est le signal de crédibilité le moins coûteux possible et presque personne n'en publie. Son absence ne prouve rien. Sa présence vaut beaucoup.

La dernière chose à dire concerne le séquençage, car la décision d'achat est ici généralement mal synchronisée. La plupart des équipes qui évaluent le marketing agentique n'ont pas encore écrit quelles tâches récurrentes peuvent être déléguées sans risque et lesquelles non — et cette décision est la même que les mains appartiennent à un prestataire, à un modérateur ou à un modèle. Comment déléguer les tâches communautaires l'examine avec des personnes, et l'analyse se transpose presque à l'identique. Faites cela d'abord. L'agent sera toujours là, et vous saurez quels outils vous voulez réellement lui donner.