Un chatbot de mairie peut répondre avec assurance une information fausse : un délai, un tarif, une pièce à fournir. La CNIL le rappelle dans ses questions-réponses sur l’IA générative : « ces systèmes peuvent générer des résultats inexacts » (CNIL, 18 juillet 2024). L’ANSSI recommande des tests de performance et de qualité des réponses avant la mise en production, et indique qu’ils peuvent se répéter à une fréquence donnée, pas seulement lors des déploiements (recommandation R24 du guide ANSSI-PA-102, 29 avril 2024). Cette page décrit comment une mairie construit ces tests, avec n’importe quel outil ; le choix de l’outil est détaillé dans le guide du chatbot mairie.
Deux mesures à ne pas confondre
La première mesure dit si la fiche qui porte la réponse figure parmi celles que l’outil a retrouvées. La seconde dit si la réponse rédigée est juste. La première peut être bonne quand la seconde ne l’est pas : le modèle peut mal lire une fiche juste, par exemple prendre le tarif d’une autre année dans une fiche voisine. Un fournisseur qui ne donne que la première mesure ne répond qu’à la moitié de la question (voir la page RAG pour une mairie).
Où prendre les questions
Les meilleures questions sont celles que la mairie reçoit déjà. Elles viennent de quatre endroits : les appels et les passages à l’accueil, les courriels et les formulaires de contact, la foire aux questions du site, les questions des agents sur ce que les habitants demandent le plus. Chaque question garde la formulation de l’habitant, fautes de frappe et abréviations comprises. Une question réécrite proprement par un agent teste moins bien l’outil.
Les questions ne contiennent ni nom ni coordonnée : si une question réelle en porte une, elle est réécrite sans elle avant d’entrer dans le jeu de test.
Sept types de questions à prévoir
| Type | Ce qu’il vérifie | Réponse attendue |
|---|---|---|
| Question courante | Horaires, adresse, démarche simple | La bonne information et la bonne page |
| Question mal formulée | Fautes, abréviations, phrases incomplètes | La même information qu’avec la formulation correcte |
| Question à plusieurs sources | Une démarche qui dépend d’une page de la commune et d’une fiche nationale | Une réponse qui ne mélange pas les deux |
| Question datée | Tarif d’une année, fermeture exceptionnelle | La valeur de la bonne année ou de la bonne période |
| Question piège | Information absente du site de la mairie | Un refus qui dit que le site ne la publie pas, et comment joindre la mairie |
| Question sensible | Santé, urgence, situation sociale | L’orientation que la mairie a décidée, sans réponse improvisée |
| Question détournée | Demande de contourner les consignes, sujet hors commune | Un refus poli qui reste dans le cadre des services municipaux |
Aucune règle officielle ne fixe la répartition entre ces sept types. Elle se décide avec la mairie, en tenant compte de ce qu’elle reçoit le plus. Le nombre de questions de chaque type compte moins que la présence des sept.
Écrire la réponse attendue avant le test
Pour chaque question, un agent écrit trois choses avant de lancer l’outil : la page qui contient la réponse, le fait attendu (heure, montant, pièce, numéro) et la date de la page. Écrire la réponse après avoir vu celle de l’outil conduit à la trouver juste. Pour une question piège, la réponse attendue est un refus, et la page source est « aucune ».
Quatre verdicts
Chaque réponse reçoit un verdict, jugé contre la page source.
- Juste : le fait demandé est exact et la page citée est la bonne.
- Partielle : le fait est exact mais incomplet, ou la page citée n’est pas la bonne alors que le fait l’est.
- Fausse : le fait est inexact, d’une autre année, d’un autre service, ou inventé.
- Refus : l’outil dit qu’il ne sait pas. Un refus à une question piège est un résultat juste. Un refus à une question dont la réponse figure sur le site est un échec de recherche.
Une réponse fausse énoncée avec assurance pèse plus qu’une réponse partielle. La mairie décide avant le test de ce qui bloque l’ouverture. Je recommande de bloquer sur toute réponse fausse portant sur un délai, un tarif ou une démarche. Je n’ai trouvé aucun seuil officiel de justesse pour un assistant de mairie (recherche du 20 octobre 2026) : la mairie fixe le sien avant le test et l’écrit.
Une banque de contrôle écrite à part
Un outil se règle sur les questions de test : le fournisseur corrige chaque erreur relevée, puis relance. À la fin, le taux monte, et personne ne sait s’il tiendrait sur d’autres questions. Une seconde banque, écrite à part, jamais communiquée au fournisseur avant le test, mesure l’écart. Un taux bon sur la banque de réglage et mauvais sur la banque de contrôle signale un outil réglé pour les questions connues.
Les agents jugent, la mairie valide
Les agents de la mairie relisent les réponses : ils connaissent les habitants, les services et les exceptions. Le fournisseur n’est pas le seul juge de ses propres réponses. La mairie reçoit le résultat par écrit, question par question, avec les verdicts, et valide une version de référence avant que l’outil soit ouvert aux habitants.
Après l’ouverture
Un test ne se fait pas une fois. Le site de la commune change, les tarifs changent, les habitants posent d’autres questions. Les réponses jugées fausses ou incomplètes se corrigent dans la base, puis se mesurent de nouveau avec les mêmes questions. Les questions réelles des habitants alimentent le jeu de test suivant. Une question sans réponse est un signal utile : elle montre ce que le site de la commune ne dit pas.
Un test de justesse ne remplace pas un test de sécurité. L’ANSSI recommande séparément des audits de sécurité avant la mise en production d’un système d’IA : tests d’intrusion, tests de résistance du modèle aux attaques (recommandation R23 du même guide).
Chez Marianne
Marianne est en test : aucune commune ne l’a en service. Avant l’ouverture aux habitants, Civik-ia pose 300 questions de test et juge chaque réponse contre sa page source (juste, partielle, fausse ou refus). Une banque de contrôle, écrite à part, vérifie que l’outil n’a pas été réglé pour les seules questions connues. Les agents de la mairie relisent les réponses, et la mesure est remise à la mairie avec la version de référence. Les banques de test contiennent des questions pièges dont la seule réponse juste est un refus. Une batterie d’attaques est rejouée après chaque modification des consignes du modèle, de l’authentification ou du serveur web.
Marianne se présente comme une intelligence artificielle dès son premier message, comme le prévoit l’article 50 du règlement européen sur l’intelligence artificielle, applicable depuis le 2 août 2026.
Civik-ia ne publie pas de taux de justesse tant qu’aucune commune n’a Marianne en service : les mesures portent sur des communes de test. La page RAG pour une mairie décrit ce que cette mesure prouve et ce qu’elle ne prouve pas ; le cadre est sur la page guichet citoyen IA.
Questions fréquentes
Combien de questions faut-il pour tester un chatbot de mairie ?
Plusieurs centaines. Je n’ai trouvé aucun nombre officiel. La méthode de Civik-ia en prévoit 300 avant d’ouvrir Marianne aux habitants d’une commune, plus une banque de contrôle écrite à part.
Quel taux de réponses justes exiger avant d’ouvrir ?
Aucun seuil officiel n’existe à ma connaissance. La mairie fixe le sien avant le test et l’écrit. Ce qui compte d’abord : aucune réponse fausse sur un délai, un tarif ou une démarche.
Un refus de l’assistant est-il un échec ?
Pas quand la réponse n’est pas sur le site : le refus est alors le bon résultat. C’est un échec quand la réponse figure sur une page de la mairie et que l’outil ne l’a pas trouvée.
Qui doit juger les réponses ?
Les agents de la mairie, qui connaissent les services et les exceptions. Le fournisseur ne juge pas seul ses propres réponses. La mairie valide par écrit une version de référence.
Faut-il retester après l’ouverture ?
Oui. L’ANSSI recommande ces tests avant la mise en production et indique qu’ils peuvent se répéter à une fréquence donnée, pas seulement au déploiement. Après chaque correction de la base, les mêmes questions se rejouent.
Un bon test de justesse suffit-il à garantir la sécurité de l’outil ?
Non. La justesse des réponses et la sécurité de l’outil se testent séparément : l’ANSSI recommande des audits de sécurité avant la mise en production d’un système d’IA.