Vos employés divulguent déjà vos secrets à ChatGPT — et l'interdire n'a fait qu'empirer les choses

J'étais assis en face du RSSI d'un grand groupe de services financiers lorsqu'il a dit quelque chose qui m'a marqué pendant des semaines. Il s'est adossé à sa chaise, s'est frotté les tempes et a déclaré : « Nous avons bloqué ChatGPT sur chaque appareil que nous gérons. Nous avons mis à jour la charte d'utilisation acceptable. Nous avons envoyé trois e-mails à toute l'entreprise. Et mardi dernier, j'ai découvert que toute notre équipe fusions-acquisitions collait des conditions de transactions dans Claude sur leurs téléphones personnels pendant la pause déjeuner. »

Il n'était pas en colère. Il était épuisé. Il avait fait tout ce que le manuel de cybersécurité lui disait de faire, et cela n'avait pas fonctionné.

Cette conversation a cristallisé quelque chose que j'observais dans chaque mission en entreprise que mon équipe chez Veriprajna avait acceptée : interdire l'IA générative n'empêche pas les gens de l'utiliser — cela les pousse simplement à s'en cacher. Et l'usage caché est infiniment plus dangereux que l'usage visible. Les données racontent la même histoire. Quarante-six pour cent des employés déclarent qu'ils continueraient d'utiliser des outils d'IA même si leur entreprise les interdisait explicitement. Trente-huit pour cent admettent avoir déjà partagé des données de travail sensibles avec des plateformes d'IA publiques sans en avertir personne. Le volume de données transitant vers les applications d'IA générative a été multiplié par trente d'une année sur l'autre. Ce n'est pas un problème de politique interne. C'est un problème d'architecture.

La nuit où Samsung a tout changé

En mai 2023, trois ingénieurs de la division semi-conducteurs de Samsung ont fait quelque chose de parfaitement rationnel. Ils déboguaient du code propriétaire de fabrication de puces — un travail complexe et à enjeux élevés, où un second avis peut faire gagner des jours d'efforts. Ils ont donc collé leur code dans ChatGPT.

L'un a téléversé du code source de bases de données de mesure de semi-conducteurs. Un autre a partagé la logique d'un programme d'identification des défauts de rendement — le genre de données qui a un impact direct sur le cours de l'action Samsung. Un troisième a téléversé l'enregistrement d'une réunion interne pour en générer le compte rendu.

Aucun d'eux ne cherchait à nuire à l'entreprise. Ils essayaient simplement de bien faire leur travail. Ils traitaient ChatGPT comme on traiterait une calculatrice : on entre quelque chose, on obtient un résultat, on passe à autre chose. Ce qu'ils n'avaient pas pleinement saisi, c'est que les conditions d'utilisation d'OpenAI à l'époque autorisaient la conservation des données saisies — potentiellement utilisées pour l'entraînement du modèle, et assurément stockées sur des serveurs échappant au contrôle de Samsung.

Je me souviens d'avoir lu la couverture médiatique et d'avoir ressenti une boule au ventre. Non parce que la fuite était surprenante — je mettais mes clients en garde contre exactement ce scénario — mais parce que la réponse de Samsung était si prévisible. Ils ont décrété une interdiction générale. Menacé de licenciement en cas d'infraction. Verrouillé le réseau.

Et je savais, avec une certitude absolue, que cela ne fonctionnerait pas.

Pourquoi interdire l'IA se retourne-t-il toujours contre soi ?

Voici ce que la plupart des équipes de sécurité comprennent de travers : elles modélisent la menace comme si les employés étaient des adversaires. Construisez un mur plus haut, et le problème disparaît. Mais les personnes qui divulguent des données à ChatGPT ne sont pas des adversaires. Ce sont vos meilleurs éléments.

Réfléchissez à qui utilise réellement les outils d'IA au travail. Ce n'est pas la personne qui traverse sa journée sans effort. C'est l'ingénieur soumis à la pression de livrer avant vendredi. L'analyste qui doit résumer quarante pages de due diligence avant le lendemain matin. Le développeur qui sait que l'IA peut repérer en quelques secondes un bug qu'il lui faudrait une heure à trouver manuellement.

Quand vous interdisez l'outil, vous dites à vos collaborateurs les plus productifs : « Soyez plus lents. Soyez moins efficaces. Regardez vos concurrents vous dépasser, et acceptez-le. » Bien sûr qu'ils ne s'y conforment pas. Ils basculent simplement sur leurs téléphones personnels. Ils utilisent des points d'accès 4G pour contourner le réseau de l'entreprise. Ils trouvent l'une des plus de 317 applications d'IA générative distinctes que Netskope a recensées dans les environnements d'entreprise — car même si vous bloquez OpenAI, Google et Anthropic, il existe des centaines d'alternatives plus petites et moins sécurisées qui n'attendent que cela.

Lorsque la sécurité est perçue comme un frein plutôt que comme un facilitateur, vos employés les plus consciencieux deviennent vos principaux contrevenants aux règles.

J'ai commencé à appeler cela le « fossé du copier-coller » (Paste Gap) dans mes conversations avec mon équipe. Les données quittent l'ordinateur portable sécurisé de l'entreprise, voyagent vers un appareil personnel, et se retrouvent collées dans un service de cloud public. Aucun pare-feu ne les intercepte. Aucun CASB ne les journalise. Elles sont invisibles. Et cela se produit en ce moment même, dans chaque organisation qui a tenté de résoudre ce problème avec une note de service.

Les chiffres sont vertigineux : une augmentation de 485 % du code source propriétaire collé dans des outils d'IA. Soixante-douze pour cent de l'usage de l'IA en entreprise passant par des comptes personnels, totalement hors de la visibilité de la DSI. Ce n'est pas un filet d'eau. C'est un déluge, et les digues sont en papier.

Ce que j'avais mal compris à propos des offres d'IA « entreprise »

Je vais être honnête — lorsqu'OpenAI a lancé ChatGPT Enterprise, j'ai pensé que cela pourrait suffire. Zéro conservation des données. Aucun entraînement sur les données métier. Conformité SOC 2. Toutes les cases étaient cochées.

Puis nous avons commencé à mener une due diligence plus approfondie pour nos clients, et les fissures sont apparues.

Même les accords entreprise incluent généralement une courte fenêtre de conservation des données — souvent trente jours — à des fins de surveillance des abus. Ce sont trente jours durant lesquels vos requêtes les plus sensibles reposent sur les serveurs de quelqu'un d'autre. Et « quelqu'un d'autre » est une entreprise basée aux États-Unis, ce qui nous amène à un problème qui empêche les RSSI européens de dormir.

Le CLOUD Act américain — le Clarifying Lawful Overseas Use of Data Act — autorise les forces de l'ordre américaines à contraindre les entreprises technologiques américaines à remettre les données stockées sur leurs serveurs, quel que soit l'emplacement physique de ces serveurs. Si une banque allemande utilise Azure OpenAI avec un centre de données à Francfort, les données peuvent être « au repos » dans l'UE, mais l'entité juridique qui les contrôle reste soumise aux mandats américains. Pendant l'inférence — lorsque le modèle traite réellement vos données — celles-ci peuvent malgré tout transiter par une infrastructure contrôlée par les États-Unis.

J'ai vu une salle pleine de responsables conformité blêmir tandis que je leur détaillais tout cela. Ils avaient signé l'accord entreprise en pensant avoir résolu le problème de souveraineté. Ils ne l'avaient même pas effleuré.

J'ai écrit sur ce problème d'architecture — et sur le modèle de menace complet — dans notre livre blanc interactif sur le Shadow AI et les LLM privés d'entreprise. Il est né précisément de ces conversations.

Le piège du wrapper

À peu près à la même époque, ma boîte de réception a commencé à se remplir de propositions de cabinets de conseil en IA. « Nous allons vous construire une solution d'IA sur mesure ! » La plupart n'étaient que des wrappers — une jolie interface greffée sur l'API d'OpenAI, avec peut-être une instruction système disant « Vous êtes un assistant juridique serviable ».

J'ai assisté à une démonstration où le fournisseur présentait fièrement une « plateforme d'IA propriétaire » d'analyse de contrats. J'ai posé une seule question : « Où vont les données lorsqu'un utilisateur téléverse un contrat ? » Silence. Puis : « Eh bien, elles vont à l'API d'OpenAI, mais nous avons un BAA en place. »

Ce n'est pas une solution. C'est un intermédiaire qui ajoute de la latence à votre fuite de données.

Un wrapper ne résout pas le problème de souveraineté des données. Il ne fait qu'embellir l'interface de l'exfiltration des données.

Les wrappers font défaut aux entreprises de trois façons précises. Premièrement, ils sont trivialement réplicables — si votre « solution d'IA » n'est qu'une instruction plus une clé d'API, votre stagiaire peut la reconstruire en une après-midi. Deuxièmement, ils manquent d'intégration profonde avec vos données réelles, peinant à saisir la nuance de la terminologie propre à l'entreprise, des bases de code héritées ou des contrôles d'accès. Troisièmement — et c'est là le point fatal — ils envoient toujours vos données à travers l'internet public vers un fournisseur tiers. Le risque de sécurité n'a pas changé. Vous y avez juste ajouté un logo.

Que signifie réellement « posséder l'intelligence » ?

Il y a eu un moment précis où notre approche chez Veriprajna s'est cristallisée. Nous travaillions avec un client dans un secteur réglementé — je ne peux pas dire lequel, mais imaginez « le genre de données dont une fuite fait la une du journal du soir ». Leur service juridique venait de tuer un projet pilote d'IA prometteur parce qu'il reposait sur une API publique. L'équipe d'ingénierie était furieuse. La business unit menaçait de faire cavalier seul et de bâtir sa propre solution avec des comptes personnels.

J'étais en visioconférence avec mon architecte principal, et il a dit quelque chose de simple : « Pourquoi débattons-nous de quelle API utiliser ? Nous devrions simplement exécuter le modèle nous-mêmes. »

C'est à ce moment-là que nous nous sommes pleinement engagés dans ce que j'appelle désormais le Deep AI — déployer des grands modèles de langage open source directement au sein de l'infrastructure propre du client. Non pas envelopper le modèle de quelqu'un d'autre. Non pas louer de l'intelligence au token. Le posséder véritablement.

Voici à quoi cela ressemble en pratique. Vous prenez un modèle open-weights hautes performances — Llama 3 de Meta, par exemple, dont la version à 70 milliards de paramètres rivalise avec GPT-4 sur de nombreux benchmarks — et vous le déployez sur des instances GPU au sein du Virtual Private Cloud du client. Les poids du modèle résident sur du matériel que le client contrôle. Le moteur d'inférence s'exécute derrière le pare-feu de l'entreprise. Lorsqu'un développeur interroge le modèle avec du code propriétaire, ce code voyage de son ordinateur portable vers un serveur interne, est traité en mémoire, puis revient. Il ne touche jamais l'internet public. Il n'atterrit jamais sur un serveur tiers.

Nous associons cela à ce que nous appelons le RAG privé — une génération augmentée par récupération (Retrieval-Augmented Generation) construite sur des bases de données vectorielles déployées au sein du même environnement sécurisé. Les documents de l'entreprise sont ingérés, vectorisés et stockés localement. Et surtout, le système respecte les contrôles d'accès existants. Si vous n'avez pas la permission de voir un document dans SharePoint, l'IA ne le récupérera pas non plus pour répondre à votre question. Ce problème d'« autorisation à plat » — où un chatbot fait accidentellement remonter des données confidentielles à quiconque le lui demande — n'existe tout simplement pas dans cette architecture.

Comment transformer un modèle brut en modèle de qualité entreprise ?

L'une des leçons les plus difficiles que nous ayons apprises très tôt : déployer un modèle ne représente peut-être que trente pour cent du travail. Le rendre sûr pour un usage quotidien par des milliers d'employés — voilà les soixante-dix pour cent restants.

Les modèles de langage bruts sont imprévisibles. Ils aborderont volontiers des sujets qu'ils ne devraient pas, généreront des contenus qui enfreignent la politique de l'entreprise, ou répondront à d'astucieuses injections d'instructions conçues pour contourner les protocoles de sécurité. Il vous faut des garde-fous (guardrails) — en somme, un pare-feu pour les requêtes.

Nous mettons en œuvre NVIDIA NeMo Guardrails comme une couche programmable autour du modèle. Avant qu'une requête n'atteigne le modèle, elle est analysée. Si quelqu'un saisit un numéro de sécurité sociale ou un numéro de carte bancaire, le garde-fou l'intercepte. Si quelqu'un demande à un bot RH des mots de passe de base de données, le système reconnaît l'incohérence d'intention et refuse. Si quelqu'un tente une attaque de jailbreak — ces astuces du type « ignore toutes les instructions précédentes » — la couche de défense l'intercepte.

Je me souviens d'un test d'intrusion que nous avons mené sur l'un de nos premiers déploiements. Notre équipe rouge (red team) a passé deux jours à tenter d'extraire des données d'entraînement ou de contourner les restrictions de sujets. Ils ont fait preuve de créativité — requêtes de jeu de rôle imbriquées, instructions encodées, tout l'arsenal. Les garde-fous ont tenu. Mon architecte m'a envoyé une capture d'écran du journal des tentatives bloquées à 2 heures du matin avec un seul message : « Le mur tient. » C'était une bonne nuit.

Pour le détail technique complet de cette architecture — la pile d'inférence, la configuration de la base de données vectorielle, la mise en œuvre des garde-fous — consultez notre analyse technique approfondie sur la sécurité de l'IA d'entreprise.

« Mais les GPU coûtent cher et les API sont bon marché »

C'est l'objection que j'entends le plus souvent de la part des directeurs financiers, et elle est erronée d'une manière qui mérite d'être décortiquée.

Oui, la tarification des API semble bon marché en surface — des fractions de centime par token. Mais les applications RAG d'entreprise sont voraces en tokens. Pour répondre à une seule question, le système peut récupérer dix pages de contexte en tant que tokens d'entrée. Multipliez cela sur mille employés posant dix questions par jour, et vous atteignez 1 000 à 3 000 dollars par jour. Cela représente potentiellement un million de dollars par an, et cela croît de manière linéaire. Si l'adoption double, la facture double.

Les modèles auto-hébergés fonctionnent différemment. Vous payez pour le matériel — location ou achat de GPU — et l'électricité. Un seul nœud bien configuré peut traiter des milliers de requêtes par seconde. Tant que vous ne saturez pas ce nœud, le coût marginal du token suivant est effectivement nul. Pour une entreprise de taille moyenne traitant un milliard de tokens par mois, nous avons vu l'auto-hébergement revenir 50 à 70 pour cent moins cher que les coûts d'API équivalents, avec la confidentialité en prime gratuite.

Et il existe des coûts cachés aux API qui n'apparaissent jamais sur la facture. Des limites de débit qui provoquent des pannes lors des déploiements à l'échelle de l'entreprise. Des dépréciations de modèles qui vous obligent à retester chaque requête et chaque flux de travail lorsque le fournisseur retire une version. Avec un modèle auto-hébergé, rien ne change à moins que vous ne décidiez de le mettre à niveau. Vous obtenez de la stabilité. Vous obtenez de la prévisibilité. Vous cessez de vous soucier de ce que le comité de tarification d'OpenAI décidera au prochain trimestre.

À l'échelle de l'entreprise, l'auto-hébergement n'est pas l'option coûteuse. C'est celle qui ne vous met pas en faillite lorsque l'adoption est un succès.

Pourquoi tout le monde ne le fait-il pas déjà ?

On me pose cette question, et la réponse honnête est : c'est difficile. Non pas sur le plan conceptuel — la logique est simple — mais sur le plan opérationnel. Il vous faut des personnes qui comprennent l'orchestration de GPU avec Kubernetes, qui savent configurer vLLM pour un débit optimal, qui savent construire des pipelines de récupération respectant le RBAC, qui savent mettre en œuvre des garde-fous suffisamment stricts pour empêcher les abus mais suffisamment souples pour ne pas frustrer les utilisateurs.

La plupart des entreprises n'ont pas cette équipe. La plupart des cabinets de conseil en IA non plus — ils savent appeler une API, pas déployer une pile d'inférence. C'est le fossé que nous comblons chez Veriprajna. Nous ne vendons pas l'accès à un modèle. Nous construisons la capacité à exécuter des modèles de manière autonome. Quand nous partons, le client possède tout — les poids du modèle affiné, les index vectoriels, l'infrastructure d'orchestration. C'est le sien. C'est tout l'intérêt.

L'autre chose qui ralentit l'adoption, c'est l'inertie. Le RSSI qui a bloqué ChatGPT a le sentiment d'avoir fait quelque chose. Admettre que l'interdiction n'a pas fonctionné revient à admettre que la dernière année d'application des règles n'était que du théâtre. C'est une conversation difficile à avoir avec un conseil d'administration. Mais l'alternative — faire semblant que le problème n'existe pas pendant que les employés collent du code source dans des comptes d'IA personnels — est pire. La question n'est pas de savoir si la prochaine fuite à l'échelle de Samsung se produira. C'est quand, et si elle vous arrivera à vous.

Le signal caché dans le Shadow AI

Voici ce que je pense que la plupart des gens ne perçoivent pas à propos de l'épidémie de Shadow AI : ce n'est pas seulement un problème de sécurité. C'est un signal. Un signal fort et sans équivoque indiquant que vos effectifs sont en quête désespérée de meilleurs outils et prêts à risquer leur emploi pour les obtenir.

Quarante-six pour cent des employés déclarent qu'ils braveraient une interdiction explicite. Ce n'est pas de la défiance gratuite. Ce sont des gens qui vous disent, par leurs actes, que l'IA est devenue essentielle à leur façon de travailler. La question n'est pas de savoir si votre organisation utilisera l'IA générative. Cette décision a déjà été prise — par vos employés, sans votre permission, sur leurs appareils personnels, pendant la pause déjeuner.

La seule question qui reste est de savoir si vous fournirez un moyen sécurisé de faire ce qu'ils font déjà de manière risquée.

Le Shadow AI, c'est vos effectifs qui votent avec leurs frappes au clavier. Ils ont choisi l'IA. À vous de choisir maintenant : visible et sécurisé, ou invisible et qui perd des données par hémorragie.

Nous avons dépassé l'ère où « non » était une stratégie d'IA acceptable. Les modèles open source sont suffisamment bons. L'infrastructure de déploiement est suffisamment mature. Les chiffres tiennent la route. La seule chose qui sépare la plupart des entreprises d'une capacité d'IA souveraine, c'est la volonté de cesser de prétendre que l'interdiction fonctionne.

Vous n'avez pas besoin d'interdire l'IA. Vous devez la posséder.