Vous partagez un lien de devis avec un prospect. Deux minutes plus tard, votre outil de suivi indique qu'il l'a ouvert, a fait défiler six pages et a passé 30 secondes sur chacune.
Vous envoyez immédiatement un e-mail de relance. Votre prospect ne comprend pas de quoi vous parlez : il ne l'a pas encore ouvert.
Ce qui s'est passé : le scanner de sécurité email de son entreprise a ouvert votre lien avant lui. La "vue" était un bot. Et à moins que votre plateforme d'analyse ne gère spécifiquement ce cas, vous ne pouvez pas faire la différence.
Ce n'est pas un cas de figure rare. Cela se produit sur pratiquement chaque e-mail envoyé à des destinataires en entreprise utilisant Microsoft 365 ou Google Workspace. En cold outbound spécifiquement, où chaque lien est réécrit via SafeLinks ou Proofpoint avant la livraison, 60 à 70 % des clics enregistrés par votre CRM sont des scanners, pas des humains, selon la pile de sécurité email du destinataire.
Peu de temps ?
Passez directement à notre solution avec trois couches de détection de bots, ou découvrez ce que cela signifie pour vos statistiques.
Les bots qui gonflent vos statistiques
Il existe trois catégories de trafic automatisé qui frappent les liens de présentations partagées :
Les bots d'aperçu de liens
Lorsque vous collez un lien dans Slack, LinkedIn, Twitter ou iMessage, un bot récupère immédiatement la page pour générer une carte d'aperçu. Ces requêtes proviennent d'agents utilisateurs identifiables : Slackbot-LinkExpanding, LinkedInBot, Twitterbot. Ils sont faciles à détecter et à filtrer. La plupart des outils de suivi les gèrent correctement.
Les robots d'indexation
Googlebot, Bingbot et leurs variantes indexent régulièrement le contenu accessible au public. Ils s'identifient également ouvertement et sont simples à filtrer. Si vos liens partagés sont derrière une authentification ou utilisent des slugs uniques, les robots d'indexation les trouvent rarement de toute façon.
Les scanners de sécurité email
C'est la catégorie qui fausse les statistiques.
Microsoft Defender SafeLinks, Proofpoint URL Defense, Mimecast et Google Safe Browsing analysent chaque lien dans les e-mails entrants avant que le destinataire ne les voie. Leur rôle est de détecter les pages de phishing et les logiciels malveillants. Pour cela, ils ouvrent réellement le lien, chargent la page et, dans de nombreux cas, naviguent à travers son contenu.
Ce qui les rend presque impossibles à distinguer des vrais utilisateurs :
- Agents utilisateurs usurpés. SafeLinks ne s'annonce pas comme un bot. Il utilise de vrais agents utilisateurs de navigateur, des chaînes comme "Chrome 120 sur Windows 11" ou même des identifiants d'appareils mobiles comme "itel A27 Android." Votre serveur voit ce qui ressemble à une visite de navigateur légitime.
- Navigation dans les pages. SafeLinks ne se contente pas de charger la première page. Il navigue à travers environ 6 pages de votre présentation, quel que soit le nombre total de pages. Proofpoint effectue une analyse multi-pages similaire.
- Timing réaliste. Ces sessions durent de 22 à 48 secondes. Elles ne parcourent pas instantanément comme un scraper rudimentaire : le timing semble plausible pour une consultation rapide.
- Événements DOM synthétiques. Certains scanners déclenchent des événements JavaScript (défilements programmatiques, simulations de toucher, voire événements de clic) pour activer d'éventuels scripts malveillants cachés derrière une interaction utilisateur.
Le résultat net : chaque fois que vous envoyez un lien de présentation par e-mail à quelqu'un dans une entreprise utilisant Microsoft 365 (c'est-à-dire la majorité de vos prospects en entreprise), vous obtenez une fausse "vue" qui ressemble à une vraie. Parfois deux : une de la pile de sécurité de l'expéditeur et une de celle du destinataire.
Voici comment une session de bot SafeLinks se compare à celle d'un vrai lecteur humain, côte à côte :
La réécriture d'URL aggrave le problème
Certains outils de sécurité ne se contentent pas de pré-analyser les liens. Ils les réécrivent entièrement. SafeLinks remplace chaque URL dans le corps de l'e-mail par une redirection via les propres serveurs de Microsoft (https://nam02.safelinks.protection.outlook.com/...). Proofpoint fait de même avec ses réécritures URL Defense (https://urldefense.proofpoint.com/v2/...).
Lorsque le destinataire clique finalement sur le lien dans son e-mail, il n'ouvre pas directement votre URL d'origine. Il clique sur l'URL réécrite par SafeLinks, qui transite d'abord par le proxy de Microsoft, et le proxy de Microsoft ouvre votre page pour la ré-analyser à ce moment-là. Ensuite, il redirige le navigateur de l'utilisateur vers votre page réelle.
Le résultat : l'analyse du bot et la vraie visite se produisent simultanément. Le scanner de sécurité ouvre votre présentation depuis une IP de datacenter à la même seconde exacte où le vrai utilisateur l'ouvre depuis son bureau. Vous obtenez deux sessions concurrentes (une du bot, une humaine) avec des horodatages quasi identiques. Si vos statistiques ne peuvent pas les distinguer, vous comptez soit les deux (chiffres gonflés), soit vous risquez de filtrer la vraie (sous-comptage).
C'est le scénario le plus difficile à gérer correctement. L'analyse pré-livraison est facile à identifier isolément : elle arrive quelques minutes avant que quiconque ne clique. Mais la ré-analyse au moment du clic arrive en même temps que le vrai utilisateur, depuis une IP différente, avec un agent utilisateur différent, créant une session séparée qui chevauche la session légitime.
Le piège de la relance
Si vous utilisez les notifications de vues pour planifier vos relances, les vues de bots sont activement nuisibles. Vous appelez un prospect "pendant qu'il consulte votre présentation" alors qu'il n'a pas encore ouvert son e-mail. Vous paraissez agressif au lieu d'attentif. Et avec la réécriture d'URL, même le timing est trompeur : la session du bot démarre au même moment que la vraie.
Pourquoi la détection standard des bots ne fonctionne pas
L'approche standard, qui consiste à vérifier les agents utilisateurs par rapport à une liste de bots connus, attrape les bots d'aperçu de liens et les robots d'indexation, mais manque complètement les scanners de sécurité email. SafeLinks utilise délibérément des agents utilisateurs réalistes, précisément pour éviter d'être identifié, car les pages de phishing qui détectent les bots servent un contenu différent de celui qu'elles servent aux vrais utilisateurs.
La limitation de débit par IP ne fonctionne pas non plus. SafeLinks effectue une rotation à travers un pool d'IP de datacenters Azure, de sorte que chaque analyse provient d'une adresse différente. Vous ne pouvez pas bloquer par IP sans bloquer les utilisateurs légitimes sur des VPN d'entreprise.
Le fingerprinting du navigateur (canvas, WebGL, énumération des polices) ne fonctionne pas car SafeLinks exécute un navigateur complet basé sur Chromium. Son empreinte est indiscernable d'une installation Chrome réelle.
Notre solution : trois couches de détection
Nous avons construit un système de détection qui identifie les scanners de sécurité email sans bloquer les utilisateurs légitimes, y compris ceux sur des VPN et proxys d'entreprise.
Voici comment le trafic transite à travers les trois couches. Survolez n'importe quel nœud pour suivre son parcours :
Couche 1 : Correspondance de l'agent utilisateur
La partie la plus directe. Nous vérifions les requêtes entrantes par rapport à plus de 60 modèles de bots connus : bots d'aperçu de liens, robots d'indexation, navigateurs headless, bibliothèques client HTTP. Si une requête s'identifie comme Slackbot ou python-requests, nous la rejetons immédiatement. Aucune session n'est créée.
Cela attrape environ 40 % du trafic de bots. Les 40 % les plus faciles.
Couche 2 : Détection des IP de datacenter
Les scanners de sécurité email usurpent leur agent utilisateur, mais ils ne peuvent pas dissimuler d'où ils opèrent. SafeLinks fonctionne depuis les datacenters Azure. Proofpoint tourne sur AWS. Ce sont des plages IP connues de fournisseurs d'hébergement.
Lorsqu'un visiteur ouvre un lien partagé, nous vérifions son IP auprès d'un service de géolocalisation qui indique si l'IP appartient à un fournisseur d'hébergement. Si c'est le cas, la session est marquée comme bot.
Cela attrape la majorité du trafic des scanners de sécurité email. Un visiteur se connectant depuis "Quincy, Washington" sur une IP Microsoft Azure à 2 heures du matin n'est presque certainement pas votre prospect en train de lire votre devis.
Il y a une subtilité ici : nous ne bloquons pas ces sessions. Nous créons l'enregistrement de vue mais le marquons comme bot, l'excluons des statistiques et ne vous envoyons pas de notification. Cela nous permet d'auditer les faux positifs et donne aux utilisateurs la possibilité d'inspecter les sessions de bots s'ils souhaitent enquêter.
Et les utilisateurs VPN ?
Les utilisateurs de VPN d'entreprise transitent parfois par des IP de datacenter, ce qui signifie que la couche 2 pourrait marquer un vrai utilisateur comme bot. C'est pourquoi la couche 3 existe : elle offre aux humains un moyen de "prouver" qu'ils sont réels, même si leur IP ressemble à celle d'un datacenter.
Couche 3 : Confirmation humaine basée sur les gestes
C'est la couche critique. Elle repose sur une observation simple : les vrais humains interagissent physiquement avec la page. Les bots non, ou quand ils le font, leurs interactions ont une signature distinctive.
Lorsqu'une session est initialement marquée comme bot (par la couche 2), nous ne la comptabilisons pas comme une vraie vue. À la place, nous surveillons les interactions humaines authentiques :
Ce que nous surveillons : Les mouvements de souris, les événements tactiles, les saisies clavier et l'activité de défilement.
Ce que nous ignorons : La navigation entre pages, les clics sur les liens et les téléchargements. C'est contre-intuitif : ces actions semblent être de forts signaux de comportement humain. Mais SafeLinks navigue à travers plus de 6 pages de chaque présentation qu'il analyse. Les navigateurs headless comme Puppeteer peuvent programmatiquement cliquer sur des boutons et déclencher des téléchargements. Ces actions peuvent être simulées trivialement. Les événements de périphériques d'entrée de bas niveau sont beaucoup plus difficiles à synthétiser de manière convaincante.
La fenêtre de 3 secondes : Nous ignorons tous les gestes dans les 3 premières secondes après le chargement de la page. SafeLinks et Proofpoint déclenchent leurs événements synthétiques presque immédiatement, dans les 500 millisecondes suivant le chargement de la page. Les vrais humains mettent au moins 3 secondes pour s'orienter et commencer à interagir. Ce simple seuil temporel élimine la majorité du bruit des événements synthétiques.
Analyse des mouvements de souris : Lorsque nous détectons un mouvement de souris après la fenêtre de 3 secondes, nous enregistrons la trajectoire, les coordonnées et les horodatages de jusqu'à 20 événements de mouvement. Les mouvements de souris générés par les bots suivent des trajectoires géométriques (lignes parfaitement droites, cercles exacts) ou déclenchent un seul événement. Les mouvements de souris humains présentent une accélération et une décélération organiques, de légères courbes et des micro-corrections.
Lorsqu'un geste authentique est détecté, la session est atomiquement "promue" de bot à réelle. À ce moment-là, et seulement à ce moment-là, le compteur de vues s'incrémente et vous recevez une notification.
Le timing est crucial
L'ensemble du système est conçu autour d'une condition de concurrence spécifique : que se passe-t-il lorsqu'un vrai utilisateur ouvre un lien, déplace sa souris une fois, puis ferme immédiatement l'onglet ?
La requête de confirmation pourrait ne pas aboutir avant la fermeture de l'onglet. Les navigateurs annulent les requêtes fetch() en cours lors de la navigation. Nous utilisons donc sendBeacon(), une API du navigateur spécifiquement conçue pour les requêtes "fire-and-forget" qui survivent à la fermeture de page, comme solution de secours. Le beacon final transporte les données de confirmation ainsi que les métriques d'engagement de la session.
Côté serveur, la promotion est atomique : une seule mise à jour SQL qui ne réussit que si la session n'a pas déjà été promue. Cela empêche le double comptage lorsque la confirmation régulière et le beacon de secours arrivent tous les deux.
Ce que cela signifie pour vos statistiques
L'impact pratique est significatif. Lors de nos tests auprès d'équipes commerciales orientées entreprise, 15 à 40 % des vues apparentes de présentations étaient des sessions de bots, principalement de SafeLinks et Proofpoint. Pour les équipes vendant à de grandes entreprises avec des politiques de sécurité email strictes, le chiffre était encore plus élevé.
Sans filtrage :
- Les compteurs de vues sont gonflés de 15 à 40 %
- Les prospects "les plus engagés" sont peut-être ceux dont la sécurité email est la plus agressive
- Le timing des vues n'est pas fiable : vous pensez que quelqu'un a consulté votre présentation à 14h alors que le scanner de sécurité l'a ouvert à 13h58
- Les signaux de relance ne sont que du bruit
Avec filtrage :
- Chaque vue représente une vraie personne qui a réellement consulté votre contenu, vous pouvez voir qui a réellement consulté votre proposition
- Les métriques d'engagement (temps passé, pages consultées, taux de completion) reflètent un intérêt authentique
- Les notifications de vues se déclenchent lorsqu'un humain est activement engagé, pas lorsqu'un bot effectue une pré-analyse
Vérifier les sessions de bots dans HummingDeck
Le flux d'activité inclut un filtre "Afficher les sessions de bots" qui vous permet d'inspecter les sessions filtrées. Utilisez-le pour vérifier que le système fonctionne correctement pour vos prospects spécifiques. Si vous voyez un visiteur légitime marqué comme bot, la couche de confirmation par geste devrait le promouvoir dès qu'il interagit avec la page. Si ce n'est pas le cas, contactez le support.
La leçon plus large
L'analyse de sécurité des e-mails ne va pas disparaître. Elle devient de plus en plus approfondie. Microsoft et Google étendent l'analyse automatisée des liens à mesure que les attaques de phishing deviennent plus sophistiquées. Toute plateforme d'analyse qui s'appuie sur les chargements de page comme indicateur de vues humaines deviendra de plus en plus inexacte. Lors de l'évaluation d'outils de suivi de propositions, la détection des bots devrait être une exigence non négociable. Les mêmes bots qui gonflent les vues de présentations falsifient aussi les taux d'ouverture d'email.
Le signal dont vous avez besoin n'est pas "mon lien a-t-il été ouvert." C'est "un humain a-t-il interagi avec mon contenu." Cela nécessite de détecter la différence, et la différence réside dans les gestes, pas dans le chargement de page. Si vous êtes en levée de fonds et que vous vous appuyez sur les analytics de deck pour prioriser vos relances, consultez notre guide sur comment savoir si les investisseurs lisent vraiment votre pitch deck pour les données à l'appui.