Chatbot personnalisé : checklist projet

Chatbot personnalisé : checklist projet

Si je ne fixe pas le cadre dès le départ, le chatbot rate sa cible. En pratique, je dois décider avant tout de 8 points: le cas d’usage, les limites, les rôles, les sources, les langues, les règles de données, les accès système, les tests et le relais humain.

Voici l’idée en une vue simple:

• 1 cas d’usage pour la v1 avec des KPI clairs, par exemple 60 % de résolution sans humain ou 30 leads/mois
• Des limites écrites: ce que le bot peut faire, ce qu’il refuse, et quand il passe à une personne
• 4 rôles nommés: projet, contenu, technique, conformité
• Des sources approuvées seulement: pas de brouillons, pas de contenus obsolètes
• Une localisation fr-CH stricte: 15.07.2026, CHF 1'200.–, 1,5 %, unités métriques, °C
• Des règles de données nettes: collecte minimale, durée de conservation, accès limités, info claire dès l’ouverture
• Des accès système limités: d’abord en lecture seule, puis actions ciblées avec validation humaine si le risque est élevé
• Des tests avant mise en ligne: fonctionnel, linguistique, fallback, régression
• Un suivi après lancement: résolution, escalade, fallback, CSAT, temps de réponse
• Une reprise manuelle cadrée avec SLA, résumé de contexte et routage par langue

Je retiens aussi un point simple: en Suisse, la conformité LPD ne se traite pas “plus tard”. Le texte rappelle qu’en cas de manquement, des amendes peuvent aller jusqu’à CHF 250'000 pour certaines obligations. Donc, si personne n’est nommé, le risque reste flou.

En clair, cette checklist me sert à transformer une idée de chatbot en plan de travail: une décision, un responsable, une échéance pour chaque sujet. La suite détaille comment poser ce cadre sans partir dans tous les sens.

1. Définir le périmètre, les objectifs et les responsabilités

Cas d'usage principal, objectifs métier et critères de succès

Pour la v1, gardez un seul cas d'usage principal. Pas trois. Pas cinq. Un seul. Cela peut être la baisse des demandes au support, la qualification de leads B2B, l'accès à une base de connaissances interne, ou l'orientation multilingue. Le reste peut venir plus tard, avec une date cible et des KPI à part.

Pour que cet objectif serve à quelque chose, il doit être mesurable. Par exemple : résoudre au moins 60 % des questions fréquentes sans aide humaine, ou générer 30 leads qualifiés par mois via le chatbot du site. ^[3][4][5][6]

Les métriques à poser dès le départ changent selon le contexte :

Contexte	KPI prioritaires
Support client	Taux de déflexion, taux de résolution, CSAT, temps de première réponse
Qualification de leads	Nombre de leads qualifiés/mois, taux de conversion en rendez-vous
Base de connaissances interne	Taux de succès des recherches, réduction des tickets helpdesk
Orientation multilingue	Couverture linguistique, temps d'accès à l'information

Suivez ces KPI chaque mois pendant 3 à 6 mois. Ce cadre va ensuite guider les contenus, les intégrations et les tests. En clair : si l'objectif est flou, le chatbot le sera aussi.

Limites du périmètre, canaux et règles de refus

Il faut aussi dire, noir sur blanc, ce que le chatbot ne fera pas. Sujets interdits, actions refusées, passage à un humain : tout doit être écrit. Le plus simple est de rédiger une note de périmètre avec les sujets autorisés, les sujets interdits, les actions autorisées et celles réservées à une personne.

Exemple concret : un chatbot peut expliquer les délais fiscaux généraux, mais il ne peut pas formuler un conseil d'optimisation personnalisé. Il peut aussi proposer des créneaux libres, mais ne confirme pas un rendez-vous sans validation humaine.

Pour les questions sensibles - juridiques, médicales, RH, financières - fixez des règles de refus explicites avec un message préapprouvé en fr-CH et une escalade claire : contact direct, demande de rappel, lien vers un spécialiste, avec horaires au format local, par exemple Lun–Ven, 08:30–17:30. Côté canaux, choisissez un seul point d'entrée au lancement - site web, portail client ou intranet - puis notez les critères qui permettront d'aller plus loin. Ces limites servent de base pour les sources, les refus et les tests.

Responsable projet, responsable contenu, responsable technique et responsable conformité

Un projet chatbot sans propriétaire clair finit souvent par partir dans tous les sens. Avant même de lancer le développement, quatre rôles doivent être nommés :

Rôle	Responsabilité principale
Responsable projet	Objectifs, budget (CHF), calendrier, arbitrages de périmètre
Responsable contenu	Sources approuvées, scripts, localisation fr-CH, mises à jour
Responsable technique	Intégrations, environnements, sécurité, incidents
Responsable conformité	LPD/RGPD, consentement, rétention des données, AIPD

Ces rôles se croisent à chaque choix qui compte : ajout d'un nouveau flux, intégration d'un système externe, modification du texte de consentement, ouverture d'une nouvelle langue. Documentez les responsabilités pour éviter les zones grises.

En Suisse, la Loi fédérale sur la protection des données (LPD) révisée peut prévoir des amendes allant jusqu'à CHF 250'000 en cas de manquement aux obligations d'information, de diligence et de sécurité. ^[1][2] Dit simplement : il faut une personne clairement désignée pour la conformité.

Une fois ces rôles nommés, l'audit des sources et des données peut commencer.

sbb-itb-454261f

Comment créer un CHATBOT IA qui QUALIFIE vos PROSPECTS en moins de 15 minutes (Typebot et Mistral)

2. Auditer les contenus, les sources de données, les langues et la conformité

Après le cadrage du projet, fixez clairement ce qui nourrit le chatbot : les sources, les langues et les données.

Sources approuvées, contenu canonique et workflows de mise à jour

Avant toute indexation, faites l’inventaire de toutes les sources qui peuvent alimenter le chatbot : pages du site, articles du centre d’aide, PDF, données CRM, documentation produit, politiques internes et bases de données structurées. Pour chaque source, notez le propriétaire, la date de dernière mise à jour, le statut d’approbation, la langue et le niveau d’accès - public, interne ou confidentiel.

Rangez ensuite chaque source dans l’une de ces trois catégories :

• canonique : approuvée, maintenue activement, référence unique
• brouillon : en cours de révision, donc à exclure jusqu’à validation
• obsolète : remplacée ou archivée

En production, le chatbot ne doit interroger que les sources canoniques. Dès qu’un changement est validé, il doit déclencher un réindexage. Dit simplement : votre moteur d’indexation ne doit intégrer que les contenus validés, point final.

Formalisez aussi un cycle de mise à jour simple et net : modification proposée → validation par le propriétaire du domaine → vérification conformité/légale si besoin → publication dans la source → rafraîchissement de l’index du chatbot. Fixez en parallèle une fréquence de révision maximale selon le type de contenu : articles de support revus tous les 6 à 12 mois, documents légaux mis à jour à chaque changement réglementaire, tarifs validés avant chaque lancement.

Ces sources forment la base unique des contenus et des réponses du chatbot. Mais il y a un piège classique : même des sources bien validées ne servent à rien si elles n’existent pas dans les langues attendues.

Langues supportées, règles terminologiques et localisation fr-CH

Construisez une matrice langue × intention × contenu pour relier chaque flux et chaque contenu aux langues disponibles. Si un flux critique manque dans une langue cible, bloquez le lancement. ^[7][10]

Préparez ensuite un glossaire bilingue avec les termes approuvés pour les produits, les rôles et les mentions légales. Ajoutez aussi les formulations interdites et les règles de politesse. En Suisse, le « vous » formel reste la norme dans un cadre B2B et institutionnel.

Pour la localisation fr-CH, appliquez ces formats sans exception : CHF 1'200.–, 1,5 %, 15.07.2026, unités métriques, adresses locales. ^[7][10]

Ces règles ne concernent pas seulement les réponses du chatbot. Elles doivent aussi s’appliquer aux écrans d’information et aux notices de consentement. Et là aussi, pas de zone grise : une bonne localisation ne suffit pas si la collecte et la rétention des données partent dans tous les sens.

Confidentialité, consentement, rétention et gouvernance des données

Listez précisément les données personnelles que le chatbot collecte, stocke ou journalise : identifiants, adresses e-mail, données financières, informations RH. Appliquez la minimisation des données ainsi que les règles de sécurité prévues par la LPD, et le RGPD si cela s’applique. Cela vise surtout les principes de proportionnalité, de limitation des finalités et de sécurité des données.

Dès l’ouverture du chatbot, affichez un avis bref qui explique qui contrôle les données, ce qui est journalisé, à quelles fins et pendant combien de temps. Faites une séparation nette entre le traitement nécessaire - la fourniture du service - et l’usage optionnel, comme l’amélioration des modèles ou l’analyse marketing. Seul cet usage optionnel demande un consentement explicite.

Définissez aussi des durées de rétention différenciées selon le niveau de risque. Par exemple, 3 à 12 mois pour les transcriptions brutes contenant des données personnelles, et 12 à 24 mois pour les journaux anonymisés. Limitez l’accès aux transcriptions brutes à un groupe restreint, comme l’équipe qualité, le DPO et les opérateurs techniques. Prévoyez enfin des mécanismes qui permettent à l’utilisateur d’exercer ses droits : accès, rectification et suppression.

Pour les cas d’usage sensibles - finance, RH, ONG, domaines proches du médical - gardez le traitement des données personnelles dans des systèmes internes contrôlés. Et, chaque fois que possible, pseudonymisez ou anonymisez les journaux du chatbot. ^[9][8]

Ces règles doivent ensuite encadrer les accès, les journaux et les tests de sécurité.

3. Spécifier les intégrations, les droits d'accès, les tests et les contrôles de sécurité

Après les sources et la conformité, il faut cadrer ce que le chatbot peut toucher, ce qu'il peut faire et comment vous le testez avant la mise en ligne. C'est là que se jouent les droits, les tests et les garde-fous de sécurité.

Intégrations système, droits lecture seule vs actions, et étapes de validation humaine

Commencez par lister chaque système relié au chatbot : CMS, CRM, ERP, moteur de réservation, base de connaissances, couche de recherche, outil de support, fournisseur d'identité (SSO/IdP), couche analytique. Pour chaque connexion, notez trois points simples : le domaine de données visé, l'environnement concerné (test ou production) et le mode d'accès, soit lecture seule, soit actions autorisées.

Le bon réflexe, c'est de démarrer en lecture seule. Par exemple : consulter du contenu dans le CMS ou la base de connaissances, lire un profil client dans le CRM, ou vérifier un statut de commande ou de livraison dans l'ERP. Les droits d'action - créer un lead, ouvrir un ticket, modifier une réservation, déclencher un remboursement - ne devraient arriver qu'une fois le cadre de gouvernance bien en place. Et dans les domaines sensibles, toute action à fort impact doit passer par une validation humaine.

Système	Mode d'accès	Exemple d'action autorisée	Approbation humaine
CMS / base de connaissances	Lecture seule	Récupérer un article FAQ	Non
CRM	Lecture + actions limitées	Créer un lead	Non
ERP	Lecture seule	Consulter le statut de livraison	Non
Outil de support	Action limitée	Ouvrir un ticket, ajouter une note	Non
Facturation / paiements	Action restreinte	Préparer un remboursement	Oui - équipe finance
IdP / SSO	Lecture des assertions d'identité	Vérifier le rôle de l'utilisateur	Non

Utilisez des comptes de service dédiés pour chaque système. Évitez les comptes génériques partagés. Préférez des jetons à courte durée de vie et stockez les secrets dans un coffre-fort, comme un vault ou un KMS. Journalisez aussi les prompts, les réponses, les appels aux outils, les accès et les décisions d'autorisation dans un registre central lié au monitoring, avec un journal non modifiable. En clair : les droits que vous donnez au chatbot vont dicter votre plan de test et votre runbook d'incident.

Plan de tests : fonctionnel, linguistique, fallback et régression

Le plan de lancement doit couvrir quatre axes. L'idée n'est pas de tester "un peu de tout", mais de vérifier les cas qui comptent, dans les bonnes langues, avec les bons formats locaux et avec les refus attendus hors périmètre.

• Tests fonctionnels : flux principaux comme une question simple, un échange sur plusieurs tours ou une collecte de données, avec des critères de succès clairs pour chaque scénario.
• Tests linguistiques fr-CH : cohérence des termes, formats locaux comme CHF 1'200.– ou 15.07.2026, absence de mélange FR/EN mal maîtrisé, et scripts relus par des locuteurs natifs.
• Tests de fallback : refus poli des demandes hors périmètre, absence de réponses inventées, puis transfert propre vers un agent humain avec un résumé de la langue, de l'intention, des données déjà collectées et des pistes déjà tentées.
• Tests de régression : jeu de cas de référence à rejouer à chaque mise à jour de prompt, de contenu ou d'intégration ; aucun déploiement en production sans rapport de régression documenté.

Fixez aussi des critères de lancement sans zone grise : aucune action non autorisée, aucune fuite de secret, réponses multilingues validées, fallback opérationnel, zéro régression critique. Si un écart apparaît, il doit remonter au pilotage de projet avant toute mise en production.

Injection de prompt, fuite de données, secrets et gestion des incidents

Les instructions système et les entrées utilisateur doivent rester séparées de façon stricte. Il ne faut jamais injecter directement l'entrée d'un utilisateur dans les instructions système. Même logique pour les contenus récupérés - pages web, tickets, e-mails - qui doivent être traités comme des sources non fiables tant qu'ils n'ont pas été filtrés.

Appliquez le principe du moindre privilège à chaque niveau : rôles d'accès aux systèmes, portées des API, permissions de stockage. Les actions autorisées doivent rester limitées à une liste explicite d'intentions reconnues, avec validation des paramètres. Pour les journaux, évitez de stocker le contenu complet des messages qui contiennent des données personnelles. Mieux vaut tokeniser ou masquer les champs sensibles, puis limiter l'accès aux journaux bruts à un groupe restreint et clairement identifié.

Enfin, préparez un runbook d'incident concret. Il doit prévoir la suspension des connecteurs, la révocation des credentials, la clôture des sessions actives, la revue des journaux et, si des données personnelles ont été exposées, le déclenchement de la procédure de notification selon la LPD. En Suisse, les sanctions en cas de non-conformité visent les personnes responsables, pas seulement l'entreprise. Autrement dit, il faut documenter noir sur blanc qui porte chaque contrôle et qui lance la réponse à incident.

4. Suivi des KPI, reprise manuelle et gouvernance continue

KPI essentiels, cadence de reporting et décisions d'ajustement

Une fois le chatbot en ligne, les KPI servent à vérifier si le cadrage de départ tient la route en production. L'idée est simple : mesurer peu, mais mesurer juste. Concentrez-vous sur les KPI liés au cas d'usage prioritaire, avec un tableau de bord réduit et facile à exploiter.

Les indicateurs à suivre sont :

• le taux de résolution autonome
• le taux de résolution
• le taux d'escalade
• le taux de fallback ou d'intentions non comprises
• le temps de réponse moyen
• le taux de conversion pour les cas de génération de leads
• le CSAT

Chaque KPI doit avoir un seuil d'alerte, un responsable, et une action corrective. Sinon, on voit le problème, mais personne ne sait quoi faire ensuite.

Pour le suivi, prévoyez :

• une revue opérationnelle hebdomadaire ou toutes les deux semaines avec le chef de projet et le responsable contenu
• une revue mensuelle avec les parties prenantes métier, techniques et conformité
• un bilan trimestriel pour vérifier si le chatbot contribue bien aux objectifs stratégiques

Segmentez aussi les données par langue, canal et type d'utilisateur. C'est souvent là que les écarts apparaissent en premier. Un bot peut très bien marcher sur le site web en français, puis décrocher sur WhatsApp ou sur une autre langue. Cette lecture fine aide à corriger les parcours au bon endroit, sans toucher à tout le système.

Ces alertes servent aussi à déclencher le relais humain.

Workflow de reprise manuelle, SLA et instructions de transfert

Dès qu'une demande sort du périmètre autorisé, le relais humain doit prendre la main. Ce passage ne doit pas être improvisé. Il faut le définir comme un flux dédié, avec des règles claires.

Le transfert s'active dès qu'une demande dépasse les droits ou le périmètre du chatbot. Les déclencheurs les plus courants sont une demande explicite de l'utilisateur, des échecs de compréhension répétés, des signes de frustration, des sujets sensibles, ou une demande qui va au-delà des droits d'action du bot.

Au moment du transfert, le chatbot doit envoyer un résumé clair avec :

• la langue préférée
• l'identifiant ou la référence client, si disponible
• l'historique utile de la conversation
• l'intention détectée
• les actions déjà tentées

Le routage se fait ensuite selon la langue et le domaine concerné, par exemple support francophone ou facturation. L'utilisateur ne doit pas avoir à répéter son problème. C'est un détail en apparence, mais en pratique, c'est souvent ce qui fait basculer l'expérience du bon au pénible.

Les délais doivent être annoncés sans flou. Durant les heures de bureau, par exemple de 08h00 à 18h00, heure de Genève, du lundi au vendredi, une escalade via chat devrait recevoir une réponse sous 15 minutes. Pour les demandes traitées par ticket ou e-mail, fixez un autre délai, par exemple 4 heures ouvrables. En dehors des heures de bureau, le chatbot indique simplement qu'il transmet le message et qu'une réponse sera donnée au plus tard le jour ouvrable suivant.

En cas d'erreur technique qui bloque une automatisation, le chatbot interrompt le flux et informe l'utilisateur dans sa langue. Le cas est ensuite transmis au support technique avec ses métadonnées.

Conclusion : une checklist pour un chatbot fiable dès le lancement

Un projet de chatbot personnalisé ne s'arrête pas au moment de la mise en ligne. Il tient surtout sur quelques règles simples, appliquées sérieusement : un périmètre clair, des sources validées et à jour, une localisation fr-CH soignée, des droits d'accès limités au strict nécessaire, des tests complets avant chaque déploiement, et une protection des données conforme à la LPD.

Après le lancement, la qualité se joue dans la durée. Ce sont les KPI, la gouvernance régulière et le workflow de reprise manuelle qui permettent de garder le cap. Cette checklist couvre l'ensemble des piliers - périmètre, sources, langues, conformité, intégrations, tests, KPI et reprise manuelle - afin d'aligner les équipes et de donner aux parties prenantes une base commune pour décider et agir.

FAQs

Par quoi commencer pour la v1 ?

Commencez par poser un cadre clair et strict. Définissez d’abord votre profil client idéal (ICP), puis fixez des critères de qualification nets, comme le budget ou l’intention d’achat.

Ensuite, misez sur une version solide dans une langue principale. Dès le départ, tenez compte du multilinguisme suisse et du respect de la LPD. Faites aussi un audit de vos données, automatisez les processus critiques et validez la solution avec un projet pilote.

Quels risques si la conformité LPD est négligée ?

Négliger la conformité à la LPD expose votre entreprise à de gros risques, sur le plan juridique comme dans l’activité de tous les jours. Si vous traitez des données sensibles, l’absence d’AIPD peut entraîner des sanctions.

Et ce n’est pas juste un sujet légal. Une telle lacune peut aussi fragiliser la sécurité des données et entamer la confiance de votre clientèle suisse. Pour réduire ces risques, mieux vaut prévoir un hébergement en Suisse et intégrer des mesures de protection dès la conception.

Quand faut-il transférer à un humain ?

Le passage à un conseiller humain doit se faire tout de suite si la demande est urgente, complexe, sensible ou sort du cadre habituel du chatbot.

Dans ce cas, le système peut diriger la demande vers l’équipe compétente et assurer un relais fluide, avec tout l’historique et les données client synchronisés en temps réel.