30.10.26
IA et cybersécurité : piéger les arnaqueurs13 min de lecture2 684 mots

IA et cybersécurité : piéger les arnaqueurs

Des bots IA occupent les escrocs et collectent des indices. Découvrez leur fonctionnement, leurs limites et les précautions à prendre pour les déployer.

IA cybersécuritébots anti-arnaquelutte contre les cyberescroquerieshoneypot intelligence artificiellecybercriminalité
IA et cybersécurité : piéger les arnaqueurs

Quand l'IA fait perdre leur temps aux cybercriminels

Un appel frauduleux n'est pas seulement une tentative de soutirer de l'argent à une personne. C'est aussi une opération organisée - souvent automatisée - qui peut contacter des centaines de victimes potentielles. À cette échelle, bloquer un numéro après l'autre ne suffit pas. Une autre approche consiste à détourner les escrocs vers de faux interlocuteurs : des systèmes pensés pour les faire rester au téléphone ou dans une conversation en ligne, sans pour autant leur permettre de toucher leur vraie cible.

C'est là que l'intelligence artificielle peut devenir un outil de défense. Des bots conversationnels imitent de « vraies » victimes, tandis que des honeypots (bacs à pièges) cherchent à attirer les attaquants pour observer leurs méthodes. L'idée n'est pas de croire que quelques bots vont « éteindre » les arnaques. Le but est plus modeste et plus concret : réduire la capacité des fraudeurs à agir efficacement, tout en récupérant des informations utiles.

Alors, qu'est-ce que cette stratégie apporte vraiment ? Où est-ce que ça coince, et quels points de vigilance pour une banque, un opérateur télécom ou une équipe de cybersécurité en Europe ? Voici comment évaluer ces outils sans tomber dans le mythe de la solution miracle.

Pourquoi détourner les fraudeurs plutôt que seulement les bloquer ?

Les approches classiques contre la fraude cherchent généralement à repérer puis interrompre une tentative : filtrage d'appels, détection de liens dangereux, signalement d'un compte, blocage d'une transaction. C'est indispensable. Mais il y a un problème d'échelle : les campagnes changent, les numéros évoluent, et une partie du travail est automatisée.

Dans ce contexte, une approche complémentaire consiste à faire perdre du temps aux fraudeurs. Le système ne les laisse pas contacter une personne réelle tout de suite : il les met en relation avec un bot suffisamment crédible pour maintenir l'échange. Chaque minute passée avec un bot, c'est une minute de moins où l'escroc parle à une autre cible. L'intérêt est particulièrement fort quand les criminels utilisent des outils de numérotation automatique ou envoient des messages à grande échelle.

Mais il ne faut pas surestimer l'effet. Si un échange est interrompu après quelques minutes, l'escroc peut avoir d'autres campagnes en parallèle - ou reprendre dès que la conversation s'arrête. Le détournement sert à perturber l'activité, pas à garantir une protection « à vie » pour chaque victime potentielle.

La valeur des renseignements collectés

L'intérêt ne se limite pas au temps perdu. Pendant la conversation, un système artificiel peut aussi faire remonter des indices sur les méthodes : adresse d'un site frauduleux, coordonnées bancaires utilisées pour recevoir l'argent, compte-relais, ou formulation d'un scénario d'arnaque. Pris séparément, ces éléments valent parfois peu. Mais mis bout à bout avec des signalements fiables et transmis aux bons acteurs, ils peuvent aider à repérer des infrastructures ou des tendances.

D'après les informations rapportées par Wired, la société australienne Apate développerait depuis deux ans une plateforme qui détourne des appels et des messages vers des bots. Son fondateur, Dali Kaafar, indique que le système compte environ 350 000 bots et aurait recueilli plus de 250 000 éléments liés à des fraudeurs - URL et informations associées à des comptes intermédiaires, notamment. Ces chiffres proviennent de l'entreprise (et de l'article), et ne constituent pas une mesure indépendante de l'impact sur le nombre d'arnaques évitées.

Cette nuance compte. Le volume de données collectées ne prouve pas, à lui seul, que les informations sont exactes, exploitables ou suffisamment récentes. Les questions à poser sont plutôt : quelle part des données est vérifiée ? Combien de temps faut-il pour les traiter ? Combien de campagnes sont réellement perturbées ? Et quels dommages ont probablement été évités ?

Une stratégie complémentaire, pas un remplacement

Ces dispositifs peuvent compléter la modération des plateformes, les systèmes antifraude des banques, les filtres des opérateurs, et le travail des équipes d'enquête. Ils ne remplacent rien de tout ça. Les victimes doivent toujours pouvoir signaler vite une fraude, faire opposition et obtenir des consignes claires.

Pour les gestes de prévention qui restent utiles contre les appels et messages frauduleux, vous pouvez aussi consulter les recommandations de Cybermalveillance.gouv.fr.

Comment fonctionnent les bots anti-arnaque ?

Un bot de détournement cherche à tenir une interaction assez longtemps pour mobiliser le fraudeur - et, si possible, observer sa méthode. On n'est pas sur un simple « répondre automatiquement ». Le système doit produire des réactions cohérentes avec le canal et l'étape de la conversation, tout en évitant de divulguer de vraies informations sensibles.

Apate décrit des profils variés : différentes « personnalités », langues et habitudes. Certains bots décrochent, d'autres raccrochent ou indiquent qu'ils rappelleront plus tard. Cette diversité vise à éviter que toutes les conversations suivent le même script. Si chaque bot répond avec les mêmes phrases, les fraudeurs finissent par reconnaître le dispositif et cessent d'interagir.

Le même principe peut s'appliquer via messagerie ou dans des espaces où circulent des offres frauduleuses. L'objectif n'est pas seulement de bloquer un message : il s'agit aussi de créer une interaction assez plausible pour recueillir plus d'indices. Là encore, la différence avec un simple filtrage est importante : le filtrage réduit l'exposition, le bot peut aussi servir à produire du renseignement.

Le réalisme est une contrainte opérationnelle

Dans le reportage de Wired, des journalistes ont testé une version de démonstration en jouant le rôle de personnes à qui l'on propose d'investir dans une fausse opportunité liée aux cryptomonnaies. Le personnage numérique s'est montré réactif et assez naturel pour continuer l'échange. Les testeurs n'ont pas réussi à faire « signer » pendant leur essai, et l'entreprise affirme que certaines conversations peuvent durer plus de deux heures.

Ce que montre ce test est intéressant, mais ça ne suffit pas à juger la performance en situation réelle. Une démonstration n'est pas une confrontation avec des fraudeurs aguerris : eux peuvent changer de tactique, tester le bot, ou interrompre dès qu'un détail leur paraît suspect. La crédibilité doit donc être mesurée sur des conversations variées, pas uniquement sur un scénario préparé.

Et pour durer, le bot doit aussi éviter d'en faire trop. Trop bavard, trop naïf, ou trop « parfait » peut déclencher des soupçons. À l'inverse, s'il coupe trop vite, il mobilise peu de ressources. Il faut donc trouver un équilibre entre durée de l'échange, plausibilité du comportement et quantité d'informations réellement exploitables.

Mesurer ce qui compte vraiment

Un tableau de bord utile ne devrait pas se limiter au nombre d'appels « capturés ». Une équipe peut suivre, par exemple :

  • la durée médiane des conversations et la distribution des durées (pas seulement un maximum) ;
  • la part des échanges qui produisent des indices nouveaux et vérifiables ;
  • le taux d'erreurs dans l'identification des numéros, URL ou comptes suspects ;
  • le temps nécessaire pour transmettre un élément exploitable aux équipes concernées ;
  • des signaux indiquant que les fraudeurs reconnaissent (ou contournent) les bots ;
  • le coût de fonctionnement par conversation utile, pas par conversation simplement ouverte.

Ces indicateurs rendent les choix plus transparents. Un bot qui retient longtemps un escroc mais renvoie des informations inexactes peut coûter plus qu'il ne rapporte. À l'inverse, une interaction plus courte peut quand même être utile si elle fait remonter rapidement une nouvelle adresse de collecte ou un scénario qui circule.

Les honeypots dopés aux modèles de langage

Les bots qui dialoguent avec des fraudeurs ne sont pas le seul usage de l'IA. En cybersécurité, les honeypots sont des environnements leurres destinés à attirer les attaquants. Ils peuvent prendre la forme de faux serveurs ou de machines virtuelles qui semblent vulnérables, mais qui servent surtout à observer les tentatives et collecter des informations sur les outils utilisés.

Un honeypot « classique » répond selon des règles prévues à l'avance. Ce comportement répétitif peut finir par être repéré. Un modèle de langage peut rendre les interactions moins uniformes : il produit des réponses qui donnent l'impression d'un système plus vivant et plus réaliste. Ce n'est pas pour rendre le leurre invulnérable. C'est pour prolonger l'interaction et récupérer davantage d'éléments sur le comportement de l'attaquant.

Mark Vero, chercheur doctorant en informatique à l'ETH Zurich, et ses collègues ont étudié des honeypots utilisant des modèles de langage. D'après leurs travaux, tels que rapportés par Wired, des agents d'IA attaquants seraient restés « significativement plus longtemps » dans un honeypot alimenté par un modèle de langage que dans un leurre au comportement plus prévisible. Ils ont aussi noté que ce honeypot serait reconnu comme tel moins souvent.

Un résultat intéressant, mais circonscrit

Ces résultats vont dans le sens de l'idée qu'un comportement plus varié peut améliorer l'efficacité du leurre dans certains scénarios expérimentaux. Mais ils ne veulent pas dire que tous les attaquants humains seront trompés, ni qu'un modèle de langage rend automatiquement un honeypot « sûr ». Les conditions de test, les types d'agents étudiés et les comportements simulés jouent beaucoup. Il faut donc éviter de transformer une observation précise en promesse générale.

L'ajout d'un modèle introduit aussi des risques. Un système génératif peut produire une réponse imprévue, révéler des informations qu'il ne devrait pas divulguer, ou compliquer l'analyse des journaux. Il peut aussi consommer des ressources, augmenter les coûts et créer une dépendance à un fournisseur externe. Un honeypot doit donc rester isolé du système d'information réel et être traité comme un composant de sécurité à part entière.

En pratique, une équipe doit savoir ce qu'elle veut apprendre avant de déployer : identifier des méthodes d'intrusion, observer des outils, repérer des adresses de commande, ou tester la détection interne. Sans objectif clair, les journaux peuvent s'accumuler sans déboucher sur une décision utile.

Ce que les organisations doivent vérifier avant de se lancer

L'IA peut aider à perturber des opérations frauduleuses. Mais elle ne transforme pas automatiquement une expérimentation en service fiable. Pour une banque, un opérateur télécom ou une entreprise de cybersécurité européenne, le mieux est de traiter ça comme un vrai projet opérationnel : objectifs mesurables, responsabilités, sécurité des données, et procédure d'escalade.

Définir l'objectif et les limites du système

Commencez par définir le résultat attendu. Est-ce pour prolonger des appels frauduleux ? Détecter plus vite de nouvelles URL ? Comprendre les scénarios utilisés ? Alimenter des enquêtes ? Les données et les critères de réussite ne seront pas les mêmes. « Utiliser l'IA contre les arnaques » ne suffit pas : ce n'est pas assez concret pour piloter un déploiement.

Définissez ensuite ce que le bot a le droit de faire et de dire. Il ne devrait pas accéder à des comptes réels, transmettre des données de clients ou déclencher une transaction. Les conversations doivent rester isolées des systèmes de production qui contiennent des informations sensibles. Pour un honeypot, la séparation réseau et la journalisation ne sont pas des « options » : ce sont des prérequis.

Encadrer les données et les échanges

Dès qu'on collecte des numéros, des messages ou des informations bancaires, on peut traiter des données personnelles. En Europe, il faut donc examiner les obligations au regard du RGPD : limiter la collecte à ce qui est nécessaire, prévoir des règles de conservation, restreindre les accès, et vérifier si une analyse juridique et une analyse d'impact sont requises. La conformité, ce n'est pas juste ajouter une phrase dans une politique de confidentialité.

Il faut aussi vérifier comment les données seront partagées. Une information récupérée par une banque n'est pas automatiquement exploitable ou transférable vers tous les partenaires. Les formats, les règles de validation et les responsabilités doivent être clarifiés avec les équipes juridiques, sécurité et conformité. Pour les repères utiles, voir les ressources de la CNIL sur le RGPD.

Prévoir la validation humaine et l'escalade

Une adresse ou un compte « repéré » par un modèle ne doit pas être traité comme une preuve suffisante pour prendre une décision irréversible. Il faut distinguer les indices, les signaux corroborés et les faits vérifiés. C'est une façon de réduire le risque de bloquer un utilisateur légitime ou de transmettre une accusation erronée.

Un processus robuste peut prévoir une validation humaine avant de partager un renseignement sensible, une procédure pour corriger les erreurs, et une personne responsable pour chaque décision. Il doit aussi préciser quoi faire si un bot reçoit une information personnelle, ou si une conversation fait apparaître une menace urgente. L'automatisation aide à gérer le volume ; elle ne supprime pas la responsabilité de l'organisation.

Tester l'efficacité et le coût complet

Avant un déploiement à grande échelle, testez sur un périmètre maîtrisé. Comparez le comportement à une base de référence : combien de tentatives sont réellement détournées ? Quelles données sont vérifiables ? Combien de temps humain reste nécessaire pour traiter les alertes ? Ajoutez aussi les coûts : hébergement, inférence, surveillance, conformité, maintenance.

Une expérimentation qui marche pendant quelques semaines peut devenir difficile à maintenir quand les scénarios changent ou que les volumes montent. Le bon critère n'est donc pas seulement « la qualité d'une démo ». C'est la capacité à obtenir des résultats utiles de façon répétable, sans créer une nouvelle surface de risque disproportionnée.

Conclusion : l'IA peut perturber les arnaques, pas les faire disparaître

Faire dialoguer des bots avec des fraudeurs, ou utiliser des modèles de langage dans des honeypots, ouvre une piste concrète : détourner une partie de l'activité criminelle, collecter des informations et mieux comprendre les méthodes employées. Les premiers retours décrits par Wired sont intéressants, mais ils ne prouvent pas à eux seuls une baisse générale de la cybercriminalité.

La décision doit s'appuyer sur des résultats vérifiables : informations confirmées, perturbations mesurables, coûts soutenables, risques maîtrisés. Sans partage sécurisé des renseignements, sans supervision humaine, et sans intégration aux dispositifs existants, même un bot très convaincant restera une démonstration isolée.

Si votre organisation envisage ce type d'outil, commencez par un cas d'usage limité et mesurable. Dites clairement ce que le système collecte, qui valide ce qui en ressort, et comment vous jugerez son utilité. En cybersécurité comme ailleurs, un dispositif simple, bien encadré et réellement exploité vaut mieux qu'une promesse technologique difficile à tenir.

Questions frequentes

Ils peuvent détourner certaines interactions et mobiliser du temps que l’escroc aurait pu consacrer à une autre cible. Ils ne bloquent pas toutes les campagnes et ne garantissent pas qu’un appel frauduleux ne vous atteindra pas. Ils complètent les filtres, les signalements et les mesures de prévention, sans les remplacer.
En poursuivant des conversations ou en répondant à des messages, il peut recueillir des indices tels que des URL, des numéros, des coordonnées de paiement ou des scripts d’arnaque. Ces éléments doivent être vérifiés et contextualisés avant d’être partagés ou utilisés pour prendre une décision.
Un honeypot est un système leurre conçu pour attirer un attaquant dans un environnement surveillé. Les équipes de sécurité peuvent ainsi observer ses tentatives et étudier ses outils. L’ajout d’un modèle de langage vise notamment à rendre les réponses moins prévisibles, mais ne dispense ni de l’isolation ni de la surveillance.
Cela dépend des données collectées, de leur usage, des personnes concernées et des modalités de partage. Un déploiement doit être évalué au regard du RGPD : minimisation, sécurité, durée de conservation et base juridique, notamment. Il est prudent d’associer les équipes juridiques et le délégué à la protection des données en amont.
Pas nécessairement. La première étape est de vérifier le problème à résoudre, les outils déjà disponibles et la capacité à traiter les renseignements générés. Pour beaucoup d’organisations, renforcer le signalement, le filtrage et la coordination avec les partenaires sera plus utile qu’un bot développé sans objectif ni équipe de suivi.

Articles similaires