Guide de déploiement pratique d'une proxy d'intelligence artificielle pour la détection des emails de phishing : 2026 analyse complète pour la sélection et le déploiement d'entreprises
De la stratégie SPF/DKIM/DMARC à l'analyse sémantique à grande échelle avec des modèles, une évaluation approfondie du processus de développement d'un moteur de détection de phishing sous contrôle d'intelligence artificielle dans un environnement réel de menace
Daniel Nikulshyn
Editor
Vue d'ensemble des menaces
Pourquoi le phishing reste la principale menace en 2026
Bien qu'il y ait plus de 20 ans d'histoire dans l'industrie de la sécurité des courriels, le phishing (phishing) reste la principale entrée d'attaque utilisée par les entreprises pour subir une fuite de données. Selon la publication annuelle du rapport de l'enquête sur les fuites de données (DBIR) de Verizon, l'utilisation de techniques d'ingénierie sociale et la saisie de certificats ont continué à occuper une position de leadership dans les événements de fuite des données au fil des années, tandis que l'électronique est le canal de délivrance le plus courant des attaques de ce type. Selon le Wikipédia, la définition du phishing montre que le principe c'est d'un attaquant qui se fait passer pour une entité crédible et qui incite la victime à lui rendre des certificats, à effectuer des retraits de compte ou à installer un logiciel malveillant. Depuis 2022, la généralisation des modeles de langage génératifs a considérablement diminué le coût de production des contenus du phishing. Les règles empiriques qui recherchaient autrefois les courriels du phishing en fonction des erreurs d'orthographe et de la syntaxe sont en train de perdre leur efficacité — les grands modèles de langage peuvent générer des textes trompeurs avec une syntaxe parfaite et une tonalité adaptée à la culture d'entreprise, et ils peuvent même personnaliser le contenu en fonction des informations publiques des réseaux sociaux des victimes, qui s'appelle le phishing ciblé (spear phishing) et le phishing commercial (BEC, Business Email Compromise). Les BEC sont particulièrement suspect. Le centre de plainte contre les crimes en ligne de l'FBI (IC3) a listé les BEC comme un des types de criminels les plus coûteux des dommages économiques dans ses rapports annuels. Ces attaques se déroulent souvent sans lien ou pièce jointe malveillante, se basant uniquement sur des manipulations sociales pour inciter les employés à effectuer des retraits, ce qui rend caduques les détections basées sur les signatures et la liste noire des URL. C'est à cause de l'émergence de ces attaques 'sans charge utile' que le débat a commencé sur l'implémentation d'agents de détection basés sur des modèles de compréhension sémantiques. Ils se contentent désormais de regarder les liens et pièces jointes, mais en analysent l’intention, les anomalies des relations, et le schéma de langage. C'est sur ce cœur technique que ce guide se focalise.
- Phishing - Wikipédia — La page Wikipédia relative à la définition, au typologie et à l’histoire des piratages par correspondance
- Rapport IC3 de l’FBI — Le rapport annuel du centre deplainte contre les crimes en ligne de l’FBI, contenant des statistiques sur les pertes subies dans des types d’attaques comme le BEC
Bases techniques
L'authentification aux protocoles est la base, et ce n'est pas la fin
Toute solution de détection de phishing sérieuse repose sur trois grands protocoles d'authentification des emails : SPF, DKIM, et DMARC. SPF (Sender Policy Framework) indique dans la base de données DNS lesquels des serveurs sont autorisés à représenter un domaine lors d'une envoi de courriel ; DKIM (DomainKeys Identified Mail) utilise une signature cryptée pour vérifier que l'envoi n'a pas été modifié lors de sa transmission ; DMARC (Domain-based Message Authentication, Reporting and Conformance) précise ensuite les stratégies d'action à suivre en cas d'échec des vérifications SPF et DKIM, ainsi que les rapports de conformité. Le wiki sur DMARC explique que ce protocole, grâce à la 'alignement', s'assure que les noms de domaine des vérifications SPF et DKIM correspondent aux noms de domaine que les utilisateurs voient dans la rubrique 'À' des emails, ce qui empêche les attaques par usurpation de nom de domaine. Google et Yahoo ont commencé à exiger le DMARC pour les nombreux expéditeurs à partir de 2024, ce qui a nettement réduit les attaques par usurpation de nom de domaine. Cependant, ces protocoles ne répondent qu'aux questions 'Qui a le droit d'utiliser ce nom de domaine ?'. Ils sont impuissants face à deux types d'attaques dangereuses: celles qui utilisent un nom de domaine très similaire (comme rn simulant m), et celles qui utilisent les vrais comptes des partenaires pour lancer des attaques, ce qui déjoue toutes les vérifications. Voilà là où s'insèrent les détecteurs de phishing à base d'IA. Ils utilisent les résultats de vérifications comme l'un des nombreux criteres, et non l'unicité de la décision, puis les combinent avec l'analyse des comportements émetteur, l'analyse de l'intention semantique et la visualisation des relations, pour couvrir les lacunes des protocoles d'authentification. Comprendre cet équilibre est la clé pour éviter les malversations lors de l'évaluation des fournisseurs, qui utiliseraient la phrase "Nous soutenons DMARC" comme arme de persuasion.
- DMARC - Wikipedia — Principe de fonctionnement, mécanisme d'alignement et types de stratégies de DMARC
- DKIM - Wikipedia — Détails techniques de la signature cryptée DKIM
L'intérieur des moteurs
Détection d'agents d'intelligence artificielle pour la détection de courriels de phishing : Guide pratique d'application et de déploiement 2026
Les agences modernes de détection de phishing utilisant l'intelligence artificielle sont généralement composées de quatre couches capacitaires. La première couche est traditionnellement un détecteur déterminant : Base de données de confiance URL, Salle de dépannage pour attachements explosifs, comparaison de codes d'empreinte d'attachements — Une partie qui a atteint sa maturité, principalement filtrant les menaces connues. La deuxième couche est caractérisée par l'ingénierie de signalisation avec statistiques et apprentissage automatique, extrayant des centaines de signalisations, telles que la durée de la période de registration du domaine de l'expéditeur,, le premier signe de communication, la divergence des adresses de réponse et d'expédition, ainsi que des caractères unicode cachés. La troisième couche est une percée majeure des dernières années : l'analyse de l'intention sémantique grâce au traitement automatique des langues et aux modèles linguistiques importants. Le moteur ne posera plus la question : "ce lien est-il sûr ?", mais plutôt : "cette courriél est-il en train de m'encourager à faire quelque chose ?". Il peut identifier les pressions de priorités ("complétez le transfert dans les 30 minutes suivantes"), les vêtements d'authenticité (prétendre être le CEO), ainsi que la divergence structurelle de la rhétorique. Les API des modèles de OpenAI, d'Anthropic et d'autres entreprises de même genre rendent précis cette précision sémantique de l'analyse, mais cela introduit également de nouveaux équilibres en termes de coûts, de retard et de confidentialité. La quatrième couche est la représentation graphique et la ligne de base comportementale. L'agent analyse les communications historiques à l'intérieur et à l'extérieur de l'organisation, et créer l'« image comportementale de chaque expéditeur : les périodes d'envoi habituelles, les appareils utilisés, les destinataires de communication, ainsi que les formules habituelles. Quand une courriél déraille (par exemple, le CFO demande un transfert urgent à une adresse IP inconnue à l'aube), le système fournit un score de risque élevé. Ce type de détection de comportement basé sur l'anomalie est particulièrement efficace contre les attaques de phishing de BEC à zéro jour, car elle ne repose pas sur aucun signe connu. Lorsque les professionnels définissent les évaluations, ils devraient se poser les questions suivantes à la fournisseurs : - L'analyse sémantique utilise-t-elle des modèles de règles ou bien des véritables capacités raisonnantes du modèle ? - Y a-t-il besoin de quel temps de formation pour la ligne de base comportementale ? - Comment les fausses alertes sont-elles renvoyées dans le modèle ? Ces réponses détermineront d'une manière plus précise le niveau réel du produit.
- Documentation de la plateforme OpenAI — Documentation officielle d'API des modèles utilisés pour l'analyse sémantique de l'intention
- Logiciels anti-phishing sur Wikipédia — Classification technique et méthodes de détection des logiciels anti-phishing
Décision d'architecture
Gateway vs API : une décision d'architecture
Lors du choix, la divergence la plus fondamentale réside dans le point de détection. Les solutions de sécurité de messagerie traditionnelles (SEG, Secure Email Gateway) sont déployées à l'entrée du flux de messagerie et acheminent toutes les messageries entrantes vers le service de détection avant de les envoyer dans la boîte mail. Ce modèle est plus efficace et ne dépend pas de l'API du service de messagerie, mais il a pour inconvénient d'être incapable de détecter les modifications apportées après l'envoi des messageries (comme des liens activés avec un retard) et difficile à analyser pour des abus transversaux. Il existe une autre méthode récente de niveaux API (ICES, Integrated Cloud Email Security) qui permet, via Microsoft Graph ou l'API de Google Workspace, de lire directement la messagerie, pour effectuer des analyses postérieures. Voici les avantages : le déploiement prend quelques minutes, il n'est plus nécessaire de modifier les enregistrements MX, et il est possible de visualiser le flux de messagerie interne et de soutenir la retenue automatique (claw-back) des messageries envoyées après l'envoi. Microsoft Defender for Office 365 et la sécurité native de Google Workspace constituent des représentations de cette approche. Ces architectures ne se contredisent pas. De nombreuses organisations mûres adoptent une stratégie de défense 'réseau de filtre grossier + API en évaluation fine' de défense en profondeur. Les professionnels du domaine doivent peser les avantages : les solutions de réseau sont plus contrôlables dans les scénarios de retard, mais nécessitent plus de maintenance ; les solutions API sont plus légères et offrent une visibilité plus forte, mais sont limitées par les taux et les droits de l'API, et la retenue automatique implique que les messageries malveillantes ont eu un bref séjour dans la boîte mail des utilisateurs. Un point d'évaluation souvent négligé est la question de la conservation des données et de la protection des données. Les solutions de niveau API nécessitent l'autorisation aux prestataires tiers pour lire la messagerie dans sa totalité, ce qui constitue pour les entreprises soumises à la réglementation GDPR ou à une réglementation sectorielle un lourd de décision. C'est nécessaire de confirmer la localisation du traitement des données par le fournisseur, la durée de conservation et l'utilisation potentiel des contenus des messageries pour entraîner des modèles génériques.
- Microsoft Defender for Office 365 — Le document officiel de la sécurité du Microsoft Office
- Filtrage de messagerie - Wikipedia — La problématique technique d'un gateway de sécurité de messagerie
Méthodologie de sélection
Évaluation du référentiel : Ce que les professionnels doivent mesurer, comment le faire
Chaque fournisseur prétend avoir une détection à plus de 99% mais ce chiffre est sans signification en dehors du jeu d'entraînement. Je recommande à tous les équipes de sécurité de créer un référentiel d'évaluation à quatre quadrants : capacité de détection, charge de mémoire fausse, expérience de gestion et coût d'exploitation total. Dans la dimension de détection, ce n'est pas la précision globale qui compte, mais la performance de type : rappel des attaques par phishing avec lien malveillant, rappel des logiciels malveillants attachés, rappel des BEC (Business Email Compromise) textuels, rappel des attaques de phishing internes. La pratique la plus précieuse est de réaliser un test de rappel sur des échantillons vrais (dénudés) de ceux qu'on a manqué dans le passé plutôt que de dépendre des échantillons de démonstration fournis par le fournisseur. Il est impératif également de demander des tests parallèles de 30 jours (mode shadow) afin de faire scorer le nouveau moteur sans perturber la production et de le comparer aux résultats réels. Le faux positif est la principale entité de coûts qui est souvent sous-estimée. Un moteur qui paraît avoir une fausse alerte de moins de 0,1% signifie que lorsqu'on traite des millions d'e-mails par jour, il faut considérer que chaque journée, 1 000 e-mails légitimes sont isolés à tort. Cela détruit complètement les SOCs et érode la confiance des utilisateurs dans le système. Lors de l'évaluation, il faut conserver le temps de gestion de chaque faux positif et tester la rapidité à laquelle le cycle de retour d'information du fournisseur est efficace. La dimension de gestion et de coût comprend : la granularité de la stratégie de configuration et sa lisibilité, la profondeur d'intégration avec le SIEM et le SOAR, la disponibilité de l'interface d'investigation des événements et le modèle de tarification (par adresse e-mail, volume de courrier ou siège). Les coûts cachés apparaissent en général dans les services professionnels, les cycles d'optimisation et le souscription de sources de renseignement sur les menaces supplémentaires. Il faut intégrer tous ces coûts dans la décision pour éviter de constater par la suite que la TCO réelle dépasse le budget initial.
- Précision et rappel - Wikipedia — Comprendre l'équilibre entre la précision et le rappel du système de détection
Le jeu du pour et contre
La réalité contraire : lorsque les attaquants utilisent eux aussi l'intelligence artificielle
La détection de phishing est en réalité une forme continue du jeu du pour et contre. Les attaquants ont commencé à cibler les détecteurs AI en concevant des moyens de les contourner : en intégrant dans les courriers des textes 'prompt injection' masqués pour manipuler les analyses basées sur les LLM ; en utilisant des images pour éviter les scannings textuels ou en utilisant des liens de partage de fichiers (Google Drive, SharePoint) comme tremplins pour révéler les contenus malveillants à plusieurs étapes de la cascade. L'article de Wikpedia sur l'apprentissage contre l'adversité (adversarial machine learning) souligne que tout système de détection basé sur des modèles est vulnérable à des échantillons contre-adversaires bien conçus. Cela signifie que les fournisseurs qui n'adoptent qu'une unique grande modèle risquent d'être attaqués de manière ciblée. La stratégie solide consiste donc à intégrer plusieurs moteurs, afin que chaque signal ne soit pas décisif en termes d'appel à une décision finale. Autre réalité qui est souvent négligée : 'fatigue de détection'. Lorsque les systèmes alertent trop fréquemment à des risques, les utilisateurs en viennent à prendre ces alertes comme des phénomènes ordinaires et finissent pour s'y habituer. Par conséquent, les produits exceptionnels évaluent les risques pour faire des interventions ferme et stratégique sur les courriers les plus dangereux, tandis que les courriers de faible ou moyen danger leur fournissent des avertissements légers. Ce qui se détermine alors réellement par la capacité du produit à allouer les attentions des utilisateurs aux cas critiques. Bien sûr l'équipement informatique ne peut jamais se remplacer par la capacité d'analyse de l'humain. Même des agents AI les plus avancés doivent être associés à une simulation d'attaque régulière de phishing et un entraînement en sécurité des employés. L'objectif doit être de positionner les agents AI comme des outils d'assistance pour réduire le volume d'e-mails dangereux à l'attention des utilisateurs et leur fournir une analyse contextualisée, et non comme le 'cure pour tous' les phishing.
- Apprentissage contre l'adversité - Wikipedia — Sur les menaces contre les systèmes de détection provenant d'un apprentissage contre-adversaire
- Anthropic Sécurité — Recherche sur la manipulation des modèles par insertion de prompt et sur la sécurité des modèles
Guide d'implémentation
Secteur d'information et d'événements de gestion sécurisée
Sur la base de plusieurs déployements, je recommande de décomposer la mise en œuvre d'un agent de détection de phishing basé sur l'intelligence artificielle en trois phases de 30 jours. La première phase de 30 jours est celle du plancher et de la phase de test parallèle : sans modifier le flux de courrier existant, se connecter en modeombre au nouveau moteur, collecter ses évaluations sur courrier réel, et comparer les résultats avec les données actuelles, quantifier les nouvelles découvertes et les fausses alertes. À la même période, finaliser les contrôles de santé SPF/DKIM/DMARC, pour se assurer d'une solide base de certification — beaucoup d'organisations ne découvrent la configuration DMARC de leur organisation qu'en p=none à ce stade. La deuxième phase de 30 jours est celle du dépannage de gris et de l'optimisation des stratégies. Sélectionner un groupe à risque contrôlé où l'on peut mettre en place un interministration forcé en surveillant de près les fausses alertes et en créant un canal de remise rapide. L'objectif principal de cette phase est de déterminer une base de stratégies qui correspond aux besoins concrètes de l'organisation et de mettre en place une mise à jour automatique des procédures de traitement des événements (playbook), afin de déterminer quel niveau d'alerte est traité automatiquement par le système, et quel niveau nécessite une analyse humaine de la part du SOC. La troisième phase de 30 jours est celle de la mise en place totale et de la stabilisation de la maintenance. Connecter l'agent de détection à la plateforme SIEM/SOAR pour permettre le retrait automatique, l'isolement automatique, et le lien avec les bulletins d'événement ; mettre en place un flux normalisé de retour de fausses alertes, afin de garantir que chaque courrier bloqué par erreur puisse être réinjecté rapidement dans le modèle ; et lancer une première campagne de simulations de phishing, afin de vérifier les effets de coopération humaine et informatique réel dans la protection contre les cybermenaces. N'oubliez pas de prévoir un plan de reprise. N'importe quel système dépendant d'API tiers et de modèles est susceptible de défaillir pour une raison de l'entreprise du fournisseur, d'une mise à jour du modèle ou d'une limitation de taux ; définir les stratégies de dégrés d'urgence à l'avance (par exemple, une régression automatique vers des règles déterministes plus conservatrices) peut empêcher que tout accroc à la relation avec le fournisseur n'entraîne une coupure totale de réseau pour la communauté. N'incluez pas ces mesures dans un contrat SLA, ce n'est pas la prévention de la perte, mais la protection des professionnels.
- Security information and event management - Wikipedia — SIEM/SOAR与邮件检测系统联动的背景知识
Ressources
- L'article Phishing de Wikipedia
L'attaque de phishing, son définition, son évolution
- L'article DMARC de Wikipedia
La fonctionnalité du protocole de sécurité du trafic de messagerie et les avantages de son utilisation
- Le service de sécurité de Microsoft 365
Le service de protection intégrée des e-mails et la protection contre les menaces
- Le modèle d'analyse sémantique d'OpenAI
Guide de l'application de l'analyse sémantique à grande échelle à partir d'un modèle API avec un grand nombre de paramètres
- La bibliothèque de recherche du modèle d'attaque d'Anthropic
La recherche sur la sécurité du modèle et les attaques de l'intelligence artificielle
Foire aux questions fréquentes
L'agent AI de détection du phishing peut-il complètement substituer la sécurité traditionnelle de la boîte de messagerie des postes de travail ?
L'agent AI dans sa version API s'est mieux comporté que les BEC et dans les attaques internes de phishing. Mais les dispositifs de sécurité, même en leur absence, sont toujours utiles car il sont en mesure d'entraver la détection des e-mails qui ont été introduits récemment et dans les cas de phishing décalés.
Déploiement du plan d'API : Quels sont les risques sur le plan de la conformité ?
L'objectif de la conformité, c'est de garantir que le fournisseur de services, les données ne soit pas collectées, les durées dans lesquelles ils sont conservés et qu'ils ne sont pas utilisés comme modèle de données. Les sociétés soumises à la règlementation de la protection des données ou des norme doivent déterminer les localisations où se situe l'entreprise, s'assurer qu'un accord DPA a été signé, qu'un avenant a été ajouté et qu'un avenant à l'accord a été ajouté pour indiquer que les données ne seront pas utilisées avec le modèle.
Pourquoi des mesures de sécurité de la messagerie (DMARC) ne peuvent ne pas éviter des attaques de phishing ?
Les attaques de phishing avec une adresse de messagerie qui ressemble à celle d'un fournisseur ou un partenaire ne sont pas détectables car elles ressemblent à des adresses qui ne sont pas fausses et sont donc authentifiées. C'est pour ça qu'une analyse sémantique est nécessaire et indispensable pour faire face au problème de phishing car elle nous permet d'analyser l'intention de l'auteur et de détecter ainsi les faux e-mails.
Le chiffre des détecteurs 99% qui sont déclarés par les fournisseurs : Y a-t-il une confiance dans cette statistique si elle est donné sans évaluation ?
Cette statistique ne représente que rien si elle est donnée sans évaluation car le détecteur doit s'appliquer en utilisant des messages réels comme dans le cas des utilisateurs qui utilisent l'application en temps réel et en utilisant des messages anciens qui n'ont jamais été traités pour évaluer le modèle. L'évaluation doit inclure plusieurs types de messages pour vérifier le modèle.
Comment se pose la mise au point : Quelle sera l'ampleur des erreurs du détecteur en cas de déploiement ?
Cette mesure sera plus importante que vous ne le pensez. Un nombre inférieur de 1‰ d'erreurs de détection dans un million de messages signifie qu'un millier de bons messages sont bloqués au quotidien ce qui pourrait conduire la pertes par le manque de confiance de la sécurité à travers tout le service.
Attente : Le système de détection de phishing ne répond-t-il encore pas ?
Ce type de détection basé sur l'analyse sémantique d'un modèle a un intérêt car il ne dépend pas de la qualité de la forme du message mais il est difficile de le mettre en œuvre et il faudrait donc le mettre en œuvre via la combinaison de plusieurs outils et de plusieurs types différents de modèles
Je suis un fournisseur de services. Comment je puis adapter l'utilisation d'agents dédiés à la détection de phishing pour ma sécurité si j'utilise Microsoft 365/Google Workspace ?
Avant d'investir dans des agents dédiés à la détection de phishing, faites tout pour maximiser le débit de sécurité native de la solution et activer les capacités de sécurité avancées, comme DMARC en mode 'force' ; Si vous avez du risque de BEC élevé ou des exigences de conformité, utilisez les fonctionnalités de détection de phishing intégrées de Microsoft 365/Google Workspace, et en cas de besoin, évaluez la mise en œuvre d'un système dédié comme un programme ICE, qui a désormais un coût moins élevé que jadis.
Faut-il, pour les petites entreprises, procéder au déploiement d'un agent dédiée à la détection de phishing pour se protéger ?
Le déploiement d'un agent dédiée à la détection de phishing n'est pas facile. Il faut donc planifier au long terme. Cela signifie mettre en œuvre un processus en trois étapes au cours desquelles le service sera en mesure de tester et de vérifier le système de détection de phishing au cours de 90 jours.
