Chatbot secteur public 2026 : FranceConnect, SecNumCloud et conformité

Un chatbot destiné à une mairie, un opérateur public ou un service de l’État ne se choisit pas comme un outil de relation client classique. Il doit répondre aux usagers sans exposer leurs données, s’intégrer aux démarches existantes et respecter des exigences de sécurité que le fournisseur ne peut pas régler par une simple promesse commerciale.

En 2026, deux sujets pèsent particulièrement dans la décision : l’authentification par FranceConnect et le recours à un hébergement qualifié SecNumCloud lorsque la sensibilité des données le justifie. Ces dispositifs ne certifient pas, à eux seuls, la conformité du chatbot. Ils obligent toutefois l’administration française à examiner précisément l’identité numérique, l’emplacement des traitements, les accès techniques et les responsabilités contractuelles.

En bref : chatbot public, identité numérique et hébergement sécurisé

• SecNumCloud qualifie un service cloud, pas un chatbot dans son ensemble. Il faut vérifier que le service utilisé et son périmètre exact figurent dans la qualification.
• FranceConnect répond à un besoin d’authentification. Son intégration dépend du téléservice, des données traitées et du niveau de garantie requis.
• La conformité réglementaire reste une responsabilité partagée. Le fournisseur apporte des garanties, mais l’organisme public doit qualifier ses risques et ses obligations.
• Le chatbot doit limiter les données collectées. Une réponse automatique sur une démarche générale ne devrait pas réclamer d’informations personnelles inutiles.
• Le contrat et la réversibilité comptent autant que la démonstration. Localisation, support, sous-traitants, disponibilité et récupération des données doivent être vérifiés.

Chatbot secteur public : le cadre SecNumCloud applicable en 2026

Ce que change l’arrêté du 12 août 2026

L’arrêté du 12 août 2026 approuve la version 3.2 du référentiel SecNumCloud pour les prestataires de services d’informatique en nuage. Publié au Journal officiel le 14 août, il entre en vigueur le lendemain et s’inscrit dans le cadre réglementaire établi par le décret n° 2026-272 du 14 avril 2026.

Le texte vise les services de l’État, les opérateurs de l’État et les groupements d’intérêt public qui confient des données sensibles à un prestataire cloud. La question n’est donc pas de savoir si tout chatbot public doit automatiquement être hébergé sous SecNumCloud. Il faut d’abord déterminer si le service traite des données dont la compromission pourrait porter atteinte à la sécurité publique, à la santé, aux personnes ou à la propriété intellectuelle.

Pour retrouver le texte de référence et son périmètre, consultez l’arrêté publié au Journal officiel. Une collectivité qui déploie un assistant sur les horaires de la piscine n’a pas le même profil de risque qu’un service qui accompagne une demande d’aide sociale contenant des justificatifs personnels.

SecNumCloud porte sur le cloud, pas sur la qualité des réponses

Le référentiel couvre plusieurs modèles : IaaS, CaaS, PaaS et SaaS. Dans un chatbot SaaS, le prestataire gère généralement l’application et son infrastructure, tandis que l’administration configure les réponses et les parcours métier. La qualification doit donc être vérifiée pour la prestation effectivement utilisée, et non déduite du seul nom commercial de l’éditeur.

• IaaS : le fournisseur fournit des ressources informatiques, tandis que le commanditaire conserve la gestion de plusieurs couches logicielles.
• PaaS ou CaaS : le fournisseur prend en charge une plateforme ou un environnement de conteneurs, mais le commanditaire garde une partie du contrôle applicatif.
• SaaS : le chatbot est fourni comme une application hébergée, avec une gestion technique largement assumée par le prestataire.

SecNumCloud ne garantit ni la pertinence des réponses, ni l’accessibilité du parcours, ni l’exactitude des informations administratives affichées. Il ne remplace pas non plus les exigences spécifiques applicables aux données de santé, aux informations Diffusion Restreinte ou aux données classifiées.

À retenir : exigez une preuve de qualification correspondant à la brique réellement utilisée et au périmètre contractuel. Pour mieux comprendre la portée du référentiel, vous pouvez consulter ce guide consacré à SecNumCloud et à la qualification ANSSI.

Un chatbot peut aussi traiter des questions simples sans recueillir d’identité. Pour comparer les options métier avant de choisir une architecture, ce guide de sélection d’un chatbot aide à séparer les besoins fonctionnels des critères d’hébergement.

Si votre organisme étudie un assistant vocal pour absorber les demandes récurrentes, découvrez comment AirAgent gère les échanges vocaux et comparez ses fonctions avec votre cahier des charges.

FranceConnect et chatbot public : distinguer information et démarche authentifiée

Quand l’identité numérique est-elle nécessaire ?

Un chatbot public peut répondre à des questions générales sans demander à l’usager de se connecter. Il peut indiquer les pièces habituellement nécessaires pour une demande, expliquer les horaires d’un service ou orienter vers le bon formulaire. Cette approche réduit la collecte de données et permet de traiter une part importante des demandes sans créer de compte conversationnel.

La situation change lorsque l’assistant doit consulter un dossier individuel, afficher une information personnelle ou déclencher une démarche. L’authentification devient alors un sujet de conception à part entière : l’usager doit comprendre qu’il quitte une conversation informative pour accéder à un service lié à son identité numérique.

FranceConnect ou FranceConnect+ ne doivent pas être présentés comme des accessoires que l’on ajoute à la fin du projet. Leur usage dépend des règles du téléservice concerné, du niveau d’authentification attendu et des données manipulées. Il faut vérifier les exigences applicables au cas d’usage, plutôt que d’affirmer que tous les services publics numériques doivent utiliser le même parcours.

Une architecture claire évite les confusions

Dans un scénario prudent, le chatbot répond aux questions générales, puis transmet l’usager vers le téléservice officiel lorsque sa demande exige une consultation de dossier. L’authentification intervient dans le parcours prévu par ce téléservice. Cette séparation réduit le risque que la conversation collecte un mot de passe, un numéro de dossier ou des pièces justificatives dans un espace mal adapté.

1. Définir les demandes anonymes : horaires, conditions générales, pièces habituelles et orientation vers le bon interlocuteur.
2. Repérer les démarches personnelles : consultation d’un dossier, dépôt d’une demande ou transmission d’un justificatif.
3. Rediriger vers le parcours authentifié : expliquer pourquoi une connexion est requise et utiliser le mécanisme prévu par le service public concerné.
4. Limiter les traces : préciser quelles données de conversation sont conservées, pour quelle durée et à quelle fin.

Une commune peut, par exemple, utiliser son chatbot pour expliquer les étapes d’une demande de logement, puis orienter l’usager vers un portail sécurisé pour déposer les justificatifs. Le chatbot n’a pas besoin de mémoriser le contenu de ces pièces pour rendre le service utile.

Conseil : dessinez séparément le parcours d’information et le parcours authentifié. Cette distinction facilite les arbitrages entre expérience usager, protection des données et sécurité.

Pour approfondir l’intégration d’une identité numérique dans un téléservice, consultez ce guide sur FranceConnect et les téléservices. Les principes de conception d’un chatbot conforme sont également détaillés dans notre ressource sur le déploiement d’un chatbot respectueux du RGPD.

Vous souhaitez évaluer un accueil vocal en complément du chatbot écrit ? Testez gratuitement une solution vocale sur un cas d’usage circonscrit, sans lui confier d’emblée la gestion des dossiers sensibles.

Une bonne réponse ne doit pas pousser l’usager à trop se dévoiler

Le chatbot doit annoncer clairement ses limites et proposer un contact humain lorsque la question est complexe, urgente ou personnelle. Il doit aussi éviter d’inventer une règle administrative en l’absence de source fiable. Un lien vers la page officielle ou le formulaire concerné est souvent plus utile qu’une réponse longue mais imprécise.

Pour une mairie, le bon indicateur n’est pas seulement le nombre de conversations automatisées. Il faut aussi suivre les demandes réorientées correctement, les abandons, les erreurs de compréhension et les sollicitations transférées à un agent. L’identité numérique ne vaut que si elle ouvre un parcours cohérent et compréhensible.

Protection des données et conformité réglementaire d’un chatbot administratif

SecNumCloud ne remplace ni le RGPD ni l’homologation

La qualification cloud apporte un cadre de sécurité reconnu, mais elle ne démontre pas à elle seule que chaque traitement respecte le RGPD. L’administration reste responsable de la finalité, de la minimisation des données, de l’information des usagers et de la durée de conservation. Le prestataire doit, de son côté, respecter ses obligations contractuelles et celles qui découlent de son rôle de sous-traitant.

Le référentiel SecNumCloud prévoit une gestion des risques couvrant notamment les accès, les fournisseurs, les données personnelles, les ressources partagées et les opérations d’administration. Il impose aussi une gouvernance de sécurité, des contrôles réguliers et une révision des risques lorsque le service ou son environnement évolue. La qualification soutient donc la décision, sans supprimer le travail d’analyse du commanditaire.

Si des données de santé ou des informations soumises à des règles particulières sont traitées, une démarche complémentaire peut être nécessaire. De même, la conformité à SecNumCloud ne vaut pas conformité automatique à la politique de sécurité de l’État. Pour chaque projet, le responsable doit documenter les exigences applicables et, lorsque c’est nécessaire, conduire une appréciation des risques ou une homologation.

Les contrôles concrets à demander au fournisseur

Les promesses de « données hébergées en Europe » sont insuffisantes si elles ne couvrent que les conversations. Les identités, journaux, certificats, configurations et données techniques peuvent également révéler des informations sensibles. Le contrat doit préciser les lieux de stockage et de traitement, les modalités de support et les conditions d’accès aux systèmes.

• Localisation : vérifier où se trouvent les données métier et les données techniques, ainsi que depuis quels pays les opérations d’administration sont effectuées.
• Accès : demander les règles de gestion des privilèges, l’authentification multifacteur et la traçabilité des interventions.
• Chiffrement : préciser les protections des données stockées et en transit, ainsi que la maîtrise des clés de chiffrement.
• Sous-traitants : identifier les tiers, leurs responsabilités et les exigences de sécurité qui leur sont imposées.
• Incidents et continuité : connaître les délais de notification, les procédures de restauration et les résultats des tests de continuité.

Une vigilance particulière s’impose concernant le droit extra-européen. Le référentiel demande au prestataire d’identifier et de documenter les risques liés à des législations étrangères susceptibles de viser les données ou leurs métadonnées. L’organisme public doit examiner ces éléments, et non se contenter d’une affirmation générale de souveraineté numérique.

Point de vigilance : SecNumCloud n’apporte pas, à lui seul, une garantie technique empêchant tout accès du prestataire aux données. Si cette protection est requise, le commanditaire doit étudier des mesures complémentaires, dont un chiffrement maîtrisé sous son contrôle.

Pour approfondir les obligations et les limites de cette qualification, l’analyse de SecNumCloud 3.2 et des données sensibles du secteur public apporte un éclairage juridique complémentaire. La présentation de l’ANSSI sur les enjeux de sécurité du cloud complète utilement cette lecture.

Si votre projet comprend des appels entrants, calculez le ROI d’un agent vocal avec AirAgent, puis confrontez les gains attendus aux exigences de confidentialité et de conservation des échanges.

La transparence protège aussi la relation avec l’usager

Une politique de protection des données ne se résume pas à une page juridique. L’usager doit savoir qu’il échange avec un chatbot, quelles informations éviter de communiquer et comment joindre un agent. Si les conversations sont conservées pour améliorer le service, cette finalité doit être expliquée et encadrée.

Un assistant qui demande spontanément une adresse, une date de naissance ou une référence de dossier crée une collecte qu’il faudra justifier. À l’inverse, un parcours conçu pour répondre d’abord sans données personnelles limite l’exposition et rassure les usagers. La meilleure protection commence souvent par une question simple : cette donnée est-elle réellement nécessaire pour répondre ?

Cybersécurité, qualification cloud et responsabilités opérationnelles

Des contrôles qui couvrent l’exploitation quotidienne

Le référentiel ne s’arrête pas à la localisation des serveurs. Il encadre aussi la sécurité des comptes, les opérations de maintenance, les sauvegardes, la surveillance des événements et la gestion des vulnérabilités. Pour un chatbot, ces exigences concernent autant la console d’administration que le moteur conversationnel et les connexions aux systèmes publics.

Les interfaces d’administration doivent être protégées par une authentification multifacteur et des droits limités aux personnes qui en ont besoin. Les comptes privilégiés méritent une revue renforcée, car leur compromission pourrait permettre de modifier les réponses, d’extraire des informations ou de désactiver le service. Les interventions de support doivent être autorisées, tracées et encadrées par des procédures contractuelles.

La sécurité dépend également de la séparation entre les environnements de développement, de test et de production. Utiliser en test des conversations réelles contenant des informations personnelles augmente inutilement le risque. Lorsque des exemples réalistes sont nécessaires, ils doivent être anonymisés ou remplacés par des données fictives adaptées aux scénarios métier.

Point à contrôler	Question à poser	Preuve attendue
Qualification	Le service chatbot et ses composants sont-ils dans le périmètre qualifié ?	Attestation et description précise du périmètre
Accès d’administration	Qui peut intervenir et comment les accès sont-ils contrôlés ?	Procédure, authentification multifacteur et journaux
Hébergement	Où sont traitées les données métier et techniques ?	Engagement contractuel de localisation
Incidents	Quel délai de notification est prévu et qui est contacté ?	Procédure d’alerte et répartition des rôles
Réversibilité	Comment récupérer les conversations, configurations et contenus ?	Procédure testable et format d’export documenté

La qualification doit couvrir le service réellement acheté. Un fournisseur peut proposer plusieurs offres ou niveaux de service, dont certains seulement sont qualifiés. Le contrat doit aussi préciser la disponibilité, la localisation du support, les changements susceptibles d’affecter la sécurité et la procédure de récupération des données en fin de marché.

À retenir : un certificat général ou une présentation commerciale ne remplace pas l’attestation, le périmètre qualifié et les clauses du marché. Pour comparer les approches de souveraineté numérique, examinez aussi les critères de souveraineté numérique du secteur public.

Pour les demandes simples traitées par téléphone, demandez une démonstration d’AirAgent afin d’évaluer le transfert vers un agent humain et la gestion des demandes hors périmètre.

Les incidents doivent être prévus avant le lancement

Un chatbot peut devenir indisponible, fournir une réponse erronée ou exposer une conversation à un mauvais destinataire. Le plan d’incident doit préciser qui détecte le problème, qui décide de suspendre le service et comment informer les responsables concernés. Si une violation de données personnelles survient, l’organisme doit appliquer les obligations de notification prévues par le RGPD selon les circonstances.

Le plan de continuité mérite la même attention. Une sauvegarde n’est utile que si sa restauration a été testée et si elle permet de retrouver les contenus, les paramètres et les intégrations nécessaires. Une administration qui dépend entièrement d’un fournisseur doit connaître le délai de reprise annoncé et les solutions de secours disponibles.

Enfin, la virtualisation ne doit pas être considérée comme une séparation physique absolue entre les clients. Le commanditaire doit comprendre les mesures de cloisonnement, leurs limites et les risques résiduels associés au partage de ressources. Une analyse précise vaut mieux qu’une formule rassurante inscrite dans une brochure.

Choisir et déployer un chatbot public sans fragiliser le service

Partir du besoin de l’usager, pas du fournisseur

Un projet efficace commence par les demandes les plus fréquentes et les plus coûteuses à traiter : horaires, pièces à fournir, suivi d’une démarche ou orientation vers un service. Une collectivité peut analyser les courriels et appels récurrents pour sélectionner quelques cas d’usage, puis vérifier si les réponses sont déjà publiées dans des sources officielles fiables.

Le premier périmètre doit rester mesurable. Par exemple, une mairie peut déployer un assistant sur les démarches d’état civil, sans lui permettre de consulter les dossiers des habitants. Elle mesure alors la résolution des demandes, la satisfaction, les transferts vers un agent et les erreurs de réponse avant d’élargir le service.

Un projet de chatbot pour une collectivité ne se limite pas au choix d’un moteur. Il faut aussi planifier la mise à jour des contenus, la validation des réponses par les métiers et l’accessibilité des échanges. Pour cadrer ces décisions, consultez notre guide consacré au chatbot pour mairie et collectivité.

Une grille de décision orientée risques et résultats

1. Décrire les parcours : séparer les demandes d’information des opérations qui nécessitent une identité vérifiée ou un accès au dossier.
2. Classer les données : déterminer si le chatbot traite des informations publiques, personnelles, sensibles ou soumises à une exigence sectorielle.
3. Évaluer le fournisseur : demander le périmètre de qualification, la localisation, les sous-traitants et les modalités de support.
4. Définir des indicateurs : suivre le taux de résolution, la qualité des redirections, la disponibilité et le coût par demande traitée.
5. Prévoir la sortie : tester l’export des contenus et la récupération des données avant la signature du marché.

Ces étapes évitent de confondre une démonstration convaincante avec une solution exploitable. Un assistant qui répond vite mais cite une ancienne procédure peut augmenter la charge des équipes au lieu de la réduire. Le processus de validation éditoriale doit donc identifier un responsable métier et une fréquence de mise à jour.

Le choix d’un service qualifié doit aussi être contractualisé. Il faut vérifier que la prestation concernée est bien celle couverte par la qualification, et intégrer cette exigence dans la convention de service. Si le prestataire réalise certaines tâches hors du périmètre qualifié, l’organisme doit connaître précisément les écarts et les risques associés.

Conseil : lancez d’abord un pilote limité aux questions dont les réponses sont stables, publiques et vérifiables. C’est le moyen le plus sûr de mesurer le gain avant de connecter un outil à des dossiers individuels.

Si vous comparez des solutions pour plusieurs canaux, notre dossier sur le chatbot public et SecNumCloud complète cette grille. Pour juger l’option d’un fournisseur français, voyez également les critères associés aux solutions d’IA françaises.

Pour mesurer l’intérêt d’un traitement vocal sur les demandes répétitives, comparez AirAgent avec votre solution actuelle en utilisant vos volumes réels, vos horaires d’ouverture et vos coûts de transfert vers les équipes.

Mesurer la valeur publique au-delà des économies

Le retour sur investissement ne se réduit pas aux minutes économisées. Un chatbot utile améliore aussi l’accès à l’information en dehors des horaires d’ouverture, rend les démarches plus faciles à comprendre et oriente les usagers vers le bon service. Ces bénéfices doivent être mesurés sans masquer les coûts d’intégration, de contrôle juridique, de mise à jour et d’accompagnement des agents.

Une administration peut suivre le coût total sur douze mois : abonnement, mise en place, connecteurs, supervision et temps consacré aux contenus. Elle doit le comparer au volume effectivement automatisé, et non au nombre total de conversations. Une réponse qui finit systématiquement par un appel ou un courriel n’a pas généré le même gain qu’une demande résolue dès le premier échange.

Le dernier arbitrage porte sur la confiance. Si l’usager sait quand il parle à un chatbot, peut demander un interlocuteur et trouve des sources fiables derrière les réponses, l’automatisation devient un prolongement crédible du service public. Si l’identité, l’hébergement et les responsabilités restent flous, la technologie ajoute un risque au lieu de simplifier la démarche.

Questions fréquentes sur FranceConnect, SecNumCloud et chatbot public

Un chatbot de service public doit-il obligatoirement être hébergé sous SecNumCloud ?

Pas automatiquement. Il faut évaluer la sensibilité des données, le cadre applicable et le périmètre du service cloud utilisé. Pour les données concernées par les exigences du référentiel, vérifiez que la prestation exacte est qualifiée ou couverte par une équivalence reconnue.

SecNumCloud certifie-t-il la conformité RGPD du chatbot ?

Non. SecNumCloud encadre la sécurité du service cloud, mais ne démontre pas à lui seul que le traitement respecte le RGPD. L’administration doit notamment définir les finalités, limiter les données collectées, encadrer la conservation et informer les usagers.

FranceConnect doit-il être utilisé dans toute conversation avec un chatbot public ?

Non. Une demande d’information générale peut souvent être traitée sans authentification. FranceConnect ou un autre mécanisme doit être envisagé lorsque le parcours nécessite une identité vérifiée, conformément aux exigences du téléservice concerné.

La qualification SecNumCloud empêche-t-elle le fournisseur d’accéder aux données ?

Elle impose des exigences de sécurité et des engagements encadrés, mais ne constitue pas à elle seule une protection technique absolue contre l’accès du prestataire. Si cette garantie est nécessaire, le commanditaire doit étudier des mesures complémentaires, notamment le chiffrement sous sa maîtrise.