Le risque des agents IA que personne ne peut corriger avec une règle DLP
Il y a quelques années, la question inconfortable en sécurité IA était simple : « Quelqu’un a-t-il collé des données clients dans ChatGPT ? »
Cette question reste importante. Très importante. Mais ce n’est plus toute l’histoire.
Le changement le plus intéressant la dernière semaine dans la couverture de la sécurité IA est le passage de la fuite de données à l’agentivité. Google News regorge de ce thème : Help Net Security parle du déficit de gouvernance IA en entreprise, Palo Alto Networks positionne la gouvernance IA agentique dans le navigateur, Forbes affirme que le vrai risque n’est pas seulement ce que les agents voient mais ce qu’ils peuvent faire, et Lookout relie l’usage mobile de l’IA à la gouvernance IA fantôme. Différents fournisseurs, angles différents, même problème sous-jacent.
L’IA est passée d’une fenêtre de chat à une surface de travail.
Cela change le modèle de sécurité.
De « qu’est-ce que l’employé a collé ? » à « qu’est-ce que l’agent peut toucher ? »
La gouvernance IA traditionnelle commence souvent par l’inspection du contenu. Surveiller les prompts. Détecter les données sensibles. Avertir l’utilisateur s’il tente d’envoyer un contrat, un fichier source ou un dossier client vers un outil non géré.
C’est raisonnable. Mais c’est aussi incomplet.
Un agent peut lire un calendrier, résumer un dossier de conseil, créer un ticket, rédiger une pull request, interroger un CRM, envoyer un message, mettre à jour un workflow et déclencher un autre système. Parfois dans un produit approuvé comme Microsoft Copilot ou ChatGPT Enterprise. Parfois dans un outil développeur, une extension de navigateur, une application mobile ou une automatisation interne jamais vue par la sécurité.
Le risque n’est plus seulement la sortie des données. C’est l’action qui revient.
Une règle DLP peut détecter un employé collant un fichier fiscal dans un chatbot public. Elle ne peut pas facilement répondre : quel agent a eu accès au drive finance, pourquoi a-t-il résumé le dossier conseil, qui a approuvé le connecteur, et a-t-il invité un utilisateur externe dans le mauvais espace de travail ?
Cela semble dramatique, mais la version quotidienne est ennuyeuse et donc plus dangereuse. Un employé connecte un preneur de notes IA aux réunions. Une équipe laisse un agent de recherche parcourir des documents internes. Un développeur donne un accès large à un agent de codage car le sprint est en retard. Une équipe sales ops connecte un assistant utile au CRM et Slack. Personne ne cherche à être imprudent. Ils essaient de faire leur travail.
Les équipes de sécurité doivent alors gouverner un système qui ressemble moins à un inventaire logiciel et plus à un ensemble croissant de collègues semi-autonomes.
Le mobile aggrave le problème de visibilité
L’angle de gouvernance IA mobile est facile à sous-estimer.
La plupart des programmes IA en entreprise pensent encore en termes de bureau : contrôles navigateur, logs SaaS, événements fournisseur d’identité, agents endpoint, peut-être couverture CASB. Pendant ce temps, les employés utilisent l’IA sur téléphones et tablettes car c’est là que le travail se fait entre réunions, dans les aéroports, chez les clients et à la maison après le dîner.
Le mobile est là où la frontière entre personnel et professionnel devient floue. Une app IA personnelle peut résumer une capture d’écran. Une extension clavier peut réécrire une réponse client. Un assistant vocal peut prendre des notes de réunion. Une app de productivité grand public peut toucher des fichiers synchronisés depuis des comptes d’entreprise. Certains outils sont excellents. D’autres opaques. Beaucoup échappent au plan de contrôle que les responsables sécurité surveillent réellement.
C’est pourquoi l’attention réglementaire et des fournisseurs émergente sur la gouvernance IA mobile mérite d’être prise au sérieux. Ce n’est pas un problème niche de MDM. C’est une partie du même problème d’IA fantôme, mais sur une classe d’appareils où la visibilité a historiquement été plus faible.
Si votre inventaire IA ne couvre que le SaaS géré et le trafic navigateur desktop, il sous-estime probablement la vraie courbe d’adoption.
Le navigateur devient un champ de bataille pour la gouvernance
Un autre signal clair : les navigateurs d’entreprise et fournisseurs d’accès sécurisé se disputent la place où l’IA agentique sera gouvernée.
Cela a du sens. Le navigateur voit beaucoup. Il peut observer quels outils IA les employés utilisent, appliquer la politique au moment de l’interaction et réduire le risque sans forcer chaque équipe à un assistant unique approuvé. Pour beaucoup d’entreprises, c’est bien plus pratique que de tenter de bloquer l’IA complètement.
Mais la gouvernance au niveau du navigateur n’est qu’une couche.
Les agents ne vivent pas uniquement dans des onglets de navigateur. Ils vivent dans des apps desktop, IDE, apps mobiles, plateformes de workflow, outils de chat, suites documentaires et automatisations internes. Ils appellent aussi de plus en plus directement des API. Un navigateur peut être un point de contrôle fort pour certains comportements, mais ce n’est pas une carte complète de l’usage IA en entreprise.
Les entreprises qui réussiront cela traiteront le navigateur comme un capteur et une surface de contrôle, pas comme la stratégie complète de gouvernance.
Ce que les équipes sécurité doivent faire maintenant
L’ancien conseil était « rédigez une politique IA ». Très bien. Rédigez-la. Mais le travail utile est plus opérationnel.
Commencez par quatre questions.
Premièrement : quels outils et agents IA sont réellement utilisés dans l’entreprise ? Pas ce que les achats ont approuvé. Pas ce que la politique mentionne. Les outils effectifs.
Deuxièmement : à quelles données chaque outil ou agent peut-il accéder ? Séparez l’accès en lecture de l’accès en écriture. Résumer un document n’est pas modifier un document. Lire une note CRM n’est pas créer une séquence sortante.
Troisièmement : quelles actions ces systèmes peuvent-ils effectuer, et sous quelle identité ? C’est la question de l’identité agentique. Si un assistant IA crée un ticket, met à jour un enregistrement ou envoie un message, vos logs doivent le montrer clairement. « Bastien l’a fait » ne suffit pas si Bastien a cliqué une approbation et un agent a réalisé dix actions en aval.
Quatrièmement : où faut-il guider les employés plutôt que les bloquer ? Un avertissement au bon moment peut être plus efficace qu’une interdiction totale. Si quelqu’un s’apprête à coller des données confidentielles dans un outil IA non géré, offrez-lui une voie plus sûre. Si une équipe utilise un agent pour un travail légitime, aidez-la à le mettre sous gouvernance plutôt que de le pousser à l’ombre.
C’est le juste milieu pratique : découvrir, classer, gouverner et accompagner.
La partie inconfortable : l’adoption est déjà en avance sur la gouvernance
La plupart des employés n’attendent pas le comité de pilotage IA. Ils essaient des outils, connectent des assistants et construisent de petites automatisations car les gains de productivité sont évidents. Ce n’est pas un échec culturel. C’est le schéma normal d’adoption d’une technologie utile.
L’échec serait de faire semblant que cela n’arrive pas.
Les équipes sécurité ne doivent pas devenir le département du non. Elles ont besoin d’assez de visibilité pour savoir où l’IA est utilisée, assez de contexte pour distinguer adoption utile et risque inacceptable, et assez de garde-fous pour que les employés avancent en sécurité.
C’est la direction que prend le marché : pas de blocage IA, pas de gouvernance chat universelle, mais une couche de sécurité IA pour la main-d’œuvre qui voit outils et agents dans l’entreprise, comprend les risques et intervient dans le contexte.
Le prochain déficit de gouvernance ne sera pas causé par un employé collant le mauvais paragraphe dans un chatbot. Ce sera un agent avec trop d’accès, trop peu d’auditabilité et personne ne sachant vraiment à qui il appartient.
C’est ce déficit qu’il faut combler maintenant.
