Chatbot IA et RGPD : les quatre obligations qui se règlent dans l'architecture

Un chatbot interne paraît anodin : une zone de texte, un modèle, une réponse. C'est pourtant le traitement dont le périmètre est défini par ses utilisateurs et non par son concepteur, ce qui déplace la conformité du contrat vers l'architecture.

Par QDNA · Publié le 28 août 2026 · 10 min de lecture

Ce qui distingue un chatbot des autres traitements

Un chatbot interne paraît anodin : une zone de texte, un modèle, une réponse. Il concentre pourtant trois particularités qui le rendent nettement plus sensible qu'un formulaire ordinaire, et qui expliquent pourquoi sa conformité ne se règle pas comme celle d'un traitement classique.

L'utilisateur y verse ce qu'il veut, là où un formulaire contraint ses champs et une conversation n'impose aucune limite, si bien qu'un collaborateur y collera un extrait de contrat, un compte rendu d'entretien, le nom d'un client mécontent, parfois une donnée de santé. Le périmètre du traitement se trouve donc défini par les utilisateurs et non par le concepteur, ce qui interdit de le documenter après coup avec la moindre exactitude.

La conversation est conservée par défaut, un historique améliorant l'expérience, il existe dans la quasi-totalité des déploiements et constitue un fichier de données personnelles à part entière, que le registre des traitements oublie fréquemment parce que personne ne l'a décidé : il est apparu comme un effet de bord de la bibliothèque retenue.

La réponse peut se tromper avec aplomb, là où un moteur de recherche qui ne trouve rien l'annonce, un modèle de langage produit une réponse plausible dans tous les cas, y compris lorsqu'il n'a rien trouvé. Si le chatbot répond sur les congés, la paie ou une procédure interne, l'erreur emporte des conséquences concrètes et la question de l'intervention humaine se pose immédiatement.

Obligation 1 : dire que c'est une machine

La transparence constitue l'obligation la moins exigeante à satisfaire, et pourtant celle que les projets bâclent le plus souvent. Elle ne se satisfait pas d'une mention en pied de page : l'information doit être accessible au moment où la personne interagit.

Concrètement, trois éléments doivent être visibles dans l'interface elle-même : le fait que l'interlocuteur est un système automatisé, ce que deviennent les messages envoyés, et comment joindre un humain. Le règlement européen sur l'IA renforce cette exigence pour les systèmes qui interagissent directement avec des personnes physiques.

Le détail qui fait la différence en audit : la mention doit survivre à l'intégration. Un chatbot embarqué dans un outil métier, une messagerie interne ou un widget perd souvent son bandeau d'information en cours de route. C'est donc le composant lui-même qui doit porter la mention d'information, et non la page d'accueil du portail qui l'héberge.

Obligation 2 : la base légale, avant l'outil

Pour un chatbot interne, la base légale la plus courante est l'intérêt légitime de l'employeur : pas le consentement du salarié, dont la validité est fragile dans une relation hiérarchique. Ce choix n'est pas un détail de formulaire : il conditionne les droits que vous devrez servir et la mise en balance que vous devrez documenter.

Deux dérives reviennent systématiquement, et toutes deux transforment la nature du traitement sans que personne l'ait décidé.

• Le glissement de finalité. Un assistant déployé pour répondre aux questions RH devient, six mois plus tard, une source d'indicateurs sur l'activité des équipes. C'est une finalité nouvelle, qui exige sa propre analyse, et qui, si elle permet d'évaluer des personnes, change la nature du traitement.
• Le réentraînement implicite. Utiliser les conversations pour améliorer le modèle est une finalité distincte de celle d'y répondre. Si le fournisseur le fait par défaut, c'est un traitement que vous n'avez pas décidé mais dont vous répondez.

Obligation 3 : limiter ce qui reste

C'est ici que l'architecture décide et que les bonnes intentions cessent de suffire, car un chatbot laisse des traces à quatre endroits distincts dont la plupart des projets ne documentent que le premier.

Le dernier point de ce tableau est aussi le plus coûteux à corriger après coup : si un document est retiré parce qu'il n'aurait jamais dû être indexé, ses fragments demeurent interrogeables tant que l'index n'a pas été reconstruit ou purgé sélectivement. Une demande d'effacement portant sur ce document ne sera donc pas honorée, alors même que l'équipe est convaincue du contraire. Le sujet est traité plus dans une large mesure dans notre guide du RAG en entreprise.

Obligation 4 : prouver, ce qui suppose d'avoir conçu pour

Les trois obligations précédentes ne valent que si elles se démontrent, et quatre artefacts y suffisent, à condition de les construire pendant le projet plutôt qu'après sa mise en service.

• Le registre, qui inclut les quatre lieux de rétention du tableau ci-dessus et pas seulement l'historique visible.
• L'analyse d'impact, lorsque le chatbot traite des données sensibles ou permet d'évaluer des personnes. Le doute doit conduire à la faire, son absence étant plus difficile à justifier que son contenu.
• La cartographie des sous-traitants : quel modèle, hébergé où, sous quel contrat, avec quelle politique de conservation. Un modèle appelé via une API est un sous-traitant, même quand l'intégration a pris dix minutes.
• La journalisation des décisions de routage, si plusieurs modèles coexistent : c'est la seule preuve que les données sensibles n'ont pas emprunté le mauvais chemin. Voir le moteur d'orchestration.

Ce que change un modèle hébergé sur site

Faire tourner le modèle dans votre propre infrastructure ne vous exonère d'aucune des quatre obligations, puisque la transparence, la base légale, la limitation des durées et la preuve restent dues à l'identique.

Ce que le déploiement local change tient à la nature de la démonstration. Sur une API externe, vous démontrez par le contrat, c'est-à-dire par un engagement de non-réutilisation, une localisation déclarée et une durée de conservation annoncée, ce qui vous rend dépendant d'un tiers pour un fait que vous ne pouvez pas observer. Sur site au contraire, vous démontrez par l'architecture, puisque les journaux sont vos journaux, la purge est votre script, et le réentraînement n'a pas lieu parce que rien ne l'exécute.

La différence apparaît le jour où il faut prouver, parce qu'une clause contractuelle décrit une intention du fournisseur là où une trace d'exploitation décrit un fait établi. C'est la même logique que celle exposée dans IA générative et RGPD, appliquée au cas particulier du chatbot.

Le corollaire pratique, souvent contre-intuitif : un déploiement local mal exploité peut être moins conforme qu'une API bien contractualisée. Des journaux locaux conservés indéfiniment, sur un serveur dont personne ne surveille les accès, sont un risque, pas une garantie. La souveraineté donne la capacité de contrôler ; elle ne dispense pas de le faire.

Une trajectoire de mise en œuvre

L'ordre ci-dessous évite les reprises coûteuses, parce qu'il traite en premier ce qui est structurant.

1. Écrire la finalité en une phrase, et la liste de ce que le chatbot ne fera pas. C'est ce refus explicite qui protégera du glissement de finalité.
2. Décider où tournent les modèles selon la sensibilité, avant d'écrire du code. Revenir dessus après coup revient à refaire l'intégration.
3. Fixer les durées de conservation aux quatre endroits, et implémenter la purge tout de suite. Une purge ajoutée plus tard ne rattrape pas les données déjà accumulées.
4. Instrumenter avant d'ouvrir : sans journalisation des décisions dès le premier jour, la période de démarrage restera un angle mort.
5. Ouvrir à un périmètre restreint, observer ce que les utilisateurs y mettent réellement, puis ajuster. C'est la seule façon de connaître le périmètre réel du traitement.

Cet article décrit des conséquences d'architecture, il ne constitue pas un conseil juridique. Sources : recommandations IA et RGPD de la CNIL, fiches pratiques IA de la CNIL, règlement (UE) 2024/1689, recommandations de sécurité de l'ANSSI. Consultées le 28 août 2026.

Ce qu'il faut retenir

Les quatre obligations d'un chatbot conforme se révèlent, à l'examen, des décisions d'architecture déguisées en obligations juridiques. Informer se code dans le composant ; fonder se décide avant l'outil ; limiter se joue aux quatre endroits où la donnée se dépose ; prouver n'est possible que si les trois premières ont laissé une trace.

Le point de bascule est le choix de l'endroit où tourne le modèle, parce qu'il détermine si votre conformité repose sur un contrat ou sur une architecture que vous observez. Pour cadrer ce choix sur votre situation, un échange sans engagement suffit à poser les premières décisions. Le sujet est aussi traité par secteur, notamment pour la santé et le secteur public.