Confidentialité des données : où vont vraiment les conversations de votre chatbot IA ?

Installer un widget de chat IA sur son site prend environ cinq minutes. Comprendre où partent réellement les conversations qui y transitent prend beaucoup plus longtemps — et la plupart des entreprises ne se posent jamais la question. La réponse n'est pourtant pas la même selon les éditeurs, et elle peut avoir une réelle importance selon ce que les clients confient au chatbot.

Cet article explique simplement ce qui se passe quand un client envoie un message, pourquoi cela compte pour toute entreprise qui traite des informations personnelles ou sensibles, ce que change concrètement une IA « auto-hébergée », et propose une checklist pratique pour évaluer la posture de confidentialité de n'importe quel éditeur — y compris cswithai.

Ce qui se passe quand un client envoie un message

L'architecture typique d'un chatbot IA suit trois étapes. D'abord, le message quitte le navigateur du visiteur pour rejoindre les serveurs de l'éditeur du chatbot. Ensuite, l'éditeur construit un « prompt » qui combine ce message avec des extraits pertinents du contenu ou de la FAQ de l'entreprise. Enfin, ce prompt est envoyé quelque part pour générer une réponse.

Le point clé est là : pour la grande majorité des éditeurs de chatbots, ce « quelque part » désigne une API d'intelligence artificielle tierce — OpenAI, Anthropic, Google, ou une autre. Autrement dit, l'éditeur ne fait pas tourner son propre modèle, il appelle l'API d'une autre société, un peu comme un logiciel de e-commerce appelle un prestataire de paiement ou une API de cartographie. Ce n'est pas suspect en soi : c'est ainsi que la plupart des produits d'IA sont construits, car entraîner et exploiter un grand modèle de langage coûte extrêmement cher.

Mais cela signifie concrètement que le message du client, et tout son contenu, échappe à la fois au contrôle de l'entreprise et de l'éditeur du chatbot pour atterrir sur l'infrastructure d'une troisième société — potentiellement en franchissant une frontière si les serveurs de cette société se trouvent ailleurs dans le monde.

Pourquoi ce n'est pas un détail anecdotique

Ce n'est pas un scénario catastrophe hypothétique. C'est une chaîne de sous-traitance que presque personne ne pense à questionner, jusqu'au jour où elle croise quelque chose d'important.

• Flux de données transfrontaliers : le RGPD en Europe, tout comme des lois similaires ailleurs (PIPA en Corée, LGPD au Brésil), s'intéressent précisément à l'endroit où les données personnelles sont traitées et partagées. Faire transiter chaque message par une API basée aux États-Unis constitue un transfert transfrontalier de données, que l'entreprise en ait conscience ou non.
• Ce que les clients écrivent réellement : les gens sont étonnamment francs dans un chat de support — une adresse pour un problème de livraison, un symptôme avant de demander les horaires d'une clinique, un litige juridique évoqué en posant une question de facturation. Rien d'inhabituel : ils pensent parler à un « service client », pas à un système distribué impliquant deux entreprises ou plus, et parfois un serveur à l'étranger.
• Ce n'est pas vraiment une question de malveillance : le problème n'est pas qu'OpenAI ou Anthropic utiliserait mal une conversation. C'est que chaque société supplémentaire, et chaque frontière franchie par une donnée, est un endroit de plus où elle peut être journalisée, conservée, mise en cache, consultée par du personnel, ou exposée lors d'une fuite — et un acteur de plus dont les politiques et la juridiction s'appliquent aux informations du client, souvent sans que celui-ci sache même que cette société existe.

Ce que signifie vraiment une IA « auto-hébergée » ou « on-premise »

De plus en plus d'éditeurs présentent l'IA « auto-hébergée » ou « on-premise » comme un argument de confidentialité. Débarrassé du discours marketing, cela veut dire ceci : au lieu d'appeler l'API d'OpenAI ou d'Anthropic, l'éditeur fait tourner sa propre copie d'un modèle de langage à poids ouverts (Qwen, Llama, Mistral sont des exemples courants) sur une infrastructure qu'il opère lui-même. Le modèle qui lit le message et rédige la réponse vit sur un serveur que l'éditeur contrôle directement, et non sur le serveur d'une société d'IA distincte.

L'effet pratique est simple : la conversation ne quitte jamais l'infrastructure propre de l'éditeur pour être traitée par un tiers. C'est une société de moins dans la chaîne, un jeu de serveurs externes de moins que la donnée doit traverser. C'est une différence architecturale réelle et significative — elle supprime un maillon entier. C'est d'ailleurs le choix de conception central du widget de chat de cswithai : les réponses sont générées par un modèle auto-hébergé que cswithai exploite lui-même, plutôt que d'envoyer chaque message client vers une API d'IA externe.

L'auto-hébergement n'est pas une garantie magique de confidentialité

Il est important de rester honnête sur les limites de cette approche. L'auto-hébergement est parfois présenté comme s'il réglait la question de la confidentialité une fois pour toutes — ce n'est pas le cas. Il change la forme du problème, il ne l'élimine pas.

Faire tourner son propre modèle signifie qu'on n'a plus besoin de faire confiance à une société d'IA tierce avec les données. Mais l'entreprise doit toujours faire confiance à l'éditeur du chatbot lui-même : ses serveurs, ses employés, ses pratiques de sécurité, la durée de conservation de ses journaux, les personnes en interne qui peuvent y accéder. L'auto-hébergement déplace la frontière de confiance : au lieu de « faire confiance à OpenAI et à l'éditeur », on passe à « faire confiance à l'infrastructure propre de l'éditeur » — c'est un acteur de moins à qui faire confiance, pas zéro.

Cela ne signifie pas non plus, automatiquement, une conformité au RGPD, à HIPAA, ou à une quelconque certification. L'architecture et la conformité réglementaire sont deux sujets liés mais distincts, et un éditeur sérieux ne devrait jamais laisser penser que l'un implique l'autre. Si la conformité est un enjeu pour une entreprise, la bonne approche est de demander directement à l'éditeur quels documents il peut fournir, plutôt que de le déduire du modèle d'hébergement.

Une checklist pratique pour évaluer n'importe quel éditeur de chatbot

Que l'on regarde cswithai ou un concurrent, ces questions valent la peine d'être posées avant d'ajouter un widget à son site. Et un éditeur incapable d'y répondre clairement en dit aussi long que celui qui répond avec précision.

• Où l'inférence de l'IA est-elle réellement exécutée ? (API d'IA tierce — laquelle — ou infrastructure propre à l'éditeur)
• Les données des clients servent-elles à entraîner des modèles d'IA ? (opt-out, opt-in, ou jamais — il faut demander)
• Combien de temps les données de conversation sont-elles conservées, et où ? (exiger une réponse précise, pas un vague « aussi longtemps que nécessaire »)
• Qui, en interne chez l'éditeur, peut accéder aux conversations brutes ? (personnel de support pour du débogage ponctuel, ou accès interne large et non journalisé)
• Que couvre un accord de traitement des données (DPA) ? (en demander un par écrit si l'activité ou la région est réglementée)
• Que devient la donnée en cas de résiliation ? (suppression programmée ou conservation indéfinie)
• L'éditeur utilise-t-il des sous-traitants, et lesquels ? (même un produit à IA auto-hébergée peut recourir à des tiers pour l'envoi d'e-mails, l'analytique ou l'hébergement — demander la liste complète)

Aucune de ces questions ne nécessite une formation juridique pour être posée, et un éditeur confiant dans son architecture devrait pouvoir y répondre simplement.

Comment cswithai gère cette question

Concernant spécifiquement le produit de cswithai, et non des généralités : le widget de chat répond à partir du contenu et de la FAQ propres à l'entreprise, et le modèle d'IA qui génère les réponses tourne sur une infrastructure auto-hébergée que cswithai exploite elle-même. Les conversations des clients ne sont pas acheminées vers une API d'IA américaine tierce pour produire une réponse. Les échanges sont résumés et envoyés par e-mail au propriétaire de l'entreprise, et tout ce que l'IA ne parvient pas à traiter est transmis à une personne.

Une précision importante s'impose ici : cette description correspond honnêtement à l'architecture du produit, ce n'est pas la revendication d'une certification de conformité spécifique. Si un élément comme SOC 2 ou une attestation formelle de conformité au RGPD compte pour une entreprise, la bonne démarche est de demander à n'importe quel éditeur, cswithai y compris, une documentation concrète, plutôt que de la présumer à partir d'un discours marketing.

FAQ

Est-il sûr d'utiliser un chatbot IA pour le service client ? Cela dépend davantage de l'architecture de l'éditeur que du simple fait qu'il s'agisse d'« IA ». Il faut vérifier où le traitement IA a lieu (infrastructure auto-hébergée ou API tierce) et combien de temps les données sont conservées. Un chatbot qui répond uniquement à partir du contenu propre de l'entreprise, sans faire transiter les messages par une société d'IA externe, présente généralement une surface d'exposition des données plus réduite.

Est-ce que tous les chatbots IA envoient les messages de mes clients à OpenAI ou à une société similaire ? Non, mais la majorité le fait, car c'est la manière la plus rapide et la moins coûteuse de construire un chatbot. Les éditeurs qui font tourner leur propre modèle auto-hébergé sont l'exception plutôt que la règle — mieux vaut le demander directement plutôt que de le supposer.

Quel est le risque de confidentialité réel lié à l'usage d'une API d'IA tierce ? Une société supplémentaire, et souvent un pays supplémentaire, s'ajoute au trajet de la donnée, chacun avec ses propres pratiques de conservation, d'accès et de sécurité — sans compter que les conversations peuvent parfois servir à améliorer les modèles du fournisseur. Cela ne constitue pas automatiquement une infraction, mais cela élargit nettement la surface de risque par rapport à une donnée qui reste dans l'infrastructure d'une seule société.

Un modèle d'IA auto-hébergé rend-il un chatbot conforme au RGPD ? Non. L'architecture d'hébergement et la conformité réglementaire sont deux questions distinctes. L'auto-hébergement peut réduire les transferts transfrontaliers de données, un facteur que les régulateurs surveillent, mais la conformité dépend aussi des pratiques de conservation, du consentement, des procédures en cas de violation de données, et de la documentation que l'éditeur doit pouvoir fournir sur demande.

Que dois-je demander à un éditeur de chatbot avant de m'engager ? Au minimum : où l'inférence IA a lieu, si les données servent à entraîner leurs modèles, combien de temps les conversations sont conservées, qui peut y accéder en interne, et quels sous-traitants sont impliqués. Un éditeur qui répond simplement et sans détour est un bon signe, quelle que soit son architecture.