Les données de vos clients et l'IA : qui va où (Pérou + RGPD), en clair

Le parcours d'un message, étape par étape

Imaginez qu'un visiteur écrive dans le widget de votre site : "Bonjour, je suis Juan Pérez, ma commande 4821 n'est pas arrivée".

Ce message fait un voyage. Ça vaut le coup de le comprendre, parce que chaque étape a ses propres règles.

Quatre étapes. La plupart des malentendus viennent du fait qu'on les mélange. Allons-y une par une.

• Le navigateur du visiteur. Seul le texte qu'il a écrit passe. Rien d'autre.
• Votre serveur (ou le nôtre, selon le montage). C'est là que vit la logique. C'est là que se trouvent les clés d'accès à vos systèmes.
• Le modèle d'IA. Il reçoit uniquement ce dont il a besoin pour répondre à cette question.
• Les journaux (logs). Une copie de la conversation reste enregistrée, pour déboguer et améliorer.

Les credentials ne touchent jamais le navigateur

C'est la première chose que je vérifie sur n'importe quel montage, et c'est là que je vois le plus d'erreurs sur les projets dont j'hérite.

Les clés de vos systèmes (la clé de votre CRM, le token de votre passerelle de paiement, le mot de passe de votre base de données) vivent sur le serveur, jamais dans le navigateur ni dans le widget.

Pourquoi ça compte autant ? Parce que tout ce qui arrive au navigateur, le visiteur peut le voir. Il suffit d'ouvrir les outils de développement, deux clics. Si une clé d'API voyage jusqu'au navigateur, n'importe qui la lit et peut utiliser votre compte.

C'est pour ça que le widget du chat ne sait rien de secret. Il sait seulement envoyer le message de l'utilisateur à votre serveur et afficher la réponse. Toute la partie sensible (interroger votre CRM, lire l'état d'une commande, écrire dans votre base) se passe côté serveur, là où le visiteur n'a pas accès.

Règle simple : si vous pouviez coller une donnée dans un mail à un inconnu sans vous inquiéter, elle peut aller au navigateur. Sinon, elle reste sur le serveur.

Le modèle ne voit que le nécessaire pour répondre

Deuxième point, et celui qui surprend le plus : le modèle d'IA n'a pas besoin de voir toute votre base de données.

Quand l'agent cherche la commande 4821, mon serveur interroge votre système, en sort l'état de cette commande, et ne passe que ça au modèle. Il ne lui envoie pas les 9 800 autres commandes. Il ne lui envoie pas la liste des clients. Il ne lui envoie pas les numéros de carte.

On appelle ça la minimisation. C'est l'idée la plus utile de toute cette discussion, et elle tient en une phrase : l'agent voit juste ce qu'il faut pour faire son travail, rien de plus.

En pratique, ça veut dire des décisions concrètes :

Pourquoi j'insiste ? Parce que moins une donnée voyage, moins il y a à protéger. Une donnée qui ne sort jamais de votre serveur ne peut fuiter nulle part ailleurs. La façon la plus sûre de protéger une donnée, c'est de ne pas la déplacer.

• L'agent reçoit "commande 4821 : en transit, arrive le 19", pas la fiche complète du client.
• S'il pose une question sur une facture, il voit le montant et la date, pas le moyen de paiement enregistré.
• Les données sensibles (pièce d'identité, données de santé, données bancaires) ne voyagent pas en clair s'il n'y a pas une vraie raison de répondre.

Ce qui est gardé dans les logs, et qui peut les lire

Troisième point, celui qu'on oublie le plus.

Presque tout agent sérieux garde les conversations. C'est nécessaire : pour comprendre pourquoi il a mal répondu une fois, pour s'améliorer, parfois pour respecter une obligation comptable ou légale. Mais ce journal, c'est justement là que s'accumulent les données personnelles.

Du coup, les bonnes questions ne sont pas "est-ce que c'est gardé ?". Ce sont celles-ci :

D'expérience, le contrôle d'accès aux logs, c'est là que la chaîne casse le plus facilement. Vous pouvez avoir un serveur impeccable et, malgré tout, laisser les conversations dans un panneau accessible à quiconque a le lien. La sécurité, c'est toute la chaîne, pas le maillon le plus solide.

• Qui peut lire les logs ? Ça devrait être une liste courte et nominative, pas "toute l'équipe".
• Combien de temps sont-ils gardés ? Un délai défini, pas "pour toujours au cas où".
• Peut-on les supprimer sur demande ? Si un client exerce son droit, vous devez pouvoir le retrouver et le supprimer.

Le cadre légal : Ley 29733 au Pérou, RGPD pour l'UE

Jusqu'ici, j'ai parlé du fonctionnement. Maintenant, le cadre. Et là, il faut que je sois très clair sur un point, je le dis plus bas en gras, ne le sautez pas.

Au Pérou, la protection des données personnelles est régie par la Ley 29733 et son règlement. L'idée de fond rejoint ce que j'ai déjà décrit : ne demander que le nécessaire, avoir une base pour traiter la donnée, informer la personne, et lui donner le contrôle sur ses informations.

Si votre agent reçoit des visiteurs de l'Union européenne, le RGPD (le règlement européen) entre aussi en jeu. Il s'applique selon la localisation de la personne, pas selon l'endroit où se trouve votre entreprise. Une entreprise péruvienne qui sert des clients en Espagne tombe sous les deux cadres.

Les deux partagent les mêmes principes pratiques :

La bonne nouvelle : un montage bien fait, avec minimisation et contrôle des logs, vous met déjà près de la conformité, dans les deux cadres. L'architecture propre et la loi pointent vers le même endroit.

• Minimisation. Ne traitez que les données dont vous avez besoin pour la finalité déclarée.
• Finalité. Utilisez la donnée pour ce que vous avez annoncé, pas pour autre chose ensuite.
• Droits de la personne. Accéder à ses données, les corriger, les supprimer.
• Sécurité. Protéger ce que vous gardez, avec des accès contrôlés.

Ceci n'est pas un conseil juridique. Vraiment.

Comme promis, en gras : rien dans cet article n'est un conseil juridique. Je suis celui qui construit l'agent et comprend le flux technique des données, pas votre avocat.

Ce que je raconte ici, c'est comment fonctionne la partie technique et quels principes je respecte au montage. Ce que la loi exige dans votre cas précis dépend de votre secteur, de vos données, et de qui vous servez. Une boutique de vêtements, ce n'est pas la même chose qu'une clinique ou une fintech. Une clinique traite des données de santé, une fintech traite des données bancaires, et là, les règles deviennent bien plus strictes.

Pour savoir ce que vous devez respecter, vous, consultez votre propre conseil juridique, quelqu'un qui connaît la Ley 29733 (et le RGPD si vous servez l'UE). Moi, je veille à ce que l'architecture ne vous mette pas dans des problèmes évitables. Votre avocat s'occupe de votre obligation précise. Ce sont deux métiers distincts et les deux sont nécessaires.

Les trois questions que vous pouvez poser dès aujourd'hui

Pas besoin d'être technique pour auditer votre propre agent. Avec ces trois questions à celui qui vous l'a monté, vous voyez déjà beaucoup :

Si les trois réponses sont claires et précises, vous êtes sur la bonne voie. Si elles sont floues, vous tenez votre prochaine conversation.

Au fond, tout ça se résume à une idée : la donnée la plus sûre est celle qui ne s'est jamais déplacée, et l'agent ne devrait voir que ce dont il a besoin pour répondre. Le reste, ce sont des détails d'implémentation, importants, mais des détails.

Si vous voulez vérifier comment votre cas est monté, ou si vous avez une question précise sur votre flux de données avant de mettre un agent en production, écrivez-nous et on regarde ça ensemble. Mais la question de fond, la juridique, celle-là va toujours de pair avec votre conseil.

• Les credentials vivent-ils uniquement sur le serveur ? La bonne réponse est oui, toujours.
• Qu'est-ce que le modèle reçoit exactement à chaque réponse ? On devrait pouvoir vous le dire avec précision, pas en général.
• Qui lit les logs, pendant combien de temps, et peut-on les supprimer ? Trois réponses concrètes, pas un "c'est protégé".