L’IA du côté de l’attaquant
·L’essentiel en bref
- L’IA ne change ni l’objectif d’un attaquant — un virement, un accès, des données — ni ses points d’entrée. Elle change le coût de la préparation.
- Un français fautif n’est plus un signal de détection. Ce qui reste fiable, c’est la nature de la demande et la vérification par un second canal.
- La voix de synthèse déplace l’arnaque au président du courriel vers le téléphone.
- Vos propres applications d’IA deviennent une surface d’attaque : prompt injection, pipelines RAG, agents outillés, serveurs MCP.
- Dans un test, ce qui change n’est pas la méthode mais le réalisme exigé : prétextes documentés, campagnes multicanales, et un contre-audit qui vérifie que la procédure corrigée tient.
L’IA est entrée dans le quotidien des entreprises, et dans celui des attaquants. La plupart des articles sur le sujet vieillissent en trois mois, parce qu’ils décrivent un outil plutôt qu’un mécanisme.
La question utile est ailleurs : qu’est-ce qui, dans le travail d’un attaquant, coûtait cher hier et ne coûte presque plus rien aujourd’hui ? La préparation. Écrire un message crédible dans une langue que l’on ne parle pas, reconstituer un organigramme, imiter un ton interne, produire cent variantes d’un même prétexte : ce travail demandait des heures, il demande quelques minutes.
Cette page est le point d’entrée ; chaque volet est détaillé ailleurs : le phishing généré par IA, l’arnaque au président, l’OSINT et le prétexte, l’IA du côté de la défense.
Ce que l’IA change, et ce qu’elle ne change pas
Trois choses changent. La langue : un attaquant écrit un français d’entreprise correct sans le parler, et adapte le registre à sa cible. La personnalisation : les fragments publics d’une société — un projet annoncé, un recrutement, un fournisseur — se recomposent en une histoire cohérente. L’échelle : une variante par service, par fonction et par langue, d’un seul coup.
Le même mouvement touche le code : des modèles savent lire un dépôt, reproduire un défaut et proposer un correctif. Le délai entre le moment où une faiblesse devient connue et celui où elle est exploitée se raccourcit, donc une correction reportée coûte plus cher qu’avant.
Trois choses ne changent pas. L’objectif reste l’argent, l’accès, la donnée et la confiance. Les points d’entrée restent une pièce jointe, un lien, un appel, un compte sans second facteur, un service exposé et non corrigé. Et les mesures qui fonctionnent restent ennuyeuses : vérification par un second canal, authentification résistante au phishing, procédures de paiement écrites, correctifs appliqués, tests réguliers.
Le phishing ne se repère plus à la langue
Le phishing (hameçonnage) reste le chemin le moins cher vers un compte ou un virement, parce qu’il vise la décision d’une personne plutôt que la technique.
Pendant des années, la consigne donnée aux collaborateurs reposait sur la forme : fautes d’orthographe, traduction approximative, mise en page grossière. Elle est périmée — un message frauduleux peut être mieux rédigé que la moyenne de vos courriels internes.
Les signaux encore exploitables portent sur le fond de la demande :
- un virement, un changement de coordonnées bancaires ou un paiement anticipé ;
- un code à usage unique, un mot de passe, une validation d’authentification ;
- une connexion par un lien plutôt que par le chemin habituel ;
- une urgence qui est précisément ce qui interdirait de vérifier.
D’où un changement de consigne : cessez de demander à vos collaborateurs de repérer un faux, demandez-leur de vérifier une demande.
La voix entre dans le périmètre
La fraude sort du texte : un extrait sonore de quelques secondes, pris dans un webinaire, une interview ou une réunion en ligne, suffit à produire une voix reconnaissable. Le scénario, lui, n’a rien d’inédit. La comptabilité reçoit un appel : la voix est celle du dirigeant, il est en déplacement, l’opération est confidentielle, elle doit passer aujourd’hui. C’est l’arnaque au président — ce que les services de l’État désignent sous le nom de faux ordre de virement. Les variantes visent la paie, les fournisseurs ou l’assistance informatique.
Ce qui change n’est pas le scénario mais son coût d’entrée : il n’est plus nécessaire de savoir imiter quelqu’un. La contre-mesure ne se joue donc plus à l’oreille, mais dans le processus : aucun virement exceptionnel ni changement de coordonnées bancaires sans confirmation par un second canal défini à l’avance.
L’OSINT : la matière première, c’est vous qui la publiez
Un prétexte crédible ne s’invente pas, il se documente — et en France la matière est publique : le registre national des entreprises et les annonces légales donnent les dirigeants, vos offres d’emploi nomment votre pile technique, les réseaux professionnels reconstituent l’organigramme, vos communiqués donnent le calendrier des projets.
L’IA n’ouvre aucune source nouvelle : elle supprime le temps de recoupement. Là où il fallait une journée pour comprendre qui valide quoi chez vous, une synthèse s’obtient en quelques minutes.
Votre propre IA devient une surface d’attaque
En déployant des assistants, des agents et de la recherche documentaire interne, vous ajoutez une surface exposée, dont les défauts caractéristiques sont connus : la prompt injection directe, où l’utilisateur détourne les instructions du système ; la prompt injection indirecte, plus intéressante pour un attaquant, où l’instruction est déposée dans un document que votre pipeline RAG ingérera plus tard ; la fuite de contexte entre utilisateurs ; les permissions trop larges d’un agent qui peut lire une boîte mail, appeler une API et déclencher une action ; les serveurs MCP exposés sans contrôle d’accès sérieux.
Aucun de ces défauts ne se corrige par un meilleur message système : ce sont des questions d’architecture, de cloisonnement et d’autorisation, qui se démontrent par un test plutôt que par un questionnaire fournisseur. Voir pentest LLM et sécurité de l’IA et le test d’intrusion des intégrations LLM.
Ce que cela change dans un test
Un exercice d’ingénierie sociale conçu avant cette évolution mesure la mauvaise chose : envoyer un message générique à mille adresses et compter les clics ne dit plus grand-chose, puisque ce n’est pas ce que vous recevrez.
Le prétexte est documenté. Il s’appuie sur ce qu’un attaquant trouverait réellement sur votre organisation, ce qui rend le résultat comparable à une attaque réelle.
La campagne devient multicanale. Un courriel suivi d’un appel met à l’épreuve vos procédures, là où un courriel seul teste une vigilance : un scénario de changement de RIB vaut dix messages de colis non livré.
Les indicateurs changent. Le taux de clic n’est qu’un chiffre d’entrée. Comptent davantage le taux et le délai de signalement, et surtout le fait de savoir si la procédure de paiement a tenu quand quelqu’un s’est laissé convaincre. Une organisation où quinze personnes cliquent mais où le virement est bloqué se porte mieux que celle où trois cliquent et où le virement part.
Les résultats restent agrégés. Aucune liste nominative, aucune sanction individuelle : une campagne qui désigne des coupables détruit la remontée d’information dont vous avez besoin.
Le prolongement naturel est la sensibilisation à la cybersécurité, par sessions courtes adossées aux résultats. Et comme pour tout test, le contre-audit est inclus, sans surcoût : nous revenons vérifier que la procédure corrigée résiste au même scénario.
Ce que le droit encadre déjà
Les attaques assistées par IA sont nouvelles ; les obligations qui les entourent le sont beaucoup moins.
L’article 32 du RGPD demande des mesures appropriées et, parmi elles, une procédure pour tester, analyser et évaluer régulièrement leur efficacité. C’est la disposition européenne qui nomme le test périodique, et elle vaut autant pour votre procédure de paiement que pour vos serveurs.
Le règlement (UE) 2024/1689 sur l’intelligence artificielle impose par ailleurs des obligations de transparence aux fournisseurs et aux déployeurs de systèmes produisant des contenus de synthèse. Utile pour l’usage légitime, sans effet sur un attaquant : n’en faites pas un moyen de détection.
Enfin, ce qui sépare un attaquant d’un testeur n’est pas la technique mais le mandat. Tous nos tests sont réalisés sur autorisation écrite, dans un périmètre défini contractuellement ; sans ce mandat, les mêmes actes relèvent des articles 323-1 et suivants du code pénal. Une simulation de phishing ajoute trois conditions : information préalable des collaborateurs, consultation du comité social et économique dans les entreprises d’au moins cinquante salariés avant la mise en place d’un moyen permettant de contrôler leur activité, et restitution agrégée.
Cet article est informatif et ne constitue pas un conseil juridique. Les obligations applicables à votre organisation dépendent de son secteur, de sa taille et de la nature de ses traitements ; faites-les vérifier par un conseil. Dernière vérification : 11 septembre 2026.
Quatre mesures qui tiennent
- Vérifiez toute demande urgente par un second canal : un numéro que vous connaissiez déjà, jamais celui du message.
- Déployez une authentification résistante au phishing : une clé de sécurité ou une passkey est liée au domaine, un code reçu par SMS se redemande en temps réel.
- Écrivez la procédure de paiement : aucun virement exceptionnel ni changement de coordonnées bancaires sans double validation.
- Testez vos mesures par un test d’intrusion — une liste de vulnérabilités n’est pas une démonstration, voir scan de vulnérabilités ou test d’intrusion — puis faites vérifier les correctifs par un contre-audit.
Conclusion : la cible n’a pas changé, la qualité des attaques si
L’objectif d’un attaquant n’a pas changé : l’argent, la donnée, l’accès, la confiance. Ce sont ses outils de préparation qui ont changé — et aucune des quatre mesures ci-dessus n’est spectaculaire. C’est pourtant ce qui rend la plupart de ces scénarios beaucoup plus coûteux à mener.
Haxoris est un prestataire européen : vos données et vos rapports restent dans l’Union européenne, nos tarifs sont publics, le contre-audit est inclus, et vous savez nommément qui réalise le test. Pour savoir où en sont vos procédures, demandez un devis.
IA et cyberattaques — questions fréquentes
01L’IA rend-elle les cyberattaques plus dangereuses ?
Elle ne change ni l’objectif d’un attaquant — un virement, un accès, des données — ni ses points d’entrée. Elle change le coût de la préparation. Écrire un message crédible dans une langue que l’on ne parle pas, reconstituer un organigramme, produire cent variantes d’un même prétexte : ce travail prenait des heures, il prend désormais quelques minutes. Le volume de tentatives plausibles augmente, pas la nature de la menace.
02Comment reconnaître un phishing écrit par une IA ?
Pas à la langue. Les fautes d’orthographe et les tournures maladroites ont longtemps servi de signal ; elles ne sont plus fiables. Les signaux utilisables portent sur la demande elle-même : un virement, un changement de coordonnées bancaires, un code à usage unique, une connexion demandée hors du canal habituel, une urgence qui interdit la vérification. La règle pratique est le rappel sur un numéro déjà connu, jamais celui indiqué dans le message.
03Comment se protéger d’un appel truqué par une voix de synthèse ?
Par la procédure, pas par l’oreille. Un extrait sonore court, tiré d’un webinaire ou d’un podcast, suffit à produire une voix convaincante. La contre-mesure est un processus de paiement où aucun virement exceptionnel et aucun changement de RIB ne s’exécute sans confirmation par un second canal connu à l’avance, quelle que soit la personne qui appelle et quel que soit le degré d’urgence invoqué.
04Faut-il tester ses propres applications d’IA ?
Dès qu’un assistant, un pipeline RAG ou un agent dispose d’un accès à vos données ou à un outil qui agit, oui. Les défauts caractéristiques sont la prompt injection directe et indirecte, la fuite de contexte entre utilisateurs, les permissions trop larges accordées à un agent et les serveurs MCP exposés. Ce sont des défauts d’architecture et d’autorisation, que l’on démontre par un test plutôt que par un questionnaire.
05Une simulation de phishing est-elle légale en France ?
Oui, à trois conditions. Les collaborateurs sont informés au préalable de l’existence du dispositif, par exemple dans la charte informatique ou une note de service. Dans les entreprises d’au moins cinquante salariés, le comité social et économique est consulté avant la mise en place d’un moyen permettant de contrôler l’activité des salariés. Enfin, les résultats sont restitués de façon agrégée, sans liste nominative et sans sanction individuelle.
