Vous partagez un lien de proposition avec un prospect. Deux minutes plus tard, votre outil de suivi indique qu'il l'a ouvert, a fait defiler six pages et a passe 30 secondes sur chacune.
Vous envoyez immediatement 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 passe : le scanner de securite email de son entreprise a ouvert votre lien avant lui. La "vue" etait un bot. Et a moins que votre plateforme d'analyse ne gere specifiquement ce cas, vous ne pouvez pas faire la difference.
Ce n'est pas un cas de figure rare. Cela se produit sur pratiquement chaque e-mail envoye a des destinataires en entreprise utilisant Microsoft 365 ou Google Workspace.
Les bots qui gonflent vos statistiques
Il existe trois categories de trafic automatise qui frappent les liens de presentations partagees :
Les bots d'apercu de liens
Lorsque vous collez un lien dans Slack, LinkedIn, Twitter ou iMessage, un bot recupere immediatement la page pour generer une carte d'apercu. Ces requetes proviennent d'agents utilisateurs identifiables — Slackbot-LinkExpanding, LinkedInBot, Twitterbot. Ils sont faciles a detecter et a filtrer. La plupart des outils de suivi les gerent correctement.
Les robots d'indexation
Googlebot, Bingbot et leurs variantes indexent regulierement le contenu accessible au public. Ils s'identifient egalement ouvertement et sont simples a filtrer. Si vos liens partages sont derriere une authentification ou utilisent des slugs uniques, les robots d'indexation les trouvent rarement de toute facon.
Les scanners de securite email
C'est la categorie 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 role est de detecter les pages de phishing et les logiciels malveillants. Pour cela, ils ouvrent reellement le lien, chargent la page et, dans de nombreux cas, naviguent a travers son contenu.
Ce qui les rend presque impossibles a distinguer des vrais utilisateurs :
- Agents utilisateurs usurpes. SafeLinks ne s'annonce pas comme un bot. Il utilise de vrais agents utilisateurs de navigateur — des chaines comme "Chrome 120 sur Windows 11" ou meme des identifiants d'appareils mobiles comme "itel A27 Android." Votre serveur voit ce qui ressemble a une visite de navigateur legitime.
- Navigation dans les pages. SafeLinks ne se contente pas de charger la premiere page. Il navigue a travers environ 6 pages de votre presentation, quel que soit le nombre total de pages. Proofpoint effectue une analyse multi-pages similaire.
- Timing realiste. Ces sessions durent de 22 a 48 secondes. Elles ne parcourent pas instantanement comme un scraper rudimentaire — le timing semble plausible pour une consultation rapide.
- Evenements DOM synthetiques. Certains scanners declenchent des evenements JavaScript — des defilements programmatiques, des simulations de toucher, voire des evenements de clic — pour activer d'eventuels scripts malveillants caches derriere une interaction utilisateur.
Le resultat net : chaque fois que vous envoyez un lien de presentation par e-mail a quelqu'un dans une entreprise utilisant Microsoft 365 (c'est-a-dire la majorite de vos prospects en entreprise), vous obtenez une fausse "vue" qui ressemble a une vraie. Parfois deux — une de la pile de securite de l'expediteur et une de celle du destinataire.
Voici comment une session de bot SafeLinks se compare a celle d'un vrai lecteur humain, cote a cote :
La reecriture d'URL aggrave le probleme
Certains outils de securite ne se contentent pas de pre-analyser les liens — ils les reecrivent entierement. 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 meme avec ses reecritures 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 reecrite par SafeLinks, qui transite d'abord par le proxy de Microsoft — et le proxy de Microsoft ouvre votre page pour la re-analyser a ce moment-la. Ensuite, il redirige le navigateur de l'utilisateur vers votre page reelle.
Le resultat : l'analyse du bot et la vraie visite se produisent simultanement. Le scanner de securite ouvre votre presentation depuis une IP de datacenter a la meme seconde exacte ou 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 gonfles), soit vous risquez de filtrer la vraie (sous-comptage).
C'est le scenario le plus difficile a gerer correctement. L'analyse pre-livraison est facile a identifier isolement — elle arrive quelques minutes avant que quiconque ne clique. Mais la re-analyse au moment du clic arrive en meme temps que le vrai utilisateur, depuis une IP differente, avec un agent utilisateur different, creant une session separee qui chevauche la session legitime.
Le piege 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 presentation" alors qu'il n'a pas encore ouvert son e-mail. Vous paraissez agressif au lieu d'attentif. Et avec la reecriture d'URL, meme le timing est trompeur — la session du bot demarre au meme moment que la vraie.
Pourquoi la detection standard des bots ne fonctionne pas
L'approche standard — verifier les agents utilisateurs par rapport a une liste de bots connus — attrape les bots d'apercu de liens et les robots d'indexation, mais manque completement les scanners de securite email. SafeLinks utilise deliberement des agents utilisateurs realistes, precisement pour eviter d'etre identifie, car les pages de phishing qui detectent les bots servent un contenu different de celui qu'elles servent aux vrais utilisateurs.
La limitation de debit par IP ne fonctionne pas non plus. SafeLinks effectue une rotation a travers un pool d'IP de datacenters Azure, de sorte que chaque analyse provient d'une adresse differente. Vous ne pouvez pas bloquer par IP sans bloquer les utilisateurs legitimes sur des VPN d'entreprise.
Le fingerprinting du navigateur (canvas, WebGL, enumeration des polices) ne fonctionne pas car SafeLinks execute un navigateur complet base sur Chromium. Son empreinte est indiscernable d'une installation Chrome reelle.
Notre solution : trois couches de detection
Nous avons construit un systeme de detection qui identifie les scanners de securite email sans bloquer les utilisateurs legitimes — y compris ceux sur des VPN et proxys d'entreprise.
Voici comment le trafic transite a travers les trois couches. Survolez n'importe quel noeud pour suivre son parcours :
Couche 1 : Correspondance de l'agent utilisateur
La partie la plus directe. Nous verifions les requetes entrantes par rapport a plus de 60 modeles de bots connus — bots d'apercu de liens, robots d'indexation, navigateurs headless, bibliotheques client HTTP. Si une requete s'identifie comme Slackbot ou python-requests, nous la rejetons immediatement. Aucune session n'est creee.
Cela attrape environ 40 % du trafic de bots. Les 40 % les plus faciles.
Couche 2 : Detection des IP de datacenter
Les scanners de securite email usurpent leur agent utilisateur, mais ils ne peuvent pas dissimuler d'ou ils operent. SafeLinks fonctionne depuis les datacenters Azure. Proofpoint tourne sur AWS. Ce sont des plages IP connues de fournisseurs d'hebergement.
Lorsqu'un visiteur ouvre un lien partage, nous verifions son IP aupres d'un service de geolocalisation qui indique si l'IP appartient a un fournisseur d'hebergement. Si c'est le cas, la session est marquee comme bot.
Cela attrape la majorite du trafic des scanners de securite email. Un visiteur se connectant depuis "Quincy, Washington" sur une IP Microsoft Azure a 2 heures du matin n'est presque certainement pas votre prospect en train de lire votre proposition.
Il y a une subtilite ici : nous ne bloquons pas ces sessions. Nous creons 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 possibilite d'inspecter les sessions de bots s'ils souhaitent enqueter.
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 reels, meme si leur IP ressemble a celle d'un datacenter.
Couche 3 : Confirmation humaine basee 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 marquee comme bot (par la couche 2), nous ne la comptabilisons pas comme une vraie vue. A la place, nous surveillons les interactions humaines authentiques :
Ce que nous surveillons : Les mouvements de souris, les evenements tactiles, les saisies clavier et l'activite de defilement.
Ce que nous ignorons : La navigation entre pages, les clics sur les liens et les telechargements. C'est contre-intuitif — ces actions semblent etre de forts signaux de comportement humain. Mais SafeLinks navigue a travers plus de 6 pages de chaque presentation qu'il analyse. Les navigateurs headless comme Puppeteer peuvent programmatiquement cliquer sur des boutons et declencher des telechargements. Ces actions peuvent etre simulees trivialement. Les evenements de peripheriques d'entree de bas niveau sont beaucoup plus difficiles a synthetiser de maniere convaincante.
La fenetre de 3 secondes : Nous ignorons tous les gestes dans les 3 premieres secondes apres le chargement de la page. SafeLinks et Proofpoint declenchent leurs evenements synthetiques presque immediatement — dans les 500 millisecondes suivant le chargement de la page. Les vrais humains mettent au moins 3 secondes pour s'orienter et commencer a interagir. Ce simple seuil temporel elimine la majorite du bruit des evenements synthetiques.
Analyse des mouvements de souris : Lorsque nous detectons un mouvement de souris apres la fenetre de 3 secondes, nous enregistrons la trajectoire — les coordonnees et les horodatages de jusqu'a 20 evenements de mouvement. Les mouvements de souris generes par les bots suivent des trajectoires geometriques (lignes parfaitement droites, cercles exacts) ou declenchent un seul evenement. Les mouvements de souris humains presentent une acceleration et une deceleration organiques, de legeres courbes et des micro-corrections.
Lorsqu'un geste authentique est detecte, la session est atomiquement "promue" de bot a reelle. A ce moment-la — et seulement a ce moment-la — le compteur de vues s'incremente et vous recevez une notification.
Le timing est crucial
L'ensemble du systeme est concu autour d'une condition de concurrence specifique : que se passe-t-il lorsqu'un vrai utilisateur ouvre un lien, deplace sa souris une fois, puis ferme immediatement l'onglet ?
La requete de confirmation pourrait ne pas aboutir avant la fermeture de l'onglet. Les navigateurs annulent les requetes fetch() en cours lors de la navigation. Nous utilisons donc sendBeacon() — une API du navigateur specifiquement concue pour les requetes "fire-and-forget" qui survivent a la fermeture de page — comme solution de secours. Le beacon final transporte les donnees de confirmation ainsi que les metriques d'engagement de la session.
Cote serveur, la promotion est atomique : une seule mise a jour SQL qui ne reussit que si la session n'a pas deja ete promue. Cela empeche le double comptage lorsque la confirmation reguliere 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 aupres d'equipes commerciales orientees entreprise, 15 a 40 % des vues apparentes de presentations etaient des sessions de bots — principalement de SafeLinks et Proofpoint. Pour les equipes vendant a de grandes entreprises avec des politiques de securite email strictes, le chiffre etait encore plus eleve.
Sans filtrage :
- Les compteurs de vues sont gonfles de 15 a 40 %
- Les prospects "les plus engages" sont peut-etre ceux dont la securite email est la plus agressive
- Le timing des vues n'est pas fiable — vous pensez que quelqu'un a consulte votre presentation a 14h alors que le scanner de securite l'a ouverte a 13h58
- Les signaux de relance ne sont que du bruit
Avec filtrage :
- Chaque vue represente une vraie personne qui a reellement consulte votre contenu
- Les metriques d'engagement (temps passe, pages consultees, taux de completion) refletent un interet authentique
- Les notifications de vues se declenchent lorsqu'un humain est activement engage, pas lorsqu'un bot effectue une pre-analyse
Verifier les sessions de bots dans HummingDeck
Le flux d'activite inclut un filtre "Afficher les sessions de bots" qui vous permet d'inspecter les sessions filtrees. Utilisez-le pour verifier que le systeme fonctionne correctement pour vos prospects specifiques — si vous voyez un visiteur legitime marque comme bot, la couche de confirmation par geste devrait le promouvoir des qu'il interagit avec la page. Si ce n'est pas le cas, contactez le support.
La lecon plus large
L'analyse de securite des e-mails ne va pas disparaitre — elle devient de plus en plus approfondie. Microsoft et Google etendent l'analyse automatisee des liens a mesure que les attaques de phishing deviennent plus sophistiquees. Toute plateforme d'analyse qui s'appuie sur les chargements de page comme indicateur de vues humaines deviendra de plus en plus inexacte.
Le signal dont vous avez besoin n'est pas "mon lien a-t-il ete ouvert." C'est "un humain a-t-il interagi avec mon contenu." Cela necessite de detecter la difference — et la difference reside dans les gestes, pas dans le chargement de page.