Le WordPress d'aujourd'hui, décodé pour les développeurs

Extensions

Un chatbot de collectivité : respecter le règlement européen sur l’IA

Quelles obligations de transparence et de journalisation le règlement européen sur l'IA impose à un assistant conversationnel public intégré à WordPress.

Par Clément Hadrot • 24 septembre 2024 • 4 min de lecture • Aucun commentaire
Un chatbot de collectivité : respecter le règlement européen sur l'IA

Comment savoir si l’on parle à un humain ou à un robot ? C’est la question à laquelle le règlement européen sur l’intelligence artificielle, entré en application par étapes depuis août 2024, oblige désormais à répondre explicitement pour tout service public qui déploie un assistant conversationnel. Une collectivité qui installe un chatbot sur son site WordPress pour répondre aux questions d’état civil ou d’urbanisme n’échappe pas à cette obligation, même si le volume de conversations reste modeste.

Le texte européen classe les systèmes d’IA par niveau de risque, et un chatbot d’accueil du public n’entre pas dans la catégorie « risque inacceptable » ni « haut risque » à lui seul. Il reste néanmoins soumis à des obligations de transparence spécifiques, prévues à l’article 50 du règlement, qui s’appliquent quel que soit le modèle utilisé derrière l’interface — un service tiers ou un modèle auto-hébergé.

L’obligation d’informer, avant toute question de qualité

La première obligation, et la plus simple à vérifier, est informative : la personne qui engage la conversation doit savoir dès le premier message qu’elle échange avec un système automatisé, sauf si cela est déjà manifeste du point de vue d’une personne raisonnablement informée. Concrètement, pour une extension WordPress qui affiche une fenêtre de chat, cela impose un message d’accroche explicite avant toute réponse générée :

<p>Vous échangez avec un assistant automatisé. Pour joindre un agent, écrivez « agent » à tout moment.</p>

Cette mention ne peut pas être reléguée dans les mentions légales du site : elle doit apparaître au niveau de l’interaction elle-même, avant ou au moment du premier échange.

Journaliser sans collecter plus que nécessaire

L'essentiel à retenir : L'obligation d'information prime sur la performance du modèle ; Journaliser les échanges est une obligation, pas une option ; Un humain doit rester joignable en cas d'échec du bot

Une collectivité doit pouvoir démontrer, en cas de contrôle ou de réclamation d’un administré, ce que le chatbot a répondu à une date donnée. Cela impose une journalisation systématique des échanges, distincte des journaux techniques classiques d’une extension : horodatage, question posée, réponse générée, et éventuellement le identifiant de session anonymisé, mais jamais de données d’identification directe non nécessaires au traitement de la demande.

  • Stocker les échanges dans une table dédiée, avec une durée de conservation définie et documentée dans le registre RGPD de la collectivité.
  • Ne jamais journaliser d’informations sensibles saisies par erreur (numéro de sécurité sociale, données de santé) sans filtrage préalable.
  • Prévoir un export possible des échanges pour répondre à une demande d’accès d’un administré, comme pour toute autre donnée personnelle traitée par la collectivité.

Garder une porte de sortie humaine

Le règlement n’impose pas explicitement un droit de recours humain pour tout chatbot de bas risque, mais les collectivités restent par ailleurs soumises au droit administratif classique, qui garantit un accès aux services publics. En pratique, un chatbot qui ne sait pas répondre, ou qui atteint un nombre de tours de conversation sans résolution, doit systématiquement proposer un canal humain — formulaire de contact, numéro de téléphone, adresse mail du service concerné — plutôt que de boucler indéfiniment sur des réponses génériques.

Le cas du modèle choisi n’est pas le sujet ici

Une confusion fréquente consiste à penser que la conformité dépend du modèle d’intelligence artificielle utilisé en coulisses. Ce n’est pas l’angle de cet article : que le chatbot s’appuie sur un modèle propriétaire distant ou sur un modèle open source auto-hébergé ne change rien aux obligations de transparence et de journalisation décrites ici, qui portent sur l’interaction avec l’usager, pas sur l’architecture technique du modèle.

Sur les projets de collectivité, la règle qu’on applique est simple : si un agent municipal ne peut pas expliquer en une phrase ce que fait le chatbot et où sont stockées les conversations, ce n’est pas prêt à être mis en ligne.

Notre verdict

Le règlement européen sur l’IA ne complexifie pas la construction technique d’un chatbot WordPress, mais il ajoute une couche d’obligations documentaires et d’affichage qui doivent être pensées dès la conception, pas ajoutées après coup. Pour une agence qui livre ce type de projet à une collectivité, la transparence de l’interaction et la journalisation encadrée des échanges sont les deux points à vérifier en priorité avant toute mise en ligne, bien avant la question du choix du fournisseur d’intelligence artificielle.

Partager :

À propos de l'auteur

Clément Hadrot

Développeur WordPress, passionné par Elementor, le FSE et l’automatisation par IA.

Voir tous ses articles

Dans la même veine

À lire aussi