Aujourd’hui, la plupart des équipes marketing utilisent l’IA au quotidien sans se poser la question de la sécurité. Pourtant, chaque chatbot, chaque automatisation et chaque assistant connecté à un CRM ou une boîte mail élargit un peu plus la surface que les cybercriminels peuvent exploiter.

Le FBI a récemment alerté sur l’usage croissant de l’IA par les attaquants pour produire des messages de phishing quasiment indétectables, capables de provoquer des pertes financières importantes et des fuites de données. Pour les responsables marketing, comprendre ces risques devient aussi essentiel que de savoir utiliser les outils eux-mêmes.

Les grandes familles de risques liés à l’IA

La première concerne les attaques visant directement le système d’IA, comme l’empoisonnement de modèle ou l’injection de prompt. La deuxième regroupe les risques liés à la façon dont les utilisateurs se servent de l’outil, par exemple en partageant des données confidentielles sans réfléchir. La troisième catégorie correspond aux usages malveillants de l’IA par les attaquants eux-mêmes, qui s’en servent comme arme pour mener des campagnes de phishing ou générer des malwares.

Ces trois axes se recoupent souvent dans la pratique, mais ils permettent de structurer une stratégie de défense cohérente.

L’empoisonnement de modèle (model poisoning)

L’empoisonnement de modèle consiste à corrompre les données d’entraînement d’une IA pour modifier son comportement de l’intérieur. Le modèle continue à fonctionner normalement en apparence, mais sa logique interne a été altérée pour produire des réponses biaisées, dangereuses ou favorables à l’attaquant.

Ce type d’attaque peut survenir via un accès interne malveillant, par exemple un fournisseur compromis dans la chaîne d’entraînement, ou via un accès non autorisé aux jeux de données. Plusieurs techniques existent : l’ajout de déclencheurs cachés qui provoquent des sorties malveillantes dans des conditions précises, le fait d’apprendre au modèle de mauvais schémas via du mauvais étiquetage, ou encore l’injection de données manipulées directement dans le corpus d’entraînement. Dans certains cas, des attaques par déni de service visent simplement à rendre le modèle instable ou peu fiable.

Les conséquences peuvent être lourdes. Un modèle empoisonné peut générer davantage d’hallucinations, recommander du contenu favorable à l’attaquant, propager de la désinformation, ou même orienter discrètement les utilisateurs vers des téléchargements infectés. Et comme tous les outils construits sur ce modèle hériteront du problème, c’est potentiellement tout un écosystème qui se trouve compromis.

Lire Aussi : Comment ChatGPT, Claude et Gemini construisent leurs réponses 

L’injection de prompt, la menace la plus discutée en 2026

Contrairement à l’empoisonnement de modèle, qui agit avant le déploiement, l’injection de prompt se produit en temps réel, pendant l’utilisation de l’outil. C’est aujourd’hui l’une des vulnérabilités les plus documentées dans le domaine de l’IA générative, et elle prend plusieurs formes.

  • L’injection directe consiste à demander explicitement au modèle d’ignorer ses instructions précédentes, parfois en mélangeant des consignes légitimes et malveillantes dans le même prompt pour brouiller son fonctionnement.
  • L’injection indirecte est plus sournoise : les instructions malveillantes sont dissimulées dans un contenu externe (une page web, un document, une image) que le modèle est amené à traiter.
  • Le jailbreak vise à faire sortir l’IA de son cadre de sécurité habituel.
  • L’injection inter-systèmes correspond au cas où une consigne malveillante transite d’un outil connecté à un autre, déclenchant des actions imprévues en cascade.
  • Enfin, l’injection de code consiste à camoufler du code malveillant dans un texte que le modèle finit par exécuter ou propager.

Le point commun à toutes ces techniques, c’est que les modèles de langage ont du mal à distinguer une instruction légitime venant du développeur d’une instruction glissée par un utilisateur ou cachée dans un contenu. Si l’outil est connecté à d’autres systèmes, une simple injection de prompt peut donc déclencher une chaîne d’actions bien plus large que prévu.

Les fuites de données, le risque le plus fréquent au quotidien

C’est sans doute le risque le plus courant, et le plus humain. Une personne de l’équipe copie un rapport interne dans un chatbot pour le résumer, partage un export CRM pour l’analyser, ou colle le contenu d’un document confidentiel pour le faire reformuler. Si l’outil utilisé est public, mal sécurisé, ou simplement compromis, ces informations peuvent se retrouver hors de l’entreprise.

Et ce qui circule ainsi est parfois sensible : documents internes, données clients, identifiants, données financières, éléments de propriété intellectuelle. Un seul fichier mal partagé peut révéler des informations sur l’organisation interne, les conventions de nommage, les habitudes d’accès ou l’infrastructure technique, autant d’indices précieux pour un attaquant qui prépare une intrusion.

Deux incidents récents illustrent bien l’ampleur que peut prendre ce type de problème. Côté Microsoft, des chercheurs de l’équipe IA ont accidentellement exposé 38 To de données privées via un dépôt GitHub censé partager du code open source pour la reconnaissance d’image. La cause venait d’un jeton SAS Azure mal configuré, qui donnait accès à l’intégralité d’un compte de stockage plutôt qu’aux seuls fichiers prévus. Dans le lot se trouvaient des mots de passe internes, des clés secrètes et plus de 30 000 messages Teams d’employés.

Plus récemment, l’application Meta AI a connu une polémique du même ordre. De nombreux utilisateurs ne réalisaient pas qu’en appuyant sur le bouton “Partager” d’une conversation, ils publiaient leur échange sur le fil public “Discover” de l’application, visible par n’importe qui. Des conversations très personnelles, sur des sujets médicaux, juridiques ou financiers, se sont ainsi retrouvées exposées publiquement. Meta a depuis ajouté un avertissement explicite avant toute publication, mais l’épisode rappelle qu’il ne faut jamais considérer une conversation avec une IA comme automatiquement privée.

Une fois qu’une donnée sensible a été transmise à un modèle externe, il devient difficile, voire impossible, de savoir où elle finira stockée ni si elle pourra servir à entraîner de futures versions de l’outil. Pour une entreprise, les conséquences peuvent aller jusqu’à une non-conformité RGPD, une perte de propriété intellectuelle, ou une exposition accrue à des tentatives de rançongiciel.

Lire Aussi : Claude génère de plus en plus de trafic vers les sites web

Les intégrations et connexions API mal sécurisées

Les fonctions d’IA sont aujourd’hui intégrées dans à peu près tous les outils du quotidien : messagerie, agenda, CRM, plateformes collaboratives. Chaque intégration représente un point d’accès supplémentaire, et donc une cible potentielle de plus.

Le vrai problème réside dans le niveau d’accès accordé à ces outils. Si un assistant IA peut lire un agenda, rédiger des emails ou aller chercher des données dans un CRM, alors toute personne capable de compromettre cette intégration obtient les mêmes droits. Une clé API mal protégée, un plugin tiers peu vérifié ou une application connectée non sécurisée peuvent suffire à exfiltrer des données ou à manipuler des systèmes connectés sans que personne ne s’en rende compte immédiatement.

Et comme ces outils opèrent souvent avec des permissions très larges, une seule connexion fragile peut devenir le point de départ d’une intrusion bien plus vaste que prévu initialement.

L’ingénierie sociale boostée par l’IA

L’IA a changé l’échelle et la crédibilité des attaques d’ingénierie sociale. Les outils permettent désormais d’imiter un style d’écriture, de cloner une voix, de générer des deepfakes vidéo et de produire des messages très ciblés, parfois quasiment impossibles à distinguer d’une communication authentique.

Plusieurs formes de ces attaques se développent en parallèle. Les deepfakes audio ou vidéo permettent d’usurper l’identité d’un dirigeant ou d’un partenaire commercial. Les emails de phishing hyper personnalisés imitent le ton et le style d’un client, d’un collègue ou d’un fournisseur réel. Des identités synthétiques, construites à partir de données volées et recoupées, créent de faux profils étonnamment crédibles. Et certains outils de reconnaissance automatisée cartographient les habitudes d’une cible avec une précision redoutable avant même de lancer l’attaque.

Ces techniques peuvent mener à des prises de contrôle de comptes, des fraudes financières, ou des campagnes de spear-phishing très efficaces, où la victime est poussée à transmettre des informations sensibles, télécharger un fichier piégé, ou effectuer un virement. Pour les équipes marketing, qui manipulent au quotidien des données clients et communiquent énormément par email, ce type de menace est particulièrement préoccupant.

L’IA accélère la découverte de failles par les attaquants

Un autre effet, moins visible mais tout aussi important, concerne la vitesse à laquelle les vulnérabilités sont aujourd’hui découvertes et exploitées. Ce qui demandait autrefois une expertise technique pointue et des heures de travail manuel peut désormais se faire en quelques minutes grâce à des outils d’IA.

Des modèles peuvent analyser un code source entier, repérer des schémas exploitables, tester des centaines de variantes d’exploit, ou générer des malwares capables de muter pour échapper aux antivirus. Même des attaquants peu expérimentés peuvent ainsi accomplir des tâches qui nécessitaient autrefois un haut niveau de compétence technique.

Concrètement, cela signifie que le délai entre la découverte d’une faille et son exploitation à grande échelle se réduit considérablement. Les équipes de sécurité doivent réagir plus vite, avec des volumes d’attaques en hausse et des coûts d’attaque qui tendent vers zéro pour les cybercriminels.

Lire Aussi : Optimisation pour l’IA sur Google : ce que les nouvelles directives changent (spoiler : pas grand-chose)

Biais, bugs et hallucinations : quand l’IA se trompe avec assurance

L’IA ne donne pas toujours la bonne réponse, et le pire, c’est qu’elle le fait souvent avec un aplomb total. Le fameux exemple du nombre de lettres “b” dans le mot “blueberry”, qui a circulé largement sur les réseaux, illustre bien ce phénomène : une réponse fausse, donnée avec une confiance totale.

Ces erreurs viennent généralement de données d’entraînement incomplètes ou biaisées, de modèles poussés au-delà de leurs capacités réelles, ou de situations qui n’ont simplement pas été représentées lors de l’apprentissage. Quand le modèle ne sait pas, il a tendance à combler le vide plutôt qu’à l’admettre, ce qui donne des réponses qui sonnent juste mais qui ne le sont pas.

Pour une équipe marketing, le risque est réel si ces sorties sont prises pour argent comptant. Une recommandation stratégique basée sur des chiffres inventés, un contenu généré qui contient une affirmation fausse, ou une analyse biaisée qui oriente une décision peuvent avoir des conséquences concrètes sur la réputation de l’entreprise ou sur ses résultats. Sans relecture humaine, une petite erreur d’IA peut devenir un vrai problème opérationnel.

La gouvernance de l’IA, le maillon souvent négligé

La gouvernance de l’IA regroupe l’ensemble des règles, contrôles et bonnes pratiques qui encadrent son usage dans l’entreprise. Et c’est justement le point sur lequel beaucoup d’organisations sont en retard.

Sans cadre clair, l’IA devient un facteur de risque plutôt qu’un levier d’efficacité. Le problème vient souvent de comportements simples mais répandus : utilisation d’outils d’IA non validés par l’entreprise (le fameux “shadow AI”), absence de suivi sur la façon dont ces outils sont utilisés, ou adoption de solutions IA avant même d’avoir défini des règles de base.

Sans gouvernance, les fuites de données sont plus probables, les sorties de l’IA deviennent difficiles à vérifier, et il n’existe aucune trace permettant de comprendre ce qui s’est passé en cas d’incident ou de contrôle de conformité.

Comment se protéger face à ces risques

La bonne nouvelle, c’est qu’il n’est pas nécessaire d’interdire l’IA pour réduire ces risques de façon significative. Quelques bonnes pratiques, appliquées de manière cohérente, suffisent à transformer l’IA d’un facteur de vulnérabilité en un outil maîtrisé.

Former les équipes à la cybersécurité et aux usages de l’IA

La formation reste le levier le plus efficace pour limiter l’erreur humaine. Quand une équipe comprend comment fonctionne un modèle, quelles sont ses limites et où se situent les zones de risque, elle est naturellement plus prudente avec les données qu’elle partage et plus critique face aux réponses obtenues.

Vérifier et nettoyer les données avant de les soumettre à l’IA

Avant d’envoyer un fichier ou un texte à un outil d’IA, il vaut mieux prendre l’habitude de le passer en revue. Concrètement, cela peut vouloir dire retirer les informations personnelles identifiables (noms, emails, numéros de téléphone) d’un rapport de campagne avant de le partager avec une agence, supprimer les scripts de tracking présents dans des fichiers de pages d’atterrissage, nettoyer les exports CRM pour ne garder que les champs strictement nécessaires, ou encore vérifier les notes et formules cachées dans un tableur avant de l’envoyer.

Cette logique vaut aussi dans l’autre sens : les réponses produites par l’IA doivent être relues avant d’être intégrées dans un processus marketing, pour repérer une éventuelle hallucination ou une recommandation hasardeuse.

Séparer clairement les instructions et les contenus dans les prompts

Mélanger des consignes système et du contenu libre dans un même prompt augmente le risque d’injection. Travailler avec des modèles de prompts structurés, où les instructions sont séparées et verrouillées par rapport au contenu fourni par l’utilisateur, réduit considérablement ce risque. Les workflows guidés et les champs contrôlés limitent aussi la marge de manœuvre pour ce type d’attaque.

Mettre en place un second modèle de vérification

Faire intervenir un deuxième modèle d’IA pour relire et vérifier la sortie du premier est une pratique qui se généralise. Ce fonctionnement reproduit, à plus grande échelle, ce qu’une relecture croisée entre collègues apporterait sur un contenu sensible. Le second modèle peut signaler des incohérences, des biais ou des informations à vérifier avant publication.

Garder un humain dans la boucle pour toute action à fort enjeu

L’IA reste un outil d’assistance, pas un outil de décision autonome, surtout sur les tâches à fort impact. Une copie de campagne, une logique de segmentation, une analyse de performance ou une automatisation ne devraient jamais être mises en production sans validation humaine. Mettre en place une étape de validation explicite avant toute publication ou tout déclenchement automatisé permet de garder le contrôle, sans pour autant ralentir le travail au quotidien.

Lire Aussi : Un tiers des nouveaux sites web sont générés par IA 

Tester régulièrement ses défenses (red teaming)

Organiser des exercices de simulation d’attaque, ou red teaming, permet de tester comment les systèmes IA réagissent face à des tentatives malveillantes, d’identifier les failles avant qu’un vrai attaquant ne le fasse, et d’ajuster les protections en conséquence. Documenter ces tests et les résultats obtenus aide aussi à suivre l’évolution des menaces dans le temps.

Surveiller, journaliser et détecter les anomalies

Les outils d’IA doivent bénéficier du même niveau de surveillance que n’importe quel autre système critique. Mettre en place un suivi des accès, des journaux d’activité et une détection des comportements anormaux permet de repérer rapidement un usage inhabituel, qu’il s’agisse d’un accès suspect ou d’une tentative d’injection de prompt.

Appliquer le principe du moindre privilège

Un outil d’IA ne devrait avoir accès qu’aux données et systèmes strictement nécessaires à sa fonction. Limiter les permissions, séparer les jeux de données, mettre en place des contrôles d’accès basés sur les rôles, et éviter de connecter directement un outil d’IA à un environnement de production réduisent considérablement l’impact potentiel d’une compromission.

Définir une politique claire d’utilisation de l’IA

Une politique d’utilisation de l’IA bien construite couvre les outils approuvés, les règles d’usage, les restrictions sur les données, et les modalités de suivi. Elle donne aux équipes un cadre clair pour utiliser ces outils en confiance, tout en réduisant le risque global pour l’entreprise. C’est souvent la pièce manquante qui transforme une utilisation anarchique de l’IA en un usage maîtrisé et traçable.

Conclusion

L’IA n’est ni un danger à fuir, ni un outil sans risque à utiliser sans réfléchir. Comme toute technologie qui s’intègre profondément dans les processus de travail, elle élargit la surface d’attaque et crée de nouvelles façons pour les données sensibles de circuler, parfois sans contrôle. Les exemples de Microsoft et de Meta montrent bien qu’il suffit parfois d’une mauvaise configuration ou d’un bouton mal compris pour exposer des données massives.

Mais avec une bonne dose de sensibilisation, des règles claires sur ce qui peut être partagé avec un outil d’IA, et un minimum de supervision humaine sur les contenus produits, les équipes marketing peuvent continuer à tirer parti de ces outils sans transformer leur quotidien en porte ouverte pour les attaquants. La cybersécurité liée à l’IA n’est pas un frein à l’innovation, c’est la condition pour pouvoir en profiter durablement.