Norton Genie, McAfee Scam Detector, Malwarebytes Scam Guard : ces scanners IA grand public promettent de repérer une arnaque avant le clic. Aucun n’empêche un message frauduleux d’atteindre la boîte de réception, ils l’analysent après coup, sur demande de l’utilisateur qui a déjà ouvert l’email. Ce qui bloque le message en amont reste une autre couche : l’authentification DNS (SPF, DKIM, DMARC) combinée aux filtres natifs de Gmail et Outlook, qui interceptent plus de 99,9% du volume avant tout affichage à l’écran. Pour un postmaster qui vient de voir son IP atterrir sur le SBL Spamhaus après une vague de plaintes liée à une usurpation de domaine, la distinction n’est pas théorique. Elle détermine où investir en premier.
Pourquoi le phishing généré par IA passe entre les mailles des scanners IA
Un message qui cite le bon nom du directeur financier, la bonne référence de facture, un ton mesuré, zéro faute. Rien à voir avec les fautes d’orthographe et les mises en page grossières qui trahissaient le phishing d’il y a cinq ans. Keepnet Labs a mesuré que 82,6% des emails de phishing détectés entre septembre 2024 et février 2025 utilisaient une forme de génération par IA, une hausse de 53,5% sur un an (Keepnet Labs, 2025). Le rapport Microsoft Digital Defense 2025 chiffre l’écart d’efficacité : un phishing entièrement généré et automatisé par IA obtient 54% de taux de clic contre 12% pour un leurre écrit à la main (Microsoft, 2025). Une étude publiée sur arXiv en novembre 2024 documente le mécanisme précis : sur le jeu de données Nigerian Fraud, Gmail Spam Filter atteint 97,88% de précision, SpamAssassin 96,75%, Proofpoint 95,88%. Ces taux chutent nettement dès que les mêmes emails sont reformulés par un grand modèle de langage, parce que la reformulation efface les marqueurs textuels sur lesquels les classifieurs s’appuient (arXiv, novembre 2024).
Les taux de détection chutent nettement lorsque les emails de phishing sont reformulés par un grand modèle de langage, y compris face aux filtres de Gmail, SpamAssassin et Proofpoint évalués dans l’étude.
Un scanner IA grand public repose sur le même principe de classification qu’un filtre anti-spam classique, appliqué à un seul message isolé plutôt qu’à un flux entier. Il hérite du même angle mort face à un texte volontairement poli par une IA pour éviter les déclencheurs habituels.
Les couches qui interceptent un email frauduleux, dans l’ordre
Configurer DMARC est un autre sujet. Ici, la question porte sur la place exacte qu’occupe un scanner IA grand public dans la chaîne d’interception, et sur le volume qu’il traite réellement une fois les couches précédentes passées.
- L’authentification DNS. SPF, DKIM et l’alignement p=reject de DMARC valident que le message part bien du domaine annoncé, avant même l’ouverture complète de la session SMTP.
- Le filtre natif du fournisseur. Le système RETVec de Google score le contenu, les liens et le comportement d’envoi ; côté Microsoft 365, Defender applique un pipeline équivalent sur les mêmes signaux.
- La passerelle de sécurité côté entreprise. Quand elle existe, elle rejoue une analyse indépendante sur les messages déjà passés les deux premiers filtres.
- Le scanner IA grand public. Installé par l’utilisateur final, il n’intervient qu’en dernier recours, sur un message déjà présent dans la boîte de réception.
Un billet publié par Google en 2024 illustre l’ampleur de la première couche : les exigences d’authentification imposées aux expéditeurs volumineux ont fait chuter de 65% les messages non authentifiés reçus par les utilisateurs Gmail, soit 265 milliards de messages non authentifiés en moins sur l’année (Google, 2024). RETVec, de son côté, a fait progresser la détection de spam de 38% tout en réduisant les faux positifs de 19,4%, un compromis rarement atteint par les outils grand public qui privilégient le rappel au détriment de la précision.
Ce que l’authentification email bloque réellement et son angle mort
La couche DNS reste la moins déployée des quatre. Seulement 9% des domaines analysés dans le monde appliquent un DMARC en p=reject pleinement actif début 2026 (DMARC Report, 2026). La majorité des domaines qui publient un enregistrement DMARC restent en p=none, une politique de simple observation qui ne bloque rien et se contente d’alimenter des rapports agrégés.
Cette couche a un angle mort mesuré : Microsoft a recensé environ 10,7 millions d’attaques BEC (Business Email Compromise) au premier trimestre 2026, en hausse de 26% rien qu’en mars (Sendmarc, 2026). Mais le chiffre inverse compte aussi : quand l’attaque part d’un compte Microsoft 365 ou Google Workspace réellement compromis, via du credential stuffing ou un phishing antérieur réussi, le message sort avec un SPF valide et un DKIM aligné ; DMARC, en bout de chaîne, ne voit rien d’anormal non plus, parce qu’il vient d’une infrastructure légitime. Le scanner IA grand public ne capte rien de suspect non plus, la plupart du temps, puisque le texte ne contient aucun des marqueurs qu’il a appris à repérer.
Ce que ratent les détecteurs IA grand public
Norton Genie identifie bien les faux avis de livraison et les fausses cartes cadeaux, des formats répétitifs, proches de ceux sur lesquels il a été entraîné. Une revue publiée par Techlicious note en revanche que des scénarios de social engineering plus subtils, comme une prise de contact anodine du type « libre pour un café ? » qui prépare une escroquerie sentimentale, passent au travers de l’analyse (Techlicious, 2025). Les avis utilisateurs restent partagés sur les stores mobiles, certains jugeant l’outil utile sur les cas évidents et inefficace sur tout le reste.
La limite tient à la nature de l’analyse. Un scanner grand public juge un message isolé, sans le contexte de l’historique d’expédition, de la réputation d’IP ou du tier de réputation associé au domaine expéditeur. Il n’a pas accès à ce que voit un MTA côté réception.
Le complaint rate, signal que ni DMARC ni un scanner IA ne remplacent
Un domaine usurpé pour une campagne de phishing se repère souvent avant même qu’un employé ouvre un email suspect : une hausse du complaint rate, le taux de plainte mesuré côté webmail, sur des campagnes légitimes qui partagent la même réputation d’IP. Les rapports agrégés DMARC, lus via un outil comme parsedmarc, exposent le champ policy_evaluated et sa valeur disposition (none, quarantine ou, plus rarement, reject) pour chaque source déclarée : une source qui envoie sans jamais apparaître dans ces rapports mérite une vérification immédiate. Côté Microsoft 365, le tableau SNDS (Smart Network Data Services) donne un signal équivalent sur la réputation de l’IP.
Avant qu’un incident de ce type ne dégénère en listage SBL, la vérification la plus simple reste la plus négligée : passer sa propre liste d’envoi au crible pour repérer les adresses mortes, les pièges à spam et, plus rarement, des doublons qui gonflent artificiellement le volume et masquent un pic de plaintes réel derrière un taux de rejet déjà élevé.
Vérifier son propre DMARC avant l’incident coûte moins cher que le découvrir après un listage SBL.
