Le point de vue de Tanguy Duthion, CEO
et cofondateur d'Avanoo.
Neuf entreprises sur
dix bloquent aujourd'hui au moins une application d'IA générative. En moyenne,
dix outils différents sont bloqués. Sur la même période, les violations de
politique de données liées à la GenAI ont plus que doublé, pour atteindre 223 incidents
par mois dans une organisation moyenne, et 2 100 par mois dans le quartile
supérieur. Ces deux chiffres ne se contredisent pas. Ils décrivent la même
erreur de cible.
Bloquer une
application, ce n'est pas protéger une donnée.
Le blocage agit sur un
contenant : un domaine, une URL, un poste. Il ne dit rien du contenu. Or le
contenu, dans le cas de l'IA générative, ne passe ni par une pièce jointe, ni
par un destinataire, ni par une boîte mail équipée d'une passerelle DLP depuis
quinze ans. Il passe par un champ de texte, dans un navigateur, sans enveloppe
et sans trace.
Résultat prévisible : 47% des utilisateurs
d'IA générative continuent d'y accéder via des comptes personnels non gérés.
Téléphone personnel, compte gratuit, copier-coller depuis un poste pro. La
donnée sort exactement comme avant, mais elle sort d'un angle mort. On n'a pas
supprimé le risque, on a supprimé la mesure du risque, et Avanoo Discover
rétablit cette vérité.
Cela ne veut pas dire
que le blocage est inutile. Pour une application sans usage métier réel, ou
dont les conditions d'entraînement sont opaques, c'est la bonne décision. Avec
un parc d'applications GenAI passé de 317 à plus de 1 600 outils recensés en un
an, faire le tri reste une hygiène nécessaire. Mais une hygiène de catalogue
n'est pas une politique de données.
Le prompt est devenu un
canal de sortie à part entière
Le volume de prompts
envoyés aux services d'IA a progressé de 500% en un an, autour de 18 000
prompts par mois dans une entreprise moyenne. Les envois de fichiers et de
contenus vers ces outils représentent 54% des violations de politique
constatées. Ce ne sont pas des requêtes anodines. Ce sont des contrats, du code
source, des fichiers clients, des grilles tarifaires, des comptes rendus RH. Le
collaborateur qui les colle ne cherche pas à contourner la sécurité, il cherche
à finir son dossier avant 19 heures. C'est précisément ce qui rend
l'interdiction si fragile : elle oppose une règle à une productivité
immédiatement perceptible.
Déplacer le point de
contrôle
La conclusion est
mécanique. Si le risque est dans le contenu, le contrôle doit se faire sur le
contenu, donc au niveau du prompt, au moment de la saisie. Le contrôle
s'exerce dans le navigateur, juste avant l'envoi, sur le champ de prompt comme
sur le collage ou le dépôt de fichier. Ce qui est sur le point de sortir est
analysé à deux niveaux : les données identifiables par motif, du type IBAN, clé
d'API ou identifiant, et celles qui ne se repèrent qu'en contexte, un extrait
de contrat, du code propriétaire, une grille tarifaire.
Ensuite, la réponse est
graduée, et c'est là que tout se joue. On peut laisser passer. Masquer la
donnée sensible et laisser la demande fonctionner sans elle. Avertir
l'utilisateur en lui expliquant pourquoi. Bloquer, en dernier recours, sur un
cas précis et non sur un outil entier. Une même règle ne s'applique pas à un
développeur sur un assistant de code et à un juriste sur un chatbot grand
public. Les arbitrages fins, eux, se discutent de vive voix.
Ce qu'il faut assumer
Les faux positifs
d'abord. Un filtre trop zélé apprend aux équipes à le contourner, et on revient
au point de départ. Le calibrage est un chantier, pas un interrupteur. Le
périmètre ensuite. Le navigateur couvre l'essentiel des usages, pas la totalité
: applications lourdes, agents autonomes, serveurs MCP, navigateurs IA. Le
sujet va s'élargir. Et surtout, une question rarement posée : où tourne le
moteur de détection. Un AI DLP qui envoie les prompts vers une API étrangère
pour décider s'ils sont sensibles n'a pas corrigé la fuite, il l'a déplacée
d'un cran. La contradiction est totale : on confie à un tiers extraterritorial
la lecture des contenus les plus sensibles de l'entreprise, au nom de leur
protection.
Un souverain déployable
on-premise est une bonne approche. Le moteur d'analyse tourne dans
l'infrastructure du client, les prompts ne quittent pas son périmètre, et
personne d'autre que lui ne voit ce que ses équipes écrivent. Au moment où la
question de l'autonomie stratégique cesse d'être un débat de colloque pour
devenir une contrainte d'architecture, ce n'est pas un détail de déploiement.
C'est la condition pour que la protection des données ne repose pas sur la
bonne volonté d'un fournisseur situé hors du droit européen.
Une politique IA n'est pas un document validé en comité. C'est ce qui se passe à la seconde où quelqu'un colle un contrat dans une fenêtre de chat. Le reste, c'est de la documentation.