L'IA qui répond au client : ce que l'article 50 vous oblige à faire
Un chatbot qui ne dit pas qu'il en est un n'est plus seulement désagréable : il est irrégulier.
Le règlement européen sur l'intelligence artificielle contient, à son article 50, une obligation qui touche directement les outils de support : informer une personne qu'elle interagit avec un système d'IA, lorsque cela n'est pas déjà évident.
C'est une des rares obligations du texte qui concerne des systèmes sans risque particulier — donc à peu près tous les assistants de support. Elle n'a rien de théorique : elle se traduit par une phrase dans un premier message et une case dans un écran de réglages.
Ce que l'obligation dit, dans l'ordre
- 1Qui est tenu. Celui qui déploie le système, c'est-à-dire vous — l'entreprise qui met l'assistant devant ses clients — et non seulement l'éditeur du logiciel. C'est le point le plus mal compris : acheter un outil conforme ne rend pas votre usage conforme.
- 2Quoi. Informer la personne qu'elle interagit avec un système d'IA, de manière claire, au plus tard au moment de la première interaction.
- 3L'exception. Sauf lorsque c'est évident pour une personne raisonnablement informée, compte tenu des circonstances.
Tout le débat pratique porte sur le mot « évident », et la tentation est de s'y réfugier. Elle est mauvaise : sur un portail d'aide, un client qui pose une question à ce qui ressemble à un formulaire de contact n'a aucune raison de supposer qu'un modèle va lui répondre. L'évidence ne se décrète pas depuis l'intérieur de l'entreprise.
Les quatre situations d'un support, et la réponse pour chacune
| Situation | L'IA est-elle en interaction avec la personne ? | Divulgation |
|---|---|---|
| Triage : l'IA catégorise un ticket entrant | Non. Elle traite une donnée, elle ne dialogue pas | Non requise au titre de l'article 50 — mais c'est un traitement à inscrire au registre RGPD |
| Brouillon de réponse relu et envoyé par un agent | Non. C'est l'agent qui répond, et il en répond | Non requise. Le client parle bien à un humain |
| Résumé de fil pour l'agent | Non. Usage interne | Non requise |
| Réponse directe au client sur un portail ou un widget | Oui | Requise, dès le premier message |
Cette ligne de partage est utile parce qu'elle est simple : l'obligation naît quand le texte produit par le modèle part au client sans qu'un humain l'ait relu. C'est aussi, par coïncidence, la ligne où la responsabilité de l'entreprise change de nature.
Le cas que personne ne traite : le passage de main
Une conversation commence avec l'assistant, ne se résout pas, et bascule vers un agent. Trois questions, dont aucune n'a de réponse dans les articles disponibles :
- Le client est-il informé du changement ? Sinon, il continue de croire qu'il parle à une machine — ou l'inverse, ce qui est pire : il découvre après coup qu'un humain lisait.
- Que devient l'historique ? Les messages produits par le modèle restent-ils identifiés comme tels dans le fil que l'agent reprend, et dans celui que le client relit ?
- Et dans le sens inverse ? Un agent qui laisse l'assistant reprendre une conversation qu'il avait prise en main doit le dire aussi.
Notre choix : chaque message porte son auteur — assistant ou personne — de façon visible et durable dans le fil, des deux côtés. Un message d'assistant reste marqué comme tel dans l'historique un an plus tard. C'est plus contraignant qu'une bannière au début de la conversation, et c'est le seul moyen que l'information survive à la conversation elle-même.
Le piège de configuration : rendre l'obligation désactivable
Un éditeur peut faire de la divulgation une option. C'est commode commercialement — certains clients trouvent la mention peu élégante — et c'est un piège pour eux : vous leur donnez le moyen de produire une non-conformité en trois clics, sans avertissement.
La question à poser à votre éditeur est donc double, et la seconde partie compte autant que la première : *l'assistant s'annonce-t-il, et puis-je le désactiver ?* Si la réponse à la seconde est oui sans avertissement affiché à l'écran, l'outil vous laisse tranquillement dans l'irrégularité.
Chez nous, la mention n'est pas désactivable quand l'assistant répond seul au client. C'est un choix qu'on nous reprochera, et nous préférons ce reproche à l'autre.
Ce qu'il faut pouvoir montrer
Une obligation d'information se prouve, et la preuve n'est pas la capture d'écran d'une bannière. Trois éléments à exiger, qui sont aussi ceux que nous produisons :
- 1Une trace par appel. Quel modèle, quel fournisseur, pour quelle conversation, à quelle date. Chez nous chaque appel est journalisé, avec son coût et les rédactions appliquées — le journal, publié.
- 2Le marquage dans le fil, exportable avec la conversation. Une divulgation qui disparaît de l'export n'a jamais eu lieu du point de vue d'un contrôle.
- 3La configuration datée. Qui a activé quoi, quand. C'est ce qui distingue « nous informons » de « nous informions à l'époque ».
Ce que cela change à un achat d'outil
Quatre questions à ajouter à votre grille, formulées pour être posées telles quelles :
- Quand l'assistant répond seul, à quel moment s'annonce-t-il — avant la première réponse, ou dans un pied de page ?
- La mention est-elle désactivable ? Si oui, l'écran m'avertit-il de ce que je fais ?
- Un message d'assistant est-il identifiable dans l'historique un an plus tard, et dans l'export ?
- Au passage de main vers un humain, qui est informé, et comment ?
Notre position sur les quatre est décrite sur la page de l'assistant, et le code qui l'applique est lisible sous licence AGPL-3.0 — page open source. C'est la seule façon de vérifier une affirmation de conformité sans demander la permission à celui qui la fait.
Une obligation d'information qu'on peut désactiver dans un menu n'est pas une fonctionnalité de conformité : c'est un risque livré avec son interrupteur.
Nous ne publions pas d'article sans un chiffre mesuré chez nous, du code qu'on peut aller lire, ou une limite avouée. C'est la seule façon d'écrire sur ce métier sans répéter ce que tout le monde écrit déjà.