Quand les chatbots deviennent plateformes : obligations et risques pour les services d’intelligence artificielle en Europe

Un chatbot qui ajoute la recherche, la diffusion de contenus, des profils personnalisés ou des interactions sociales ne se comporte plus comme un simple outil de réponse : il peut devenir une plateforme, avec des responsabilités plus larges. Pour les équipes produit, comprendre quand un chatbot plateforme change de régime est essentiel pour anticiper les obligations européennes en matière d’intelligence artificielle, de données, de contenus et de protection des utilisateurs.

Le point de départ consiste à ne pas réduire l’analyse au modèle utilisé. Le fournisseur du modèle, l’entreprise qui intègre le chatbot et l’opérateur qui distribue un service doté de fonctions de plateforme peuvent occuper des rôles différents et cumuler des obligations. Les évolutions européennes récentes relatives aux modèles GPAI, aux compagnons IA et aux plateformes renforcent l’intérêt d’une cartographie précise des fonctions, des publics et des flux de données.

Quand un chatbot devient-il une plateforme d’intelligence artificielle ?

Un assistant conversationnel limité à une interface de questions-réponses n’a pas le même profil qu’un service qui organise l’accès à plusieurs fonctions et met en relation des utilisateurs, des contenus ou des services. Le basculement ne dépend pas seulement du nom commercial du produit ni de la taille de son audience. Il tient surtout à ce que le service permet de faire, à la manière dont il distribue des contenus et au degré de contrôle exercé sur les interactions.

Un produit peut, par exemple, commencer comme un assistant de rédaction, puis intégrer une recherche sur le web, des recommandations, des agents spécialisés, l’hébergement de créations d’utilisateurs ou des espaces d’échange. Ces ajouts ne rendent pas automatiquement le service illégal ou soumis à une catégorie juridique unique. Ils augmentent cependant le nombre de risques à examiner et peuvent rapprocher l’opérateur d’une logique de plateforme, avec des obligations qui ne se limitent plus au modèle d’IA.

Réponse directe : un chatbot devient plus proche d’une plateforme lorsque, au-delà de générer des réponses, il organise la découverte, la diffusion ou l’échange de contenus et d’interactions. L’analyse européenne doit alors distinguer le fournisseur du modèle, l’intégrateur du chatbot et l’opérateur du service, puis examiner les fonctions réellement proposées.

Pour cadrer le périmètre, les équipes peuvent examiner les fonctions une par une plutôt que de qualifier le produit en bloc :

  • Recherche et agrégation : le chatbot interroge-t-il des contenus externes, les classe-t-il ou les présente-t-il dans une interface de découverte ?
  • Publication et diffusion : les utilisateurs peuvent-ils créer, partager, héberger ou faire circuler des contenus au moyen du service ?
  • Personnalisation : le service adapte-t-il les réponses ou les recommandations au profil, à l’historique ou aux préférences de la personne ?
  • Interaction sociale : des utilisateurs échangent-ils entre eux, avec des personnages conversationnels ou dans des espaces collectifs ?
  • Fonctions affectives : le chatbot se présente-t-il comme un compagnon, entretient-il une relation prolongée ou adapte-t-il ses réponses à l’état émotionnel perçu ?

Cette grille n’est pas un test juridique automatique. Elle aide à repérer les endroits où les risques se déplacent : d’une réponse générée vers la modération d’un espace, d’un modèle vers une expérience personnalisée, ou d’une interface vers une relation conversationnelle qui peut affecter des personnes vulnérables. Un service qui combine plusieurs fonctions doit donc analyser leurs effets ensemble, et pas uniquement leurs composants techniques isolés.

Chatbot plateforme : distinguer fournisseur du modèle, intégrateur et opérateur

La distinction entre les rôles est déterminante, car la conformité se construit à plusieurs niveaux. Le fournisseur du modèle développe ou met à disposition le modèle sous-jacent. L’intégrateur l’emploie pour créer le chatbot et choisit notamment son interface, ses instructions, ses outils et ses limites. L’opérateur de plateforme exploite le service auprès des utilisateurs et peut ajouter des fonctions de recherche, d’hébergement, de diffusion ou d’interaction sociale.

Dans certains produits, une même entreprise peut tenir plusieurs de ces rôles. Dans d’autres, ils sont répartis entre un fournisseur de modèle externe, un éditeur de logiciel et une entreprise qui commercialise le service final. Cette répartition ne supprime pas les responsabilités de l’opérateur : elle rend nécessaire une compréhension documentée de ce que chaque partie contrôle, fournit et sait sur le système.

Cartographier la chaîne de valeur avant le lancement

Une cartographie utile ne se limite pas aux contrats. Elle relie les acteurs aux fonctions qu’ils opèrent effectivement : qui choisit le modèle, qui règle les filtres, qui détermine les usages permis, qui collecte les données, qui publie les réponses et qui traite les signalements ? Ces questions permettent de repérer les dépendances et les zones où une obligation ou une mesure de prévention pourrait rester sans responsable clairement désigné.

  1. Identifier les composants : recenser les modèles, outils de recherche, bases de connaissance, systèmes de recommandation et interfaces qui participent à l’expérience.
  2. Attribuer les décisions : préciser quelle entité choisit les fonctions activées, les publics visés, les contenus accessibles et les mécanismes de contrôle.
  3. Décrire les interactions : suivre le parcours depuis la demande de l’utilisateur jusqu’à la réponse, y compris les appels à des services tiers et les éventuelles publications.
  4. Prévoir la coopération : organiser l’accès aux informations utiles, la gestion des incidents et la mise à jour des mesures lorsque le modèle ou le produit évolue.

Cette démarche devient particulièrement importante quand un chatbot repose sur un modèle GPAI. Les obligations applicables au fournisseur du modèle peuvent avoir des conséquences sur l’architecture, les documents et les conditions de déploiement du service intégré. L’entreprise qui construit la plateforme doit donc connaître les informations disponibles en amont et évaluer si elles suffisent à maîtriser les risques de son propre produit.

Il faut également éviter deux raccourcis. Le premier serait de supposer que le fournisseur du modèle porte, à lui seul, toute la responsabilité du service final. Le second serait de penser qu’un opérateur de plateforme peut corriger après coup les limites du modèle sans accès aux informations nécessaires. Une gouvernance efficace organise plutôt la coopération entre acteurs et conserve une vision propre des usages, des publics et des effets de l’interface.

Les obligations AI Act pertinentes pour les chatbots et les modèles GPAI

Les obligations les plus directement visibles pour un service conversationnel concernent la transparence envers les personnes. L’AI Act impose déjà aux chatbots qui interagissent directement avec des personnes de les informer qu’elles échangent avec une IA. Cette information doit être pensée dans le parcours réel : une mention difficile à trouver ou éloignée de l’interaction ne répond pas nécessairement au besoin pratique de clarté que l’obligation vise à servir.

La transparence ne devrait donc pas être traitée comme un simple élément de pied de page. L’équipe produit peut vérifier que la nature artificielle de l’interlocuteur est compréhensible au moment où l’échange commence, puis rester cohérente lorsque l’expérience change de forme, par exemple lorsqu’un assistant devient un personnage conversationnel ou qu’il intervient dans un espace communautaire. Il s’agit ici d’une approche de conception prudente, et non d’une prétention à remplacer l’analyse juridique du service concret.

Les exigences applicables aux modèles GPAI

À partir du 2 août 2025, les fournisseurs de modèles d’IA à usage général, ou GPAI, doivent respecter des obligations spécifiques sous l’AI Act. Les éléments indiqués comprennent des exigences de transparence, une politique de conformité au droit d’auteur et un résumé public des données d’entraînement. La Commission rappelle également la nécessité d’une politique de respect du droit d’auteur de l’Union et d’une synthèse publique des données de training.

Pour un chatbot construit sur un modèle GPAI, ces obligations peuvent se répercuter sur le service, même si elles visent d’abord le fournisseur du modèle. L’intégrateur doit comprendre la provenance et les limites des informations qu’il reçoit, apprécier le rôle du modèle dans ses usages et examiner si ses propres fonctionnalités créent des risques supplémentaires. Lorsque le produit agrège des fonctions, la transparence du modèle ne remplace pas la transparence sur l’expérience complète proposée à l’utilisateur.

La Commission a indiqué qu’à partir du 2 août 2026 elle appliquerait la conformité complète pour les fournisseurs de modèles GPAI, y compris au moyen de sanctions. Cette perspective donne un enjeu opérationnel à la préparation : les équipes qui dépendent de fournisseurs externes ont intérêt à savoir comment elles suivront les évolutions documentaires, les changements de modèle et les conséquences éventuelles sur le service déployé.

Ce que l’obligation implique côté produit

Une entreprise qui intègre un modèle ne devrait pas prétendre produire elle-même les informations que seul le fournisseur amont peut établir. Elle peut, en revanche, organiser son propre dispositif de conformité : sélectionner les fournisseurs avec attention, documenter les usages autorisés, suivre les évolutions communiquées et vérifier que les promesses adressées aux clients sont compatibles avec les capacités réellement disponibles.

  • Conserver une fiche interne des modèles utilisés et des fonctions qui en dépendent.
  • Relier les changements de modèle aux tests de qualité, de sécurité et de comportement du chatbot.
  • Examiner les conditions d’accès aux informations sur l’entraînement et les restrictions d’usage communiquées par le fournisseur.
  • Éviter d’annoncer une traçabilité ou une conformité complète que l’entreprise ne peut pas démontrer.

Ces mesures ne se substituent pas aux obligations légales propres à chaque acteur. Elles rendent néanmoins plus facile l’identification d’un problème lorsque le produit évolue, qu’un fournisseur change ses pratiques ou qu’une fonctionnalité crée une nouvelle exposition réglementaire.

Compagnons IA, mineurs et risques de manipulation

Les compagnons IA et les chatbots conversationnels généraux font l’objet d’un encadrement spécifique dans des textes européens récents de 2026, avec des obligations ciblant notamment les plateformes sociales, de vidéo et de jeux qui intègrent ces fonctions. Cette évolution confirme que les institutions ne regardent plus seulement le modèle ou l’outil conversationnel : elles s’intéressent aussi à la plateforme qui distribue la fonction et au contexte dans lequel les personnes l’utilisent.

Le risque ne tient pas uniquement à une réponse inexacte. Une relation conversationnelle prolongée, conçue pour susciter le retour fréquent ou l’attachement, peut soulever des préoccupations particulières lorsque des mineurs sont concernés. La proposition et l’analyse d’impact de 2026 soulignent que certains designs peuvent exposer les jeunes à des dépendances émotionnelles ou à des pratiques manipulatrices. Le Conseil et la Commission reconnaissent également des risques spécifiques pour les mineurs, alors que les mesures de safety by design ne sont pas encore aussi détaillées que pour d’autres catégories d’IA.

Cette relative absence de détail prescriptif ne doit pas être interprétée comme une absence de responsabilité. Elle signifie plutôt que les opérateurs doivent prendre au sérieux la conception de leurs propres garde-fous, en tenant compte du public visé, des mécanismes d’engagement et de la manière dont le système répond aux signes de détresse ou aux demandes sensibles. Les institutions européennes présentent la protection de la santé, de la sécurité et des droits fondamentaux, notamment ceux des mineurs, comme un objectif central de l’encadrement.

Examiner l’expérience, pas seulement les réponses isolées

Un contrôle ponctuel des réponses ne suffit pas à comprendre une relation qui se construit dans le temps. L’équipe doit aussi regarder les mécanismes de produit qui peuvent encourager une interaction prolongée, créer une impression de dépendance ou brouiller la distinction entre un système artificiel et une relation humaine. Le bon niveau d’analyse est celui du parcours : ce que l’utilisateur voit, ce que le chatbot lui demande, ce qu’il retient et la façon dont il relance la conversation.

Pour structurer cette évaluation, les équipes peuvent documenter les décisions de conception suivantes :

  • Le service est-il destiné aux adultes, aux mineurs, ou à un public mixte ?
  • Les utilisateurs comprennent-ils clairement qu’ils interagissent avec une IA, y compris après plusieurs échanges ?
  • Le chatbot sollicite-t-il de nouvelles interactions, et selon quelles règles de conception ?
  • Les réponses personnalisées peuvent-elles exploiter une vulnérabilité ou renforcer une situation de dépendance ?
  • Existe-t-il un moyen compréhensible de quitter l’expérience, de supprimer un historique ou de demander de l’aide ?

Ces questions sont des outils de conception et de gouvernance, pas une liste exhaustive d’exigences juridiques. Elles permettent de relier les risques humains aux décisions concrètes de produit plutôt que de traiter la protection des mineurs comme une déclaration générale sans traduction opérationnelle.

La Commission indique par ailleurs que, selon les fonctionnalités, un compagnon IA peut relever d’une pratique interdite ou d’un système à haut risque, notamment s’il intègre de la reconnaissance des émotions. Elle rappelle aussi que certaines formes de manipulation ou d’exploitation des vulnérabilités peuvent déjà relever des interdictions existantes de l’AI Act. Ainsi, l’ajout d’une fonction émotionnelle n’est pas un détail d’interface : il peut modifier la qualification et le niveau d’exigence applicable au service.

Données personnelles, scraping et droit d’auteur dans un chatbot plateforme

Les risques liés aux données sont particulièrement importants lorsqu’un chatbot s’appuie sur de grands modèles de langage, personnalise ses réponses ou aspire des contenus pour enrichir sa base de connaissances. En 2025, l’EDPB a publié un rapport consacré aux risques de confidentialité des LLM et aux mesures d’atténuation, en prenant comme cas d’usage un chatbot d’assistance client. Les risques de fuite de données, de mémorisation indue et de réidentification restent donc des sujets centraux pour les produits conversationnels.

Ces risques ne disparaissent pas parce qu’une donnée a été transmise sous forme de prompt ou parce qu’une réponse est produite automatiquement. Une information communiquée par un client peut réapparaître dans une sortie, être conservée plus longtemps que prévu ou permettre d’identifier une personne lorsqu’elle est combinée avec d’autres éléments. La plateforme doit donc comprendre quels flux alimentent le chatbot et où les données peuvent être enregistrées, transformées, consultées ou réutilisées.

Réduire les risques de confidentialité par conception

Les mesures concrètes dépendent du produit et des traitements envisagés. Elles peuvent toutefois être organisées autour de quelques vérifications pratiques : limiter les informations personnelles collectées, éviter d’envoyer au modèle des éléments qui ne sont pas nécessaires à la tâche, définir des règles de conservation et tester les réponses susceptibles de révéler des informations confidentielles. Il faut également vérifier les accès internes et les dépendances avec les prestataires qui participent à l’exécution du service.

Un chatbot d’assistance client illustre bien le problème. Il peut recevoir des demandes contenant des détails sur un compte, une commande ou une situation personnelle. Si le système mémorise ou réutilise ces éléments de façon inattendue, le risque ne porte pas seulement sur l’exactitude de la réponse : il touche à la confidentialité et à la confiance dans l’ensemble du service. Les équipes doivent donc tester les parcours représentatifs et les cas où une personne demande des informations qu’elle ne devrait pas obtenir.

En 2026, l’EDPB a également insisté sur la nécessité d’encadrer l’anonymisation et le web scraping dans les systèmes génératifs. Ces questions concernent directement les plateformes qui aspirent des contenus web pour alimenter un chatbot, améliorer ses réponses ou les personnaliser. Une donnée dite anonymisée ne doit pas être considérée comme hors de risque sans examen, et l’accès technique à un contenu public ne suffit pas à résoudre toutes les questions liées à son réemploi.

Articuler données d’entraînement et contenus protégés

Les obligations GPAI relatives à la politique de conformité au droit d’auteur de l’Union et au résumé public des données d’entraînement donnent une visibilité particulière aux enjeux de provenance. Pour un opérateur de chatbot plateforme, le sujet peut concerner à la fois le modèle sous-jacent, les contenus aspirés au moyen d’une fonction de recherche et les contributions publiées par les utilisateurs. Ces catégories ne sont pas interchangeables : les sources, les usages et les contrôles doivent être analysés séparément.

Une démarche prudente consiste à documenter les sources utilisées par les composants du service, les finalités de leur collecte ou de leur indexation, ainsi que les responsabilités convenues avec les fournisseurs. Lorsqu’une fonctionnalité permet de rechercher ou de reproduire des contenus, il faut aussi examiner comment le produit traite les demandes qui conduisent à restituer des éléments protégés. Les informations disponibles ne permettent pas de conclure que tout entraînement ou toute indexation serait autorisé ou interdit dans tous les cas : l’analyse doit rester liée aux usages et aux faits propres au produit.

En pratique, la gouvernance des données doit couvrir toute la chaîne, et pas uniquement le jeu d’entraînement du modèle. Elle doit inclure les prompts, les historiques, les documents importés, les résultats de recherche et les contenus que les utilisateurs publient. Cette vue d’ensemble facilite les arbitrages entre personnalisation et minimisation des données, entre richesse fonctionnelle et maîtrise des sources, ainsi qu’entre expérience fluide et possibilité de contrôle.

Pourquoi l’AI Act et le DSA se croisent pour les services de plateforme

Le débat européen lie de plus en plus l’AI Act et le DSA lorsque des plateformes intègrent des fonctionnalités de chatbot. Les deux cadres ne doivent pas être confondus, mais ils ne peuvent pas toujours être examinés séparément dans un produit où l’IA intervient dans la découverte, la modération, la recommandation ou la diffusion de contenus. Un service peut devoir analyser à la fois la manière dont son système d’IA fonctionne et la manière dont sa plateforme organise les interactions et les contenus.

Le changement de perspective est important pour les équipes qui avaient conçu leur chatbot comme une fonction isolée. Dès qu’il devient un point d’entrée vers des contenus, qu’il aide à les classer ou qu’il facilite leur circulation, les risques de gouvernance dépassent la relation entre un utilisateur et un modèle. La modération, la transparence et l’évaluation des risques deviennent des sujets liés à l’architecture globale du service.

Par exemple, un assistant qui ne fait que résumer un document fourni par une entreprise n’a pas le même contexte qu’un chatbot intégré à un espace social où des utilisateurs publient, recommandent et commentent des contenus. Dans le second cas, les réponses générées peuvent se mêler aux contenus d’utilisateurs, contribuer à leur visibilité ou influencer les échanges. Il faut donc déterminer comment sont identifiés les contenus générés, qui peut agir lorsqu’un problème est signalé et comment les décisions prises par le système s’intègrent aux mécanismes de gouvernance du service.

Une lecture fonctionnelle plutôt qu’une conformité en silos

Une organisation peut répartir ses travaux entre équipes juridiques, produit, sécurité et données, mais elle devrait conserver une analyse commune du parcours utilisateur. Sans cela, l’équipe chargée du modèle risque d’ignorer les effets de la diffusion, tandis que l’équipe plateforme peut ne pas savoir quelles limites viennent du système d’IA ou de ses données. Une vision partagée permet de repérer les responsabilités qui se chevauchent et les contrôles qui manquent.

  • Pour les équipes IA : documenter le modèle, les fonctions activées, les tests réalisés et les limites connues.
  • Pour les équipes plateforme : comprendre comment les sorties circulent, comment les utilisateurs interagissent et quels mécanismes de modération existent.
  • Pour les équipes de protection des données : suivre les flux d’informations, les usages de l’historique et les risques de divulgation ou de réidentification.
  • Pour les équipes produit : intégrer les obligations et les garde-fous dans les choix d’interface, les parcours et les réglages par défaut.

Cette coopération n’implique pas que chaque chatbot soit automatiquement soumis à toutes les obligations applicables à une plateforme. Elle permet plutôt de vérifier les critères propres au service, sans inférer une qualification juridique uniquement à partir d’un mot comme plateforme, compagnon ou assistant. Le périmètre doit être confirmé au regard des fonctions réellement proposées et des textes applicables.

Construire une architecture et une gouvernance adaptées au risque

La conformité ne se résume ni à une mention de transparence ni à un dossier produit rédigé une fois pour toutes. Les chatbots évoluent : un modèle peut être remplacé, une fonction de recherche ajoutée, un nouveau public ciblé ou une interaction sociale activée. Une architecture de gouvernance utile doit pouvoir repérer ces changements et déclencher une nouvelle évaluation lorsqu’ils modifient les usages ou les risques.

Mettre en place un processus d’examen avant chaque évolution majeure

Une équipe peut intégrer un contrôle réglementaire et produit aux étapes de conception, de test et de mise en production. L’objectif n’est pas de ralentir toute expérimentation, mais d’éviter que des changements fonctionnels importants arrivent en production sans analyse de leurs conséquences. Une procédure concise, appliquée de façon régulière, est souvent plus exploitable qu’une politique générale que les équipes ne consultent pas.

  1. Décrire la fonction : préciser ce qui change pour l’utilisateur, ce que le chatbot peut désormais faire et quelles sources ou outils il mobilise.
  2. Revoir les rôles : vérifier si l’entreprise reste seulement intégratrice ou assume désormais aussi une fonction d’opérateur de plateforme.
  3. Analyser les publics : établir si le changement touche des mineurs ou d’autres publics vulnérables et s’il crée une relation conversationnelle plus forte.
  4. Contrôler les données : identifier les nouvelles données collectées, les sources aspirées, les informations conservées et les risques de réidentification.
  5. Tester les scénarios sensibles : vérifier les réponses et les comportements du service dans les situations susceptibles d’entraîner une divulgation, une manipulation ou une exposition à des contenus inadaptés.
  6. Conserver les décisions : consigner les arbitrages, les limites retenues, les responsables et les conditions qui déclencheront une nouvelle revue.

Les tests doivent porter sur l’expérience complète, pas seulement sur la qualité linguistique d’une sortie. Une réponse peut sembler correcte isolément tout en s’inscrivant dans un parcours qui incite un mineur à poursuivre une relation affective ou qui révèle des éléments issus d’un historique. À l’inverse, une erreur ponctuelle ne suffit pas toujours à caractériser le risque du système entier. L’analyse gagne en précision lorsqu’elle relie les comportements observés aux fonctions, aux publics et aux mécanismes de contrôle.

Prévoir les dépendances aux modèles et aux prestataires

Un chatbot plateforme repose souvent sur plusieurs composants externes. Les équipes doivent savoir ce qui se passe si un fournisseur modifie le modèle, retire une fonction, change ses informations ou ne permet plus d’obtenir les éléments nécessaires à l’évaluation. La préparation à ces scénarios relève autant de la continuité technique que de la maîtrise du risque réglementaire.

Une stratégie réaliste peut prévoir des critères d’évaluation des fournisseurs, des solutions de repli lorsqu’elles sont techniquement envisageables, et des règles internes pour désactiver une fonction si un risque ne peut pas être maîtrisé. Il ne s’agit pas de promettre une indépendance totale vis-à-vis des modèles, mais d’éviter qu’une dépendance critique empêche l’entreprise de comprendre ou de contrôler les effets de son service.

Pour les entreprises situées hors de l’Union, un point supplémentaire est à intégrer : les fournisseurs non établis dans l’UE qui offrent des services d’AI companions ou de chatbots conversationnels généraux dans l’Union devront désigner un représentant légal dans un État membre. Les acteurs extra-européens qui distribuent leurs services comme plateformes doivent donc traiter cette exigence comme un élément de leur organisation européenne, et non comme une simple formalité à reporter jusqu’à l’ouverture du service.

Amendes, responsabilité et décisions à prendre avant le déploiement

Le risque financier associé aux nouveaux textes sur les compagnons IA et les chatbots conversationnels peut être élevé. Selon le texte de 2026, le non-respect de certaines obligations peut entraîner des amendes administratives allant jusqu’à 6 % du chiffre d’affaires annuel mondial précédent. Ce plafond concerne certaines obligations et ne doit pas être présenté comme une sanction automatique pour toute erreur liée à un chatbot.

Une analyse raisonnable doit cependant aller au-delà du montant potentiel de l’amende. Les risques matériels incluent l’exposition de données, des effets défavorables sur les mineurs, une atteinte aux droits fondamentaux ou l’utilisation de contenus sans maîtrise suffisante de leur provenance. Un service peut ainsi créer des conséquences opérationnelles, réputationnelles et commerciales même lorsque la question de la sanction administrative n’est pas tranchée.

L’EDPB a averti en 2026 que l’évolution rapide de l’IA justifie de préserver ou d’accélérer certaines obligations, notamment la transparence, plutôt que de les retarder. Cette position rappelle aux entreprises qu’elles ne devraient pas fonder leur plan de conformité sur l’hypothèse d’un assouplissement général. Elles ont intérêt à concevoir des mécanismes de transparence et de contrôle qui restent utiles même si les détails d’application évoluent.

Choisir entre lancement limité, adaptation ou retrait d’une fonction

Lorsque l’évaluation révèle un risque important, la réponse n’est pas nécessairement de renoncer à l’IA. Il est possible de réduire le périmètre du produit, de réserver une fonction à certains usages, d’ajouter des contrôles, de revoir le public visé ou de reporter une fonctionnalité qui ne peut pas être encadrée de façon satisfaisante. Cette approche progressive permet de préserver la valeur du service sans confondre ambition produit et nécessité de lancer toutes les fonctions simultanément.

Une équipe peut notamment comparer trois options :

  • Lancer une version limitée : proposer une interaction circonscrite, avec des fonctions et des sources mieux maîtrisées, puis réévaluer avant d’élargir le service.
  • Adapter le design : modifier les incitations, les réglages par défaut ou la manière dont le système présente sa nature et ses capacités.
  • Ne pas activer une fonction : retirer ou différer une capacité lorsque le risque, la dépendance fournisseur ou l’absence de contrôle est trop important.

Le compromis central est souvent celui de la richesse fonctionnelle contre la capacité de gouvernance. Une recherche plus large peut rendre le chatbot plus utile, mais accroître la difficulté de suivre les sources et les contenus restitués. Une personnalisation forte peut améliorer la pertinence, mais augmenter l’exposition liée aux données et rendre plus délicate la protection des personnes vulnérables. Une relation conversationnelle plus immersive peut renforcer l’engagement, mais appelle un examen accru de la transparence et des risques de manipulation.

La décision de déploiement doit donc relier les bénéfices attendus aux moyens réels de contrôle. Si l’entreprise ne peut pas expliquer quel acteur maîtrise une fonction, quelles données elle mobilise ou comment elle protège un public vulnérable, il est préférable de clarifier ces points avant d’étendre le service. Une gouvernance crédible repose sur des décisions vérifiables et des responsabilités attribuées, pas uniquement sur des principes affichés.

Pour les entreprises qui conçoivent un chatbot en Europe, le changement de perspective est concret : le modèle n’est qu’une partie du produit. Dès que le service agrège des contenus, personnalise les échanges, héberge des interactions ou s’adresse à des mineurs, il faut examiner ensemble le rôle du fournisseur GPAI, celui de l’intégrateur et celui de l’opérateur de plateforme, tout en tenant compte des données, du droit d’auteur et des effets de l’expérience.

La meilleure préparation consiste à cartographier les fonctions et les responsabilités dès la conception, à intégrer la transparence dans le parcours utilisateur et à réévaluer les risques à chaque évolution importante. À mesure que les chatbots deviennent des plateformes, ces pratiques permettent de prendre des décisions de lancement plus solides et de faire évoluer le service sans perdre de vue la sécurité, les droits fondamentaux et la confiance des utilisateurs.