IA et cybersécurité : 20 nouvelles menaces à connaître en 2026 et comment s’en protéger

Ce que disent réellement les autorités en 2026

Avant de lister les menaces, il faut poser le cadre, parce que le sujet est saturé de formules spectaculaires qui ne résistent pas à la lecture des rapports officiels.

Le CERT-FR, rattaché à l’ANSSI, a publié le 4 février 2026 un rapport de renseignement sur la menace consacré à l’IA générative face aux attaques informatiques (référence CERTFR-2026-CTI-001). Il constate que les systèmes d’IA générative sont utilisés et détournés à différentes étapes d’une attaque, principalement pour le profilage de victimes, la conception de contenus d’ingénierie sociale et le développement de programmes malveillants. Il pose aussi une limite que peu d’articles reprennent : à la date du rapport, aucun système d’IA générative n’a été en mesure de mener de manière autonome toutes les étapes d’une attaque informatique.

Le même rapport distingue deux profils d’attaquants. Pour les groupes les plus avancés, l’IA est un outil de gain de performance et de passage à l’échelle : elle ne leur apprend rien qu’ils ne sachent déjà, elle leur fait gagner du temps. Pour les acteurs les moins expérimentés, elle joue surtout un rôle d’outil d’apprentissage. La conséquence pratique pour une entreprise est simple : le volume et la qualité moyenne des tentatives augmentent, pas la nature des tentatives.

Du côté européen, le rapport ENISA Threat Landscape 2025 rapporte que plus de 80 % des courriels d’hameçonnage identifiés entre septembre 2024 et février 2025 recouraient à l’IA à un degré ou à un autre. Le même rapport précise que l’activité malveillante assistée par IA consistait jusque-là à augmenter des opérations existantes avec des outils grand public, plutôt qu’à atteindre des capacités de rupture.

Europol, dans son évaluation IOCTA 2026, observe que l’IA générative accélère la fraude en ligne en permettant aux réseaux criminels de personnaliser facilement leurs scénarios, note la détection croissante de contenus entièrement ou partiellement synthétiques, et signale que des acteurs ont commencé à s’appuyer sur des systèmes d’IA agentiques. Cette dernière observation est présentée comme un début, pas comme un état stabilisé.

Enfin, côté volumétrie française, le rapport d’activité 2025 de Cybermalveillance.gouv.fr place, pour les entreprises et associations, le piratage de compte en tête des demandes d’assistance (21 %, en hausse de 52 %), devant l’hameçonnage (16 %, en hausse de 29 %) et la fraude au virement (13,5 %, en hausse de 93 %). L’IA n’y apparaît pas comme une catégorie d’incident : elle est un moyen, pas un type d’attaque déclaré par les victimes.

Les 20 menaces en un tableau

Le tableau ci-dessous sert de repère de lecture. Les cinq familles correspondent aux cinq sections qui suivent.

Famille 1 : l’ingénierie sociale augmentée

C’est la famille la mieux documentée, et de loin la plus rentable pour les attaquants. Le point commun de ces cinq menaces : aucune ne vise votre infrastructure, toutes visent une personne.

1. L’hameçonnage rédigé par une IA

Statut : observée. Pendant vingt ans, le principal signal d’alerte d’un courriel frauduleux a été sa langue : fautes d’accord, tournures traduites mot à mot, formules de politesse incohérentes. Ce signal a disparu. Un modèle de langue rédige aujourd’hui un français professionnel irréprochable, dans le registre attendu, en quelques secondes et dans n’importe quelle langue.

L’ENISA chiffre le phénomène : plus de 80 % des courriels d’hameçonnage identifiés entre septembre 2024 et février 2025 recouraient à l’IA. Ce n’est donc plus une tendance à surveiller, c’est le régime normal.

Ce qui protège : arrêter d’enseigner « repérez les fautes ». La formation des équipes doit se déplacer vers les invariants que l’IA ne change pas : l’adresse réelle de l’expéditeur, la destination réelle d’un lien, le caractère inhabituel de la demande, et surtout l’urgence associée à une opération financière ou à une remise d’identifiants.

2. L’hameçonnage ciblé nourri de sources ouvertes

Statut : observée. Le CERT-FR range explicitement le profilage de victimes parmi les usages détournés constatés. Le mécanisme est le suivant, au niveau conceptuel : les informations qu’une organisation publie d’elle-même (organigramme, communiqués, offres d’emploi, publications professionnelles de ses salariés) suffisent à produire un message qui mentionne le bon projet, le bon nom et le bon moment. Ce travail de recoupement prenait des heures par cible ; il en prend désormais beaucoup moins.

La conséquence est un déplacement du risque : le message ciblé, autrefois réservé aux grandes entreprises, devient économiquement viable contre une PME de quarante personnes.

Ce qui protège : partir du principe que tout message crédible peut être faux, et raisonner par canal. Une demande sensible arrivée par courriel se confirme par un autre canal, sur un numéro déjà connu, jamais sur celui indiqué dans le message.

3. La voix synthétique et la fraude au virement

Statut : observée. Europol constate le déploiement de robots vocaux pour présélectionner des victimes à grande échelle et de scripts conversationnels générés par IA dans les centres d’appels frauduleux. La synthèse vocale permet par ailleurs d’imiter un timbre de voix à partir d’un échantillon court, ce qui rend l’appel de « la direction » ou du « conseiller bancaire » plus convaincant qu’auparavant.

Le contexte français rend cette menace sérieuse : la fraude au virement représente 13,5 % des demandes d’assistance des professionnels auprès de Cybermalveillance.gouv.fr en 2025, en progression de 93 % sur un an. Cette hausse n’est pas attribuée à l’IA par l’organisme, mais elle indique où se situe la pression.

Ce qui protège : une procédure écrite qui ne dépend d’aucune reconnaissance de voix ou de visage. Tout changement de coordonnées bancaires et tout virement au-delà d’un seuil défini exigent une validation par un second canal et par une seconde personne. C’est une mesure d’organisation, pas de technologie, et elle reste efficace quel que soit le niveau de réalisme du faux.

4. Le deepfake vidéo en visioconférence

Statut : émergente. Des cas de réunions en visioconférence où un ou plusieurs participants étaient des imitations vidéo ont été rapportés à l’international. Le phénomène reste minoritaire rapporté au volume total de la fraude, et il demande davantage de préparation qu’un simple courriel. Il faut donc le traiter comme un risque réel mais ciblé, plutôt que comme la nouvelle norme.

Le point important est que l’indice visuel n’est plus fiable. Chercher un clignement d’yeux anormal ou un artefact de compression est une stratégie perdante : la qualité progresse plus vite que l’œil de l’observateur.

Ce qui protège : exactement la même chose qu’au point 3. Une réunion ne vaut pas validation. Ce qui vaut validation, c’est une procédure documentée qui passe par un canal indépendant de la réunion elle-même.

5. Les faux interlocuteurs de longue durée

Statut : observée. L’ENISA documente la création de faux profils professionnels utilisés pour entrer en contact avec des organisations cibles, ainsi que l’usage de contenus synthétiques pour usurper l’identité de contacts de confiance dans les escroqueries à l’investissement. Il ne s’agit plus d’un message isolé mais d’une relation entretenue sur des semaines : faux candidat, faux prestataire, faux prospect.

Ce format vise moins le virement immédiat que l’accès : obtenir un document interne, un identifiant, ou simplement la confiance qui permettra la demande suivante.

Ce qui protège : vérifier l’existence réelle des interlocuteurs avant tout échange de documents sensibles, notamment lors des recrutements à distance et des prises de contact fournisseurs. Un profil professionnel n’est pas une pièce justificative.

Famille 2 : les attaques contre vos propres outils d’IA

Dès qu’une entreprise branche un assistant sur ses documents, sa messagerie ou son site, elle ajoute un composant logiciel exposé. L’OWASP, organisation de référence en sécurité applicative, maintient pour cela un Top 10 des risques propres aux applications fondées sur les modèles de langue, dont une nouvelle édition a été publiée le 3 août 2026. Les cinq menaces qui suivent en reprennent les catégories principales.

6. L’injection de prompt directe

Statut : observée. C’est le risque classé premier par l’OWASP depuis la création de son classement, et il l’est resté dans l’édition 2026. Le principe, au niveau conceptuel : un modèle de langue ne fait pas de différence structurelle entre les consignes que vous lui avez données et le texte qu’un utilisateur lui envoie. Tout arrive dans la même fenêtre de contexte, sous forme de mots. Un utilisateur qui écrit au bon endroit peut donc tenter de déplacer le comportement de l’assistant hors de ce qui était prévu.

Cela concerne directement toute entreprise qui met un agent conversationnel en contact avec le public : support client, assistant de pré-qualification commerciale, aide à la navigation sur un site.

Ce qui protège : ne jamais considérer la consigne système comme une barrière de sécurité. La protection réelle se situe en dehors du modèle : limiter ce que l’assistant a le droit de consulter, limiter ce qu’il a le droit de déclencher, filtrer et journaliser ses sorties, et ne jamais lui donner accès à une donnée qu’il ne doit pas pouvoir divulguer.

7. L’injection de prompt indirecte

Statut : émergente. Variante plus préoccupante pour l’entreprise, parce que la victime n’a rien demandé. Le principe : lorsqu’un assistant lit un contenu externe pour vous (une page web, une pièce jointe, un ticket, un courriel), ce contenu entre dans son contexte. S’il comporte du texte rédigé à destination du modèle plutôt qu’à destination du lecteur humain, l’assistant peut le traiter comme une consigne.

L’ANSSI et son homologue allemand, le BSI, mentionnent explicitement ce risque dans leurs recommandations conjointes sur les assistants de programmation fondés sur l’IA. Le sujet est devenu central avec la généralisation des assistants qui naviguent, lisent des boîtes de réception et parcourent des dépôts de code.

Ce qui protège : traiter tout contenu externe comme non fiable, même issu d’une source habituelle. Concrètement : un assistant qui lit des contenus externes ne doit pas disposer en même temps du droit d’envoyer, de publier ou de payer. La séparation entre lecture du monde extérieur et action sur vos systèmes est la seule défense robuste connue à ce jour.

8. L’agent doté de trop de pouvoir

Statut : structurelle. C’est le changement le plus significatif de l’édition 2026 du classement OWASP : la catégorie de l’autonomie excessive, sixième en 2025, passe à la troisième place. Elle ne décrit pas une attaque mais une erreur de conception : donner à une automatisation plus de droits qu’elle n’en a besoin, ou la laisser agir sans point de validation humain.

Le risque ne vient pas de la malveillance du modèle mais de la combinaison : une consigne mal interprétée, ou une injection réussie au point 7, se transforme en action réelle uniquement si l’agent possède les droits pour l’exécuter. Le même incident produit un texte inutile dans un cas, un courriel envoyé à toute la base client dans l’autre.

Ce qui protège : le moindre privilège, appliqué aux agents comme il l’est aux comptes utilisateurs. Un compte technique dédié par automatisation, des droits en lecture seule par défaut, une validation humaine explicite sur toute action irréversible (envoi, suppression, paiement, publication), et une journalisation complète. Ce sujet est détaillé dans notre formation aux agents IA.

9. La fuite du contexte et des instructions internes

Statut : démontrée en recherche. L’édition 2026 du classement OWASP a élargi cette catégorie, jusque-là limitée à la divulgation de la consigne système, à l’ensemble du contexte caché d’une application. Le principe : tout ce que vous placez dans le contexte d’un assistant, y compris ce que l’utilisateur ne voit pas à l’écran, peut finir par apparaître dans une réponse.

L’enjeu n’est pas la perte de votre formulation élégante de consigne. C’est ce qui se trouve autour : un extrait de base interne, une clé d’accès laissée dans une configuration, des règles métier confidentielles, la liste des sources consultées.

Ce qui protège : ne rien mettre dans un contexte d’IA qui ne puisse pas devenir public. Les secrets d’authentification n’ont rien à y faire, et les règles sensibles doivent être appliquées par le code qui entoure le modèle, pas écrites dans la consigne.

10. L’empoisonnement des données et du modèle

Statut : démontrée en recherche. Le CERT-FR cite l’empoisonnement de modèles parmi les atteintes possibles aux systèmes d’IA eux-mêmes, et la CNIL identifie de longue date l’empoisonnement, l’inversion de modèle et l’extraction de données d’entraînement comme des vecteurs d’attaque à prendre en compte dès la conception.

Pour une PME, le scénario réaliste n’est pas l’altération du modèle d’un grand fournisseur. C’est beaucoup plus prosaïque : la base documentaire que vous donnez à lire à votre assistant interne. Si n’importe qui peut y déposer un document, n’importe qui peut influencer les réponses que l’assistant donnera à vos salariés. Un tarif périmé, une procédure modifiée ou une consigne insérée dans un document deviennent la vérité de référence de l’outil.

Ce qui protège : traiter la base de connaissances comme un actif contrôlé. Dépôt restreint à des personnes identifiées, revue des documents avant indexation, date de mise à jour visible, et affichage systématique des sources dans les réponses pour rendre une anomalie détectable.

Famille 3 : la fuite de données par l’usage quotidien

Cette famille est la moins spectaculaire et, dans les faits, la plus fréquente. Elle ne suppose aucun attaquant. Elle suppose seulement un salarié pressé et un outil disponible.

11. Les données confidentielles saisies dans un outil grand public

Statut : observée. Coller un contrat pour le résumer, un fichier client pour le trier, un dossier médical pour le reformuler, un extrait de code propriétaire pour le corriger : dans chacun de ces gestes, la donnée quitte l’entreprise et entre chez un prestataire, avec des conditions contractuelles que personne n’a lues.

Il faut ici être précis, parce que le sujet est souvent traité de manière binaire. Dire qu’un assistant est « sécurisé » ou « conforme au RGPD » n’a pas de sens en soi : la conformité ne s’attache pas à l’outil mais à l’usage que vous en faites, à l’offre souscrite, à la localisation des traitements, à la base légale retenue, à la durée de conservation et à la chaîne de sous-traitance. Deux entreprises utilisant le même outil peuvent être l’une conforme et l’autre non.

Ce qui protège : une règle courte, écrite et connue de tous, qui dit quelles catégories de données ne sortent jamais. Le reste suit : choix d’une offre professionnelle avec des garanties contractuelles écrites, vérification de la réutilisation éventuelle des contenus pour l’entraînement, et registre des traitements tenu à jour. Le détail des réglages et des étapes figure dans notre guide pour sécuriser ChatGPT en entreprise ; notre formation IA et RGPD traite ce cadrage, et le modèle de charte d’utilisation de l’IA en entreprise donne la base du document.

12. Le shadow AI

Statut : observée. Le shadow AI désigne l’usage d’outils d’IA non validés par l’entreprise, souvent sur un compte personnel et parfois depuis un appareil personnel. Il ne résulte pas d’un acte de défiance mais d’un vide : quand aucun outil n’est fourni et qu’aucune règle n’est énoncée, chacun choisit le sien.

Les conséquences sont cumulatives : aucune visibilité sur les données sorties, aucune révocation possible quand la personne quitte l’entreprise, aucune traçabilité en cas de contrôle, et une hétérogénéité de qualité dans les productions.

Ce qui protège : l’interdiction seule ne fonctionne pas, elle déplace l’usage vers le téléphone personnel. Ce qui fonctionne : fournir un outil officiel correct, dire clairement ce qui est autorisé, et former. Le sujet rejoint celui du choix des outils.

13. Les extensions et connecteurs non maîtrisés

Statut : émergente. Autour des assistants s’est constitué un écosystème d’extensions de navigateur, de modules complémentaires bureautiques et de connecteurs qui promettent d’ajouter l’IA à un outil existant. Beaucoup demandent, pour fonctionner, un accès large : lecture de toutes les pages visitées, accès à la messagerie, accès aux fichiers d’un espace de stockage.

Le risque est double : la permission accordée dépasse souvent le besoin réel, et l’éditeur peut changer, être revendu ou être compromis après l’installation. L’autorisation, elle, reste active.

Ce qui protège : une liste d’extensions autorisées, une revue périodique des autorisations accordées aux applications tierces sur vos comptes professionnels, et le réflexe de révoquer ce qui n’est plus utilisé. Cette revue prend une heure par trimestre et évite des surprises durables.

14. La rétention et la réutilisation des données saisies

Statut : structurelle. Ce n’est pas une attaque, c’est un paramètre. Selon l’offre souscrite et les réglages du compte, ce que vous saisissez peut être conservé pendant une durée variable, consultable par le fournisseur dans certains cas d’abus ou de support, et éventuellement réutilisé pour améliorer les modèles. Ces règles diffèrent entre une offre gratuite, une offre individuelle payante, une offre équipe et un accès par interface de programmation, et elles changent au fil des mises à jour contractuelles.

Un second effet est souvent ignoré : les fonctions de mémoire persistante, qui conservent d’une conversation à l’autre des informations sur l’utilisateur et son travail. Pratiques pour un usage personnel, elles créent un stock de données professionnelles hors de votre contrôle.

Ce qui protège : aller lire les paramètres du compte plutôt que les pages commerciales, vérifier explicitement le réglage de réutilisation des contenus, décider si la mémoire persistante est activée, et refaire cette vérification au moins une fois par an. Nos repères sur les limites de l’IA complètent ce point.

Famille 4 : le code et la chaîne logicielle

Cette famille concerne les entreprises qui développent, mais aussi celles qui font développer. L’ANSSI et le BSI allemand ont publié des recommandations conjointes consacrées aux assistants de programmation fondés sur l’IA, en rappelant que ces outils induisent de nouveaux risques de sécurité et doivent être abordés avec précaution, en particulier lorsqu’ils reposent sur des services mutualisés accessibles par internet.

15. Les vulnérabilités dans le code généré

Statut : observée. Un assistant de programmation produit du code qui fonctionne, ce qui n’est pas la même chose qu’un code sûr. Il reproduit les habitudes majoritaires de ses données d’entraînement, y compris les mauvaises : gestion approximative des entrées utilisateur, contrôles d’accès absents parce que non demandés, secrets écrits en clair, dépendances anciennes.

Le problème s’aggrave avec la vitesse : un développeur produit davantage de code qu’avant, donc davantage de code à relire, dans une équipe dont la capacité de relecture n’a pas augmenté.

Ce qui protège : ne pas réduire la revue de code sous prétexte de gain de productivité, maintenir l’analyse automatisée dans la chaîne d’intégration, et considérer une production de l’assistant comme une proposition d’un développeur junior rapide et sans mémoire des exigences de votre organisation.

16. Les dépendances inventées par l’IA

Statut : émergente. Un assistant peut suggérer d’installer une bibliothèque qui n’existe pas. Le nom paraît plausible, la syntaxe est correcte, et le développeur pressé lance l’installation. Le risque apparaît lorsqu’un tiers, ayant observé que les modèles inventent régulièrement le même nom, publie un paquet portant ce nom dans un dépôt public. Ce phénomène est désigné sous le terme de slopsquatting, et il figure parmi les risques identifiés dans les travaux conjoints de l’ANSSI et du BSI.

Ce qui protège : vérifier l’existence et la réputation de toute nouvelle dépendance avant installation, figer les versions, passer par un miroir interne des dépôts publics quand c’est possible, et maintenir un inventaire des composants logiciels.

17. La compromission de la chaîne d’approvisionnement IA

Statut : émergente. Le CERT-FR cite la compromission de chaîne logicielle parmi les atteintes visant les systèmes d’IA, et l’OWASP maintient une catégorie dédiée à ce risque. Le périmètre s’est élargi : il ne s’agit plus seulement des bibliothèques logicielles, mais aussi des modèles téléchargés depuis des dépôts publics, des jeux de données d’ajustement, des extensions et des serveurs de connexion qui relient un assistant à vos outils internes.

Chacun de ces éléments est un composant exécuté ou interprété dans votre environnement, avec des droits, et souvent installé sans passer par le circuit habituel de validation des logiciels.

Ce qui protège : faire entrer les composants d’IA dans le processus existant de gestion des fournisseurs et des logiciels. Origine identifiée, version figée, mise à jour suivie, droits limités, et suppression de ce qui n’est plus utilisé.

Famille 5 : l’information, la réputation et les coûts

Les trois dernières menaces ne provoquent pas d’intrusion. Elles produisent une perte : de crédibilité, de justesse, ou d’argent.

18. L’usurpation de marque et les contenus faux

Statut : observée. Produire un site qui ressemble au vôtre, un communiqué signé de votre dirigeant, une fausse offre d’emploi à votre nom ou une série d’avis clients inventés coûte désormais quelques minutes. Europol observe que la génération de contenus permet aux réseaux criminels de personnaliser leurs scénarios avec facilité, notamment pour usurper l’identité d’institutions de confiance.

L’entreprise visée découvre en général le problème par un tiers : un client qui appelle pour vérifier, un candidat qui s’étonne, un fournisseur qui a reçu des coordonnées bancaires modifiées.

Ce qui protège : une surveillance simple du nom de l’entreprise et du nom des dirigeants, l’enregistrement des noms de domaine proches du vôtre, une page officielle qui centralise vos canaux légitimes, et une procédure de signalement prête à l’avance. La rapidité de réaction compte davantage que la prévention, qui est ici largement hors de votre contrôle.

19. La décision prise sur une sortie non vérifiée

Statut : observée. L’OWASP classe la production d’informations inexactes parmi ses dix risques principaux, et l’a même fait remonter dans son édition 2026. Ce n’est pas une attaque : c’est une propriété des modèles. Ils produisent une réponse plausible, avec le même ton assuré qu’elle soit juste ou fausse.

Le risque devient sérieux quand la sortie sert de base à une décision : une clause contractuelle reformulée de travers, un calcul réglementaire erroné, une réponse à un client fondée sur une jurisprudence qui n’existe pas. La responsabilité, elle, reste entièrement celle de l’entreprise.

Ce point rejoint une obligation juridique. Le règlement européen 2024/1689 sur l’intelligence artificielle impose, à son article 4, que les fournisseurs et les déployeurs de systèmes d’IA veillent à un niveau suffisant de maîtrise de l’IA parmi les personnes chargées de les utiliser pour leur compte. Par ailleurs, l’article 22 du RGPD encadre les décisions fondées exclusivement sur un traitement automatisé et produisant des effets juridiques.

Ce qui protège : définir, par cas d’usage, ce qui doit être vérifié et par qui. Un résumé de réunion interne et une réponse juridique adressée à un client n’appellent pas le même contrôle. C’est l’objet de notre formation cybersécurité et IA.

20. La consommation et les coûts non maîtrisés

Statut : émergente. La catégorie de la consommation non bornée est passée de la dixième à la sixième place dans l’édition 2026 du classement OWASP. Elle recouvre deux situations distinctes. La première est accidentelle : une automatisation mal conçue qui boucle, un agent qui relance des appels sans limite, une facture qui dépasse le budget annuel en trois jours. La seconde est délibérée : un tiers qui exploite un assistant public mal protégé pour faire exécuter ses propres traitements à vos frais.

Ce qui protège : des plafonds de dépense définis sur chaque clé d’accès, une limitation du nombre d’appels, des alertes de dépassement, et l’usage de clés distinctes par projet pour pouvoir en révoquer une sans arrêter tout le reste.

Ce que l’IA ne change pas

Un constat s’impose à la lecture des vingt menaces : la plupart des parades sont des mesures que la cybersécurité recommande depuis quinze ans. L’IA n’a pas rendu obsolètes l’authentification multifacteur, les sauvegardes hors ligne, le cloisonnement des accès, les mises à jour ou la double validation des paiements. Elle a rendu plus coûteux le fait de ne pas les avoir.

Trois éléments seulement sont réellement nouveaux. D’abord, le signal linguistique de la fraude a disparu : la formation des salariés doit changer de contenu. Ensuite, l’entreprise expose désormais des composants d’IA qui ont leurs propres vulnérabilités : c’est un nouveau périmètre à inventorier. Enfin, l’arrivée des agents introduit la question du droit d’agir : elle appelle des règles d’habilitation, pas une nouvelle technologie de défense.

Reste la question symétrique, que ce dossier ne traite pas : l’IA sert aussi à se défendre. Nous l’avons traitée à part, en détaillant quinze cas d’usage défensifs avec leurs bénéfices, leurs limites et le niveau de supervision requis, dans notre dossier sur les moyens d’utiliser l’IA pour renforcer la cybersécurité de son entreprise.

Le plan d’action en dix mesures

Les mesures ci-dessous sont classées par rapport entre effet obtenu et effort demandé. Une PME peut mettre les six premières en place en quelques semaines sans investissement technique.

Que faire en cas d’incident

Trois réflexes, dans cet ordre. Contenir d’abord : isoler le poste ou le compte concerné, révoquer les accès et les clés, contacter la banque immédiatement s’il s’agit d’un virement. Conserver ensuite : ne pas effacer les traces, les journaux ni les messages, ils seront nécessaires. Déclarer enfin.

• Cybermalveillance.gouv.fr oriente les victimes, particuliers comme professionnels, et met en relation avec des prestataires référencés.
• Plainte auprès des services de police ou de gendarmerie, indispensable pour les démarches assurantielles et bancaires.
• CNIL : en cas de violation de données personnelles, le responsable de traitement notifie dans les 72 heures après en avoir pris connaissance, sauf si la violation n’est pas susceptible d’engendrer un risque pour les personnes.
• ANSSI : pour les opérateurs et administrations relevant de son périmètre, selon les obligations applicables.

Questions fréquentes

L’IA permet-elle vraiment à n’importe qui de mener une cyberattaque ?

Non, et c’est le point sur lequel le CERT-FR est le plus explicite : aucun système d’IA générative n’a été en mesure de mener de manière autonome toutes les étapes d’une attaque informatique. L’IA abaisse le coût de certaines étapes, en particulier la rédaction et le profilage. Pour les attaquants déjà compétents, elle sert de démultiplicateur ; pour les débutants, elle joue surtout un rôle d’apprentissage.

Comment repérer un courriel d’hameçonnage écrit par une IA ?

Il ne faut plus chercher à le repérer à la langue. Les critères qui restent valables sont extérieurs au texte, et ils sont détaillés à la menace 1. Un signal supplémentaire mérite d’être connu : lorsque le message fournit lui-même le numéro ou le lien par lequel le vérifier, c’est que la vérification fait partie du piège. Une confirmation ne vaut que si elle emprunte un canal issu de vos propres répertoires.

Peut-on dire que ChatGPT est conforme au RGPD ?

La question est mal posée. La conformité ne s’attache pas à un outil mais à un traitement : quelles données, pour quelle finalité, sur quelle base légale, avec quelle durée de conservation, quels sous-traitants et quelles garanties contractuelles. Le même outil peut être utilisé de manière conforme dans une entreprise et non conforme dans une autre. L’offre souscrite change par ailleurs les garanties applicables.

Qu’est-ce qu’une injection de prompt, en une phrase ?

C’est le fait qu’un modèle de langue ne distingue pas structurellement vos consignes du texte qu’il reçoit : tout se présente à lui sous la même forme, ce qui rend possible un déplacement de son comportement par le contenu lui-même. C’est le premier risque du classement OWASP.

Faut-il interdire ChatGPT dans mon entreprise ?

L’interdiction pure et simple déplace généralement l’usage vers les appareils personnels, où vous n’avez plus aucune visibilité. La combinaison qui fonctionne est autre : fournir un outil officiel avec une offre professionnelle, écrire une charte courte qui dit ce qui ne sort jamais, et former les équipes. L’encadrement coûte moins cher que la reprise en main après coup.

Les deepfakes vidéo sont-ils un risque réel pour une PME ?

Le risque existe, mais il demeure rare au regard du volume de la fraude ordinaire. La voix synthétique et le courriel ciblé sont statistiquement bien plus probables. La bonne nouvelle est que la parade est la même pour les trois : une procédure de validation qui ne repose ni sur la reconnaissance d’une voix, ni sur celle d’un visage.

Qu’est-ce que le shadow AI ?

L’usage d’outils d’IA non validés par l’entreprise, souvent sur des comptes personnels. Il ne traduit pas une volonté de contournement mais l’absence d’une offre officielle : quand rien n’est fourni ni dit, chacun choisit son outil.

Mes données servent-elles à entraîner les modèles ?

Cela dépend de l’offre, du réglage du compte et de la version des conditions contractuelles en vigueur. Les offres professionnelles et les accès par interface de programmation sont généralement traités différemment des offres grand public. La seule réponse fiable se trouve dans les paramètres de votre compte et dans le contrat que vous avez signé, pas dans une page de présentation commerciale. Cette vérification est à refaire au moins une fois par an.

Un agent IA peut-il agir seul sur mes systèmes ?

Uniquement dans la mesure des droits que vous lui avez donnés. C’est précisément pour cela que l’autonomie excessive est montée à la troisième place du classement OWASP 2026. La bonne question n’est pas « l’agent est-il fiable ? » mais « que peut-il déclencher au pire, et qui valide avant ? ».

Le code produit par une IA est-il moins sûr ?

Il n’est pas intrinsèquement moins sûr, mais il reproduit les usages majoritaires de ses données d’entraînement, bons comme mauvais, et il arrive en plus grande quantité. Le risque réel vient du déséquilibre entre un volume de code produit en hausse et une capacité de relecture inchangée. L’ANSSI et le BSI ont publié des recommandations conjointes sur ce sujet.

Que dit l’AI Act sur la sécurité ?

Le règlement européen 2024/1689 impose notamment, à son article 4, que les fournisseurs et les déployeurs de systèmes d’IA veillent à un niveau suffisant de maîtrise de l’IA parmi les personnes qui les utilisent. L’article 50 prévoit des obligations de transparence pour certains contenus générés ou manipulés. La formation des équipes n’est donc plus seulement une bonne pratique de sécurité.

Par où commencer si mon entreprise n’a rien mis en place ?

Par la double validation des paiements et des changements de coordonnées bancaires, puis par une charte d’usage d’une page. Ces deux mesures ne coûtent rien, couvrent les menaces les plus probables et les plus coûteuses, et peuvent être en place avant la fin de la semaine.

Sources

• CERT-FR, L’IA générative face aux attaques informatiques, référence CERTFR-2026-CTI-001, 4 février 2026.
• ANSSI, Panorama de la cybermenace, référence CERTFR-2026-CTI-002.
• ANSSI et BSI, recommandations de sécurité relatives aux assistants de programmation fondés sur l’IA, cyber.gouv.fr.
• ENISA, Threat Landscape 2025.
• Europol, Internet Organised Crime Threat Assessment (IOCTA) 2026.
• CNIL, fiches sécurité relatives à la conception et à l’apprentissage des systèmes d’IA, et recommandations sur le développement des systèmes d’IA.
• Cybermalveillance.gouv.fr, rapport d’activité et état de la menace 2025.
• OWASP Gen AI Security Project, Top 10 for LLM Applications, éditions 2025 et 2026 (édition 2026 publiée le 3 août 2026).
• Règlement (UE) 2024/1689 établissant des règles harmonisées concernant l’intelligence artificielle.

Pour aller plus loin

• Sécuriser ChatGPT en entreprise : les 8 étapes et la liste de vérification en 15 points.
• Utiliser l’IA pour renforcer la cybersécurité de son entreprise : 15 cas d’usage défensifs concrets.
• Comment utiliser l’intelligence artificielle en entreprise : 20 exemples concrets et leur cadre.
• Charte d’utilisation de l’IA en entreprise : la base du document à diffuser.
• Ce que l’IA ne sait pas faire : les limites à connaître avant de lancer un projet.
• Quelle formation IA choisir : repères, financements et critères de sélection.