Chatbot service public : usages réels et cadre légal en 2026

Les standards téléphoniques des mairies sonnent toujours aux mêmes heures : lundis matins, veilles de vacances, période des cartes d’identité avant l’été. Derrière, une grande partie des questions portent sur des choses simples : quels papiers apporter, où retirer un formulaire, comment prendre rendez-vous. Le chatbot de service public est né de ce constat : offrir une réponse immédiate, 24 heures sur 24, sans mobiliser un agent pour relire la même fiche. Mais déployer un agent conversationnel quand on est une personne morale de droit public, ce n’est pas installer un widget comme une marque commerciale : la loi impose des garanties supplémentaires, et elles viennent de changer. Ce guide fait le tour complet du sujet : usages réels, cadre légal au 16 septembre 2026, et méthode de déploiement.

Chatbot service public : de quoi parle-t-on exactement ?

Un chatbot de service public est un agent conversationnel publié par un organisme public (commune, EPCI, département, service de l’État, opérateur public comme un CCAS ou un bailleur social) sur son site, son portail de démarches ou sa messagerie. Son but : répondre aux usagers sur les démarches de l’organisme, sans qu’un agent ait à répéter la même information. On parle bien du bot tourné vers les usagers : l’assistant réservé aux agents d’une administration est un autre sujet, couvert par notre guide du chatbot interne.

Cette famille d’outils n’est pas théorique. L’État et ses opérateurs en publient déjà : le site Service Public Entreprendre (Dila) répond aux créateurs d’entreprise via le chatbot NOA, présenté sur une page officielle comme l’outil « réponse aux questions sur la création d’entreprise pour les start-up » (page consultée le 16 septembre 2026). La DINUM, elle, opère l’Assistant, un agent conversationnel réservé aux agents publics dont nous reparlons plus bas. Côté communes, l’offre s’est structurée autour de bots d’accueil dédiés aux mairies, souvent couplés à la prise de rendez-vous.

Trois familles de missions, trois niveaux d’exigence

Tous les projets « chatbot public » ne se valent pas, et c’est la première distinction à faire avant d’écrire la moindre ligne de cahier des charges. On peut regrouper les missions en trois familles, par niveau de risque croissant (la typologie complète des technologies se trouve dans notre article sur les types de chatbots) :

• L’information générale : horaires, coordonnées, pièces à fournir, délais, orientation vers le bon service. Le bot lit une base de connaissances et renvoie vers la page officielle. Aucune donnée personnelle n’a besoin d’être collectée.
• L’accompagnement d’une démarche en ligne : aider l’usager à remplir un téléservice, reprendre une démarche sauvegardée, prendre ou déplacer un rendez-vous (carte d’identité, passeport, conseil municipal). Le bot touche ici des données d’identification et des numéros de dossier.
• Le conseil individualisé : « ai-je droit à telle aide », « que risque-je si… », « comment contester ». Le bot produit une réponse qui engage la vie de l’usager : c’est la famille la plus sensible, où la frontière entre informer et conseiller doit rester visible.

Cette grille revient tout au long de l’article, et l’outil de cadrage en fin de page s’en sert comme colonne vertébrale : plus la mission monte en individualisation, plus le cadre juridique se durcit.

Ce qu’un chatbot public peut faire (et ce qui doit rester humain)

La valeur d’un bot d’accueil public se mesure à ce qu’il décharge réellement les agents, pas à son nombre de réponses. Le tableau ci-dessous résume le périmètre réaliste, telle une fiche de service :

Concrètement, une commune qui démarre retient presque toujours le même trio : questions récurrentes de l’accueil, horaires et pièces, rendez-vous. C’est le périmètre où le bot rend service sans jamais s’approcher d’une décision, et où l’usager comprend immédiatement à qui il parle. Le suivi de dossier vient ensuite, car il suppose des connecteurs vers le système d’information (état civil, téléservices) et une politique de données écrite. Le conseil individualisé, lui, ne se lance pas sans un vrai travail juridique en amont.

Le cadre légal : ce qui a changé le 2 août 2026

Le règlement européen sur l’intelligence artificielle (règlement (UE) 2024/1689, dit « AI Act ») s’applique par étapes depuis son entrée en vigueur le 1er août 2024. Il a été modifié par le train de mesures dit « omnibus » : la CNIL rappelle qu’une version amendée « a été adoptée le 24 juillet 2026 et est entrée en vigueur le 27 juillet 2026 » (page CNIL mise à jour le 17 août 2026). Pour un chatbot public, la date qui compte est la suivante, citée de la même page : « 2 août 2026 : Obligations de transparence concernant certains systèmes d’IA ». Nous y sommes : ces obligations sont applicables au jour où nous écrivons.

Dire à l’usager qu’il parle à un système d’IA

C’est l’obligation la plus visible de l’article 50. Le texte consolidé au 27 juillet 2026 dispose :

Lisez bien le début : l’obligation pèse sur le fournisseur du système, c’est-à-dire celui qui le développe et le met sur le marché, pas directement sur la mairie qui l’achète. En pratique, cela ne vous exonère de rien : un organisme public qui déploie une solution doit vérifier que la mention est bien là, visible dès l’ouverture du chat, et la maintenir. « Sauf si cela ressort clairement » : un widget baptisé « assistant automatique de la mairie » avec réponses instantanées type menu peut rendre l’évidence discutable ; la prudence élémentaire consiste à afficher la mention dans tous les cas. Un bot génératif, lui, ne peut jamais s’en passer.

Marquer les contenus générés

Deuxième obligation de l’article 50 : les fournisseurs de systèmes d’IA qui génèrent des contenus de synthèse (audio, image, vidéo ou texte) doivent veiller à ce que les sorties soient « marquées dans un format lisible par machine et identifiables comme ayant été générées ou manipulées par une IA » (article 50, paragraphe 2, même version consolidée). Pour les systèmes mis sur le marché avant le 2 août 2026, la CNIL date cette obligation de transparence au 2 décembre 2026. Un chatbot public branché sur un modèle génératif est directement concerné : les textes qu’il produit relèvent du marquage, et l’organisme qui le déploie a intérêt à exiger de son fournisseur la façon dont c’est implémenté.

Des agents qui maîtrisent l’outil

Troisième pilier, souvent oublié des cahiers des charges : l’article 4 du règlement, rebaptisé « Maîtrise de l’IA » par la version amendée, impose aux fournisseurs et aux déployeurs de « prendre des mesures pour favoriser le développement de la maîtrise de l’IA par leur personnel et les autres personnes s’occupant du fonctionnement et de l’utilisation des systèmes d’IA pour leur compte » (article 4, paragraphe 1, version consolidée du 27 juillet 2026). Le déployeur, ici, c’est vous : l’administration qui met le bot à disposition de ses usagers. Concrètement, les agents qui surveillent les conversations, alimentent la base de connaissances et remontent les réponses fautives doivent savoir ce que l’outil fait, et ne fait pas. Le texte précise qu’il ne vous oblige pas à garantir un niveau de maîtrise précis pour chaque individu : c’est une obligation de moyens, pas de diplôme.

L’accessibilité, la spécificité que le privé n’a pas

Ici, le service public joue dans une autre catégorie que le commerce. L’article 47 de la loi n° 2005-102 du 11 février 2005 (version en vigueur depuis le 8 septembre 2023) impose que « sont accessibles aux personnes handicapées dans les conditions définies au présent article […] les services de communication au public en ligne des organismes suivants : 1° Les personnes morales de droit public », ainsi que certains délégataires et structures privées d’intérêt général. Un chatbot publié par une mairie ou une administration fait partie du service de communication au public en ligne : son déclencheur, sa zone de saisie, son contraste et sa navigation au clavier doivent respecter le référentiel général d’amélioration de l’accessibilité (RGAA), et le site doit publier une déclaration d’accessibilité à jour. C’est le point qui coûte le plus cher à corriger après coup, car il touche le composant lui-même : à vérifier avant la signature du contrat, pas au recettage.

Le RGPD : responsable de traitement, comme toujours

Un organisme public qui déploie un chatbot est responsable de traitement au sens du RGPD : il détermine les finalités (répondre aux usagers) et les moyens. Les conversations peuvent contenir des noms, numéros de dossier, situations familiales, parfois des révélations de santé ou de précarité : la minimisation, la durée de conservation, l’information des personnes et l’analyse d’impact quand elle est nécessaire se planifient avant le lancement. Le cadre détaillé (bases légales, consentement, droits des personnes, cookies du widget) fait l’objet de notre guide dédié à la conformité RGPD d’un chatbot.

Le tableau suivant récapitule les obligations au 16 septembre 2026 :

Outil : votre projet passe-t-il le cadrage ?

Le routeur ci-dessous croise les trois paramètres qui déterminent le niveau d’exigence d’un chatbot de service public : votre organisme, la mission confiée au bot et les données qu’il touche. Il applique la grille de lecture de cet article, il ne remplace pas une analyse juridique : c’est un outil de premier tri, avant la réunion de projet.

Données et hébergement : l’exemple donné par l’État

La question qui bloque le plus de projets publics n’est pas la conversation, c’est où passent les données. L’État a répondu côté agents : la page officielle de l’Assistant décrit « un assistant conversationnel opéré par la DINUM pour permettre aux agents publics de dialoguer avec des modèles d’intelligence artificielle générative dans un environnement sécurisé », où « vos données restent dans un circuit sécurisé et fermé grâce à Albert API et un hébergement SecNumCloud » (page consultée le 16 septembre 2026). SecNumCloud est le référentiel d’hébergement sécurisé de l’ANSSI ; Albert API est le socle interministériel développé par l’administration.

Une commune n’a pas les mêmes obligations d’hébergement qu’un ministère, mais la logique de cahier des charges est identique, à trois questions : où sont stockées les conversations, qui peut les lire, et combien de temps. Un bot d’accueil qui ne collecte rien peut tourner partout ; dès qu’il touche des numéros de dossier, l’hébergement et la localisation des données deviennent des clauses contractuelles à écrire noir sur blanc, et le sous-traitement (le fournisseur du modèle, l’hébergeur de l’éditeur) doit être documenté. La distinction agents et usagers reste essentielle : un outil interne comme l’Assistant ne sort pas les données, un bot public les reçoit de personnes parfois en situation de fragilité, qui n’ont pas choisi d’automatiser leur mairie.

Déployer sans casser la relation d’usage

Un chatbot public réussi est un chatbot que les agents ne maudissent pas. La méthode qui suit est volontairement modeste : elle démarre petit, mesure, puis élargit. Le choix de la plateforme elle-même (no-code ou sur mesure, comparatif et coûts) est détaillé dans notre guide des solutions de chatbot pour une organisation.

1. Cadrez le périmètre sur papier : liste fermée des intentions couvertes (une dizaine au départ), liste écrite de ce que le bot ne fait pas (décision, conseil juridique, réclamation). Faites valider cette liste par l’accueil, pas par la DSI seule.
2. Construisez la base sur les sources officielles : chaque réponse doit reprendre la fiche officielle (service-public.fr, votre règlement, vos arrêtés) et l’afficher comme source. Un bot qui improvise une liste de pièces est un bug administratif en série.
3. Mettez la remontée humaine en un clic : un bouton « parler à un agent » visible, avec horaires et canal de repli. C’est votre filet de sécurité juridique et relationnel.
4. Affichez la mention IA et l’information données dès l’ouverture (article 50 côté fournisseur, votre vérification côté déploiement ; information RGPD).
5. Formez les agents exploitants (article 4) : qui corrige une réponse fausse, qui ajoute une fiche, qui décide d’élargir le périmètre, à quelle fréquence on relit les conversations les plus consultées.
6. Mesurez des indicateurs de service : questions résolues sans agent, taux de remontée humaine, sujets non couverts, délai de correction d’une réponse fausse. Publiez ces chiffres : la transparence est un argument de confiance publique.

FAQ : les questions que posent les projets publics

Conclusion : un outil d’accueil, jamais un décideur

Le chatbot de service public a trouvé sa place : réponse immédiate aux questions répétitives, accompagnement des démarches en ligne, relais de l’accueil la nuit. Le cadre est désormais stable et daté : mention IA depuis le 2 août 2026 (article 50 du règlement modifié), marquage des contenus générés au plus tard le 2 décembre 2026 pour les systèmes antérieurs, maîtrise de l’outil par les agents (article 4), accessibilité RGAA (article 47 de la loi du 11 février 2005) et RGPD comme pour tout traitement public. La ligne de conduit ne changera pas : le bot informe et oriente, l’agent instruit et décide.

Pour passer à l’action, Botnation propose une page dédiée au chatbot pour mairies et services publics, avec des exemples d’usages adaptés à l’accueil des administrés. Et si vous hésitez sur le type de bot à mettre en place, notre panorama des types de chatbots vous aidera à choisir la bonne architecture avant le premier cahier des charges.