Google donne une carte d'identité aux agents IA : chez vous, ils travaillent encore avec le badge de qui ?

Najat El Khallouqi
iteyre

Google oblige à déclarer les agents IA qui accèdent à Workspace. En PME, l'agent agit sous le nom d'un salarié. 3 questions pour savoir demain qui, de l'humain ou de l'agent, a fait quoi.

Lundi soir, j’ai reçu comme beaucoup d’entre vous un mail de Google au titre peu engageant, "Action requise", adressé aux administrateurs et aux développeurs qui connectent des applications à Google Workspace. Je l’ai lu 2 fois, parce qu’il dit en langage d’ingénieur quelque chose qui concerne directement les dirigeant(e)s : un agent n'est ni un logiciel ni un salarié, et il lui faut une identité à lui.

En effet, Google s’apprête à ouvrir des serveurs qui permettront à des agents d’IA d’agir dans Gmail, Drive ou Agenda, et pour s’y préparer, il crée une nouvelle case à cocher dans sa console, "utiliser ce client pour un agent alimenté par l’IA".

Depuis le 12 octobre, chaque entreprise peut ainsi déclarer lesquels de ses accès sont ceux d’un agent, mais à partir du 11 novembre, les nouveaux serveurs refuseront tous les autres. Si vos applications se contentent des interfaces classiques de Gmail ou de Drive, rien ne change pour vous, et vous pourriez refermer ce mail. Ne partez pourtant pas si vite.

Un agent n’est pas une application comme une autre

Ce qui m’intéresse dans cette annonce, c’est la raison que Google en donne : il veut que ses propres équipes et les administrateurs des entreprises puissent distinguer le trafic des agents de celui des applications ordinaires, et appliquer aux agents des contrôles d’accès qui leur sont propres, sans toucher à ceux des humains.

Autrement dit, l’un des plus grands fournisseurs de messagerie du monde vient d’écrire noir sur blanc qu’un agent d’IA n’est pas un logiciel comme un autre, et qu’il faut pouvoir le reconnaître quand il frappe à la porte. Il demande d’ailleurs aux entreprises dont une même application sert à la fois des humains et des agents de séparer les 2, avec un accès distinct pour chacun.

Il y a 2 semaines, je racontais ici comment OpenAI avait appris par d’autres les dérapages de ses propres agents, et je posais une question : qui surveille les vôtres ? L’annonce de Google rappelle qu’il y en a une autre, qui vient avant : encore faut-il savoir que c’est un agent.

Dans une PME, l’agent porte le badge de quelqu’un d’autre

Or dans la plupart des entreprises que je connais, on ne le sait pas, et pour une raison très simple : l’agent travaille avec le compte d’un salarié.

Cela s’est fait sans que personne le décide : un responsable commercial installe un assistant qui lit ses mails et prépare ses relances, une assistante de direction branche un outil sur l’agenda de son dirigeant, un comptable confie le rapprochement des factures à un agent connecté à sa propre session, et chacun le fait avec ses identifiants, parce que c’est le seul moyen qu’on lui propose.

Selon l’étude de Microsoft et LinkedIn sur le travail, 78 % des personnes qui utilisent l’IA au travail y apportent leurs propres outils, et la proportion monte à 80 % dans les petites et moyennes entreprises.

Je le sais d’autant mieux que je le fais moi-même : les agents que je fais tourner travaillent avec mes accès, et pour les outils qu’ils utilisent, c’est moi qui agis.

Le résultat, c’est que pour la messagerie, le logiciel commercial ou la banque, rien ne distingue ce que le salarié a fait de ce que l’agent a fait en son nom. Le jour où un mail part à tort, où une pièce est supprimée ou une commande passée, le journal de l’outil affichera un nom et une heure, et ce nom sera celui d’une personne qui dormait peut-être à ce moment-là.

Et pourtant, dans la vie "brick and mortar", aucun(e) dirigeant(e) n’accepterait cela d’un humain : on ne prête pas son badge à un intérimaire, on donne encore moins sa carte bancaire et son code à un stagiaire, et quand un collaborateur doit signer à votre place, on rédige un pouvoir qui dit qui, pour quoi, jusqu’à quel montant et jusqu’à quand. Et (re)pourtant avec les agents, nous avons sauté cette étape, simplement par commodité ou par ignorance, et parce que l’agent ne réclame rien.

Une étiquette ne suffit pas

Il faut être honnête sur ce que fait réellement la case de Google. Comme souvent dans un contrat d’adhésion, c’est une simple déclaration : l’entreprise dit elle-même que tel accès est celui d’un agent, Google ne le vérifie pas, et sa documentation précise que l’étiquette ne donne aucun droit supplémentaire sur les données. C’est donc une carte d’identité que l’on se délivre soi-même.

Ce n’est pas une critique, c’est le point de départ, car on ne peut limiter, surveiller ou couper que ce que l’on sait nommer. Mais la suite ne viendra pas de Google, et elle ne concerne pas seulement Gmail : elle vaut pour tous les outils sur lesquels vos équipes branchent des agents, y compris ceux dont l’éditeur ne vous enverra jamais de mail.

3 questions à poser cette semaine

Alors, voici ce que je m’applique et ce que je conseille aux dirigeant(e)s : n’attendez pas le 11 novembre. Il n’y a besoin ni d’un comité ni d’un expert en sécurité pour commencer, il suffit de se poser 3 questions.

1. Chaque agent a-t-il un nom à lui ?

Un compte à son nom, distinct de celui de la personne qui l’a installé, chaque fois que l’outil le permet. Quand il ne le permet pas, au moins une liste tenue à jour : quel agent, branché sur quel outil, avec le compte de qui.

2. Qui lui a donné ses droits, et jusqu’à quand ?

Comme pour un pouvoir bancaire, quelqu’un de nommé décide de ce que l’agent peut lire et faire, et ce quelqu’un peut le lui retirer en 5 minutes. Un accès sans date de fin est un accès que tout le monde aura oublié dans 6 mois.

3. Peut-on relire ce qu’il a fait ?

Un journal où les actions de l’agent sont séparées de celles des humains, et une personne qui en répond. Sans cela, votre seule réponse à un client mécontent sera "je ne sais pas qui a envoyé ce message".

Et si vous développez vous-même des agents branchés sur Google Workspace, ne cochez pas la case "au cas où" : le choix devient définitif le 12 novembre, et il vaut mieux créer un accès séparé pour l’agent, comme Google le recommande, que d’étiqueter d’un bloc une application qui sert aussi des humains.

Savoir qui a fait quoi

On parle beaucoup de ce que les agents savent faire, et très peu de la question que posera le premier incident : qui a fait cela ? Tant que la réponse est "le compte de Sophie", l’entreprise ne peut ni corriger, ni expliquer, ni assumer.

Google vient de régler le problème pour ses propres serveurs, à sa manière et dans son intérêt.

Chez vous, personne ne le fera à votre place, et cela commence par une liste d’une page, que vous pouvez demander dès demain matin.

Sources