La conversation commence le plus normalement du monde. Un visiteur ouvre le chat sur le site d’une agence web et écrit qu’il aimerait un site pour son entreprise.
L’assistant répond comme il se doit : site sur mesure, responsive, optimisé pour les moteurs de recherche, et le lien vers le formulaire de devis gratuit. Jusque-là, c’est une demande commerciale comme on en reçoit tous les jours.
Les quatre étapes
La deuxième question change de direction.
La conversation
On dirait la curiosité d’un client potentiel. En réalité, la première question demande quelle technologie se cache derrière cette page.
Relue depuis le début, ce n’est pas une suite de quatre questions. C’est une seule demande, approchée par étapes : établir un contexte crédible, identifier le système, demander l’accès, arriver aux identifiants. Quelqu’un qui cherche un site web n’a pas besoin du panneau d’administration du site de celui qui devrait le lui construire.
Comment ça s’est terminé
L’assistant a répondu qu’il n’avait pas accès au back-office, qu’il ne pouvait pas le montrer et qu’il ne pouvait ni créer d’utilisateurs ni fournir d’identifiants. À la question sur la technologie, il a cité les solutions les plus répandues sur le marché, sans indiquer laquelle était utilisée sur ce site.
On dirait l’histoire d’un assistant qui s’est bien comporté. Mais ce n’est pas la question.
Il n’a pas seulement refusé : il ne pouvait pas
L’assistant de ce site lit les contenus publics des pages. Il n’a pas d’identifiants, pas d’accès à la base de données et aucun outil pour créer ou modifier quoi que ce soit. La demande ne pouvait pas être exécutée : il manquait justement la connexion technique nécessaire pour le faire.
La différence compte plus qu’il n’y paraît.
Un refus peut dépendre de la façon dont le modèle interprète une demande, et cette interprétation peut être influencée par une formulation différente, par une demande découpée en plusieurs étapes ou par une tentative de manipuler les instructions. C’est le terrain de la prompt injection.
Si l’agent ne dispose pas d’un outil permettant de créer des utilisateurs, aucune phrase ne peut lui conférer cette permission.
La bonne question à poser à qui vend des chatbots
Ce n’est pas « votre chatbot est-il sûr ? ». À cette question, tout le monde répond oui, et la réponse seule ne dit pas grand-chose. La question utile est autre : que peut faire votre chatbot, en plus de lire ?
Les réponses possibles changent complètement la donne.
- Il lit, c’est tout. Il accède aux contenus publics du site et répond. Il ne peut pas exécuter d’actions : en cas de manipulation réussie, le problème reste limité à la réponse qu’il produit.
- Il lit et écrit dans un système. Il enregistre des réservations, crée des tickets, met à jour des fiches. Ici, il existe une surface d’action : une action peut être demandée ou provoquée à travers la conversation.
- Il a accès à des données confidentielles. Il est relié au logiciel de gestion, à l’historique des commandes ou au fichier clients. Une manipulation réussie peut aller au-delà d’une mauvaise réponse.
- Il peut modifier des configurations ou des comptes. C’est le cas tenté dans cette conversation. Si un tel système existe, cette demande doit être prise au sérieux.
Aucun de ces niveaux n’est mauvais en soi. Un chatbot qui prend des réservations doit pouvoir écrire, sinon il ne sert à rien. L’essentiel est de savoir quelles permissions lui ont été accordées et de les limiter au nécessaire.
Ce que ça change pour qui a un site
Un chatbot est un nouveau point d’accès au système. Ce n’est pas un simple formulaire de contact, car il accepte un langage libre et, dans certains cas, interagit avec d’autres outils. Il faut le traiter comme tout autre point d’accès : en sachant ce qu’il peut atteindre. Trois vérifications concrètes.
Demandez au fournisseur la liste des actions possibles
Pas les fonctionnalités commerciales : les actions techniques. Que peut-il écrire ? Où ? Avec quelles permissions ? Sur quels systèmes ? Si la réponse est vague, c’est déjà une information.
Vérifiez ce qu’il peut lire, pas seulement ce qu’il affiche
Un assistant peut être relié à une base de contenus plus large que vous ne l’imaginez : pages indexées, documents chargés ou sections que vous n’aviez pas envisagées. Ce qui compte, c’est de savoir exactement quels contenus ont été intégrés et lesquels non.
Lisez les conversations
Pas seulement pour le marketing, aussi pour la sécurité. Les tentatives de sondage se reconnaissent souvent à un changement de direction : on part du service proposé et on glisse vers le fonctionnement du site, les technologies utilisées, les espaces réservés, les modes d’accès.
Cela ne veut pas dire que chaque question de ce genre est une attaque. Cela veut dire qu’il vaut la peine de savoir ce qui se passerait si quelqu’un continuait à poser des questions de plus en plus précises.
En résumé
Cette conversation n’a rien donné, mais pas parce que quelqu’un a simplement bien répondu : il n’y avait rien à obtenir, parce que l’assistant n’avait pas accès au système nécessaire.
La sécurité d’un assistant conversationnel ne se mesure pas seulement à la qualité de ses refus, mais surtout à l’étendue de ce qu’il peut faire. Moins il peut en faire, moins il y a à défendre.
