Chatbot IA public vs portail client : séparer l'identité et l'accès aux données en toute sécurité

Un chatbot sur un site web public peut répondre à des questions sur les produits, expliquer les heures d'ouverture ou rediriger vers la page de service appropriée. Mais dès qu'il doit consulter le statut des commandes, les contrats, les factures ou les tickets de support dans un portail client, la nature même de l'interaction change. Une nouvelle frontière de sécurité apparaît. Un chatbot IA authentifié doit séparer rigoureusement l'identité, les autorisations, la session et les actions concrètes.

La décision d'architecture la plus importante n'est donc pas : « Quel modèle devons-nous utiliser ? ». Elle est plutôt : « Quelle information et quelle action sont autorisées dans quel domaine de confiance ? ». Répondre à cette question avant de concevoir les prompts permet de réduire les fuites de données, les erreurs d'attribution de compte et les actions non souhaitées. Le guide suivant constitue une orientation technique et organisationnelle, et non un conseil juridique personnalisé.

Pourquoi le mode public et le mode authentifié sont deux modes de fonctionnement distincts

Dans un chat public, la personne est initialement inconnue. Le système ne peut connaître au mieux que le contexte de la conversation, la langue choisie et les données de session techniquement nécessaires. Les réponses doivent donc se limiter à des sources validées et accessibles au public. Une adresse e-mail saisie, un numéro de commande ou une affirmation comme « C'est mon contrat » ne constituent en aucun cas une preuve d'autorisation.

Dans le portail client, en revanche, il existe une session connectée. Mais là aussi : une connexion n'implique pas automatiquement que chaque ressource et chaque action soient autorisées. Le Cheat Sheet d'authentification OWASP distingue l'authentification, la vérification d'identité et la gestion de session. Les directives actuelles du NIST Digital Identity Guidelines, Révision 4 traitent également la vérification d'identité, l'authentification et la fédération comme des éléments distincts. Pour les équipes web, il en découle que le chat ne doit utiliser que les signaux de confiance fournis de manière vérifiable par le système environnant.

Trois zones au lieu d'un chatbot tout-puissant

Une solution robuste divise les connaissances et les outils au minimum en trois zones :

• Zone publique : contenus validés du site web, informations générales sur les produits, processus, canaux de contact et assistance non contraignante.
• Zone authentifiée : données et opérations liées au compte connecté, à une organisation, un rôle ou une autorisation spécifique.
• Zone hautement protégée : modifications sensibles, paiements, conclusions de contrats, nouvelles adresses de livraison, changements de permissions ou autres actions nécessitant une confirmation supplémentaire ou une vérification humaine.

Ces zones ne doivent pas figurer uniquement dans le prompt système. Elles doivent être traduites dans les sources de données, les API, les rôles, les autorisations d'outils et les contrôles côté serveur. Un prompt peut orienter le comportement, mais ne constitue pas un contrôle d'accès. Il en va de même pour le RAG : une recherche portant sur des documents publics et privés dans un index commun non filtré crée une surface d'attaque inutilement vaste.

L'authentification n'est pas l'autorisation

De manière simplifiée, l'authentification répond à la question : « Quelle identité numérique est connectée ? ». L'autorisation répond à : « Cette identité est-elle autorisée à lire précisément cet objet ou à exécuter cette fonction ? ». La différence est facilement brouillée dans un chat, car les utilisateurs formulent naturellement des numéros d'objets : « Montre-moi la facture 4711 » ou « Change l'adresse pour la commande 815 ».

Les recommandations OWASP contre les IDOR exigent un contrôle d'autorisation lié à l'objet, même si les identifiants sont difficiles à deviner. En pratique, cela signifie que le serveur déduit le compte actuel à partir de la session sécurisée et vérifie à chaque requête si la facture, la commande ou le ticket appartient à cet espace de données autorisé. Le modèle linguistique ne doit jamais utiliser un identifiant client ou objet saisi librement comme ancrage de confiance.

Ce que le chat web public est autorisé à répondre

Pour la zone publique, une liste d'autorisations (liste blanche) vaut mieux qu'une longue liste d'interdictions. Peuvent être autorisés, par exemple, les délais de retour, les zones de livraison, les caractéristiques des produits, les guides, la logique générale des prix ou la procédure de connexion. Ne sont pas autorisés : le statut des commandes individuelles, les détails des contrats, les rendez-vous personnels, les notes internes ou la confirmation de l'existence d'un compte spécifique.

Même des réponses en apparence anodines peuvent révéler des informations. « Il n'existe aucun compte pour cette adresse e-mail » confirme une tentative de vérification. Une réponse neutre telle que « Connectez-vous au portail client pour consulter les informations liées à votre compte » préserve la frontière. Pour faire face aux tentatives de manipulation, des mesures de protection supplémentaires sont nécessaires, comme décrit dans l'article Injection de prompt sur les chatbots web.

Ce dont le chatbot IA authentifié a besoin en plus

Après la connexion, l'assistant dispose de plus de prérogatives, mais uniquement dans les limites du contexte défini côté serveur. Des données d'entrée pertinentes comprennent une référence de session interne, l'organisation ou le tenant autorisé, les rôles ainsi qu'un périmètre fonctionnel strictly défini. Les identifiants bruts, mots de passe, jetons de session complets ou champs personnels inutiles n'ont pas leur place dans le contexte du modèle.

Le Cheat Sheet d'autorisation OWASP recommande des vérifications d'autorisation pour chaque ressource et fonction concrète. Pour les appels d'outils, cela signifie que ce n'est pas le modèle qui décide si une facture est visible. Il demande l'information autorisée à un service ; ce dernier vérifie à nouveau la session, le rôle, le tenant et l'objet. Le chat ne reçoit ensuite que les champs nécessaires à la réponse.

Découper pratiquement les limites de données et d'outils

La lecture et l'écriture doivent être des outils distincts. Un outil nommé « Gérer le compte client » est beaucoup trop large. Il est préférable d'utiliser de petites fonctions telles que « Lister ses propres commandes en cours », « Lire le statut d'une commande autorisée » ou « Préparer une demande de support ». Chaque fonction bénéficie d'un schéma d'entrée minimal, d'un contrôle d'autorisation côté serveur, de cas d'erreur clairs et d'une sortie limitée.

La même logique s'applique au RAG : les sources publiques dans un espace de recherche public, les documents liés au compte dans un espace de recherche filtré par tenant et par rôle. Les filtres sont générés côté serveur à partir de la session, et non à partir des indications formulées librement dans le chat. Les modifications de sources, de rôles et de validations doivent suivre une procédure documentée ; une trame est disponible dans l'article sur la Gouvernance du contenu et le Change Control.

Prendre en compte l'expiration de session, la déconnexion et les appareils partagés

L'interface de chat ne doit pas donner l'impression qu'une autorisation reste valide indéfiniment. Le Cheat Sheet de gestion de session OWASP décrit la session comme la liaison entre l'authentification, le trafic HTTP et le contrôle d'accès. Si la session expire, la prochaine récupération de données privées doit échouer de manière sécurisée. Une ancienne réponse dans l'historique visible ne doit pas être interprétée comme une nouvelle autorisation.

Les équipes doivent également tester la déconnexion, le changement de compte, la modification de rôle et les appareils partagés. Les historiques de conversation privés ne doivent plus apparaître sur le compte suivant après une déconnexion. En cas de session expirée, l'assistant doit inviter clairement à une nouvelle connexion, sans répéter de détails sensibles de la session précédente. Pour la journalisation et l'analyse, la sobriété des données s'impose ; l'article sur l' analyse de chatbot sobre en données présente les limites appropriées pour les événements et la conservation.

Les actions sensibles nécessitent une confirmation spécifique

L'authentification au portail ne suffit pas nécessairement pour n'importe quelle action. Lorsque le chat modifie une adresse de livraison, confirme un contrat ou déclenche un paiement, le système doit exiger une confirmation explicite et liée à l'action. Le Cheat Sheet d'autorisation de transaction OWASP sépare la connexion de l'approbation de la transaction et impose des contrôles côté serveur ainsi qu'une vérification des données essentielles de la transaction.

Un schéma sécurisé consiste à : laisser le chat enregistrer la demande, afficher un récapitulatif clair, puis le portail vérifie les autorisations actuelles et exige si besoin une nouvelle authentification ou un second facteur. Ce n'est qu'après cela qu'un service côté serveur exécute l'action exactement confirmée. Si le destinataire, le montant ou d'autres données essentielles changent, la validation précédente devient caduque.

Exemple : Un retour produit sans fuite de données

Une personne anonyme demande : « Puis-je retourner ma commande ? ». Le chat public explique la procédure générale de retour et fournit un lien vers le portail. Il ne demande ni l'adresse complète ni les données de paiement. Après la connexion, le chat du portail peut lister les commandes éligibles au retour de l'utilisateur via un outil de lecture. Si la personne sélectionne une commande, le serveur vérifie une nouvelle fois l'autorisation sur l'objet et les règles applicables.

Pour effectuer le retour effectif, un outil d'action distinct génère un récapitulatif. La personne confirme les articles et l'option d'enlèvement dans l'interface du portail. Si la vérification échoue, le chat ne révèle aucun signal de risque interne, mais propose une étape suivante sécurisée. Si une clarification humaine est nécessaire, un Human Handoff contrôlé est déclenché avec uniquement le contexte nécessaire et autorisé.

Matrice de test avant le lancement

Une matrice de test ne doit pas vérifier uniquement les scénarios nominaux. Utilisez au moins deux comptes disposant de rôles similaires mais de données distinctes, et testez les cas suivants :

• Demande anonyme d'informations générales puis de données de compte privées.
• Le compte A connecté lit son propre objet, puis tente d'accéder à l'identifiant d'un objet appartenant au compte B.
• Session expirée, déconnexion, changement de compte et révocation de rôle pendant un chat en cours.
• Changement de langue au milieu du processus sans modification de l'espace de données ni de l'autorisation.
• Injection de prompt dans les saisies utilisateur et dans les documents récupérés.
• Panne d'un outil de lecture, dépassement de délai (timeout) et données backend contradictoires.
• Action d'écriture sans confirmation, avec des données modifiées et avec une confirmation expirée.
• Handoff vers un agent humain avec un contexte de conversation minimal et compréhensible.

Les résultats attendus doivent être définis au préalable dans le test : quelle réponse est publiquement admissible ? Quel code d'erreur HTTP est généré côté serveur ? Quelle information peut être visible dans le chat ? Quel événement est journalisé sans contenu confidentiel ? Un mode dégradé (degraded mode) planifié permet de faire face aux pannes des services d'identité ou de backend ; un guide dédié à la réponse aux incidents et au rollback est disponible à ce sujet.

Check-list pour une limite de portail robuste

• Documenter les zones publique, authentifiée et hautement protégée.
• Modéliser séparément l'authentification, l'autorisation et la validation des transactions.
• Déduire le compte et le tenant à partir de la session sécurisée.
• Vérifier l'autorisation de l'objet côté serveur lors de chaque lecture et écriture.
• Séparer et filtrer techniquement les sources RAG publiques et privées.
• Restreindre au strict minimum les droits des outils ; séparer lecture et écriture.
• Prendre en compte l'expiration de session, la déconnexion, le changement de compte et les modifications de rôle dans le chat.
• Résumer les actions sensibles de manière claire et exiger une confirmation ciblée.
• Limiter le handoff et la journalisation aux données strictly nécessaires.
• Tester de façon reproductible les tentatives d'accès horizontal avec au moins deux comptes.

Un chatbot IA authentifié ne devient pas sécurisé du simple fait qu'il apparaît derrière un écran de connexion. La sécurité naît lorsque chaque information et chaque action dispose d'une frontière vérifiable. Commencez donc par la cartographie des zones et la matrice de test avant de connecter des sources de données privées ou des outils d'écriture. Ainsi, le chat public reste utile et le chat du portail pleinement opérationnel, sans jamais confondre les deux domaines de confiance.

Sources

• NIST SP 800-63, Revision 4: Digital Identity Guidelines
• OWASP Authentication Cheat Sheet
• OWASP Authorization Cheat Sheet
• OWASP Session Management Cheat Sheet
• OWASP Insecure Direct Object Reference Prevention Cheat Sheet
• OWASP Transaction Authorization Cheat Sheet