Cybersécurité
Données confidentielles et IA générative : le risque que l'on ne voit pas
Copier-coller un contrat, un code source ou un dossier client dans un assistant IA paraît anodin. C'est pourtant l'une des fuites de données les plus difficiles à maîtriser, car elle passe par des outils que l'on croit inoffensifs.
Un geste banal, une fuite silencieuse
La scène se répète dans toutes les organisations. Un collaborateur ouvre un assistant IA, colle un paragraphe d'un contrat commercial pour le résumer, puis un fragment de code source interne pour le déboguer, puis un extrait d'un tableur client pour le mettre en forme. Chaque action paraît isolée, utile, sans conséquence. Multipliées par dizaines chaque jour, elles constituent pourtant un risque de fuite de données continu, souvent invisible et difficile à maîtriser.
Le problème ne tient pas à l'outil lui-même, mais à ce que l'on en fait. Selon l'outil, le type de compte, sa configuration et les conditions contractuelles applicables, les contenus transmis peuvent être conservés, traités ou, dans certains cas, réutilisés par le fournisseur à des fins d'amélioration de ses services ou de ses modèles. Ils peuvent également être traités sur des infrastructures situées hors de l'Union européenne. La frontière entre une fonctionnalité et une vulnérabilité est ténue, et elle dépend rarement du salarié qui agit.
Ce phénomène porte un nom : le shadow AI. Il désigne l'usage d'outils d'intelligence artificielle en dehors de tout cadre défini par l'entreprise. À la différence du shadow IT traditionnel, il ne laisse presque aucune trace : pas de nouveau serveur, pas de logiciel installé, juste un onglet de navigateur ouvert sur une page que tout le monde utilise légitimement.
Ce qui sort réellement de l'entreprise
Les informations transmises couvrent rarement un seul type de donnée. Un prompt contient souvent, sans que l'auteur en ait conscience, plusieurs couches : le contenu explicite, mais aussi les métadonnées du document, les noms des clients cités, la structure d'un processus interne, voire des identifiants techniques. Ce que l'organisation croit garder en interne se retrouve en clair chez un tiers, parfois à l'étranger, sans que le cadre contractuel, les responsabilités respectives ou les conditions de transfert aient nécessairement été vérifiés.
Les conséquences se mesurent sur plusieurs registres. Sur le plan contractuel, un accord de confidentialité ou une clause de protection des données peut être rompu sans que personne ne le sache. Sur le plan réglementaire, la transmission de données personnelles à un fournisseur constitue un traitement qui doit être encadré. Lorsqu'un transfert de données vers un pays situé hors de l'Union européenne intervient, il doit également respecter les conditions prévues par le RGPD pour les transferts internationaux. Sur le plan concurrentiel, un algorithme maison, une liste de prix ou une stratégie dévoilée par morceaux peuvent, dans certains scénarios, contribuer à exposer des informations sensibles ou à permettre leur extraction par des requêtes spécialement conçues.
La question de la persistance est plus complexe. Lorsqu'une donnée est simplement transmise à un assistant, elle peut notamment être conservée dans les journaux ou l'historique du service selon sa configuration et les règles du fournisseur. Si elle est également utilisée pour l'entraînement ou l'amélioration d'un modèle, un risque supplémentaire apparaît : certains modèles peuvent mémoriser des fragments de leurs données d'apprentissage et, dans certaines circonstances, permettre l'extraction d'informations par une requête. Le risque ne signifie pas qu'une donnée ressortira nécessairement, mais qu'une organisation peut perdre une partie du contrôle sur son devenir.
Pourquoi les interdictions ne suffisent pas
La première réaction des organisations est souvent d'interdire purement et simplement l'usage des assistants IA. Cette posture rassure, mais elle ne tient pas longtemps. Les équipes ont découvert un gain de productivité réel, et l'interdit déplace simplement l'usage vers des canaux non surveillés : comptes personnels, outils en ligne, applications mobiles. Le shadow AI, loin de reculer, se densifie.
La deuxième réaction consiste à déployer un outil d'IA dit sécurisé, avec un engagement contractuel ou une configuration garantissant l'absence de réutilisation des données d'usage à des fins d'entraînement ou d'amélioration des modèles. C'est mieux, mais cela ne résout rien si l'on ne répond pas à deux questions : qui a accès à quoi, et pour quel usage légitime ? Sans référentiel, les salariés ne savent pas distinguer ce qu'ils peuvent confier à l'IA de ce qui doit rester en dehors. Le bon outil, mal cadré, produit le même résultat qu'un mauvais outil.
La solution durable n'est ni l'interdiction ni la confiance aveugle. Elle tient dans la combinaison de trois leviers : un cadre d'usage écrit, des outils maîtrisés, et une classification des données qui indique clairement ce qui est public, ce qui est interne et ce qui est confidentiel.
Le rôle de la classification des données
Tant que l'organisation ne sait pas quelles informations elle détient, elle ne peut pas protéger celles qui comptent. La classification n'est pas un exercice théorique : c'est une grille simple, comprise par tous, qui dit pour chaque type de donnée le niveau de précaution attendu. Trois niveaux suffisent largement : public, interne, confidentiel. L'effort ne porte pas sur l'écriture des catégories, mais sur leur application concrète, dossier par dossier, application par application.
Une fois la grille posée, la règle pour l'IA devient évidente et tient en une phrase : les données confidentielles ne sont jamais transmises à un outil d'IA sans validation préalable et sans cadre de protection adapté. A fortiori, elles ne doivent pas être saisies dans un outil grand public non autorisé. Cette phrase, répétée et incarnée par la direction, fait davantage qu'une politique de sécurité de quarante pages.
La classification peut également servir de point d'appui au registre des traitements RGPD et à la gouvernance des usages de l'IA, en donnant une vision structurée des données manipulées et des niveaux de précaution associés. Au lieu de constituer un exercice réglementaire de plus, elle devient un socle commun pour la sécurité, la conformité et la gouvernance de l'IA. C'est le point où plusieurs obligations se rejoignent et où l'effort, fait une fois, paye sur tous les fronts.
Construire un cadre d'usage de l'IA
Le cadre d'usage n'a pas besoin d'être long. Il gagne à être court, clair et opposable. Il précise quels outils sont autorisés, pour quels types de données, à quelle condition de configuration, et qui valide les usages nouveaux. Il distingue les cas où l'on peut utiliser un assistant grand public de ceux où seul un outil maîtrisé, contractualisé et configuré pour que les données d'usage ne soient pas réutilisées à des fins d'entraînement ou d'amélioration des modèles est acceptable.
Ce cadre n'a de valeur que s'il est incarné. Un responsable désigné, une formation courte, des exemples concrets tirés de l'activité réelle de l'organisation : voilà ce qui transforme un texte en pratique. L'objectif n'est pas de freiner l'IA, mais de permettre aux équipes d'en profiter sans trahir ce qui ne doit pas sortir.
Reste la dimension humaine. Un collaborateur qui voit dans l'IA un gain de temps quotidien ne comprendra pas spontanément pourquoi une précaution s'impose. La règle doit s'expliquer par le risque réel, pas par la peur. Quand un salarié comprend que transmettre un contrat à un assistant non autorisé peut exposer l'entreprise à un risque réglementaire, contractuel ou concurrentiel, il applique la règle non par obéissance, mais par compréhension.
Du constat à l'action
Le risque de fuite vers les IA génératives ne se traite pas par un coup d'éclat, mais par une démarche patiente. Elle commence par un inventaire honnête des usages déjà en place, y compris ceux que personne n'a validés. C'est souvent l'étape la plus inconfortable, car elle révèle un écart entre la sécurité affichée et la réalité. Elle se poursuit par une classification des données simple et partagée, puis par un cadre d'usage court, incarné et outillé.
Le travail ne s'arrête pas là. Les usages évoluent, les outils se renouvellent, les équipes tournent. La gouvernance de l'IA n'est pas un projet qui se termine, mais un réflexe qui s'entretient. Ceux qui le prennent tôt transforment un risque diffus en avantage maîtrisé ; ceux qui l'ignorent découvrent un jour, à l'occasion d'un audit ou d'un incident, l'étendue de ce qui s'est joué sans eux.
Chez NovIA Secure, nous accompagnons les organisations sur ce chemin : rendre visibles les usages d'IA réels, classer ce qui doit l'être, écrire un cadre lisible et outiller la pratique. La sécurité des données confidentielles face à l'IA générative n'est pas une question de technologie, mais de gouvernance. C'est précisément le terrain où l'on passe du comprendre au faire.
Une question sur votre situation ?
Évaluez votre niveau de conformité en quelques minutes ou échangez directement avec nous.