Protection des données à l'ère de l'IA : risques et parades

Ce que l'IA change vraiment à la protection des données#

Pendant vingt ans, protéger des données a voulu dire contrôler leur circulation : qui y accède, par quel canal, vers où elles partent. Chiffrement en transit, cloisonnement, journalisation des accès, sauvegardes. Ce modèle mental reste juste, et il est devenu insuffisant.

L'intelligence artificielle introduit un mode de fuite que les dispositifs classiques ne voient pas : une donnée peut être absorbée par un modèle, puis ressortir ailleurs, sous une autre forme, sans qu'aucun fichier n'ait été copié. Aucun transfert à bloquer, aucune pièce jointe à inspecter, aucun accès anormal à détecter. La donnée n'a pas été volée : elle a été apprise.

C'est le déplacement conceptuel qu'il faut opérer avant tout le reste. La question n'est plus seulement « qui peut lire cette donnée ? » mais « qu'est-ce qui a été appris à partir d'elle, et où ce qui a été appris se trouve-t-il maintenant ? ».

Cet article fait le tour du sujet : ce qui change, les risques réellement nouveaux, ce que l'IA apporte en défense — car elle apporte beaucoup —, et le cadre réglementaire qui s'applique déjà.

Les risques nouveaux, et ceux qui ne le sont pas#

Un discours ambiant présente l'IA comme un cataclysme de sécurité. La réalité est plus intéressante : la majorité des incidents restent classiques — un accès mal révoqué, une sauvegarde exposée, un identifiant partagé. L'IA amplifie ceux-là et en ajoute quelques-uns qui lui sont propres.

Ce qui n'est pas nouveau, mais s'aggrave. L'hameçonnage rédigé dans un français impeccable, personnalisé à partir d'informations publiques, produit à grande échelle. La reconnaissance vocale imitée pour un appel de fraude au président. Ces attaques existaient ; elles étaient limitées par le coût de production du texte crédible. Ce coût a chuté.

Ce qui est réellement nouveau. L'absorption, la restitution et l'inférence décrites plus haut. Auxquelles s'ajoute une famille propre aux systèmes conversationnels : l'injection d'instruction, où un contenu apparemment inoffensif — une page web, un document joint, un courriel — contient des instructions destinées au modèle qui le lira. Un assistant qui résume vos courriels peut ainsi recevoir un ordre venu de l'extérieur.

Ce qui devient critique alors qu'on l'ignorait. La traçabilité des sources : quand un système produit une réponse, savoir sur quelles données il s'est appuyé n'était pas un enjeu tant qu'un humain rédigeait. Cela devient la seule façon de répondre à « d'où sort cette affirmation ? » — et cette question arrive toujours au mauvais moment.

L'autre versant : ce que l'IA protège#

Il serait malhonnête de ne présenter que le risque. L'IA est aussi, aujourd'hui, l'un des meilleurs outils de défense disponibles, et pour une raison structurelle : la sécurité est un problème de détection d'anomalies dans un volume que personne ne peut lire.

Un analyste humain ne peut pas parcourir des millions d'événements par jour. Un modèle le peut, et il excelle précisément là où les règles fixes échouent : repérer qu'un accès légitime survient à une heure inhabituelle, depuis un contexte inhabituel, sur un périmètre inhabituel — aucune règle n'est violée, et pourtant l'ensemble ne ressemble pas au comportement normal de cette personne.

Trois usages sont matures. La détection comportementale signale l'écart plutôt que la signature, donc attrape ce qui n'a pas encore de nom. La classification automatique identifie les données sensibles dans des dépôts que personne n'a cartographiés depuis des années — l'inventaire est le préalable de toute protection, et c'est la tâche que les organisations remettent indéfiniment. Le tri des alertes enfin : la plupart des équipes de sécurité ne souffrent pas d'un manque d'alertes mais d'une noyade, et hiérarchiser est exactement ce qu'un modèle sait faire.

La lucidité s'impose sur un point : ces systèmes produisent des faux positifs, et un dispositif qui crie trop souvent finit désactivé. La valeur ne vient pas du modèle seul mais du réglage de son seuil — c'est-à-dire d'une décision humaine sur le niveau de bruit acceptable.

Le cadre : ce qui s'applique déjà#

Deux textes se superposent, et les confondre coûte cher.

Le règlement général sur la protection des données n'a pas changé. Ses principes s'appliquent intégralement à un traitement par intelligence artificielle : une finalité déterminée avant la collecte, une minimisation réelle des données traitées, une durée de conservation fixée, une base légale, et les droits des personnes — accès, rectification, effacement. Le point sensible avec l'IA est l'effacement : retirer une donnée d'une base est simple, la retirer d'un modèle qui l'a apprise ne l'est pas. Cette difficulté ne suspend pas l'obligation ; elle impose de réfléchir en amont à ce qui entre dans un entraînement.

Le règlement européen sur l'intelligence artificielle ajoute une couche propre au système lui-même. Son calendrier a bougé, et l'interprétation courante est fausse : les obligations applicables aux systèmes à haut risque ont bien été reportées — fin 2027 pour les systèmes autonomes visés par l'annexe III, 2028 pour l'IA intégrée dans des produits déjà réglementés —, mais les obligations de transparence de l'article 50 s'appliquent depuis le 2 août 2026. Elles imposent d'informer une personne qu'elle interagit avec un système d'IA, et de marquer les contenus synthétiques dans un format lisible par machine. Les sanctions prévues atteignent quinze millions d'euros ou trois pour cent du chiffre d'affaires mondial, et le champ est extraterritorial : ce qui compte n'est pas où vous êtes établi, mais où le résultat est utilisé.

Nous détaillons ce point dans un article dédié : conformité AI Act, prouver plutôt que déclarer.

Sept réflexes qui changent le niveau de risque#

Aucun n'exige de projet, tous exigent une décision.

Décider ce qui n'entre jamais dans un outil externe. Une liste courte, écrite, connue : données de santé, données de mineurs, secrets industriels, données de clients sous contrat de confidentialité. Une règle non écrite n'est pas une règle.

Fournir une alternative interne. Interdire sans proposer produit l'usage clandestin, qui est le pire des mondes : le risque demeure et la visibilité disparaît. C'est la leçon de vingt ans de gouvernance des outils.

Vérifier ce que devient ce qui est saisi. Les conditions d'usage des services diffèrent radicalement sur un point : votre contenu sert-il à améliorer le modèle ? Cette réponse figure dans le contrat, elle se négocie, et elle change tout.

Séparer les environnements. Un assistant qui traite des documents publics ne doit pas être le même que celui qui touche à la comptabilité. La séparation coûte peu à la conception et devient impossible à rattraper une fois les usages installés.

Journaliser les usages de l'IA comme n'importe quel accès. Qui a demandé quoi, à quel système, sur quelles données. Sans cela, une question aussi simple que « ce document est-il passé par un modèle ? » reste sans réponse.

Traiter les entrées comme non fiables. Un document, une page web ou un courriel lu par un assistant peut contenir des instructions. Le principe est identique à celui qui gouverne la sécurité applicative depuis toujours : ne jamais exécuter ce qui vient de l'extérieur sans contrôle.

Écrire la conduite en cas d'incident IA. Que fait-on si une donnée sensible a été saisie dans un service externe ? La réponse s'écrit à froid, pas le jour où cela arrive.

Ce que l'IA générative change en particulier#

Les modèles génératifs ajoutent trois difficultés que les systèmes prédictifs classiques ne posaient pas.

La frontière entre donnée et instruction disparaît. Dans un système ordinaire, les données arrivent par un canal et les commandes par un autre. Un modèle de langage reçoit tout sous la même forme — du texte. C'est ce qui rend l'injection d'instruction possible, et c'est structurel : aucun correctif ne sépare rétroactivement ce qui arrive par le même tuyau.

La sortie est plausible même quand elle est fausse. Un système classique en erreur produit une erreur visible ; un modèle génératif produit une réponse bien formée. Appliqué à la sécurité, cela signifie qu'un rapport d'incident rédigé automatiquement peut être convaincant et inexact. D'où la règle : un modèle propose, un humain valide ce qui engage.

La donnée d'entraînement laisse une empreinte durable. Un fichier supprimé disparaît ; un fichier appris a modifié des paramètres. Cette asymétrie est le cœur du problème d'effacement, et elle impose une discipline en amont : décider ce qui entre dans un entraînement est une décision plus lourde que décider ce qu'on stocke.

Nous consacrons un article distinct à la façon dont ces sorties se prouvent : de la trace immuable à la preuve opposable.

Les questions à poser à un fournisseur#

Cinq questions écrites, cinq réponses écrites. Elles suffisent à classer une offre.

Que devient ce que nous saisissons ? Conservé combien de temps, utilisé pour améliorer un modèle, accessible à qui. Une réponse évasive sur ce point est une réponse.

Où sont traitées et stockées les données ? La localisation détermine le régime juridique applicable et les possibilités de transfert. C'est une question de droit avant d'être une question technique.

Que se passe-t-il à la sortie du contrat ? Récupération des contenus, suppression effective, délai, preuve de suppression. Et surtout : ce qui a été appris de vos données reste-t-il dans un modèle après votre départ ?

Quelles traces nous remettez-vous ? Un journal des accès et des traitements, exportable, qui vous appartienne. Sans cela, vous ne pourrez rien démontrer, ni à un auditeur ni à un client.

Comment isolez-vous nos données de celles de vos autres clients ? La réponse attendue décrit un mécanisme — cloisonnement, chiffrement par client, environnement dédié — pas une intention.

Un fournisseur sérieux répond aux cinq par écrit en quelques jours. Un fournisseur qui propose une réunion pour en discuter vous dit déjà quelque chose.

La question qui structure tout : où vivent vos données quand un système apprend ?#

Un dernier angle, moins souvent traité, et pourtant décisif à moyen terme.

Quand une organisation confie ses documents, ses procédures et son historique à un service extérieur pour en tirer un assistant compétent, elle transfère bien plus que des fichiers : elle transfère la matière de son savoir-faire. La question du jour de la rupture — changement de tarif, de conditions, de propriétaire — n'est pas « puis-je récupérer mes fichiers ? », mais « que reste-t-il de ce qui a été appris ? ».

C'est ce qui nous a conduits à concevoir l'intelligence comme un objet que l'on possède plutôt qu'un service auquel on s'abonne : un artefact scellé, chiffré, dont le contenu et les droits d'usage voyagent avec l'objet, et dont la validité se vérifie sans dépendre de qui que ce soit. Le sujet dépasse la cybersécurité — nous le traitons dans ce qu'est une capsule d'intelligence —, mais il commence par une question de protection des données : ce qui a été appris de vous vous appartient-il ?

Par où commencer si vous partez de zéro#

Trois semaines suffisent pour passer d'une situation opaque à une situation gouvernée.

Semaine un, l'inventaire. Quels outils d'IA sont réellement utilisés dans l'organisation, par qui, sur quelles données ? La réponse surprend presque toujours : les usages précèdent les politiques, et une part notable passe par des comptes personnels.

Semaine deux, la ligne rouge. Écrire la liste courte de ce qui n'entre jamais dans un outil externe, et la diffuser. Pas un document de vingt pages : une page que les équipes liront.

Semaine trois, l'alternative et le journal. Fournir un outil interne pour les usages courants, et journaliser. À partir de là, vous avez une base : un périmètre connu, une règle écrite, une trace.

Le reste — analyse d'impact, classification fine, marquage des contenus, contrats fournisseurs — se construit ensuite, et se construit mieux sur cette base que sur une page blanche.

Questions fréquentes#

Les données saisies dans un assistant IA sont-elles utilisées pour l'entraîner ?#

Cela dépend entièrement du service et de la formule souscrite : certains l'excluent contractuellement, d'autres l'autorisent par défaut avec une possibilité de refus, d'autres encore ne le précisent pas clairement. C'est la première clause à vérifier, et elle se négocie dans un contrat professionnel. Tant que la réponse n'est pas écrite noir sur blanc, considérez que ce qui est saisi peut être conservé et exploité — c'est l'hypothèse prudente, et elle coûte peu.

Le RGPD s'applique-t-il aux modèles d'intelligence artificielle ?#

Oui, intégralement, dès lors que des données personnelles sont traitées — à la collecte, à l'entraînement, à l'utilisation. Les principes ne changent pas : finalité déterminée, minimisation, durée de conservation, base légale, droits des personnes. La difficulté propre à l'IA porte sur l'effacement : retirer une donnée d'une base est simple, la retirer d'un modèle qui l'a apprise ne l'est pas. Cette difficulté technique ne crée aucune exception juridique ; elle impose d'anticiper ce qui entre dans un entraînement.

Faut-il interdire les assistants IA dans l'entreprise ?#

L'interdiction sans alternative produit l'usage clandestin : le risque demeure et la visibilité disparaît. La stratégie qui fonctionne consiste à écrire une liste courte de ce qui n'entre jamais dans un outil externe, à fournir un outil interne pour le reste, et à journaliser les usages. On obtient alors un périmètre connu au lieu d'une politique respectée par ceux qui l'auraient respectée de toute façon.

Qu'est-ce que l'injection d'instruction, et pourquoi est-ce nouveau ?#

C'est le fait qu'un contenu lu par un assistant — page web, document joint, courriel — contienne des instructions destinées au modèle. Un assistant qui résume votre boîte de réception peut ainsi recevoir un ordre venu de l'extérieur. C'est nouveau parce que, dans les systèmes classiques, données et instructions circulent par des canaux séparés ; avec un modèle de langage, tout arrive par le même canal — du texte. Le réflexe à adopter est celui de la sécurité applicative : ne jamais exécuter ce qui vient de l'extérieur sans contrôle.

L'IA améliore-t-elle réellement la cybersécurité, ou est-ce un argument commercial ?#

Elle l'améliore réellement sur trois usages matures : la détection d'anomalies comportementales, la classification automatique des données sensibles, et le tri des alertes. Son avantage structurel est le volume : un analyste ne peut pas lire des millions d'événements, un modèle le peut. Sa limite est le faux positif — un dispositif qui crie trop souvent finit désactivé. La valeur vient donc autant du réglage du seuil que du modèle lui-même, et ce réglage est une décision humaine.

Que dit exactement le règlement européen sur l'IA aujourd'hui ?#

Le calendrier a été modifié en 2026 : les obligations applicables aux systèmes à haut risque ont été reportées à fin 2027 pour les systèmes autonomes de l'annexe III et à 2028 pour l'IA intégrée dans des produits réglementés. En revanche, les obligations de transparence de l'article 50 s'appliquent depuis le 2 août 2026 : informer les personnes qu'elles interagissent avec une IA, et marquer les contenus synthétiques de façon lisible par machine. Conclure que « tout a été reporté » est l'erreur d'interprétation la plus répandue.

À retenir#

L'IA n'ajoute pas un risque à une liste : elle change la nature du risque. Une donnée peut être absorbée par un modèle, restituée ailleurs, ou déduite sans avoir jamais été collectée — trois chemins que les dispositifs classiques ne voient pas, parce qu'aucun fichier ne bouge.

En face, l'IA est aussi l'un des meilleurs outils de défense disponibles, sur la détection d'anomalies, la classification et le tri des alertes. Ce n'est ni une menace ni un sauveur : c'est un déplacement du terrain.

Le cadre, lui, n'attend pas : le RGPD s'applique intégralement, et les obligations de transparence du règlement européen sur l'IA sont en vigueur depuis août 2026. La bonne nouvelle est que les réflexes qui protègent réellement — une liste rouge écrite, une alternative interne, des environnements séparés, des usages journalisés — ne coûtent rien d'autre que des décisions.