Le jour où notre IA privée a montré à un employé un salaire qu'il n'aurait jamais dû voir

La note de service qui ne fonctionne pas

Quelque part dans votre entreprise, en ce moment même, quelqu'un a collé un contrat client dans un chatbot pour le résumer. Cette personne n'a pas demandé la permission. Elle n'est pas malveillante. Elle avait une échéance et un outil qui fonctionnait, et il se trouve que cet outil a envoyé ce contrat vers un serveur appartenant à une entreprise située sur un autre continent.

Je le sais parce que chaque RSSI avec qui j'ai travaillé a le même tableau de bord, et il raconte la même histoire. L'un d'eux a ouvert Netskope en pleine réunion et m'a montré 317 applications d'IA générative distinctes activement utilisées dans son organisation. Il en avait approuvé une poignée. Le reste, c'étaient ses employés qui résolvaient leurs propres problèmes, un copier-coller à la fois.

Cet écart — entre l'IA que vous avez approuvée et l'IA que vos collaborateurs utilisent réellement — est le problème que j'ai passé la dernière étape de ma carrière à résoudre en bâtissant Veriprajna. Nous faisons du déploiement de LLM privé : nous plaçons un grand modèle de langage performant au sein de votre propre infrastructure, sous vos propres contrôles, afin que le travail que vos employés réalisent déjà avec l'IA cesse de s'échapper par les côtés du bâtiment. L'IA souveraine n'est pas un argumentaire philosophique sur l'indépendance technologique nationale. C'est la réponse pratique à une question à laquelle chaque responsable de la sécurité échoue déjà à répondre : où vont nos données, et pouvons-nous le prouver ?

L'instinct, la première fois que vous voyez ce tableau de bord, c'est d'envoyer une note de service. Interdire les outils. J'ai essayé cette approche assez tôt, et je veux vous expliquer exactement pourquoi elle s'effondre — car cet échec est la raison même de l'existence de cette entreprise.

Interdire l'IA ne la fait pas disparaître de votre entreprise. Cela supprime seulement votre visibilité sur elle.

Les chiffres plaident mieux que je ne saurais le faire. Le rapport 2025 d'IBM sur le coût d'une violation de données a révélé qu'une organisation sur cinq a déjà subi une violation liée à l'IA fantôme — des outils non autorisés utilisés à l'insu du service informatique. Ces violations ont coûté en moyenne 670 000 $ de plus que les incidents traditionnels, et il a fallu 247 jours pour les détecter, contre 241 pour tout le reste. Une enquête distincte l'a dit sans détour : 43 % des employés admettent partager des informations professionnelles sensibles avec des outils d'IA que leur employeur n'a jamais approuvés. Une interdiction ne change pas ce comportement. Elle garantit simplement que vous serez le dernier informé quand les choses tourneront mal.

Pourquoi un chatbot privé ne règle-t-il pas le problème de l'IA fantôme ?

Donc, si vous ne pouvez pas l'interdire, vous construisez l'alternative sûre. Vous déployez un chatbot interne, vous le connectez à un bon modèle, vous dites à tout le monde de l'utiliser à la place. C'est là que j'ai commis mon erreur la plus coûteuse, et elle mérite qu'on s'y attarde, car presque tout le monde la commet.

Le premier déploiement interne dont j'ai été proche était superbe en démonstration. Interface épurée, réponses rapides, un modèle qui connaissait les documents de l'entreprise. Nous en étions fiers. Puis, pendant le pilote, quelqu'un occupant un poste subalterne lui a posé une question sur un plan de rémunération — et il a répondu. Entièrement. Avec précision. Avec des détails tirés d'un document que cette personne n'avait aucun droit de consulter.

Rien n'avait été piraté. Le système de récupération a fait exactement ce que nous l'avions conçu pour faire : trouver les documents les plus pertinents et les transmettre au modèle. Nous ne lui avions simplement jamais appris que pertinence et autorisation sont deux choses différentes. Le chatbot était un bibliothécaire dévoué à qui l'on avait confié le passe-partout de toutes les pièces verrouillées du bâtiment.

Cet après-midi-là a recadré tout le problème pour moi. Le modèle n'a jamais été la partie difficile. La partie difficile, c'est l'autorisation.

Voici ce que personne ne vous dit dans les démonstrations des fournisseurs : la plupart des entreprises traînent des années de logique d'accès accumulée, enfouie dans Active Directory — groupes de sécurité imbriqués, autorisations héritées, listes de distribution, unités organisationnelles empilées les unes sur les autres par des gens partis depuis des années. Quand vous construisez un système de récupération, le réflexe naïf est d'étiqueter chaque fragment de texte avec une liste plate de qui peut le voir. Cela s'effondre dès que vous rencontrez l'imbrication de groupes du monde réel. Un document hérite de l'accès d'un groupe, qui hérite d'un autre groupe, auquel un prestataire a été ajouté pour un projet unique il y a des années.

Bien faire cela, c'est le vrai travail. Nous avons construit une couche de synchronisation qui se situe entre le fournisseur d'identité — Active Directory, Okta, Azure AD — et la base de données vectorielle où résident les documents. Elle résout l'appartenance aux groupes de manière récursive, aplatit ces chaînes d'héritage et actualise les métadonnées d'accès à une cadence serrée. Pour la plupart des déploiements, nous synchronisons toutes les 60 à 90 secondes. Mais le cas qui vous empêche de dormir, c'est la résiliation : quelqu'un est raccompagné vers la sortie à 9 h, et vous ne pouvez pas laisser le système continuer à répondre avec ses accès à 9 h 05. Les révocations n'attendent donc pas la prochaine synchronisation — un webhook Okta ou Azure AD déclenche une purge immédiate à l'instant même où le compte est désactivé.

Pertinence et autorisation ne sont pas la même chose, et un système de récupération qui les confond livrera la bonne réponse précisément à la mauvaise personne. Aucune grande plateforme de RAG ne résout cela d'emblée — je suis allé voir.

Ce n'est pas de la confiance marketing — c'est ce que j'ai constaté en cherchant. TrueFoundry, Databricks, les produits de recherche cloud-native ont tous des réponses partielles : vérifications d'autorisations en lecture seule, synchronisations périodiques. Aucun d'eux n'hérite de l'image complète des politiques de groupe et des règles basées sur les attributs — accès à durée limitée, « uniquement depuis un appareil géré », niveaux de classification — sur lesquels une entreprise réglementée fonctionne réellement. Nous construisons donc ce moteur de politiques sur mesure, car il n'existe aucun raccourci pour y parvenir. Si vous voulez l'architecture complète du fonctionnement de bout en bout de cette application des autorisations, elle est détaillée sur notre page IA souveraine et déploiement de LLM privé.

Un centre de données à Francfort rend-il votre IA européenne ?

Il y a un deuxième piège, et il est plus subtil parce qu'il ressemble à de la conformité. Beaucoup d'entreprises se tournent vers une option managée — Azure OpenAI, AWS Bedrock — et se sentent en sécurité. Les données restent dans leur tenant cloud. Il y a des points de terminaison VPC, un réseau privé, une pile de certifications. Pour bien des entreprises, c'est véritablement la bonne réponse, et je le dirai en face à un client quand c'est le cas.

Mais il existe une réalité juridique sous la réalité technique que je vois les gens manquer sans arrêt. Héberger votre IA dans un centre de données à Francfort ne la rend pas européenne. Microsoft et Amazon sont des entreprises dont le siège est aux États-Unis, ce qui les soumet au CLOUD Act américain, qui permet aux forces de l'ordre américaines de contraindre une entreprise américaine à remettre les données qu'elle stocke n'importe où dans le monde. L'article 48 du RGPD dispose qu'une décision d'un tribunal étranger n'est valable ici qu'en vertu d'un accord international. Ces deux lois pointent dans des directions opposées, et vos données se trouvent dans cet interstice.

Cela a cessé d'être théorique en mars 2026. L'Autorité autrichienne de protection des données a infligé à une fintech viennoise une amende de 450 000 EUR pour avoir effectué de la notation de crédit via une API d'IA basée aux États-Unis — la qualifiant de transfert de données illicite au regard du RGPD. L'entreprise avait supposé, comme presque tout le monde, qu'un hébergement en région européenne suffisait. Ce n'était pas le cas. Je garde cette décision en favori parce que c'est la plus nette illustration que j'aie trouvée d'un risque que la plupart des conseils d'administration ignorent porter.

Le cas symétrique est celui d'une chaîne hospitalière américaine : là, le CLOUD Act ne compte quasiment pas, mais les exigences relatives aux sous-traitants (business associate) de la loi HIPAA et — dès l'instant où vous touchez à des contrats fédéraux — le cadre de gestion des risques liés à l'IA du NIST (NIST AI Risk Management Framework) et FedRAMP High deviennent la ligne que vous tracez à la place. La question de la juridiction garde la même forme ; seule change la loi affichée au mur.

Pour une société financière américaine sans clients européens, rien de tout cela n'importe et Azure OpenAI est souvent exactement le bon choix. Pour une banque européenne traitant les données de ses propres clients, le calcul s'inverse — et la seule configuration qui supprime entièrement l'exposition au CLOUD Act est un déploiement auto-hébergé sur des modèles à poids ouverts, tournant sur une infrastructure dont l'exploitant n'est pas soumis à la juridiction américaine. C'est là la véritable fonction des fournisseurs de cloud souverain européens — OVHcloud, Scaleway, la nouvelle capacité Blackwell qui arrive en Europe. Pas du patriotisme. De la juridiction.

Et l'échéance est bien réelle. Les obligations de transparence de l'article 50 du règlement européen sur l'IA (AI Act) deviennent applicables le 2 août 2026. Empilez les sanctions de l'AI Act sur celles du RGPD et le plafond combiné atteint 55 millions d'EUR, soit 11 % du chiffre d'affaires annuel mondial. Ce n'est pas une amende que l'on absorbe. C'est un chiffre qui met fin à des carrières.

« Utilisez simplement l'API » — la conversation que j'ai chaque mois

L'objection que j'entends le plus est financière, et elle est légitime : l'auto-hébergement semble coûteux. Pourquoi acheter des GPU et recruter une équipe quand une API n'est qu'à un débit de carte bancaire ?

Parce que le calcul bascule, et l'endroit où il bascule est plus précis que les gens ne le pensent. Pour un modèle auto-hébergé de 70 milliards de paramètres, l'inférence revient à environ 0,013 $ pour mille tokens. Le même travail via une API hébergée comme GPT-4o mini coûte 0,15 à 0,60 $ pour mille. Ce n'est pas une différence d'arrondi. Mais cela ne compte qu'au-dessus d'un certain volume, car les GPU auto-hébergés coûtent de l'argent, que vous les utilisiez ou qu'ils restent inactifs.

Le seuil de rentabilité se situe autour de deux millions de tokens par jour. En dessous de cette ligne, les API l'emportent — vous ne payez pas de matériel inactif, et je dirai à un client de rester sur les API sans hésiter. Au-dessus, l'auto-hébergement fait économiser 60 à 85 % sur l'inférence. Une fintech que je connais a réduit sa facture d'IA mensuelle de 47 000 $ à 8 000 $ en passant à l'auto-hébergement hybride.

Mais — et c'est la partie que les étiquettes de prix des GPU dissimulent — le matériel est rarement le poste de dépense le plus important. Aux prix actuels, une H100 se loue de 2,50 $ à 3,50 $ l'heure, et une seule d'entre elles faisant tourner un modèle à poids ouverts comme Llama 3.3 70B sert 30 à 50 utilisateurs simultanés avec une latence inférieure à deux secondes. La partie coûteuse, ce sont les gens. Il vous faut des ingénieurs MLOps — deux au minimum pour une fiabilité de production — à 200 000 $ à 350 000 $ chacun, plus la surveillance, les pipelines d'évaluation, une stratégie de retour en arrière. Pour une équipe novice dans l'exécution de modèles, le coût total de possession atteint environ 3,2 fois le coût brut de l'API la première année. Pour une équipe mature disposant déjà d'outils, il descend à environ 1,8 fois.

Cette fintech qui a réduit sa facture de façon si spectaculaire ? Cela a fonctionné parce qu'elle disposait déjà d'une équipe Kubernetes et de 18 mois de cicatrices opérationnelles. Le même mouvement aurait mis en faillite une équipe qui apprend sur le tas.

Le GPU est la partie la moins chère de l'auto-hébergement. Les deux ingénieurs qui le maintiennent en marche sont le poste de dépense qui décide si le calcul fonctionne réellement — et quiconque répond à « devrions-nous auto-héberger ? » plus vite que « cela dépend de votre volume et de votre équipe » cherche à vous vendre quelque chose.

La bonne nouvelle sous-jacente à tout cela, c'est que les modèles à poids ouverts sont devenus assez bons pour que la question vaille la peine d'être posée. Llama 3.3 70B atteint 86 % au benchmark MMLU et tourne, en auto-hébergement, environ 25 fois moins cher que l'API équivalente. DeepSeek-V3 obtient 88,5 % — dépassant de justesse un modèle propriétaire de pointe sur cette mesure. Pour la grande majorité des tâches d'entreprise, le modèle que vous pouvez faire tourner à l'intérieur de vos propres murs n'est plus le compromis qu'il était il y a deux ans.

Ce qui se passe quand l'IA cesse de simplement parler

Une évolution transforme tout cela de prudent en urgent. L'IA de votre entreprise est sur le point de cesser d'être un chatbot pour devenir un agent — un logiciel qui ne se contente pas de répondre à des questions mais qui prend des actions, avec un accès permanent à vos systèmes.

Gartner prévoit que 40 % des applications d'entreprise intégreront des agents d'IA d'ici la fin 2026, contre moins de 5 % un an plus tôt. Mais seulement 5 % environ des entreprises ont réellement fait passer des agents du pilote à la production, et le tableau de la sécurité est franchement alarmant : 92 % des responsables de la sécurité déclarent manquer d'une visibilité complète sur les identités d'IA opérant déjà dans leur environnement. Un agent capable de lire votre CRM, d'ouvrir des tickets et de déplacer de l'argent représente un risque très différent d'un chatbot capable de résumer un PDF.

Tout ce que j'ai décrit — l'application des autorisations, le contrôle de la juridiction, les garde-fous d'exécution qui interceptent l'injection de prompt — cesse d'être un simple atout dès l'instant où votre IA peut agir. Un chatbot qui récupère le mauvais document est une gêne. Un agent doté d'un accès permanent et d'aucune frontière d'autorisation est un incident qui n'attend qu'une date.

Voici le recadrage sur lequel je vous laisserais. La couche de garde-fous compte ici aussi — et il vaut la peine de savoir que des options prêtes à l'emploi comme NeMo Guardrails de NVIDIA ajoutent une latence réelle, de 100 à 300 millisecondes par appel, raison pour laquelle nous ajustons la logique de politiques au schéma de conformité spécifique plutôt que de greffer un filtre générique. Mais le point le plus profond est architectural. Vous ne pouvez pas placer un agent sur une infrastructure que vous ne contrôlez pas et prétendre qu'elle est gouvernée.

La partie que les gens contestent toujours

Les gens me demandent s'ils doivent vraiment choisir — s'ils peuvent conserver quelques API cloud et se dire encore souverains. Oui : la plupart des déploiements que je recommanderais sont hybrides, les charges de travail sensibles sur une infrastructure privée et celles à faible risque sur des API managées, avec une frontière de politique claire décidant laquelle est laquelle. La souveraineté n'a jamais été un vœu du tout ou rien ; c'est tracer la ligne au bon endroit et pouvoir prouver où elle se situe.

L'autre question, c'est le calendrier — n'est-ce pas prématuré ? L'amende autrichienne est déjà tombée. L'échéance de l'article 50 est inscrite au calendrier. Vos employés collent des données dans des centaines d'outils que vous n'avez pas approuvés pendant que vous lisez ceci. Le coût d'un mouvement précoce, c'est un projet. Le coût d'un mouvement tardif se mesure à l'aune d'un plafond de onze pour cent du chiffre d'affaires.

J'ai fondé Veriprajna parce que j'ai vu un petit chatbot dévoué remettre à un employé subalterne un salaire qu'il n'aurait jamais dû lui montrer, et j'ai compris que toute l'industrie vendait des modèles alors que le vrai problème était le contrôle. Le modèle est la partie facile. Il l'a toujours été.

Vos collaborateurs n'attendent pas la permission pour utiliser l'IA. La seule question ouverte, c'est de savoir si l'IA qu'ils utilisent vous rend des comptes.

Si vous voulez voir comment nous concevons ce contrôle pour un profil de risque spécifique — où placer la ligne entre le privé et le managé, comment se construit la couche d'autorisation, à quoi ressemble le coût total réel pour votre équipe — c'est ce que nous exposons, honnêtement et sans parti pris pour un fournisseur, sur la page IA souveraine de Veriprajna. Apportez votre tableau de bord. Je sais déjà en gros ce qu'il dit.