WebMCP va-t-il mettre fin au modal newsletter & offre de réduction ? Nous l'espérons. Nous en avons enregistré un sur notre site pour le savoir.

Vous cliquez sur un lien, la page commence à charger, et un popup glisse par-dessus avant que vous ayez lu une phrase. Dix pour cent de réduction, si vous confiez une adresse email à une entreprise chez qui vous êtes arrivé il y a neuf secondes. Vous le fermez. Quelque part plus bas, un second attend le moment où vous vous dirigerez vers le bouton retour.

Ce popup n’est pas un échec de conception. Il fait exactement ce pour quoi il a été construit, et il fonctionne assez bien pour que personne dans l’équipe marketing ne plaide sa suppression.

Une adresse email est la clé du programme de rétention. Une fois qu’une marque en tient une, elle peut faire tourner les flux de cycle de vie qui se trouvent derrière chaque plateforme ecommerce : la série de bienvenue qui se déclenche à l’inscription, l’email d’abandon de navigation qui part quand quelqu’un regarde un produit et s’en va, la séquence d’abandon de panier et de checkout, les rappels post-achat et de réapprovisionnement, la reconquête de quiconque s’est tu. Aucun de ces flux ne peut démarrer sans l’adresse. Tous sont déclenchés par le comportement et continuent de rapporter longtemps après que la publicité qui a amené le visiteur a été payée.

Voilà ce qu’achètent les dix pour cent. La réduction est le prix d’achat d’une ligne de contact permanente, et elle est bon marché à côté du clic payant qui vous a livré. Les flux déclenchés rapportent bien plus par destinataire qu’une newsletter diffusée, et la séquence de panier abandonné rapporte le plus de toutes, si bien qu’un marketeur qui compte la valeur d’une adresse ne compte pas un email. Il compte un flux d’emails qui court pendant des années.

Cela explique aussi le calendrier. Le popup se déclenche à l’arrivée, à une certaine profondeur de défilement, ou au premier signe que vous vous dirigez vers le bouton retour, parce qu’un visiteur qui part sans céder d’adresse est injoignable pour toujours, tandis qu’un visiteur qui en cède une est le début d’une séquence. Une marque qui collecte des adresses sur trois pour cent de ses visiteurs fait une excellente affaire pour le prix d’agacer les quatre-vingt-dix-sept autres.

WebMCP ne touche à rien de tout cela. Ce qu’il change, c’est le mécanisme. Une page peut publier son inscription comme une fonction, décrire en langage clair ce qu’elle fait, et laisser l’agent IA qui travaille pour le visiteur l’appeler quand le visiteur demande réellement l’offre. L’adresse arrive quand même, la réduction est quand même envoyée, et rien n’interrompt la lecture.

Pour la personne qui lit, c’est tout le gain. La question est de savoir combien on peut en récolter aujourd’hui, et la réponse honnête tient en une part.

Comment le visiteur vit la disparition du popup

Voici la même offre, collectée de deux façons. À gauche, ce qu’obtient un visiteur aujourd’hui. À droite, ce qu’obtient la même personne quand la page a publié son inscription sous une forme que son assistant peut exécuter.

Ce qui met vraiment fin au popup, c’est un changement de trafic

Certains, dans la marque, laisseraient tomber le popup complètement. Il reste parce qu’interrompre les gens est la seule méthode qui collecte des adresses email de façon fiable, et parce que le coût de cette interruption tombe sur le visiteur plutôt que sur l’équipe qui l’a choisie. Tous ceux qui lisent obtiennent une expérience dégradée pour qu’un petit pourcentage d’entre eux cède une adresse, et le marché tient depuis une vingtaine d’années parce que rien d’autre ne collectait aussi bien les adresses.

Le marché ne se rompt que lorsqu’une seconde méthode commence à collecter les mêmes adresses sans l’interruption, et il se rompt une visite à la fois.

Un popup ne fonctionne que sur un humain devant un écran. Quand un assistant fait la lecture, il n’y a pas d’écran à couvrir ni d’hésitation à minuter, si bien que cette visite ne produit aucune adresse, quel que soit le réglage du popup.

La même visite peut tout de même produire une adresse. Quelqu’un qui demande la réduction à son assistant en cède une volontairement, avec un nom attaché, au moment où il la voulait. Cette adresse est plus propre, l’intention derrière elle est plus forte, et aucun capital de sympathie n’a été dépensé pour l’obtenir.

Une équipe marketing garde le popup tant qu’il paie. À mesure que davantage de visites arrivent par des assistants, le popup se déclenche devant un public qui rétrécit pour un retour qui rétrécit, alors que l’agacement qu’il provoque reste constant. Le même calcul qui l’a mis sur la page finit par l’en retirer.

Rien de tout cela n’arrive selon un calendrier qu’une spécification contrôle. Cela arrive quand assez de gens lisent le web à travers quelque chose qui lit pour eux, ce qui est une question de trafic plutôt qu’une question de standards, et cela se mesure dans vos propres logs dès aujourd’hui.

Ce qui mérite d’être dit clairement, c’est que la destination est bonne. Un web où l’offre est disponible pour quiconque la demande, et invisible pour tous ceux qui ne l’ont pas demandée, est meilleur pour le lecteur et pas pire pour la marque. C’est une combinaison rare, et c’est la raison pour laquelle cela vaut la peine de construire dans ce sens tôt plutôt que d’attendre que la portée arrive.

L’objection d’Apple, c’est qu’un site ne devrait jamais savoir qu’un agent est aux commandes

Deux ingénieurs d’Apple ont exposé l’objection de WebKit dans le fil public des standards-positions en juin 2026, et la position a été arrêtée comme opposition le 11 juin. Ils avancent six raisons, et la première touche à ce qu’est un agent.

La position de WebKit tient qu’un agent agissant pour un utilisateur est « en pratique une technologie d’assistance : il devrait utiliser un site comme l’utilisateur le ferait, et le site ne devrait pas le distinguer pour un traitement différent ». WebMCP fait l’inverse. Il fait de « un agent est aux commandes » un fait observable, et dès lors que cela devient adressable séparément, rien ne maintient les deux surfaces à parité. Un site peut donner aux agents des capacités qu’il refuse à sa propre interface, ou les refuser aux agents, ce qu’ils décrivent comme « le problème du blocage des lecteurs d’écran, appliqué aux agents IA ».

Ils doutent aussi de la promesse de fiabilité. Un agent choisit toujours un outil en lisant son nom et sa description, dont la spécification elle-même concède qu’ils sont ambigus et invérifiables, sans « aucune garantie que l’intention déclarée d’un outil WebMCP corresponde à son comportement réel ». Un schéma typé fixe la forme d’un argument et non le sens que l’agent doit inférer, si bien que, dans leur lecture, la fragilité sort de la page pour entrer dans les descriptions d’outils au lieu de disparaître.

L’objection de vie privée est plus tranchante que d’ordinaire. Un site peut demander plus de paramètres qu’il n’en a besoin, et un agent serviable les remplit à partir de ce que l’utilisateur a dit à l’agent plutôt qu’au site. La spécification qualifie cela de pipeline « de la personnalisation au fingerprinting » dans son propre texte.

Ils relèvent aussi que les éléments dont un relecteur aurait besoin pour juger de tout cela, l’analyse de sécurité cross-origin et le point d’accroche du consentement parmi eux, restent marqués comme du travail à faire, et qu’un groupe dont le mandat porte sur l’apprentissage automatique est le mauvais lieu pour des changements dont la place réelle est dans HTML et dans la sémantique d’accessibilité.

Un de leurs invariants déclarés pointe directement vers le sujet de cet article : « Certains utilisateurs ne voudront pas, ou ne pourront pas, se servir d’agents, si bien que le résultat doit bénéficier à tous les utilisateurs et ne doit pas privilégier ceux qui en ont un. »

Placez cela à côté du motif présent dans le code ci-dessus. Supprimer le popup dépend de ce que la page apprenne qu’un agent a agi, ce qui est exactement l’observabilité qu’Apple juge illégitime. L’expérience silencieuse décrite plus haut s’achète avec un signal qu’un second moteur estime que le web ne devrait pas exposer. Les deux peuvent être vrais, et quiconque construit là-dessus devrait savoir qu’il choisit un camp plutôt qu’il ne ramasse un outil stabilisé.

Les éditeurs de Google ont répondu dans le même fil et demandé ce qui satisferait WebKit à défaut de retirer l’API impérative. La réponse a été qu’ils ne répondraient pas point par point, parce que chaque question suppose l’approche saine, et ils ont proposé de repartir de zéro : un nouveau groupe communautaire, le problème défini avant toute solution, et un atelier autour du TPAC fin octobre 2026.

Aucun iPhone ne peut faire tourner cela, y compris Chrome pour iPhone

La position d’Apple n’est pas seulement un vote dans un fil de standardisation. Elle décide de la fonctionnalité pour tous les navigateurs de la plateforme.

Tous les navigateurs livrés sur iOS aujourd’hui rendent avec WebKit. Chrome pour iPhone est le moteur de Safari revêtu de l’interface de Google, et il en va de même pour Edge, Firefox et les autres. Une fonctionnalité que WebKit refuse d’implémenter est donc indisponible sur un iPhone, quelle que soit l’icône de navigateur sur laquelle on appuie.

Cela peut changer, lentement. La Competition and Markets Authority britannique a jugé l’exigence de moteur d’Apple contraire à son régime de Strategic Market Status, avec un plan de conformité attendu en juin 2026 et des changements prévus dans iOS 20 à l’automne 2026, avant une conformité complète en janvier 2027. Le Digital Markets Act de l’Union européenne autorise les moteurs alternatifs depuis 2024. En pratique, aucun des deux n’en a produit : aucun éditeur de navigateur n’a livré de moteur alternatif via l’App Store, et Google comme Mozilla disposent de portages restés inédits.

Pour une marque ecommerce, c’est le chiffre qui compte plus que n’importe quelle date de spécification, parce que le trafic iPhone représente une large part de la plupart des boutiques et que rien de ce trafic ne peut atteindre un outil enregistré aujourd’hui.

Le tester suppose un navigateur Chromium, ce que la plupart des agents utilisent déjà

Les agents qui font la lecture sont déjà sur le bon moteur. Claude tourne comme extension dans Chrome, Gemini est intégré à Chrome, Copilot se trouve dans Edge, et Comet de Perplexity est un navigateur Chromium à part entière. La navigation agentique sur le bureau est très majoritairement Chromium aujourd’hui, si bien que le moteur est rarement l’obstacle.

L’obstacle que l’on manque, c’est que tous les assistants qui lisent votre page ne sont pas des navigateurs. Demandez à ChatGPT ou à Claude dans une fenêtre de conversation d’ouvrir une URL et la récupération se fait le plus souvent sur un serveur : votre HTML est récupéré, aucun JavaScript ne s’exécute, et aucune liste d’outils n’est jamais construite. Cet assistant peut lire chaque mot de votre page sans avoir la moindre idée qu’un outil y a été enregistré. Seul un agent opérant à l’intérieur d’une vraie page Chromium voit l’outil, ce qui signifie aujourd’hui quelque chose comme Gemini dans Chrome ou une extension qui implémente elle-même la découverte.

L’obstacle, c’est que la fonctionnalité reste sous condition, et il y a deux façons de franchir la porte.

Le site s’inscrit à l’origin trial de Chrome et sert le jeton. C’est la voie que prend une boutique en production, et elle tient en trois étapes.

Enregistrez l’origine sur developer.chrome.com/origintrials/#/register_trial/4163014905550602241, qui est l’essai WebMCP et court de Chrome 149 à Chrome 156. Saisissez l’origine qui sert réellement vos pages, sous-domaine compris, parce qu’un jeton émis pour example.com ne couvre pas www.example.com. Si votre apex redirige vers www, enregistrez l’hôte www et laissez de côté la correspondance de sous-domaines, puisqu’une redirection ne charge jamais de document et n’a donc jamais besoin du jeton.

Servez le jeton qu’il vous donne, soit en en-tête de réponse, soit en balise meta dans le head de chaque page qui enregistre un outil :

<meta http-equiv="origin-trial" content="YOUR_TOKEN_HERE">

Ne l’émettez que lorsque vous en avez un. Un jeton vide ou expiré consigne une erreur de console à chaque chargement de page, alors rendez la balise conditionnelle plutôt que de coller un attribut vide et de l’oublier.

Edge fait tourner un essai distinct avec son propre enregistrement et son propre jeton. S’inscrire à l’un ne fait rien pour l’autre.

Ou le visiteur l’active lui-même, en lançant Chrome avec --enable-blink-features=WebMCP ou en activant les fonctionnalités expérimentales de la plateforme web dans chrome://flags. C’est la voie d’un développeur, pas celle d’un client.

Cette page prend la première voie. Chaque page de ce site sert un jeton d’origin trial WebMCP, si bien qu’un visiteur arrivant dans Chrome 149 à 156 obtient document.modelContext sans rien à activer, et le panneau ci-dessus le dira. Ce jeton expire le 17 novembre 2026, moment auquel l’outil se tait pour les visiteurs ordinaires jusqu’à ce que l’essai soit prolongé ou que la fonctionnalité soit livrée, et le formulaire continue comme il l’a toujours fait. Quiconque est sur Safari, sur n’importe quel navigateur d’iPhone, ou sur un Chrome hors de cette plage de versions voit le formulaire et rien d’autre.

Les anciens tutoriels ne fonctionneront pas, et la plupart se trompent de date

WebMCP n’est pas un standard du web abouti. C’est un brouillon, édité par des ingénieurs de Google et de Microsoft, et les brouillons changent alors que des gens construisent déjà dessus. Celui-ci a changé d’une façon qui casse le code.

Le nom que vous appelez a bougé. C’était navigator.modelContext et c’est désormais document.modelContext. Chrome a accepté les deux noms pendant un temps et a averti les développeurs dans la console, puis a cessé d’accepter l’ancien à partir de Chrome 152, arrivé chez tout le monde le 25 août 2026. Le code écrit à l’ancienne ne ralentit pas et ne se dégrade pas. Il s’arrête.

Nous le signalons parce que les articles se contredisent sur la date. Plusieurs situent le changement en août 2026. L’historique du projet lui-même le place en mai, trois mois plus tôt :

Utilisez document.modelContext. Un tutoriel qui tend la main vers navigator a été écrit contre quelque chose qui n’existe plus, et une date tirée d’un billet de blog vaut moins que la même date tirée de l’historique de commits du projet.

La prise en charge est Chromium et rien d’autre. Chrome a ouvert un test public en juin 2026 qui court jusqu’à Chrome 156. Edge fait tourner le sien depuis Edge 150 et Brave l’a de façon expérimentale, et tous deux reposent sur le moteur de Chrome. Apple s’est formellement opposé à la proposition le 11 juin 2026. Mozilla n’a pris aucun parti et garde un prototype ouvert.

Un outil, c’est une fonction plus les mots qui disent à un assistant quand s’en servir

Un outil est un dictionnaire avec un nom, une description, un schéma d’entrée JSON et un callback d’exécution. Le nom accepte de 1 à 128 caractères ASCII alphanumériques, plus le tiret bas, le trait d’union et le point. L’exigence de contexte sécurisé couvre toute l’interface, getTools et executeTool compris, et l’accès est régi par une fonctionnalité de Permissions Policy appelée tools dont la liste d’autorisation par défaut est 'self'.

La description pèse plus lourd que le nom. Un agent choisit entre des outils en lisant les descriptions, si bien qu’une description écrite pour un changelog de développeur perdra face à une description écrite pour la personne qui décide.

Écrire l’inscription comme un outil prend une trentaine de lignes

Le motif a deux moitiés. Enregistrer l’offre comme un outil, et apprendre au modal à se retirer une fois l’offre acceptée.

const modelContext = document.modelContext || navigator.modelContext;

if (modelContext) {
  modelContext.registerTool({
    name: "subscribe_to_offer",
    title: "Get the first-order discount code",
    description:
      "Starts a first-order discount signup by sending a confirmation email to an " +
      "address. The code arrives only after the address is confirmed. Call this when " +
      "the visitor asks for the discount or asks to join the mailing list.",
    inputSchema: {
      type: "object",
      properties: {
        email: {
          type: "string",
          format: "email",
          description: "The address the visitor wants the code sent to."
        }
      },
      required: ["email"]
    },
    annotations: { readOnlyHint: false },
    execute: async ({ email }, { signal }) => {
      const res = await fetch("/api/subscribe", {
        method: "POST",
        headers: { "Content-Type": "application/json" },
        body: JSON.stringify({ email, source: "webmcp" }),
        signal
      });

      if (!res.ok) {
        return "The signup did not go through. The form near the foot of the page still works.";
      }

      // Silence the popup for the rest of this visit. Make it permanent from the
      // server when the confirmation link is clicked, never from here.
      try { sessionStorage.setItem("offer_asked", "1"); } catch (e) {}

      return "Confirmation email sent. The code arrives once the address is confirmed.";
    }
  });
}

Le popup se tait dès que l’outil s’exécute, et c’est tout l’intérêt de faire tout cela.

L’indicateur ne dure que le temps de la visite, volontairement. Éteindre le popup définitivement, avant que quiconque ait cliqué le lien de confirmation, retire l’inscription à un visiteur dont l’adresse n’a jamais été confirmée et ne lui laisse aucun moyen de s’abonner. Faites taire le popup pour la visite depuis la page. Rendez cela permanent depuis votre serveur une fois la confirmation cliquée.

annotations: { readOnlyHint: false } indique à l’agent que l’appel modifie quelque chose plutôt qu’il ne lit quelque chose. C’est déjà la valeur par défaut, et l’écrire place le prochain lecteur à une ligne de untrustedContentHint, qui est l’annotation qui compte pour tout outil renvoyant du texte sur lequel un agent va agir.

Le signal est un signal d’abandon que le navigateur remet à chaque outil qu’il exécute. Le passer dans la requête fait qu’un agent qui abandonne en cours de route ne laisse pas une inscription se terminer pour quelqu’un qui a cessé de demander.

Il n’existe aucun moyen de demander à la page si un agent l’observe. La spécification offre getTools, executeTool et un événement toolchange, et aucun des trois ne répond à la question. Votre propre outil appelé est le seul signal fiable que vous obtenez. Écrivez le même indicateur que votre popup vérifie déjà, et il cesse de se déclencher pour ce visiteur de la même façon qu’il s’arrête après que quelqu’un a rempli le formulaire.

La version qui tourne sur cette page

Ce site enregistre un seul outil, appelé contact_wislr, et il est en ligne depuis la publication de cet article. Le formulaire de contact de ce site s’ouvre sur un clic plutôt qu’il ne se déclenche sur une intention de sortie, si bien que l’outil ne supprime pas une interruption ici. Il supprime la saisie.

Trois décisions de cette implémentation méritent d’être copiées.

Le schéma demande plus que le formulaire. Le formulaire est un unique textarea avec un placeholder qui rappelle d’inclure son nom et son email. Beaucoup de messages arrivent sans l’un ni l’autre, et un message sans adresse de réponse est une piste à laquelle on ne peut pas répondre. L’outil déclare name, email et website comme entrées nommées à côté du message, si bien qu’un agent qui remplit l’appel a un endroit évident où les mettre.

La valeur de retour donne à l’agent de quoi agir. Le callback d’exécution peut se résoudre sur n’importe quoi, et executeTool remet à l’agent une chaîne, qu’il lit. Quand un message arrive sans adresse email, le nôtre le dit et demande à l’agent d’en collecter une et d’envoyer un second message. Une confirmation qui dit seulement « envoyé » jette la seule occasion de corriger l’appel pendant que le visiteur est encore là.

L’agent partage le budget d’envoi du formulaire. Le formulaire autorise trois messages par session de navigation, comptés dans sessionStorage. L’outil lit et écrit le même compteur, si bien qu’un agent et un visiteur qui travaillent la même page en ont trois à eux deux plutôt que trois chacun. Cela a demandé une modification du formulaire, qui lisait le compteur une seule fois au chargement de la page et le gardait dans une variable. Une copie en cache donne à chaque surface son propre budget et laisse celle qui écrit en dernier annuler l’autre, ce qui est le genre de bug qui n’apparaît qu’une fois qu’une seconde surface existe.

Le point de terminaison est celui vers lequel le formulaire poste déjà. Les champs nommés sont assemblés dans le corps du message avant le départ de la requête, si bien que le gestionnaire existant n’a eu besoin d’aucune modification pour les lire, et la charge utile porte un champ source pour que les messages envoyés par un agent puissent être comptés à part des messages saisis, sans analyser de la prose.

Comment le voir fonctionner

Ce site sert le jeton de l’essai, donc il n’y a rien à activer. Ouvrez n’importe quelle page d’ici dans Chrome 149 à 156 et le panneau plus haut dans cet article vous dira si votre navigateur dispose de l’outil, puis le bouton en dessous l’appelle pour de vrai.

Pour le vérifier vous-même, demandez au navigateur quels outils lui ont été proposés :

const mc = document.modelContext || navigator.modelContext;
const tools = await mc.getTools();
console.log(tools.map(t => t.name));
// ["contact_wislr"]

Les deux noms se résolvaient encore dans Chrome 151, qui est l’alias dans son dernier jalon. À partir de Chrome 152, seul document.modelContext répond.

Sur un site qui ne s’est pas inscrit à l’essai, document.modelContext est undefined et rien de tout cela ne tourne. Lancer Chrome avec --enable-blink-features=WebMCP active l’API localement, ce qui est la façon de développer avec avant qu’un jeton n’existe.

Une différence entre la spécification et l’implémentation mérite d’être connue avant qu’elle ne vous coûte un après-midi. L’IDL type le second argument de executeTool comme un objet, et passer un objet échoue avec UnknownError: Failed to parse input arguments, qui ne dit ni quel argument ni pourquoi. Chrome veut les arguments sérialisés :

await mc.executeTool(tool, JSON.stringify({ message: "How do you measure AI referrals?" }));

getTools() répond de la même façon. L’inputSchema d’un outil renvoyé arrive comme une chaîne JSON plutôt que comme l’objet qui a été enregistré, si bien que tout ce qui le relit doit d’abord le parser.

Des choses plus utiles se trouvent sur la même page

L’inscription est le point de départ parce que le point de terminaison, le flux de consentement et l’email de confirmation existent déjà. C’est aussi la plus petite chose de la page qui vaille la peine d’être exposée.

Chaque interaction qu’un visiteur mène à bien à la main est une candidate, et celles qui demandent plusieurs étapes gagnent le plus à être réduites à un seul appel.

Les outils en lecture seule sont l’endroit le plus sûr pour commencer. Mettre readOnlyHint: true sur un outil de recherche ou de disponibilité indique à l’agent que l’appel ne change rien, et une erreur coûte une requête perdue plutôt qu’un enregistrement écrit dans votre base.

Tout ce qui est derrière une authentification reste derrière cette authentification. Un outil enregistré s’exécute dans la page avec la session dont le visiteur dispose déjà, si bien que get_order_status est exactement aussi protégé que la page compte qu’il lit, et pas davantage.

Rien ici ne change la raison pour laquelle le popup a été construit

Un outil ne s’exécute qu’après que quelqu’un a demandé quelque chose. Cette personne a dit à son assistant d’obtenir la réduction, et l’assistant a trouvé la fonction qui le fait. Elle allait de toute façon céder une adresse par le chemin que vous lui auriez donné.

Le popup vise la personne inverse. Quelqu’un qui n’a rien décidé et qui s’en va, attrapé par un minuteur ou par la souris qui remonte vers le bouton retour. Il gagne sa place en convertissant des gens qui n’allaient pas convertir, et c’est la seule raison pour laquelle une équipe accepte d’agacer tous les autres pour les obtenir.

Couper le popup pour le trafic agentique ne coûte donc rien, parce que ces visiteurs n’ont jamais été sa cible. Le supprimer pour tout le monde revient à renoncer aux adresses qu’il a été construit pour attraper, ainsi qu’aux années d’emails qui en découlent.

Les équipes marketing sont jugées sur la vitesse de croissance de la liste et sur le chiffre d’affaires que les emails de cycle de vie rapportent. WebMCP ne déplace ni l’un ni l’autre. Il donne à un visiteur volontaire un chemin plus propre et laisse intacte la raison de l’interruption.

La prise en charge décide du reste. Chromium seulement, dans des tests qui s’arrêtent à Chrome 156, avec Apple opposé. Remplacer un formulaire d’inscription par un outil retirerait le chemin qu’emploient presque tous les visiteurs en échange d’un chemin qui fonctionne dans une fraction d’un seul navigateur.

Pour l’instant, c’est une voie d’accès supplémentaire. Le popup se déclenche moins souvent à mesure que davantage de visites arrivent par des assistants, et il disparaît entièrement le jour où collecter une adresse cesse de payer. Aucune spécification ne peut avancer ce jour-là.

Une inscription ouverte, voilà comment les gens se retrouvent ensevelis sous le courrier

Un outil d’inscription prend une adresse email qu’il ne peut pas vérifier et lui envoie du courrier. Quiconque sait piloter un agent peut le pointer vers n’importe quelle boîte. Votre formulaire a le même trou, parce que l’adresse derrière les deux est une URL publique sur laquelle un script peut poster sans jamais charger votre page.

L’attaque a un nom. Dans une campagne de list bombing, l’adresse d’une victime est soumise à des centaines ou des milliers de sites d’un coup, une requête pour chacun. Chaque site voit une inscription unique et sans relief, et rien ne paraît anormal nulle part. La victime reçoit des milliers d’emails de confirmation en une heure, et ce déluge sert en général à couvrir autre chose qui arrive dans la même boîte : une alerte de fraude de sa banque, une réinitialisation de mot de passe, un reçu pour un achat que quelqu’un a fait avec sa carte. Votre réputation d’expéditeur en prend un coup aussi, et c’est la plus petite partie de ce qui s’est passé.

Cette forme met en échec la défense vers laquelle la plupart des gens se tournent. Une limitation de débit compte des requêtes, et une campagne qui vous envoie exactement une requête ne lui donne rien à compter.

Quatre choses aident vraiment.

Placez un challenge devant l’inscription, pour qu’une soumission automatisée doive franchir quelque chose qu’une vraie personne passe sans s’en apercevoir.

Dédupliquez par adresse et tenez une liste de suppression, pour qu’une même boîte ne puisse pas être inscrite encore et encore et qu’une seconde demande pour une adresse dont la confirmation est déjà en attente n’envoie rien du tout.

Demandez aux gens de confirmer avant de les ajouter à une liste, pour qu’un appel détourné ne puisse pas produire d’abonnement. Une réserve prend les gens de court : selon la loi anti-pourriel canadienne, un email de confirmation compte lui-même comme un message commercial, si bien qu’en envoyer un à une adresse qui n’a rien demandé constitue la violation plutôt que la protection. Les tribunaux allemands se sont divisés sur la même question. La confirmation est le bon réglage par défaut dans la plupart des pays et elle n’est pas universelle.

Enregistrez d’où vient chaque inscription au moment où la ligne est écrite. Le déduire après un incident revient à deviner quelles adresses étaient réelles.

Prouver le consentement est plus difficile quand c’est un logiciel qui a cliqué

Une soumission de formulaire produit un enregistrement de ce que le visiteur a vu. La case à cocher, le libellé à côté, le lien de confidentialité et l’horodatage se trouvent tous de votre côté.

Un appel d’outil produit une adresse email dans un argument de fonction. Ce que l’on a dit au visiteur avant que l’agent n’agisse s’est passé dans une conversation à laquelle vous n’avez pas accès. Sous le RGPD, le consentement doit être libre, spécifique, éclairé et univoque, et un responsable de traitement doit pouvoir le démontrer ensuite. Une adresse qui arrive par un agent ne satisfait à rien de tout cela par elle-même.

Le double opt-in porte ici l’essentiel du poids, pour la deuxième fois. L’email de confirmation part vers l’adresse elle-même, et cliquer dessus produit une action horodatée de l’abonné plutôt que de quelque chose qui agit pour lui. Gardez les inscriptions passées par un agent distinguables en base pour qu’un audit puisse les séparer des soumissions de formulaire au lieu de traiter toute la liste comme une seule provenance.

Ces inscriptions disparaissent en silence, alors construisez le comptage d’abord

Un agent qui appelle un outil enregistré exécute un callback à l’intérieur de la page. Il n’y a pas de page vue, pas d’événement de soumission de formulaire, et fréquemment pas de session du tout au sens où un outil d’analytics navigateur l’entend. La conversion a lieu et l’abonné est réel, pendant que le rapport ne montre rien. Montez cela de travers et l’échec est silencieux : les abonnés grimpent, aucune source ne les explique, et rien dans l’interface n’a l’air cassé.

C’est le même trou structurel qui cache les crawlers IA et les visites référées par IA aux outils d’analytics navigateur, arrivant à une nouvelle couche. Un crawler n’exécute jamais le JavaScript qui le signalerait. Un agent exécute le JavaScript, et exécute la partie qui achève la conversion tout en sautant chaque partie qui l’aurait mesurée.

La requête qui frappe votre point de terminaison d’inscription est le seul endroit où la conversion existe sous une forme qui vous appartient. Marquez-la là, dans des logs first-party, et le canal devient quelque chose que vous pourrez dimensionner au trimestre prochain.

Quatre choses qui les empêchent de disparaître

Estampillez la source côté serveur, dans la même écriture que celle qui crée l’abonné. La page envoie un champ source avec la requête, et le serveur le pose sur la ligne à côté de l’adresse et de l’horodatage. Le déduire ensuite à partir de la formulation du message tient de la devinette, et le référent ne vous sauvera pas, parce que les agents n’en envoient fréquemment aucun.

Signalez l’inscription avant l’appel réseau plutôt qu’à l’intérieur du gestionnaire de succès. Un appel abandonné en cours de route, ou qui échoue après que le serveur a déjà fait le travail, n’atteint jamais la branche de succès. Signalez-le au départ et vous comptez la tentative, qui est le nombre que vous voulez vraiment.

Créez l’événement dans votre outil d’analytics avant de livrer l’outil. Les événements personnalisés sont couramment acceptés puis écartés de tous les rapports tant qu’un objectif au nom correspondant n’existe pas, si bien qu’un événement non enregistré renvoie un code de succès et n’apparaît nulle part. Le silence du tableau de bord n’est pas la preuve que rien ne s’est déclenché, et c’est la façon la plus simple de passer une semaine à déboguer du code qui fonctionnait depuis le début.

Réconciliez une fois par semaine, délibérément. Comptez les lignes de vos propres données portant la source agent, puis comparez avec ce que votre analytics affiche pour les mêmes jours. Deux nombres qui concordent signifient que le tuyau est intact. Un écart donne la taille de votre angle mort. Du trafic d’un côté et un zéro de l’autre signifient que l’événement n’arrive pas du tout, et vous le savez désormais en une semaine plutôt qu’à la fin du trimestre.

Que faire à ce sujet ce trimestre

Enregistrer un outil prend un après-midi. Commencez par l’offre pour laquelle vous interrompez déjà les gens, parce que le point de terminaison, le flux de consentement et l’email de confirmation sont construits et fonctionnent.

Gardez le formulaire. Presque tous ceux qui passent l’utiliseront encore, et cela reste vrai aussi longtemps qu’Apple tient sa position.

Utilisez document.modelContext, et inscrivez-vous à l’essai Chrome si vous voulez que des visiteurs ordinaires atteignent l’outil plutôt que des développeurs avec un flag activé.

Ajoutez le champ source à votre point de terminaison d’inscription avant de livrer l’outil. Le faire après signifie que vous ne pourrez pas dire lesquelles des inscriptions déjà en base viennent d’un agent.

Lisez les résultats sur votre propre serveur. Une propriété analytics ne vous montrera pas ces inscriptions du tout, et rien en elle n’a l’air cassé pendant qu’elles restent non comptées.

Le chiffre qui vaut la peine d’être suivi n’est aucun des précédents. C’est la part de vos visites qui arrivent par un assistant, qui décide du moment où cela cesse d’être une expérience, et vous pouvez la mesurer dans vos logs dès aujourd’hui, que vous enregistriez un outil ou non.